[PATCH] xilinx: common: Add support for partial string match in board_fit_config_name_match()
Board name in FIT image can use U-Boot regular expressions SLRE to instruct U-Boot to handle all revisions for certain board. For example when name (description property) is saying "zynqmp-zcu104-revA" only description with this name is selected. When zynqmp-zcu104.* is described then all board revisions will be handled by this fragment. Xilinx normally have some board revisions which are SW compatible to each other. That's why make sense to define board name with revisions first follow by generic description with '.*' at the end like this: config_1 { description = "zynqmp-zcu104-rev[AB]"; fdt = "zynqmp-zcu104-revA"; }; config_2 { description = "zynqmp-zcu104.*"; fdt = "zynqmp-zcu104-revC"; }; Signed-off-by: Michal Simek --- board/xilinx/common/board.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c index 59d87f235202..823d703ea93c 100644 --- a/board/xilinx/common/board.c +++ b/board/xilinx/common/board.c @@ -1,7 +1,9 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * (C) Copyright 2014 - 2020 Xilinx, Inc. - * Michal Simek + * (C) Copyright 2014 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. + * + * Michal Simek */ #include @@ -22,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -468,6 +471,21 @@ int __maybe_unused board_fit_config_name_match(const char *name) { debug("%s: Check %s, default %s\n", __func__, name, board_name); +#if !defined(CONFIG_SPL_BUILD) + if (CONFIG_IS_ENABLED(REGEX)) { + struct slre slre; + int ret; + + ret = slre_compile(&slre, name); + if (ret) { + ret = slre_match(&slre, board_name, strlen(board_name), +NULL); + debug("%s: name match ret = %d\n", __func__, ret); + return !ret; + } + } +#endif + if (!strcmp(name, board_name)) return 0; -- 2.36.1
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
Hi, On 1/5/23 21:35, Marek Vasut wrote: On 1/5/23 19:31, Patrick DELAUNAY wrote: Hi Marek, Hi, [...] I tested on STM32MP157C-EV1 on my side... with 1GiB mermory size U-Boot is booting on next TOP (for trusted boot with TF-A and OP-TEE) U-Boot 2023.01-rc4-00386-gb429e78942de (Jan 05 2023 - 17:44:04 +0100) Note that I am not running into this problem on next, but on current master . Also, I am using basic boot. Can you retest ? [...] I retest on master for STM32MP157C-EV1, basic defconfig. SHA1 = 8d6cbf5e6bc4e10e38b954763fa025caed517cc2 no blocking issue on my side I go up to U-Boot console. but it is the same binary than you (not the same defconfig) so your blcoking point is perhaps only masked. regards. Patrick
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
Hi, On 1/5/23 20:25, Pali Rohar wrote: Ok, so it is working... On Thursday 05 January 2023 19:31:19 Patrick DELAUNAY wrote: I tested on STM32MP157C-EV1 on my side... with 1GiB mermory size U-Boot is booting on next TOP (for trusted boot with TF-A and OP-TEE) U-Boot 2023.01-rc4-00386-gb429e78942de (Jan 05 2023 - 17:44:04 +0100) stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) CPU: STM32MP157C?? Rev.Z Model: STMicroelectronics STM32MP157C eval daughter on eval mother Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) DRAM: 1 GiB STM32MP> bdinfo boot_params = 0x DRAM bank = 0x -> start = 0xc000 -> size = 0x3000 << the patch is applied - 4kiB here !!! But this is wrong. DRAM bank size should not be changed. I think that in U-Boot is another issue which propagates mapped U-Boot RAM size/range to the places where should be real DDR size. Yes it is wrong and it is introduced by your patch... in the STM32MP15x platfrorm are using the genric weak function ./common/board_f.c:267 __weak int dram_init_banksize(void) { gd->bd->bi_dram[0].start = gd->ram_base; gd->bd->bi_dram[0].size = get_effective_memsize(); return 0; } For me: get_effective_memsize() must return the effective size of the DDR and NOT -4KiB to avoid side effects in other part of the code (LMB for example) I think today we need to revert your patch. regards Patrick
[PATCH v2] efi_selftest: add hii database protocol test cases
Add a couple of tests for the cases when the HII database protocol get_package_list_handle() function is called with invalid parameters. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt Cc: Ilias Apalodimas --- Hi, Thanks Heinrich for your review and feedbacks; here is v2 of this patch. Best regards, Vincent. Changes in v2: - Change initialization of driver_handle to a non-NULL value, which will never get allocated. - Add a second test for the case when driver handle is invalid. v1 reference(s): - https://lists.denx.de/pipermail/u-boot/2022-December/502213.html - https://lists.denx.de/pipermail/u-boot/2023-January/503718.html lib/efi_selftest/efi_selftest_hii.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/lib/efi_selftest/efi_selftest_hii.c b/lib/efi_selftest/efi_selftest_hii.c index eaf3b0995d4..608e3982399 100644 --- a/lib/efi_selftest/efi_selftest_hii.c +++ b/lib/efi_selftest/efi_selftest_hii.c @@ -605,6 +605,25 @@ static int test_hii_database_get_package_list_handle(void) goto out; } + /* Invalid package list handle. */ + driver_handle = (efi_handle_t)~1UL; + ret = hii_database_protocol->get_package_list_handle( + hii_database_protocol, NULL, &driver_handle); + if (ret != EFI_INVALID_PARAMETER) { + efi_st_error("get_package_list_handle returned %u not invalid\n", +(unsigned int)ret); + goto out; + } + + /* Invalid driver handle. */ + ret = hii_database_protocol->get_package_list_handle( + hii_database_protocol, handle, NULL); + if (ret != EFI_INVALID_PARAMETER) { + efi_st_error("get_package_list_handle returned %u not invalid\n", +(unsigned int)ret); + goto out; + } + result = EFI_ST_SUCCESS; out: -- 2.39.0
Re: Pull request: u-boot-rockchip/for-next
Hi Tom, I have remove the rk3399.dtsi sync patch and update the for-next branch. Do you need me to resend a new PR, or could you merge the latest patches? The new CI result: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14618 Thanks, - Kever On 2023/1/5 17:01, Kever Yang wrote: Hi Tom, Please pull the updates for rockchip platform for next: - Add support for rv1126 soc and rv1126 neu2 io board; - Add support for rk3399 pine64 pinephone pro board; - dts sync from linux for rk3399; Travis: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14601 Thanks, - Kever The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: Merge branch '2023-01-02-platform-updates' into next (2023-01-02 18:07:41 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-rockchip.git for-next for you to fetch changes up to 7c2c42aa4b623dae0dd59064ff2b147eb01dbb75: rockchip: Add initial support for the PINE64 Pinephone Pro (2023-01-04 17:00:48 +0800) Christopher Obbard (1): configs: roc-pc-rk3399: Enable rockchip efuse support Jagan Teki (25): ram: Mark ram-uclass depend on TPL_DM or SPL_DM ram: rockchip: Add common ddr type configs ram: rockchip: Compute ddr capacity based on grf split ram: rockchip: Update ddr pctl regs for px30 ram: rockchip: Add rv1126 ddr3 support ram: rockchip: Add rv1126 ddr loader params ram: rockchip: Add rv1126 ddr driver support ram: rockchip: rv1126: Control ddr init prints via DEBUG ram: rockchip: Add rv1126 lpddr4 support pinctrl: rockchip: Add pinctrl route types pinctrl: rockchip: Add rv1126 support arch: rockchip: Add cru header for rv1126 dt-bindings: clk: Add dt-binding header for RV1126 clk: rockchip: Add rv1126 clk support dt-bindings: power: Add power-domain header for rv1126 arm: rockchip: Add grf header for rv1126 ARM: dts: rockchip: Add Rockchip RV1126 pinctrl ARM: dts: rockchip: Add Rockchip RV1126 SoC arm: rockchip: Add RV1126 arch core support arm: rockchip: rv1126: Set dram area unsecure for SPL rockchip: mkimage: Add rv1126 support ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module 2(Neu2) ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module 2(Neu2) IO ARM: dts: rockchip: Add rv1126-u-boot.dtsi board: rockchip: Add Edgeble Neu2 IO Board John Keeping (2): rc4: mark key as const rockchip: mkimage: make RC4 key const Peter Robinson (3): arm64: dts: rk3399: sync rk3399.dtsi from 6.1-rc1 arm64: dts: rk3399: Add upstream Pinephone Pro dts rockchip: Add initial support for the PINE64 Pinephone Pro Quentin Schulz (3): rockchip: px30: make watchdog and tsadc trigger a first global reset rockchip: clk: add watchdog clock to px30_clk_enable rockchip: puma-rk3399: sync DTS with Linux kernel next-20221114 arch/arm/dts/Makefile |4 + arch/arm/dts/rk3399-opp.dtsi |6 +- arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 31 + arch/arm/dts/rk3399-pinephone-pro.dts | 474 +++ arch/arm/dts/rk3399-puma-haikou.dts|5 +- arch/arm/dts/rk3399-puma.dtsi | 32 +- arch/arm/dts/rk3399-u-boot.dtsi| 36 +- arch/arm/dts/rk3399.dtsi | 200 +- arch/arm/dts/rv1126-edgeble-neu2-io-u-boot.dtsi| 10 + arch/arm/dts/rv1126-edgeble-neu2-io.dts| 42 + arch/arm/dts/rv1126-edgeble-neu2.dtsi | 338 ++ arch/arm/dts/rv1126-pinctrl.dtsi | 211 ++ arch/arm/dts/rv1126-u-boot.dtsi| 62 + arch/arm/dts/rv1126.dtsi | 438 +++ arch/arm/include/asm/arch-rockchip/cru_rv1126.h| 459 +++ .../include/asm/arch-rockchip/dram_spec_timing.h | 452 +++ arch/arm/include/asm/arch-rockchip/grf_rv1126.h| 251 ++ arch/arm/include/asm/arch-rockchip/sdram_common.h | 214 +- arch/arm/include/asm/arch-rockchip/sdram_msch.h| 12 + .../include/asm/arch-rockchip/sdram_pctl_px30.h| 100 +- .../include/asm/arch-rockchip/sdram_phy_rv1126.h | 93 + arch/arm/include/asm/arch-rockchip/sdram_rv1126.h | 420 +++ arch/arm/include/asm/arch-rv1126/boot0.h | 11 + arch/arm/include/asm/arch-rv1126/gpio.h| 11 + arch/arm/mach-rockchip/Kconfig | 46 + arch/arm/mach-rockchip/Makefile|1 + arch/arm/mach-rockchip/px30/px30.c |4 + arch/arm/mach-rockchip/rk3399/Kconfig |8 + arch/arm/mach-rockchip/rv1126/Kconfig | 59 + arch/arm/mach-rockchip/rv1126/Makefile
[PATCH 0/2] efi: small hii set_keyboard_layout conformance improvement
Hi, The following couple of patches make UEFI HII set_keyboard_layout() more conforming in the case of invalid input parameter and add a selftest. This is sent in this order to avoid breaking `bootefi selftest' in the middle but feel free to apply in any order if preferred. Best regards, Vincent. Vincent Stehlé (2): efi_loader: refine set_keyboard_layout() status efi_selftest: add hii set keyboard layout test case lib/efi_loader/efi_hii.c| 3 +++ lib/efi_selftest/efi_selftest_hii.c | 12 2 files changed, 15 insertions(+) -- 2.39.0
[PATCH 1/2] efi_loader: refine set_keyboard_layout() status
As per the EFI specification, the HII database protocol function set_keyboard_layout() must return EFI_INVALID_PARAMETER when it is called with a NULL key_guid argument. Modify the function accordingly to improve conformance. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt Cc: Ilias Apalodimas --- lib/efi_loader/efi_hii.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c index 27db3be6a17..3b54ecb11ac 100644 --- a/lib/efi_loader/efi_hii.c +++ b/lib/efi_loader/efi_hii.c @@ -758,6 +758,9 @@ set_keyboard_layout(const struct efi_hii_database_protocol *this, { EFI_ENTRY("%p, %pUs", this, key_guid); + if (!key_guid) + return EFI_EXIT(EFI_INVALID_PARAMETER); + return EFI_EXIT(EFI_NOT_FOUND); } -- 2.39.0
[PATCH 2/2] efi_selftest: add hii set keyboard layout test case
Add a test for the case when the HII database protocol set_keyboard_layout() function is called with a NULL key_guid argument. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt Cc: Ilias Apalodimas --- lib/efi_selftest/efi_selftest_hii.c | 12 1 file changed, 12 insertions(+) diff --git a/lib/efi_selftest/efi_selftest_hii.c b/lib/efi_selftest/efi_selftest_hii.c index eaf3b0995d4..f4b55889e29 100644 --- a/lib/efi_selftest/efi_selftest_hii.c +++ b/lib/efi_selftest/efi_selftest_hii.c @@ -564,7 +564,19 @@ out: */ static int test_hii_database_set_keyboard_layout(void) { + efi_status_t ret; + PRINT_TESTNAME; + + /* Invalid key guid. */ + ret = hii_database_protocol->set_keyboard_layout( + hii_database_protocol, NULL); + if (ret != EFI_INVALID_PARAMETER) { + efi_st_error("set_keyboard_layout returned %u not invalid\n", +(unsigned int)ret); + return EFI_ST_FAILURE; + } + /* set_keyboard_layout() not implemented yet */ return EFI_ST_SUCCESS; } -- 2.39.0
Re: [PATCH] mtd: spi-nor: Keep CFR5V[6] as 1 in Octal DTR enable
Hi Takahiro, On 06/01/23 09:04, tkuw584...@gmail.com wrote: From: Takahiro Kuwano CFR5V[6] is reserved bit and must always be 1. Fixes: ea9a22f7e79c ("mtd: spi-nor-core: Add support for Cypress Semper flash") Signed-off-by: Takahiro Kuwano --- include/linux/mtd/spi-nor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 30f15452aa68..181eb6710d7e 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -194,7 +194,7 @@ #define SPINOR_REG_CYPRESS_CFR3V_PGSZ BIT(4) /* Page size. */ #define SPINOR_REG_CYPRESS_CFR3V_UNISECT BIT(3) /* Uniform sector mode */ #define SPINOR_REG_CYPRESS_CFR5V 0x0086 -#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN0x3 +#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN0x43 I second Tudor's review on the linux-mtd mailing list here as well, (<493d9a10-aaf3-70f6-36c3-9a2cf39f0...@linaro.org>) This looks bad. Instead of overwriting CFR5V with whatever value, we should instead first read it and then update only the bit that we're interested in. If it happens to write CFR5V before octal enable/disable, you'll overwrite the previous set values. #define SPINOR_OP_CYPRESS_RD_FAST 0xee /* Supported SPI protocols */ -- Thanks and Regards, Dhruva Gole
[PULL] Pull request for u-boot master / v2023.01 = u-boot-stm32-20230106
Hi Tom, Please pull the STM32 related fixes for u-boot/master, v2023.01: u-boot-stm32-20230106 - stm32mp: Fix board_get_usable_ram_top(): workaround to avoid issue after the commit 777706b ("common/memsize.c: Fix get_effective_memsize() to check for overflow") because the effective DDR effective size is reduce by 4KiB and sometime the board hang on boot CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/14623 This last patch for v2023.01 avoids a hang on 1GB DDR STM32MP15 board detected by Marek and caused by Pali patch. For my point a view , this patch is an acceptable workaround for master branch and v2023.01 delivery but the initial patch should be revisited or reverted (in master or in next ?). For details see comments in patch "arm: stm32mp: Fix board_get_usable_ram_top() again" http://patchwork.ozlabs.org/project/uboot/patch/2023010501.238075-1-ma...@denx.de/ https://lore.kernel.org/u-boot/2023010501.238075-1-ma...@denx.de/ Thanks, Patrick = The following changes since commit 8d6cbf5e6bc4e10e38b954763fa025caed517cc2: Merge tag 'efi-2023-01-rc5-3' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-01-04 08:50:24 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20230106 for you to fetch changes up to a2e0b041d662e4c80502cd5c9a8326d026f9deb1: arm: stm32mp: Fix board_get_usable_ram_top() again (2023-01-06 11:02:17 +0100) - stm32mp: Fix board_get_usable_ram_top(): workaround to avoid issue after the commit 777706b ("common/memsize.c: Fix get_effective_memsize() to check for overflow") because the effective DDR effective size is reduce by 4KiB and sometime the board hang on boot Marek Vasut (1): arm: stm32mp: Fix board_get_usable_ram_top() again arch/arm/mach-stm32mp/dram_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH 00/17] Support android boot image v3/v4
On 04/01/2023 21:01, Simon Glass wrote: Hi Safae, On Wed, 4 Jan 2023 at 02:02, safae ouajih wrote: On 30/12/2022 02:48, Tom Rini wrote: On Sat, 26 Nov 2022 17:59:14 +0100, Safae Ouajih wrote: * This is based on Roman Stratiienko's work to support boot image header version 3 and 4. * This supports the new boot image headers v3, v4 and bootconfig feature. https://source.android.com/docs/core/architecture/bootloader/boot-image-header https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig - Tested on Amlogic Khadas vim3l, a reference board for Android Open Source Project https://www.khadas.com/vim3l [...] This series causes the test/py/tests/test_android/test_abootimg.py tests to fail: FAILED test/py/tests/test_android/test_abootimg.py::test_abootimg - ValueError: U-Boot exite... and likely that test needs to be expanded for these new formats too. Hello Tom, Thank you for reporting the failure. This will be fixed in a v2. Please also update the test as requested. Regards, Simon Hello Simon, I am working on the test update. This will be in a v2. Thank you. Best Regards, -- Safae
[PATCH 0/4] Fix sparse warnings
Run and fix sparse warnings in below files -drivers/mmc/zynq_sdhci.c -board/xilinx/common/board.h -drivers/gpio/zynqmp_gpio_modepin.c -board/xilinx/versal/board.c Algapally Santosh Sagar (4): xilinx: common: Add missing prototype for board_get_usable_ram_top gpio: zynqmp: Remove unused variable ret xilinx: versal: Add missing prototype drivers: mmc: Change datatype to fix a warning board/xilinx/common/board.h| 4 board/xilinx/versal/board.c| 1 + drivers/gpio/zynqmp_gpio_modepin.c | 3 +-- drivers/mmc/zynq_sdhci.c | 2 +- 4 files changed, 7 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH 1/4] xilinx: common: Add missing prototype for board_get_usable_ram_top
From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'board_get_usable_ram_top' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/common/board.h | 4 1 file changed, 4 insertions(+) diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h index 69e642429b..ef7f3f3dce 100644 --- a/board/xilinx/common/board.h +++ b/board/xilinx/common/board.h @@ -11,4 +11,8 @@ int board_late_init_xilinx(void); int xilinx_read_eeprom(void); +#if defined(CONFIG_LMB) +phys_size_t board_get_usable_ram_top(phys_size_t total_size); +#endif + #endif /* BOARD_XILINX_COMMON_BOARD_H */ -- 2.17.1
[PATCH 2/4] gpio: zynqmp: Remove unused variable ret
From: Algapally Santosh Sagar There is a unused variable ret, due to which we are getting sparse warning as below. warning: variable 'ret' set but not used [-Wunused-but-set-variable]. Remove variable ret. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/gpio/zynqmp_gpio_modepin.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpio/zynqmp_gpio_modepin.c b/drivers/gpio/zynqmp_gpio_modepin.c index 078fd83395..52eda9ceb4 100644 --- a/drivers/gpio/zynqmp_gpio_modepin.c +++ b/drivers/gpio/zynqmp_gpio_modepin.c @@ -45,9 +45,8 @@ static int modepin_gpio_set_value(struct udevice *dev, unsigned int offset, { u32 ret_payload[PAYLOAD_ARG_CNT]; u32 out_val = 0; - int ret; - ret = get_gpio_modepin(ret_payload); + get_gpio_modepin(ret_payload); if (value) out_val = OUTVAL(offset) | ret_payload[1]; else -- 2.17.1
[PATCH 3/4] xilinx: versal: Add missing prototype
From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'do_go_exec' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/versal/board.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c index f9f5457ed2..d8562ce47a 100644 --- a/board/xilinx/versal/board.c +++ b/board/xilinx/versal/board.c @@ -22,6 +22,7 @@ #include #include #include "../common/board.h" +#include DECLARE_GLOBAL_DATA_PTR; -- 2.17.1
[PATCH 4/4] drivers: mmc: Change datatype to fix a warning
From: Algapally Santosh Sagar tuning_loop_counter is of char type. Change to int to fix below warning. warning: comparison is always false due to limited range of data type. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/mmc/zynq_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index 7dcf6ad842..be4075c97a 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -249,7 +249,7 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 opcode) u32 ctrl; struct sdhci_host *host; struct arasan_sdhci_priv *priv = dev_get_priv(mmc->dev); - char tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; + int tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; dev_dbg(mmc->dev, "%s\n", __func__); -- 2.17.1
Re: [PATCH 0/4] Enable gigadevice and add new part #s
> Regarding the location of the entry, I believe you want me to add the entry in > the alphabetical order? Not really. I want to you follow Kconfig layout which is what make savedefconfig && cp defconfig configs/ is for. Can you be more specific on this requirement? I believe this is pertaining to the defconfig files. Where is the correct line to insert the following entry? CONFIG_SPI_FLASH_GIGADEVICE=y Regards, Victor
[PATCH] usb: dwc3: Fix the return value of gpio_request_by_name()
As the "reset-gpios" property is optional, don't return the error and just skip the gpio reset sequence. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/dwc3-generic.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c index 78966718d0..e88e0b2e5a 100644 --- a/drivers/usb/dwc3/dwc3-generic.c +++ b/drivers/usb/dwc3/dwc3-generic.c @@ -93,21 +93,21 @@ static int dwc3_generic_probe(struct udevice *dev, device_is_compatible(dev->parent, "xlnx,zynqmp-dwc3")) { rc = gpio_request_by_name(dev->parent, "reset-gpios", 0, &priv->ulpi_reset, GPIOD_ACTIVE_LOW); - if (rc) - return rc; + /* property is optional, don't return error! */ + if (rc != -ENOENT) { + /* Toggle ulpi to reset the phy. */ + rc = dm_gpio_set_value(&priv->ulpi_reset, 1); + if (rc) + return rc; - /* Toggle ulpi to reset the phy. */ - rc = dm_gpio_set_value(&priv->ulpi_reset, 1); - if (rc) - return rc; + mdelay(5); - mdelay(5); + rc = dm_gpio_set_value(&priv->ulpi_reset, 0); + if (rc) + return rc; - rc = dm_gpio_set_value(&priv->ulpi_reset, 0); - if (rc) - return rc; - - mdelay(5); + mdelay(5); + } } if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3")) -- 2.17.1
RE: [PATCH] usb: dwc3: Fix the return value of gpio_request_by_name()
Hi Marek, Thanks. I will check and update. Thanks Venkatesh > -Original Message- > From: Marek Vasut > Sent: Friday, January 6, 2023 9:51 AM > To: Abbarapu, Venkatesh ; u- > b...@lists.denx.de > Cc: Simek, Michal ; g...@xilinx.com > Subject: Re: [PATCH] usb: dwc3: Fix the return value of > gpio_request_by_name() > > On 1/6/23 04:51, Venkatesh Yadav Abbarapu wrote: > > As the "reset-gpios" property is optional, don't return the error and > > just skip the gpio reset sequence. > > > > Signed-off-by: Venkatesh Yadav Abbarapu > > > --- > > > > drivers/usb/dwc3/dwc3-generic.c | 24 > > 1 file changed, 12 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/usb/dwc3/dwc3-generic.c > > b/drivers/usb/dwc3/dwc3-generic.c index 78966718d0..e88e0b2e5a > 100644 > > --- a/drivers/usb/dwc3/dwc3-generic.c > > +++ b/drivers/usb/dwc3/dwc3-generic.c > > @@ -93,21 +93,21 @@ static int dwc3_generic_probe(struct udevice *dev, > > device_is_compatible(dev->parent, "xlnx,zynqmp-dwc3")) { > > rc = gpio_request_by_name(dev->parent, "reset-gpios", 0, > > Have a look at devm_gpiod_get_optional() , this might simplify the code.
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
Hi, On 1/5/23 20:16, Pali Rohar wrote: Hello! On Thursday 05 January 2023 11:03:07 Patrick DELAUNAY wrote: Hi, On 1/5/23 02:22, Marek Vasut wrote: Do not access gd->ram_size and assume this is actual valid RAM size. Since commit 777706b ("common/memsize.c: Fix get_effective_memsize() to check for overflow") the RAM size may be less than gd->ram_size , call get_effective_memsize() to get the limited value instead. The aforementioned commit makes STM32MP15xx boards with 1 GiB of DRAM at 0xc000 hang on boot, which is a grave defect. Signed-off-by: Marek Vasut --- Cc: Pali Rohar Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Tom Rini --- arch/arm/mach-stm32mp/dram_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c index 9346fa8546d..80ba5c27741 100644 --- a/arch/arm/mach-stm32mp/dram_init.c +++ b/arch/arm/mach-stm32mp/dram_init.c @@ -51,7 +51,7 @@ phys_size_t board_get_usable_ram_top(phys_size_t total_size) /* found enough not-reserved memory to relocated U-Boot */ lmb_init(&lmb); - lmb_add(&lmb, gd->ram_base, gd->ram_size); + lmb_add(&lmb, gd->ram_base, get_effective_memsize()); boot_fdt_add_mem_rsv_regions(&lmb, (void *)gd->fdt_blob); /* add 8M for reserved memory for display, fdt, gd,... */ size = ALIGN(SZ_8M + CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE), Thanks for the patch Reviewed-by: Patrick Delaunay Even if I don't uderstood where the code blocked here... I need to cros-check it. But I think it is more a regression introduced by 777706b ("common/memsize.c: Fix get_effective_memsize() to check for overflow") in this patch I don't understood the assumption: * It is required that ram_base + ram_size must be representable by * phys_size_t type and must be aligned by direct access why add now this limitation ? why phys_size_t here and not phys_addr_t or unsigned long, the ram_base type ? Well, I think that it is quite confusing when it is phys_addr_t and when phys_size_t. Because U-Boot on more places is doing addition: phys_addr_t + phys_size_t. And I was confused by it too, because get_effective_memsize() function works only with variables of phys_size_t type. So I would agree that it should be mentioned as phys_addr_t. But is there any platform on which phys_addr_t and phys_size_t types have different sizes? I don't know, it is just more clear => addr overflow based on address type Why it is not ram_base? Because there is no such type. Why it is not phys_addr_t? Because some 32-bit platforms support more than 4GB of physical memory and unsigned long type is small for them. Also there are 64-bit platforms with just 32-bit data bus (but I'm not sure if these platforms are handled somehow specially with just 32-bit phys_addr_t). why align on 4kB and not on MMU_SECTION_SIZE ? Because of my mistake and seems that nobody spotted or reported this issue yet. I agree it should be some platform specific macro (I have not checked now if MMU_SECTION_SIZE is the correct one). I propose MMU_SECTION_SIZE to allow MMU configuration up to end of effective ram top. until now on ARM 32bits U-Boot is working with ram_base = 0xC000 (unsigned long) ram_size = 0x4000 (phys_size_t) overflow for ram_top (phys_addr_t) = ram_base + get_effective_memsize() was previously managed in the code as we work only on base address + size (in board_f.c, in lmb library) I correct in the code overflow issues, for example in commit 54be09cd8f6e ("arm: caches: manage phys addr_t overflow in mmu_set_region_dcache_behaviour"). moreover for me it is strange to reduce the size of the DDR banks by default (see resutl of bdinfo command) only just to avoid overflow: common/board_f.c:267: gd->bd->bi_dram[0].size = get_effective_memsize(); Yes, this really looks strange to reduce total size of DDR banks to the effective memory size which U-Boot can use or map. There is also config option CONFIG_MAX_MEM_MAPPED to allow user to reduce mappable memory in U-Boot to more strict value. For sure DDR bank size should be set to the real size. For example 32-bit U-Boot can map maximally 4GB of RAM, but on some (32-bit) platforms there can be more than 4GB of DDR and operating system may support to use more than 4GB of it. So DDR bank size passed from bootloader to OS should be precise and not reduced to size supported by bootloader. For me the real assumption is on the end of RAM: "ram_base + ram_size - 1" must be representable by 'ram_base' type (phys_addr_t or unsigned long ?) You are missing there +1. That is restriction in the U-Boot as it requires that one byte after the RAM can be stored in both phys_addr_t and phys_size_t variables. Again, I wrote code comment slightly wrong. It should say that ram_base + get_effective_memsize() must be representable by phys_addr_t type. For me it is not a prob
[PATCH 0/6] stm32mp: Add support of OP-TEE and STM32MP13x in bsec driver
Add support of STM32MP13x in bsec driver with OP-TEE pseudo TA and activate the associated commands fuse, stboard and stm32key. This PTA is merged in OP-TEE master branch, and can be used for STM32MP15X and STM32MP13X SoC to access to BSEC secured ressource. This serie is a preliminary step for STM32MP13x USB support, with serial number and for ETH with mac address. Patrick Patrick Delaunay (6): stm32mp: cosmetic: Update of bsec driver stm32mp: Add OP-TEE support in bsec driver stm32mp: Add support of STM32MP13x in bsec driver configs: stm32mp13: Activate CONFIG_CMD_FUSE board: st: Add support of STM32MP13x boards in stm32board cmd configs: stm32mp13: Activate command stm32key arch/arm/mach-stm32mp/bsec.c | 176 +- arch/arm/mach-stm32mp/cmd_stm32key.c | 4 +- arch/arm/mach-stm32mp/include/mach/bsec.h | 7 + board/st/common/Kconfig | 2 +- board/st/common/cmd_stboard.c | 12 +- configs/stm32mp13_defconfig | 2 + doc/board/st/stm32mp1.rst | 6 +- 7 files changed, 191 insertions(+), 18 deletions(-) -- 2.25.1
[PATCH 1/6] stm32mp: cosmetic: Update of bsec driver
Remove unnecessary return in stm32mp_bsec_write_lock and replace tab by space for plat_auto opts. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/bsec.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c index c00130b08b36..51ccff9aa560 100644 --- a/arch/arm/mach-stm32mp/bsec.c +++ b/arch/arm/mach-stm32mp/bsec.c @@ -468,8 +468,6 @@ static int stm32mp_bsec_write_lock(struct udevice *dev, u32 val, u32 otp) plat = dev_get_plat(dev); return bsec_permanent_lock_otp(dev, plat->base, otp); - - return -EINVAL; } static int stm32mp_bsec_read(struct udevice *dev, int offset, @@ -608,7 +606,7 @@ U_BOOT_DRIVER(stm32mp_bsec) = { .id = UCLASS_MISC, .of_match = stm32mp_bsec_ids, .of_to_plat = stm32mp_bsec_of_to_plat, - .plat_auto = sizeof(struct stm32mp_bsec_plat), + .plat_auto = sizeof(struct stm32mp_bsec_plat), .ops = &stm32mp_bsec_ops, .probe = stm32mp_bsec_probe, }; -- 2.25.1
[PATCH 3/6] stm32mp: Add support of STM32MP13x in bsec driver
Add support for "st,stm32mp13-bsec" for STM32MP13x in the bsec driver based on OP-TEE pseudo TA STM32MP BSEC. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/bsec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c index fe79c986f95c..f5f4b20d4776 100644 --- a/arch/arm/mach-stm32mp/bsec.c +++ b/arch/arm/mach-stm32mp/bsec.c @@ -761,6 +761,7 @@ static int stm32mp_bsec_probe(struct udevice *dev) } static const struct udevice_id stm32mp_bsec_ids[] = { + { .compatible = "st,stm32mp13-bsec" }, { .compatible = "st,stm32mp15-bsec" }, {} }; -- 2.25.1
[PATCH 2/6] stm32mp: Add OP-TEE support in bsec driver
When OP-TEE is used, the SMC for BSEC management are not available and the STM32MP BSEC pseudo TA must be used (it is mandatory for STM32MP13 and it is a new feature for STM32MP15x). The BSEC driver try to open a session to this PTA BSEC at probe and use it for OTP read or write access to fuse or to shadow. This patch also adapts the commands stm32key and stboard to handle the BSEC_LOCK_PERM lock value instead of 1. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/bsec.c | 173 +- arch/arm/mach-stm32mp/cmd_stm32key.c | 4 +- arch/arm/mach-stm32mp/include/mach/bsec.h | 7 + board/st/common/cmd_stboard.c | 5 +- doc/board/st/stm32mp1.rst | 6 +- 5 files changed, 183 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c index 51ccff9aa560..fe79c986f95c 100644 --- a/arch/arm/mach-stm32mp/bsec.c +++ b/arch/arm/mach-stm32mp/bsec.c @@ -10,9 +10,11 @@ #include #include #include +#include #include #include #include +#include #include #include #include @@ -63,10 +65,43 @@ */ #define BSEC_LOCK_PROGRAM 0x04 +#define PTA_BSEC_UUID { 0x94cf71ad, 0x80e6, 0x40b5, \ + { 0xa7, 0xc6, 0x3d, 0xc5, 0x01, 0xeb, 0x28, 0x03 } } + +/* + * Read OTP memory + * + * [in]value[0].a OTP start offset in byte + * [in]value[0].b Access type (0:shadow, 1:fuse, 2:lock) + * [out] memref[1].bufferOutput buffer to store read values + * [out] memref[1].size Size of OTP to be read + * + * Return codes: + * TEE_SUCCESS - Invoke command success + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param + * TEE_ERROR_ACCESS_DENIED - OTP not accessible by caller + */ +#define PTA_BSEC_READ_MEM 0x0 + /* - * OTP status: bit 0 permanent lock + * Write OTP memory + * + * [in]value[0].a OTP start offset in byte + * [in]value[0].b Access type (0:shadow, 1:fuse, 2:lock) + * [in]memref[1].bufferInput buffer to read values + * [in]memref[1].size Size of OTP to be written + * + * Return codes: + * TEE_SUCCESS - Invoke command success + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param + * TEE_ERROR_ACCESS_DENIED - OTP not accessible by caller */ -#define BSEC_LOCK_PERM BIT(0) +#define PTA_BSEC_WRITE_MEM 0x1 + +/* value of PTA_BSEC access type = value[in] b */ +#define SHADOW_ACCESS 0 +#define FUSE_ACCESS1 +#define LOCK_ACCESS2 /** * bsec_lock() - manage lock for each type SR/SP/SW @@ -359,6 +394,10 @@ struct stm32mp_bsec_plat { u32 base; }; +struct stm32mp_bsec_priv { + struct udevice *tee; +}; + static int stm32mp_bsec_read_otp(struct udevice *dev, u32 *val, u32 otp) { struct stm32mp_bsec_plat *plat; @@ -470,14 +509,109 @@ static int stm32mp_bsec_write_lock(struct udevice *dev, u32 val, u32 otp) return bsec_permanent_lock_otp(dev, plat->base, otp); } +static int bsec_pta_open_session(struct udevice *tee, u32 *tee_session) +{ + const struct tee_optee_ta_uuid uuid = PTA_BSEC_UUID; + struct tee_open_session_arg arg; + int rc; + + memset(&arg, 0, sizeof(arg)); + tee_optee_ta_uuid_to_octets(arg.uuid, &uuid); + arg.clnt_login = TEE_LOGIN_REE_KERNEL; + rc = tee_open_session(tee, &arg, 0, NULL); + if (rc < 0) + return -ENODEV; + + *tee_session = arg.session; + + return 0; +} + +static int bsec_optee_open(struct udevice *dev) +{ + struct stm32mp_bsec_priv *priv = dev_get_priv(dev); + struct udevice *tee; + u32 tee_session; + int rc; + + tee = tee_find_device(NULL, NULL, NULL, NULL); + if (!tee) + return -ENODEV; + + /* try to open the STM32 BSEC TA */ + rc = bsec_pta_open_session(tee, &tee_session); + if (rc) + return rc; + + tee_close_session(tee, tee_session); + + priv->tee = tee; + + return 0; +} + +static int bsec_optee_pta(struct udevice *dev, int cmd, int type, int offset, + void *buff, ulong size) +{ + struct stm32mp_bsec_priv *priv = dev_get_priv(dev); + u32 tee_session; + struct tee_invoke_arg arg; + struct tee_param param[2]; + struct tee_shm *fw_shm; + int rc; + + rc = bsec_pta_open_session(priv->tee, &tee_session); + if (rc) + return rc; + + rc = tee_shm_register(priv->tee, buff, size, 0, &fw_shm); + if (rc) + goto close_session; + + memset(&arg, 0, sizeof(arg)); + arg.func = cmd; + arg.session = tee_session; + + memset(param, 0, sizeof(param)); + + param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT; + param[0].u.value.a = offset; +
[PATCH 4/6] configs: stm32mp13: Activate CONFIG_CMD_FUSE
Activate the command fuse to access on STM32MP13x OTP with the BSEC driver. Signed-off-by: Patrick Delaunay --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index af6b1839d039..f3d5e9812c6c 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -26,6 +26,7 @@ CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_UNZIP=y CONFIG_CMD_CLK=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_LSBLK=y -- 2.25.1
[PATCH 5/6] board: st: Add support of STM32MP13x boards in stm32board cmd
Add board identifiers for STMicroelectronics STM32MP13x boards: - DISCO board: MB1635 Signed-off-by: Patrick Delaunay --- board/st/common/Kconfig | 2 +- board/st/common/cmd_stboard.c | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig index 2f57118bb265..aba3590866e0 100644 --- a/board/st/common/Kconfig +++ b/board/st/common/Kconfig @@ -1,7 +1,7 @@ config CMD_STBOARD bool "stboard - command for OTP board information" depends on ARCH_STM32MP - default y if TARGET_ST_STM32MP15x + default y if TARGET_ST_STM32MP15x || TARGET_ST_STM32MP13x help This compile the stboard command to read and write the board in the OTP. diff --git a/board/st/common/cmd_stboard.c b/board/st/common/cmd_stboard.c index 213fb5d30208..853ab78bbf16 100644 --- a/board/st/common/cmd_stboard.c +++ b/board/st/common/cmd_stboard.c @@ -2,8 +2,8 @@ /* * Copyright (C) 2019, STMicroelectronics - All Rights Reserved * - * the st command stboard supports the STMicroelectronics board identification - * saved in OTP 59. + * the command stboard supports the STMicroelectronics board identification + * saved in OTP_BOARD. * * The ST product codification have several element * - "Commercial Product Name" (CPN): type of product board (DKX, EVX) @@ -18,7 +18,7 @@ * - Finished Good = EVA32MP157A1$AU1 * * Both information are written on board and these information are also saved - * in OTP59, with: + * in OTP_BOARD (59 for STM32MP15x or 60 for STM32MP13x), with: * bit [31:16] (hex) => Board id, MB * bit [15:12] (dec) => Variant CPN (115) * bit [11:8] (dec) => Revision board (index with A = 1, Z = 26) @@ -49,6 +49,7 @@ static bool check_stboard(u16 board) 0x1298, 0x1341, 0x1497, + 0x1635, }; for (i = 0; i < ARRAY_SIZE(st_board_id); i++) -- 2.25.1
[PATCH 6/6] configs: stm32mp13: Activate command stm32key
Activate the command stm32key with CONFIG_CMD_STM32KEY. Signed-off-by: Patrick Delaunay --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index f3d5e9812c6c..70b0d5dc99bf 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp135f-dk" CONFIG_SYS_PROMPT="STM32MP> " CONFIG_STM32MP13x=y CONFIG_DDR_CACHEABLE_SIZE=0x1000 +CONFIG_CMD_STM32KEY=y CONFIG_TARGET_ST_STM32MP13x=y CONFIG_ENV_OFFSET_REDUND=0x94 # CONFIG_ARMV7_NONSEC is not set -- 2.25.1
Re: Pull request: u-boot-rockchip/for-next
Please send a new PR. On Fri, Jan 6, 2023, 4:40 AM Kever Yang wrote: > Hi Tom, > > I have remove the rk3399.dtsi sync patch and update the for-next > branch. > > Do you need me to resend a new PR, or could you merge the latest > patches? > > The new CI result: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14618 > > > Thanks, > > - Kever > > On 2023/1/5 17:01, Kever Yang wrote: > > Hi Tom, > > > > Please pull the updates for rockchip platform for next: > > - Add support for rv1126 soc and rv1126 neu2 io board; > > - Add support for rk3399 pine64 pinephone pro board; > > - dts sync from linux for rk3399; > > > > Travis: > > > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14601 > > > > Thanks, > > - Kever > > > > The following changes since commit > a95410696d21d38b629c61a09c100197c5fc533a: > > > >Merge branch '2023-01-02-platform-updates' into next (2023-01-02 > 18:07:41 -0500) > > > > are available in the Git repository at: > > > >https://source.denx.de/u-boot/custodians/u-boot-rockchip.git for-next > > > > for you to fetch changes up to 7c2c42aa4b623dae0dd59064ff2b147eb01dbb75: > > > >rockchip: Add initial support for the PINE64 Pinephone Pro > (2023-01-04 17:00:48 +0800) > > > > > > Christopher Obbard (1): > >configs: roc-pc-rk3399: Enable rockchip efuse support > > > > Jagan Teki (25): > >ram: Mark ram-uclass depend on TPL_DM or SPL_DM > >ram: rockchip: Add common ddr type configs > >ram: rockchip: Compute ddr capacity based on grf split > >ram: rockchip: Update ddr pctl regs for px30 > >ram: rockchip: Add rv1126 ddr3 support > >ram: rockchip: Add rv1126 ddr loader params > >ram: rockchip: Add rv1126 ddr driver support > >ram: rockchip: rv1126: Control ddr init prints via DEBUG > >ram: rockchip: Add rv1126 lpddr4 support > >pinctrl: rockchip: Add pinctrl route types > >pinctrl: rockchip: Add rv1126 support > >arch: rockchip: Add cru header for rv1126 > >dt-bindings: clk: Add dt-binding header for RV1126 > >clk: rockchip: Add rv1126 clk support > >dt-bindings: power: Add power-domain header for rv1126 > >arm: rockchip: Add grf header for rv1126 > >ARM: dts: rockchip: Add Rockchip RV1126 pinctrl > >ARM: dts: rockchip: Add Rockchip RV1126 SoC > >arm: rockchip: Add RV1126 arch core support > >arm: rockchip: rv1126: Set dram area unsecure for SPL > >rockchip: mkimage: Add rv1126 support > >ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module > 2(Neu2) > >ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module > 2(Neu2) IO > >ARM: dts: rockchip: Add rv1126-u-boot.dtsi > >board: rockchip: Add Edgeble Neu2 IO Board > > > > John Keeping (2): > >rc4: mark key as const > >rockchip: mkimage: make RC4 key const > > > > Peter Robinson (3): > >arm64: dts: rk3399: sync rk3399.dtsi from 6.1-rc1 > >arm64: dts: rk3399: Add upstream Pinephone Pro dts > >rockchip: Add initial support for the PINE64 Pinephone Pro > > > > Quentin Schulz (3): > >rockchip: px30: make watchdog and tsadc trigger a first global > reset > >rockchip: clk: add watchdog clock to px30_clk_enable > >rockchip: puma-rk3399: sync DTS with Linux kernel next-20221114 > > > > arch/arm/dts/Makefile |4 + > > arch/arm/dts/rk3399-opp.dtsi |6 +- > > arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 31 + > > arch/arm/dts/rk3399-pinephone-pro.dts | 474 +++ > > arch/arm/dts/rk3399-puma-haikou.dts|5 +- > > arch/arm/dts/rk3399-puma.dtsi | 32 +- > > arch/arm/dts/rk3399-u-boot.dtsi| 36 +- > > arch/arm/dts/rk3399.dtsi | 200 +- > > arch/arm/dts/rv1126-edgeble-neu2-io-u-boot.dtsi| 10 + > > arch/arm/dts/rv1126-edgeble-neu2-io.dts| 42 + > > arch/arm/dts/rv1126-edgeble-neu2.dtsi | 338 ++ > > arch/arm/dts/rv1126-pinctrl.dtsi | 211 ++ > > arch/arm/dts/rv1126-u-boot.dtsi| 62 + > > arch/arm/dts/rv1126.dtsi | 438 +++ > > arch/arm/include/asm/arch-rockchip/cru_rv1126.h| 459 +++ > > .../include/asm/arch-rockchip/dram_spec_timing.h | 452 +++ > > arch/arm/include/asm/arch-rockchip/grf_rv1126.h| 251 ++ > > arch/arm/include/asm/arch-rockchip/sdram_common.h | 214 +- > > arch/arm/include/asm/arch-rockchip/sdram_msch.h| 12 + > > .../include/asm/arch-rockchip/sdram_pctl_px30.h| 100 +- > > .../include/asm/arch-rockchip/sdram_phy_rv1126.h | 93 + > > arch/arm/include/asm/arch-rockchip/sdram_rv1126.h | 420 +++ > > arch/arm/include/asm
Re: [PATCH 3/4] xilinx: versal: Add missing prototype
Add missing header in subject? On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'do_go_exec' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/versal/board.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c index f9f5457ed2..d8562ce47a 100644 --- a/board/xilinx/versal/board.c +++ b/board/xilinx/versal/board.c @@ -22,6 +22,7 @@ #include #include #include "../common/board.h" +#include alphabetic order please. M DECLARE_GLOBAL_DATA_PTR;
Re: [PATCH 4/4] drivers: mmc: Change datatype to fix a warning
mmc: zynq_sdhci: Fix wrong tuning_loop_counter datatype On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar tuning_loop_counter is of char type. Change to int to fix below warning. warning: comparison is always false due to limited range of data type. Conceptually description should be done a way that you say I fixed this issue because datatype wasn't correct. And this was reported by spare. And you are doing it because it is not correct not because there is a warning. Warning just points to it. M Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/mmc/zynq_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index 7dcf6ad842..be4075c97a 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -249,7 +249,7 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 opcode) u32 ctrl; struct sdhci_host *host; struct arasan_sdhci_priv *priv = dev_get_priv(mmc->dev); - char tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; + int tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; dev_dbg(mmc->dev, "%s\n", __func__);
Re: [PATCH 2/4] gpio: zynqmp: Remove unused variable ret
On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar There is a unused variable ret, due to which we are getting sparse warning as below. warning: variable 'ret' set but not used [-Wunused-but-set-variable]. Remove variable ret. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/gpio/zynqmp_gpio_modepin.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpio/zynqmp_gpio_modepin.c b/drivers/gpio/zynqmp_gpio_modepin.c index 078fd83395..52eda9ceb4 100644 --- a/drivers/gpio/zynqmp_gpio_modepin.c +++ b/drivers/gpio/zynqmp_gpio_modepin.c @@ -45,9 +45,8 @@ static int modepin_gpio_set_value(struct udevice *dev, unsigned int offset, { u32 ret_payload[PAYLOAD_ARG_CNT]; u32 out_val = 0; - int ret; - ret = get_gpio_modepin(ret_payload); + get_gpio_modepin(ret_payload); :-) what about return error if get_gpio_modepin fails? M if (value) out_val = OUTVAL(offset) | ret_payload[1]; else
Re: [PATCH 1/4] xilinx: common: Add missing prototype for board_get_usable_ram_top
On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'board_get_usable_ram_top' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/common/board.h | 4 1 file changed, 4 insertions(+) diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h index 69e642429b..ef7f3f3dce 100644 --- a/board/xilinx/common/board.h +++ b/board/xilinx/common/board.h @@ -11,4 +11,8 @@ int board_late_init_xilinx(void); int xilinx_read_eeprom(void); +#if defined(CONFIG_LMB) +phys_size_t board_get_usable_ram_top(phys_size_t total_size); it is already in include/init.h. M
Re: [PATCH 0/4] Fix sparse warnings
On 1/6/23 13:00, Ashok Reddy Soma wrote: Run and fix sparse warnings in below files -drivers/mmc/zynq_sdhci.c -board/xilinx/common/board.h -drivers/gpio/zynqmp_gpio_modepin.c -board/xilinx/versal/board.c Algapally Santosh Sagar (4): xilinx: common: Add missing prototype for board_get_usable_ram_top gpio: zynqmp: Remove unused variable ret xilinx: versal: Add missing prototype drivers: mmc: Change datatype to fix a warning board/xilinx/common/board.h| 4 board/xilinx/versal/board.c| 1 + drivers/gpio/zynqmp_gpio_modepin.c | 3 +-- drivers/mmc/zynq_sdhci.c | 2 +- 4 files changed, 7 insertions(+), 3 deletions(-) Please do it against upstream. M
Re: Please pull u-boot-dm/next
On Thu, Jan 05, 2023 at 09:40:20PM -0600, Simon Glass wrote: > Hi Tom, > > This is for the -next branch > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/14617 > > > The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: > > Merge branch '2023-01-02-platform-updates' into next (2023-01-02 18:07:41 > -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-next-5jan23 > > for you to fetch changes up to 8c042fb7f9f475367804b26a892fd522ad8fcfcc: > > patman: add '--get-maintainer-script' argument (2023-01-05 19:21:57 -0700) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fastboot: remove #ifdef CONFIG when it is possible
On Thu, Jan 05, 2023 at 12:37:58PM +0100, Patrick DELAUNAY wrote: > Hi Tom, > > On 1/3/23 21:35, Tom Rini wrote: > > On Thu, Dec 15, 2022 at 10:15:50AM +0100, Patrick Delaunay wrote: > > > Much of the fastboot code predates the introduction of Kconfig and > > > has quite a few #ifdefs in it which is unnecessary now that we can use > > > IS_ENABLED() et al. > > > > > > Signed-off-by: Patrick Delaunay > > > --- > > > > > > cmd/fastboot.c | 35 +-- > > > drivers/fastboot/fb_command.c | 104 > > > drivers/fastboot/fb_common.c| 11 ++-- > > > drivers/fastboot/fb_getvar.c| 49 ++- > > > drivers/usb/gadget/f_fastboot.c | 7 +-- > > > include/fastboot.h | 13 > > > net/fastboot.c | 8 +-- > > > 7 files changed, 82 insertions(+), 145 deletions(-) > > > > > > diff --git a/cmd/fastboot.c b/cmd/fastboot.c > > > index b498e4b22bb3..b94dbd548843 100644 > > > --- a/cmd/fastboot.c > > > +++ b/cmd/fastboot.c > > > @@ -19,8 +19,14 @@ > > > static int do_fastboot_udp(int argc, char *const argv[], > > > uintptr_t buf_addr, size_t buf_size) > > > { > > > -#if CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT) > > > - int err = net_loop(FASTBOOT); > > > + int err; > > > + > > > + if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) { > > > + pr_err("Fastboot UDP not enabled\n"); > > > + return CMD_RET_FAILURE; > > > + } > > > + > > > + err = net_loop(FASTBOOT); > > > if (err < 0) { > > > printf("fastboot udp error: %d\n", err); > > > @@ -28,21 +34,21 @@ static int do_fastboot_udp(int argc, char *const > > > argv[], > > > } > > > return CMD_RET_SUCCESS; > > > -#else > > > - pr_err("Fastboot UDP not enabled\n"); > > > - return CMD_RET_FAILURE; > > > -#endif > > > } > > This probably needs to become an if (CONFIG_IS_ENABLED(...)) { ... } > > else { ... } in order to remain size-neutral. > > > Are you sure ? > > > { > if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) { > > return CMD_RET_FAILURE; > } > > > > return CMD_RET_SUCCESS; > } > > > For me, it is exactly the same size after compiler/linker than : > > > { > if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) { > > return CMD_RET_FAILURE; > } else { > > return CMD_RET_SUCCESS; > > } > > } > > > if UDP_FUNCTION_FASTBOOTis activated or not > > or I forget something during the Christmas break. If you've size-tested and it's the same, OK. I'm just worried about strings not being discarded since that's sometimes an unexpected side effect / bug. -- Tom signature.asc Description: PGP signature
[PATCH v3 00/25] bootstd: Add a boot menu
So far standard boot lacks a boot menu, although it is possible to create a rudimentary one using the existing 'bootmenu' command. Even then, this text-based menu offer only basic functionality and does not take full advantage of the displays which are common on many devices. This series provides a 'bootflow menu' command which allows the user to select from the available bootflows. An attempt is made to show the name of the available operating systems, by reading more information into the bootflow. A logo can be read also, where supported, so that this can be presented to the user when an option is highlighted. Full use is made of TrueType fonts, if enabled. For cases where only a serial console is available, it falls back to a simple text-based menu. All of this is implementing using a new 'expo' construct, a collection of scenes (like menu screens) which can be navigated by the user to view information and select options. This is fairly general and should be able to cope with a wider array of use cases, with less hacking of the menu code, such as is currently needed for CMD_BOOTEFI_BOOTMGR. Of course it would be possible to enhance the existing menu rather than creating a new setup. Instead it seems better to make the existing menu use expo, if code space permits. It avoids the event-loop problem and should be more extensible, given its loosely coupled components and use of IDs instead of pointers. Further motivation is provided in the documentation. For now the CLI keypress-decoding code is split out to be used by the new menu. The key codes defined by menu.h are reused also. This is of course just a starting point. Some ideas for future work are included in the documentation. Changes in v3: - Rebase to master Changes in v2: - Drop the _add suffix on expo creation function - Fix 'touse' typo - Fix pylint warning in mkdir_cond() - Put strings in a separate structure referenced by ID - Rebase to master - Rename vidconsole_get_font() to vidconsole_get_font_size() - Update for new API Simon Glass (25): sandbox: Enable mmc command and legacy images cli: Move readline character-processing to a state machine bootmenu: Add a few comments menu: Rename KEY_... to BKEY_... menu: Update bootmenu_autoboot_loop() to return the code menu: Update bootmenu_loop() to return the code menu: Use a switch statement menu: Make use of CLI character processing image: Add a function to find a script in an image image: Move common image code to image_board and command video: Enable VIDEO_ANSI by default only with EFI video: truetype: Rename the metrics function video: Fix unchnaged typo video: Add font functions to the vidconsole API bootstd: Read the Operating System name for distro/scripts bootstd: Allow reading a logo for the OS menu: Factor out menu-keypress decoding expo: Add basic implementation expo: Add support for scenes expo: Add support for scene menus expo: Add basic tests bootstd: Support creating a boot menu bootstd: Add a test for the bootstd menu bootstd: Support setting a theme for the menu expo: Add documentation .../cmd_stm32prog/cmd_stm32prog.c | 2 +- arch/sandbox/dts/test.dts | 11 + boot/Kconfig | 12 + boot/Makefile | 3 + boot/bootflow.c | 1 + boot/bootflow_internal.h | 47 ++ boot/bootflow_menu.c | 284 + boot/bootmeth-uclass.c| 69 ++- boot/bootmeth_distro.c| 36 ++ boot/bootmeth_script.c| 40 +- boot/bootstd-uclass.c | 2 + boot/expo.c | 170 ++ boot/image-board.c| 133 + boot/scene.c | 414 ++ boot/scene_internal.h | 123 boot/scene_menu.c | 390 + cmd/bootflow.c| 44 +- cmd/bootmenu.c| 19 +- cmd/eficonfig.c | 38 +- cmd/font.c| 11 +- cmd/source.c | 140 + common/Makefile | 6 +- common/cli_getch.c| 208 +++ common/cli_readline.c | 150 + common/command.c | 19 + common/menu.c | 157 +++-- configs/sandbox_defconfig | 2 + configs/sandbox_flattree_defconfig| 2 + configs/snow_defconfig| 4 + configs/tools-only_defconfig | 2 + doc/develop/expo.rst | 188 ++ doc/develop/index.rst | 1 + drivers/usb/gadget/f_sdp.c
[PATCH v3 01/25] sandbox: Enable mmc command and legacy images
The mmc command is useful for testing mmc disk images in sandbox, so enable it. We also need to enable legacy images so that we can run tests which use them. Disable it for a few avb tests since MMC is not implemented there yet. Signed-off-by: Simon Glass --- (no changes since v1) configs/sandbox_defconfig | 2 ++ configs/sandbox_flattree_defconfig | 2 ++ test/py/tests/test_android/test_avb.py | 2 ++ 3 files changed, 6 insertions(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index be46cae7aad..0b26673bf4f 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -13,6 +13,7 @@ CONFIG_FIT=y CONFIG_FIT_RSASSA_PSS=y CONFIG_FIT_CIPHER=y CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y CONFIG_BOOTSTAGE_FDT=y @@ -72,6 +73,7 @@ CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y CONFIG_CMD_LOADM=y CONFIG_CMD_LSBLK=y +CONFIG_CMD_MMC=y CONFIG_CMD_MUX=y CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 88aaddfa4ae..41453e0e2fa 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -11,6 +11,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y CONFIG_BOOTSTAGE_FDT=y @@ -40,6 +41,7 @@ CONFIG_CMD_DEMO=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y CONFIG_CMD_OSD=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y diff --git a/test/py/tests/test_android/test_avb.py b/test/py/tests/test_android/test_avb.py index a3f883136b0..bc5c5b55821 100644 --- a/test/py/tests/test_android/test_avb.py +++ b/test/py/tests/test_android/test_avb.py @@ -39,6 +39,7 @@ def test_avb_verify(u_boot_console): @pytest.mark.buildconfigspec('cmd_avb') @pytest.mark.buildconfigspec('cmd_mmc') +@pytest.mark.notbuildconfigspec('sandbox') def test_avb_mmc_uuid(u_boot_console): """Check if 'avb get_uuid' works, compare results with 'part list mmc 1' output @@ -97,6 +98,7 @@ def test_avb_is_unlocked(u_boot_console): @pytest.mark.buildconfigspec('cmd_avb') @pytest.mark.buildconfigspec('cmd_mmc') +@pytest.mark.notbuildconfigspec('sandbox') def test_avb_mmc_read(u_boot_console): """Test mmc read operation """ -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 03/25] bootmenu: Add a few comments
The behaviour of these two functions is completely undocumented. Add some notes so the poor, suffering dev can figure out what is going on. Signed-off-by: Simon Glass --- (no changes since v1) include/menu.h | 42 ++ 1 file changed, 42 insertions(+) diff --git a/include/menu.h b/include/menu.h index 702aacb170c..0b4d9734149 100644 --- a/include/menu.h +++ b/include/menu.h @@ -42,6 +42,7 @@ struct bootmenu_data { struct bootmenu_entry *first; /* first menu entry */ }; +/** enum bootmenu_key - keys that can be returned by the bootmenu */ enum bootmenu_key { KEY_NONE = 0, KEY_UP, @@ -53,8 +54,49 @@ enum bootmenu_key { KEY_SPACE, }; +/** + * bootmenu_autoboot_loop() - handle autobooting if no key is pressed + * + * This shows a prompt to allow the user to press a key to interrupt auto boot + * of the first menu option. + * + * It then waits for the required time (menu->delay in seconds) for a key to be + * pressed. If nothing is pressed in that time, @key returns KEY_SELECT + * indicating that the current option should be chosen. + * + * @menu: Menu being processed + * @key: Returns the code for the key the user pressed: + * enter: KEY_SELECT + * Ctrl-C: KEY_QUIT + * anything else: KEY_NONE + * @esc: Set to 1 if the escape key is pressed, otherwise not updated + */ void bootmenu_autoboot_loop(struct bootmenu_data *menu, enum bootmenu_key *key, int *esc); + +/** + * bootmenu_loop() - handle waiting for a keypress when autoboot is disabled + * + * This is used when the menu delay is negative, indicating that the delay has + * elapsed, or there was no delay to begin with. + * + * It reads a character and processes it, returning a menu-key code if a + * character is recognised + * + * @menu: Menu being processed + * @key: Returns the code for the key the user pressed: + * enter: KEY_SELECT + * Ctrl-C: KEY_QUIT + * Up arrow: KEY_UP + * Down arrow: KEY_DOWN + * Escape (by itself): KEY_QUIT + * Plus: KEY_PLUS + * Minus: KEY_MINUS + * Space: KEY_SPACE + * @esc: On input, a non-zero value indicates that an escape sequence has + * resulted in that many characters so far. On exit this is updated to the + * new number of characters + */ void bootmenu_loop(struct bootmenu_data *menu, enum bootmenu_key *key, int *esc); -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 05/25] menu: Update bootmenu_autoboot_loop() to return the code
Use the return value to save having to pass around a pointer. This also resolves any ambiguity about what *key contains when the function is called. Signed-off-by: Simon Glass --- (no changes since v1) cmd/bootmenu.c | 2 +- common/menu.c | 16 +--- include/menu.h | 7 +++ 3 files changed, 13 insertions(+), 12 deletions(-) diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index c80004c54dc..0e22f504fe4 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -93,7 +93,7 @@ static char *bootmenu_choice_entry(void *data) while (1) { if (menu->delay >= 0) { /* Autoboot was not stopped */ - bootmenu_autoboot_loop(menu, &key, &esc); + key = bootmenu_autoboot_loop(menu, &esc); } else { /* Some key was pressed, so autoboot was stopped */ bootmenu_loop(menu, &key, &esc); diff --git a/common/menu.c b/common/menu.c index a245c5a9c6c..bafc8470d7d 100644 --- a/common/menu.c +++ b/common/menu.c @@ -425,9 +425,9 @@ int menu_destroy(struct menu *m) return 1; } -void bootmenu_autoboot_loop(struct bootmenu_data *menu, - enum bootmenu_key *key, int *esc) +enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc) { + enum bootmenu_key key = BKEY_NONE; int i, c; while (menu->delay > 0) { @@ -446,16 +446,16 @@ void bootmenu_autoboot_loop(struct bootmenu_data *menu, switch (c) { case '\e': *esc = 1; - *key = BKEY_NONE; + key = BKEY_NONE; break; case '\r': - *key = BKEY_SELECT; + key = BKEY_SELECT; break; case 0x3: /* ^C */ - *key = BKEY_QUIT; + key = BKEY_QUIT; break; default: - *key = BKEY_NONE; + key = BKEY_NONE; break; } @@ -471,7 +471,9 @@ void bootmenu_autoboot_loop(struct bootmenu_data *menu, printf(ANSI_CURSOR_POSITION ANSI_CLEAR_LINE, menu->count + 5, 1); if (menu->delay == 0) - *key = BKEY_SELECT; + key = BKEY_SELECT; + + return key; } void bootmenu_loop(struct bootmenu_data *menu, diff --git a/include/menu.h b/include/menu.h index 29b457921e9..9f30a3c1acd 100644 --- a/include/menu.h +++ b/include/menu.h @@ -65,14 +65,13 @@ enum bootmenu_key { * indicating that the current option should be chosen. * * @menu: Menu being processed - * @key: Returns the code for the key the user pressed: + * @esc: Set to 1 if the escape key is pressed, otherwise not updated + * Returns: code for the key the user pressed: * enter: KEY_SELECT * Ctrl-C: KEY_QUIT * anything else: KEY_NONE - * @esc: Set to 1 if the escape key is pressed, otherwise not updated */ -void bootmenu_autoboot_loop(struct bootmenu_data *menu, - enum bootmenu_key *key, int *esc); +enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc); /** * bootmenu_loop() - handle waiting for a keypress when autoboot is disabled -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 06/25] menu: Update bootmenu_loop() to return the code
Use the return value to save having to pass around a pointer. This also resolves any ambiguity about what *key contains when the function is called. Signed-off-by: Simon Glass --- (no changes since v1) cmd/bootmenu.c | 2 +- cmd/eficonfig.c | 4 ++-- common/menu.c | 30 -- include/menu.h | 11 +-- 4 files changed, 24 insertions(+), 23 deletions(-) diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index 0e22f504fe4..573afe16609 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -96,7 +96,7 @@ static char *bootmenu_choice_entry(void *data) key = bootmenu_autoboot_loop(menu, &esc); } else { /* Some key was pressed, so autoboot was stopped */ - bootmenu_loop(menu, &key, &esc); + key = bootmenu_loop(menu, &esc); } switch (key) { diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c index 8f246bc271f..96cb1a367f3 100644 --- a/cmd/eficonfig.c +++ b/cmd/eficonfig.c @@ -191,7 +191,7 @@ static char *eficonfig_choice_entry(void *data) struct efimenu *efi_menu = data; while (1) { - bootmenu_loop((struct bootmenu_data *)efi_menu, &key, &esc); + key = bootmenu_loop((struct bootmenu_data *)efi_menu, &esc); switch (key) { case BKEY_UP: @@ -1868,7 +1868,7 @@ static efi_status_t eficonfig_choice_change_boot_order(struct efimenu *efi_menu) struct eficonfig_entry *entry, *tmp; while (1) { - bootmenu_loop(NULL, &key, &esc); + key = bootmenu_loop(NULL, &esc); switch (key) { case BKEY_PLUS: diff --git a/common/menu.c b/common/menu.c index bafc8470d7d..6842f5409d6 100644 --- a/common/menu.c +++ b/common/menu.c @@ -476,9 +476,9 @@ enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc) return key; } -void bootmenu_loop(struct bootmenu_data *menu, - enum bootmenu_key *key, int *esc) +enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, int *esc) { + enum bootmenu_key key = BKEY_NONE; int c; if (*esc == 1) { @@ -505,17 +505,17 @@ void bootmenu_loop(struct bootmenu_data *menu, /* First char of ANSI escape sequence '\e' */ if (c == '\e') { *esc = 1; - *key = BKEY_NONE; + key = BKEY_NONE; } break; case 1: /* Second char of ANSI '[' */ if (c == '[') { *esc = 2; - *key = BKEY_NONE; + key = BKEY_NONE; } else { /* Alone ESC key was pressed */ - *key = BKEY_QUIT; + key = BKEY_QUIT; *esc = (c == '\e') ? 1 : 0; } break; @@ -524,7 +524,7 @@ void bootmenu_loop(struct bootmenu_data *menu, /* Third char of ANSI (number '1') - optional */ if (*esc == 2 && c == '1') { *esc = 3; - *key = BKEY_NONE; + key = BKEY_NONE; break; } @@ -532,31 +532,33 @@ void bootmenu_loop(struct bootmenu_data *menu, /* ANSI 'A' - key up was pressed */ if (c == 'A') - *key = BKEY_UP; + key = BKEY_UP; /* ANSI 'B' - key down was pressed */ else if (c == 'B') - *key = BKEY_DOWN; + key = BKEY_DOWN; /* other key was pressed */ else - *key = BKEY_NONE; + key = BKEY_NONE; break; } /* enter key was pressed */ if (c == '\r') - *key = BKEY_SELECT; + key = BKEY_SELECT; /* ^C was pressed */ if (c == 0x3) - *key = BKEY_QUIT; + key = BKEY_QUIT; if (c == '+') - *key = BKEY_PLUS; + key = BKEY_PLUS; if (c == '-') - *key = BKEY_MINUS; + key = BKEY_MINUS; if (c == ' ') - *key = BKEY_SPACE; + key = BKEY_SPACE; + + return key; } diff --git a/include/menu.h b/include/menu.h index 9f30a3c1acd..8b9b36214f7 100644 --- a/include/menu.h +++ b/include/menu.h @@ -83,7 +83,10 @@ enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc); * character is recognised * * @menu: Menu being processed - * @key: Returns the code for the key the user pressed: + * @esc: On input, a non-zero value indicates that an escape sequence has + * resulted in that many characters so far. On exit this is updated
[PATCH v3 07/25] menu: Use a switch statement
Convert the long line of if() statements to a switch() since this makes better use of the C language. Signed-off-by: Simon Glass --- (no changes since v1) common/menu.c | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/common/menu.c b/common/menu.c index 6842f5409d6..7db98942a61 100644 --- a/common/menu.c +++ b/common/menu.c @@ -543,22 +543,31 @@ enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, int *esc) break; } - /* enter key was pressed */ - if (c == '\r') + switch (c) { + case '\r': + /* enter key was pressed */ key = BKEY_SELECT; - - /* ^C was pressed */ - if (c == 0x3) + break; + case CTL_CH('c'): + /* ^C was pressed */ key = BKEY_QUIT; - - if (c == '+') + break; + case CTL_CH('p'): + key = BKEY_UP; + break; + case CTL_CH('n'): + key = BKEY_DOWN; + break; + case '+': key = BKEY_PLUS; - - if (c == '-') + break; + case '-': key = BKEY_MINUS; - - if (c == ' ') + break; + case ' ': key = BKEY_SPACE; + break; + } return key; } -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 09/25] image: Add a function to find a script in an image
Split this functionality out of the 'source' command so it can be used from another place. For now leave it where it is, but a future patch will move it out of cmd/ Signed-off-by: Simon Glass --- (no changes since v1) cmd/source.c| 173 ++-- include/image.h | 13 2 files changed, 107 insertions(+), 79 deletions(-) diff --git a/cmd/source.c b/cmd/source.c index 698d9f86d96..dfa995f1df6 100644 --- a/cmd/source.c +++ b/cmd/source.c @@ -24,7 +24,6 @@ #include #include -#if defined(CONFIG_FIT) /** * get_default_image() - Return default property from /images * @@ -40,123 +39,139 @@ static const char *get_default_image(const void *fit) return fdt_getprop(fit, images_noffset, FIT_DEFAULT_PROP, NULL); } -#endif -int image_source_script(ulong addr, const char *fit_uname) +int image_locate_script(void *buf, int size, const char *fit_uname, + char **datap, uint *lenp) { ulong len; -#if defined(CONFIG_LEGACY_IMAGE_FORMAT) const struct legacy_img_hdr *hdr; -#endif u32 *data; int verify; - void *buf; -#if defined(CONFIG_FIT) const void* fit_hdr; int noffset; const void *fit_data; size_t fit_len; -#endif verify = env_get_yesno("verify"); - buf = map_sysmem(addr, 0); switch (genimg_get_format(buf)) { -#if defined(CONFIG_LEGACY_IMAGE_FORMAT) case IMAGE_FORMAT_LEGACY: - hdr = buf; + if (IS_ENABLED(CONFIG_LEGACY_IMAGE_FORMAT)) { + hdr = buf; - if (!image_check_magic (hdr)) { - puts ("Bad magic number\n"); - return 1; - } + if (!image_check_magic(hdr)) { + puts("Bad magic number\n"); + return 1; + } - if (!image_check_hcrc (hdr)) { - puts ("Bad header crc\n"); - return 1; - } + if (!image_check_hcrc(hdr)) { + puts("Bad header crc\n"); + return 1; + } + + if (verify) { + if (!image_check_dcrc(hdr)) { + puts("Bad data crc\n"); + return 1; + } + } - if (verify) { - if (!image_check_dcrc (hdr)) { - puts ("Bad data crc\n"); + if (!image_check_type(hdr, IH_TYPE_SCRIPT)) { + puts("Bad image type\n"); return 1; } - } - if (!image_check_type (hdr, IH_TYPE_SCRIPT)) { - puts ("Bad image type\n"); - return 1; - } + /* get length of script */ + data = (u32 *)image_get_data(hdr); - /* get length of script */ - data = (u32 *)image_get_data (hdr); + len = uimage_to_cpu(*data); + if (!len) { + puts("Empty Script\n"); + return 1; + } - if ((len = uimage_to_cpu (*data)) == 0) { - puts ("Empty Script\n"); - return 1; + /* +* scripts are just multi-image files with one +* component, so seek past the zero-terminated sequence +* of image lengths to get to the actual image data +*/ + while (*data++); } - - /* -* scripts are just multi-image files with one component, seek -* past the zero-terminated sequence of image lengths to get -* to the actual image data -*/ - while (*data++); break; -#endif -#if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: - fit_hdr = buf; - if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) { - puts ("Bad FIT image format\n"); - return 1; - } + if (IS_ENABLED(CONFIG_FIT)) { + fit_hdr = buf; + if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) { + puts("Bad FIT image format\n"); + return 1; + } - if (!fit_uname) - fit_uname = get_default_image(fit_hdr
[PATCH v3 10/25] image: Move common image code to image_board and command
We should use the cmd/ directory for commands rather than for common code used elsewhere in U-Boot. Move the common 'source' code into image-board.c to achieve this. The image_source_script() function needs to call run_command_list() so seems to belong better in the command library. Move and rename it. Signed-off-by: Simon Glass --- (no changes since v1) .../cmd_stm32prog/cmd_stm32prog.c | 2 +- boot/bootmeth_script.c| 2 +- boot/image-board.c| 133 +++ cmd/source.c | 155 +- common/command.c | 19 +++ drivers/usb/gadget/f_sdp.c| 2 +- include/command.h | 12 ++ include/image.h | 12 -- 8 files changed, 168 insertions(+), 169 deletions(-) diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c index 007f7131306..6fb3d868d77 100644 --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c @@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, int argc, do_bootz(cmdtp, 0, 4, bootm_argv); } if (data->script) - image_source_script(data->script, "script@stm32prog"); + cmd_source_script(data->script, "script@stm32prog"); if (reset) { puts("Reset...\n"); diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c index d1c3f940037..16c5dadcca1 100644 --- a/boot/bootmeth_script.c +++ b/boot/bootmeth_script.c @@ -101,7 +101,7 @@ static int script_boot(struct udevice *dev, struct bootflow *bflow) log_debug("mmc_bootdev: %s\n", env_get("mmc_bootdev")); addr = map_to_sysmem(bflow->buf); - ret = image_source_script(addr, NULL); + ret = cmd_source_script(addr, NULL); if (ret) return log_msg_ret("boot", ret); diff --git a/boot/image-board.c b/boot/image-board.c index 34d1e5f18be..7f96a80c85b 100644 --- a/boot/image-board.c +++ b/boot/image-board.c @@ -971,3 +971,136 @@ void genimg_print_time(time_t timestamp) tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec); } + +/** + * get_default_image() - Return default property from /images + * + * Return: Pointer to value of default property (or NULL) + */ +static const char *get_default_image(const void *fit) +{ + int images_noffset; + + images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH); + if (images_noffset < 0) + return NULL; + + return fdt_getprop(fit, images_noffset, FIT_DEFAULT_PROP, NULL); +} + +int image_locate_script(void *buf, int size, const char *fit_uname, + char **datap, uint *lenp) +{ + const struct legacy_img_hdr *hdr; + const void *fit_data; + const void *fit_hdr; + size_t fit_len; + int noffset; + int verify; + ulong len; + u32 *data; + + verify = env_get_yesno("verify"); + + switch (genimg_get_format(buf)) { + case IMAGE_FORMAT_LEGACY: + if (IS_ENABLED(CONFIG_LEGACY_IMAGE_FORMAT)) { + hdr = buf; + + if (!image_check_magic(hdr)) { + puts("Bad magic number\n"); + return 1; + } + + if (!image_check_hcrc(hdr)) { + puts("Bad header crc\n"); + return 1; + } + + if (verify) { + if (!image_check_dcrc(hdr)) { + puts("Bad data crc\n"); + return 1; + } + } + + if (!image_check_type(hdr, IH_TYPE_SCRIPT)) { + puts("Bad image type\n"); + return 1; + } + + /* get length of script */ + data = (u32 *)image_get_data(hdr); + + len = uimage_to_cpu(*data); + if (!len) { + puts("Empty Script\n"); + return 1; + } + + /* +* scripts are just multi-image files with one +* component, so seek past the zero-terminated sequence +* of image lengths to get to the actual image data +*/ + while (*data++); + } + break; + case IMAGE_FORMAT_FIT: + if (IS_ENABLED(CONFIG_FIT)) { + fit_hdr = buf; +
[PATCH v3 11/25] video: Enable VIDEO_ANSI by default only with EFI
This is not generally needed unless EFI_LOADER is used. Adjust the default setting to reduce the size of the U-Boot build. Signed-off-by: Simon Glass --- (no changes since v1) drivers/video/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index c841b99bb30..0c914dc1165 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -112,10 +112,13 @@ config VIDEO_BPP32 config VIDEO_ANSI bool "Support ANSI escape sequences in video console" - default y + default y if EFI_LOADER help Enable ANSI escape sequence decoding for a more fully functional - console. + console. Functionality includes changing the text colour and moving + the cursor. These date from the 1970s and are still widely used today + to control a text terminal. U-Boot implements these by decoding the + sequences and performing the appropriate operation. config VIDEO_MIPI_DSI bool "Support MIPI DSI interface" -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 12/25] video: truetype: Rename the metrics function
This should really have a 'truetype' prefix. Fix it. Signed-off-by: Simon Glass --- (no changes since v1) drivers/video/console_truetype.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c index 6859c9fa116..4abc0bc2ff1 100644 --- a/drivers/video/console_truetype.c +++ b/drivers/video/console_truetype.c @@ -595,7 +595,7 @@ void vidconsole_list_fonts(void) } /** - * vidconsole_add_metrics() - Add a new font/size combination + * truetype_add_metrics() - Add a new font/size combination * * @dev: Video console device to update * @font_name: Name of font @@ -604,8 +604,8 @@ void vidconsole_list_fonts(void) * @return 0 if OK, -EPERM if stbtt failed, -E2BIG if the the metrics table is * full */ -static int vidconsole_add_metrics(struct udevice *dev, const char *font_name, - uint font_size, const void *font_data) +static int truetype_add_metrics(struct udevice *dev, const char *font_name, + uint font_size, const void *font_data) { struct console_tt_priv *priv = dev_get_priv(dev); struct console_tt_metrics *met; @@ -693,7 +693,7 @@ int vidconsole_select_font(struct udevice *dev, const char *name, uint size) !strcmp(name, tab->name)) { int ret; - ret = vidconsole_add_metrics(dev, + ret = truetype_add_metrics(dev, tab->name, size, tab->begin); if (ret < 0) return log_msg_ret("add", ret); @@ -745,7 +745,7 @@ static int console_truetype_probe(struct udevice *dev) return -EBFONT; } - ret = vidconsole_add_metrics(dev, tab->name, font_size, tab->begin); + ret = truetype_add_metrics(dev, tab->name, font_size, tab->begin); if (ret < 0) return log_msg_ret("add", ret); priv->cur_met = &priv->metrics[ret]; -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 15/25] bootstd: Read the Operating System name for distro/scripts
Add the concept of an OS name to the bootflow. This typically includes the OS name, version and kernel version. Implement this for the distro and script bootmeths so that it works with Armbian and older version of Fedora. Signed-off-by: Simon Glass --- (no changes since v1) boot/bootflow.c| 1 + boot/bootmeth_distro.c | 36 boot/bootmeth_script.c | 34 ++ cmd/bootflow.c | 1 + include/bootflow.h | 3 +++ test/boot/bootflow.c | 1 + 6 files changed, 76 insertions(+) diff --git a/boot/bootflow.c b/boot/bootflow.c index f9ad4099244..163cd4953dd 100644 --- a/boot/bootflow.c +++ b/boot/bootflow.c @@ -354,6 +354,7 @@ void bootflow_free(struct bootflow *bflow) free(bflow->subdir); free(bflow->fname); free(bflow->buf); + free(bflow->os_name); } void bootflow_remove(struct bootflow *bflow) diff --git a/boot/bootmeth_distro.c b/boot/bootmeth_distro.c index 5c6c687f0a6..6ef0fa1f2c9 100644 --- a/boot/bootmeth_distro.c +++ b/boot/bootmeth_distro.c @@ -66,6 +66,38 @@ static int distro_check(struct udevice *dev, struct bootflow_iter *iter) return 0; } +/** + * distro_fill_info() - Decode the extlinux file to find out distro info + * + * @bflow: Bootflow to process + * @return 0 if OK, -ve on error + */ +static int distro_fill_info(struct bootflow *bflow) +{ + struct membuff mb; + char line[200]; + char *data; + int len; + + log_debug("parsing bflow file size %x\n", bflow->size); + membuff_init(&mb, bflow->buf, bflow->size); + membuff_putraw(&mb, bflow->size, true, &data); + while (len = membuff_readline(&mb, line, sizeof(line) - 1, ' '), len) { + char *tok, *p = line; + + tok = strsep(&p, " "); + if (p) { + if (!strcmp("label", tok)) { + bflow->os_name = strdup(p); + if (!bflow->os_name) + return log_msg_ret("os", -ENOMEM); + } + } + } + + return 0; +} + static int distro_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct blk_desc *desc; @@ -99,6 +131,10 @@ static int distro_read_bootflow(struct udevice *dev, struct bootflow *bflow) if (ret) return log_msg_ret("read", ret); + ret = distro_fill_info(bflow); + if (ret) + return log_msg_ret("inf", ret); + return 0; } diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c index 16c5dadcca1..6f2a09846db 100644 --- a/boot/bootmeth_script.c +++ b/boot/bootmeth_script.c @@ -35,6 +35,36 @@ static int script_check(struct udevice *dev, struct bootflow_iter *iter) return 0; } +/** + * script_fill_info() - Decode the U-Boot script to find out distro info + * + * @bflow: Bootflow to process + * @return 0 if OK, -ve on error + */ +static int script_fill_info(struct bootflow *bflow) +{ + char *name = NULL; + char *data; + uint len; + int ret; + + log_debug("parsing bflow file size %x\n", bflow->size); + + ret = image_locate_script(bflow->buf, bflow->size, NULL, &data, &len); + if (!ret) { + if (strstr(data, "armbianEnv")) + name = "Armbian"; + } + + if (name) { + bflow->os_name = strdup(name); + if (!bflow->os_name) + return log_msg_ret("os", -ENOMEM); + } + + return 0; +} + static int script_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct blk_desc *desc = NULL; @@ -75,6 +105,10 @@ static int script_read_bootflow(struct udevice *dev, struct bootflow *bflow) if (ret) return log_msg_ret("read", ret); + ret = script_fill_info(bflow); + if (ret) + return log_msg_ret("inf", ret); + return 0; } diff --git a/cmd/bootflow.c b/cmd/bootflow.c index 313103d2775..6b8ac8c8504 100644 --- a/cmd/bootflow.c +++ b/cmd/bootflow.c @@ -337,6 +337,7 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int flag, int argc, printf("Filename: %s\n", bflow->fname); printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf)); printf("Size: %x (%d bytes)\n", bflow->size, bflow->size); + printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)"); printf("Error: %d\n", bflow->err); if (dump && bflow->buf) { /* Set some sort of maximum on the size */ diff --git a/include/bootflow.h b/include/bootflow.h index 32de261..776158c65df 100644 --- a/include/bootflow.h +++ b/include/bootflow.h @@ -52,6 +52,8 @@ enum bootflow_state_t { * @buf: Bootflow file contents (allocated) * @size: Size of bootflow file in bytes * @err: Error number received (0 if OK) + * @os_name: Name of the OS /
[PATCH v3 14/25] video: Add font functions to the vidconsole API
Support for fonts currently depends on the type of vidconsole in use. Add two new methods to enumerate fonts and to set the font. Fix a few other method comments while we are here. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Rename vidconsole_get_font() to vidconsole_get_font_size() cmd/font.c| 11 - drivers/video/console_truetype.c | 27 +++ drivers/video/vidconsole-uclass.c | 33 ++ include/video_console.h | 75 ++- test/cmd/font.c | 6 +-- 5 files changed, 127 insertions(+), 25 deletions(-) diff --git a/cmd/font.c b/cmd/font.c index 3e522f3aaa1..7b4347f32b5 100644 --- a/cmd/font.c +++ b/cmd/font.c @@ -15,7 +15,11 @@ static int do_font_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { - vidconsole_list_fonts(); + struct udevice *dev; + + if (uclass_first_device_err(UCLASS_VIDEO_CONSOLE, &dev)) + return CMD_RET_FAILURE; + vidconsole_list_fonts(dev); return 0; } @@ -47,6 +51,7 @@ static int do_font_select(struct cmd_tbl *cmdtp, int flag, int argc, static int do_font_size(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { + const char *font_name; struct udevice *dev; uint size; int ret; @@ -56,9 +61,11 @@ static int do_font_size(struct cmd_tbl *cmdtp, int flag, int argc, if (uclass_first_device_err(UCLASS_VIDEO_CONSOLE, &dev)) return CMD_RET_FAILURE; + font_name = vidconsole_get_font_size(dev, &size); size = dectoul(argv[1], NULL); - ret = vidconsole_select_font(dev, NULL, size); + + ret = vidconsole_select_font(dev, font_name, size); if (ret) { printf("Failed (error %d)\n", ret); return CMD_RET_FAILURE; diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c index 4abc0bc2ff1..9cac9a6de4d 100644 --- a/drivers/video/console_truetype.c +++ b/drivers/video/console_truetype.c @@ -584,14 +584,20 @@ static struct font_info *console_truetype_find_font(void) return NULL; } -void vidconsole_list_fonts(void) +int console_truetype_get_font(struct udevice *dev, int seq, + struct vidfont_info *info) { struct font_info *tab; + int i; - for (tab = font_table; tab->begin; tab++) { - if (abs(tab->begin - tab->end) > 4) - printf("%s\n", tab->name); + for (i = 0, tab = font_table; tab->begin; tab++, i++) { + if (i == seq && font_valid(tab)) { + info->name = tab->name; + return 0; + } } + + return -ENOENT; } /** @@ -674,7 +680,8 @@ static void select_metrics(struct udevice *dev, struct console_tt_metrics *met) vc_priv->tab_width_frac = VID_TO_POS(met->font_size) * 8 / 2; } -int vidconsole_select_font(struct udevice *dev, const char *name, uint size) +static int truetype_select_font(struct udevice *dev, const char *name, + uint size) { struct console_tt_priv *priv = dev_get_priv(dev); struct console_tt_metrics *met; @@ -684,7 +691,7 @@ int vidconsole_select_font(struct udevice *dev, const char *name, uint size) if (!size) size = CONFIG_CONSOLE_TRUETYPE_SIZE; if (!name) - name = priv->cur_met->font_name; + name = font_table->name; met = find_metrics(dev, name, size); if (!met) { @@ -694,7 +701,9 @@ int vidconsole_select_font(struct udevice *dev, const char *name, uint size) int ret; ret = truetype_add_metrics(dev, - tab->name, size, tab->begin); + tab->name, + size, + tab->begin); if (ret < 0) return log_msg_ret("add", ret); @@ -715,7 +724,7 @@ int vidconsole_select_font(struct udevice *dev, const char *name, uint size) return 0; } -const char *vidconsole_get_font(struct udevice *dev, uint *sizep) +const char *vidconsole_get_font_size(struct udevice *dev, uint *sizep) { struct console_tt_priv *priv = dev_get_priv(dev); struct console_tt_metrics *met = priv->cur_met; @@ -763,6 +772,8 @@ struct vidconsole_ops console_truetype_ops = { .set_row= console_truetype_set_row, .backspace = console_truetype_backspace, .entry_start= console_truetype_entry_start, +
[PATCH v3 17/25] menu: Factor out menu-keypress decoding
Move this code into a separate function so that it can be used in the new VBE menu. Signed-off-by: Simon Glass --- (no changes since v1) common/menu.c | 48 ++-- include/menu.h | 10 ++ 2 files changed, 40 insertions(+), 18 deletions(-) diff --git a/common/menu.c b/common/menu.c index 45f36ae3ede..cdcdbb2a185 100644 --- a/common/menu.c +++ b/common/menu.c @@ -483,26 +483,11 @@ enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, return key; } -enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, - struct cli_ch_state *cch) +enum bootmenu_key bootmenu_conv_key(int ichar) { - enum bootmenu_key key = BKEY_NONE; - int c; - - c = cli_ch_process(cch, 0); - if (!c) { - while (!c && !tstc()) { - schedule(); - mdelay(10); - c = cli_ch_process(cch, -ETIMEDOUT); - } - if (!c) { - c = getchar(); - c = cli_ch_process(cch, c); - } - } + enum bootmenu_key key; - switch (c) { + switch (ichar) { case '\n': /* enter key was pressed */ key = BKEY_SELECT; @@ -527,7 +512,34 @@ enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, case ' ': key = BKEY_SPACE; break; + default: + key = BKEY_NONE; + break; + } + + return key; +} + +enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, + struct cli_ch_state *cch) +{ + enum bootmenu_key key; + int c; + + c = cli_ch_process(cch, 0); + if (!c) { + while (!c && !tstc()) { + schedule(); + mdelay(10); + c = cli_ch_process(cch, -ETIMEDOUT); + } + if (!c) { + c = getchar(); + c = cli_ch_process(cch, c); + } } + key = bootmenu_conv_key(c); + return key; } diff --git a/include/menu.h b/include/menu.h index 3996075a337..1e88141d6bf 100644 --- a/include/menu.h +++ b/include/menu.h @@ -53,6 +53,8 @@ enum bootmenu_key { BKEY_PLUS, BKEY_MINUS, BKEY_SPACE, + + BKEY_COUNT, }; /** @@ -101,4 +103,12 @@ enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, struct cli_ch_state *cch); +/** + * bootmenu_conv_key() - Convert a U-Boot keypress into a menu key + * + * @ichar: Keypress to convert (ASCII, including control characters) + * Returns: Menu key that corresponds to @ichar, or BKEY_NONE if none + */ +enum bootmenu_key bootmenu_conv_key(int ichar); + #endif /* __MENU_H__ */ -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 16/25] bootstd: Allow reading a logo for the OS
Some operating systems provide a logo in bmp format. Read this in if present so it can be displayed in the menu. Signed-off-by: Simon Glass --- (no changes since v1) boot/bootmeth-uclass.c | 69 -- boot/bootmeth_script.c | 4 +++ cmd/bootflow.c | 6 include/bootflow.h | 4 +++ include/bootmeth.h | 16 ++ test/boot/bootflow.c | 1 + 6 files changed, 91 insertions(+), 9 deletions(-) diff --git a/boot/bootmeth-uclass.c b/boot/bootmeth-uclass.c index 25552dd96f6..4c3529d1555 100644 --- a/boot/bootmeth-uclass.c +++ b/boot/bootmeth-uclass.c @@ -290,25 +290,19 @@ int bootmeth_try_file(struct bootflow *bflow, struct blk_desc *desc, return 0; } -int bootmeth_alloc_file(struct bootflow *bflow, uint size_limit, uint align) +static int alloc_file(const char *fname, uint size, void **bufp) { loff_t bytes_read; ulong addr; char *buf; - uint size; int ret; - size = bflow->size; - log_debug(" - script file size %x\n", size); - if (size > size_limit) - return log_msg_ret("chk", -E2BIG); - - buf = memalign(align, size + 1); + buf = malloc(size + 1); if (!buf) return log_msg_ret("buf", -ENOMEM); addr = map_to_sysmem(buf); - ret = fs_read(bflow->fname, addr, 0, 0, &bytes_read); + ret = fs_read(fname, addr, 0, size, &bytes_read); if (ret) { free(buf); return log_msg_ret("read", ret); @@ -316,12 +310,69 @@ int bootmeth_alloc_file(struct bootflow *bflow, uint size_limit, uint align) if (size != bytes_read) return log_msg_ret("bread", -EINVAL); buf[size] = '\0'; + + *bufp = buf; + + return 0; +} + +int bootmeth_alloc_file(struct bootflow *bflow, uint size_limit, uint align) +{ + void *buf; + uint size; + int ret; + + size = bflow->size; + log_debug(" - script file size %x\n", size); + if (size > size_limit) + return log_msg_ret("chk", -E2BIG); + + ret = alloc_file(bflow->fname, bflow->size, &buf); + if (ret) + return log_msg_ret("all", ret); + bflow->state = BOOTFLOWST_READY; bflow->buf = buf; return 0; } +int bootmeth_alloc_other(struct bootflow *bflow, const char *fname, +void **bufp, uint *sizep) +{ + struct blk_desc *desc = NULL; + char path[200]; + loff_t size; + void *buf; + int ret; + + snprintf(path, sizeof(path), "%s%s", bflow->subdir, fname); + log_debug("trying: %s\n", path); + + if (bflow->blk) + desc = dev_get_uclass_plat(bflow->blk); + + ret = setup_fs(bflow, desc); + if (ret) + return log_msg_ret("fs", ret); + + ret = fs_size(path, &size); + log_debug(" %s - err=%d\n", path, ret); + + ret = setup_fs(bflow, desc); + if (ret) + return log_msg_ret("fs", ret); + + ret = alloc_file(path, size, &buf); + if (ret) + return log_msg_ret("all", ret); + + *bufp = buf; + *sizep = size; + + return 0; +} + int bootmeth_common_read_file(struct udevice *dev, struct bootflow *bflow, const char *file_path, ulong addr, ulong *sizep) { diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c index 6f2a09846db..a8f77e29f99 100644 --- a/boot/bootmeth_script.c +++ b/boot/bootmeth_script.c @@ -109,6 +109,10 @@ static int script_read_bootflow(struct udevice *dev, struct bootflow *bflow) if (ret) return log_msg_ret("inf", ret); + ret = bootmeth_alloc_other(bflow, "boot.bmp", &bflow->logo, + &bflow->logo_size); + /* ignore error */ + return 0; } diff --git a/cmd/bootflow.c b/cmd/bootflow.c index 6b8ac8c8504..495ef85f25b 100644 --- a/cmd/bootflow.c +++ b/cmd/bootflow.c @@ -338,6 +338,12 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int flag, int argc, printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf)); printf("Size: %x (%d bytes)\n", bflow->size, bflow->size); printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)"); + printf("Logo: %s\n", bflow->logo ? + simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)"); + if (bflow->logo) { + printf("Logo size: %x (%d bytes)\n", bflow->logo_size, + bflow->logo_size); + } printf("Error: %d\n", bflow->err); if (dump && bflow->buf) { /* Set some sort of maximum on the size */ diff --git a/include/bootflow.h b/include/bootflow.h index 776158c65df..8a07ab30191 100644 --- a/include/bootflow.h +++ b/include/bootflow.h @@ -49,6 +49,8 @@ enum bootflow_state_t { * @state: Current state (enum bootflow_state_t) * @subdir: S
[PATCH v3 18/25] expo: Add basic implementation
An expo is a way of presenting and collecting information from the user. It consists of a collection of 'scenes' of which only one is presented at a time. An expo is typically used to show a boot menu and allow settings to be changed. One created, the same expo can be automatically presented in graphical form using a vidconsole, or in text form on a serial console. Add an initial implementation of the expo itself. Supports for scenes and objects is provided later. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Drop the _add suffix on expo creation function - Put strings in a separate structure referenced by ID boot/Kconfig | 12 + boot/expo.c | 170 configs/tools-only_defconfig | 2 + include/expo.h | 521 +++ 4 files changed, 705 insertions(+) create mode 100644 boot/expo.c create mode 100644 include/expo.h diff --git a/boot/Kconfig b/boot/Kconfig index 424ad0e466d..f672a325776 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -556,6 +556,18 @@ config VPL_BOOTMETH_VBE_SIMPLE_FW endif # BOOTMETH_VBE +config EXPO + bool "Support for expos - groups of scenes displaying a UI" + default y if BOOTMETH_VBE + help + An expo is a way of presenting and collecting information from the + user. It consists of a collection of 'scenes' of which only one is + presented at a time. An expo is typically used to show a boot menu + and allow settings to be changed. + + The expo can be presented in graphics form using a vidconsole, or in + text form on a serial console. + config BOOTMETH_SANDBOX def_bool y depends on SANDBOX diff --git a/boot/expo.c b/boot/expo.c new file mode 100644 index 000..05950a17603 --- /dev/null +++ b/boot/expo.c @@ -0,0 +1,170 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Implementation of a expo, a collection of scenes providing menu options + * + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#include +#include +#include +#include +#include +#include "scene_internal.h" + +int expo_new(const char *name, void *priv, struct expo **expp) +{ + struct expo *exp; + + exp = calloc(1, sizeof(struct expo)); + if (!exp) + return log_msg_ret("expo", -ENOMEM); + exp->name = strdup(name); + if (!exp->name) { + free(exp); + return log_msg_ret("name", -ENOMEM); + } + exp->priv = priv; + INIT_LIST_HEAD(&exp->scene_head); + INIT_LIST_HEAD(&exp->str_head); + + *expp = exp; + + return 0; +} + +static void estr_destroy(struct expo_string *estr) +{ + free(estr); +} + +void expo_destroy(struct expo *exp) +{ + struct scene *scn, *next; + struct expo_string *estr, *enext; + + list_for_each_entry_safe(scn, next, &exp->scene_head, sibling) + scene_destroy(scn); + + list_for_each_entry_safe(estr, enext, &exp->str_head, sibling) + estr_destroy(estr); + + free(exp->name); + free(exp); +} + +int expo_str(struct expo *exp, const char *name, uint id, const char *str) +{ + struct expo_string *estr; + + estr = calloc(1, sizeof(struct expo_string)); + if (!estr) + return log_msg_ret("obj", -ENOMEM); + + estr->id = resolve_id(exp, id); + estr->str = str; + list_add_tail(&estr->sibling, &exp->str_head); + + return estr->id; +} + +const char *expo_get_str(struct expo *exp, uint id) +{ + struct expo_string *estr; + + list_for_each_entry(estr, &exp->str_head, sibling) { + if (estr->id == id) + return estr->str; + } + + return NULL; +} + +int expo_set_display(struct expo *exp, struct udevice *dev) +{ + exp->display = dev; + + return 0; +} + +void exp_set_text_mode(struct expo *exp, bool text_mode) +{ + exp->text_mode = text_mode; +} + +struct scene *expo_lookup_scene_id(struct expo *exp, uint scene_id) +{ + struct scene *scn; + + list_for_each_entry(scn, &exp->scene_head, sibling) { + if (scn->id == scene_id) + return scn; + } + + return NULL; +} + +int expo_set_scene_id(struct expo *exp, uint scene_id) +{ + if (!expo_lookup_scene_id(exp, scene_id)) + return log_msg_ret("id", -ENOENT); + exp->scene_id = scene_id; + + return 0; +} + +int expo_render(struct expo *exp) +{ + struct udevice *dev = exp->display; + struct video_priv *vid_priv = dev_get_uclass_priv(dev); + struct scene *scn = NULL; + u32 colour; + int ret; + + colour = video_index_to_colour(vid_priv, VID_WHITE); + ret = video_fill(dev, colour); + if (ret) + return log_msg_ret("fill", ret); + + if (exp->scene_id) { + scn = expo_lookup_scene_id(exp, exp->scene_id)
[PATCH v3 19/25] expo: Add support for scenes
A scene is a single screen within an expo. It is possible to move between scenes but only one can be displayed at once. Add a basic implementation. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Drop the _add suffix on expo creation function - Put strings in a separate structure referenced by ID boot/scene.c | 414 ++ boot/scene_internal.h | 123 + 2 files changed, 537 insertions(+) create mode 100644 boot/scene.c create mode 100644 boot/scene_internal.h diff --git a/boot/scene.c b/boot/scene.c new file mode 100644 index 000..030f6aa2a0a --- /dev/null +++ b/boot/scene.c @@ -0,0 +1,414 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Implementation of a scene, a collection of text/image/menu items in an expo + * + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "scene_internal.h" + +uint resolve_id(struct expo *exp, uint id) +{ + if (!id) + id = exp->next_id++; + else if (id >= exp->next_id) + exp->next_id = id + 1; + + return id; +} + +int scene_new(struct expo *exp, const char *name, uint id, struct scene **scnp) +{ + struct scene *scn; + + scn = calloc(1, sizeof(struct scene)); + if (!scn) + return log_msg_ret("expo", -ENOMEM); + scn->name = strdup(name); + if (!scn->name) { + free(scn); + return log_msg_ret("name", -ENOMEM); + } + + INIT_LIST_HEAD(&scn->obj_head); + scn->id = resolve_id(exp, id); + scn->expo = exp; + list_add_tail(&scn->sibling, &exp->scene_head); + + *scnp = scn; + + return scn->id; +} + +void scene_obj_destroy(struct scene_obj *obj) +{ + if (obj->type == SCENEOBJT_MENU) + scene_menu_destroy((struct scene_obj_menu *)obj); + free(obj->name); + free(obj); +} + +void scene_destroy(struct scene *scn) +{ + struct scene_obj *obj, *next; + + list_for_each_entry_safe(obj, next, &scn->obj_head, sibling) + scene_obj_destroy(obj); + + free(scn->name); + free(scn->title); + free(scn); +} + +int scene_title_set(struct scene *scn, const char *title) +{ + free(scn->title); + scn->title = strdup(title); + if (!scn->title) + return log_msg_ret("tit", -ENOMEM); + + return 0; +} + +int scene_obj_count(struct scene *scn) +{ + struct scene_obj *obj; + int count = 0; + + list_for_each_entry(obj, &scn->obj_head, sibling) + count++; + + return count; +} + +void *scene_obj_find(struct scene *scn, uint id, enum scene_obj_t type) +{ + struct scene_obj *obj; + + list_for_each_entry(obj, &scn->obj_head, sibling) { + if (obj->id == id && + (type == SCENEOBJT_NONE || obj->type == type)) + return obj; + } + + return NULL; +} + +int scene_obj_add(struct scene *scn, const char *name, uint id, + enum scene_obj_t type, uint size, struct scene_obj **objp) +{ + struct scene_obj *obj; + + obj = calloc(1, size); + if (!obj) + return log_msg_ret("obj", -ENOMEM); + obj->name = strdup(name); + if (!obj->name) { + free(obj); + return log_msg_ret("name", -ENOMEM); + } + + obj->id = resolve_id(scn->expo, id); + obj->scene = scn; + obj->type = type; + list_add_tail(&obj->sibling, &scn->obj_head); + *objp = obj; + + return obj->id; +} + +int scene_img(struct scene *scn, const char *name, uint id, char *data, + struct scene_obj_img **imgp) +{ + struct scene_obj_img *img; + int ret; + + ret = scene_obj_add(scn, name, id, SCENEOBJT_IMAGE, + sizeof(struct scene_obj_img), + (struct scene_obj **)&img); + if (ret < 0) + return log_msg_ret("obj", -ENOMEM); + + img->data = data; + + if (imgp) + *imgp = img; + + return img->obj.id; +} + +int scene_txt(struct scene *scn, const char *name, uint id, uint str_id, + struct scene_obj_txt **txtp) +{ + struct scene_obj_txt *txt; + int ret; + + ret = scene_obj_add(scn, name, id, SCENEOBJT_TEXT, + sizeof(struct scene_obj_txt), + (struct scene_obj **)&txt); + if (ret < 0) + return log_msg_ret("obj", -ENOMEM); + + txt->str_id = str_id; + + if (txtp) + *txtp = txt; + + return txt->obj.id; +} + +int scene_txt_str(struct scene *scn, const char *name, uint id, uint str_id, + const char *str, struct scene_obj_txt **txtp) +{ + struct scene_obj_txt *txt; + int ret; + + ret = expo_str(scn->expo,
[PATCH v3 22/25] bootstd: Support creating a boot menu
Create an expo to handle the boot menu. For now this is quite simple, with just a header, some menu items and a pointer to show the current one. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Rebase to master boot/Makefile| 1 + boot/bootflow_internal.h | 47 boot/bootflow_menu.c | 241 +++ cmd/bootflow.c | 37 +- include/bootflow.h | 23 5 files changed, 347 insertions(+), 2 deletions(-) create mode 100644 boot/bootflow_internal.h create mode 100644 boot/bootflow_menu.c diff --git a/boot/Makefile b/boot/Makefile index 0b30fcd64a9..f990e66f522 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL obj-$(CONFIG_$(SPL_TPL_)CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o +obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o endif obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o diff --git a/boot/bootflow_internal.h b/boot/bootflow_internal.h new file mode 100644 index 000..38cf02a55b5 --- /dev/null +++ b/boot/bootflow_internal.h @@ -0,0 +1,47 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Internal header file for bootflow + * + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#ifndef __BOOTFLOW_INTERNAL_H +#define __BOOTFLOW_INTERNAL_H + +/* expo IDs for elements of the bootflow menu */ +enum { + START, + + /* strings */ + STR_PROMPT, + STR_MENU_TITLE, + STR_POINTER, + + /* scene */ + MAIN, + + /* objects */ + OBJ_U_BOOT_LOGO, + OBJ_MENU, + OBJ_PROMPT, + OBJ_MENU_TITLE, + OBJ_POINTER, + + /* strings for menu items */ + STR_LABEL = 100, + STR_DESC = 200, + STR_KEY = 300, + + /* menu items / components (bootflow number is added to these) */ + ITEM = 400, + ITEM_LABEL = 500, + ITEM_DESC = 600, + ITEM_KEY = 700, + ITEM_PREVIEW = 800, + + /* left margin for the main menu */ + MARGIN_LEFT = 100, +}; + +#endif /* __BOOTFLOW_INTERNAL_H */ diff --git a/boot/bootflow_menu.c b/boot/bootflow_menu.c new file mode 100644 index 000..1105783afeb --- /dev/null +++ b/boot/bootflow_menu.c @@ -0,0 +1,241 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Provide a menu of available bootflows and related options + * + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#define LOG_CATEGORY UCLASS_BOOTSTD + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "bootflow_internal.h" + +/** + * struct menu_priv - information about the menu + * + * @num_bootflows: Number of bootflows in the menu + */ +struct menu_priv { + int num_bootflows; +}; + +int bootflow_menu_new(struct expo **expp) +{ + struct udevice *last_bootdev; + struct scene_obj_menu *menu; + struct menu_priv *priv; + struct bootflow *bflow; + struct scene *scn; + struct expo *exp; + void *logo; + int ret, i; + + priv = calloc(1, sizeof(*priv)); + if (!priv) + return log_msg_ret("prv", -ENOMEM); + + ret = expo_new("bootflows", priv, &exp); + if (ret) + return log_msg_ret("exp", ret); + + ret = scene_new(exp, "main", MAIN, &scn); + if (ret < 0) + return log_msg_ret("scn", ret); + + ret |= scene_txt_str(scn, "prompt", OBJ_PROMPT, STR_PROMPT, +"UP and DOWN to choose, ENTER to select", NULL); + + ret = scene_menu(scn, "main", OBJ_MENU, &menu); + ret |= scene_obj_set_pos(scn, OBJ_MENU, MARGIN_LEFT, 100); + ret |= scene_txt_str(scn, "title", OBJ_MENU_TITLE, STR_MENU_TITLE, +"U-Boot - Boot Menu", NULL); + ret |= scene_menu_set_title(scn, OBJ_MENU, OBJ_PROMPT); + + logo = video_get_u_boot_logo(); + if (logo) { + ret |= scene_img(scn, "ulogo", OBJ_U_BOOT_LOGO, logo, NULL); + ret |= scene_obj_set_pos(scn, OBJ_U_BOOT_LOGO, -4, 4); + } + + ret |= scene_txt_str(scn, "cur_item", OBJ_POINTER, STR_POINTER, ">", +NULL); + ret |= scene_menu_set_pointer(scn, OBJ_MENU, OBJ_POINTER); + if (ret < 0) + return log_msg_ret("new", -EINVAL); + + last_bootdev = NULL; + for (ret = bootflow_first_glob(&bflow), i = 0; !ret && i < 36; +ret = bootflow_next_glob(&bflow), i++) { + char str[2], *label, *key; + uint preview_id; + bool add_gap; + + if (bflow->state != BOOTFLOWST_READY) + continue; + + *str = i < 10 ? '0' + i : 'A' + i - 10; + str[1] = '\0'; + key = strdup(str); +
[PATCH v3 24/25] bootstd: Support setting a theme for the menu
Allow a theme to be set. For now this is very simple, just a default font size to use for all elements. Signed-off-by: Simon Glass --- (no changes since v1) boot/bootflow_menu.c | 43 ++ boot/bootstd-uclass.c | 2 ++ include/bootflow.h| 10 ++ include/bootstd.h | 4 +++ test/boot/bootflow.c | 83 +-- 5 files changed, 139 insertions(+), 3 deletions(-) diff --git a/boot/bootflow_menu.c b/boot/bootflow_menu.c index 1105783afeb..7f06dac0af7 100644 --- a/boot/bootflow_menu.c +++ b/boot/bootflow_menu.c @@ -129,6 +129,43 @@ int bootflow_menu_new(struct expo **expp) return 0; } +int bootflow_menu_apply_theme(struct expo *exp, ofnode node) +{ + struct menu_priv *priv = exp->priv; + struct scene *scn; + u32 font_size; + int ret; + + log_debug("Applying theme %s\n", ofnode_get_name(node)); + scn = expo_lookup_scene_id(exp, MAIN); + if (!scn) + return log_msg_ret("scn", -ENOENT); + + /* Avoid error-checking optional items */ + if (!ofnode_read_u32(node, "font-size", &font_size)) { + int i; + + log_debug("font size %d\n", font_size); + scene_txt_set_font(scn, OBJ_PROMPT, NULL, font_size); + scene_txt_set_font(scn, OBJ_POINTER, NULL, font_size); + for (i = 0; i < priv->num_bootflows; i++) { + ret = scene_txt_set_font(scn, ITEM_DESC + i, NULL, +font_size); + if (ret) + return log_msg_ret("des", ret); + scene_txt_set_font(scn, ITEM_KEY + i, NULL, font_size); + scene_txt_set_font(scn, ITEM_LABEL + i, NULL, + font_size); + } + } + + ret = scene_arrange(scn); + if (ret) + return log_msg_ret("arr", ret); + + return 0; +} + int bootflow_menu_run(struct bootstd_priv *std, bool text_mode, struct bootflow **bflowp) { @@ -149,6 +186,12 @@ int bootflow_menu_run(struct bootstd_priv *std, bool text_mode, if (ret) return log_msg_ret("exp", ret); + if (ofnode_valid(std->theme)) { + ret = bootflow_menu_apply_theme(exp, std->theme); + if (ret) + return log_msg_ret("thm", ret); + } + /* For now we only support a video console */ ret = uclass_first_device_err(UCLASS_VIDEO, &dev); if (ret) diff --git a/boot/bootstd-uclass.c b/boot/bootstd-uclass.c index 565c22a36e7..7887acdc11b 100644 --- a/boot/bootstd-uclass.c +++ b/boot/bootstd-uclass.c @@ -33,6 +33,8 @@ static int bootstd_of_to_plat(struct udevice *dev) &priv->prefixes); dev_read_string_list(dev, "bootdev-order", &priv->bootdev_order); + + priv->theme = ofnode_find_subnode(dev_ofnode(dev), "theme"); } return 0; diff --git a/include/bootflow.h b/include/bootflow.h index e7a09568f1b..c201246c6de 100644 --- a/include/bootflow.h +++ b/include/bootflow.h @@ -7,6 +7,7 @@ #ifndef __bootflow_h #define __bootflow_h +#include #include struct bootstd_priv; @@ -347,6 +348,15 @@ int bootflow_iter_uses_system(const struct bootflow_iter *iter); */ int bootflow_menu_new(struct expo **expp); +/** + * bootflow_menu_apply_theme() - Apply a theme to a bootmenu + * + * @exp: Expo to update + * @node: Node containing the theme information + * Returns 0 on success, -ve on error + */ +int bootflow_menu_apply_theme(struct expo *exp, ofnode node); + /** * bootflow_menu_run() - Create and run a menu of available bootflows * diff --git a/include/bootstd.h b/include/bootstd.h index 01be249d16e..4fa0d531001 100644 --- a/include/bootstd.h +++ b/include/bootstd.h @@ -9,6 +9,8 @@ #ifndef __bootstd_h #define __bootstd_h +#include + struct udevice; /** @@ -27,6 +29,7 @@ struct udevice; * @bootmeth_count: Number of bootmeth devices in @bootmeth_order * @bootmeth_order: List of bootmeth devices to use, in order, NULL-terminated * @vbe_bootmeth: Currently selected VBE bootmeth, NULL if none + * @theme: Node containing the theme information */ struct bootstd_priv { const char **prefixes; @@ -37,6 +40,7 @@ struct bootstd_priv { int bootmeth_count; struct udevice **bootmeth_order; struct udevice *vbe_bootmeth; + ofnode theme; }; /** diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index abafa44b2ed..5b76cd3ab14 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef CONFIG_SANDBOX #include #endif @@ -21,6 +22,8 @@ #include #include #include "bootstd_common.h" +#include "../../boot/bootflow_internal.h" +#include "../..
[PATCH v3 21/25] expo: Add basic tests
Add some tests for the expo, including setting up and rendering an expo. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Drop the _add suffix on expo creation function - Put strings in a separate structure referenced by ID test/boot/Makefile | 2 + test/boot/expo.c | 539 + 2 files changed, 541 insertions(+) create mode 100644 test/boot/expo.c diff --git a/test/boot/Makefile b/test/boot/Makefile index d724629d3b0..22ed61c8fa0 100644 --- a/test/boot/Makefile +++ b/test/boot/Makefile @@ -5,6 +5,8 @@ obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o obj-$(CONFIG_FIT) += image.o +obj-$(CONFIG_EXPO) += expo.o + ifdef CONFIG_OF_LIVE obj-$(CONFIG_BOOTMETH_VBE_SIMPLE) += vbe_simple.o endif diff --git a/test/boot/expo.c b/test/boot/expo.c new file mode 100644 index 000..7104dff05e8 --- /dev/null +++ b/test/boot/expo.c @@ -0,0 +1,539 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "bootstd_common.h" +#include "../../boot/scene_internal.h" + +enum { + /* scenes */ + SCENE1 = 7, + SCENE2, + + /* objects */ + OBJ_LOGO, + OBJ_TEXT, + OBJ_TEXT2, + OBJ_MENU, + OBJ_MENU_TITLE, + + /* strings */ + STR_TEXT, + STR_TEXT2, + STR_MENU_TITLE, + STR_POINTER_TEXT, + + STR_ITEM1_LABEL, + STR_ITEM1_DESC, + STR_ITEM1_KEY, + STR_ITEM1_PREVIEW, + + STR_ITEM2_LABEL, + STR_ITEM2_DESC, + STR_ITEM2_KEY, + STR_ITEM2_PREVIEW, + + /* menu items */ + ITEM1, + ITEM1_LABEL, + ITEM1_DESC, + ITEM1_KEY, + ITEM1_PREVIEW, + + ITEM2, + ITEM2_LABEL, + ITEM2_DESC, + ITEM2_KEY, + ITEM2_PREVIEW, + + /* pointer to current item */ + POINTER_TEXT, +}; + +#define BAD_POINTER((void *)1) + +/* names for various things */ +#define EXPO_NAME "my menus" +#define SCENE_NAME1"main" +#define SCENE_NAME2"second" +#define SCENE_TITLE"Main Menu" +#define LOGO_NAME "logo" + +/* Check base expo support */ +static int expo_base(struct unit_test_state *uts) +{ + struct udevice *dev; + struct expo *exp; + ulong start_mem; + char name[100]; + int i; + + ut_assertok(uclass_first_device_err(UCLASS_VIDEO, &dev)); + + start_mem = ut_check_free(); + + exp = NULL; + strcpy(name, EXPO_NAME); + ut_assertok(expo_new(name, NULL, &exp)); + *name = '\0'; + ut_assertnonnull(exp); + ut_asserteq(0, exp->scene_id); + ut_asserteq(0, exp->next_id); + + /* Make sure the name was allocated */ + ut_assertnonnull(exp->name); + ut_asserteq_str(EXPO_NAME, exp->name); + + ut_assertok(expo_set_display(exp, dev)); + expo_destroy(exp); + ut_assertok(ut_check_delta(start_mem)); + + /* test handling out-of-memory conditions */ + for (i = 0; i < 2; i++) { + struct expo *exp2; + + malloc_enable_testing(i); + exp2 = BAD_POINTER; + ut_asserteq(-ENOMEM, expo_new(EXPO_NAME, NULL, &exp2)); + ut_asserteq_ptr(BAD_POINTER, exp2); + malloc_disable_testing(); + } + + return 0; +} +BOOTSTD_TEST(expo_base, UT_TESTF_DM | UT_TESTF_SCAN_FDT); + +/* Check creating a scene */ +static int expo_scene(struct unit_test_state *uts) +{ + struct scene *scn; + struct expo *exp; + ulong start_mem; + char name[100]; + int id; + + start_mem = ut_check_free(); + + ut_assertok(expo_new(EXPO_NAME, NULL, &exp)); + + scn = NULL; + ut_asserteq(0, exp->next_id); + strcpy(name, SCENE_NAME1); + id = scene_new(exp, name, SCENE1, &scn); + *name = '\0'; + ut_assertnonnull(scn); + ut_asserteq(SCENE1, id); + ut_asserteq(SCENE1 + 1, exp->next_id); + ut_asserteq_ptr(exp, scn->expo); + + /* Make sure the name was allocated */ + ut_assertnonnull(scn->name); + ut_asserteq_str(SCENE_NAME1, scn->name); + + /* Set the title */ + strcpy(name, SCENE_TITLE); + ut_assertok(scene_title_set(scn, name)); + *name = '\0'; + ut_assertnonnull(scn->title); + ut_asserteq_str(SCENE_TITLE, scn->title); + + /* Use an allocated ID */ + scn = NULL; + id = scene_new(exp, SCENE_NAME2, 0, &scn); + ut_assertnonnull(scn); + ut_asserteq(SCENE2, id); + ut_asserteq(SCENE2 + 1, exp->next_id); + ut_asserteq_ptr(exp, scn->expo); + + ut_asserteq_str(SCENE_NAME2, scn->name); + + expo_destroy(exp); + + ut_assertok(ut_check_delta(start_mem)); + + return 0; +} +BOOTSTD_TEST(expo_scene, UT_TESTF_DM | UT_TESTF_SCAN_FDT); + +/* Check creating a
[PATCH v3 25/25] expo: Add documentation
Add some documentation for the expo feature. Signed-off-by: Simon Glass --- Changes in v3: - Rebase to master Changes in v2: - Update for new API doc/develop/expo.rst | 188 ++ doc/develop/index.rst | 1 + 2 files changed, 189 insertions(+) create mode 100644 doc/develop/expo.rst diff --git a/doc/develop/expo.rst b/doc/develop/expo.rst new file mode 100644 index 000..32dd7f09030 --- /dev/null +++ b/doc/develop/expo.rst @@ -0,0 +1,188 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Expo menu += + +U-Boot provides a menu implementation for use with selecting bootflows and +changing U-Boot settings. This is in early stages of development. + +Motivation +-- + +U-Boot already has a text-based menu system accessed via the +:doc:`../usage/cmd/bootmenu`. This works using environment variables, or via +some EFI-specific hacks. + +The command makes use of a lower-level `menu` implementation, which is quite +flexible and can be used to make menu hierarchies. + +However this system is not flexible enough for use with standard boot. It does +not support a graphical user interface and cannot currently support anything +more than a very simple list of items. While it does support multiple menus in +hierarchies, these are implemented by the caller. See for example `eficonfig.c`. + +Another challenge with the current menu implementation is that it controls +the event loop, such that bootmenu_loop() does not return until a key is +pressed. This makes it difficult to implement dynamic displays or to do other +things while the menu is running, such as searching for more bootflows. + +For these reasons an attempt has been made to develop a more flexible system +which can handle menus as well as other elements. This is called 'expo', short +for exposition, in an attempt to avoid common words like display, screen, menu +and the like. The primary goal is to support Verified Boot for Embedded (VBE), +although it is available to any boot method, using the 'bootflow menu' command. + +Efforts have been made to use common code with the existing menu, including +key processing in particular. + +Previous work looked at integrating Nuklear into U-Boot. This works fine and +could provide a way to provide a more flexible UI, perhaps with expo dealing +with the interface to Nuklear. But this is quite a big step and it may be years +before this becomes desirable, if at all. For now, U-Boot only needs a fairly +simple set of menus and options, so rendering them directly is fairly +straightforward. + +Concepts + + +The creator of the expo is here called a `controller` and it controls most +aspects of the expo. This is the code that you must write to use expo. + +An `expo` is a set of scenes which can be presented to the user one at a time, +to show information and obtain input from the user. + +A `scene` is a collection of objects which are displayed together on the screen. +Only one scene is visible at a time and scenes do not share objects. + +A `scene object` is something that appears in the scene, such as some text, an +image or a menu. Objects can be positioned and hidden. + +A `menu object` contains a title, a set of `menu items` and a pointer to the +current item. Menu items consist of a keypress (indicating what to press to +select the item), label and description. All three are shown in a single line +within the menu. Items can also have a preview image, which is shown when the +item is highlighted. + +All components have a name. This is purely for debugging, so it is easy to see +what object is referred to. Of course the ID numbers can help as well, but they +are less easy to distinguish. + +While the expo implementation provides support for handling keypresses and +rendering on the display or serial port, it does not actually deal with reading +input from the user, nor what should be done when a particular menu item is +selected. This is deliberate since having the event loop outside the expo is +more flexible, particularly in a single-threaded environment like U-Boot. + +Everything within an expo has a unique ID number. This is done so that it is +easy to refer to things after the expo has been created. The expectation is that +the controller declares an enum containing all of the elements in the expo, +passing the ID of each object as it is created. When a menu item is selected, +its ID is returned. When a object's font or position needs to change, the ID is +passed to expo functions to indicate which object it is. It is possible for expo +to auto-allocate IDs, but this is not recommended. The use of IDs is a +convenience, removing the need for the controller to store pointers to objects, +or even the IDs of objects. Programmatic creation of many items in a loop can be +handled by allocating space in the enum for a maximum number of items, then +adding the loop count to the enum values to obtain unique IDs. + +All text strings are stored in a struc
[PATCH v3 20/25] expo: Add support for scene menus
A menu is a key part of the expo design. It consists of a number of items which the user can select from. Add the initial implementation of this. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Drop the _add suffix on expo creation function - Put strings in a separate structure referenced by ID boot/Makefile | 2 + boot/scene_menu.c | 390 ++ 2 files changed, 392 insertions(+) create mode 100644 boot/scene_menu.c diff --git a/boot/Makefile b/boot/Makefile index f0c31549213..0b30fcd64a9 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -47,6 +47,8 @@ ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_LOAD_FIT) += common_fit.o endif +obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE) += expo.o scene.o scene_menu.o + obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE) += vbe.o vbe_request.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o diff --git a/boot/scene_menu.c b/boot/scene_menu.c new file mode 100644 index 000..18998e862ab --- /dev/null +++ b/boot/scene_menu.c @@ -0,0 +1,390 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Implementation of a menu in a scene + * + * Copyright 2022 Google LLC + * Written by Simon Glass + */ + +#define LOG_CATEGORY LOGC_BOOT + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "scene_internal.h" + +static void scene_menuitem_destroy(struct scene_menitem *item) +{ + free(item->name); + free(item); +} + +void scene_menu_destroy(struct scene_obj_menu *menu) +{ + struct scene_menitem *item, *next; + + list_for_each_entry_safe(item, next, &menu->item_head, sibling) + scene_menuitem_destroy(item); +} + +/** + * menu_point_to_item() - Point to a particular menu item + * + * Sets the currently pointed-to / highlighted menu item + */ +static void menu_point_to_item(struct scene_obj_menu *menu, uint item_id) +{ + menu->cur_item_id = item_id; +} + +int scene_menu_arrange(struct scene *scn, struct scene_obj_menu *menu) +{ + struct scene_menitem *item; + int y, cur_y; + int ret; + + y = menu->obj.y; + if (menu->title_id) { + ret = scene_obj_set_pos(scn, menu->title_id, menu->obj.x, y); + if (ret < 0) + return log_msg_ret("tit", ret); + + ret = scene_obj_get_hw(scn, menu->title_id, NULL); + if (ret < 0) + return log_msg_ret("hei", ret); + + y += ret * 2; + } + + /* +* Currently everything is hard-coded to particular columns so this +* won't work on small displays and looks strange if the font size is +* small. This can be updated once text measuring is supported in +* vidconsole +*/ + cur_y = -1; + list_for_each_entry(item, &menu->item_head, sibling) { + int height; + + ret = scene_obj_get_hw(scn, item->desc_id, NULL); + if (ret < 0) + return log_msg_ret("get", ret); + height = ret; + + if (item->flags & SCENEMIF_GAP_BEFORE) + y += height; + + /* select an item if not done already */ + if (!menu->cur_item_id) + menu_point_to_item(menu, item->id); + + /* +* Put the label on the left, then leave a space for the +* pointer, then the key and the description +*/ + if (item->label_id) { + ret = scene_obj_set_pos(scn, item->label_id, menu->obj.x, + y); + if (ret < 0) + return log_msg_ret("nam", ret); + } + + ret = scene_obj_set_pos(scn, item->key_id, menu->obj.x + 230, + y); + if (ret < 0) + return log_msg_ret("key", ret); + + ret = scene_obj_set_pos(scn, item->desc_id, menu->obj.x + 280, + y); + if (ret < 0) + return log_msg_ret("des", ret); + + if (menu->cur_item_id == item->id) + cur_y = y; + + if (item->preview_id) { + bool hide; + + /* +* put all previews on top of each other, on the right +* size of the display +*/ + ret = scene_obj_set_pos(scn, item->preview_id, -4, y); + if (ret < 0) + return log_msg_ret("prev", ret); + + hide = menu->cur_item_id != item->id; + ret = scene_obj_set_hide(scn, item->preview_id, hide); +
[PATCH v3 23/25] bootstd: Add a test for the bootstd menu
Add a test which checks that two operating systems can be displayed in a menu, allowing one to be selected. Enable a few things on snow so that the unit tests build. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Fix 'touse' typo - Fix pylint warning in mkdir_cond() arch/sandbox/dts/test.dts| 11 ++ configs/snow_defconfig | 4 + test/boot/bootflow.c | 51 +++ test/py/tests/bootstd/armbian.bmp.xz | Bin 0 -> 1384 bytes test/py/tests/bootstd/mmc4.img.xz| Bin 0 -> 7072 bytes test/py/tests/test_ut.py | 218 --- 6 files changed, 265 insertions(+), 19 deletions(-) create mode 100644 test/py/tests/bootstd/armbian.bmp.xz create mode 100644 test/py/tests/bootstd/mmc4.img.xz diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index dffe10adbf4..2e580f980fc 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -94,6 +94,10 @@ compatible = "u-boot,distro-efi"; }; + theme { + font-size = <30>; + }; + /* * This is used for the VBE OS-request tests. A FAT filesystem * created in a partition with the VBE information appearing @@ -1013,6 +1017,13 @@ non-removable; }; + /* This is used for bootstd bootmenu tests */ + mmc4 { + status = "disabled"; + compatible = "sandbox,mmc"; + filename = "mmc4.img"; + }; + pch { compatible = "sandbox,pch"; }; diff --git a/configs/snow_defconfig b/configs/snow_defconfig index 6921c5667da..faa3a944c02 100644 --- a/configs/snow_defconfig +++ b/configs/snow_defconfig @@ -28,7 +28,11 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x205 CONFIG_FIT=y CONFIG_FIT_BEST_MATCH=y +CONFIG_BOOTSTD_FULL=y CONFIG_SILENT_CONSOLE=y +CONFIG_BLOBLIST=y +# CONFIG_SPL_BLOBLIST is not set +CONFIG_BLOBLIST_ADDR=0x43d0 # CONFIG_SPL_FRAMEWORK is not set CONFIG_SPL_FOOTPRINT_LIMIT=y CONFIG_SPL_MAX_FOOTPRINT=0x3800 diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index 00dfd990687..abafa44b2ed 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -11,15 +11,21 @@ #include #include #include +#include #include #ifdef CONFIG_SANDBOX #include #endif +#include #include #include #include #include "bootstd_common.h" +DECLARE_GLOBAL_DATA_PTR; + +extern U_BOOT_DRIVER(bootmeth_script); + static int inject_response(struct unit_test_state *uts) { /* @@ -462,3 +468,48 @@ static int bootflow_cmd_boot(struct unit_test_state *uts) return 0; } BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM | UT_TESTF_SCAN_FDT); + +/* Check 'bootflow menu' to select a bootflow */ +static int bootflow_cmd_menu(struct unit_test_state *uts) +{ + static const char *order[] = {"mmc2", "mmc1", "mmc4", NULL}; + struct udevice *dev, *bootstd; + struct bootstd_priv *std; + const char **old_order; + char prev[3]; + ofnode node; + + /* Enable the mmc4 node since we need a second bootflow */ + node = ofnode_path("/mmc4"); + ut_assertok(lists_bind_fdt(gd->dm_root, node, &dev, NULL, false)); + + /* Enable the script bootmeth too */ + ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, &bootstd)); + ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_script), + "bootmeth_script", 0, ofnode_null(), &dev)); + + /* Change the order to include mmc4 */ + std = dev_get_priv(bootstd); + old_order = std->bootdev_order; + std->bootdev_order = order; + + console_record_reset_enable(); + ut_assertok(run_command("bootflow scan", 0)); + ut_assert_console_end(); + + /* Restore the order used by the device tree */ + std->bootdev_order = old_order; + + /* Add keypresses to move to and select the second one in the list */ + prev[0] = CTL_CH('n'); + prev[1] = '\r'; + prev[2] = '\0'; + ut_asserteq(2, console_in_puts(prev)); + + ut_assertok(run_command("bootflow menu", 0)); + ut_assert_nextline("Selected: Armbian"); + ut_assert_console_end(); + + return 0; +} +BOOTSTD_TEST(bootflow_cmd_menu, UT_TESTF_DM | UT_TESTF_SCAN_FDT); diff --git a/test/py/tests/bootstd/armbian.bmp.xz b/test/py/tests/bootstd/armbian.bmp.xz new file mode 100644 index ..ad137ea6e6df5c51d0a98a4be190c4cb4c48fc76 GIT binary patch literal 1384 zcmV-u1(*8$H+ooF000E$*0e?f03iV!G&sfahT|osUT>v2yL`vV4GWns~_Xm1L zxE>Ubk@J6u_+aW`8~-8B2G301rYP}LjG-Uj!5v5M@cMEp)w7Jy+>!JE+yYjbr*Cj;GV^2Hw z@W7BuO=bDneVey~z?{IPxUWVi=>AB+fXkNrMXePTCtS4$20)TF&Ej-}em=4#*uIHD z1l@)}!B8#S*Y2}K?!cbS0x0Q6+%GVl9r84w9-r^ww#S)^#5L%?tS_gQGFqN4x0;M* z069Xd{Tg$MBJXPB3ZuxY@@+^>NZzLHs%(t8LBUGbn8_tB+-cv$
[PATCH v3 08/25] menu: Make use of CLI character processing
Avoid duplicating some of the escape-sequence processing here and use the CLI function instead. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Rebase to master cmd/bootmenu.c | 9 +++-- cmd/eficonfig.c| 12 -- common/cli_getch.c | 12 -- common/menu.c | 92 +- include/cli.h | 4 +- include/menu.h | 7 +++- 6 files changed, 56 insertions(+), 80 deletions(-) diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index 573afe16609..52d8c2f266d 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -4,6 +4,7 @@ */ #include +#include #include #include #include @@ -84,19 +85,21 @@ static void bootmenu_print_entry(void *data) static char *bootmenu_choice_entry(void *data) { + struct cli_ch_state s_cch, *cch = &s_cch; struct bootmenu_data *menu = data; struct bootmenu_entry *iter; enum bootmenu_key key = BKEY_NONE; - int esc = 0; int i; + cli_ch_init(cch); + while (1) { if (menu->delay >= 0) { /* Autoboot was not stopped */ - key = bootmenu_autoboot_loop(menu, &esc); + key = bootmenu_autoboot_loop(menu, cch); } else { /* Some key was pressed, so autoboot was stopped */ - key = bootmenu_loop(menu, &esc); + key = bootmenu_loop(menu, cch); } switch (key) { diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c index 96cb1a367f3..d830e4af53b 100644 --- a/cmd/eficonfig.c +++ b/cmd/eficonfig.c @@ -6,6 +6,7 @@ */ #include +#include #include #include #include @@ -184,14 +185,16 @@ static void eficonfig_display_statusline(struct menu *m) */ static char *eficonfig_choice_entry(void *data) { - int esc = 0; + struct cli_ch_state s_cch, *cch = &s_cch; struct list_head *pos, *n; struct eficonfig_entry *entry; enum bootmenu_key key = BKEY_NONE; struct efimenu *efi_menu = data; + cli_ch_init(cch); + while (1) { - key = bootmenu_loop((struct bootmenu_data *)efi_menu, &esc); + key = bootmenu_loop((struct bootmenu_data *)efi_menu, cch); switch (key) { case BKEY_UP: @@ -1862,13 +1865,14 @@ static void eficonfig_display_change_boot_order(struct efimenu *efi_menu) */ static efi_status_t eficonfig_choice_change_boot_order(struct efimenu *efi_menu) { - int esc = 0; + struct cli_ch_state s_cch, *cch = &s_cch; struct list_head *pos, *n; enum bootmenu_key key = BKEY_NONE; struct eficonfig_entry *entry, *tmp; + cli_ch_init(cch); while (1) { - key = bootmenu_loop(NULL, &esc); + key = bootmenu_loop(NULL, cch); switch (key) { case BKEY_PLUS: diff --git a/common/cli_getch.c b/common/cli_getch.c index 9eeea7fef29..87c23edcf4b 100644 --- a/common/cli_getch.c +++ b/common/cli_getch.c @@ -140,10 +140,11 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar) * sequence */ if (!ichar) { - if (cch->emit_upto) { + if (cch->emitting) { if (cch->emit_upto < cch->esc_len) return cch->esc_save[cch->emit_upto++]; cch->emit_upto = 0; + cch->emitting = false; } return 0; } else if (ichar == -ETIMEDOUT) { @@ -174,18 +175,21 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar) case ESC_SAVE: /* save this character and return nothing */ cch->esc_save[cch->esc_len++] = ichar; - return 0; + ichar = 0; + break; case ESC_REJECT: /* * invalid escape sequence, start returning the * characters in it */ cch->esc_save[cch->esc_len++] = ichar; - return cch->esc_save[cch->emit_upto++]; + ichar = cch->esc_save[cch->emit_upto++]; + cch->emitting = true; + break; case ESC_CONVERTED: /* valid escape sequence, return the resulting char */ cch->esc_len = 0; - return ichar; + break; } } diff --git a/common/menu.c b/common/menu.c index 7db98942a61..45f36ae3ede 100644 --- a/common/menu.c +++ b/common/menu.c @@ -15,6 +15,8 @@ #include "menu.h" +#define ansi 0 + /* * Internally, each item in a menu is represented by a struct menu_item. * @@ -425,15 +427,19 @@ int menu_destroy(str
[PATCH v3 02/25] cli: Move readline character-processing to a state machine
The current cread_line() function is very long. It handles the escape processing inline. The menu command does similar processing but at the character level, so there is some duplication. Split the character processing into a new function cli_ch_process() which processes individual characters and returns the resulting input character, taking account of escape sequences. It requires the caller to set up and maintain its state. Update cread_line() to use this new function. The only intended functional change is that an invalid escape sequence does not add invalid/control characters into the input buffer, but instead discards these. Signed-off-by: Simon Glass --- (no changes since v1) common/Makefile | 6 +- common/cli_getch.c| 204 ++ common/cli_readline.c | 150 +-- include/cli.h | 72 +++ 4 files changed, 301 insertions(+), 131 deletions(-) create mode 100644 common/cli_getch.c diff --git a/common/Makefile b/common/Makefile index 20addfb244c..67485e77a04 100644 --- a/common/Makefile +++ b/common/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_SPLASH_SOURCE) += splash_source.o obj-$(CONFIG_MENU) += menu.o obj-$(CONFIG_UPDATE_COMMON) += update.o obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o -obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o +obj-$(CONFIG_CMDLINE) += cli_getch.o cli_readline.o cli_simple.o endif # !CONFIG_SPL_BUILD @@ -93,8 +93,8 @@ obj-y += eeprom/eeprom_field.o eeprom/eeprom_layout.o endif obj-y += cli.o -obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o -obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_simple.o cli_readline.o +obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o +obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o obj-$(CONFIG_DFU_OVER_USB) += dfu.o obj-y += command.o obj-$(CONFIG_$(SPL_TPL_)LOG) += log.o diff --git a/common/cli_getch.c b/common/cli_getch.c new file mode 100644 index 000..9eeea7fef29 --- /dev/null +++ b/common/cli_getch.c @@ -0,0 +1,204 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2000 + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. + * + * Copyright 2022 Google LLC + */ + +#include +#include + +/** + * enum cli_esc_state_t - indicates what to do with an escape character + * + * @ESC_REJECT: Invalid escape sequence, so the esc_save[] characters are + * returned from each subsequent call to cli_ch_esc() + * @ESC_SAVE: Character should be saved in esc_save until we have another one + * @ESC_CONVERTED: Escape sequence has been completed and the resulting + * character is available + */ +enum cli_esc_state_t { + ESC_REJECT, + ESC_SAVE, + ESC_CONVERTED +}; + +void cli_ch_init(struct cli_ch_state *cch) +{ + memset(cch, '\0', sizeof(*cch)); +} + +/** + * cli_ch_esc() - Process a character in an ongoing escape sequence + * + * @cch: State information + * @ichar: Character to process + * @actp: Returns the action to take + * Returns: Output character if *actp is ESC_CONVERTED, else 0 + */ +static int cli_ch_esc(struct cli_ch_state *cch, int ichar, + enum cli_esc_state_t *actp) +{ + enum cli_esc_state_t act = ESC_REJECT; + + switch (cch->esc_len) { + case 1: + if (ichar == '[' || ichar == 'O') + act = ESC_SAVE; + break; + case 2: + switch (ichar) { + case 'D': /* <- key */ + ichar = CTL_CH('b'); + act = ESC_CONVERTED; + break; /* pass off to ^B handler */ + case 'C': /* -> key */ + ichar = CTL_CH('f'); + act = ESC_CONVERTED; + break; /* pass off to ^F handler */ + case 'H': /* Home key */ + ichar = CTL_CH('a'); + act = ESC_CONVERTED; + break; /* pass off to ^A handler */ + case 'F': /* End key */ + ichar = CTL_CH('e'); + act = ESC_CONVERTED; + break; /* pass off to ^E handler */ + case 'A': /* up arrow */ + ichar = CTL_CH('p'); + act = ESC_CONVERTED; + break; /* pass off to ^P handler */ + case 'B': /* down arrow */ + ichar = CTL_CH('n'); + act = ESC_CONVERTED; + break; /* pass off to ^N handler */ + case '1': + case '2': + case '3': + case '4': + case '7': + case '8': + if (cch->esc_save[1] == '[') { + /* see if next character is ~ */ +
[PATCH v3 04/25] menu: Rename KEY_... to BKEY_...
This enum values conflict with linux/input.h so rename them. Signed-off-by: Simon Glass --- (no changes since v1) cmd/bootmenu.c | 10 +- cmd/eficonfig.c | 26 +- common/menu.c | 34 +- include/menu.h | 32 4 files changed, 51 insertions(+), 51 deletions(-) diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index 3340be16325..c80004c54dc 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -86,7 +86,7 @@ static char *bootmenu_choice_entry(void *data) { struct bootmenu_data *menu = data; struct bootmenu_entry *iter; - enum bootmenu_key key = KEY_NONE; + enum bootmenu_key key = BKEY_NONE; int esc = 0; int i; @@ -100,22 +100,22 @@ static char *bootmenu_choice_entry(void *data) } switch (key) { - case KEY_UP: + case BKEY_UP: if (menu->active > 0) --menu->active; /* no menu key selected, regenerate menu */ return NULL; - case KEY_DOWN: + case BKEY_DOWN: if (menu->active < menu->count - 1) ++menu->active; /* no menu key selected, regenerate menu */ return NULL; - case KEY_SELECT: + case BKEY_SELECT: iter = menu->first; for (i = 0; i < menu->active; ++i) iter = iter->next; return iter->key; - case KEY_QUIT: + case BKEY_QUIT: /* Quit by choosing the last entry - U-Boot console */ iter = menu->first; while (iter->next) diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c index ce7175a5666..8f246bc271f 100644 --- a/cmd/eficonfig.c +++ b/cmd/eficonfig.c @@ -187,31 +187,31 @@ static char *eficonfig_choice_entry(void *data) int esc = 0; struct list_head *pos, *n; struct eficonfig_entry *entry; - enum bootmenu_key key = KEY_NONE; + enum bootmenu_key key = BKEY_NONE; struct efimenu *efi_menu = data; while (1) { bootmenu_loop((struct bootmenu_data *)efi_menu, &key, &esc); switch (key) { - case KEY_UP: + case BKEY_UP: if (efi_menu->active > 0) --efi_menu->active; /* no menu key selected, regenerate menu */ return NULL; - case KEY_DOWN: + case BKEY_DOWN: if (efi_menu->active < efi_menu->count - 1) ++efi_menu->active; /* no menu key selected, regenerate menu */ return NULL; - case KEY_SELECT: + case BKEY_SELECT: list_for_each_safe(pos, n, &efi_menu->list) { entry = list_entry(pos, struct eficonfig_entry, list); if (entry->num == efi_menu->active) return entry->key; } break; - case KEY_QUIT: + case BKEY_QUIT: /* Quit by choosing the last entry */ entry = list_last_entry(&efi_menu->list, struct eficonfig_entry, list); return entry->key; @@ -1864,14 +1864,14 @@ static efi_status_t eficonfig_choice_change_boot_order(struct efimenu *efi_menu) { int esc = 0; struct list_head *pos, *n; - enum bootmenu_key key = KEY_NONE; + enum bootmenu_key key = BKEY_NONE; struct eficonfig_entry *entry, *tmp; while (1) { bootmenu_loop(NULL, &key, &esc); switch (key) { - case KEY_PLUS: + case BKEY_PLUS: if (efi_menu->active > 0) { list_for_each_safe(pos, n, &efi_menu->list) { entry = list_entry(pos, struct eficonfig_entry, list); @@ -1885,11 +1885,11 @@ static efi_status_t eficonfig_choice_change_boot_order(struct efimenu *efi_menu) list_add(&tmp->list, &entry->list); } fallthrough; - case KEY_UP: + case BKEY_UP: if (efi_menu->active > 0) --efi_menu->active; return EFI_NOT_READY; - case KEY_MINUS: + case BKEY_MINUS: if (efi_menu->active < efi_menu->count - 3) { list_for_each
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
On 1/6/23 10:13, Patrick DELAUNAY wrote: Hi, Hi, For me: get_effective_memsize() must return the effective size of the DDR and NOT -4KiB to avoid side effects in other part of the code (LMB for example) I think today we need to revert your patch. I agree it would be good to revert the patch for the v2023.01 release , and then re-add it once all the issues it triggers are explained or resolved in satisfactory manner.
[PATCH v3 13/25] video: Fix unchnaged typo
Fix this typo in the header file. Signed-off-by: Simon Glass Reviewed-by: Heinrich Schuchardt --- (no changes since v1) include/video.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/video.h b/include/video.h index 43f2e2c02f0..3f67a93bc93 100644 --- a/include/video.h +++ b/include/video.h @@ -248,7 +248,7 @@ void video_bmp_get_info(void *bmp_image, ulong *widthp, ulong *heightp, * that direction * - if a coordinate is -ve then it will be offset to the * left/top of the centre by that many pixels - * - if a coordinate is positive it will be used unchnaged. + * - if a coordinate is positive it will be used unchanged. * Return: 0 if OK, -ve on error */ int video_bmp_display(struct udevice *dev, ulong bmp_image, int x, int y, -- 2.39.0.314.g84b9a713c41-goog
Re: [PATCH 1/2] efi_loader: refine set_keyboard_layout() status
On 1/6/23 10:46, Vincent Stehlé wrote: As per the EFI specification, the HII database protocol function set_keyboard_layout() must return EFI_INVALID_PARAMETER when it is called with a NULL key_guid argument. Modify the function accordingly to improve conformance. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt Cc: Ilias Apalodimas --- lib/efi_loader/efi_hii.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c index 27db3be6a17..3b54ecb11ac 100644 --- a/lib/efi_loader/efi_hii.c +++ b/lib/efi_loader/efi_hii.c @@ -758,6 +758,9 @@ set_keyboard_layout(const struct efi_hii_database_protocol *this, { EFI_ENTRY("%p, %pUs", this, key_guid); + if (!key_guid) + return EFI_EXIT(EFI_INVALID_PARAMETER); This is just suppressing an SCT warning for an unimplemented function. I think we should complete the implementation of the HII protocols instead of trying to hide the deficiency. Best regards Heinrich + return EFI_EXIT(EFI_NOT_FOUND); }
Re: [PATCH v3 02/25] cli: Move readline character-processing to a state machine
On 1/6/23 15:52, Simon Glass wrote: The current cread_line() function is very long. It handles the escape processing inline. The menu command does similar processing but at the character level, so there is some duplication. Split the character processing into a new function cli_ch_process() which processes individual characters and returns the resulting input character, taking account of escape sequences. It requires the caller to set up and maintain its state. Update cread_line() to use this new function. The only intended functional change is that an invalid escape sequence does not add invalid/control characters into the input buffer, but instead discards these. Signed-off-by: Simon Glass --- (no changes since v1) common/Makefile | 6 +- common/cli_getch.c| 204 ++ common/cli_readline.c | 150 +-- include/cli.h | 72 +++ 4 files changed, 301 insertions(+), 131 deletions(-) create mode 100644 common/cli_getch.c diff --git a/common/Makefile b/common/Makefile index 20addfb244c..67485e77a04 100644 --- a/common/Makefile +++ b/common/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_SPLASH_SOURCE) += splash_source.o obj-$(CONFIG_MENU) += menu.o obj-$(CONFIG_UPDATE_COMMON) += update.o obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o -obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o +obj-$(CONFIG_CMDLINE) += cli_getch.o cli_readline.o cli_simple.o endif # !CONFIG_SPL_BUILD @@ -93,8 +93,8 @@ obj-y += eeprom/eeprom_field.o eeprom/eeprom_layout.o endif obj-y += cli.o -obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o -obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_simple.o cli_readline.o +obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o +obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o obj-$(CONFIG_DFU_OVER_USB) += dfu.o obj-y += command.o obj-$(CONFIG_$(SPL_TPL_)LOG) += log.o diff --git a/common/cli_getch.c b/common/cli_getch.c new file mode 100644 index 000..9eeea7fef29 --- /dev/null +++ b/common/cli_getch.c @@ -0,0 +1,204 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2000 + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. + * + * Copyright 2022 Google LLC + */ + +#include +#include + +/** + * enum cli_esc_state_t - indicates what to do with an escape character + * + * @ESC_REJECT: Invalid escape sequence, so the esc_save[] characters are + * returned from each subsequent call to cli_ch_esc() + * @ESC_SAVE: Character should be saved in esc_save until we have another one + * @ESC_CONVERTED: Escape sequence has been completed and the resulting + * character is available + */ +enum cli_esc_state_t { + ESC_REJECT, + ESC_SAVE, + ESC_CONVERTED +}; + +void cli_ch_init(struct cli_ch_state *cch) +{ + memset(cch, '\0', sizeof(*cch)); +} + +/** + * cli_ch_esc() - Process a character in an ongoing escape sequence + * + * @cch: State information + * @ichar: Character to process + * @actp: Returns the action to take + * Returns: Output character if *actp is ESC_CONVERTED, else 0 + */ +static int cli_ch_esc(struct cli_ch_state *cch, int ichar, + enum cli_esc_state_t *actp) +{ + enum cli_esc_state_t act = ESC_REJECT; + + switch (cch->esc_len) { + case 1: + if (ichar == '[' || ichar == 'O') + act = ESC_SAVE; + break; + case 2: + switch (ichar) { + case 'D': /* <- key */ + ichar = CTL_CH('b'); + act = ESC_CONVERTED; + break; /* pass off to ^B handler */ + case 'C': /* -> key */ + ichar = CTL_CH('f'); + act = ESC_CONVERTED; + break; /* pass off to ^F handler */ + case 'H': /* Home key */ + ichar = CTL_CH('a'); + act = ESC_CONVERTED; + break; /* pass off to ^A handler */ + case 'F': /* End key */ + ichar = CTL_CH('e'); + act = ESC_CONVERTED; + break; /* pass off to ^E handler */ + case 'A': /* up arrow */ + ichar = CTL_CH('p'); + act = ESC_CONVERTED; + break; /* pass off to ^P handler */ + case 'B': /* down arrow */ + ichar = CTL_CH('n'); + act = ESC_CONVERTED; + break; /* pass off to ^N handler */ + case '1': + case '2': + case '3': + case '4': + case '7': + case '8': + if (cch->esc_save[1] == '[') { + /* see if nex
[PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
This reverts commit 777706bcfe08c284aed06886db7d482af3f8. The changes to this generic function, which is intended to help with 32bit platforms with large amounts of memory has unintended side effects (which in turn lead to boot failures) on other platforms which were previously functional. Reported-by: Marek Vasut Cc: Patrick Delaunay Cc: Pali Rohár Signed-off-by: Tom Rini --- common/memsize.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/common/memsize.c b/common/memsize.c index 3c80ad2c8346..31884acca0df 100644 --- a/common/memsize.c +++ b/common/memsize.c @@ -94,23 +94,11 @@ long get_ram_size(long *base, long maxsize) phys_size_t __weak get_effective_memsize(void) { - phys_size_t ram_size = gd->ram_size; - - /* -* Check for overflow and limit ram size to some representable value. -* It is required that ram_base + ram_size must be representable by -* phys_size_t type and must be aligned by direct access, therefore -* calculate it from last 4kB sector which should work as alignment -* on any platform. -*/ - if (gd->ram_base + ram_size < gd->ram_base) - ram_size = ((phys_size_t)~0xfffULL) - gd->ram_base; - #ifndef CONFIG_MAX_MEM_MAPPED - return ram_size; + return gd->ram_size; #else /* limit stack to what we can reasonable map */ - return ((ram_size > CONFIG_MAX_MEM_MAPPED) ? - CONFIG_MAX_MEM_MAPPED : ram_size); + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ? + CONFIG_MAX_MEM_MAPPED : gd->ram_size); #endif } -- 2.25.1
Re: [PATCH v3 03/25] bootmenu: Add a few comments
On 1/6/23 15:52, Simon Glass wrote: The behaviour of these two functions is completely undocumented. Add some notes so the poor, suffering dev can figure out what is going on. Signed-off-by: Simon Glass --- (no changes since v1) include/menu.h | 42 ++ 1 file changed, 42 insertions(+) diff --git a/include/menu.h b/include/menu.h index 702aacb170c..0b4d9734149 100644 --- a/include/menu.h +++ b/include/menu.h @@ -42,6 +42,7 @@ struct bootmenu_data { struct bootmenu_entry *first; /* first menu entry */ }; +/** enum bootmenu_key - keys that can be returned by the bootmenu */ enum bootmenu_key { KEY_NONE = 0, KEY_UP, @@ -53,8 +54,49 @@ enum bootmenu_key { KEY_SPACE, }; +/** + * bootmenu_autoboot_loop() - handle autobooting if no key is pressed + * + * This shows a prompt to allow the user to press a key to interrupt auto boot + * of the first menu option. + * + * It then waits for the required time (menu->delay in seconds) for a key to be + * pressed. If nothing is pressed in that time, @key returns KEY_SELECT + * indicating that the current option should be chosen. + * + * @menu: Menu being processed + * @key: Returns the code for the key the user pressed: + * enter: KEY_SELECT + * Ctrl-C: KEY_QUIT + * anything else: KEY_NONE + * @esc: Set to 1 if the escape key is pressed, otherwise not updated + */ void bootmenu_autoboot_loop(struct bootmenu_data *menu, enum bootmenu_key *key, int *esc); + +/** + * bootmenu_loop() - handle waiting for a keypress when autoboot is disabled + * + * This is used when the menu delay is negative, indicating that the delay has + * elapsed, or there was no delay to begin with. + * + * It reads a character and processes it, returning a menu-key code if a + * character is recognised + * + * @menu: Menu being processed + * @key: Returns the code for the key the user pressed: + * enter: KEY_SELECT + * Ctrl-C: KEY_QUIT + * Up arrow: KEY_UP + * Down arrow: KEY_DOWN + * Escape (by itself): KEY_QUIT + * Plus: KEY_PLUS + * Minus: KEY_MINUS + * Space: KEY_SPACE + * @esc: On input, a non-zero value indicates that an escape sequence has + * resulted in that many characters so far. On exit this is updated to the + * new number of characters + */ void bootmenu_loop(struct bootmenu_data *menu, enum bootmenu_key *key, int *esc); This should not be an exported function. The program part that wants to display a menu should not have to deal with navigation keys. Best regards Heinrich
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
On Friday 06 January 2023 10:13:34 Patrick DELAUNAY wrote: > Hi, > > On 1/5/23 20:25, Pali Rohar wrote: > > Ok, so it is working... > > > > On Thursday 05 January 2023 19:31:19 Patrick DELAUNAY wrote: > > > I tested on STM32MP157C-EV1 on my side... > > > > > > with 1GiB mermory size > > > > > > U-Boot is booting on next TOP (for trusted boot with TF-A and OP-TEE) > > > > > > > > > > > > U-Boot 2023.01-rc4-00386-gb429e78942de (Jan 05 2023 - 17:44:04 +0100) > > > > > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) > > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) > > > CPU: STM32MP157C?? Rev.Z > > > Model: STMicroelectronics STM32MP157C eval daughter on eval mother > > > Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) > > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1) > > > DRAM: 1 GiB > > > > > > > > > > > > STM32MP> bdinfo > > > boot_params = 0x > > > DRAM bank = 0x > > > -> start = 0xc000 > > > -> size = 0x3000 << the patch is applied - 4kiB here > > > !!! > > But this is wrong. DRAM bank size should not be changed. I think that in > > U-Boot is another issue which propagates mapped U-Boot RAM size/range to > > the places where should be real DDR size. > > > Yes it is wrong > > and it is introduced by your patch... > > > in the STM32MP15x platfrorm are using the genric weak function > > > ./common/board_f.c:267 > > > __weak int dram_init_banksize(void) > { > gd->bd->bi_dram[0].start = gd->ram_base; > gd->bd->bi_dram[0].size = get_effective_memsize(); > > return 0; > } > > For me: > > get_effective_memsize() must return the effective size of the DDR > > and NOT -4KiB to avoid side effects in other part of the code (LMB for > example) Ok, this needs to be reworked. But seems it is not just simple issue. > > I think today we need to revert your patch. Hard revert without anything else is not the solution. As it will break all 36-bit powerpc boards with 4GB of DDR RAM on which is u-boot running in 32-bit mode.
Re: [PATCH v2] usb: gadget: fastboot: detach usb just before rebooting
On Thu, Jan 05, 2023 at 14:25, Dario Binacchi wrote: > Hi Mattijs, > > On Thu, Jan 5, 2023 at 12:03 PM Mattijs Korpershoek > wrote: >> >> On Thu, Jan 05, 2023 at 10:10, Dario Binacchi >> wrote: >> >> > Hi Mattijs, >> > >> > On Thu, Jan 5, 2023 at 10:06 AM Mattijs Korpershoek >> > wrote: >> >> >> >> On Wed, Jan 04, 2023 at 17:46, Dario Binacchi >> >> wrote: >> >> >> >> > The patch fixes the following error when updating a BSH SMM S2 board: >> >> > 3:72>Start Cmd:FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb >> >> > ${filesize} >> >> > 3:72>Okay (0.023s) >> >> > 3:72>Start Cmd:FB: reboot >> >> > 3:72>Fail Bulk(R):LIBUSB_ERROR_IO(0s) >> >> > >> >> > The "fastboot reboot" command detaches the USB when it still needs to be >> >> > used. So let's detach the USB just before the reset. >> >> > >> >> > CC: Mattijs Korpershoek >> >> > Fixes: 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot >> >> > commands") >> >> > Suggested-by: Michael Trimarchi >> >> > Signed-off-by: Dario Binacchi >> >> >> >> Hi Dario, >> >> >> >> Thank you for your patch and for reporting the problem. >> >> >> >> Unfortunately, applying it seems to break the problem I tried to >> >> solve with 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot >> >> commands") >> >> >> >> Does reverting 5f7e01e9d5d800 also solves your issue? >> > >> > Yes >> > >> >> >> >> I'll spend some time on this. >> > >> > Ok, thanks. So we can test on our hardware. >> >> So historically, I wanted to make this a "arch specific fix, as >> discussed in >> https://lore.kernel.org/u-boot/20220728-reset-usb-controller-v2-0-ef7657ce7...@baylibre.com/ >> >> To me, the problem with calling g_dnl_trigger_detach() in the >> fastboot_func->in_req->complete() handler is that it's called too late. >> >> In fact, the main fastboot loop is as following: >> >> while (1) { >> if (g_dnl_detach()) >> break; >> if (ctrlc()) >> break; >> schedule(); >> usb_gadget_handle_interrupts(controller_index); >> } >> ret = CMD_RET_SUCCESS; >> >> exit: >> usb_gadget_release(controller_index); >> g_dnl_unregister(); >> g_dnl_clear_detach(); >> >> return ret; >> >> usb_gadget_handle_interrupts, will at some point, call complete() which will >> call compl_do_reset(). >> But in compl_do_reset(), we already reset the board >> (without going through the exit: section from cmd/fastboot.c) >> >> For the BSH SMM S2 board, since it's being updated with uuu, >> I assume that the host PC also triggers a call of acmd_complete() afterwards? >> >> Can you try the following diff as well, on top of your change? (for testing >> purposes) >> >> --- a/drivers/usb/gadget/f_fastboot.c >> +++ b/drivers/usb/gadget/f_fastboot.c >> @@ -492,7 +492,7 @@ static void do_bootm_on_complete(struct usb_ep *ep, >> struct usb_request *req) >> >> static void compl_do_reset(struct usb_ep *ep, struct usb_request *req) >> { >> - do_exit_on_complete(ep, req); >> + usb_gadget_release(0); >> do_reset(NULL, 0, 0, NULL); >> } >> >> I suspect this will also break your flashing. > > No, I am able to flash and reset the board. > This change works. With some additional testing on my end, I can see that the final message (sending OKAY to the host) done on fastboot_func->in_ep is not done on my end. I think I am lucky that my controller driver (dwc2_udc_otg) delivers the message to my host anyways and calls done() even when messages are aborted. I think I have something that might be better. Dario, could you do another test for me, please? 1. Revert 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot commands") 2. Apply the following diff: diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index d0e92c7a071f..f4311328a2da 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -421,6 +421,7 @@ static int fastboot_tx_write_str(const char *buffer) static void compl_do_reset(struct usb_ep *ep, struct usb_request *req) { + g_dnl_unregister(); do_reset(NULL, 0, 0, NULL); } The call to g_dnl_unregister() will end up calling g_dnl_unbind() which calls usb_gadget_disconnect() where each controller can implement a soft disconnect (which I can do for dwc2_udc_otg) > >> >> > Regards Dario >> > >> >> >> >> > >> >> > --- >> >> > >> >> > Changes in v2: >> >> > - Add 'Suggested-by' tag. >> >> > >> >> > drivers/usb/gadget/f_fastboot.c | 12 ++-- >> >> > 1 file changed, 6 insertions(+), 6 deletions(-) >> >> > >> >> > diff --git a/drivers/usb/gadget/f_fastboot.c >> >> > b/drivers/usb/gadget/f_fastboot.c >> >> > index 07b1681c8a9a..0b3fae564d0a 100644 >> >> > --- a/drivers/usb/gadget/f_fastboot.c >> >> > +++ b/drivers/usb/gadget/f_fastboot.c >> >> > @@ -419,11 +419,6 @@ static int fastboot_tx_write_str(const char >> >> > *buffer) >> >> > return fastboot_tx_write(buffer, st
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 10:51:43 Tom Rini wrote: > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > The changes to this generic function, which is intended to help with > 32bit platforms with large amounts of memory has unintended side effects > (which in turn lead to boot failures) on other platforms which were > previously functional. As mentioned previously, unfortunately this revert breaks 32-bit u-boot on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. Which platforms currently have broken u-boot without this revert? The only one which was reported is stm32mp but for it there different workaround patch waiting in the queue. > Reported-by: Marek Vasut > Cc: Patrick Delaunay > Cc: Pali Rohár > Signed-off-by: Tom Rini > --- > common/memsize.c | 18 +++--- > 1 file changed, 3 insertions(+), 15 deletions(-) > > diff --git a/common/memsize.c b/common/memsize.c > index 3c80ad2c8346..31884acca0df 100644 > --- a/common/memsize.c > +++ b/common/memsize.c > @@ -94,23 +94,11 @@ long get_ram_size(long *base, long maxsize) > > phys_size_t __weak get_effective_memsize(void) > { > - phys_size_t ram_size = gd->ram_size; > - > - /* > - * Check for overflow and limit ram size to some representable value. > - * It is required that ram_base + ram_size must be representable by > - * phys_size_t type and must be aligned by direct access, therefore > - * calculate it from last 4kB sector which should work as alignment > - * on any platform. > - */ > - if (gd->ram_base + ram_size < gd->ram_base) > - ram_size = ((phys_size_t)~0xfffULL) - gd->ram_base; > - > #ifndef CONFIG_MAX_MEM_MAPPED > - return ram_size; > + return gd->ram_size; > #else > /* limit stack to what we can reasonable map */ > - return ((ram_size > CONFIG_MAX_MEM_MAPPED) ? > - CONFIG_MAX_MEM_MAPPED : ram_size); > + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ? > + CONFIG_MAX_MEM_MAPPED : gd->ram_size); > #endif > } > -- > 2.25.1 >
Re: [PATCH] i2c: uniphier-f: correct error recovery
On Fri, Dec 09, 2022 at 08:38:27PM +0900, Dai Okamura wrote: > The uniphier i2c block can recognize some handshake errors. > But driver handles all error detections as no error if no timeout. > So this makes unrecoverable state. > > This replaces the return values with the right ones to tell the i2c > framework the errors: > - EDEADLK for arbitration lost error > - ENODATA for no answer error > > Signed-off-by: Dai Okamura > Acked-by: Kunihiko Hayashi > Reviewed-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd: pxe_utils: Limit fdtcontroladdr usage to non-fitImage
On Wed, Dec 14, 2022 at 07:45:18AM +0100, Marek Vasut wrote: > Commit d5ba6188dfb ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") > forces '$fdtcontroladdr' DT address as a third parameter of bootm command > even if the PXE transfer pulls in a fitImage which contains configuration > node with its own DT that is preferrable to be passed to Linux. Limit the > $fdtcontroladdr fallback utilization to non-fitImages, since it is highly > likely a fitImage would come with its own DT, while single-file images do > need a separate DT. > > Fixes: d5ba6188dfb ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") > Signed-off-by: Marek Vasut > Reviewed-by: Quentin Schulz > Tested-by: Quentin Schulz > Reviewed-by: Simon Glass > Reviewed-by: Peter Hoyes > Tested-by: Peter Hoyes > Reviewed-by: Neil Armstrong Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "Revert "cmd: pxe_utils: Check fdtcontroladdr in label_boot""
On Sat, Dec 17, 2022 at 06:41:13PM +0100, Marek Vasut wrote: > This reverts commit ed6251187afabf811a5fd49a44ebd61c53c7b378. > > Superseded by "cmd: pxe_utils: Limit fdtcontroladdr usage to non-fitImage" > which is less heavy-handed approach and retains part of the original > behavior for non-fitImage. > > Signed-off-by: Marek Vasut > Acked-by: Neil Armstrong Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin
On Wed, Dec 28, 2022 at 07:18:39PM +0100, Pali Rohár wrote: > U-Boot build system builds final U-Boot binary for socrates board in custom > file u-boot-socrates.bin (instead of standard u-boot.bin). Output target > file u-boot-socrates.bin is generated by binman as defined in board binman > config file arch/powerpc/dts/socrates-u-boot.dtsi. > > But binman was disabled in commit 5af42eafd7e1 ("Makefile: Reduce usage of > custom mpc85xx u-boot.bin target") for all mpc85xx boards which do not use > standard powerpc binman config file arch/powerpc/dts/u-boot.dtsi and boards > which do not require binman at all. > > The only such mpc85xx board is socrates. So since that commit, U-Boot does > not final binary for socrates board anymore. > > Fix this issue by re-enabling binman for socrates board. And build process > starts again producing u-boot-socrates.bin binary. > > Note that build process for this socrates board always produce u-boot.bin > binary which is broken and not usable for socrates board. Long term > solution should be to disable building broken binary u-boot.bin and then > renaming u-boot-socrates.bin to u-boot.bin, or switching to use common > powerpc binman config file arch/powerpc/dts/socrates-u-boot.dtsi (if it is > possible). > > Fixes: 5af42eafd7e1 ("Makefile: Reduce usage of custom mpc85xx u-boot.bin > target") > Signed-off-by: Pali Rohár > Tested-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] imx7d-pico: Fix the name of the u-boot.dtsi file
On Sat, Dec 31, 2022 at 01:25:14PM -0300, Fabio Estevam wrote: > Since commit 2f96d4dd95f8 ("imx7s/d: synchronise device trees with linux") > the imx7d-pico board no longer boots. > > The reason is that prior to the above commit there was an explicit > inclusion of arch/arm/dts/imx7d-pico-u-boot.dtsi inside imx7d-pico.dtsi. > > After the syncing with the Linux upstream dtsi, this u-boot.dtsi inclusion > is gone and the board fails to boot. > > U-Boot uses the imx7d-pico-pi.dtb file, so rename the u-boot.dtsi to > imx7d-pico-pi-u-boot.dtsi which gets included automatically by U-Boot > standard make logic and makes the board boot again. > > Signed-off-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] rockchip: Fix the broken Video out for rk3288 boards
On Mon, Jan 02, 2023 at 11:53:45PM +0530, Jagan Teki wrote: > Video out on RK3288 boards has been broken since from few > releases due to the adding of reset support on vop but > missed enabling DM_RESET on associated boards. > > This patch fixes those RK3288 boards. > > Cc: Simon Glass > Cc: Lin Huang > Cc: Jernej Skrabec > Cc: Michael Trimarchi > Cc: Arnaud Patard (Rtp) > Fixes: <9749d2ea29e1> ("rockchip: video: vop: Add reset support") > Reported-by: Manoj Sai > Signed-off-by: Jagan Teki > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pylibfdt: Fix disable version normalization
On Wed, Jan 04, 2023 at 03:43:33PM +0100, Philippe Schenker wrote: > From: Philippe Schenker > > On Arch Linux based systems python setuptools does not contain > "setuptools.extern" hence it is failing with the following > error-message: > " > ModuleNotFoundError: No module named 'setuptools.extern' > " > > According to a eschwartz `setuptools.extern` is not a public API and > shall not be assumed to be present in the setuptools package. He > mentions that the setuptools project anyway wants to drop this. [1] > > Use the correct solution introduced by python setuptools developers to > disable normalization. [2] > > [1] https://bbs.archlinux.org/viewtopic.php?id=259608 > [2] https://github.com/pypa/setuptools/pull/2026 > Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning") > Signed-off-by: Philippe Schenker > Reviewed-by: Marek Vasut > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: rz-g2-beacon-u-boot: Fix QSPI Regression
On Wed, Jan 04, 2023 at 09:53:09AM -0600, Adam Ford wrote: > The QSPI is accessed via the RPC-IF, but the compatible flags > previously used a different name. This compatibel name was changed > which broke the ability to access the QSPI. Fix this by removing > the custom naming reference. > > Fixes: 68083b897b57 ("renesas: Fix RPC-IF compatible values") > Signed-off-by: Adam Ford > Reviewed-by: Marek Vasut > > diff --git a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi > b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi > index 4d17854918..da1c3b0939 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY
On Wed, Jan 04, 2023 at 12:05:43PM -0600, Adam Ford wrote: > Due to the part shortage, the AR8031 PHY was replaced with a > Micrel KSZ9131. Enabling both config options keeps backward > compatibility with either platform, and both appear to be > auto-detected. > > Signed-off-by: Adam Ford > Reviewed-by: Marek Vasut > > diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig > index 36787057a2..b4ea6c630a 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] Pull request for u-boot master / v2023.01 = u-boot-stm32-20230106
On Fri, Jan 06, 2023 at 11:48:54AM +0100, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the STM32 related fixes for u-boot/master, v2023.01: > u-boot-stm32-20230106 > > > - stm32mp: Fix board_get_usable_ram_top(): workaround to avoid issue after > the > > commit 777706b ("common/memsize.c: Fix get_effective_memsize() to > check > > for overflow") because the effective DDR effective size is reduce by 4KiB > and sometime the board hang on boot > > > CI status: > https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/14623 > > > This last patch for v2023.01 avoids a hang on 1GB DDR STM32MP15 board > detected > > by Marek and caused by Pali patch. > > > For my point a view , this patch is an acceptable workaround for master > branch and v2023.01 delivery > > but the initial patch should be revisited or reverted (in master or in next > ?). > > > For details see comments in patch > > "arm: stm32mp: Fix board_get_usable_ram_top() again" > > http://patchwork.ozlabs.org/project/uboot/patch/2023010501.238075-1-ma...@denx.de/ > > https://lore.kernel.org/u-boot/2023010501.238075-1-ma...@denx.de/ Yes, I want to see how this progresses, thanks for taking a work-around for now. But for now I have also posted a revert, to help spur discussion. > > Thanks, > Patrick > > = > > > The following changes since commit 8d6cbf5e6bc4e10e38b954763fa025caed517cc2: > > Merge tag 'efi-2023-01-rc5-3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-01-04 08:50:24 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20230106 > > for you to fetch changes up to a2e0b041d662e4c80502cd5c9a8326d026f9deb1: > > arm: stm32mp: Fix board_get_usable_ram_top() again (2023-01-06 11:02:17 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
Hi Marek, On 1/5/23 02:22, Marek Vasut wrote: Do not access gd->ram_size and assume this is actual valid RAM size. Since commit 777706b ("common/memsize.c: Fix get_effective_memsize() to check for overflow") the RAM size may be less than gd->ram_size , call get_effective_memsize() to get the limited value instead. The aforementioned commit makes STM32MP15xx boards with 1 GiB of DRAM at 0xc000 hang on boot, which is a grave defect. Signed-off-by: Marek Vasut --- Cc: Pali Rohar Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Tom Rini --- arch/arm/mach-stm32mp/dram_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c index 9346fa8546d..80ba5c27741 100644 --- a/arch/arm/mach-stm32mp/dram_init.c +++ b/arch/arm/mach-stm32mp/dram_init.c @@ -51,7 +51,7 @@ phys_size_t board_get_usable_ram_top(phys_size_t total_size) /* found enough not-reserved memory to relocated U-Boot */ lmb_init(&lmb); - lmb_add(&lmb, gd->ram_base, gd->ram_size); + lmb_add(&lmb, gd->ram_base, get_effective_memsize()); boot_fdt_add_mem_rsv_regions(&lmb, (void *)gd->fdt_blob); /* add 8M for reserved memory for display, fdt, gd,... */ size = ALIGN(SZ_8M + CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE), Applied to u-boot-stm/master, thanks! For my point a view , this patch is an acceptable workaround for master branch and v2023.01 delivery. but the initial commit 777706b ("common/memsize.c: Fix get_effective_memsize() to check should be revisited or reverted (in master or in next ?). For details see comments in patch "arm: stm32mp: Fix board_get_usable_ram_top() again" http://patchwork.ozlabs.org/project/uboot/patch/2023010501.238075-1-ma...@denx.de/ https://lore.kernel.org/u-boot/2023010501.238075-1-ma...@denx.de/ Regards Patrick
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > The changes to this generic function, which is intended to help with > > 32bit platforms with large amounts of memory has unintended side effects > > (which in turn lead to boot failures) on other platforms which were > > previously functional. > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > Which platforms currently have broken u-boot without this revert? The > only one which was reported is stm32mp but for it there different > workaround patch waiting in the queue. Are you able to test on one of these PowerPC platforms currently? As the stm32 problem shows, not everything is getting tested frequently enough, so how many other cases are lurking out there. And, I think overall issue is that the overflow check-and-change you introduce here should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the case you're dealing with, yes? -- Tom signature.asc Description: PGP signature
Re: linksys wrt1900acs v2 boot problem
Hello Dilyan! On Tuesday 28 September 2021 22:01:40 Dilyan Lazarov wrote: > Hi, > I have a problem with my linksys wrt1900acs. > My main question is this a hardware problem or software problem? > Is it possible to address? This looks like DDR3 training SW issue problem. Marek worked on in and tried to address issue. He should know more details in this area. > I have started researching and have tried with "kwboot" under Windows VM - > Ubuntu 20 - Linux but I have a problem with usb serial connection. I have > tried several things but I understand that it isn't possible to start USB > to Serial on a Windows VM. > I will expect your response. > Thank you in advance. You need to use kwboot natively. It was heavily tested on Linux and I think it should work also on BSD systems. Windows systems are not really supported and kwboot will not work on them. > All the best > Dilyan > > I see the following Log from U-Boot with PuTTy under Windows 10: > BootROM - 1.73 > Booting from NAND flash > > General initialization - Version: 1.0.0 > Detected Device ID 6820 > High speed PHY - Version: 2.0 > > Init RD NAS topology Serdes Lane 3 is USB3 > Serdes Lane 4 is SGMII > board SerDes lanes topology details: > | Lane # | Speed | Type | > > | 0| 06 | SATA0 | > | 1| 05 | PCIe0 | > | 2| 06 | SATA1 | > | 3| 05 | USB3 HOST1 | > | 4| 05 | PCIe1 | > | 5| 00 | SGMII2 | > > :** Link is Gen1, check the EP capability > PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities > :** Link is Gen1, check the EP capability > PCIe, Idx 1: remains Gen1 > High speed PHY - Ended Successfully > DDR3 Training Sequence - Ver TIP-1.26.0 > mvSysEnvGetTopologyUpdateInfo: TWSI Read failed > WL Supp: IF 0 busId 1 Failed ! > WL Supp: IF 0 failed > ddr3TipDynamicWriteLevelingSupp failure > DRAM initialization Failed (res 0x1) > DDR3 run algorithm - FAILED 0x1 > DDR3 Training Sequence - FAILED > > > ** DRAM initialization failed! > -- > Dilyan Could you please try to update U-Boot to the new version? If the issue is still there? Because DDR3 marvell driver was updated and it is possible that also your issue is fixed now too...
Re: Netgear RN102 U-Boot Nand Driver Modification
Hello Abdus! On Thursday 24 September 2020 17:26:49 Abdus Rainey wrote: > I have recently modded a Netgear RN102 NAND flash from 128 MB to 4096 MB > (Samsung k9gbg08u0a) but i have a problem with NAND initialization. > I can boot with kwboot which is unique for Armada CPU's. > > Here is my log from kwboot with my stock mtd0: > > > root at whitepawnxeon:/home/jigsaw/Downloads# kwboot -t -B 115200 > /dev/ttyUSB0 -b mtd0stockuboot.img -p > Sending boot message. Please reboot the target...- > Sending boot image... > 0 % [..] ... > 5 % [. > > General initialization - Version: 1.0.0 > > High speed PHY - Version: 2.1.4 (COM-PHY-V20) > Update PEX Device ID 0x6710 > High speed PHY - Ended Successfully > > DDR3 Training Sequence - Ver 5.7.1 > DDR3 Training Sequence - Run without PBS. > DDR3 Training Sequence - Ended Successfully > .] > 5 % [..] ... > 99 % [..] > [Type Ctrl-\ + c to quit] > > __ __ _ _ > | \/ | __ _ _ _| | | > | |\/| |/ _` | '__\ \ / / _ \ | | > | | | | (_| | | \ V / __/ | | > |_| |_|\__,_|_|\_/ \___|_|_| > _ _ _ > | | | | | __ ) ___ ___ | |_ > | | | |___| _ \ / _ \ / _ \| __| > | |_| |___| |_) | (_) | (_) | |_ > \___/|/ \___/ \___/ \__| > ** LOADER ** > > > U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:53:05) Marvell version: > v2011.12 2014_T2.0p1 > 06/23/2015 ReadyNAS-102 V2.0 > > Board: DB-88F6710-BP > SoC: MV6710 A1 > CPU: Marvell PJ4B v7 UP (Rev 1) LE >CPU@ 1200 [MHz] >L2 @ 600 [MHz] >TClock @ 200 [MHz] >DDR@ 600 [MHz] >DDR 16Bit Width, FastPath Memory Access > DRAM: 512 MiB > > Map: Code: 0x1feef000:0x1ff9ef34 >BSS: 0x1ffef0a0 >Stack: 0x1f9eeef8 >Heap: 0x1f9ef000:0x1feef000 > > NAND: (ID 0xd7ec) nand_get_flash_type: second ID read did not match ac,d7 > against ec,52 > No NAND device found!!! > 0 MiB This error message means that your u-boot does not have a driver for your NAND memory. Or it has driver, but it is missing manufacturer id, so driver correctly binds to that NAND device. > As you can see u-boot sees device id and manufacturer id but cannot recognize > it.My stock u-boot is very old and i get u-boot source code from Netgear > GPL.(ReadyNASOS_V6.6.0_WW_src.zip) > In here https://forum.doozan.com/read.php?2,106589,108204#msg-108204 you can > see my whole story about this device. > Can someone suggest any solution? I would suggest to update to the new U-Boot version. This is really old version. Also look into U-Boot source code if NAND drivers support this id. If id is not supported then it is possible that change would be relatively easy if id is just missing in the supported list.
Re: kwboot : bug when board stops acking
Hello Stephane! On Wednesday 08 January 2020 15:21:12 SC wrote: > Hi list, > > I think there's a bug in kwboot. > I have a faulty board that stops acking xmodem frames after a certain number > of packets and kwboot > instead of exiting continues to send frames up to 100%. > With the one second retry timer it's very long! More than 2 hours :-( I saw very similar bugs in kwboot and together with Marek we fixed lot of issues in kwboot. Could you test if last version of kwboot from U-Boot git master branch has still same or similar issue? > The bug is in the kwboot_xm_sendblock() fonction : > https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375 > kwboot_tty_recv detects the timeout but the return value is based on the last > character received > (line 403) > The variable c is not initialized so if it keeps the previous value which is > ACK => rc=0 => infinite > loop > > There are several ways to fix the bug: > * Surround the "switch(c)" with a test: > if ( !((rc == -1) && (errno == ETIMEDOUT)) ) { > rc = -1; > switch (c) { > case ACK: > rc = 0; > break; > case NAK: > errno = EBADMSG; > break; > case CAN: > errno = ECANCELED; > break; > default: > errno = EPROTO; > break; > } > } > return rc; > * In the case of a TIMEOUT set c to a specific value and add the case in the > switch > > Do you agree with my diagnosis? > What is the best solution to fix this bug? > Should I provide a patch? > > Thank you, > Stephane
[PATCH] common: bouncebuf: Use dma-mapping for cache ops
This matches how this would be done in Linux and these functions do the alignment for us which makes the code look cleaner. Signed-off-by: Andrew Davis --- common/bouncebuf.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/common/bouncebuf.c b/common/bouncebuf.c index 6d98920de66..93a35668cc2 100644 --- a/common/bouncebuf.c +++ b/common/bouncebuf.c @@ -12,6 +12,7 @@ #include #include #include +#include static int addr_aligned(struct bounce_buffer *state) { @@ -59,9 +60,9 @@ int bounce_buffer_start_extalign(struct bounce_buffer *state, void *data, * Flush data to RAM so DMA reads can pick it up, * and any CPU writebacks don't race with DMA writes */ - flush_dcache_range((unsigned long)state->bounce_buffer, - (unsigned long)(state->bounce_buffer) + - state->len_aligned); + dma_map_single(state->bounce_buffer, + state->len_aligned, + DMA_BIDIRECTIONAL); return 0; } @@ -78,9 +79,9 @@ int bounce_buffer_stop(struct bounce_buffer *state) { if (state->flags & GEN_BB_WRITE) { /* Invalidate cache so that CPU can see any newly DMA'd data */ - invalidate_dcache_range((unsigned long)state->bounce_buffer, - (unsigned long)(state->bounce_buffer) + - state->len_aligned); + dma_unmap_single((dma_addr_t)state->bounce_buffer, +state->len_aligned, +DMA_BIDIRECTIONAL); } if (state->bounce_buffer == state->user_buffer) -- 2.38.1
Re: [PATCH] ARM: omap3: evm: Name this directory omap3
On 10/7/22 10:21 PM, Derald Woods wrote: On Fri, Oct 07, 2022 at 12:33:14PM -0500, Andrew Davis wrote: Before this was named just evm, which doesn't match the naming of the other TI board file directory and makes it look like a common directory for evms. Name this omap3. Signed-off-by: Andrew Davis --- arch/arm/mach-omap2/omap3/Kconfig | 2 +- board/ti/{evm => omap3}/Kconfig | 2 +- board/ti/{evm => omap3}/MAINTAINERS | 2 +- board/ti/{evm => omap3}/Makefile| 0 board/ti/{evm => omap3}/evm.c | 0 board/ti/{evm => omap3}/evm.h | 0 6 files changed, 3 insertions(+), 3 deletions(-) rename board/ti/{evm => omap3}/Kconfig (87%) rename board/ti/{evm => omap3}/MAINTAINERS (87%) rename board/ti/{evm => omap3}/Makefile (100%) rename board/ti/{evm => omap3}/evm.c (100%) rename board/ti/{evm => omap3}/evm.h (100%) diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index 3e97ec2629..4e9924faf7 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -163,7 +163,7 @@ config SYS_SOC source "board/logicpd/am3517evm/Kconfig" source "board/ti/beagle/Kconfig" source "board/timll/devkit8000/Kconfig" -source "board/ti/evm/Kconfig" +source "board/ti/omap3/Kconfig" source "board/isee/igep00x0/Kconfig" source "board/logicpd/omap3som/Kconfig" source "board/nokia/rx51/Kconfig" diff --git a/board/ti/evm/Kconfig b/board/ti/omap3/Kconfig similarity index 87% rename from board/ti/evm/Kconfig rename to board/ti/omap3/Kconfig index 4f490ddd9d..d60b229a4e 100644 --- a/board/ti/evm/Kconfig +++ b/board/ti/omap3/Kconfig @@ -1,7 +1,7 @@ if TARGET_OMAP3_EVM config SYS_BOARD - default "evm" + default "omap3" config SYS_VENDOR default "ti" diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3/MAINTAINERS similarity index 87% rename from board/ti/evm/MAINTAINERS rename to board/ti/omap3/MAINTAINERS index cd315c1635..95b34bbd11 100644 --- a/board/ti/evm/MAINTAINERS +++ b/board/ti/omap3/MAINTAINERS @@ -1,6 +1,6 @@ EVM BOARD M: Derald D. Woods S: Maintained -F: board/ti/evm/ +F: board/ti/omap3/ F: include/configs/omap3_evm.h F: configs/omap3_evm_defconfig diff --git a/board/ti/evm/Makefile b/board/ti/omap3/Makefile similarity index 100% rename from board/ti/evm/Makefile rename to board/ti/omap3/Makefile diff --git a/board/ti/evm/evm.c b/board/ti/omap3/evm.c similarity index 100% rename from board/ti/evm/evm.c rename to board/ti/omap3/evm.c diff --git a/board/ti/evm/evm.h b/board/ti/omap3/evm.h similarity index 100% rename from board/ti/evm/evm.h rename to board/ti/omap3/evm.h -- 2.37.3 It seems to me that something like 'omap3evm' would be more appropriate for a directory name. Using just 'omap3' may be too generic. The actual EVM configurations are TMDSEVM3530 [1] and TMDSEVM3730 [2], with the corresponding processor boards attached. It would also align with the TARGET_OMAP3_EVM definition still in use. These are my observations. I'm not sure about that, the convention seems to be the directory name matches the SoC, then the source files match for each type/name of board. This is at least true for some newer TI boards, but I agree it is not always followed for the older devices. I have no strong preference either way, just as long as we can not call it "board/ti/evm" like it is now.. This patch still applies to the latest u-boot, or I can send a v2. Andrew - Derald [1] https://www.digikey.com/en/products/detail/texas-instruments/TMDSEVM3530/2232584 [2] https://www.digikey.com/en/products/detail/texas-instruments/TMDSEVM3730/2627669 [3] https://media.digikey.com/pdf/Data%20Sheets/Texas%20Instruments%20PDFs/tmdsevm3730.pdf [4] https://media.digikey.com/pdf/Data%20Sheets/Texas%20Instruments%20PDFs/TMDSEVM3530.pdf
Re: [PATCH] ARM: omap3: evm: Name this directory omap3
On Fri, Jan 06, 2023 at 12:13:12PM -0600, Andrew Davis wrote: > On 10/7/22 10:21 PM, Derald Woods wrote: > > On Fri, Oct 07, 2022 at 12:33:14PM -0500, Andrew Davis wrote: > > > Before this was named just evm, which doesn't match the naming > > > of the other TI board file directory and makes it look like a > > > common directory for evms. Name this omap3. > > > > > > Signed-off-by: Andrew Davis > > > --- > > > arch/arm/mach-omap2/omap3/Kconfig | 2 +- > > > board/ti/{evm => omap3}/Kconfig | 2 +- > > > board/ti/{evm => omap3}/MAINTAINERS | 2 +- > > > board/ti/{evm => omap3}/Makefile| 0 > > > board/ti/{evm => omap3}/evm.c | 0 > > > board/ti/{evm => omap3}/evm.h | 0 > > > 6 files changed, 3 insertions(+), 3 deletions(-) > > > rename board/ti/{evm => omap3}/Kconfig (87%) > > > rename board/ti/{evm => omap3}/MAINTAINERS (87%) > > > rename board/ti/{evm => omap3}/Makefile (100%) > > > rename board/ti/{evm => omap3}/evm.c (100%) > > > rename board/ti/{evm => omap3}/evm.h (100%) > > > > > > diff --git a/arch/arm/mach-omap2/omap3/Kconfig > > > b/arch/arm/mach-omap2/omap3/Kconfig > > > index 3e97ec2629..4e9924faf7 100644 > > > --- a/arch/arm/mach-omap2/omap3/Kconfig > > > +++ b/arch/arm/mach-omap2/omap3/Kconfig > > > @@ -163,7 +163,7 @@ config SYS_SOC > > > source "board/logicpd/am3517evm/Kconfig" > > > source "board/ti/beagle/Kconfig" > > > source "board/timll/devkit8000/Kconfig" > > > -source "board/ti/evm/Kconfig" > > > +source "board/ti/omap3/Kconfig" > > > source "board/isee/igep00x0/Kconfig" > > > source "board/logicpd/omap3som/Kconfig" > > > source "board/nokia/rx51/Kconfig" > > > diff --git a/board/ti/evm/Kconfig b/board/ti/omap3/Kconfig > > > similarity index 87% > > > rename from board/ti/evm/Kconfig > > > rename to board/ti/omap3/Kconfig > > > index 4f490ddd9d..d60b229a4e 100644 > > > --- a/board/ti/evm/Kconfig > > > +++ b/board/ti/omap3/Kconfig > > > @@ -1,7 +1,7 @@ > > > if TARGET_OMAP3_EVM > > > > > > config SYS_BOARD > > > - default "evm" > > > + default "omap3" > > > > > > config SYS_VENDOR > > >default "ti" > > > diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3/MAINTAINERS > > > similarity index 87% > > > rename from board/ti/evm/MAINTAINERS > > > rename to board/ti/omap3/MAINTAINERS > > > index cd315c1635..95b34bbd11 100644 > > > --- a/board/ti/evm/MAINTAINERS > > > +++ b/board/ti/omap3/MAINTAINERS > > > @@ -1,6 +1,6 @@ > > > EVM BOARD > > > M: Derald D. Woods > > > S: Maintained > > > -F: board/ti/evm/ > > > +F: board/ti/omap3/ > > > F: include/configs/omap3_evm.h > > > F: configs/omap3_evm_defconfig > > > diff --git a/board/ti/evm/Makefile b/board/ti/omap3/Makefile > > > similarity index 100% > > > rename from board/ti/evm/Makefile > > > rename to board/ti/omap3/Makefile > > > diff --git a/board/ti/evm/evm.c b/board/ti/omap3/evm.c > > > similarity index 100% > > > rename from board/ti/evm/evm.c > > > rename to board/ti/omap3/evm.c > > > diff --git a/board/ti/evm/evm.h b/board/ti/omap3/evm.h > > > similarity index 100% > > > rename from board/ti/evm/evm.h > > > rename to board/ti/omap3/evm.h > > > -- > > > 2.37.3 > > > > > > > It seems to me that something like 'omap3evm' would be more appropriate > > for a directory name. Using just 'omap3' may be too generic. The actual > > EVM configurations are TMDSEVM3530 [1] and TMDSEVM3730 [2], with the > > corresponding processor boards attached. It would also align with the > > TARGET_OMAP3_EVM definition still in use. These are my observations. > > > > I'm not sure about that, the convention seems to be the directory name > matches the SoC, then the source files match for each type/name of > board. This is at least true for some newer TI boards, but I agree it > is not always followed for the older devices. I have no strong preference > either way, just as long as we can not call it "board/ti/evm" like it > is now.. > > This patch still applies to the latest u-boot, or I can send a v2. I'd like a v2 of "omap3evm" please, we have other omap3 platforms still so it would just be a different confusion I feel (and most of the other board/ti/SOC/ directories support the EVM + SK + other stuff model, while this is just the 3530/3730 boards that are iirc otherwise very similar). Thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for u-boot-nand-20230104
On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote: > Hi Tom, > > The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: > > Merge branch '2023-01-02-platform-updates' into next (2023-01-02 > 18:07:41 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git > tags/u-boot-nand-20230104 > > for you to fetch changes up to 48f219cb16f88cd2e392e2f438409a00d3ddff54: > > mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04 > 17:24:30 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597 > NAK. This commit: commit 48f219cb16f88cd2e392e2f438409a00d3ddff54 Author: Roger Quadros Date: Tue Dec 20 12:22:03 2022 +0200 mtd: rawnand: omap_elm: u-boot driver model support Support u-boot driver model. We still retain support legacy way of doing things if ELM_BASE is defined in We could completely get rid of that if all platforms defining ELM_BASE get rid of that definition and enable CONFIG_SYS_NAND_SELF_INIT and are verified to work. Signed-off-by: Roger Quadros Signed-off-by: Michael Trimarchi Breaks am335x_evm thusly: U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500) Trying to boot from MMC1 U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500) CPU : AM335X-GP rev 2.1 Model: TI AM335x EVM DRAM: 1 GiB Error binding driver 'omap-elm': -96 Some drivers failed to bind Error binding driver 'ti_sysc': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind initcall sequence bffdbbe0 failed at call 808155a9 (err=-96) ### ERROR ### Please RESET the board ### -- Tom signature.asc Description: PGP signature
[PATCH v2] ARM: omap3: evm: Name this directory omap3evm
Before this was named just evm, which doesn't match the naming of the other TI board file directory and makes it look like a common directory for evms. Name this omap3evm. Signed-off-by: Andrew Davis --- Changes from v1: - Call dir omap3evm instead of omap3 arch/arm/mach-omap2/omap3/Kconfig | 2 +- board/ti/{evm => omap3evm}/Kconfig | 2 +- board/ti/{evm => omap3evm}/MAINTAINERS | 2 +- board/ti/{evm => omap3evm}/Makefile| 0 board/ti/{evm => omap3evm}/evm.c | 0 board/ti/{evm => omap3evm}/evm.h | 0 6 files changed, 3 insertions(+), 3 deletions(-) rename board/ti/{evm => omap3evm}/Kconfig (86%) rename board/ti/{evm => omap3evm}/MAINTAINERS (85%) rename board/ti/{evm => omap3evm}/Makefile (100%) rename board/ti/{evm => omap3evm}/evm.c (100%) rename board/ti/{evm => omap3evm}/evm.h (100%) diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index 3e97ec26295..671e4791c67 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -163,7 +163,7 @@ config SYS_SOC source "board/logicpd/am3517evm/Kconfig" source "board/ti/beagle/Kconfig" source "board/timll/devkit8000/Kconfig" -source "board/ti/evm/Kconfig" +source "board/ti/omap3evm/Kconfig" source "board/isee/igep00x0/Kconfig" source "board/logicpd/omap3som/Kconfig" source "board/nokia/rx51/Kconfig" diff --git a/board/ti/evm/Kconfig b/board/ti/omap3evm/Kconfig similarity index 86% rename from board/ti/evm/Kconfig rename to board/ti/omap3evm/Kconfig index 4f490ddd9d5..08a8aa20ae8 100644 --- a/board/ti/evm/Kconfig +++ b/board/ti/omap3evm/Kconfig @@ -1,7 +1,7 @@ if TARGET_OMAP3_EVM config SYS_BOARD - default "evm" + default "omap3evm" config SYS_VENDOR default "ti" diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3evm/MAINTAINERS similarity index 85% rename from board/ti/evm/MAINTAINERS rename to board/ti/omap3evm/MAINTAINERS index cd315c1635b..fb4268b312f 100644 --- a/board/ti/evm/MAINTAINERS +++ b/board/ti/omap3evm/MAINTAINERS @@ -1,6 +1,6 @@ EVM BOARD M: Derald D. Woods S: Maintained -F: board/ti/evm/ +F: board/ti/omap3evm/ F: include/configs/omap3_evm.h F: configs/omap3_evm_defconfig diff --git a/board/ti/evm/Makefile b/board/ti/omap3evm/Makefile similarity index 100% rename from board/ti/evm/Makefile rename to board/ti/omap3evm/Makefile diff --git a/board/ti/evm/evm.c b/board/ti/omap3evm/evm.c similarity index 100% rename from board/ti/evm/evm.c rename to board/ti/omap3evm/evm.c diff --git a/board/ti/evm/evm.h b/board/ti/omap3evm/evm.h similarity index 100% rename from board/ti/evm/evm.h rename to board/ti/omap3evm/evm.h -- 2.38.1
Re: [PATCH 0/4] Enable gigadevice and add new part #s
Hi, Michal, On 1/5/23 20:47, Vlim wrote: >> Regarding the location of the entry, I believe you want me to add the entry >> in >> the alphabetical order? > > Not really. I want to you follow Kconfig layout which is what make > savedefconfig > && cp defconfig configs/ is for. > > Can you be more specific on this requirement? > I believe this is pertaining to the defconfig files. > Where is the correct line to insert the following entry? > CONFIG_SPI_FLASH_GIGADEVICE=y Again. Just enable that option and run for example make xilinx_zynqmp_virt_defconfig echo CONFIG_SPI_FLASH_GIGADEVICE=y >> .config make savedefconfig cp defconfig configs/xilinx_zynqmp_virt_defconfig git commit -a -s And that's it. Your symbol will be added to proper location. I did the make command, but it says nothing to be done. Do I need to install an additional software package in order to perform this function? victor@victor-17Z990-R-AAC9U1:~/Desktop/u-boot-xlnx/configs$ make zynq_cse_qspi_defconfig make: Nothing to be done for 'zynq_cse_qspi_defconfig'. victor@victor-17Z990-R-AAC9U1:~/Desktop/u-boot-xlnx/configs$ Regards, Victor
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 12:25:24 Tom Rini wrote: > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > The changes to this generic function, which is intended to help with > > > 32bit platforms with large amounts of memory has unintended side effects > > > (which in turn lead to boot failures) on other platforms which were > > > previously functional. > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > Which platforms currently have broken u-boot without this revert? The > > only one which was reported is stm32mp but for it there different > > workaround patch waiting in the queue. > > Are you able to test on one of these PowerPC platforms currently? As > the stm32 problem shows, not everything is getting tested frequently > enough, so how many other cases are lurking out there. And, I think > overall issue is that the overflow check-and-change you introduce here > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > case you're dealing with, yes? I was planning to do big retest again after all powerpc patches are reviewed and merged... Anyway, if the issue here is with ram_size and its reduction was needed for mpc85xx (at the time of introduction of that patch), what about putting mpc85xx ifdef around ram_size reduction? For arm boards it would have same behavior as revert of that commit and for mpc85xx it would be no change. I agree that this code needs to be revisited, together with ram_top issue and also code which fills DDR banks. Because really mapped memory for u-boot and real size of DDR are two different things here.
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 6, 2023 at 12:51 PM Tom Rini wrote: > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > The changes to this generic function, which is intended to help with > 32bit platforms with large amounts of memory has unintended side effects > (which in turn lead to boot failures) on other platforms which were > previously functional. > > Reported-by: Marek Vasut > Cc: Patrick Delaunay > Cc: Pali Rohár > Signed-off-by: Tom Rini Peng also reported an imx issue caused by 777706bc (""common/memsize.c: Fix get_effective_memsize() to check for overflow""): https://patchwork.ozlabs.org/project/uboot/patch/20221107080016.1304-2-peng@oss.nxp.com/
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > The changes to this generic function, which is intended to help with > > > > 32bit platforms with large amounts of memory has unintended side effects > > > > (which in turn lead to boot failures) on other platforms which were > > > > previously functional. > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > Which platforms currently have broken u-boot without this revert? The > > > only one which was reported is stm32mp but for it there different > > > workaround patch waiting in the queue. > > > > Are you able to test on one of these PowerPC platforms currently? As > > the stm32 problem shows, not everything is getting tested frequently > > enough, so how many other cases are lurking out there. And, I think > > overall issue is that the overflow check-and-change you introduce here > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > case you're dealing with, yes? > > I was planning to do big retest again after all powerpc patches are > reviewed and merged... Yes, but can you test one of them now, to see if my idea works? > Anyway, if the issue here is with ram_size and its reduction was needed > for mpc85xx (at the time of introduction of that patch), what about > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > have same behavior as revert of that commit and for mpc85xx it would be > no change. > > I agree that this code needs to be revisited, together with ram_top > issue and also code which fills DDR banks. Because really mapped memory > for u-boot and real size of DDR are two different things here. The issue here is that we see two now (given Fabio's reminder about another thread I had forgotten) of unintended consequences, on 32bit platforms trying to normally have 2GB of memory, which does not require special treatment. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > The changes to this generic function, which is intended to help with > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > effects > > > > > (which in turn lead to boot failures) on other platforms which were > > > > > previously functional. > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > > > Which platforms currently have broken u-boot without this revert? The > > > > only one which was reported is stm32mp but for it there different > > > > workaround patch waiting in the queue. > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > the stm32 problem shows, not everything is getting tested frequently > > > enough, so how many other cases are lurking out there. And, I think > > > overall issue is that the overflow check-and-change you introduce here > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > case you're dealing with, yes? > > > > I was planning to do big retest again after all powerpc patches are > > reviewed and merged... > > Yes, but can you test one of them now, to see if my idea works? > > > Anyway, if the issue here is with ram_size and its reduction was needed > > for mpc85xx (at the time of introduction of that patch), what about > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > have same behavior as revert of that commit and for mpc85xx it would be > > no change. > > > > I agree that this code needs to be revisited, together with ram_top > > issue and also code which fills DDR banks. Because really mapped memory > > for u-boot and real size of DDR are two different things here. > > The issue here is that we see two now (given Fabio's reminder about > another thread I had forgotten) of unintended consequences, on 32bit > platforms trying to normally have 2GB of memory, which does not require > special treatment. What I'm leaning towards right now even, is that since it's hard to test the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if their behavior also changed here, the 36bit platforms should just be overriding get_effective_memsize. -- Tom signature.asc Description: PGP signature
Re: kwboot : bug when board stops acking
Hello, On Fri, Jan 6, 2023 at 9:52 AM Pali Rohár wrote: > > Hello Stephane! > > On Wednesday 08 January 2020 15:21:12 SC wrote: > > Hi list, > > > > I think there's a bug in kwboot. > > I have a faulty board that stops acking xmodem frames after a certain > > number of packets and kwboot > > instead of exiting continues to send frames up to 100%. > > With the one second retry timer it's very long! More than 2 hours :-( > > I saw very similar bugs in kwboot and together with Marek we fixed lot > of issues in kwboot. > > Could you test if last version of kwboot from U-Boot git master branch > has still same or similar issue? > > > The bug is in the kwboot_xm_sendblock() fonction : > > https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375 > > kwboot_tty_recv detects the timeout but the return value is based on the > > last character received > > (line 403) > > The variable c is not initialized so if it keeps the previous value which > > is ACK => rc=0 => infinite > > loop > > > > There are several ways to fix the bug: > > * Surround the "switch(c)" with a test: > > if ( !((rc == -1) && (errno == ETIMEDOUT)) ) { > > rc = -1; > > switch (c) { > > case ACK: > > rc = 0; > > break; > > case NAK: > > errno = EBADMSG; > > break; > > case CAN: > > errno = ECANCELED; > > break; > > default: > > errno = EPROTO; > > break; > > } > > } > > return rc; > > * In the case of a TIMEOUT set c to a specific value and add the case in > > the switch > > I've been running the latest kwboot (2023.01-rc4), and I did not see this problem. And the current code looks OK to me. c is modified before it is used later: https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1238 And the function kwboot_xm_sendblock() in GitHub is line L1215! https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1215 Probably Stephane is running an older version of kwboot? Best, Tony > > Do you agree with my diagnosis? > > What is the best solution to fix this bug? > > Should I provide a patch? > > > > Thank you, > > Stephane
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 16:45:41 Tom Rini wrote: > On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > > > The changes to this generic function, which is intended to help with > > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > > effects > > > > > > (which in turn lead to boot failures) on other platforms which were > > > > > > previously functional. > > > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit > > > > > u-boot > > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > > > > > Which platforms currently have broken u-boot without this revert? The > > > > > only one which was reported is stm32mp but for it there different > > > > > workaround patch waiting in the queue. > > > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > > the stm32 problem shows, not everything is getting tested frequently > > > > enough, so how many other cases are lurking out there. And, I think > > > > overall issue is that the overflow check-and-change you introduce here > > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > > case you're dealing with, yes? > > > > > > I was planning to do big retest again after all powerpc patches are > > > reviewed and merged... > > > > Yes, but can you test one of them now, to see if my idea works? Ok, I will try to look at during the weekend. > > > Anyway, if the issue here is with ram_size and its reduction was needed > > > for mpc85xx (at the time of introduction of that patch), what about > > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > > have same behavior as revert of that commit and for mpc85xx it would be > > > no change. This is what I mean: #ifdef CONFIG_MPC85xx if (gd->ram_base + ram_size < gd->ram_base) ram_size = ...; #endif > > > I agree that this code needs to be revisited, together with ram_top > > > issue and also code which fills DDR banks. Because really mapped memory > > > for u-boot and real size of DDR are two different things here. > > > > The issue here is that we see two now (given Fabio's reminder about > > another thread I had forgotten) of unintended consequences, on 32bit > > platforms trying to normally have 2GB of memory, which does not require > > special treatment. Running git grep get_effective_memsize and git grep 'gd->ram_top' shows the root of this issue: Different platforms, boards and common code use these things differently. This needs to be "fixed" = unified in whole codebase. We need a function which returns mappable memory for u-boot (intptr_t type is enough) and another function (or structure or whatever) which says total size of RAM as u64 type (to ensure that it would work also for 4GB SODIMM modules on pure 32-bit platforms). And then each place in u-boot code has to be modified to use the correct function. Second issue is then gd->ram_top. Either say 4GB for 32-bit ram_top type is not supported or say that zero value is special and represents 4GB. And also every place in u-boot code needs to be adjusted by this decision / code. Fixing both issues make easily break lot of boards (if done improperly) as it touches whole u-boot code base. So not easy task. > What I'm leaning towards right now even, is that since it's hard to test > the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if > their behavior also changed here, the 36bit platforms should just be > overriding get_effective_memsize. There are (at least) 3 situation: 1) if RAM is mapped to the end of physical address space (possibly just small e.g. 1GB) 2) if platform is >32-bit but running in 32-bit mode (so physical address is u64 because we do not have e.g. int36_t; but void* is 32-bit) 3) if RAM is exactly 4GB and u-boot is 32-bit And every one has different edge cases and cause different problems. Now, as I pointed above that every platform / board is using get_effective_memsize() differently, plus we have CONFIG_MAX_MEM_MAPPED option, it means that number of test matrix is really huge. It looks like that ARM issues are caused by the fact that RAM is mapped to the end of the physical address space (so it does not matter how big or small it is). And powerpc issue is 4GB of RAM together with running in 32-bit mode. Anyway, has U-Boot support for 32-bit x86 CPUs with PAE support? If yes, then I bet that there can be other edge cases when e.g. 8GB of DDR is connected.
Pull request efi-2023-01-rc5-4
The following changes since commit 9ddcdcc03cc6f0f46895604c589af17fdbdfe8b7: Merge tag 'u-boot-stm32-20230106' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2023-01-06 08:16:15 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-01-rc5-4 for you to fetch changes up to 4bba71ff83e2b2a1607c5b3b9995767691242b29: efi_loader: make .data section of *_efi.so files RW (2023-01-06 22:27:30 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/14631 Bbooting via EFI and via booti/bootz was susccessful on * Orange Pi PC * Pine A64 LTS Pull request efi-2023-01-rc5-4 UEFI: * correct the vexpress loaddr which collides with memory used by EFI * consider the EFI memory map for LMB memory reservation * avoid RWX section warnings for .data section of *_efi.so files Heinrich Schuchardt (4): vexpress: adjust loadaddr efi_loader: carve out efi_get_memory_map_alloc() lmb: consider EFI memory map efi_loader: make .data section of *_efi.so files RW arch/arm/lib/elf_aarch64_efi.lds | 8 +++- cmd/efidebug.c| 18 -- include/configs/vexpress_common.h | 1 + include/efi_loader.h | 3 +++ lib/efi_loader/efi_memory.c | 34 ++ lib/lmb.c | 36 6 files changed, 85 insertions(+), 15 deletions(-)
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 11:09:30PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 16:45:41 Tom Rini wrote: > > On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > > > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > > > > > The changes to this generic function, which is intended to help > > > > > > > with > > > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > > > effects > > > > > > > (which in turn lead to boot failures) on other platforms which > > > > > > > were > > > > > > > previously functional. > > > > > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit > > > > > > u-boot > > > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR > > > > > > module. > > > > > > > > > > > > Which platforms currently have broken u-boot without this revert? > > > > > > The > > > > > > only one which was reported is stm32mp but for it there different > > > > > > workaround patch waiting in the queue. > > > > > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > > > the stm32 problem shows, not everything is getting tested frequently > > > > > enough, so how many other cases are lurking out there. And, I think > > > > > overall issue is that the overflow check-and-change you introduce here > > > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > > > case you're dealing with, yes? > > > > > > > > I was planning to do big retest again after all powerpc patches are > > > > reviewed and merged... > > > > > > Yes, but can you test one of them now, to see if my idea works? > > Ok, I will try to look at during the weekend. OK, good, thanks. > > > > Anyway, if the issue here is with ram_size and its reduction was needed > > > > for mpc85xx (at the time of introduction of that patch), what about > > > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > > > have same behavior as revert of that commit and for mpc85xx it would be > > > > no change. > > This is what I mean: > > #ifdef CONFIG_MPC85xx > if (gd->ram_base + ram_size < gd->ram_base) > ram_size = ...; > #endif > > > > > I agree that this code needs to be revisited, together with ram_top > > > > issue and also code which fills DDR banks. Because really mapped memory > > > > for u-boot and real size of DDR are two different things here. > > > > > > The issue here is that we see two now (given Fabio's reminder about > > > another thread I had forgotten) of unintended consequences, on 32bit > > > platforms trying to normally have 2GB of memory, which does not require > > > special treatment. > > Running git grep get_effective_memsize and git grep 'gd->ram_top' shows > the root of this issue: Different platforms, boards and common code use > these things differently. This needs to be "fixed" = unified in whole > codebase. We need a function which returns mappable memory for u-boot > (intptr_t type is enough) and another function (or structure or > whatever) which says total size of RAM as u64 type (to ensure that it > would work also for 4GB SODIMM modules on pure 32-bit platforms). And > then each place in u-boot code has to be modified to use the correct > function. > > Second issue is then gd->ram_top. Either say 4GB for 32-bit ram_top type > is not supported or say that zero value is special and represents 4GB. > And also every place in u-boot code needs to be adjusted by this > decision / code. > > Fixing both issues make easily break lot of boards (if done improperly) > as it touches whole u-boot code base. So not easy task. > > > What I'm leaning towards right now even, is that since it's hard to test > > the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if > > their behavior also changed here, the 36bit platforms should just be > > overriding get_effective_memsize. > > There are (at least) 3 situation: > 1) if RAM is mapped to the end of physical address space (possibly just >small e.g. 1GB) > 2) if platform is >32-bit but running in 32-bit mode (so physical >address is u64 because we do not have e.g. int36_t; but void* is >32-bit) > 3) if RAM is exactly 4GB and u-boot is 32-bit > > And every one has different edge cases and cause different problems. > Now, as I pointed above that every platform / board is using > get_effective_memsize() differently, plus we have CONFIG_MAX_MEM_MAPPED > option, it means that number of test matrix is really huge. > > It looks like that ARM issues are caused by the fact that RAM is mapped > to the end of the physical address space (so it does not matter how big > or small it is). And powerpc issue is
Re: linksys wrt1900acs v2 boot problem
Hi all, On Fri, Jan 6, 2023 at 9:35 AM Pali Rohár wrote: > > Hello Dilyan! > > On Tuesday 28 September 2021 22:01:40 Dilyan Lazarov wrote: > > Hi, > > I have a problem with my linksys wrt1900acs. > > My main question is this a hardware problem or software problem? > > Is it possible to address? > > This looks like DDR3 training SW issue problem. Marek worked on in and > tried to address issue. He should know more details in this area. > > > I have started researching and have tried with "kwboot" under Windows VM - > > Ubuntu 20 - Linux but I have a problem with usb serial connection. I have > > tried several things but I understand that it isn't possible to start USB > > to Serial on a Windows VM. > > I will expect your response. > > Thank you in advance. > > You need to use kwboot natively. It was heavily tested on Linux and I > think it should work also on BSD systems. Windows systems are not really > supported and kwboot will not work on them. > > > All the best > > Dilyan > > > > I see the following Log from U-Boot with PuTTy under Windows 10: > > BootROM - 1.73 > > Booting from NAND flash > > > > General initialization - Version: 1.0.0 > > Detected Device ID 6820 > > High speed PHY - Version: 2.0 > > > > Init RD NAS topology Serdes Lane 3 is USB3 > > Serdes Lane 4 is SGMII > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 06 | SATA0 | > > | 1| 05 | PCIe0 | > > | 2| 06 | SATA1 | > > | 3| 05 | USB3 HOST1 | > > | 4| 05 | PCIe1 | > > | 5| 00 | SGMII2 | > > > > :** Link is Gen1, check the EP capability > > PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities > > :** Link is Gen1, check the EP capability > > PCIe, Idx 1: remains Gen1 > > High speed PHY - Ended Successfully > > DDR3 Training Sequence - Ver TIP-1.26.0 > > mvSysEnvGetTopologyUpdateInfo: TWSI Read failed > > WL Supp: IF 0 busId 1 Failed ! > > WL Supp: IF 0 failed > > ddr3TipDynamicWriteLevelingSupp failure > > DRAM initialization Failed (res 0x1) > > DDR3 run algorithm - FAILED 0x1 > > DDR3 Training Sequence - FAILED > > > > > > ** DRAM initialization failed! > > -- > > Dilyan > > Could you please try to update U-Boot to the new version? If the issue > is still there? Because DDR3 marvell driver was updated and it is > possible that also your issue is fixed now too... I can confirm that on the Synology DS116 board (also Armada 385, 1GB DDR3). The last tests I ran on this board were built with u-boot-2022.07 and did not see any problem with DDR3 training. All the best, Tony
Re: [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc()
On 2023-01-05, Heinrich Schuchardt wrote: > Carve out code from efidebug command used to read the memory map. > > Signed-off-by: Heinrich Schuchardt Tested on odroid-c2, fixes booting from extlinux.conf and boot.scr using booti, and still works using EFI boot as well. Thanks! Tested-by: Vagrant Cascadian live well, vagrant > --- > v2: > new patch > --- > cmd/efidebug.c | 18 -- > include/efi_loader.h| 3 +++ > lib/efi_loader/efi_memory.c | 34 ++ > 3 files changed, 41 insertions(+), 14 deletions(-) > > diff --git a/cmd/efidebug.c b/cmd/efidebug.c > index 569003ae2e..e6959ede93 100644 > --- a/cmd/efidebug.c > +++ b/cmd/efidebug.c > @@ -591,25 +591,15 @@ static void print_memory_attributes(u64 attributes) > static int do_efi_show_memmap(struct cmd_tbl *cmdtp, int flag, > int argc, char *const argv[]) > { > - struct efi_mem_desc *memmap = NULL, *map; > - efi_uintn_t map_size = 0; > + struct efi_mem_desc *memmap, *map; > + efi_uintn_t map_size; > const char *type; > int i; > efi_status_t ret; > > - ret = efi_get_memory_map(&map_size, memmap, NULL, NULL, NULL); > - if (ret == EFI_BUFFER_TOO_SMALL) { > - map_size += sizeof(struct efi_mem_desc); /* for my own */ > - ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size, > - (void *)&memmap); > - if (ret != EFI_SUCCESS) > - return CMD_RET_FAILURE; > - ret = efi_get_memory_map(&map_size, memmap, NULL, NULL, NULL); > - } > - if (ret != EFI_SUCCESS) { > - efi_free_pool(memmap); > + ret = efi_get_memory_map_alloc(&map_size, &memmap); > + if (ret != EFI_SUCCESS) > return CMD_RET_FAILURE; > - } > > printf("Type Start%.*s End%.*s Attributes\n", > EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc); > diff --git a/include/efi_loader.h b/include/efi_loader.h > index 0899e293e5..02d151b715 100644 > --- a/include/efi_loader.h > +++ b/include/efi_loader.h > @@ -734,6 +734,9 @@ efi_status_t efi_allocate_pool(enum efi_memory_type > pool_type, > efi_uintn_t size, void **buffer); > /* EFI pool memory free function. */ > efi_status_t efi_free_pool(void *buffer); > +/* Allocate and retrieve EFI memory map */ > +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size, > + struct efi_mem_desc **memory_map); > /* Returns the EFI memory map */ > efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size, > struct efi_mem_desc *memory_map, > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c > index 8d347f101f..32254d2433 100644 > --- a/lib/efi_loader/efi_memory.c > +++ b/lib/efi_loader/efi_memory.c > @@ -736,6 +736,40 @@ efi_status_t efi_get_memory_map(efi_uintn_t > *memory_map_size, > return EFI_SUCCESS; > } > > +/** > + * efi_get_memory_map_alloc() - allocate map describing memory usage > + * > + * The caller is responsible for calling FreePool() if the call succeeds. > + * > + * @memory_map buffer to which the memory map is written > + * @map_size size of the memory map > + * Return: status code > + */ > +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size, > + struct efi_mem_desc **memory_map) > +{ > + efi_status_t ret; > + > + *memory_map = NULL; > + *map_size = 0; > + ret = efi_get_memory_map(map_size, *memory_map, NULL, NULL, NULL); > + if (ret == EFI_BUFFER_TOO_SMALL) { > + *map_size += sizeof(struct efi_mem_desc); /* for the map */ > + ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, *map_size, > + (void **)memory_map); > + if (ret != EFI_SUCCESS) > + return ret; > + ret = efi_get_memory_map(map_size, *memory_map, > + NULL, NULL, NULL); > + if (ret != EFI_SUCCESS) { > + efi_free_pool(*memory_map); > + *memory_map = NULL; > + } > + } > + > + return ret; > +} > + > /** > * efi_add_conventional_memory_map() - add a RAM memory area to the map > * signature.asc Description: PGP signature