[PATCH] arm64: zynqmp: Remove description for 8T49N240

2023-11-07 Thread Michal Simek
8T49N240 driver was never upstreamed by IDT and there is no user of this
driver that's why remove description for this chip with also remove this
driver.

Signed-off-by: Michal Simek 
Reviewed-by: Radhey Shyam Pandey 
---

 arch/arm/dts/zynqmp-e-a2197-00-revA.dts |  8 +---
 arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 10 +-
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts 
b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
index bf7569c6dda5..cc57c2a1b0be 100644
--- a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
@@ -311,13 +311,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
-   clock_8t49n287: clock-generator@6c { /* u39 8T49N240 */
-   #clock-cells = <1>; /* author David Cater 
*/
-   compatible = "idt,8t49n240", "idt,8t49n241"; /* 
FIXME no driver for 240 */
-   reg = <0x6c>;
-   /* 
Documentation/devicetree/bindings/clock/idt,idt8t49n24x.txt */
-   /* FIXME there input via J241 Samtec CLK1 and 
CLK0 from U38 - selection PIN */
-   };
+   /* u39 8T49N240 */
};
i2c@3 { /* PMBUS2_INA226 */
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts 
b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
index c456c375ac80..9acccad40e77 100644
--- a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
@@ -532,15 +532,7 @@
/* u36 0xd8 or 0xde - pcie clk buf - 9ZML1241EKILF PCIe 
GEN 4 CLOCK BUFFER FIXME - no driver */
/* u37 0xd0 DNP - pcie clocking 1 - 9FGV1006BQ505LTGI - 
PCIe GEN 4 CLOCK GENERATOR FIXME - no linux driver */
/* u38 0xca - pcie clocking 2 - 9ZML1241EKILF PCIe GEN 
4 CLOCK BUFFER FIXME - no driver */
-   clock_8t49n287: clock-generator@60 { /* u39 8T49N240 - 
pcie clocking 3 */
-   #clock-cells = <1>; /* author David Cater 
*/
-   compatible = "idt,8t49n240", "idt,8t49n241"; /* 
FIXME no driver for 240 */
-   reg = <0x60>;
-   /* 
Documentation/devicetree/bindings/clock/idt,idt8t49n24x.txt */
-   /* FIXME there input via J241 Samtec CLK1 and 
CLK0 from U38 - selection PIN */
-
-   };
-
+   /* u39 8T49N240 - pcie clocking 3 */
};
};
 };
-- 
2.36.1



Re: [PATCH 1/3] board: ti: common: add rtc setup to common folder

2023-11-07 Thread Vignesh Raghavendra



On 08/11/23 04:51, Bryan Brattlof wrote:
> All of the starter kit boards for the am62xxx extended family utilize
> the same 32k crystal oscillator for a more accurate clock for the RTC
> instance. Add the setup the clock mux and debounce configuration to the
> common board directory so the entire am62xxx extended family can utilize
> it.
> 
> Signed-off-by: Bryan Brattlof 
> ---
>  board/ti/common/Kconfig |  8 +++
>  board/ti/common/rtc.c   | 47 +
>  2 files changed, 55 insertions(+)
>  create mode 100644 board/ti/common/rtc.c
> 
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 49edd98014ab7..56a65c0a402bb 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -1,3 +1,11 @@
> +config BOARD_HAS_32K_RTC_CRYSTAL
> + bool "Enable the 32k crystial for RTC"
> + help
> +Some of Texas Instrument's Starter-Kit boards have
> +an onboard 32k crystal. Select this option if you wish Uboot
> +to enable this crystal for Linux
> + default n
> +
>  config TI_I2C_BOARD_DETECT
>   bool "Support for Board detection for TI platforms"
>   help
> diff --git a/board/ti/common/rtc.c b/board/ti/common/rtc.c
> new file mode 100644
> index 0..e117a927765c5
> --- /dev/null
> +++ b/board/ti/common/rtc.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * RTC setup for TI Platforms
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +#include 
> +#include 
> +#include 
> +
> +#define WKUP_CTRLMMR_DBOUNCE_CFG1 0x04504084
> +#define WKUP_CTRLMMR_DBOUNCE_CFG2 0x04504088
> +#define WKUP_CTRLMMR_DBOUNCE_CFG3 0x0450408c
> +#define WKUP_CTRLMMR_DBOUNCE_CFG4 0x04504090
> +#define WKUP_CTRLMMR_DBOUNCE_CFG5 0x04504094
> +#define WKUP_CTRLMMR_DBOUNCE_CFG6 0x04504098
> +
> +void board_rtc_init(void)
> +{
> + u32 val;
> +
> + /* We have 32k crystal, so lets enable it */
> + val = readl(MCU_CTRL_LFXOSC_CTRL);
> + val &= ~(MCU_CTRL_LFXOSC_32K_DISABLE_VAL);
> + writel(val, MCU_CTRL_LFXOSC_CTRL);
> +
> + /* Add any TRIM needed for the crystal here.. */
> + /* Make sure to mux up to take the SoC 32k from the crystal */
> + writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL,
> +MCU_CTRL_DEVICE_CLKOUT_32K_CTRL);
> +
> + /* Setup debounce conf registers - arbitrary values.
> +  * Times are approx
> +  */
> + /* 1.9ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG1, 0x1);
> + /* 5ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG2, 0x5);
> + /* 20ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG3, 0x14);
> + /* 46ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG4, 0x18);
> + /* 100ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG5, 0x1c);
> + /* 156ms debounce @ 32k */
> + writel(WKUP_CTRLMMR_DBOUNCE_CFG6, 0x1f);
> +}


Pad Debounce settings has nothing to do with RTC. This doesn't belong to
board_rtc_init()

-- 
Regards
Vignesh


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Ilias Apalodimas
Hi
I am late to the party but

[...]

> > I can't help to think that you like the FDT as a well understood and
> > flexible general purpose data structure. And it can indeed be used as a
> > configuration file, especially since you have the parser in your code
> > already - the FIT image is a good example. But this is distinct from the
> > Devicetree as a hardware description.
>
> Indeed, although I don't see such a bright line between the
> hardware/software concepts. In any case, the RNG is a hardware
> feature, surely?
>
> > Would it help to separate the two use cases: to go with one DTB that is
> > strictly for hardware configuration, as described by the DT bindings in
> > the Linux kernel tree, and a *separate* DT blob that carries configuration
> > information, U-Boot specific data (like memory layout, SRAM usage, device
> > priorities, packaging information)? TF-A chose this approach: there is
> > hw-config, which is the hardware DTB, and there is fw-config, which is a
> > FDT blob as well, but describes the firmware layout and other configuration
> > information.
>
> Or we could just not do that and have a single DT :-)
>
> I wondered where that idea came from and it has been mentioned before.

Yes, that was me.  I still think this would solve a *ton* of problems
and I am willing to explore that.
The only thing I haven't thought through is DTs and limited SRAM in
the SPL, but I don't think this should be a showstopper.

Thanks
/Ilias
> TF-A should be a C library called by bootloaders, BTW.
>
> I haven't replied to everything above...I believe I have had this same
> discussion about a dozen times over the last 6 years. I did try to
> send a patch to state my POV at some point, but I think it got NAKed
> :-)
>
> Regards,
> Simon
>
>
> >
> > Cheers,
> > Andre
> >
> > > > > > > > But as Heinrich also said: those instructions are not
> > > > > > > > peripherals, they are part of an instruction set extensions,
> > > > > > > > the same story as with x86's RDRAND instruction. We don't have
> > > > > > > > those in ACPI or so as well, because CPUID has you covered.
> > > > > > > > The same on ARM, ID_AA64ISAR0_EL1 is readable on every chip
> > > > > > > > (outside of EL0), and tells you whether you have the RNDR
> > > > > > > > register or not. IIUC RISC-V is slightly different here, since
> > > > > > > > not all ISA extensions are covered by CSRs, hence some of them
> > > > > > > > indeed listed in the DT.
> > > > > > > >
> > > > > > > > So a proper solution(TM) would be to split this up in
> > > > > > > > architectural *instructions* and proper TRNG *devices*, maybe
> > > > > > > > wrapping this up in some function that tests both. This is
> > > > > > > > roughly what the kernel does, somewhat abstracted by the
> > > > > > > > concept of "entropy sources", which could be TRNG devices, CPU
> > > > > > > > instructions, interrupt jitter or even "instruction execution
> > > > > > > > jitter"[1], with the latter two definitely not being devices
> > > > > > > > really at all.
> > > > > > > >
> > > > > > > > But I don't know if U-Boot wants to go through the hassle of
> > > > > > > > this whole framework, as we tend to implement things much
> > > > > > > > easier. But a simple get_cpu_random() function, implemented
> > > > > > > > per architecture, and with some kind of success flag, should
> > > > > > > > be easy enough to do. Then either the users (UEFI?) explicitly
> > > > > > > > call this before trying UCLASS_RNG, or we wrap this for every
> > > > > > > > RNG user.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Andre
> > > > > > > >
> > > > > > > > > > > > > VExpress64# rng 1
> > > > > > > > > > > > > : f3 88 b6 d4 24 da 49 ca 49 f7 9e 66 5f 12
> > > > > > > > > > > > > 07 b2  $.I.I..f_...
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Essentially in any case were you have multiple drivers
> > > > > > > > > > > > for the same device using uclass_get_device(, 0, ) and
> > > > > > > > > > > > uclass_find_first_device() will only give you the
> > > > > > > > > > > > first bound device and not the first successfully
> > > > > > > > > > > > probed device. Furthermore neither of this functions
> > > > > > > > > > > > causes probing. This is not restricted to the RNG
> > > > > > > > > > > > drivers but could also happen with multiple TPM
> > > > > > > > > > > > drivers or multiple watchdogs.
> > > > > > > > > > > >
> > > > > > > > > > > > This patch is related to the problem:
> > > > > > > > > > > >
> > > > > > > > > > > > [PATCH v1] rng: add dm_rng_read_default() helper
> > > > > > > > > > > > https://lore.kernel.org/u-boot/4e28a388-f5b1-4cf7-b0e3-b12a876d0...@gmx.de/T/#me44263ec9141e3ea65ee232aa9a411fc6201bd95
> > > > > > > > > > > >
> > > > > > > > > > > > We have weak function platform_get_rng_device() which
> > > > > > > > > > > > should be moved to drivers/rng/rng-uclass.c.
> > > > > > > > > > > >
> > > > > > > > > > > > We could add a function to 

[UBOOT PATCH v3] test/py: net: Add a TFTP put test

2023-11-07 Thread Love Kumar
Execute tftpput command for uploading files to a server and validate its
size & CRC32.

Signed-off-by: Love Kumar 
---
Changes in v2:
- Add marking for cmd_tftpput config

Chnages in v3:
- Add filename to upload as part of env file
---
 test/py/tests/test_net.py | 71 +++
 1 file changed, 71 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index b2241ae6a482..2495608786de 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -7,6 +7,7 @@
 import pytest
 import u_boot_utils
 import uuid
+import datetime
 
 """
 Note: This test relies on boardenv_* containing configuration values to define
@@ -51,6 +52,8 @@ env__net_tftp_readable_file = {
 'addr': 0x1000,
 'size': 5058624,
 'crc32': 'c2244b26',
+'timeout': 5,
+'fnu': 'ubtest-upload.bin',
 }
 
 # Details regarding a file that may be read from a NFS server. This variable
@@ -326,3 +329,71 @@ def test_net_pxe_get(u_boot_console):
 
 assert expected_text_default in output
 assert "Config file 'default.boot' found" in output
+
+@pytest.mark.buildconfigspec("cmd_crc32")
+@pytest.mark.buildconfigspec("cmd_net")
+@pytest.mark.buildconfigspec("cmd_tftpput")
+def test_net_tftpput(u_boot_console):
+"""Test the tftpput command.
+
+A file is downloaded from the TFTP server and then uploaded to the TFTP
+server, its size and its CRC32 are validated.
+
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip("Network not initialized")
+
+f = u_boot_console.config.env.get("env__net_tftp_readable_file", None)
+if not f:
+pytest.skip("No TFTP readable file to read")
+
+addr = f.get("addr", None)
+if not addr:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+sz = f.get("size", None)
+timeout = f.get("timeout", u_boot_console.p.timeout)
+fn = f["fn"]
+fnu = f.get("fnu", 
"_".join([datetime.datetime.now().strftime("%y%m%d%H%M%S"), fn]))
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("tftpboot %x %s" % (addr, fn))
+
+assert "TIMEOUT" not in output
+assert expected_text in output
+
+expected_tftpb_crc = f.get("crc32", None)
+
+output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+assert expected_tftpb_crc in output
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command(
+"tftpput $fileaddr $filesize $serverip:%s" % (fnu)
+)
+
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+addr = addr + sz
+assert "TIMEOUT" not in output
+assert "Access violation" not in output
+assert expected_text in output
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("tftpboot %x %s" % (addr, fnu))
+
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+assert "TIMEOUT" not in output
+assert expected_text in output
+
+output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+assert expected_tftpb_crc in output
-- 
2.25.1



Re: [PATCH 4/4] serial: s5p: Improve coding style

2023-11-07 Thread Simon Glass
On Tue, 7 Nov 2023 at 12:06, Sam Protsenko  wrote:
>
> Just some minor style fixes. No functional change.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/serial/serial_s5p.c | 34 ++
>  1 file changed, 18 insertions(+), 16 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 01/25] spl: blk_fs: Fix uninitialized return value when we can't get a blk_desc

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> Initialize ret to avoid returning garbage if blk_get_devnum_by_uclass_id
> fails.
>
> Fixes: 8ce6a2e1757 ("spl: blk: Support loading images from fs")
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_blk_fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 05/25] spl: Remove NULL assignments in spl_load_info

2023-11-07 Thread Simon Glass
Hi Sean,

On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> Remove NULL assignments to fields in spl_load_info when .load doesn't
> reference these fields. This can result in more efficient code. filename
> must stay even if it is unused, since load_simple_fit uses it.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  arch/arm/mach-sunxi/spl_spi_sunxi.c | 2 --
>  common/spl/spl_fat.c| 1 -
>  common/spl/spl_mmc.c| 2 --
>  common/spl/spl_nand.c   | 4 
>  common/spl/spl_spi.c| 2 --
>  common/spl/spl_ymodem.c | 1 -
>  6 files changed, 12 deletions(-)

This makes me wonder if we should have a function to clear it out
(using memset() and perhaps a bl_len parameter)? Having said that, the
info-field use is pretty self-contained with these files.

Reviewed-by: Simon Glass 


Re: [PATCH v6 19/25] spl: Convert net to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the net load method to use spl_load. As a result, it also
> adds support for LOAD_FIT_FULL and IMX images.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Explicitly initialize load_info members
>
> Changes in v5:
> - Rework to load header in spl_load
>
>  common/spl/spl_net.c  | 29 +
>  include/spl_load.h|  1 +
>  test/image/spl_load_net.c |  2 ++
>  3 files changed, 8 insertions(+), 24 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 17/25] spl: Convert mmc to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the mmc loader to spl_load. Legacy images are handled by
> spl_load (via spl_parse_image_header), so mmc_load_legacy can be
> omitted. To accurately determine whether mmc_load_image_raw_sector is used
> (which might not be the case if SYS_MMCSD_FS_BOOT is enabled), we introduce
> a helper config SYS_MMCSD_RAW_MODE. This ensures we can inline spl_load
> correctly when a board only boots from filesystems. We still need to check
> for SPL_MMC, since some boards enable configure raw mode even without MMC
> support.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Add SYS_MMCSD_RAW_MODE to help determine whether SPL_MMC loads
>   anything directly.
> - Explicitly initialize load_info members
>
> Changes in v5:
> - Rework to load header in spl_load
>
>  common/spl/Kconfig   |  8 
>  common/spl/spl_mmc.c | 89 
>  include/spl_load.h   |  1 +
>  test/image/spl_load_fs.c |  3 --
>  4 files changed, 16 insertions(+), 85 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 25/25] spl: fat: Add option to disable DMA alignment

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> If we don't DMA-align buffers we pass to FAT, it will align them itself.
> This behaviour likely should be deprecated in favor of
> CONFIG_BOUNCE_BUFFER, but that's a task for another series. For the
> meantime, don't bother aligning the buffer unless we had been doing so in
> the past.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/Kconfig  | 18 --
>  common/spl/spl_blk_fs.c |  5 -
>  common/spl/spl_fat.c|  5 -
>  3 files changed, 24 insertions(+), 4 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 07/25] spl: Take advantage of bl_len's power-of-twoness

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> bl_len must be a power of two, so we can use ALIGN instead of roundup and
> similar tricks to avoid divisions.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_fit.c   | 2 +-
>  common/spl/spl_imx_container.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 24/25] spl: spi: Consolidate spi_load_image_os into spl_spi_load_image

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> spi_load_image_os performs almost the same steps as the non-falcon-boot
> path of spl_spi_load_image. The load address is different, and it also
> loads a device tree, but that's it. Refactor the boot process so that
> they can both use the same load function.
>
> Signed-off-by: Sean Anderson 
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - Rework to load header in spl_load
>
> Changes in v2:
> - New
>
>  common/spl/spl_spi.c | 54 
>  1 file changed, 14 insertions(+), 40 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Simon Glass
Hi Andre,

On Tue, 7 Nov 2023 at 08:12, Andre Przywara  wrote:
>
> On Tue, 7 Nov 2023 05:22:58 -0700
> Simon Glass  wrote:
>
> Hi Simon,
>
> > Hi Andre,
> >
> > On Tue, 7 Nov 2023 at 04:27, Andre Przywara 
> > wrote:
> > >
> > > On Tue, 7 Nov 2023 01:08:15 +
> > > Simon Glass  wrote:
> > >
> > > Hi Simon,
> > >
> > > > On Mon, 6 Nov 2023 at 21:55, Andre Przywara 
> > > > wrote:
> > > > >
> > > > > On Mon, 6 Nov 2023 13:38:39 -0700
> > > > > Simon Glass  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > > > > Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > > > > Simon Glass  wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > > Hi Heinrich,
> > > > > > > > > >
> > > > > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > > > > Heinrich Schuchardt
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > > >
> > > > > > > > > > > >> The Zkr ISA extension (ratified Nov 2021)
> > > > > > > > > > > >> introduced the seed CSR. It provides an interface
> > > > > > > > > > > >> to a physical entropy source.
> > > > > > > > > > > >>
> > > > > > > > > > > >> A RNG driver based on the seed CSR is provided. It
> > > > > > > > > > > >> depends on mseccfg.sseed being set in the SBI
> > > > > > > > > > > >> firmware.
> > > > > > > > > > > >
> > > > > > > > > > > > As you might have seen, I added a similar driver for
> > > > > > > > > > > > the respective Arm functionality:
> > > > > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > > > > >
> > > > > > > > > > > > And I see that you seem to use the same mechanism to
> > > > > > > > > > > > probe and init the driver: U_BOOT_DRVINFO and fail
> > > > > > > > > > > > in probe() if the feature is not implemented.
> > > > > > > > > > > > One downside of this approach is that the driver is
> > > > > > > > > > > > always loaded (and visible in the DM tree), even
> > > > > > > > > > > > with the feature not being available. That doesn't
> > > > > > > > > > > > seem too much of a problem on the first glance, but
> > > > > > > > > > > > it occupies a device number, and any subsequent
> > > > > > > > > > > > other DM_RNG devices (like virtio-rng) typically get
> > > > > > > > > > > > higher device numbers. So without the feature, but
> > > > > > > > > > > > with virtio-rng, I get: VExpress64# rng 0 No RNG
> > > > > > > > > > > > device
> > > > > > > > > >
> > > > > > > > > > Why do we get this? If the device is not there, the
> > > > > > > > > > bind() function can return -ENODEV
> > > > > > > > > >
> > > > > > > > > > I see this in U-Boot:
> > > > > > > > > >
> > > > > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > > > > >
> > > > > > > > > > We should not use this.
> > > > > > > > >
> > > > > > > > > Agreed.
> > > > > > > > >
> > > > > > > > > > Use the devicetree.
> > > > > > > > >
> > > > > > > > > No, this is definitely not something for the DT, at least
> > > > > > > > > not on ARM. It's perfectly discoverable via the
> > > > > > > > > architected CPU ID registers. Similar to PCI and USB
> > > > > > > > > devices, which we don't probe via the DT as well.
> > > > > > > > >
> > > > > > > > > It's arguably not proper "driver" material per se, as I've
> > > > > > > > > argued before, but it's the simplest solution and fits in
> > > > > > > > > nicely otherwise.
> > > > > > > > >
> > > > > > > > > I was wondering if it might be something for UCLASS_CPU,
> > > > > > > > > something like a "CPU feature bus": to let devices
> > > > > > > > > register on one on the many CPU features (instead of
> > > > > > > > > compatible strings), then only bind() those drivers it the
> > > > > > > > > respective bit is set.
> > > > > > > > >
> > > > > > > > > Does that make sense? Would that be doable without boiling
> > > > > > > > > the ocean? As I don't know if we see many users apart from
> > > > > > > > > this.
> > > > > > > >
> > > > > > > > I have seen this so many times, where people want to avoid
> > > > > > > > putting things in the DT and then are surprised that
> > > > > > > > everything is difficult, broken and confusing. Why not just
> > > > > > > > follow the rules? It is not just about whether we can avoid
> > > > > > > > it, etc. It is about how devices fit together cohesively in
> > > > > > > > the system, and how U-Boot operates.
> > > > > > >
> > > > > > > A devicetree is only for peripherals *that cannot 

Re: [PATCH v4 1/8] binman: ti-secure: Add support for firewalling entities

2023-11-07 Thread Simon Glass
Hi Manorit,

On Tue, 7 Nov 2023 at 02:40, Manorit Chawdhry  wrote:
>
> Hi Simon,
>
> On 08:29-20231012, Simon Glass wrote:
> > Hi Manorit,
> >
> > On Wed, 11 Oct 2023 at 22:46, Manorit Chawdhry  wrote:
> > >
> > > Hi Simon,
> > >
> > > On 20:41-20231011, Simon Glass wrote:
> > > > Hi Manorit,
> > > >
> > > > On Tue, 10 Oct 2023 at 23:25, Manorit Chawdhry  
> > > > wrote:
> > > > >
> > > > > We can now firewall entities while loading them through our secure
> > > > > entity TIFS, the required information should be present in the
> > > > > certificate that is being parsed by TIFS.
> > > > >
> > > > > The following commit adds the support to enable the certificates to be
> > > > > generated if the firewall configurations are present in the binman 
> > > > > dtsi
> > > > > nodes.
> > > > >
> > > > > Signed-off-by: Manorit Chawdhry 
> > > > > ---
> > > > >  tools/binman/btool/openssl.py   | 16 +++-
> > > > >  tools/binman/etype/ti_secure.py | 90 
> > > > > +
> > > > >  tools/binman/etype/x509_cert.py |  3 +-
> > > > >  3 files changed, 106 insertions(+), 3 deletions(-)
> > > > >
> > > >
> > > > Reviewed-by: Simon Glass 
> > > >
> > > > I'm still a little worried about the error reporting if the user
> > > > leaves out a property. Does it do the right thing?
> > > >
> > >
> > > I did make a test also along the lines that would check all the
> > > firewalling properties and just auth-in-place isn't checked at this
> > > stage and people could end up adding the firewalling node without
> > > auth-in-place. Do you want to cover that test case as well? Regarding
> > > the other firewalling properties ( immitating the test by removing
> > > "id"), We get this:
> > >
> > > [..]
> > >   AR  spl/common/spl/built-in.o
> > >   LD  spl/u-boot-spl
> > >   OBJCOPY spl/u-boot-spl-nodtb.bin
> > >   SYM spl/u-boot-spl.sym
> > >   CAT spl/u-boot-spl-dtb.bin
> > >   COPYspl/u-boot-spl.bin
> > >   BINMAN  .binman_stamp
> > > binman: id can't be None in firewall node
> >
> > That's a bit vague...at least it should show the full path to the node
> > that failure, e.g. use self.Raise(). Also, I assume the property is
> > missing and the None refers to the Python value for the var. Better to
> > provide a nice error.
>
> I was working on this so I realised that Firewall class that I have is
> not an etype so I have hacked a bit around to get that self.Raise in but
> hoping that shouldn't be much of a problem..
>
> Does this error look okay now?
>
> [..]
>   COPYspl/u-boot-spl.bin
>   BINMAN  .binman_stamp
> binman: Node '/binman/ti-spl/fit/images/atf/ti-secure': Subnode 'firewall' is 
> missing properties: id,region

Yes

>
> >
> > Any possible user error should ideally be checked, to avoid later confusion.
> >
> > See Entry.ensure_props()
>
> I was thinking of using this as well but I noticed that this gets called
> in the beginning itself and since the Firewall class that I have is not
> an etype then I won't be getting the information that all this is
> failing in firewalling related node and might be confused with debugging
> in ti-secure hence thought of updating the dataclass only with the
> function only as you suggested below. Thanks for the suggestions!

That's fine, so long as you have the node path as you do above...it is
pretty easy for people to understand it when you have that.

>
> Regards,
> Manorit
>
> >
> > You could add an optional argument - the list of props to check. If
> > present it could use that instead of self.required_props
> >
> > Hmm better might be to have a new function which tells the user that
> > since the firewall property is present, it needs these others ones
> > too.
> >
> > Regards,
> > Simon

Regards.

Simon


Re: [PATCH v6 15/25] spl: Convert ext to use spl_load

2023-11-07 Thread Simon Glass
Hi Sean,

On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the ext load method to use spl_load. As a consequence, it
> also adds support for FIT and IMX images.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Explicitly initialize load_info members
>
> Changes in v5:
> - Rework to load header in spl_load
>
>  common/spl/spl_ext.c | 36 ++--
>  include/spl_load.h   |  1 +
>  test/image/spl_load_fs.c |  9 ++---
>  3 files changed, 25 insertions(+), 21 deletions(-)

Reviewed-by: Simon Glass 

but nit below

>
> diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
> index af836ca15b8..d280b69c387 100644
> --- a/common/spl/spl_ext.c
> +++ b/common/spl/spl_ext.c
> @@ -2,25 +2,35 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> +static ulong spl_fit_read(struct spl_load_info *load, ulong file_offset,
> + ulong size, void *buf)
> +{
> +   int ret;
> +   loff_t actlen;
> +
> +   ret = ext4fs_read(buf, file_offset, size, );
> +   if (ret)
> +   return ret;
> +   return actlen;
> +}
> +
>  int spl_load_image_ext(struct spl_image_info *spl_image,
>struct spl_boot_device *bootdev,
>struct blk_desc *block_dev, int partition,
>const char *filename)
>  {
> s32 err;
> -   struct legacy_img_hdr *header;
> -   loff_t filelen, actlen;
> +   loff_t filelen;
> struct disk_partition part_info = {};
> -
> -   header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
> +   struct spl_load_info load;
>
> if (part_get_info(block_dev, partition, _info)) {
> printf("spl: no partition table found\n");
> @@ -42,20 +52,10 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
> puts("spl: ext4fs_open failed\n");
> goto end;
> }
> -   err = ext4fs_read((char *)header, 0, sizeof(struct legacy_img_hdr), 
> );
> -   if (err < 0) {
> -   puts("spl: ext4fs_read failed\n");
> -   goto end;
> -   }
>
> -   err = spl_parse_image_header(spl_image, bootdev, header);
> -   if (err < 0) {
> -   puts("spl: ext: failed to parse image header\n");
> -   goto end;
> -   }
> -
> -   err = ext4fs_read(map_sysmem(spl_image->load_addr, filelen), 0, 
> filelen,
> - );
> +   spl_set_bl_len(, 1);
> +   load.read = spl_fit_read;
> +   err = spl_load(spl_image, bootdev, , filelen, 0);
>
>  end:
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> diff --git a/include/spl_load.h b/include/spl_load.h
> index 406f8b577b2..65aa6bb4493 100644
> --- a/include/spl_load.h
> +++ b/include/spl_load.h
> @@ -95,6 +95,7 @@ static inline int _spl_load(struct spl_image_info 
> *spl_image,
>   * inline if there is one caller, and extern otherwise.
>   */
>  #define SPL_LOAD_USERS \
> +   IS_ENABLED(CONFIG_SPL_FS_EXT4) + \
> 0
>
>  #if SPL_LOAD_USERS > 1
> diff --git a/test/image/spl_load_fs.c b/test/image/spl_load_fs.c
> index 59d0244d44b..01559e98c4f 100644
> --- a/test/image/spl_load_fs.c
> +++ b/test/image/spl_load_fs.c
> @@ -422,20 +422,23 @@ static int spl_test_mmc(struct unit_test_state *uts, 
> const char *test_name,
> spl_mmc_clear_cache();
> spl_fat_force_reregister();
>
> -   if (type == LEGACY &&
> -   spl_test_mmc_fs(uts, test_name, type, create_ext2, false))
> +   if (spl_test_mmc_fs(uts, test_name, type, create_ext2, false))
> return CMD_RET_FAILURE;
>
> -   if (type != IMX8 &&
> +   if (type != IMX8 && type != LEGACY_LZMA &&
> spl_test_mmc_fs(uts, test_name, type, create_fat, false))
> return CMD_RET_FAILURE;

This is not a command.

How about:

if (type != IMX8 && type != LEGACY_LZMA &&
   ut_assertok(spl_test_mmc_fs(...

>
> +   if (type == LEGACY_LZMA)
> +   return 0;
> +
> return do_spl_test_load(uts, test_name, type,
> SPL_LOAD_IMAGE_GET(0, BOOT_DEVICE_MMC1,
>spl_mmc_load_image),
> spl_test_mmc_write_image);
>  }
>  SPL_IMG_TEST(spl_test_mmc, LEGACY, DM_FLAGS);
> +SPL_IMG_TEST(spl_test_mmc, LEGACY_LZMA, DM_FLAGS);
>  SPL_IMG_TEST(spl_test_mmc, IMX8, DM_FLAGS);
>  SPL_IMG_TEST(spl_test_mmc, FIT_EXTERNAL, DM_FLAGS);
>  SPL_IMG_TEST(spl_test_mmc, FIT_INTERNAL, DM_FLAGS);
> --
> 2.37.1
>

Regards,
Simon


Re: [PATCH v6 18/25] spl: Convert nand to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the nand load method to use spl_load. nand_page_size may not
> be valid until after nand_spl_load_image is called (see e.g. fsl_ifc_spl),
> so we set bl_len in spl_nand_read. Since spl_load reads the header for us,
> we can remove that argument from spl_nand_load_element.
>
> There are two possible regressions which could result from this commit.
> First, we ask for a negative address from spl_get_load_buffer. That is,
> instead of
>
> header = spl_get_load_buffer(0, sizeof(*header));
>
> we do
>
> header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
>
> this could cause a problem if spl_get_load_buffer does not return valid
> memory for negative offsets. Second, we now set bl_len for legacy images.
> This can cause memory up to a bl_len - 1 before the image load address to
> be written, which might not have been the case before. If this turns out to
> be a problem, we can add an option for a bounce buffer.
>
> We can't load FITs with external data with SPL_LOAD_FIT_FULL, so disable the
> test in that case. No boards enable SPL_NAND_SUPPORT and SPL_LOAD_FIT_FULL, so
> this is not a regression.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_nand.c  | 70 +-
>  include/spl_load.h |  1 +
>  test/image/spl_load_nand.c |  2 ++
>  3 files changed, 19 insertions(+), 54 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/4] serial: s5p: Remove common.h inclusion

2023-11-07 Thread Simon Glass
On Tue, 7 Nov 2023 at 12:06, Sam Protsenko  wrote:
>
> It's not really needed here anymore. Remove it, as common.h is going
> away at some point.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/serial/serial_s5p.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 16/25] spl: Convert fat to spl_load

2023-11-07 Thread Simon Glass
Hi Sean,

On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the fat loader to use spl_load. Some platforms are very
> tight on space, so we take care to only include the code we really need.
>
> Signed-off-by: Sean Anderson 
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - Rework to load header in spl_load
>
> Changes in v3:
> - Fix failing on success
>
>  common/spl/spl_fat.c | 56 +---
>  include/spl_load.h   |  1 +
>  test/image/spl_load_fs.c |  3 +--
>  3 files changed, 20 insertions(+), 40 deletions(-)

Reviewed-by: Simon Glass 

nits below

>
> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
> index a0c34eba48f..569f2b32928 100644
> --- a/common/spl/spl_fat.c
> +++ b/common/spl/spl_fat.c
> @@ -11,8 +11,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,58 +66,38 @@ int spl_load_image_fat(struct spl_image_info *spl_image,
>const char *filename)
>  {
> int err;
> -   struct legacy_img_hdr *header;
> +   loff_t size;
> +   struct spl_load_info load;
>
> err = spl_register_fat_device(block_dev, partition);
> if (err)
> goto end;
>
> -   header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
> -
> -   err = file_fat_read(filename, header, sizeof(struct legacy_img_hdr));
> -   if (err <= 0)
> -   goto end;
> -
> -   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL) &&
> -   image_get_magic(header) == FDT_MAGIC) {
> -   err = file_fat_read(filename,
> -   map_sysmem(CONFIG_SYS_LOAD_ADDR, 0), 0);
> -   if (err <= 0)
> -   goto end;
> -   err = spl_parse_image_header(spl_image, bootdev,
> -map_sysmem(CONFIG_SYS_LOAD_ADDR,
> -   err));
> -   if (err == -EAGAIN)
> -   return err;
> -   if (err == 0)
> -   err = 1;
> -   } else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> -   image_get_magic(header) == FDT_MAGIC) {
> -   struct spl_load_info load;
> -
> -   debug("Found FIT\n");
> -   load.read = spl_fit_read;
> -   spl_set_bl_len(, ARCH_DMA_MINALIGN);
> -   load.priv = (void *)filename;
> -
> -   return spl_load_simple_fit(spl_image, , 0, header);
> -   } else {
> -   err = spl_parse_image_header(spl_image, bootdev, header);
> +   /*
> +* Avoid pulling in this function for other image types since we are
> +* very short on space on some boards.
> +*/
> +   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL)) {
> +   err = fat_size(filename, );
> if (err)
> goto end;
> -
> -   err = file_fat_read(filename, map_sysmem(spl_image->load_addr,
> -spl_image->size), 0);
> +   } else {
> +   size = 0;
> }
>
> +   load.read = spl_fit_read;
> +   spl_set_bl_len(, ARCH_DMA_MINALIGN);
> +   load.priv = (void *)filename;
> +   err = spl_load(spl_image, bootdev, , size, 0);
> +
>  end:
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> -   if (err <= 0)
> +   if (err < 0)
> printf("%s: error reading image %s, err - %d\n",
>__func__, filename, err);

Do we still need this sort of #ifdef? I thought printf() would melt
away without SPL_LIBCOMMON_SUPPORT? I haven't looked though. Also it
isn't related to your patch.

>  #endif
>
> -   return (err <= 0);
> +   return err;
>  }
>
>  #if CONFIG_IS_ENABLED(OS_BOOT)
> diff --git a/include/spl_load.h b/include/spl_load.h
> index 65aa6bb4493..5e0460d956d 100644
> --- a/include/spl_load.h
> +++ b/include/spl_load.h
> @@ -96,6 +96,7 @@ static inline int _spl_load(struct spl_image_info 
> *spl_image,
>   */
>  #define SPL_LOAD_USERS \
> IS_ENABLED(CONFIG_SPL_FS_EXT4) + \
> +   IS_ENABLED(CONFIG_SPL_FS_FAT) + \
> 0
>
>  #if SPL_LOAD_USERS > 1
> diff --git a/test/image/spl_load_fs.c b/test/image/spl_load_fs.c
> index 01559e98c4f..333df2dfb53 100644
> --- a/test/image/spl_load_fs.c
> +++ b/test/image/spl_load_fs.c
> @@ -425,8 +425,7 @@ static int spl_test_mmc(struct unit_test_state *uts, 
> const char *test_name,
> if (spl_test_mmc_fs(uts, test_name, type, create_ext2, false))
> return CMD_RET_FAILURE;
>
> -   if (type != IMX8 && type != LEGACY_LZMA &&
> -   spl_test_mmc_fs(uts, test_name, type, create_fat, false))
> +   if (spl_test_mmc_fs(uts, test_name, type, create_fat, false))
> return CMD_RET_FAILURE;
>
> if (type == LEGACY_LZMA)
> --
> 2.37.1
>

Regards,
Simon


Re: [PATCH v6 13/25] test: spl: Support testing LEGACY_LZMA filesystem images

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> These will soon be supported, so we need to be able to test it. Export the
> lzma data and generally use the same process in spl_test_mmc_fs as
> do_spl_test_load.  If we end up needing this in third place in the future,
> it would probably be good to refactor things out.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  include/test/spl.h   |  4 
>  test/image/spl_load.c|  4 +++-
>  test/image/spl_load_fs.c | 23 ++-
>  3 files changed, 25 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH] serial: s5p: Use dev_read_addr_ptr() to get base address

2023-11-07 Thread Simon Glass
On Tue, 7 Nov 2023 at 13:13, Sam Protsenko  wrote:
>
> As the address read from device tree is being cast to a pointer, it's
> better to use dev_read_addr_ptr() API for getting that address. The more
> detailed explanation can be found in commit a12a73b66476 ("drivers: use
> dev_read_addr_ptr when cast to pointer").
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/serial/serial_s5p.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 20/25] spl: Convert nor to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the nor load method to use spl_load. As a result it also
> adds support for LOAD_FIT_FULL. Since this is the last caller of
> spl_load_legacy_img, it has been removed.
>
> We can't load FITs with external data with SPL_LOAD_FIT_FULL, so disable the
> test in that case. No boards enable SPL_NOR_SUPPORT and SPL_LOAD_FIT_FULL, so
> this is not a regression.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Fix LZMA support
> - Fix load address
> - Explicitly initialize load_info members
>
> Changes in v5:
> - Rework to load header in spl_load
>
>  common/spl/spl_legacy.c   | 61 ---
>  common/spl/spl_nor.c  | 40 +
>  include/spl_load.h|  1 +
>  test/image/spl_load_nor.c |  2 ++
>  4 files changed, 10 insertions(+), 94 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 23/25] spl: Convert spi to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the spi load method to use spl_load. The address used for
> LOAD_FIT_FULL may be different, but there are no in-tree users of that
> config. Since payload_offs is only used without OS_BOOT, we defer its
> initialization.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Fix soft reset after loading from SPI
>
> Changes in v5:
> - Rework to load header in spl_load
>
>  common/spl/spl_spi.c  | 80 +++
>  include/spl_load.h|  1 +
>  test/image/spl_load_spi.c |  1 +
>  3 files changed, 15 insertions(+), 67 deletions(-)
>

Reviewed-by: Simon Glass 

I am just amazed at how many times this FIT code got copied...there is
something wrong with U-Boot's development model here.


Re: [PATCH v6 14/25] spl: Add generic spl_load function

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> Implementers of SPL_LOAD_IMAGE_METHOD have to correctly determine what
> type of image is being loaded and then call the appropriate image load
> function correctly. This is tricky, because some image load functions
> expect the whole image to already be loaded (CONFIG_SPL_LOAD_FIT_FULL),
> some will load the image automatically using spl_load_info.read()
> (CONFIG_SPL_LOAD_FIT/CONFIG_SPL_LOAD_IMX_CONTAINER), and some just parse
> the header and expect the caller to do the actual loading afterwards
> (legacy/raw images). Load methods often only support a subset of the
> above methods, meaning that not all image types can be used with all
> load methods. Further, the code to invoke these functions is
> duplicated between different load functions.
>
> To address this problem, this commit introduces a "spl_load" function.
> It aims to handle image detection and correct invocation of each of the
> parse/load functions.
>
> Although this function generally results in a size reduction with
> several users, it tends to bloat boards with only a single user.
> This is generally because programmers open-coding the contents of this
> function can make optimizations based on the specific loader. For
> example, NOR flash is memory-mapped, so it never bothers calling
> load->read. The compiler can't really make these optimizations across
> translation units. LTO solves this, but it is only available on some
> arches. To address this, perform "pseudo-LTO" by inlining spl_load when
> there are one or fewer users. At the moment, there are no users, so
> define SPL_LOAD_USERS to be 0.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Use pseudo-LTO for spl_load
> - Align reads to bl_len
>
> Changes in v5:
> - Load the header in spl_load as well
> - Don't bother trying to DMA-align the buffer, since we can't really fix
>   it.
>
> Changes in v4:
> - Fix format specifiers in debug prints
> - Reword/fix some of the doc comments for spl_load
>
> Changes in v3:
> - Fix using ffs instead of fls
> - Fix using not initializing bl_len when info->filename was NULL
>
> Changes in v2:
> - Use reverse-xmas-tree style for locals in spl_simple_read. This is not
>   complete, since overhead depends on bl_mask.
>
>  common/spl/spl.c   |  10 
>  include/spl_load.h | 135 +
>  2 files changed, 145 insertions(+)
>  create mode 100644 include/spl_load.h
>

Reviewed-by: Simon Glass 

Definitely a lot of effort on code size!


Re: [PATCH v6 11/25] spl: nand: Remove spl_nand_legacy_read

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> Now that spl_nand_fit_read works in units of bytes, it can be combined with
> spl_nand_legacy_read. Rename the resulting function spl_nand_read, since it
> is no longer FIT-specific.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_nand.c | 33 +
>  1 file changed, 13 insertions(+), 20 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 12/25] spl: legacy: Split off LZMA decompression into its own function

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> To allow for easier reuse of this functionality, split it off into its
> own function.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_legacy.c | 73 ++---
>  include/spl.h   | 13 
>  2 files changed, 52 insertions(+), 34 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 2/4] serial: s5p: Use livetree API to get "id" property

2023-11-07 Thread Simon Glass
Hi Sam,

On Tue, 7 Nov 2023 at 12:06, Sam Protsenko  wrote:
>
> Use dev_read_u8_default() instead of fdtdec_get_int() to read the "id"
> property from device tree, as suggested in [1]. dev_* API is already
> used in this driver, so there is no reason to stick to fdtdec_* API.
> This also fixes checkpatch warning:
>
> WARNING: Use the livetree API (dev_read_...)
>
> [1] doc/develop/driver-model/livetree.rst
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/serial/serial_s5p.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> index 177215535676..c57bdd059ea6 100644
> --- a/drivers/serial/serial_s5p.c
> +++ b/drivers/serial/serial_s5p.c
> @@ -20,8 +20,6 @@
>  #include 
>  #include 
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  enum {
> PORT_S5P = 0,
> PORT_S5L
> @@ -220,8 +218,7 @@ static int s5p_serial_of_to_plat(struct udevice *dev)
>
> plat->reg = (struct s5p_uart *)addr;
> plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
> -   plat->port_id = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> -   "id", dev_seq(dev));
> +   plat->port_id = dev_read_u8_default(dev, "id", dev_seq(dev));
>
> if (port_type == PORT_S5L) {
> plat->rx_fifo_count_shift = S5L_RX_FIFO_COUNT_SHIFT;
> --
> 2.39.2
>

Really this property should not be needed anymore. Can you figure out
how to drop it?

Regards,
Simon


Re: [PATCH v6 21/25] spl: Convert NVMe to spl_load

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> This converts the blk load method (used exclusively by NVMe) to use
> spl_load. As a consequence, it also adds support for LOAD_FIT_FULL and
> IMX images.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Fix invalid return from spl_blk_load_image
> - Explicitly initialize load_info members
>
> Changes in v5:
> - New
>
>  common/spl/spl_blk_fs.c  | 66 +++-
>  include/spl_load.h   |  1 +
>  test/image/spl_load_fs.c |  2 ++
>  3 files changed, 14 insertions(+), 55 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 3/4] serial: s5p: Use named constants for register values

2023-11-07 Thread Simon Glass
Hi Sam,

On Tue, 7 Nov 2023 at 12:06, Sam Protsenko  wrote:
>
> Get rid of magic numbers in s5p_serial_init() when writing to UART
> registers. While at it, use BIT() macro for existing constants when
> appropriate.
>
> No functional change.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/serial/serial_s5p.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 03/25] spl: Make SHOW_ERRORS depend on LIBCOMMON

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> The purpose of SHOW_ERRORS is to print extra information. Make it depend
> on LIBCOMMON to avoid having to check for two configs.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Tom Rini 
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - New
>
>  common/spl/Kconfig | 1 +
>  common/spl/spl.c   | 3 +--
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v6 04/25] spl: semihosting: Don't close fd before spl_load_simple_fit

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> On real hardware, semihosting calls tends to have a large constant
> overhead (on the order of tens of milliseconds). Reduce the number of
> calls by one by reusing the existing fd in smh_fit_read, and closing it
> at the end of spl_smh_load_image.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_semihosting.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v6 09/25] spl: Remove filename from spl_load_info

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> For filesystems, filename serves the same purpose as priv. However,
> spl_load_fit_image also uses it to determine whether to use a DMA-aligned
> buffer. This is beneficial for FAT, which uses a bounce-buffer if the
> destination is not DMA-aligned. Remove this logic, and instead achieve it
> by setting bl_len to ARCH_DMA_MINALIGN. With this done, we can remove
> filename entirely.
>
> One wrinkle bears mentioning: because filesystems are not block-based, we
> may read less than the size passed to spl_load_info.read. This can happen
> if the file size is not DMA-aligned. This is fine as long as we read the
> amount we originally wanted to. Modify the conditions for callers of
> spl_load_info.read to check against the original, unaligned size to avoid
> failing spuriously.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  arch/arm/mach-sunxi/spl_spi_sunxi.c |  1 -
>  common/spl/spl_blk_fs.c | 10 ++
>  common/spl/spl_fat.c|  6 +++---
>  common/spl/spl_fit.c| 23 +--
>  common/spl/spl_imx_container.c  |  8 +---
>  common/spl/spl_mmc.c|  2 --
>  common/spl/spl_nand.c   |  3 ---
>  common/spl/spl_semihosting.c|  1 -
>  common/spl/spl_spi.c|  2 --
>  common/spl/spl_ymodem.c |  1 -
>  include/spl.h   |  2 --
>  test/image/spl_load_os.c|  1 -
>  12 files changed, 15 insertions(+), 45 deletions(-)

Er, I think

Reviewed-by: Simon Glass 

but I wonder if this patch could be split?


Re: [PATCH v6 06/25] spl: Remove dev from spl_load_info

2023-11-07 Thread Simon Glass
Hi Sean,

On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> dev and priv server the same purpose, and are never set at the same time.

serve

> Remove dev and convert all users to priv. While we're at it, reorder bl_len
> to be last for better alignment.

It's a bit unfortunate to drop the device, isn't it? But then, as
before, this is self-contained so Is suppose it doesn't matter what we
store.

Reviewed-by: Simon Glass 

Regards,
Simon



>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  common/spl/spl_mmc.c   | 6 +++---
>  common/spl/spl_spi.c   | 6 +++---
>  drivers/usb/gadget/f_sdp.c | 6 +++---
>  include/spl.h  | 4 +---
>  4 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 6d9137c32e0..3d7551a7dae 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -65,7 +65,7 @@ static int mmc_load_legacy(struct spl_image_info *spl_image,
>  static ulong h_spl_load_read(struct spl_load_info *load, ulong sector,
>  ulong count, void *buf)
>  {
> -   struct mmc *mmc = load->dev;
> +   struct mmc *mmc = load->priv;
>
> return blk_dread(mmc_get_blk_desc(mmc), sector, count, buf);
>  }
> @@ -105,7 +105,7 @@ int mmc_load_image_raw_sector(struct spl_image_info 
> *spl_image,
> struct spl_load_info load;
>
> debug("Found FIT\n");
> -   load.dev = mmc;
> +   load.priv = mmc;
> load.filename = NULL;
> load.bl_len = mmc->read_bl_len;
> load.read = h_spl_load_read;
> @@ -114,7 +114,7 @@ int mmc_load_image_raw_sector(struct spl_image_info 
> *spl_image,
>valid_container_hdr((void *)header)) {
> struct spl_load_info load;
>
> -   load.dev = mmc;
> +   load.priv = mmc;
> load.filename = NULL;
> load.bl_len = mmc->read_bl_len;
> load.read = h_spl_load_read;
> diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
> index d83d70f2f33..af7a28e7c25 100644
> --- a/common/spl/spl_spi.c
> +++ b/common/spl/spl_spi.c
> @@ -59,7 +59,7 @@ static int spi_load_image_os(struct spl_image_info 
> *spl_image,
>  static ulong spl_spi_fit_read(struct spl_load_info *load, ulong sector,
>   ulong count, void *buf)
>  {
> -   struct spi_flash *flash = load->dev;
> +   struct spi_flash *flash = load->priv;
> ulong ret;
>
> ret = spi_flash_read(flash, sector, count, buf);
> @@ -151,7 +151,7 @@ static int spl_spi_load_image(struct spl_image_info 
> *spl_image,
> struct spl_load_info load;
>
> debug("Found FIT\n");
> -   load.dev = flash;
> +   load.priv = flash;
> load.filename = NULL;
> load.bl_len = 1;
> load.read = spl_spi_fit_read;
> @@ -162,7 +162,7 @@ static int spl_spi_load_image(struct spl_image_info 
> *spl_image,
>valid_container_hdr((void *)header)) {
> struct spl_load_info load;
>
> -   load.dev = flash;
> +   load.priv = flash;
> load.filename = NULL;
> load.bl_len = 1;
> load.read = spl_spi_fit_read;
> diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
> index ee9384fb37e..1b16b7eb452 100644
> --- a/drivers/usb/gadget/f_sdp.c
> +++ b/drivers/usb/gadget/f_sdp.c
> @@ -744,7 +744,7 @@ static ulong sdp_load_read(struct spl_load_info *load, 
> ulong sector,
>  {
> debug("%s: sector %lx, count %lx, buf %lx\n",
>   __func__, sector, count, (ulong)buf);
> -   memcpy(buf, (void *)(load->dev + sector), count);
> +   memcpy(buf, (void *)(load->priv + sector), count);
> return count;
>  }
>
> @@ -844,7 +844,7 @@ static int sdp_handle_in_ep(struct spl_image_info 
> *spl_image,
> struct spl_load_info load;
>
> debug("Found FIT\n");
> -   load.dev = header;
> +   load.priv = header;
> load.bl_len = 1;
> load.read = sdp_load_read;
> spl_load_simple_fit(spl_image, , 0,
> @@ -857,7 +857,7 @@ static int sdp_handle_in_ep(struct spl_image_info 
> *spl_image,
> valid_container_hdr((void *)header)) {
> struct spl_load_info load;
>
> -   load.dev = header;
> +   load.priv = header;
> load.bl_len = 1;
> load.read = sdp_load_read;
> 

Re: [PATCH v6 10/25] spl: Only support bl_len when we have to

2023-11-07 Thread Simon Glass
On Sun, 5 Nov 2023 at 19:26, Sean Anderson  wrote:
>
> Aligning addresses and sizes causes overhead which is unnecessary when we
> are not loading from block devices. Remove bl_len when it is not needed.
>
> For example, on iot2050 we save 144 bytes with this patch (once the rest of
> this series is applied):
>
> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-144 (-144)
> Function old new   delta
> spl_load_simple_fit  920 904 -16
> load_simple_fit  496 444 -52
> spl_spi_load_image   384 308 -76
> Total: Before=87431, After=87287, chg -0.16%
>
> We use panic() instead of BUILD_BUG_ON in spl_set_bl_len because we still
> need to be able to compile it for things like mmc_load_image_raw_sector,
> even if that function will not be used.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - New
>
>  arch/arm/mach-imx/spl_imx_romapi.c  |  8 
>  arch/arm/mach-sunxi/spl_spi_sunxi.c |  2 +-
>  common/spl/Kconfig  | 14 +-
>  common/spl/spl_blk_fs.c |  2 +-
>  common/spl/spl_fat.c|  2 +-
>  common/spl/spl_fit.c|  6 +++---
>  common/spl/spl_imx_container.c  | 10 +-
>  common/spl/spl_legacy.c |  4 ++--
>  common/spl/spl_mmc.c|  4 ++--
>  common/spl/spl_nand.c   |  6 +++---
>  common/spl/spl_net.c|  2 +-
>  common/spl/spl_nor.c|  8 
>  common/spl/spl_ram.c|  2 +-
>  common/spl/spl_semihosting.c|  2 +-
>  common/spl/spl_spi.c|  4 ++--
>  common/spl/spl_ymodem.c |  2 +-
>  drivers/usb/gadget/f_sdp.c  |  4 ++--
>  include/spl.h   | 25 +
>  test/image/Kconfig  |  1 +
>  test/image/spl_load.c   |  9 -
>  test/image/spl_load_os.c|  2 +-
>  21 files changed, 78 insertions(+), 41 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [tom.r...@gmail.com: Fwd: New Defects reported by Coverity Scan for Das U-Boot]

2023-11-07 Thread Alexander Gendin
On Mon, Nov 06, 2023 at 03:27:52PM -0500, Tom Rini  wrote:

> Hey all,
> 
> Here's the latest report. I _think_ I passed the right options to
> get_maintainer.pl such that it would only look far enough back in git to
> find the likely authors (along with listed maintainers of the files).
> 
> -- Forwarded message -
> From: 
> Date: Mon, Nov 6, 2023 at 2:58 PM
> Subject: New Defects reported by Coverity Scan for Das U-Boot
> To: 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Das
> U-Boot found with Coverity Scan.
> 
> 13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
> 5 defect(s), reported by Coverity Scan earlier, were marked fixed in
> the recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 13 of 13 defect(s)
> 
> <...skipped...>
> *** CID 467404:  Control flow issues  (DEADCODE)
> /test/cmd/mbr.c: 217 in build_mbr_parts()
> 211 return 1;
> 212 strcat(cur_buf, mbr_parts_p5);
> 213 bytes_remaining -= cur_str_size;
> 214
> 215 }
> 216 else if (num_parts > 5)
> >>> CID 467404:  Control flow issues  (DEADCODE)
> >>> Execution cannot reach this statement: "return 1U;".
> 217 return 1;
> 218 }
> 219 }
> 220 }
> 221
> 222 cur_str_size = sizeof(mbr_parts_tail);
> <...skipped...>
> 
> -- 
> Tom

Hi Tom,

Thanks for the report.

The patch to fix CID 467404 has been sent to the mailing list.

Regards,
Alex

-- 

[PATCH] test: cmd: mbr: Remove unreachable code

2023-11-07 Thread Alexander Gendin
Fix Coverity (CID 467404): Control flow issues (DEADCODE).
Fix code indentation.

Reported-by: Coverity (CID 467404)
Signed-off-by: Alexander Gendin 
---
 test/cmd/mbr.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/test/cmd/mbr.c b/test/cmd/mbr.c
index 5d7402154d..46b78e706c 100644
--- a/test/cmd/mbr.c
+++ b/test/cmd/mbr.c
@@ -205,16 +205,14 @@ static unsigned build_mbr_parts(char *buf, size_t 
buf_size, unsigned num_parts)
bytes_remaining -= cur_str_size;
 
}
-   else if (num_parts == 5) {
-   cur_str_size = sizeof(mbr_parts_p5);
-   if (cur_str_size + 1 > bytes_remaining)
-   return 1;
-   strcat(cur_buf, mbr_parts_p5);
-   bytes_remaining -= cur_str_size;
+   else if (num_parts == 5) {
+   cur_str_size = sizeof(mbr_parts_p5);
+   if (cur_str_size + 1 > bytes_remaining)
+   return 1;
+   strcat(cur_buf, mbr_parts_p5);
+   bytes_remaining -= cur_str_size;
 
-   }
-   else if (num_parts > 5)
-   return 1;
+   }
}
}
}
-- 
2.41.0


Re: [RESEND PATCH v10 7/9] efi_loader: support boot from URI device path

2023-11-07 Thread Masahisa Kojima
Hi Ilias,

On Tue, 7 Nov 2023 at 18:37, Ilias Apalodimas
 wrote:
>
> Kojima-san
>
> On Mon, 6 Nov 2023 at 13:40, Masahisa Kojima  
> wrote:
> [...]
>
> > +/**
> > + * search_default_file() - search default file
> > + *
> > + * @dev:   pointer to the UCLASS_BLK or UCLASS_PARTITION udevice
> > + * @dp:pointer to default file device path
> > + * Return: status code
> > + */
> > +static efi_status_t search_default_file(struct udevice *dev,
> > +   struct efi_device_path **dp)
> > +{
> > +   efi_status_t ret;
> > +   efi_handle_t handle;
> > +   u16 *default_file_name = NULL;
> > +   struct efi_file_handle *root, *f;
> > +   struct efi_device_path *full_path;
> > +   struct efi_device_path *device_path;
> > +   struct efi_device_path *file_path = NULL;
> > +   struct efi_simple_file_system_protocol *file_system;
> > +
> > +   if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
> > +   log_warning("DM_TAG_EFI not found\n");
> > +   return EFI_INVALID_PARAMETER;
> > +   }
> > +
> > +   ret = EFI_CALL(bs->open_protocol(handle, 
> > _simple_file_system_protocol_guid,
> > +(void **)_system, efi_root, 
> > NULL,
> > +EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> > +   if (ret != EFI_SUCCESS)
> > +   return ret;
> > +
> > +   ret = EFI_CALL(file_system->open_volume(file_system, ));
> > +   if (ret != EFI_SUCCESS)
> > +   return ret;
> > +
> > +   file_path = efi_dp_from_file(NULL, "/EFI/BOOT/" BOOTEFI_NAME);
> > +   default_file_name = efi_dp_str(file_path);
> > +   if (!default_file_name) {
> > +   ret = EFI_OUT_OF_RESOURCES;
> > +   goto err;
> > +   }
> > +
> > +   ret = EFI_CALL(root->open(root, , default_file_name,
> > + EFI_FILE_MODE_READ, 0));
> > +   efi_free_pool(default_file_name);
> > +   if (ret != EFI_SUCCESS)
> > +   goto err;
> > +
> > +   EFI_CALL(f->close(f));
> > +
> > +   ret = EFI_CALL(bs->open_protocol(handle, _guid_device_path,
> > +(void **)_path, efi_root, 
> > NULL,
> > +EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> > +   if (ret != EFI_SUCCESS)
> > +   goto err;
> > +
> > +   full_path = efi_dp_append(device_path, file_path);
> > +   if (!full_path) {
> > +   ret = EFI_OUT_OF_RESOURCES;
> > +   goto err;
> > +   }
> > +
> > +   *dp = full_path;
> > +err:
> > +   efi_free_pool(file_path);
> > +
> > +   return ret;
> > +}
>
> We discussed this offline, adding it here for completeness.
> What is happening here, is that we are mounting the blkmap disk and
> try to search boot options on the fly.
> Since u-boot will scan all boot options once a disk is probed, the
> boot option you are trying to find is already added in the EFI
> bootmgr.  I think it's going to be easier to search for that specific
> boot option instead of re-scanning for it on the fly.

I'm now trying to implement loading a default file
from the auto-generated boot option, I would like to consult with you.

My v9 implementation to load the default file
from blkmap device is as follows.

/**
 * try_load_default_file() - try to load the default file
 *
 * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
 * then try to load with the default boot file(e.g. EFI/BOOT/BOOTAA64.EFI).
 *
 * @devpointer to the UCLASS_BLK or
UCLASS_PARTITION udevice
 * @image_handle:  pointer to handle for newly installed image
 * Return: status code
 */
static efi_status_t try_load_default_file(struct udevice *dev,
 efi_handle_t *image_handle)
{
   efi_status_t ret;
   efi_handle_t handle;
   struct efi_handler *handler;
   struct efi_device_path *file_path;
   struct efi_device_path *device_path;

   if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
   log_warning("DM_TAG_EFI not found\n");
   return EFI_INVALID_PARAMETER;
   }

   ret = efi_search_protocol(handle,

_simple_file_system_protocol_guid, );
   if (ret != EFI_SUCCESS)
   return ret;

   ret = EFI_CALL(bs->open_protocol(handle, _guid_device_path,
(void **)_path, efi_root, NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL));
   if (ret != EFI_SUCCESS)
   return ret;

   file_path = expand_media_path(device_path);
   ret = EFI_CALL(efi_load_image(true, efi_root, file_path, NULL, 0,
 image_handle));
   efi_free_pool(file_path);

   return ret;
}

Note that try_load_default_file() is repeatedly called
with all child partition devices until 

[PATCH v1 4/4] serial: npcm: support skip uart clock setting

2023-11-07 Thread Jim Liu
Skip the uart clock setting if CONFIG_SYS_SKIP_UART_INIT
is enabled.
Fix divisor error.

Signed-off-by: Jim Liu 
---
 drivers/serial/serial_npcm.c | 39 ++--
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/serial/serial_npcm.c b/drivers/serial/serial_npcm.c
index 76ac7cb80d..6bf3a943a2 100644
--- a/drivers/serial/serial_npcm.c
+++ b/drivers/serial/serial_npcm.c
@@ -83,8 +83,11 @@ static int npcm_serial_setbrg(struct udevice *dev, int 
baudrate)
struct npcm_uart *uart = plat->reg;
u16 divisor;
 
+   if (IS_ENABLED(CONFIG_SYS_SKIP_UART_INIT))
+   return 0;
+
/* BaudOut = UART Clock / (16 * [Divisor + 2]) */
-   divisor = DIV_ROUND_CLOSEST(plat->uart_clk, 16 * baudrate + 2) - 2;
+   divisor = DIV_ROUND_CLOSEST(plat->uart_clk, 16 * baudrate) - 2;
 
setbits_8(>lcr, LCR_DLAB);
writeb(divisor & 0xff, >dll);
@@ -97,29 +100,35 @@ static int npcm_serial_setbrg(struct udevice *dev, int 
baudrate)
 static int npcm_serial_probe(struct udevice *dev)
 {
struct npcm_serial_plat *plat = dev_get_plat(dev);
-   struct npcm_uart *uart = plat->reg;
+   struct npcm_uart *uart;
struct clk clk, parent;
u32 freq;
int ret;
 
plat->reg = dev_read_addr_ptr(dev);
-   freq = dev_read_u32_default(dev, "clock-frequency", 0);
+   uart = plat->reg;
 
-   ret = clk_get_by_index(dev, 0, );
-   if (ret < 0)
-   return ret;
+   if (!IS_ENABLED(CONFIG_SYS_SKIP_UART_INIT)) {
+   freq = dev_read_u32_default(dev, "clock-frequency", 2400);
 
-   ret = clk_get_by_index(dev, 1, );
-   if (!ret) {
-   ret = clk_set_parent(, );
-   if (ret)
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
return ret;
-   }
 
-   ret = clk_set_rate(, freq);
-   if (ret < 0)
-   return ret;
-   plat->uart_clk = ret;
+   ret = clk_get_by_index(dev, 1, );
+   if (!ret) {
+   ret = clk_set_parent(, );
+   if (ret)
+   return ret;
+   }
+
+   if (freq) {
+   ret = clk_set_rate(, freq);
+   if (ret < 0)
+   return ret;
+   }
+   plat->uart_clk = clk_get_rate();
+   }
 
/* Disable all interrupt */
writeb(0, >ier);
-- 
2.25.1



[PATCH v1 3/4] configs: arbel: Enable full functions

2023-11-07 Thread Jim Liu
Enable more functions/commands for arbel evb.

Signed-off-by: Jim Liu 
---
 configs/arbel_evb_defconfig | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/configs/arbel_evb_defconfig b/configs/arbel_evb_defconfig
index 6cfb5a7d32..dddfa298c9 100644
--- a/configs/arbel_evb_defconfig
+++ b/configs/arbel_evb_defconfig
@@ -4,6 +4,8 @@ CONFIG_TEXT_BASE=0x06208000
 CONFIG_SYS_MALLOC_LEN=0x24
 CONFIG_SYS_MALLOC_F_LEN=0x1000
 CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x06208000
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_OFFSET=0x3C
 CONFIG_ENV_SECT_SIZE=0x1000
@@ -19,10 +21,12 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="run common_bootargs; run romboot"
+CONFIG_LAST_STAGE_INIT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot>"
 CONFIG_SYS_MAXARGS=32
 CONFIG_SYS_BOOTM_LEN=0x140
+CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
@@ -31,14 +35,17 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_RNG=y
 CONFIG_CMD_UUID=y
+CONFIG_CMD_AES=y
 CONFIG_CMD_HASH=y
 CONFIG_CMD_TPM=y
+CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
@@ -49,6 +56,7 @@ CONFIG_NPCM_AES=y
 CONFIG_NPCM_SHA=y
 CONFIG_NPCM_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_NPCM=y
 # CONFIG_INPUT is not set
 CONFIG_MISC=y
 CONFIG_NPCM_HOST=y
@@ -56,9 +64,12 @@ CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_NPCM=y
 CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_GOOGLE=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_WINBOND=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_BITBANGMII=y
+CONFIG_BITBANGMII_MULTI=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_GIGE=y
 CONFIG_ETH_DESIGNWARE=y
@@ -87,11 +98,15 @@ CONFIG_TPM2_FTPM_TEE=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_NPCM=y
-CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_OHCI_GENERIC=y
 CONFIG_USB_OHCI_NPCM=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Nuvoton"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0416
+CONFIG_USB_GADGET_PRODUCT_NUM=0x
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_LIB_HW_RAND=y
 CONFIG_TPM=y
 CONFIG_SHA_HW_ACCEL=y
-- 
2.25.1



[PATCH v1 2/4] board: nuvoton: update console environment variable

2023-11-07 Thread Jim Liu
If CONFIG_SYS_SKIP_UART_INIT is enabled, calculate the
current baud rate and update the "console" environment
variable.

Signed-off-by: Jim Liu 
---
 board/nuvoton/arbel_evb/Kconfig |  1 +
 board/nuvoton/common/Kconfig|  9 +
 board/nuvoton/common/Makefile   |  1 +
 board/nuvoton/common/common.c   | 71 +
 board/nuvoton/common/common.h   | 11 +
 board/nuvoton/poleg_evb/Kconfig |  1 +
 6 files changed, 94 insertions(+)
 create mode 100644 board/nuvoton/common/Kconfig
 create mode 100644 board/nuvoton/common/Makefile
 create mode 100644 board/nuvoton/common/common.c
 create mode 100644 board/nuvoton/common/common.h

diff --git a/board/nuvoton/arbel_evb/Kconfig b/board/nuvoton/arbel_evb/Kconfig
index 33c589f1fb..ed1c1ad8ee 100644
--- a/board/nuvoton/arbel_evb/Kconfig
+++ b/board/nuvoton/arbel_evb/Kconfig
@@ -15,4 +15,5 @@ config SYS_MEM_TOP_HIDE
help
  Reserve memory for ECC/GFX/OPTEE/TIP/CP.
 
+source "board/nuvoton/common/Kconfig"
 endif
diff --git a/board/nuvoton/common/Kconfig b/board/nuvoton/common/Kconfig
new file mode 100644
index 00..61de7bc5f8
--- /dev/null
+++ b/board/nuvoton/common/Kconfig
@@ -0,0 +1,9 @@
+if ARCH_NPCM
+
+config SYS_SKIP_UART_INIT
+   bool "Skip UART initialization"
+   depends on NPCM_SERIAL
+   help
+ Select this if the UART you want to use is already
+ initialized by the time U-Boot starts its execution.
+endif
diff --git a/board/nuvoton/common/Makefile b/board/nuvoton/common/Makefile
new file mode 100644
index 00..52e77185c4
--- /dev/null
+++ b/board/nuvoton/common/Makefile
@@ -0,0 +1 @@
+obj-y  += common.o
diff --git a/board/nuvoton/common/common.c b/board/nuvoton/common/common.c
new file mode 100644
index 00..6da9d93e80
--- /dev/null
+++ b/board/nuvoton/common/common.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 Nuvoton Technology Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UART_DLL   0x0
+#define UART_DLM   0x4
+#define UART_LCR   0xc
+#define LCR_DLAB   BIT(7)
+
+int board_set_console(void)
+{
+   const unsigned long baudrate_table[] = CFG_SYS_BAUDRATE_TABLE;
+   struct udevice *dev = gd->cur_serial_dev;
+   unsigned int baudrate, max_delta;
+   void __iomem *uart_reg;
+   struct clk clk;
+   char string[32];
+   u32 uart_clk;
+   u8 dll, dlm;
+   u16 divisor;
+   int ret, i;
+
+   /* If uart init is skipped, update the actual baudrate in boot 
arguments */
+   if (!IS_ENABLED(CONFIG_SYS_SKIP_UART_INIT))
+   return 0;
+   if (!dev)
+   return 0;
+   uart_reg = dev_read_addr_ptr(dev);
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return 0;
+   uart_clk = clk_get_rate();
+   setbits_8(uart_reg + UART_LCR, LCR_DLAB);
+   dll = readb(uart_reg + UART_DLL);
+   dlm = readb(uart_reg + UART_DLM);
+   clrbits_8(uart_reg + UART_LCR, LCR_DLAB);
+   divisor = dll | (dlm << 8);
+   baudrate =  uart_clk / ((16 * (divisor + 2)));
+   for (i = 0; i < ARRAY_SIZE(baudrate_table); ++i) {
+   max_delta = baudrate_table[i] / 20;
+   if (abs(baudrate - baudrate_table[i]) < max_delta) {
+   /* The baudrate is supported */
+   gd->baudrate = baudrate_table[i];
+   break;
+   }
+   }
+   if (i == ARRAY_SIZE(baudrate_table)) {
+   /* current baudrate is not suitable, set to default */
+   divisor = DIV_ROUND_CLOSEST(uart_clk, 16 * gd->baudrate) - 2;
+   setbits_8(uart_reg + UART_LCR, LCR_DLAB);
+   writeb(divisor & 0xff, uart_reg + UART_DLL);
+   writeb(divisor >> 8, uart_reg + UART_DLM);
+   clrbits_8(uart_reg + UART_LCR, LCR_DLAB);
+   udelay(100);
+   printf("\r\nUART(source %u): change baudrate from %u to %u\n",
+  uart_clk, baudrate, uart_clk / ((16 * (divisor + 2;
+   }
+   debug("Set env baudrate=%u\n", gd->baudrate);
+   snprintf(string, sizeof(string), "ttyS0,%un8", gd->baudrate);
+   env_set("console", string);
+
+   return 0;
+}
diff --git a/board/nuvoton/common/common.h b/board/nuvoton/common/common.h
new file mode 100644
index 00..64a09670cb
--- /dev/null
+++ b/board/nuvoton/common/common.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Nuvoton Technology Corp.
+ */
+
+#ifndef _NUVOTON_COMMON_H
+#define _NUVOTON_COMMON_H
+
+int board_set_console(void);
+
+#endif /* _NUVOTON_COMMON_H */
diff --git a/board/nuvoton/poleg_evb/Kconfig b/board/nuvoton/poleg_evb/Kconfig
index d3f4c1dd81..6f7f1ef157 100644
--- a/board/nuvoton/poleg_evb/Kconfig
+++ b/board/nuvoton/poleg_evb/Kconfig
@@ -22,4 +22,5 @@ config TARGET_POLEG_EVB
 
 endchoice
 
+source 

[PATCH v1 1/4] arm: dts: npcm845-evb: fix/add node and aliases name

2023-11-07 Thread Jim Liu
Modify spi and usb aliases name.
Add dt-binding for usb phy define and fix usb phy reset error.
Add tpm and otpee node.

Signed-off-by: Jim Liu 
---
 arch/arm/dts/nuvoton-common-npcm8xx.dtsi  |  2 +-
 arch/arm/dts/nuvoton-npcm845-evb.dts  | 29 ++-
 arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi  |  2 +-
 include/dt-bindings/phy/nuvoton,npcm-usbphy.h | 14 +
 4 files changed, 38 insertions(+), 9 deletions(-)
 create mode 100644 include/dt-bindings/phy/nuvoton,npcm-usbphy.h

diff --git a/arch/arm/dts/nuvoton-common-npcm8xx.dtsi 
b/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
index fabe5925b7..8478367711 100644
--- a/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
+++ b/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
@@ -133,7 +133,7 @@
ranges = <0x0 0x0 0xf000 0x0030>,
<0xfff0 0x0 0xfff0 0x00016000>;
 
-   spi1: spi@201000 {
+   pspi: spi@201000 {
compatible = "nuvoton,npcm845-pspi";
reg = <0x201000 0x1000>;
pinctrl-names = "default";
diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts 
b/arch/arm/dts/nuvoton-npcm845-evb.dts
index a93666cb41..0d3aaa0fff 100644
--- a/arch/arm/dts/nuvoton-npcm845-evb.dts
+++ b/arch/arm/dts/nuvoton-npcm845-evb.dts
@@ -2,6 +2,8 @@
 // Copyright (c) 2021 Nuvoton Technology tomer.mai...@nuvoton.com
 
 /dts-v1/;
+
+#include 
 #include "nuvoton-npcm845.dtsi"
 #include "nuvoton-npcm845-pincfg.dtsi"
 
@@ -46,10 +48,10 @@
spi1 = 
spi3 = 
spi4 = 
-   spi5 = 
+   spi5 = 
usb0 = 
usb1 = 
-   usb2 = 
+   usb2 = 
};
 
chosen {
@@ -60,6 +62,17 @@
reg = <0x0 0x0 0x0 0x4000>;
};
 
+   tpm@0 {
+   compatible = "microsoft,ftpm";
+   };
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+
vsbr2: vsbr2 {
compatible = "regulator-npcm845";
regulator-name = "vr2";
@@ -149,6 +162,8 @@
snps,reset-active-low;
snps,reset-delays-us = <0 1 100>;
snps,reset-gpio = < 2 GPIO_ACTIVE_LOW>;/* gpio162 */
+   phy-supply = <>;
+   phy-supply-microvolt = <180>;
status = "okay";
 };
 
@@ -179,7 +194,7 @@
status = "okay";
 };
 
- {
+ {
status = "okay";
 };
 
@@ -197,7 +212,7 @@
 
  {
status = "okay";
-   phys = < 0>;
+   phys = < NPCM_UDC0_7>;
 };
 
  {
@@ -207,12 +222,12 @@
 
  {
status = "okay";
-   phys = < 3>;
+   phys = < NPCM_USBH1>;
 };
 
- {
+ {
status = "okay";
-   phys = < 4>;
+   phys = < NPCM_UDC8>;
 };
 
  {
diff --git a/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi 
b/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
index e49e564b79..4c6d5bed44 100644
--- a/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
+++ b/arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
@@ -174,7 +174,7 @@
compatible = "nuvoton,npcm845-usb-phy";
#phy-cells = <1>;
reg = <3>;
-   resets = < NPCM8XX_RESET_USBPHY3>;
+   resets = < NPCM8XX_RESET_USBPHY3>;
status = "disabled";
};
};
diff --git a/include/dt-bindings/phy/nuvoton,npcm-usbphy.h 
b/include/dt-bindings/phy/nuvoton,npcm-usbphy.h
new file mode 100644
index 00..46946d377d
--- /dev/null
+++ b/include/dt-bindings/phy/nuvoton,npcm-usbphy.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+// Copyright (c) 2023 Nuvoton Technology corporation.
+
+#ifndef _DT_BINDINGS_NPCM_USBPHY_H
+#define _DT_BINDINGS_NPCM_USBPHY_H
+
+#define NPCM_UDC0_70
+#define NPCM_UDC8  1
+#define NPCM_UDC9  2
+#define NPCM_USBH1 3
+#define NPCM_USBH2 4
+#define NPCM_MAX_USB_CTRL_ID   4
+
+#endif
-- 
2.25.1



[PATCH v1 0/4] fix/add npcm845 serial and board error

2023-11-07 Thread Jim Liu
1. Fix serial error and add bypass serial setting.
2. Fix/Add dts node node.
3. Add full function defconfig 

Jim Liu (4):
  arm: dts: npcm845-evb: fix/add node and aliases name
  board: nuvoton: update console environment variable
  configs: arbel: Enable full functions
  serial: npcm: support skip uart clock setting

 arch/arm/dts/nuvoton-common-npcm8xx.dtsi  |  2 +-
 arch/arm/dts/nuvoton-npcm845-evb.dts  | 29 ++--
 arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi  |  2 +-
 board/nuvoton/arbel_evb/Kconfig   |  1 +
 board/nuvoton/common/Kconfig  |  9 +++
 board/nuvoton/common/Makefile |  1 +
 board/nuvoton/common/common.c | 71 +++
 board/nuvoton/common/common.h | 11 +++
 board/nuvoton/poleg_evb/Kconfig   |  1 +
 configs/arbel_evb_defconfig   | 19 -
 drivers/serial/serial_npcm.c  | 39 ++
 include/dt-bindings/phy/nuvoton,npcm-usbphy.h | 14 
 12 files changed, 173 insertions(+), 26 deletions(-)
 create mode 100644 board/nuvoton/common/Kconfig
 create mode 100644 board/nuvoton/common/Makefile
 create mode 100644 board/nuvoton/common/common.c
 create mode 100644 board/nuvoton/common/common.h
 create mode 100644 include/dt-bindings/phy/nuvoton,npcm-usbphy.h

-- 
2.25.1



Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Wed, Nov 08, 2023 at 12:29:03AM +, Conor Dooley wrote:
> On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote:
[snip]
> > Thanks. Setting aside Simon's follow-up, this is what I was looking for.
> > We might have to wait for Heinrich to return from the conference to have
> > time to look at how to utilize the above and see what we can do from
> > there.
> 
> I did read that, but I don't think most of it is relevant to the binding
> itself. His five things were:
> | - U-Boot models hardware (and other things) as devices in driver model [1]
> 
> This I think should be satisfied. The Zkr CSR is a property of the CPU,
> and shouldn't have its own DT node IMO. Is it problematic for U-Boot to
> populate multiple devices for its driver model based on one DT node?
> I know in Linux that I can create devices using something like
> platform_device_register(), does U-Boot have a similar facility?
> https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L767
> 
> | - U-Boot requires devices to be in the devicetree, with very limited
> | exceptions [2]
> 
> | - Where multiple devices exist in a uclass, it is desirable to be able
> | to number them [3]
> 
> I'm not sure really how this one ties in. Do you need a number for each
> CPU that supports Zkr, since a system may be heterogeneous? I think that
> how you treat things like that is beyond communicating support via DT
> though, IMO the job of the DT is just to tell U-Boot on which CPUs it
> can access the seed CSR.
> 
> | - Similarly it is useful to be able select a particular device, e.g.
> | with a phandle [4]
> 
> I suppose a phandle to the CPU would work in this case.
> 
> | - U-Boot uses devicetree for configuration as it has no userspace

I mean, the reason I was setting aside Simon's question is that in my
mind, we (U-Boot) need to think about what we're declaring as a MUST
because the constant feedback that we get is "No, why does that need to
get added to DT? Can't you just use ... ?". So I do find your answers
above enlightening in that regard.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Conor Dooley
On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote:
> On Tue, Nov 07, 2023 at 11:12:16PM +, Conor Dooley wrote:
> > +CC Palmer
> > 
> > On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> > > On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> > > > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> > > > 
> > > > 
> > > > > further clarify or not
> > > > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > > > kernel, not a U-Boot thing).
> > > > 
> > > > TBH, this a bit fragmented across threads, and as someone that hasn't
> > > > been following it it's a bit difficult to tell exactly what is being
> > > > asked for. Would someone be able to ask it as a direct question?
> > > 
> > > Sorry for being unclear, and thanks for asking. What I think the U-Boot
> > > community would like to know is, what is the device-tree based way to
> > > know if a RISC-V platform has the Zbb extensions
> > 
> > For this one, it's pretty straightforward IMO - if riscv,isa-extensions
> > contains "zbb", then you are safe to use those instructions. My
> > understanding is that relying on getting illegal instruction traps is
> > not a sufficient test for usability of standard extensions, as a vendor
> > extension could be using the same opcodes as a standard extension.
> > 
> > > so the RNG opcodes,
> > > similar (in concept at least?) to the ARMv8.5 RNG feature.
> > 
> > The ordinary extensions that are instructions - like Zbkb that provides
> > bit manipulation instructions for cryptography you will be able to rely
> > on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy
> > source and is a bit more complicated. RISC-V Cryptography Extensions
> > Volume I, Chapter Four [0] is the relevant thing for use of the CSR
> > provided by Zkr, and it says "The seed CSR is also access controlled by
> > execution mode, and attempted read or write access will raise an illegal
> > instruction exception outside M mode unless access is explicitly granted."
> > My take is that either the SBI implementation needs to provide S-Mode
> > U-Boot with an accurate devicetree (including what extensions are valid
> > for use in S-mode) or if the devicetree is provided as part of the U-Boot
> > binary then it needs to match what is available at that privilege level
> > on the platform. In this case, you would also be able to rely on
> > riscv,isa-extensions for that detection. There is an existing dt-binding
> > patch
> > 
> > that adds Zkr, and my proposal would be to document that the presence of Zkr
> > explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed
> > has been set so it can be used at the current privilege level.
> > 
> > If that's not acceptable, and people think that having Zkr in the
> > devicetree means that the hardware has the extension, regardless of
> > usability at the present privilege level, then IMO we need an SBI ecall
> > defined to request entablement of the CSR & report as to whether or not
> > that was possible.
> > 
> > I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
> > unfortunately.
> 
> Thanks. Setting aside Simon's follow-up, this is what I was looking for.
> We might have to wait for Heinrich to return from the conference to have
> time to look at how to utilize the above and see what we can do from
> there.

I did read that, but I don't think most of it is relevant to the binding
itself. His five things were:
| - U-Boot models hardware (and other things) as devices in driver model [1]

This I think should be satisfied. The Zkr CSR is a property of the CPU,
and shouldn't have its own DT node IMO. Is it problematic for U-Boot to
populate multiple devices for its driver model based on one DT node?
I know in Linux that I can create devices using something like
platform_device_register(), does U-Boot have a similar facility?
https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L767

| - U-Boot requires devices to be in the devicetree, with very limited
| exceptions [2]

| - Where multiple devices exist in a uclass, it is desirable to be able
| to number them [3]

I'm not sure really how this one ties in. Do you need a number for each
CPU that supports Zkr, since a system may be heterogeneous? I think that
how you treat things like that is beyond communicating support via DT
though, IMO the job of the DT is just to tell U-Boot on which CPUs it
can access the seed CSR.

| - Similarly it is useful to be able select a particular device, e.g.
| with a phandle [4]

I suppose a phandle to the CPU would work in this case.

| - U-Boot uses devicetree for configuration as it has no userspace

Cheers,
Conor.


signature.asc
Description: PGP signature


Re: [PATCH v2 1/3] net: Get pxe config file from dhcp option 209

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 03:50:06PM -0800, Sean Edmond wrote:
> 
> On 2023-11-04 12:53 a.m., Heinrich Schuchardt wrote:
> > On 11/4/23 03:03, Sean Edmond wrote:
> > > 
> > > On 2023-10-23 10:54 p.m., Heinrich Schuchardt wrote:
> > > > On 10/24/23 02:21, seanedm...@linux.microsoft.com wrote:
> > > > > From: Sean Edmond 
> > > > > 
> > > > > Allow dhcp server pass pxe config file full path by using option 209
> > > > > 
> > > > > Signed-off-by: Sean Edmond 
> > > > > ---
> > > > >   cmd/Kconfig |  4 
> > > > >   cmd/pxe.c   | 10 ++
> > > > >   net/bootp.c | 21 +
> > > > >   3 files changed, 35 insertions(+)
> > > > > 
> > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > > > index 5bc0a92d57..adbb1a6187 100644
> > > > > --- a/cmd/Kconfig
> > > > > +++ b/cmd/Kconfig
> > > > > @@ -1826,6 +1826,10 @@ config BOOTP_PXE_CLIENTARCH
> > > > >   default 0x15 if ARM
> > > > >   default 0x0 if X86
> > > > > 
> > > > > +config BOOTP_PXE_DHCP_OPTION
> > > > > +    bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
> > > > > +    depends on BOOTP_PXE
> > > > 
> > > > Why should this be disabled by default?
> > > > 
> > > > Do we really want a separate config variable?
> > > > 
> > > I expect most won't use this option to get the file path (they'll use
> > > the default paths as per the PXE specification).  It makes more sense
> > > for me to keep it optional, like many of the other options?
> > 
> > RFC 5701 seems to require this option. Hence we should make it default
> > yes. Boards that have a build size issue can opt out.
> 
> The PXELINUX specification
> (https://wiki.syslinux.org/wiki/index.php?title=PXELINUX) doesn't state that
> option 209 is required. In the abense of option 209, PXELINUX will try the
> following default configuration files (this example is provided on the wiki
> link):
>  /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
>  /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
>  /mybootdir/pxelinux.cfg/C0A8025B
>  /mybootdir/pxelinux.cfg/C0A8025
>  /mybootdir/pxelinux.cfg/C0A802
>  /mybootdir/pxelinux.cfg/C0A80
>  /mybootdir/pxelinux.cfg/C0A8
>  /mybootdir/pxelinux.cfg/C0A
>  /mybootdir/pxelinux.cfg/C0
>  /mybootdir/pxelinux.cfg/C
>  /mybootdir/pxelinux.cfg/default
> 
> If 209 is requested/provided it tries the provided "config file" before the
> default paths.  RFC 5071 should be seen as an extension for PXELINUX (not a
> requirement).  RFC 5071 only states "The Config File Option MUST be supplied
> by the DHCP server if it appears on the Parameter Request List".

We also want to be careful about overall size growth on common options,
even if someone can opt-out. Those are usually last-ditch stop-gaps and
it's better to make sure we really need functionality X/Y/Z by default,
for everyone. Especially with all of the work going on to make HTTP(s)
based network installs a viable option, how much more do we want to
change the PXE case, for everyone. I'm personally somewhat looking for
the use case to be well defined for a "this must be default". Network
provisioning is a thing, yes, but for whom/what, and in turn how broadly
do we need this to be in the vast majority of our boards (since it would
come in via BOOT*DEFAULTS or DISTRO_DEFAULTS).

-- 
Tom


signature.asc
Description: PGP signature


Re: Booting Android using U-Boot

2023-11-07 Thread Simão Gomes Viana


Hi everyone,

Good news! I disabled compression on kernel build and the resulting boot image 
starts booting Linux.

This is great but it does not solve the decompression issue.
Thanks to Mattijs for pointing me in the compression direction which made me 
further investigate compression options.

So with compression disabled, let's move on to the next issue:
I picked the Quartz64 DTS commits, built and booted it, however there seems to 
still be an issue:
Starting kernel ...

[    0.00] Booting Linux on physical CPU 0x00 [0x412fd050]
[    0.00] Linux version 4.19.154-xos (nobody@android-build) (Android 
(6877366 based on r383902b1) clang version 11.0.2 
(https://android.googlesource.com/toolchain/llvm-project 
b397f81060ce6d701042b782172ed13bee898b79), GNU ld (binutils-2.27-bd24d23f) 
2.27.0.20170315) #1 SMP PREEMPT Wed Nov 8 00:54:49 CET 2023
[    0.00] Machine model: Pine64 RK3566 Quartz64-A Board
...omitted for brevity...
[    0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 
4398046511097ns
[    0.001828] Insufficient stack space to handle exception!
[    0.001835] ESR: 0x81054040 -- IABT (lower EL)
[    0.002766] FAR: 0xc08eea4d24faf096
[    0.003098] Task stack: [0xff8009cc1000..0xff8009cc5000]
[    0.003697] IRQ stack:  [0xff800800..0xff8008004000]
[    0.004299] Overflow stack: [0xffc1ff713080..0xffc1ff714080]
[    0.004907] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.154-xos #1
[    0.005516] Hardware name: Pine64 RK3566 Quartz64-A Board (DT)
[    0.006073] pstate: 2049 (nzCv daif +PAN -UAO)
[    0.006544] pc : start_kernel+0x26c/0x3d0
[    0.006931] lr : start_kernel+0x25c/0x3d0
...omitted for brevity...
[    0.098560] Kernel panic - not syncing: kernel stack overflow
[    0.099108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.154-xos #1
[    0.099717] Hardware name: Pine64 RK3566 Quartz64-A Board (DT)
[    0.100270] Call trace:
[    0.100515]  dump_backtrace+0x0/0x158
[    0.100871]  show_stack+0x14/0x1c
[    0.101195]  dump_stack+0xb8/0xf0
[    0.101519]  panic+0x12c/0x2a4
[    0.101815]  panic+0x0/0x2a4
[    0.102095]  handle_bad_stack+0x118/0x12c
[    0.102479]  __bad_stack+0xc0/0xc4
[    0.102809]  start_kernel+0x26c/0x3d0


Full log: https://termbin.com/yzx6k

Do I need to do anything to reserve stack space for the kernel?

Thanks a lot!

Cheers,
Simao


On Tuesday, November 07, 2023 21:42 CET, Simão Gomes Viana 
 wrote:
 Hi Simon,
Hi everyone from the mailing list,

I'm following up to the email you sent today about a particular problem I'm 
facing trying to boot AOSP 11 (built from source) using U-Boot.
I have extended my original email to include additional information and added 
the mailing list to CC as requested.

In essence, it boils down to this:
## Booting Android Image at 0x00c00800 ...
Kernel load addr 0x00c01000 size 15184 KiB
Kernel command line: console=ttyS2,150 earlycon=uart8250,mmio32,0xfe66 
androidboot.selinux=permissive service_locator.enable=1 kpti=0 loop.max_part=7 
firmware_class.path=/vendor/etc/firmware buildvariant=user
RAM disk load addr 0x01ad5000 size 751 KiB
## Flattened Device Tree blob at 0060
   Booting using the fdt blob at 0x60
Working FDT set to 60
   Uncompressing Kernel Image
lz4 compressed: uncompress error -71
Must RESET board to recover


I have asked the same question on SO with more details.

The kernel is built in-line with the AOSP sources, just like LineageOS does it.
It builds the kernel using make as usual, then takes the Image.lz4 and runs 
mkbootimg with that.

I found this in scripts/Makefile.lib:
quiet_cmd_lz4 = LZ4 $@
cmd_lz4 = (cat $(filter-out FORCE,$^) | \
    lz4 -l -12 --favor-decSpeed stdin stdout && \
    $(call size_append, $(filter-out FORCE,$^))) > $@ || \
    (rm -f $@ ; false)

It is using the -l parameter which is required for LZ4 compression of the 
kernel image.

This is what is present in my BoardConfig:

# Kernel
BOARD_KERNEL_CMDLINE := \
    console=ttyS2,150 \
    earlycon=uart8250,mmio32,0xfe66 \
    androidboot.selinux=permissive \
    service_locator.enable=1 \
    kpti=0 \
    loop.max_part=7 \
    firmware_class.path=/vendor/etc/firmware

BOARD_KERNEL_BASE := 0x1000
BOARD_KERNEL_PAGESIZE := 2048
BOARD_KERNEL_IMAGE_NAME := Image.lz4
TARGET_KERNEL_CLANG_COMPILE := true
#TARGET_KERNEL_CLANG_VERSION := latest
TARGET_KERNEL_SOURCE := kernel/rockchip/rk356x
TARGET_KERNEL_CONFIG := xos_rk356x_defconfig
TARGET_PREBUILT_RESOURCE ?= $(TARGET_KERNEL_SOURCE)/resource.img
TARGET_BOOTLOADER_IS_2ND := true

This is what the file utility tells me:
out/target/product/rk3566_rgo/boot.img: Android bootimg, kernel (0x10008000), 
ramdisk (0x1100), second stage (0x10f0), page size: 2048, cmdline 
(console=ttyS2,150 earlycon=uart8250,mmio32,0xfe66 
androidboot.selinux=permissive service_locator.enable=1 kpti=0 loop.m)


unpack_bootimg shows:
boot magic: ANDROID!
kernel_size: 15547433

Re: [PATCH v2 1/3] net: Get pxe config file from dhcp option 209

2023-11-07 Thread Sean Edmond



On 2023-11-04 12:53 a.m., Heinrich Schuchardt wrote:

On 11/4/23 03:03, Sean Edmond wrote:


On 2023-10-23 10:54 p.m., Heinrich Schuchardt wrote:

On 10/24/23 02:21, seanedm...@linux.microsoft.com wrote:

From: Sean Edmond 

Allow dhcp server pass pxe config file full path by using option 209

Signed-off-by: Sean Edmond 
---
  cmd/Kconfig |  4 
  cmd/pxe.c   | 10 ++
  net/bootp.c | 21 +
  3 files changed, 35 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5bc0a92d57..adbb1a6187 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1826,6 +1826,10 @@ config BOOTP_PXE_CLIENTARCH
  default 0x15 if ARM
  default 0x0 if X86

+config BOOTP_PXE_DHCP_OPTION
+    bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
+    depends on BOOTP_PXE


Why should this be disabled by default?

Do we really want a separate config variable?


I expect most won't use this option to get the file path (they'll use
the default paths as per the PXE specification).  It makes more sense
for me to keep it optional, like many of the other options?


RFC 5701 seems to require this option. Hence we should make it default
yes. Boards that have a build size issue can opt out.


The PXELINUX specification 
(https://wiki.syslinux.org/wiki/index.php?title=PXELINUX) doesn't state 
that option 209 is required. In the abense of option 209, PXELINUX will 
try the following default configuration files (this example is provided 
on the wiki link):

 /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
 /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
 /mybootdir/pxelinux.cfg/C0A8025B
 /mybootdir/pxelinux.cfg/C0A8025
 /mybootdir/pxelinux.cfg/C0A802
 /mybootdir/pxelinux.cfg/C0A80
 /mybootdir/pxelinux.cfg/C0A8
 /mybootdir/pxelinux.cfg/C0A
 /mybootdir/pxelinux.cfg/C0
 /mybootdir/pxelinux.cfg/C
 /mybootdir/pxelinux.cfg/default

If 209 is requested/provided it tries the provided "config file" before 
the default paths.  RFC 5071 should be seen as an extension for PXELINUX 
(not a requirement).  RFC 5071 only states "The Config File Option MUST 
be supplied by the DHCP server if it appears on the Parameter Request List".




Best regards

Heinrich


+
  config BOOTP_VCI_STRING
  string
  depends on CMD_BOOTP
diff --git a/cmd/pxe.c b/cmd/pxe.c
index 704589702f..9404f44518 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -65,6 +65,8 @@ static int pxe_dhcp_option_path(struct pxe_context
*ctx, unsigned long pxefile_a
  int ret = get_pxe_file(ctx, pxelinux_configfile, 
pxefile_addr_r);


  free(pxelinux_configfile);
+    /* set to NULL to avoid double-free if DHCP is tried again */
+    pxelinux_configfile = NULL;

  return ret;
  }
@@ -141,6 +143,14 @@ int pxe_get(ulong pxefile_addr_r, char
**bootdirp, ulong *sizep, bool use_ipv6)
    env_get("bootfile"), use_ipv6))
  return -ENOMEM;

+    if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION) &&
+    pxelinux_configfile && !use_ipv6) {
+    if (pxe_dhcp_option_path(, pxefile_addr_r) > 0)
+    goto done;
+
+    goto error_exit;
+    }
+
  if (IS_ENABLED(CONFIG_DHCP6_PXE_DHCP_OPTION) &&
  pxelinux_configfile && use_ipv6) {
  if (pxe_dhcp_option_path(, pxefile_addr_r) > 0)
diff --git a/net/bootp.c b/net/bootp.c
index 7b0f45e18a..6800290963 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -26,6 +26,7 @@
  #ifdef CONFIG_BOOTP_RANDOM_DELAY
  #include "net_rand.h"
  #endif
+#include 

  #define BOOTP_VENDOR_MAGIC    0x63825363    /* RFC1048 Magic 
Cookie */


@@ -601,6 +602,10 @@ static int dhcp_extended(u8 *e, int
message_type, struct in_addr server_ip,
  *e++  = 42;
  *cnt += 1;
  #endif
+    if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
+    *e++ = 209;    /* PXELINUX Config File */
+    *cnt += 1;
+    }
  /* no options, so back up to avoid sending an empty request
list */
  if (*cnt == 0)
  e -= 2;
@@ -909,6 +914,22 @@ static void dhcp_process_options(uchar *popt,
uchar *end)
  net_boot_file_name[size] = 0;
  }
  break;
+    case 209:    /* PXELINUX Config File */


This 209 appears in multiple places. Please, define a constant, e.g.
DHCP_OPTION_CONFIG_FILE, in bootp.h and use the symbolic name. Please,
document the constant referring to RFC 5071.

fixed in v3.



+    if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
+    /* In case it has already been allocated when get
DHCP Offer packet,
+ * free first to avoid memory leak.
+ */
+    if (pxelinux_configfile)
+    free(pxelinux_configfile);
+
+    pxelinux_configfile = (char *)malloc((oplen + 1) *
sizeof(char));
+
+    if (pxelinux_configfile)
+    strlcpy(pxelinux_configfile, popt + 2, oplen + 
1);

+    else
+    printf("Error: Failed to allocate
pxelinux_configfile\n");


We do the same in dhcp6_parse_options(). 

Re: [v5 02/30] buildman: Use oldconfig when adjusting the config

2023-11-07 Thread Tom Rini
On Thu, Oct 26, 2023 at 02:31:10PM -0400, Tom Rini wrote:

> From: Simon Glass 
> 
> We cannot be sure that the new config is consistent, particularly when
> changing a major item like CONFIG_CMDLINE. Use 'make oldconfig' to
> check that and avoid any such problems.
> 
> Signed-off-by: Simon Glass 

For this and the rest of this series (patch 1 is already applied),
applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 01/20] m68k: Remove CONFIG_FSLDMAFEC

2023-11-07 Thread Tom Rini
On Wed, 01 Nov 2023 12:28:05 -0400, Tom Rini wrote:

> There are no platforms which enable this feature, so remove it.
> 
> 

Applied to u-boot/next, thanks!

-- 
Tom



Re: [PATCH 2/3] configs: am62ax: setup the 32k RTC crystal

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 05:21:42PM -0600, Bryan Brattlof wrote:

> The am62ax utilizes the same 32k crystal for a more accurate RTC clock
> source. Enable the configuration to set this up for Linux.
> 
> Signed-off-by: Bryan Brattlof 
> ---
>  board/ti/am62ax/evm.c| 5 +
>  configs/am62ax_evm_a53_defconfig | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
> index f2dd3b4192ee0..6e031784766c4 100644
> --- a/board/ti/am62ax/evm.c
> +++ b/board/ti/am62ax/evm.c
> @@ -14,8 +14,13 @@
>  #include 
>  #include 
>  
> +#include "../common/rtc.c"

Oh goodness, no, we don't include a C file without very good reason.
Build that object based on whatever the right symbol name is (based on
my feedback in 1/3) and find some appropriate header for the function
prototype to be in as well. And this applies to 3/3 as well.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/3] board: ti: common: add rtc setup to common folder

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 05:21:41PM -0600, Bryan Brattlof wrote:

> All of the starter kit boards for the am62xxx extended family utilize
> the same 32k crystal oscillator for a more accurate clock for the RTC
> instance. Add the setup the clock mux and debounce configuration to the
> common board directory so the entire am62xxx extended family can utilize
> it.
> 
> Signed-off-by: Bryan Brattlof 
[snip]
> diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
> index 49edd98014ab7..56a65c0a402bb 100644
> --- a/board/ti/common/Kconfig
> +++ b/board/ti/common/Kconfig
> @@ -1,3 +1,11 @@
> +config BOARD_HAS_32K_RTC_CRYSTAL
> + bool "Enable the 32k crystial for RTC"
> + help
> +Some of Texas Instrument's Starter-Kit boards have
> +an onboard 32k crystal. Select this option if you wish Uboot
> +to enable this crystal for Linux
> + default n

No "default n" as that is the default. And we (a) need some depends on
for what families this is found on and then (b) how, if at all, does
this match up with the 32k crystal used on other TI reference platforms
over the years? If this is specific to the K3 families of reference
platforms, the help needs re-phrasing and the filename is too generic.
It's also not a "RTC" in terms of something we can talk to via
drivers/rtc/rtc-uclass.c and drivers/rtc/davinci.c, or in this case
porting the kernel's drivers/rtc/rtc-ti-k3.c over, yes?

Oh, and "U-Boot" not "Uboot". Should see if the checkpatch typo list
can be easily expanded by us, one of these days.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 11:12:16PM +, Conor Dooley wrote:
> +CC Palmer
> 
> On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> > On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> > > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> > > 
> > > 
> > > > further clarify or not
> > > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > > kernel, not a U-Boot thing).
> > > 
> > > TBH, this a bit fragmented across threads, and as someone that hasn't
> > > been following it it's a bit difficult to tell exactly what is being
> > > asked for. Would someone be able to ask it as a direct question?
> > 
> > Sorry for being unclear, and thanks for asking. What I think the U-Boot
> > community would like to know is, what is the device-tree based way to
> > know if a RISC-V platform has the Zbb extensions
> 
> For this one, it's pretty straightforward IMO - if riscv,isa-extensions
> contains "zbb", then you are safe to use those instructions. My
> understanding is that relying on getting illegal instruction traps is
> not a sufficient test for usability of standard extensions, as a vendor
> extension could be using the same opcodes as a standard extension.
> 
> > so the RNG opcodes,
> > similar (in concept at least?) to the ARMv8.5 RNG feature.
> 
> The ordinary extensions that are instructions - like Zbkb that provides
> bit manipulation instructions for cryptography you will be able to rely
> on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy
> source and is a bit more complicated. RISC-V Cryptography Extensions
> Volume I, Chapter Four [0] is the relevant thing for use of the CSR
> provided by Zkr, and it says "The seed CSR is also access controlled by
> execution mode, and attempted read or write access will raise an illegal
> instruction exception outside M mode unless access is explicitly granted."
> My take is that either the SBI implementation needs to provide S-Mode
> U-Boot with an accurate devicetree (including what extensions are valid
> for use in S-mode) or if the devicetree is provided as part of the U-Boot
> binary then it needs to match what is available at that privilege level
> on the platform. In this case, you would also be able to rely on
> riscv,isa-extensions for that detection. There is an existing dt-binding
> patch
> 
> that adds Zkr, and my proposal would be to document that the presence of Zkr
> explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed
> has been set so it can be used at the current privilege level.
> 
> If that's not acceptable, and people think that having Zkr in the
> devicetree means that the hardware has the extension, regardless of
> usability at the present privilege level, then IMO we need an SBI ecall
> defined to request entablement of the CSR & report as to whether or not
> that was possible.
> 
> I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
> unfortunately.

Thanks. Setting aside Simon's follow-up, this is what I was looking for.
We might have to wait for Heinrich to return from the conference to have
time to look at how to utilize the above and see what we can do from
there.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 1/3] board: ti: common: add rtc setup to common folder

2023-11-07 Thread Bryan Brattlof
All of the starter kit boards for the am62xxx extended family utilize
the same 32k crystal oscillator for a more accurate clock for the RTC
instance. Add the setup the clock mux and debounce configuration to the
common board directory so the entire am62xxx extended family can utilize
it.

Signed-off-by: Bryan Brattlof 
---
 board/ti/common/Kconfig |  8 +++
 board/ti/common/rtc.c   | 47 +
 2 files changed, 55 insertions(+)
 create mode 100644 board/ti/common/rtc.c

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab7..56a65c0a402bb 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -1,3 +1,11 @@
+config BOARD_HAS_32K_RTC_CRYSTAL
+   bool "Enable the 32k crystial for RTC"
+   help
+  Some of Texas Instrument's Starter-Kit boards have
+  an onboard 32k crystal. Select this option if you wish Uboot
+  to enable this crystal for Linux
+   default n
+
 config TI_I2C_BOARD_DETECT
bool "Support for Board detection for TI platforms"
help
diff --git a/board/ti/common/rtc.c b/board/ti/common/rtc.c
new file mode 100644
index 0..e117a927765c5
--- /dev/null
+++ b/board/ti/common/rtc.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RTC setup for TI Platforms
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+#include 
+#include 
+#include 
+
+#define WKUP_CTRLMMR_DBOUNCE_CFG1 0x04504084
+#define WKUP_CTRLMMR_DBOUNCE_CFG2 0x04504088
+#define WKUP_CTRLMMR_DBOUNCE_CFG3 0x0450408c
+#define WKUP_CTRLMMR_DBOUNCE_CFG4 0x04504090
+#define WKUP_CTRLMMR_DBOUNCE_CFG5 0x04504094
+#define WKUP_CTRLMMR_DBOUNCE_CFG6 0x04504098
+
+void board_rtc_init(void)
+{
+   u32 val;
+
+   /* We have 32k crystal, so lets enable it */
+   val = readl(MCU_CTRL_LFXOSC_CTRL);
+   val &= ~(MCU_CTRL_LFXOSC_32K_DISABLE_VAL);
+   writel(val, MCU_CTRL_LFXOSC_CTRL);
+
+   /* Add any TRIM needed for the crystal here.. */
+   /* Make sure to mux up to take the SoC 32k from the crystal */
+   writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL,
+  MCU_CTRL_DEVICE_CLKOUT_32K_CTRL);
+
+   /* Setup debounce conf registers - arbitrary values.
+* Times are approx
+*/
+   /* 1.9ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG1, 0x1);
+   /* 5ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG2, 0x5);
+   /* 20ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG3, 0x14);
+   /* 46ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG4, 0x18);
+   /* 100ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG5, 0x1c);
+   /* 156ms debounce @ 32k */
+   writel(WKUP_CTRLMMR_DBOUNCE_CFG6, 0x1f);
+}
-- 
2.42.0



[PATCH 2/3] configs: am62ax: setup the 32k RTC crystal

2023-11-07 Thread Bryan Brattlof
The am62ax utilizes the same 32k crystal for a more accurate RTC clock
source. Enable the configuration to set this up for Linux.

Signed-off-by: Bryan Brattlof 
---
 board/ti/am62ax/evm.c| 5 +
 configs/am62ax_evm_a53_defconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index f2dd3b4192ee0..6e031784766c4 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -14,8 +14,13 @@
 #include 
 #include 
 
+#include "../common/rtc.c"
+
 int board_init(void)
 {
+   if (IS_ENABLED(CONFIG_BOARD_HAS_32K_RTC_CRYSTAL))
+   board_rtc_init();
+
return 0;
 }
 
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index d0a34c75505d2..e9e969c842d7d 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_K3=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_BOARD_HAS_32K_RTC_CRYSTAL=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
-- 
2.42.0



[PATCH 3/3] configs: am62x: move 32K RTC crystal to common

2023-11-07 Thread Bryan Brattlof
The am62x utilizes the same 32k crystal for a more accurate RTC clock
source. Enable the configuration to set this up for Linux.

Signed-off-by: Bryan Brattlof 
---
 board/ti/am62x/evm.c| 5 +
 configs/am62x_evm_a53_defconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad939088402e4..1b2ff7e5c2443 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include "../common/rtc.c"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #if CONFIG_IS_ENABLED(SPLASH_SCREEN)
@@ -46,6 +48,9 @@ int splash_screen_prepare(void)
 
 int board_init(void)
 {
+   if (IS_ENABLED(CONFIG_BOARD_HAS_32K_RTC_CRYSTAL))
+   board_rtc_init();
+
return 0;
 }
 
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index df2511546eab7..e9ee265fd7a91 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_K3=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_BOARD_HAS_32K_RTC_CRYSTAL=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
-- 
2.42.0



[PATCH 0/3] board: ti: common: setup mux and debounce for 32k RTC crystal

2023-11-07 Thread Bryan Brattlof
Hello everyone!

The starter kit boards for Texas Instruments' am62xxx extended SoC
family all have the same discrete 32k crystal to provide a more accurate
clock source if needed.

Up until now this has not been needed, however as more features are
starting to rely on the accuracy of the internal RTC we should switch to
using this crystal.

This little series adds a board_rtc_init() function in the
board/ti/common directory to setup this crystal for the am62x and am62ax
starter kits.

Thanks for reviewing!
~Bryan

Bryan Brattlof (3):
  board: ti: common: add rtc setup to common folder
  configs: am62ax: setup the 32k RTC crystal
  configs: am62x: move 32K RTC crystal to common

 board/ti/am62ax/evm.c|  5 
 board/ti/am62x/evm.c |  5 
 board/ti/common/Kconfig  |  8 ++
 board/ti/common/rtc.c| 47 
 configs/am62ax_evm_a53_defconfig |  1 +
 configs/am62x_evm_a53_defconfig  |  1 +
 6 files changed, 67 insertions(+)
 create mode 100644 board/ti/common/rtc.c


base-commit: e17d174773e9ba9447596708e702b7382e47a6cf
-- 
2.42.0



Re: [tom.r...@gmail.com: Fwd: New Defects reported by Coverity Scan for Das U-Boot]

2023-11-07 Thread Johan Jonker
Hi Tom, Simon,

Please have a look some comments below at 3 issues that are introduced by 
meself. ;)

On 11/6/23 21:27, Tom Rini wrote:
> Hey all,
> 
> Here's the latest report. I _think_ I passed the right options to
> get_maintainer.pl such that it would only look far enough back in git to
> find the likely authors (along with listed maintainers of the files).
> 
> -- Forwarded message -
> From: 
> Date: Mon, Nov 6, 2023 at 2:58 PM
> Subject: New Defects reported by Coverity Scan for Das U-Boot
> To: 
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Das
> U-Boot found with Coverity Scan.
> 
> 13 new defect(s) introduced to Das U-Boot found with Coverity Scan.
> 5 defect(s), reported by Coverity Scan earlier, were marked fixed in
> the recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 13 of 13 defect(s)
> 
> 
> ** CID 467411:  Memory - corruptions  (OVERRUN)
> 
> 
> 

[..]

> *** CID 467407:  Uninitialized variables  (UNINIT)
> /drivers/scsi/scsi.c: 612 in do_scsi_scan_one()
> 606
> 607 bdesc = dev_get_uclass_plat(bdev);
> 608 bdesc->target = id;
> 609 bdesc->lun = lun;
> 610 bdesc->removable = bd.removable;
> 611 bdesc->type = bd.type;
 CID 467407:  Uninitialized variables  (UNINIT)
 Using uninitialized value "bd.bb".
> 612 bdesc->bb = bd.bb;
> 613 memcpy(>vendor, , sizeof(bd.vendor));
> 614 memcpy(>product, , sizeof(bd.product));
> 615 memcpy(>revision, ,  sizeof(bd.revision));
> 616 if (IS_ENABLED(CONFIG_SYS_BIG_ENDIAN)) {
> 617 ata_swap_buf_le16((u16 *)>vendor,
> sizeof(bd.vendor) / 2);
> 
> ** CID 467406:  Memory - corruptions  (OVERRUN)
> 
> 

Scsi devices are not my thing.
I'm forced to poke in drivers, because someone else is plumbing bounce buffer 
code to our block class.


Introduced by:
[PATCH v5 4/8] rockchip: block: blk-uclass: add bounce buffer flag to blk_desc
https://lore.kernel.org/u-boot/ee332375-8812-8e12-da1c-9973d10a4...@gmail.com/

static void scsi_init_dev_desc_priv(struct blk_desc *dev_desc)
{
[..]

#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
dev_desc->bb = true;
#endif  /* CONFIG_BOUNCE_BUFFER */
}

[..]
struct blk_desc bd;

scsi_init_dev_desc_priv();

bdesc->bb = bd.bb;
===
https://www.kernel.org/doc/html/latest/dev-tools/checkpatch.html

GLOBAL_INITIALISERS

Global variables should not be initialized explicitly to 0 (or NULL, false, 
etc.). Your compiler (or rather your loader, which is responsible for zeroing 
out the relevant sections) automatically does it for you.
INITIALISED_STATIC

Static variables should not be initialized explicitly to zero. Your 
compiler (or rather your loader) automatically does it for you.

===
I assumed that variables are always zeroed in the blk_desc structure.
The value of bb only matters if IS_ENABLED(CONFIG_BOUNCE_BUFFER).

For scsi:
dev_desc->bb = IS_ENABLED(CONFIG_BOUNCE_BUFFER) ? true : false;

The scsi block class worked fine for years without bounce buffer. Do all scsi 
devices need that buffer all of a sudden? What didn't work then?

Please advise what is the best approach.

===
There is a patch in review that changes this file. Better let that go in first 
before changing something here. What's the status?

[PATCH] scsi: Forceably finish migration to DM_SCSI
https://lore.kernel.org/u-boot/20231028005951.1187616-1-tr...@konsulko.com/

> 

[..]

> 
> *** CID 467402:(CHECKED_RETURN)
> /drivers/block/rkmtd.c: 737 in rkmtd_init_plat()
> 731
> 732 debug("starting_lba   : %llu\n",
> le64_to_cpu(plat->gpt_e->starting_lba));
> 733 debug("ending_lba : %llu\n",
> le64_to_cpu(plat->gpt_e->ending_lba));
> 734
> 735 memcpy(plat->gpt_e->partition_type_guid.b,
> _basic_data_guid, 16);
> 736


 CID 467402:(CHECKED_RETURN)
 Calling "uuid_str_to_bin" without checking return value (as is done 
 elsewhere 9 out of 11 times).
> 737 uuid_str_to_bin(plat->uuid_part_str,
> plat->gpt_e->unique_partition_guid.b,
> 738 UUID_STR_FORMAT_GUID);

Comment 2:

gen_rand_uuid_str(plat->uuid_disk_str, UUID_STR_FORMAT_GUID);
uuid_str_to_bin(plat->uuid_part_str, 
plat->gpt_e->unique_partition_guid.b,
UUID_STR_FORMAT_GUID);


The function uuid_str_to_bin() gets a string from gen_rand_uuid_str() which is 
guarantied correct.
Checking the output is unnecessary. 
 
if (!uuid_str_valid(uuid_str)) {
return 

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 03:51:21PM -0700, Simon Glass wrote:
> Hi,
> 
> On Tue, 7 Nov 2023 at 15:38, Tom Rini  wrote:
> >
> > On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> > > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> > >
> > >
> > > > further clarify or not
> > > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > > kernel, not a U-Boot thing).
> > >
> > > TBH, this a bit fragmented across threads, and as someone that hasn't
> > > been following it it's a bit difficult to tell exactly what is being
> > > asked for. Would someone be able to ask it as a direct question?
> >
> > Sorry for being unclear, and thanks for asking. What I think the U-Boot
> > community would like to know is, what is the device-tree based way to
> > know if a RISC-V platform has the Zbb extensions and so the RNG opcodes,
> > similar (in concept at least?) to the ARMv8.5 RNG feature.
> 
> Some more details (sorry) from your friendly devicetree and driver
> model maintainer:
> 
> - U-Boot models hardware (and other things) as devices in driver model [1]
> - U-Boot requires devices to be in the devicetree, with very limited
> exceptions [2]
> - Where multiple devices exist in a uclass, it is desirable to be able
> to number them [3]
> - Similarly it is useful to be able select a particular device, e.g.
> with a phandle [4]
> - U-Boot uses devicetree for configuration as it has no userspace

And I'm very specifically trying to NOT dive in to these particular
details and just find out how the accepted bindings for RISC-V are
intended to solve the question U-Boot has and in turn figure out what
U-Boot should do here. I'm not asking Conor how it should all fit in to
what U-Boot does, just how what's defined now can be used in this case.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Conor Dooley
+CC Palmer

On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote:
> On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> > 
> > 
> > > further clarify or not
> > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > kernel, not a U-Boot thing).
> > 
> > TBH, this a bit fragmented across threads, and as someone that hasn't
> > been following it it's a bit difficult to tell exactly what is being
> > asked for. Would someone be able to ask it as a direct question?
> 
> Sorry for being unclear, and thanks for asking. What I think the U-Boot
> community would like to know is, what is the device-tree based way to
> know if a RISC-V platform has the Zbb extensions

For this one, it's pretty straightforward IMO - if riscv,isa-extensions
contains "zbb", then you are safe to use those instructions. My
understanding is that relying on getting illegal instruction traps is
not a sufficient test for usability of standard extensions, as a vendor
extension could be using the same opcodes as a standard extension.

> so the RNG opcodes,
> similar (in concept at least?) to the ARMv8.5 RNG feature.

The ordinary extensions that are instructions - like Zbkb that provides
bit manipulation instructions for cryptography you will be able to rely
on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy
source and is a bit more complicated. RISC-V Cryptography Extensions
Volume I, Chapter Four [0] is the relevant thing for use of the CSR
provided by Zkr, and it says "The seed CSR is also access controlled by
execution mode, and attempted read or write access will raise an illegal
instruction exception outside M mode unless access is explicitly granted."
My take is that either the SBI implementation needs to provide S-Mode
U-Boot with an accurate devicetree (including what extensions are valid
for use in S-mode) or if the devicetree is provided as part of the U-Boot
binary then it needs to match what is available at that privilege level
on the platform. In this case, you would also be able to rely on
riscv,isa-extensions for that detection. There is an existing dt-binding
patch

that adds Zkr, and my proposal would be to document that the presence of Zkr
explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed
has been set so it can be used at the current privilege level.

If that's not acceptable, and people think that having Zkr in the
devicetree means that the hardware has the extension, regardless of
usability at the present privilege level, then IMO we need an SBI ecall
defined to request entablement of the CSR & report as to whether or not
that was possible.

I'm not sure how any of the above lines up with the ARMv8.5 RNG feature
unfortunately.

Cheers,
Conor.

0 - https://github.com/riscv/riscv-crypto/releases/tag/v1.0.1-scalar


signature.asc
Description: PGP signature


[PATCH 1/1] pico-imx7d: add baseboard SD card boot detect

2023-11-07 Thread egyszeregy
From: Benjamin Szőke 

Technexion PICO-IMX7 SoM is supporting USDHC3 (eMMC or micro SD on SoM)
and USDHC1 (SD on carrier board) to use on any carrier board like
PICO-NYMPH. Based on the U-Boot version from Technexion it adds
baseboard SD card boot detect to able to boot from selected USDHC1
or USDHC3 boot devices.

- Add baseboard SD card boot detect from Technexion's U-Boot.
- Implement board_mmc_get_env_dev() for pico-imx7d SoM.
- Implement mmc_map_to_kernel_blk() for pico-imx7d SoM.
- Add board_late_mmc_env_init() to use from common freescale
  functions to able to provide "mmcdev" and "mmcroot" variables
  in environment of U-boot.
- Add "mmc1" alias to use for usdhc1 in imx7d-pico-pi-u-boot.dtsi.
- In default environment set "mmcautodetect=yes" to use boot detection.

Signed-off-by: Benjamin Szőke 
---
 arch/arm/dts/imx7d-pico-pi-u-boot.dtsi   |  1 +
 board/technexion/pico-imx7d/Makefile |  2 +-
 board/technexion/pico-imx7d/pico-imx7d.c | 63 
 board/technexion/pico-imx7d/spl.c| 91 ++--
 include/configs/pico-imx7d.h |  4 +-
 5 files changed, 152 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/imx7d-pico-pi-u-boot.dtsi 
b/arch/arm/dts/imx7d-pico-pi-u-boot.dtsi
index 843b4583e5..6289a76486 100644
--- a/arch/arm/dts/imx7d-pico-pi-u-boot.dtsi
+++ b/arch/arm/dts/imx7d-pico-pi-u-boot.dtsi
@@ -3,6 +3,7 @@
 /{
 aliases {
 mmc0 = 
+   mmc1 = 
 usb0 = 
 display0 = 
 };
diff --git a/board/technexion/pico-imx7d/Makefile 
b/board/technexion/pico-imx7d/Makefile
index 4ae3d606b5..61b55fcc55 100644
--- a/board/technexion/pico-imx7d/Makefile
+++ b/board/technexion/pico-imx7d/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 # (C) Copyright 2017 NXP Semiconductors
 
-obj-y  := pico-imx7d.o spl.o
+obj-y  := pico-imx7d.o spl.o ../../freescale/common/mmc.o
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index 6e98b85b28..edd66ac7ac 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
 
+#define PICO_MMC0 0
+#define PICO_MMC0_BLK 2
+#define PICO_MMC1 1
+#define PICO_MMC1_BLK 0
+
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -176,6 +182,12 @@ int board_late_init(void)
 
set_wdog_reset(wdog);
 
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
+#if CONFIG_IS_ENABLED(ENV_IS_IN_MMC) || CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
+   board_late_mmc_env_init();
+#endif /* CONFIG_ENV_IS_IN_MMC or CONFIG_ENV_IS_NOWHERE */
+#endif
+
/*
 * Do not assert internal WDOG_RESET_B_DEB(controlled by bit 4),
 * since we use PMIC_PWRON to reset the board.
@@ -210,3 +222,54 @@ int board_ehci_hcd_init(int port)
}
return 0;
 }
+
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
+#if CONFIG_IS_ENABLED(ENV_IS_IN_MMC) || CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
+int board_mmc_get_env_dev(int devno)
+{
+   int dev_env = 0;
+   (void)(devno);
+
+   switch (get_boot_device()) {
+   case SD3_BOOT:
+   case MMC3_BOOT:
+   env_set("bootdev", "MMC3");
+   dev_env = PICO_MMC0;
+   break;
+   case SD1_BOOT:
+   env_set("bootdev", "SD1");
+   dev_env = PICO_MMC1;
+   break;
+   default:
+   printf("Wrong boot device!");
+   }
+
+   return dev_env;
+}
+
+int mmc_map_to_kernel_blk(int dev_no)
+{
+   int blk_no = 0;
+
+   switch (dev_no) {
+   case PICO_MMC0:
+   blk_no = PICO_MMC0_BLK;
+   break;
+   case PICO_MMC1:
+   blk_no = PICO_MMC1_BLK;
+   break;
+   default:
+   printf("Invalid MMC device!");
+   }
+
+   return blk_no;
+}
+#endif
+
+#if CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
+int mmc_get_env_dev(void)
+{
+   return board_mmc_get_env_dev(0);
+}
+#endif
+#endif /* CONFIG_FSL_ESDHC_IMX */
diff --git a/board/technexion/pico-imx7d/spl.c 
b/board/technexion/pico-imx7d/spl.c
index c6b21aaa42..0192eafbaa 100644
--- a/board/technexion/pico-imx7d/spl.c
+++ b/board/technexion/pico-imx7d/spl.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -159,7 +160,20 @@ void reset_cpu(void)
 #define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
 
-static iomux_v3_cfg_t const usdhc3_pads[] = {
+#define USDHC1_CD_GPIO IMX_GPIO_NR(5, 0)
+/* EMMC/SD */
+static const iomux_v3_cfg_t usdhc1_pads[] = {
+   MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+   

[PATCH v11 12/24] cli: Enables using hush 2021 parser as command line parser

2023-11-07 Thread Francis Laniel
If one defines HUSH_2021_PARSER, it is then possible to use 2021 parser with:
=> cli get
old
=> cli set 2021
=> cli get
2021

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 cmd/Kconfig   | 12 
 cmd/Makefile  |  2 +-
 cmd/cli.c | 28 ++---
 common/Makefile   |  1 +
 common/cli.c  | 38 +++
 common/cli_hush_2021.c|  3 ++
 common/cli_hush_upstream.c| 46 +---
 doc/usage/cmd/cli.rst | 17 ++-
 include/asm-generic/global_data.h |  4 +++
 include/cli_hush.h| 51 +--
 10 files changed, 183 insertions(+), 19 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index f3a00ee59b..4641333809 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -34,6 +34,18 @@ menu "Hush flavor to use"
  2005.
 
  It is actually the default U-Boot shell when decided to use 
hush as shell.
+
+   config HUSH_2021_PARSER
+   bool "Use hush 2021 parser"
+   help
+ This option enables the new flavor of hush based on hush 
Busybox from
+ 2021.
+
+ This parser is experimental and not well tested.
+
+   config HUSH_SELECTABLE
+   bool
+   default y if HUSH_OLD_PARSER && HUSH_2021_PARSER
 endmenu
 
 config CMDLINE_EDITING
diff --git a/cmd/Makefile b/cmd/Makefile
index 620f69c1c5..e260c81405 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -227,7 +227,7 @@ obj-$(CONFIG_CMD_AVB) += avb.o
 # Foundries.IO SCP03
 obj-$(CONFIG_CMD_SCP03) += scp03.o
 
-obj-$(CONFIG_HUSH_PARSER) += cli.o
+obj-$(CONFIG_HUSH_SELECTABLE) += cli.o
 
 obj-$(CONFIG_ARM) += arm/
 obj-$(CONFIG_RISCV) += riscv/
diff --git a/cmd/cli.c b/cmd/cli.c
index 86c6471aa4..7da196186a 100644
--- a/cmd/cli.c
+++ b/cmd/cli.c
@@ -12,6 +12,8 @@ static const char *gd_flags_to_parser_name(void)
 {
if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
return "old";
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER)
+   return "2021";
return NULL;
 }
 
@@ -34,18 +36,31 @@ static int parser_string_to_gd_flags(const char *parser)
 {
if (!strcmp(parser, "old"))
return GD_FLG_HUSH_OLD_PARSER;
+   if (!strcmp(parser, "2021"))
+   return GD_FLG_HUSH_2021_PARSER;
+   return -1;
+}
+
+static int gd_flags_to_parser_config(int flag)
+{
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
+   return CONFIG_VAL(HUSH_OLD_PARSER);
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER)
+   return CONFIG_VAL(HUSH_2021_PARSER);
return -1;
 }
 
 static void reset_parser_gd_flags(void)
 {
gd->flags &= ~GD_FLG_HUSH_OLD_PARSER;
+   gd->flags &= ~GD_FLG_HUSH_2021_PARSER;
 }
 
 static int do_cli_set(struct cmd_tbl *cmdtp, int flag, int argc,
  char *const argv[])
 {
char *parser_name;
+   int parser_config;
int parser_flag;
 
if (argc < 2)
@@ -59,9 +74,14 @@ static int do_cli_set(struct cmd_tbl *cmdtp, int flag, int 
argc,
return CMD_RET_USAGE;
}
 
-   if (parser_flag == GD_FLG_HUSH_OLD_PARSER &&
-   !CONFIG_IS_ENABLED(HUSH_OLD_PARSER)) {
-   printf("Want to set current parser to old, but its code was not 
compiled!\n");
+   parser_config = gd_flags_to_parser_config(parser_flag);
+   switch (parser_config) {
+   case -1:
+   printf("Bad value for parser flags: %d\n", parser_flag);
+   return CMD_RET_FAILURE;
+   case 0:
+   printf("Want to set current parser to %s, but its code was not 
compiled!\n",
+   parser_name);
return CMD_RET_FAILURE;
}
 
@@ -102,7 +122,7 @@ static int do_cli(struct cmd_tbl *cmdtp, int flag, int argc,
 #if CONFIG_IS_ENABLED(SYS_LONGHELP)
 static char cli_help_text[] =
"get - print current cli\n"
-   "set - set the current cli, possible value is: old"
+   "set - set the current cli, possible value are: old, 2021"
;
 #endif
 
diff --git a/common/Makefile b/common/Makefile
index 23851a68e2..b487421133 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -9,6 +9,7 @@ obj-y += init/
 obj-y += main.o
 obj-y += exports.o
 obj-$(CONFIG_HUSH_OLD_PARSER) += cli_hush.o
+obj-$(CONFIG_HUSH_2021_PARSER) += cli_hush_2021.o
 obj-$(CONFIG_AUTOBOOT) += autoboot.o
 
 # # boards
diff --git a/common/cli.c b/common/cli.c
index d419671e8c..e3e2bc7fe1 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -43,12 +43,15 @@ int run_command(const char *cmd, int flag)
return 1;
 
return 0;
-#else
+#elif CONFIG_IS_ENABLED(HUSH_OLD_PARSER)
int hush_flags = FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP;
 
if (flag & CMD_FLAG_ENV)
hush_flags |= FLAG_CONT_ON_NEWLINE;
return 

Booting Android using U-Boot

2023-11-07 Thread Simão Gomes Viana


Hi Simon,
Hi everyone from the mailing list,

I'm following up to the email you sent today about a particular problem I'm 
facing trying to boot AOSP 11 (built from source) using U-Boot.
I have extended my original email to include additional information and added 
the mailing list to CC as requested.

In essence, it boils down to this:
## Booting Android Image at 0x00c00800 ...
Kernel load addr 0x00c01000 size 15184 KiB
Kernel command line: console=ttyS2,150 earlycon=uart8250,mmio32,0xfe66 
androidboot.selinux=permissive service_locator.enable=1 kpti=0 loop.max_part=7 
firmware_class.path=/vendor/etc/firmware buildvariant=user
RAM disk load addr 0x01ad5000 size 751 KiB
## Flattened Device Tree blob at 0060
   Booting using the fdt blob at 0x60
Working FDT set to 60
   Uncompressing Kernel Image
lz4 compressed: uncompress error -71
Must RESET board to recover


I have asked the same question on SO with more details.

The kernel is built in-line with the AOSP sources, just like LineageOS does it.
It builds the kernel using make as usual, then takes the Image.lz4 and runs 
mkbootimg with that.

I found this in scripts/Makefile.lib:
quiet_cmd_lz4 = LZ4 $@
cmd_lz4 = (cat $(filter-out FORCE,$^) | \
    lz4 -l -12 --favor-decSpeed stdin stdout && \
    $(call size_append, $(filter-out FORCE,$^))) > $@ || \
    (rm -f $@ ; false)

It is using the -l parameter which is required for LZ4 compression of the 
kernel image.

This is what is present in my BoardConfig:

# Kernel
BOARD_KERNEL_CMDLINE := \
    console=ttyS2,150 \
    earlycon=uart8250,mmio32,0xfe66 \
    androidboot.selinux=permissive \
    service_locator.enable=1 \
    kpti=0 \
    loop.max_part=7 \
    firmware_class.path=/vendor/etc/firmware

BOARD_KERNEL_BASE := 0x1000
BOARD_KERNEL_PAGESIZE := 2048
BOARD_KERNEL_IMAGE_NAME := Image.lz4
TARGET_KERNEL_CLANG_COMPILE := true
#TARGET_KERNEL_CLANG_VERSION := latest
TARGET_KERNEL_SOURCE := kernel/rockchip/rk356x
TARGET_KERNEL_CONFIG := xos_rk356x_defconfig
TARGET_PREBUILT_RESOURCE ?= $(TARGET_KERNEL_SOURCE)/resource.img
TARGET_BOOTLOADER_IS_2ND := true

This is what the file utility tells me:
out/target/product/rk3566_rgo/boot.img: Android bootimg, kernel (0x10008000), 
ramdisk (0x1100), second stage (0x10f0), page size: 2048, cmdline 
(console=ttyS2,150 earlycon=uart8250,mmio32,0xfe66 
androidboot.selinux=permissive service_locator.enable=1 kpti=0 loop.m)


unpack_bootimg shows:
boot magic: ANDROID!
kernel_size: 15547433
kernel load address: 0x10008000
ramdisk size: 768194
ramdisk load address: 0x1100
second bootloader size: 200192
second bootloader load address: 0x10f0
kernel tags load address: 0x1100
page size: 2048
os version: 11.0.0
os patch level: 2021-09
boot image header version: 2
product name:
command line args: console=ttyS2,150 earlycon=uart8250,mmio32,0xfe66 
androidboot.selinux=permissive service_locator.enable=1 kpti=0 loop.max_part=7 
firmware_class.path=/vendor/etc/firmware buildvariant=user
additional command line args:
recovery dtbo size: 0
recovery dtbo offset: 0x
boot header size: 1660
dtb size: 11792057
dtb address: 0x11f0

This is what the working boot.img built by the manufacturer yields:
boot.img: Android bootimg, kernel (0x10008000), ramdisk (0x1100), second 
stage (0x10f0), page size: 2048, cmdline (console=ttyFIQ0 
androidboot.baseband=N/A androidboot.wificountrycode=CN 
androidboot.veritymode=enforcing androidboot.hardware=r)

unpack_bootimg shows:
boot magic: ANDROID!
kernel_size: 31041552
kernel load address: 0x10008000
ramdisk size: 904155
ramdisk load address: 0x1100
second bootloader size: 200192
second bootloader load address: 0x10f0
kernel tags load address: 0x1100
page size: 2048
os version: 11.0.0
os patch level: 2021-04
boot image header version: 2
product name:
command line args: console=ttyFIQ0 androidboot.baseband=N/A 
androidboot.wificountrycode=CN androidboot.veritymode=enforcing 
androidboot.hardware=rk30board androidboot.console=ttyFIQ0 
androidboot.verifiedbootstate=orange firmware_class.path=/vendor/etc/firmware 
init=/init rootwait ro loop.max_part=7 androidboot.selinux=permissive 
buildvariant=userdebug
additional command line args:
recovery dtbo size: 0
recovery dtbo offset: 0x
boot header size: 1660
dtb size: 111487
dtb address: 0x11f0

Given that the kernel image is actually smaller than the manufacturer one, 
there can't be an overlapping issue.
The only real difference is the dtb size which is a lot bigger on the 
non-functional boot image (I don't know why).
However, U-Boot is able to list all the DTBs.

The kernel source I'm using is the one provided in the BSP here (the 79G file): 
https://wiki.pine64.org/wiki/Quartz64_Software_Releases#Android_SDK

If I build the kernel with CONFIG_COMPRESS_GZ instead of CONFIG_COMPRESS_LZ4, I 
also get an error:
## Booting Android Image at 0x00c00800 ...

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Simon Glass
Hi,

On Tue, 7 Nov 2023 at 15:38, Tom Rini  wrote:
>
> On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> >
> >
> > > further clarify or not
> > > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > > kernel, not a U-Boot thing).
> >
> > TBH, this a bit fragmented across threads, and as someone that hasn't
> > been following it it's a bit difficult to tell exactly what is being
> > asked for. Would someone be able to ask it as a direct question?
>
> Sorry for being unclear, and thanks for asking. What I think the U-Boot
> community would like to know is, what is the device-tree based way to
> know if a RISC-V platform has the Zbb extensions and so the RNG opcodes,
> similar (in concept at least?) to the ARMv8.5 RNG feature.

Some more details (sorry) from your friendly devicetree and driver
model maintainer:

- U-Boot models hardware (and other things) as devices in driver model [1]
- U-Boot requires devices to be in the devicetree, with very limited
exceptions [2]
- Where multiple devices exist in a uclass, it is desirable to be able
to number them [3]
- Similarly it is useful to be able select a particular device, e.g.
with a phandle [4]
- U-Boot uses devicetree for configuration as it has no userspace

Regards,
Simon

[1] https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html
[2] 
https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#platform-data
[3] 
https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#device-sequence-numbers
[4] 
https://u-boot.readthedocs.io/en/latest/api/dm.html?highlight=phandle#c.of_find_node_by_phandle


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 10:27:50PM +, Conor Dooley wrote:
> On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:
> 
> 
> > further clarify or not
> > the RISC-V ISA thing that's elsewhere in this thread (and part of the
> > kernel, not a U-Boot thing).
> 
> TBH, this a bit fragmented across threads, and as someone that hasn't
> been following it it's a bit difficult to tell exactly what is being
> asked for. Would someone be able to ask it as a direct question?

Sorry for being unclear, and thanks for asking. What I think the U-Boot
community would like to know is, what is the device-tree based way to
know if a RISC-V platform has the Zbb extensions and so the RNG opcodes,
similar (in concept at least?) to the ARMv8.5 RNG feature.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Conor Dooley
On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote:


> further clarify or not
> the RISC-V ISA thing that's elsewhere in this thread (and part of the
> kernel, not a U-Boot thing).

TBH, this a bit fragmented across threads, and as someone that hasn't
been following it it's a bit difficult to tell exactly what is being
asked for. Would someone be able to ask it as a direct question?



signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 03:52:36PM -0600, Rob Herring wrote:
> On Tue, Nov 7, 2023 at 1:30 PM Tom Rini  wrote:
> >
> > On Tue, Nov 07, 2023 at 01:10:44AM +, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 6 Nov 2023 at 13:46, Tom Rini  wrote:
> > > >
> > > > On Mon, Nov 06, 2023 at 01:38:39PM -0700, Simon Glass wrote:
> > > > > Hi Andre,
> > > > >
> > > > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  
> > > > > wrote:
> > > > > >
> > > > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > > > Simon Glass  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > > > Simon Glass  wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > > Hi Heinrich,
> > > > > > > > >
> > > > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > > > Heinrich Schuchardt  
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > >
> > > > > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the 
> > > > > > > > > > >> seed CSR. It
> > > > > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > > > > >>
> > > > > > > > > > >> A RNG driver based on the seed CSR is provided. It 
> > > > > > > > > > >> depends on
> > > > > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > > > > >
> > > > > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > > > > respective Arm
> > > > > > > > > > > functionality:
> > > > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > > > >
> > > > > > > > > > > And I see that you seem to use the same mechanism to 
> > > > > > > > > > > probe and init the
> > > > > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature 
> > > > > > > > > > > is not
> > > > > > > > > > > implemented.
> > > > > > > > > > > One downside of this approach is that the driver is 
> > > > > > > > > > > always loaded (and
> > > > > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > > > > available.
> > > > > > > > > > > That doesn't seem too much of a problem on the first 
> > > > > > > > > > > glance, but it
> > > > > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > > > > devices
> > > > > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > > > > without
> > > > > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > > > > VExpress64# rng 0
> > > > > > > > > > > No RNG device
> > > > > > > > >
> > > > > > > > > Why do we get this? If the device is not there, the bind() 
> > > > > > > > > function
> > > > > > > > > can return -ENODEV
> > > > > > > > >
> > > > > > > > > I see this in U-Boot:
> > > > > > > > >
> > > > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > > > >
> > > > > > > > > We should not use this.
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > > Use the devicetree.
> > > > > > > >
> > > > > > > > No, this is definitely not something for the DT, at least not 
> > > > > > > > on ARM.
> > > > > > > > It's perfectly discoverable via the architected CPU ID 
> > > > > > > > registers.
> > > > > > > > Similar to PCI and USB devices, which we don't probe via the DT 
> > > > > > > > as well.
> > > > > > > >
> > > > > > > > It's arguably not proper "driver" material per se, as I've 
> > > > > > > > argued before, but
> > > > > > > > it's the simplest solution and fits in nicely otherwise.
> > > > > > > >
> > > > > > > > I was wondering if it might be something for UCLASS_CPU, 
> > > > > > > > something like
> > > > > > > > a "CPU feature bus": to let devices register on one on the many 
> > > > > > > > CPU
> > > > > > > > features (instead of compatible strings), then only bind() those
> > > > > > > > drivers it the respective bit is set.
> > > > > > > >
> > > > > > > > Does that make sense? Would that be doable without boiling the 
> > > > > > > > ocean?
> > > > > > > > As I don't know if we see many users apart from this.
> > > > > > >
> > > > > > > I have seen this so many times, where people want to avoid putting
> > > > > > > things in the DT and then are surprised that everything is 
> > > > > > > difficult,
> > > > > > > broken and confusing. Why not just follow the rules? It is not 
> > > > > > > just
> > > > > > > about whether we can avoid it, etc. It is about how devices fit
> > > > > > > together cohesively in the system, and how U-Boot operates.
> > > > > >
> > > > > > A devicetree is only for peripherals *that cannot be located by 
> > > > > > probing*.
> > > > >
> > > > > I have to stop you 

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 03:12:48PM +, Andre Przywara wrote:
> On Tue, 7 Nov 2023 05:22:58 -0700
> Simon Glass  wrote:
[snip]
> > We already have a perfectly good way of selecting between multiple
> > devices. It is used all over U-Boot. We should not be inventing a
> > hard-coded hack just because we are confused about whether something
> > is a device. Just make it a device.
> 
> And this is exactly what my ARM RNDR driver was doing: using a
> UCLASS_RNG driver interface to expose entropy. I just don't understand why
> we desperately need a DT node for that? I understand that U_BOOT_DRVINFO
> should not be used, and this is fine.

I think part of the problem is that U_BOOT_DRVINFO probably is the right
answer for more things than it might have been intended for at first.
Because yes, looking at the driver right now, whatever semantic-wise was
mentioned earlier in the thread is applicable, but it otherwise looks
like the easy path to "one device has many functions" without us having
to develop some special case bus to put things on.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 05:22:58AM -0700, Simon Glass wrote:
> Hi Andre,
> 
> On Tue, 7 Nov 2023 at 04:27, Andre Przywara  wrote:
> >
> > On Tue, 7 Nov 2023 01:08:15 +
> > Simon Glass  wrote:
> >
> > Hi Simon,
> >
> > > On Mon, 6 Nov 2023 at 21:55, Andre Przywara  
> > > wrote:
> > > >
> > > > On Mon, 6 Nov 2023 13:38:39 -0700
> > > > Simon Glass  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  
> > > > > wrote:
> > > > > >
> > > > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > > > Simon Glass  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > > > Simon Glass  wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > > Hi Heinrich,
> > > > > > > > >
> > > > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > > > Heinrich Schuchardt  
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > >
> > > > > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the 
> > > > > > > > > > >> seed CSR. It
> > > > > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > > > > >>
> > > > > > > > > > >> A RNG driver based on the seed CSR is provided. It 
> > > > > > > > > > >> depends on
> > > > > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > > > > >
> > > > > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > > > > respective Arm
> > > > > > > > > > > functionality:
> > > > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > > > >
> > > > > > > > > > > And I see that you seem to use the same mechanism to 
> > > > > > > > > > > probe and init the
> > > > > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature 
> > > > > > > > > > > is not
> > > > > > > > > > > implemented.
> > > > > > > > > > > One downside of this approach is that the driver is 
> > > > > > > > > > > always loaded (and
> > > > > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > > > > available.
> > > > > > > > > > > That doesn't seem too much of a problem on the first 
> > > > > > > > > > > glance, but it
> > > > > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > > > > devices
> > > > > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > > > > without
> > > > > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > > > > VExpress64# rng 0
> > > > > > > > > > > No RNG device
> > > > > > > > >
> > > > > > > > > Why do we get this? If the device is not there, the bind() 
> > > > > > > > > function
> > > > > > > > > can return -ENODEV
> > > > > > > > >
> > > > > > > > > I see this in U-Boot:
> > > > > > > > >
> > > > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > > > >
> > > > > > > > > We should not use this.
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > > Use the devicetree.
> > > > > > > >
> > > > > > > > No, this is definitely not something for the DT, at least not 
> > > > > > > > on ARM.
> > > > > > > > It's perfectly discoverable via the architected CPU ID 
> > > > > > > > registers.
> > > > > > > > Similar to PCI and USB devices, which we don't probe via the DT 
> > > > > > > > as well.
> > > > > > > >
> > > > > > > > It's arguably not proper "driver" material per se, as I've 
> > > > > > > > argued before, but
> > > > > > > > it's the simplest solution and fits in nicely otherwise.
> > > > > > > >
> > > > > > > > I was wondering if it might be something for UCLASS_CPU, 
> > > > > > > > something like
> > > > > > > > a "CPU feature bus": to let devices register on one on the many 
> > > > > > > > CPU
> > > > > > > > features (instead of compatible strings), then only bind() those
> > > > > > > > drivers it the respective bit is set.
> > > > > > > >
> > > > > > > > Does that make sense? Would that be doable without boiling the 
> > > > > > > > ocean?
> > > > > > > > As I don't know if we see many users apart from this.
> > > > > > >
> > > > > > > I have seen this so many times, where people want to avoid putting
> > > > > > > things in the DT and then are surprised that everything is 
> > > > > > > difficult,
> > > > > > > broken and confusing. Why not just follow the rules? It is not 
> > > > > > > just
> > > > > > > about whether we can avoid it, etc. It is about how devices fit
> > > > > > > together cohesively in the system, and how U-Boot operates.
> > > > > >
> > > > > > A devicetree is only for peripherals *that cannot be located by 
> > > > > > probing*.
> > > 

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Rob Herring
On Tue, Nov 7, 2023 at 1:30 PM Tom Rini  wrote:
>
> On Tue, Nov 07, 2023 at 01:10:44AM +, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 6 Nov 2023 at 13:46, Tom Rini  wrote:
> > >
> > > On Mon, Nov 06, 2023 at 01:38:39PM -0700, Simon Glass wrote:
> > > > Hi Andre,
> > > >
> > > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  
> > > > wrote:
> > > > >
> > > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > > Simon Glass  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > > Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > > Hi Heinrich,
> > > > > > > >
> > > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > > Heinrich Schuchardt  
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Heinrich,
> > > > > > > > > >
> > > > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the 
> > > > > > > > > >> seed CSR. It
> > > > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > > > >>
> > > > > > > > > >> A RNG driver based on the seed CSR is provided. It depends 
> > > > > > > > > >> on
> > > > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > > > >
> > > > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > > > respective Arm
> > > > > > > > > > functionality:
> > > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > > >
> > > > > > > > > > And I see that you seem to use the same mechanism to probe 
> > > > > > > > > > and init the
> > > > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature 
> > > > > > > > > > is not
> > > > > > > > > > implemented.
> > > > > > > > > > One downside of this approach is that the driver is always 
> > > > > > > > > > loaded (and
> > > > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > > > available.
> > > > > > > > > > That doesn't seem too much of a problem on the first 
> > > > > > > > > > glance, but it
> > > > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > > > devices
> > > > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > > > without
> > > > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > > > VExpress64# rng 0
> > > > > > > > > > No RNG device
> > > > > > > >
> > > > > > > > Why do we get this? If the device is not there, the bind() 
> > > > > > > > function
> > > > > > > > can return -ENODEV
> > > > > > > >
> > > > > > > > I see this in U-Boot:
> > > > > > > >
> > > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > > >
> > > > > > > > We should not use this.
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > > Use the devicetree.
> > > > > > >
> > > > > > > No, this is definitely not something for the DT, at least not on 
> > > > > > > ARM.
> > > > > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > > > > Similar to PCI and USB devices, which we don't probe via the DT 
> > > > > > > as well.
> > > > > > >
> > > > > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > > > > before, but
> > > > > > > it's the simplest solution and fits in nicely otherwise.
> > > > > > >
> > > > > > > I was wondering if it might be something for UCLASS_CPU, 
> > > > > > > something like
> > > > > > > a "CPU feature bus": to let devices register on one on the many 
> > > > > > > CPU
> > > > > > > features (instead of compatible strings), then only bind() those
> > > > > > > drivers it the respective bit is set.
> > > > > > >
> > > > > > > Does that make sense? Would that be doable without boiling the 
> > > > > > > ocean?
> > > > > > > As I don't know if we see many users apart from this.
> > > > > >
> > > > > > I have seen this so many times, where people want to avoid putting
> > > > > > things in the DT and then are surprised that everything is 
> > > > > > difficult,
> > > > > > broken and confusing. Why not just follow the rules? It is not just
> > > > > > about whether we can avoid it, etc. It is about how devices fit
> > > > > > together cohesively in the system, and how U-Boot operates.
> > > > >
> > > > > A devicetree is only for peripherals *that cannot be located by 
> > > > > probing*.
> > > >
> > > > I have to stop you there. It absolutely is not limited to that.
> > >
> > > It is limited to that if we're going to keep using the device trees that
> > > Linux uses. Full stop. There's not really wiggle room there either.
> >
> > That is really the problem, I agree.
>
> And we need to accept that, and what is/isn't something that we can
> 

Re: [RFC PATCH v10 00/24] Modernize U-Boot shell

2023-11-07 Thread Francis Laniel
Hi!


Le lundi 9 octobre 2023, 20:56:30 EET Simon Glass a écrit :
> Hi Francis,
> 
> On Wed, 4 Oct 2023 at 10:42, Francis Laniel <
> 
> francis.lan...@amarulasolutions.com> wrote:
> > Hi.
> > 
> > 
> > During 2021 summer, Sean Anderson wrote a contribution to add a new
> 
> shell, based
> 
> > on LIL, to U-Boot [1, 2].
> > While one of the goals of this contribution was to address the fact actual
> > U-Boot shell, which is based on Busybox hush, is old there was a
> 
> discussion
> 
> > about adding a new shell versus updating the actual one [3, 4].
> > 
> > So, in this series, with Harald Seiler, we updated the actual U-Boot
> 
> shell to
> 
> > reflect what is currently in Busybox source code.
> > Basically, this contribution is about taking a snapshot of Busybox
> 
> shell/hush.c
> 
> > file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
> > 
> > This contribution was written to be as backward-compatible as possible to
> 
> avoid
> 
> > breaking the existing.
> > So, the 2021 hush flavor offers the same as the actual, that is to say:
> > 1. Variable expansion.
> > 2. Instruction lists (;, && and ||).
> > 3. If, then and else.
> > 4. Loops (for, while and until).
> > No new features offered by Busybox hush were implemented (e.g. functions).
> > 
> > It is possible to change the parser at runtime using the "cli" command:
> > => cli print
> > old
> > => cli set 2021
> > => cli print
> > 2021
> > => cli set old
> > The default parser is the old one.
> > Note that to use both parser, you would need to set both
> 
> CONFIG_HUSH_2021_PARSER
> 
> > and CONFIG_HUSH_OLD_PARSER.
> > 
> > In terms of testing, new unit tests were added to ut to ensure the new
> 
> behavior
> 
> > is the same as the old one and it does not add regression.
> > Nonetheless, if old behavior was buggy and fixed upstream, the fix is
> 
> then added
> 
> > to U-Boot [5].
> > In sandbox, all of these tests pass smoothly:
> > => printenv board
> > board=sandbox
> > => ut hush
> > Running 20 hush tests
> > ...
> > Failures: 0
> > => parser set 2021
> > => ut hush
> > Running 20 hush tests
> > ...
> > Failures: 0
> > 
> > Thanks to the effort of Harald Seiler, I was successful booting a board:
> > => printenv fdtfile
> > fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> > => cli get
> > old
> 
> This is a really nice integration.
> 
> I think it could benefit from a new Kconfig like CONFIG_HUSH_SELECTABLE
> which enables the cli command and selection of parser...this could perhaps
> be enabled automatically if two parsers are selected. Then the code growth
> (about 1KB on Thumb 2) would mostly go away.

Excellent idea!
I added this in v11 but did not find a way to count how many options were set, 
so HUSH_SELECTABLE is set when the two hush flavors are selected.

> For checking parsers, the code you use:
> 
>if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
>   int hush_flags = FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP;
> 
>   if (flag & CMD_FLAG_ENV)
>  hush_flags |= FLAG_CONT_ON_NEWLINE;
>   return parse_string_outer(cmd, hush_flags);
>} else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
> ...
>   return parse_string_outer_2021(cmd, FLAG_EXIT_FROM_LOOP);
>}
> 
> could be written to reduce code size...i.e. there is only a need to check
> the gd flag if HUSH_SELECTABLE is enabled, so:
> 
> static inline bool use_hush_old(void)
> {
>  return IS_ENABLED(CONFIG_HUSH_SELECTABLE) ?
>  gd->flags & GD_FLG_HUSH_OLD_PARSER :
>  IS_ENABLD(CONFIG_HUSH_OLD_PARSER);
> }
> 
> Then use that function in the code able.

Indeed! Thank you for the suggestion!

> Size growth when swtiching to the the new parser is only 3KB, from my test.
> I thought it would be much more?
> 
> > => boot
> > ...
> > root@lepotato:~#
> > root@lepotato:~# reboot
> > ...
> > => cli set 2021
> > => cli get
> > 2021
> > => printenv fdtfile
> > fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> > => boot
> > ...
> > root@lepotato:~#
> > 
> > I had to not use CONFIG_HUSH_2021_PARSER for the keymile board.
> > Indeed, the keymile board family is the only set of boards to call
> > get_local_var(), set_local_var() and unset_local_var().
> > Sadly, these functions are static in this contribution.
> > I could have change all of them to introduce code like this:
> > *_local_var(/*...*/)
> > {
> > 
> > if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
> > 
> > return *_local_var_old(/*...*/);
> > 
> > if (gd->flags & GD_FLG_HUSH_2021_PARSER)
> > 
> > return *_local_var_2021(/*...*/);
> > 
> > }
> > But this would have mean renaming all old hush functions calls and I did
> 
> not
> 
> > want to change the old hush particularly to avoid breaking things.
> > Instead, I change the keymile board to use environment variable instead
> 
> of local
> 
> > ones.
> > I think this particularities can be addressed in future works.
> 
> I agree.
> 
> > I also had to enable CONFIG_LTO for 

Re: [RFC PATCH v10 11/24] cmd: Add new cli command

2023-11-07 Thread Francis Laniel
Hi!


Le jeudi 5 octobre 2023, 02:26:52 EET Heinrich Schuchardt a écrit :
> On 10/4/23 18:42, Francis Laniel wrote:
> > This command can be used to print the current parser with 'cli print'.
> 
> Please, provide a commit message that matches the code.
> 
> > It can also be used to set the current parser with 'cli set'.
> > For the moment, only one value is valid for set: old.
> 
> If there is only one valid value, we should not provide the 'cli'
> command to save code size. The patch seems to be in the wrong spot in
> the series.

Thank you for your feedback! I normally addressed this problem in v11.

> > Signed-off-by: Francis Laniel 
> > ---
> > 
> >   cmd/Makefile  |   2 +
> >   cmd/cli.c | 120 ++
> >   common/cli.c  |   3 +-
> >   doc/usage/cmd/cli.rst |  59 +
> >   doc/usage/index.rst   |   1 +
> >   5 files changed, 184 insertions(+), 1 deletion(-)
> >   create mode 100644 cmd/cli.c
> >   create mode 100644 doc/usage/cmd/cli.rst
> > 
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 9bebf321c3..d468cc5065 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -226,6 +226,8 @@ obj-$(CONFIG_CMD_AVB) += avb.o
> > 
> >   # Foundries.IO SCP03
> >   obj-$(CONFIG_CMD_SCP03) += scp03.o
> > 
> > +obj-$(CONFIG_HUSH_PARSER) += cli.o
> 
> Don't waste binary code size. We only need the command if at least two
> parsers are available.
> 
> ifeq ($(CONFIG_HUSH_OLD_PARSER)$(HUSH_2021_PARSER),yy)
> obj-y += cli.o
> endif
> 
> The symbol CONFIG_HUSH_PARSER should be eliminated.
> 
> > +
> > 
> >   obj-$(CONFIG_ARM) += arm/
> >   obj-$(CONFIG_RISCV) += riscv/
> >   obj-$(CONFIG_SANDBOX) += sandbox/
> > 
> > diff --git a/cmd/cli.c b/cmd/cli.c
> > new file mode 100644
> > index 00..7671785b83
> > --- /dev/null
> > +++ b/cmd/cli.c
> > @@ -0,0 +1,120 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static const char *gd_flags_to_parser(void)
> > +{
> > +   if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
> > +   return "old";
> > +   return NULL;
> > +}
> > +
> > +static int do_cli_get(struct cmd_tbl *cmdtp, int flag, int argc,
> > +char *const argv[])
> > +{
> > +   const char *current = gd_flags_to_parser();
> > +
> > +   if (!current) {
> > +   printf("current cli value is not valid, this should not happen!
\n");
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > +   printf("%s\n", current);
> > +
> > +   return CMD_RET_SUCCESS;
> > +}
> > +
> 
> Please, describe this function (and all the others) in Sphinx style.
> 
> /**
>   * parser_string_to_gd_flags() - converts parser name to bit mask
>   *
>   * @parser:  parser name
>   * Return:   valid bit mask or -1
>   */
> 
> > +static int parser_string_to_gd_flags(const char *parser)
> > +{
> > +   if (!strcmp(parser, "old"))
> > +   return GD_FLG_HUSH_OLD_PARSER;
> 
> Please, do not return an invalid bit mask.
> 
> if (CONFIG_IS_ENABLED(HUSH_OLD_PARSER) && !strcmp(parser, "old"))
>   return GD_FLG_HUSH_OLD_PARSER;
> if (CONFIG_IS_ENABLED(HUSH_2021_PARSER) && !strcmp(parser, "2021"))
>   return GD_FLG_HUSH_201_PARSER;
> 
> > +   return -1;
> > +}
> > +
> > +static void reset_parser_gd_flags(void)
> > +{
> > +   gd->flags &= ~GD_FLG_HUSH_OLD_PARSER;
> 
> gd->flags &= ~(GD_FLG_HUSH_OLD_PARSER | GD_FLG_HUSH_2021_PARSER);
> 
> If there were only one parser, we wouldn't create this command.
> 
> > +}
> > +
> > +static int do_cli_set(struct cmd_tbl *cmdtp, int flag, int argc,
> > + char *const argv[])
> > +{
> > +   char *parser_name;
> > +   int parser_flag;
> > +
> > +   if (argc < 2)
> > +   return CMD_RET_USAGE;
> > +
> > +   parser_name = argv[1];
> > +
> > +   parser_flag = parser_string_to_gd_flags(parser_name);
> 
> This function should return -1 for for any value that is not supported
> be it 'foo', 'old', or '2021'. Then you can eliminate a bunch of error
> checking code below.
> 
> > +   if (parser_flag == -1) {
> > +   printf("Bad value for parser name: %s\n", parser_name);
> > +   return CMD_RET_USAGE;
> > +   }
> > +
> > +   if (parser_flag == GD_FLG_HUSH_OLD_PARSER &&
> > +   !CONFIG_IS_ENABLED(HUSH_OLD_PARSER)) {
> > +   printf("Want to set current parser to old, but its code was not
> > compiled!\n"); +return CMD_RET_FAILURE;
> > +   }
> 
> Superfluous check, see above.
> 
> > +
> > +   if (parser_flag == GD_FLG_HUSH_2021_PARSER &&
> > +   !CONFIG_IS_ENABLED(HUSH_2021_PARSER)) {
> > +   printf("Want to set current parser to 2021, but its code was 
not
> > compiled!\n"); +return CMD_RET_FAILURE;
> > +   }
> 
> Superfluous check, see above.
> 
> > +
> > +   reset_parser_gd_flags();
> > +   gd->flags |= parser_flag;
> > +
> > +   cli_init();
> > +   cli_loop();
> > +
> > +   /* cli_loop() 

[PATCH v11 24/24] DO NOT MERGE: ci: Build the world in any case.

2023-11-07 Thread Francis Laniel
The CI can fails previously for reasons which are not tied to hush 2021.
Let's build the world in any case to check everything is OK there too.

Signed-off-by: Francis Laniel 
---
 .azure-pipelines.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index d6f3fa423c..4eaf0e9062 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -469,6 +469,7 @@ stages:
 retryCountOnTaskFailure: 2 # QEMU may be too slow, etc.
 
 - stage: world_build
+  condition: always()
   jobs:
   - job: build_the_world
 timeoutInMinutes: 0 # Use the maximum allowed
-- 
2.34.1



[PATCH v11 23/24] DO NOT MERGE: only to make CI happy

2023-11-07 Thread Francis Laniel
This commit set CONFIG_HUSH_PARSER_2021 as the default to trigger the CI with
this parser.

Nonetheless, the keymile (i.e. VENDOR_KM) board family is not compatible with
new 2021 hush parser.
Indeed, This boards used set_local_var() to store some variables as local shell.
They then used get_local_var() to retrieve the variables values.
Sadly, this two functions do not exist with CONFIG_HUSH_PARSER_2021.
A patch was proposed to use environment variables rather than local variables
but it does not tackle the problem, so complementary work is needed to make
this boards use CONFIG_HUSH_PARSER_2021 [1].

We also remove a #undef of CONFIG_FEATURE_SH_STANDALONE as it does not exist in
U-Boot and causes troubles in the CI.

We also set CONFIG_LTO for kirkwoord sheevaplug and phytec bk4r1, otherwise it
hits its board size limit.

We also disable some check for pylint as it was not able to find future for
commit object.

Acked-by: Tony Dinh 
Signed-off-by: Francis Laniel 
[1] https://marc.info/?l=u-boot=165541917618725=2
---
 cmd/Kconfig  | 3 ++-
 common/cli_hush_upstream.c   | 1 -
 configs/sheevaplug_defconfig | 1 +
 tools/patman/series.py   | 4 
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4641333809..3c36833f4d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -28,7 +28,7 @@ menu "Hush flavor to use"
 
config HUSH_OLD_PARSER
bool "Use hush old parser"
-   default y
+   default y if VENDOR_KM
help
  This option enables the old flavor of hush based on hush 
Busybox from
  2005.
@@ -37,6 +37,7 @@ menu "Hush flavor to use"
 
config HUSH_2021_PARSER
bool "Use hush 2021 parser"
+   default y if !VENDOR_KM
help
  This option enables the new flavor of hush based on hush 
Busybox from
  2021.
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index 709c055d2f..243710ab51 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -427,7 +427,6 @@
 #include "NUM_APPLETS.h"
 #if NUM_APPLETS == 1
 /* STANDALONE does not make sense, and won't compile */
-# undef CONFIG_FEATURE_SH_STANDALONE
 # undef ENABLE_FEATURE_SH_STANDALONE
 # undef IF_FEATURE_SH_STANDALONE
 # undef IF_NOT_FEATURE_SH_STANDALONE
diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig
index 2e4901b840..365f779cc8 100644
--- a/configs/sheevaplug_defconfig
+++ b/configs/sheevaplug_defconfig
@@ -16,6 +16,7 @@ CONFIG_ENV_OFFSET=0x8
 CONFIG_DEFAULT_DEVICE_TREE="kirkwood-sheevaplug"
 CONFIG_IDENT_STRING="\nMarvell-Sheevaplug"
 CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_LTO=y
 CONFIG_HAS_BOARD_SIZE_LIMIT=y
 CONFIG_BOARD_SIZE_LIMIT=524288
 CONFIG_BOOTDELAY=3
diff --git a/tools/patman/series.py b/tools/patman/series.py
index 6866e1dbd0..f99818e33a 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -316,6 +316,8 @@ class Series(dict):
 # Show progress any commits that are taking forever
 lastlen = 0
 while True:
+# pylint does not find future which is set above.
+# pylint: disable=E1101
 left = [commit for commit in self.commits
 if not commit.future.done()]
 if not left:
@@ -333,6 +335,8 @@ class Series(dict):
 print('Cc processing complete')
 
 for commit in self.commits:
+# pylint does not find future which is set above.
+# pylint: disable=E1101
 cc = commit.future.result()
 all_ccs += cc
 print(commit.patch, '\0'.join(sorted(set(cc))), file=fd)
-- 
2.34.1



[PATCH v11 22/24] cli: hush_2021: Add upstream commits up to 2nd October 2023.

2023-11-07 Thread Francis Laniel
This commit adds the following hush busybox upstream commits:
791b222dd55d ("sleep: fix "sleep -- ARGS"")
5353df91cba7 ("Update applet size estimates")
e41e481fd571 ("hush: fix a compile failure")
07a95cfcabb0 ("ash: disable check for "good" function name, bash does not check 
this")
e5692e2342c6 ("hush: quote values in "readonly" output")
96769486e20f ("shell: move varcmp() to shell_common.h and use it in hush")
bab8828b0dad ("hush: fix expansion of space in "a=${a:+$a }c" construct")
b5be8da350b5 ("hush: make "false" built-in")
6824298ab4d3 ("hush: fix ELIF cmd1;cmd2 THEN ... not executing cmd2, closes 
15571")
3a7f00eadcf4 ("hush: add comment about abort on syntax error %{^}")
acae889dd972 ("ash,hush: tab completion of functions and aliases")
90b607d79a13 ("hush: quote variable values printed by "set" (match ash 
behavior)")
6748e6494c22 ("hush (NOMMU): fix LINENO in execed children")
fd5fb2d2b596 ("hush: speed up "big heredoc" code")
1409432d072e ("hush: add TODO comment")
93ae7464e6e4 ("hush: restore SIGHUP handling, this time explain why we do what 
we do")
1fdb33bd07e5 ("hush: restore tty pgrp on SIGHUP")
6101b6d3eaa0 ("hush: remove special handling of SIGHUP")
93e0898c663a ("shell: fix SIGWINCH and SIGCHLD (in hush) interrupting line 
input, closes 15256")
969e00816835 ("hush: code shrink")
27be0e8cfeb6 ("shell: fix compile failures in some configs")
7d1c7d833785 ("ash,hush: use HOME for tab completion and prompts")
21afddefd258 ("hush: fix "error: invalid preprocessing directive ##"")
e53c7dbafc78 ("hush: fix set -n to act immediately, not just after run_list()")
574b9c446da1 ("hush: fix var_LINENO3.tests failure")
49bcf9f40cff ("hush: speed up ${x//\*/|} too")
53b2fdcdba4c ("*: add NOINLINEs where code noticeably shrinks")
7c3e96d4b3d4 ("shell: use more compact SHELL_ASH / HUSH config defines. no code 
changes")
62f1eed1e191 ("hush: in a comment, document what -i might be doing")
aaf3d5ba74c5 ("shell: tweak --help")
db5546ca1018 ("libbb: code shrink: introduce and use [_]exit_SUCCESS()")
931c55f9e2b4 ("libbb: invert the meaning of SETUP_ENV_NO_CHDIR -> 
SETUP_ENV_CHDIR")
12566e7f9b5e ("ash,hush: fix handling of SIGINT while waiting for interactive 
input")
987be932ed3c ("*: slap on a few ALIGN_PTR where appropriate")

Signed-off-by: Francis Laniel 
---
 common/cli_hush_2021.c |  20 +-
 common/cli_hush_upstream.c | 407 ++---
 2 files changed, 304 insertions(+), 123 deletions(-)

diff --git a/common/cli_hush_2021.c b/common/cli_hush_2021.c
index 0a207d147b..15a5d3134e 100644
--- a/common/cli_hush_2021.c
+++ b/common/cli_hush_2021.c
@@ -26,7 +26,7 @@
 /*
  * BusyBox Version: UPDATE THIS WHEN PULLING NEW UPSTREAM REVISION!
  */
-#define BB_VER "1.34.0.git37460f5daff9"
+#define BB_VER "1.35.0.git7d1c7d833785"
 
 /*
  * Define hush features by the names used upstream.
@@ -236,6 +236,24 @@ static size_t list_size(char **list)
return size;
 }
 
+static int varcmp(const char *p, const char *q)
+{
+   int c, d;
+
+   while ((c = *p) == (d = *q)) {
+   if (c == '\0' || c == '=')
+   goto out;
+   p++;
+   q++;
+   }
+   if (c == '=')
+   c = '\0';
+   if (d == '=')
+   d = '\0';
+out:
+   return c - d;
+}
+
 struct in_str;
 static int u_boot_cli_readline(struct in_str *i);
 
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index 23392939e1..709c055d2f 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -91,7 +91,7 @@
  * in word = GLOB, quoting should be significant on char-by-char basis: a*cd"*"
  */
 //config:config HUSH
-//config:  bool "hush (68 kb)"
+//config:  bool "hush (70 kb)"
 //config:  default y
 //config:  select SHELL_HUSH
 //config:  help
@@ -339,7 +339,7 @@
  * therefore we don't show them either.
  */
 //usage:#define hush_trivial_usage
-//usage:   "[-enxl] [-c 'SCRIPT' [ARG0 ARGS] | FILE [ARGS] | -s [ARGS]]"
+//usage:   "[-enxl] [-c 'SCRIPT' [ARG0 ARGS] | FILE ARGS | -s ARGS]"
 //usage:#define hush_full_usage "\n\n"
 //usage:   "Unix shell interpreter"
 
@@ -374,7 +374,7 @@
 # define F_DUPFD_CLOEXEC F_DUPFD
 #endif
 
-#if ENABLE_FEATURE_SH_EMBEDDED_SCRIPTS && !(ENABLE_ASH || ENABLE_SH_IS_ASH || 
ENABLE_BASH_IS_ASH)
+#if ENABLE_FEATURE_SH_EMBEDDED_SCRIPTS && !ENABLE_SHELL_ASH
 # include "embedded_scripts.h"
 #else
 # define NUM_SCRIPTS 0
@@ -574,7 +574,7 @@ enum {
 #define NULL_O_STRING { NULL }
 
 #ifndef debug_printf_parse
-static const char *const assignment_flag[] = {
+static const char *const assignment_flag[] ALIGN_PTR = {
"MAYBE_ASSIGNMENT",
"DEFINITELY_ASSIGNMENT",
"NOT_ASSIGNMENT",
@@ -958,6 +958,7 @@ struct globals {
 #if ENABLE_HUSH_INTERACTIVE
smallint promptmode; /* 0: PS1, 1: PS2 */
 #endif
+   /* set by signal handler if SIGINT is received _and_ its trap is not 
set */
smallint 

[PATCH v11 21/24] test: hush: Fix loop tests for hush 2021

2023-11-07 Thread Francis Laniel
Modifies return code got from while loop as hush 2021 always returns 0 from
while loop.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 test/hush/loop.c | 34 ++
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/test/hush/loop.c b/test/hush/loop.c
index ca777e38fe..add5402a32 100644
--- a/test/hush/loop.c
+++ b/test/hush/loop.c
@@ -9,6 +9,9 @@
 #include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 static int hush_test_for(struct unit_test_state *uts)
 {
@@ -21,7 +24,12 @@ static int hush_test_for(struct unit_test_state *uts)
ut_assert_nextline("quux");
ut_assert_console_end();
 
-   puts("Beware: this test set local variable loop_i and it cannot be 
unset!");
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /* Reset local variable. */
+   ut_assertok(run_command("loop_i=", 0));
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   puts("Beware: this test set local variable loop_i and it cannot 
be unset!");
+   }
 
return 0;
 }
@@ -31,12 +39,30 @@ static int hush_test_while(struct unit_test_state *uts)
 {
console_record_reset_enable();
 
-   /* Exit status is that of test, so 1 since test is false to quit the 
loop. */
-   ut_asserteq(1, run_command("while test -z \"$loop_foo\"; do echo bar; 
loop_foo=quux; done", 0));
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* Hush 2021 always returns 0 from while loop...
+* You can see code snippet near this line to have a better
+* understanding:
+* debug_printf_exec(": while expr is false: breaking 
(exitcode:EXIT_SUCCESS)\n");
+*/
+   ut_assertok(run_command("while test -z \"$loop_foo\"; do echo 
bar; loop_foo=quux; done", 0));
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   /*
+* Exit status is that of test, so 1 since test is false to quit
+* the loop.
+*/
+   ut_asserteq(1, run_command("while test -z \"$loop_foo\"; do 
echo bar; loop_foo=quux; done", 0));
+   }
ut_assert_nextline("bar");
ut_assert_console_end();
 
-   puts("Beware: this test set local variable loop_foo and it cannot be 
unset!");
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /* Reset local variable. */
+   ut_assertok(run_command("loop_foo=", 0));
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   puts("Beware: this test set local variable loop_foo and it 
cannot be unset!");
+   }
 
return 0;
 }
-- 
2.34.1



[PATCH v11 20/24] cli: hush_2021: Enable loops

2023-11-07 Thread Francis Laniel
Enables the use of for, while and until loops for command line as
well as with run_command().

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 common/cli_hush_2021.c |  1 +
 common/cli_hush_upstream.c | 15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/common/cli_hush_2021.c b/common/cli_hush_2021.c
index aba5dcbbcd..0a207d147b 100644
--- a/common/cli_hush_2021.c
+++ b/common/cli_hush_2021.c
@@ -34,6 +34,7 @@
 #define ENABLE_HUSH_INTERACTIVE1
 #define ENABLE_FEATURE_EDITING 1
 #define ENABLE_HUSH_IF 1
+#define ENABLE_HUSH_LOOPS  1
 /* No MMU in U-Boot */
 #define BB_MMU 0
 #define USE_FOR_NOMMU(...) __VA_ARGS__
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index 9b65dcbde1..23392939e1 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -10349,7 +10349,7 @@ static int run_list(struct pipe *pi)
 #ifndef __U_BOOT__
for (; pi; pi = IF_HUSH_LOOPS(rword == RES_DONE ? loop_top : ) 
pi->next) {
 #else /* __U_BOOT__ */
-   for (; pi; pi = pi->next) {
+   for (; pi; pi = rword == RES_DONE ? loop_top : pi->next) {
 #endif /* __U_BOOT__ */
int r;
int sv_errexit_depth;
@@ -10451,7 +10451,20 @@ static int run_list(struct pipe *pi)
}
/* Insert next value from for_lcur */
/* note: *for_lcur already has quotes removed, $var 
expanded, etc */
+#ifndef __U_BOOT__
set_local_var(xasprintf("%s=%s", pi->cmds[0].argv[0], 
*for_lcur++), /*flag:*/ 0);
+#else /* __U_BOOT__ */
+   /* We cannot use xasprintf, so we emulate it. */
+   char *full_var;
+   char *var = pi->cmds[0].argv[0];
+   char *val = *for_lcur++;
+
+   /* + 1 to take into account =. */
+   full_var = xmalloc(strlen(var) + strlen(val) + 1);
+   sprintf(full_var, "%s=%s", var, val);
+
+   set_local_var_2021(full_var, /*flag:*/ 0);
+#endif /* __U_BOOT__ */
continue;
}
if (rword == RES_IN) {
-- 
2.34.1



[PATCH v11 19/24] cli: hush_2021: Enable if keyword

2023-11-07 Thread Francis Laniel
Adds support for "if then else" construct both for command line interface and
through run_command().

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 common/cli_hush_2021.c | 11 +++
 common/cli_hush_upstream.c | 12 
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/common/cli_hush_2021.c b/common/cli_hush_2021.c
index 7dd30ea0ef..aba5dcbbcd 100644
--- a/common/cli_hush_2021.c
+++ b/common/cli_hush_2021.c
@@ -33,6 +33,7 @@
  */
 #define ENABLE_HUSH_INTERACTIVE1
 #define ENABLE_FEATURE_EDITING 1
+#define ENABLE_HUSH_IF 1
 /* No MMU in U-Boot */
 #define BB_MMU 0
 #define USE_FOR_NOMMU(...) __VA_ARGS__
@@ -124,6 +125,11 @@ static void bb_error_msg(const char *s, ...)
va_end(p);
 }
 
+static void bb_simple_error_msg(const char *s)
+{
+   bb_error_msg("%s", s);
+}
+
 static void *xmalloc(size_t size)
 {
void *p = NULL;
@@ -147,6 +153,11 @@ static void *xrealloc(void *ptr, size_t size)
return p;
 }
 
+static void *xmemdup(const void *s, int n)
+{
+   return memcpy(xmalloc(n), s, n);
+}
+
 #define xstrdupstrdup
 #define xstrndup   strndup
 
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index 68a9a4bb72..9b65dcbde1 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -1488,7 +1488,6 @@ static void msg_and_die_if_script(unsigned lineno, const 
char *fmt, ...)
die_if_script();
 }
 
-#ifndef __U_BOOT__
 static void syntax_error(unsigned lineno UNUSED_PARAM, const char *msg)
 {
if (msg)
@@ -1497,7 +1496,6 @@ static void syntax_error(unsigned lineno UNUSED_PARAM, 
const char *msg)
bb_simple_error_msg("syntax error");
die_if_script();
 }
-#endif /* !__U_BOOT__ */
 
 static void syntax_error_at(unsigned lineno UNUSED_PARAM, const char *msg)
 {
@@ -3962,7 +3960,6 @@ static void debug_print_tree(struct pipe *pi, int lvl)
[PIPE_OR ] = "OR" ,
[PIPE_BG ] = "BG" ,
};
-#ifndef __U_BOOT__
static const char *RES[] = {
[RES_NONE ] = "NONE" ,
 # if ENABLE_HUSH_IF
@@ -3992,7 +3989,6 @@ static void debug_print_tree(struct pipe *pi, int lvl)
[RES_ ] = "" ,
[RES_SNTX ] = "SNTX" ,
};
-#endif /* !__U_BOOT__ */
static const char *const CMDTYPE[] = {
"{}",
"()",
@@ -4010,10 +4006,8 @@ static void debug_print_tree(struct pipe *pi, int lvl)
lvl*2, "",
pin,
pi->num_cmds,
-#ifdef __U_BOOT__
(IF_HAS_KEYWORDS(pi->pi_inverted ? "! " :) ""),
RES[pi->res_word],
-#endif /* !__U_BOOT__ */
pi->followup, PIPE[pi->followup]
);
prn = 0;
@@ -9833,6 +9827,7 @@ static NOINLINE int run_pipe(struct pipe *pi)
rcode = 1; /* exitcode if redir failed */
 #ifndef __U_BOOT__
if (setup_redirects(command, ) == 0) {
+#endif /* !__U_BOOT__ */
debug_printf_exec(": run_list\n");
 //FIXME: we need to pass squirrel down into run_list()
 //for SH_STANDALONE case, or else this construct:
@@ -9841,10 +9836,11 @@ static NOINLINE int run_pipe(struct pipe *pi)
 //and in SH_STANDALONE mode, "find" is not execed,
 //therefore CLOEXEC on saved fd does not help.
rcode = run_list(command->group) & 0xff;
+#ifndef __U_BOOT__
}
restore_redirects(squirrel);
-   IF_HAS_KEYWORDS(if (pi->pi_inverted) rcode = !rcode;)
 #endif /* !__U_BOOT__ */
+   IF_HAS_KEYWORDS(if (pi->pi_inverted) rcode = !rcode;)
debug_leave();
debug_printf_exec("run_pipe: return %d\n", rcode);
return rcode;
@@ -10363,12 +10359,12 @@ static int run_list(struct pipe *pi)
break;
if (G_flag_return_in_progress == 1)
break;
+#endif /* !__U_BOOT__ */
 
IF_HAS_KEYWORDS(rword = pi->res_word;)
debug_printf_exec(": rword=%d cond_code=%d last_rword=%d\n",
rword, cond_code, last_rword);
 
-#endif /* !__U_BOOT__ */
sv_errexit_depth = G.errexit_depth;
if (
 #if ENABLE_HUSH_IF
-- 
2.34.1



[PATCH v11 18/24] cli: hush_2021: Enable using < and > as string compare operators

2023-11-07 Thread Francis Laniel
In Busybox hush, '<' and '>' are used as redirection operators.
For example, cat foo > bar will write content of file foo inside file bar.
In U-Boot, we do not have file system, so we can hardly redirect command output
inside a file.

But, in actual U-Boot hush, these operators ('<' and '>') are used as string
compare operators.
For example, test aaa < bbb returns 0 as aaa is before bbb in the dictionary.
Busybox hush also permits this, but operators need to be escaped ('\<' and
'\>').
Indeed, if escaping is needed it permits the developer to think about its code,
as in a lot of case, we want to compare integers (using '-lt' or '-gt') rather
than strings.

As testing in U-Boot is handled by the test command, we will stick with the
original behaviour and not adapt to Busybox one.

Nonetheless, if one day we decide to implement test with '[[ ]]', we will then
stick to upstream Busybox behavior.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 common/cli_hush_upstream.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index dbf77ad503..68a9a4bb72 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -6160,7 +6160,28 @@ static struct pipe *parse_stream(char **pstring,
if (parse_redirect(, redir_fd, redir_style, input))
goto parse_error_exitcode1;
continue; /* get next char */
-#endif /* !__U_BOOT__ */
+#else /* __U_BOOT__ */
+   /*
+* In U-Boot, '<' and '>' can be used in test command 
to test if
+* a string is, alphabetically, before or after another.
+* In 2021 Busybox hush, we will keep the same behavior 
and so not treat
+* them as redirection operator.
+*
+* Indeed, in U-Boot, tests are handled by the test 
command and not by the
+* shell code.
+* So, better to give this character as input to test 
command.
+*
+* NOTE In my opinion, when you use '<' or '>' I am 
almost sure
+* you wanted to use "-gt" or "-lt" in place, so 
thinking to
+* escape these will make you should check your code 
(sh syntax
+* at this level is, for me, error prone).
+*/
+   case '>':
+   fallthrough;
+   case '<':
+   o_addQchr(, ch);
+   continue;
+#endif /* __U_BOOT__ */
case '#':
if (ctx.word.length == 0 && !ctx.word.has_quoted_part) {
/* skip "#comment" */
-- 
2.34.1



[PATCH v11 17/24] test: hush: Fix variable expansion tests for hush 2021

2023-11-07 Thread Francis Laniel
Modifies the expected result for hush 2021.
Indeed, there were bugs in actual U-Boot hush which were fixed in upstream
Busybox.
As hush 2021 is based on upstream Busybox, these bugs no longer exist.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 test/hush/dollar.c | 79 --
 1 file changed, 69 insertions(+), 10 deletions(-)

diff --git a/test/hush/dollar.c b/test/hush/dollar.c
index defb2c3fd0..f23392c72d 100644
--- a/test/hush/dollar.c
+++ b/test/hush/dollar.c
@@ -9,6 +9,9 @@
 #include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 static int hush_test_simple_dollar(struct unit_test_state *uts)
 {
@@ -51,13 +54,29 @@ static int hush_test_simple_dollar(struct unit_test_state 
*uts)
ut_asserteq(1, run_command("dollar_foo='bar quux", 0));
/* Next line contains error message */
ut_assert_skipline();
-   ut_assert_console_end();
+
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* For some strange reasons, the console is not empty after
+* running above command.
+* So, we reset it to not have side effects for other tests.
+*/
+   console_record_reset_enable();
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_assert_console_end();
+   }
 
ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
/* Two next lines contain error message */
ut_assert_skipline();
ut_assert_skipline();
-   ut_assert_console_end();
+
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /* See above comments. */
+   console_record_reset_enable();
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_assert_console_end();
+   }
 
ut_assertok(run_command("dollar_foo='bar \"quux'", 0));
 
@@ -71,17 +90,35 @@ static int hush_test_simple_dollar(struct unit_test_state 
*uts)
 */
console_record_reset_enable();
 
-   ut_asserteq(1, run_command("dollar_foo=\"bar 'quux\"", 0));
-   /* Next line contains error message */
-   ut_assert_skipline();
-   ut_assert_console_end();
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* Old parser returns an error because it waits for closing
+* '\'', but this behavior is wrong as the '\'' is surrounded by
+* '"', so no need to wait for a closing one.
+*/
+   ut_assertok(run_command("dollar_foo=\"bar 'quux\"", 0));
+
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline("bar 'quux");
+   ut_assert_console_end();
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_asserteq(1, run_command("dollar_foo=\"bar 'quux\"", 0));
+   /* Next line contains error message */
+   ut_assert_skipline();
+   ut_assert_console_end();
+   }
 
ut_assertok(run_command("dollar_foo='bar quux'", 0));
ut_assertok(run_command("echo $dollar_foo", 0));
ut_assert_nextline("bar quux");
ut_assert_console_end();
 
-   puts("Beware: this test set local variable dollar_foo and it cannot be 
unset!");
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /* Reset local variable. */
+   ut_assertok(run_command("dollar_foo=", 0));
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   puts("Beware: this test set local variable dollar_foo and it 
cannot be unset!");
+   }
 
return 0;
 }
@@ -109,7 +146,12 @@ static int hush_test_env_dollar(struct unit_test_state 
*uts)
/* Clean up setting the variable */
env_set("env_foo", NULL);
 
-   puts("Beware: this test set local variable env_foo and it cannot be 
unset!");
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /* Reset local variable. */
+   ut_assertok(run_command("env_foo=", 0));
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   puts("Beware: this test set local variable env_foo and it 
cannot be unset!");
+   }
 
return 0;
 }
@@ -144,7 +186,18 @@ static int hush_test_command_dollar(struct unit_test_state 
*uts)
ut_assertok(run_command("dollar_bar='echo bar\\n'", 0));
 
ut_assertok(run_command("$dollar_bar", 0));
-   ut_assert_nextline("barn");
+
+   if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* This difference seems to come from a bug solved in Busybox
+* hush.
+* Behavior of hush 2021 is coherent with bash and other shells.
+*/
+   ut_assert_nextline("bar\\n");
+   } else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_assert_nextline("barn");
+   }
+
ut_assert_console_end();
 

[PATCH v11 16/24] test: hush: Fix instructions list tests for hush 2021

2023-11-07 Thread Francis Laniel
Modifies the expected result for hush 2021.
Indeed, there were bugs in actual U-Boot hush which were fixed in upstream
Busybox.
As hush 2021 is based on upstream Busybox, these bugs no longer exist.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 test/hush/list.c | 69 +---
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/test/hush/list.c b/test/hush/list.c
index 052cf2783c..6f8f10f15e 100644
--- a/test/hush/list.c
+++ b/test/hush/list.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int hush_test_semicolon(struct unit_test_state *uts)
 {
@@ -46,12 +47,43 @@ static int hush_test_or(struct unit_test_state *uts)
 }
 HUSH_TEST(hush_test_or, 0);
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static int hush_test_and_or(struct unit_test_state *uts)
 {
/* A && B || C truth table. */
ut_asserteq(1, run_command("false && false || false", 0));
-   ut_asserteq(1, run_command("false && false || true", 0));
-   ut_asserteq(1, run_command("false && true || true", 0));
+
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_asserteq(1, run_command("false && false || true", 0));
+   } else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* This difference seems to come from a bug solved in Busybox
+* hush.
+*
+* Indeed, the following expression can be seen like this:
+* (false && false) || true
+* So, (false && false) returns 1, the second false is not
+* executed, and true is executed because of ||.
+*/
+   ut_assertok(run_command("false && false || true", 0));
+   }
+
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_asserteq(1, run_command("false && true || true", 0));
+   } else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* This difference seems to come from a bug solved in Busybox
+* hush.
+*
+* Indeed, the following expression can be seen like this:
+* (false && true) || true
+* So, (false && true) returns 1, the true is not executed, and
+* true is executed because of ||.
+*/
+   ut_assertok(run_command("false && true || true", 0));
+   }
+
ut_asserteq(1, run_command("false && true || false", 0));
ut_assertok(run_command("true && true || false", 0));
ut_asserteq(1, run_command("true && false || false", 0));
@@ -69,8 +101,37 @@ static int hush_test_or_and(struct unit_test_state *uts)
ut_asserteq(1, run_command("false || false && true", 0));
ut_assertok(run_command("false || true && true", 0));
ut_asserteq(1, run_command("false || true && false", 0));
-   ut_assertok(run_command("true || true && false", 0));
-   ut_assertok(run_command("true || false && false", 0));
+
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_assertok(run_command("true || true && false", 0));
+   } else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* This difference seems to come from a bug solved in Busybox
+* hush.
+*
+* Indeed, the following expression can be seen like this:
+* (true || true) && false
+* So, (true || true) returns 0, the second true is not
+* executed, and then false is executed because of &&.
+*/
+   ut_asserteq(1, run_command("true || true && false", 0));
+   }
+
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
+   ut_assertok(run_command("true || false && false", 0));
+   } else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
+   /*
+* This difference seems to come from a bug solved in Busybox
+* hush.
+*
+* Indeed, the following expression can be seen like this:
+* (true || false) && false
+* So, (true || false) returns 0, the false is not executed, and
+* then false is executed because of &&.
+*/
+   ut_asserteq(1, run_command("true || false && false", 0));
+   }
+
ut_assertok(run_command("true || false && true", 0));
ut_assertok(run_command("true || true && true", 0));
 
-- 
2.34.1



[PATCH v11 15/24] cli: add hush 2021 as parser for run_command*()

2023-11-07 Thread Francis Laniel
Enables using, in code, hush 2021 as parser for run_command function family.
It also enables the command run to be used by CLI user of hush 2021.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 common/cli.c   | 67 --
 common/cli_hush_upstream.c |  2 +-
 2 files changed, 51 insertions(+), 18 deletions(-)

diff --git a/common/cli.c b/common/cli.c
index e3e2bc7fe1..e332bdd670 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -25,6 +25,14 @@
 #include 
 
 #ifdef CONFIG_CMDLINE
+
+static inline bool use_hush_old(void)
+{
+   return IS_ENABLED(CONFIG_HUSH_SELECTABLE) ?
+   gd->flags & GD_FLG_HUSH_OLD_PARSER :
+   IS_ENABLED(CONFIG_HUSH_OLD_PARSER);
+}
+
 /*
  * Run a command using the selected parser.
  *
@@ -43,15 +51,30 @@ int run_command(const char *cmd, int flag)
return 1;
 
return 0;
-#elif CONFIG_IS_ENABLED(HUSH_OLD_PARSER)
-   int hush_flags = FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP;
-
-   if (flag & CMD_FLAG_ENV)
-   hush_flags |= FLAG_CONT_ON_NEWLINE;
-   return parse_string_outer(cmd, hush_flags);
-#else /* HUSH_2021_PARSER */
-   /* Not yet implemented. */
-   return 1;
+#else
+   if (use_hush_old()) {
+   int hush_flags = FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP;
+
+   if (flag & CMD_FLAG_ENV)
+   hush_flags |= FLAG_CONT_ON_NEWLINE;
+   return parse_string_outer(cmd, hush_flags);
+   }
+   /*
+* Possible values for flags are the following:
+* FLAG_EXIT_FROM_LOOP: This flags ensures we exit from loop in
+* parse_and_run_stream() after first iteration while normal
+* behavior, * i.e. when called from cli_loop(), is to loop
+* infinitely.
+* FLAG_PARSE_SEMICOLON: Hush 2021 parses ';' and does not stop
+* first time it sees one. So, I think we do not need this flag.
+* FLAG_REPARSING: For the moment, I do not understand the goal
+* of this flag.
+* FLAG_CONT_ON_NEWLINE: This flag seems to be used to continue
+* parsing even when reading '\n' when coming from
+* run_command(). In this case, Hush 2021 reads until it finds
+* '\0'. So, I think we do not need this flag.
+*/
+   return parse_string_outer_2021(cmd, FLAG_EXIT_FROM_LOOP);
 #endif
 }
 
@@ -67,12 +90,23 @@ int run_command_repeatable(const char *cmd, int flag)
 #ifndef CONFIG_HUSH_PARSER
return cli_simple_run_command(cmd, flag);
 #else
+   int ret;
+
+   if (use_hush_old()) {
+   ret = parse_string_outer(cmd,
+FLAG_PARSE_SEMICOLON
+| FLAG_EXIT_FROM_LOOP);
+   } else {
+   ret = parse_string_outer_2021(cmd,
+ FLAG_PARSE_SEMICOLON
+ | FLAG_EXIT_FROM_LOOP);
+   }
+
/*
 * parse_string_outer() returns 1 for failure, so clean up
 * its result.
 */
-   if (parse_string_outer(cmd,
-  FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP))
+   if (ret)
return -1;
 
return 0;
@@ -111,12 +145,11 @@ int run_command_list(const char *cmd, int len, int flag)
buff[len] = '\0';
}
 #ifdef CONFIG_HUSH_PARSER
-#if CONFIG_IS_ENABLED(HUSH_OLD_PARSER)
-   rcode = parse_string_outer(buff, FLAG_PARSE_SEMICOLON);
-#else /* HUSH_2021_PARSER */
-   /* Not yet implemented. */
-   rcode = 1;
-#endif
+   if (use_hush_old()) {
+   rcode = parse_string_outer(buff, FLAG_PARSE_SEMICOLON);
+   } else {
+   rcode = parse_string_outer_2021(buff, FLAG_PARSE_SEMICOLON);
+   }
 #else
/*
 * This function will overwrite any \n it sees with a \0, which
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index b11445c3ac..dbf77ad503 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -8023,7 +8023,7 @@ static int parse_and_run_string(const char *s)
 }
 
 #ifdef __U_BOOT__
-int parse_string_outer(const char *cmd, int flags)
+int parse_string_outer_2021(const char *cmd, int flags)
 {
int ret;
int old_flags;
-- 
2.34.1



[PATCH v11 14/24] cli: hush_2021: Add functions to be called from run_command()

2023-11-07 Thread Francis Laniel
run_command() is called internally by the command run and it can also be called
directly from U-Boot code, e.g. to do unit tests.
This commit adds this path to go to hush 2021.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 common/cli_hush_upstream.c | 66 --
 1 file changed, 63 insertions(+), 3 deletions(-)

diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index b806c5c653..b11445c3ac 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -1012,6 +1012,7 @@ struct globals {
 #ifdef __U_BOOT__
int flag_repeat;
int do_repeat;
+   int run_command_flags;
 #endif /* __U_BOOT__ */
char *ifs_whitespace; /* = G.ifs or malloced */
 #ifndef __U_BOOT__
@@ -3005,7 +3006,24 @@ static int i_getch(struct in_str *i)
if (i->p && *i->p != '\0') {
ch = (unsigned char)*i->p++;
goto out;
+#ifndef __U_BOOT__
}
+#else /* __U_BOOT__ */
+   /*
+* There are two ways for command to be called:
+* 1. The first one is when they are typed by the user.
+* 2. The second one is through run_command() (NOTE command run
+* internally calls run_command()).
+*
+* In the second case, we do not get input from the user, so once we
+* get a '\0', it means we need to stop.
+* NOTE G.run_command_flags is only set on run_command call stack, so
+* we use this to know if we come from user input or run_command().
+*/
+   } else if (i->p && *i->p == '\0' && G.run_command_flags){
+   return EOF;
+   }
+#endif /* __U_BOOT__ */
 #endif
 #ifndef __U_BOOT__
/* peek_buf[] is an int array, not char. Can contain EOF. */
@@ -3164,7 +3182,6 @@ static void setup_file_in_str(struct in_str *i)
 #endif /* !__U_BOOT__ */
 }
 
-#ifndef __U_BOOT__
 static void setup_string_in_str(struct in_str *i, const char *s)
 {
memset(i, 0, sizeof(*i));
@@ -3172,7 +3189,6 @@ static void setup_string_in_str(struct in_str *i, const 
char *s)
i->p = s;
 }
 
-#endif /* !__U_BOOT__ */
 
 /*
  * o_string support
@@ -7911,7 +7927,11 @@ static int run_and_free_list(struct pipe *pi);
  * NUL: parse all, execute, return
  * ';': parse till ';' or newline, execute, repeat till EOF
  */
+#ifndef __U_BOOT__
 static void parse_and_run_stream(struct in_str *inp, int end_trigger)
+#else /* __U_BOOT__ */
+static int parse_and_run_stream(struct in_str *inp, int end_trigger)
+#endif /* __U_BOOT__ */
 {
/* Why we need empty flag?
 * An obscure corner case "false; ``; echo $?":
@@ -7920,7 +7940,11 @@ static void parse_and_run_stream(struct in_str *inp, int 
end_trigger)
 * this breaks "false; echo `echo $?`" case.
 */
bool empty = 1;
+#ifndef __U_BOOT__
while (1) {
+#else /* __U_BOOT__ */
+   do {
+#endif /* __U_BOOT__ */
struct pipe *pipe_list;
 
 #if ENABLE_HUSH_INTERACTIVE
@@ -7967,21 +7991,57 @@ static void parse_and_run_stream(struct in_str *inp, 
int end_trigger)
empty = 0;
if (G_flag_return_in_progress == 1)
break;
+#ifndef __U_BOOT__
}
+#else /* __U_BOOT__ */
+   /*
+* This do/while is needed by run_command to avoid looping on a command
+* with syntax error.
+*/
+   } while (!(G.run_command_flags & FLAG_EXIT_FROM_LOOP));
+
+   return G.last_exitcode;
+#endif /* __U_BOOT__ */
 }
 
 #ifndef __U_BOOT__
 static void parse_and_run_string(const char *s)
+#else /* __U_BOOT__ */
+static int parse_and_run_string(const char *s)
+#endif /* __U_BOOT__ */
 {
struct in_str input;
//IF_HUSH_LINENO_VAR(unsigned sv = G.parse_lineno;)
 
setup_string_in_str(, s);
+#ifndef __U_BOOT__
parse_and_run_stream(, '\0');
+#else /* __U_BOOT__ */
+   return parse_and_run_stream(, '\0');
+#endif /* __U_BOOT__ */
//IF_HUSH_LINENO_VAR(G.parse_lineno = sv;)
 }
-#endif /* !__U_BOOT__ */
 
+#ifdef __U_BOOT__
+int parse_string_outer(const char *cmd, int flags)
+{
+   int ret;
+   int old_flags;
+
+   /*
+* Keep old values of run_command to be able to restore them once
+* command was executed.
+*/
+   old_flags = G.run_command_flags;
+   G.run_command_flags = flags;
+
+   ret = parse_and_run_string(cmd);
+
+   G.run_command_flags = old_flags;
+
+   return ret;
+}
+#endif /* __U_BOOT__ */
 #ifndef __U_BOOT__
 static void parse_and_run_file(HFILE *fp)
 #else /* __U_BOOT__ */
-- 
2.34.1



[PATCH v11 13/24] cli: hush_2021: Enable variables expansion for hush 2021

2023-11-07 Thread Francis Laniel
Enables variables expansion for hush 2021, both for local and environment
variables.
So the following commands:
foo=bar
echo $foo
setenv bar foo
echo $bar
leads to "bar" and "foo" being printed on console output.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 common/cli_hush_2021.c | 17 +++
 common/cli_hush_upstream.c | 91 +++---
 2 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/common/cli_hush_2021.c b/common/cli_hush_2021.c
index 653ea52929..7dd30ea0ef 100644
--- a/common/cli_hush_2021.c
+++ b/common/cli_hush_2021.c
@@ -207,6 +207,23 @@ static const char* endofname(const char *name)
return name;
 }
 
+/**
+ * list_size() - returns the number of elements in char ** before NULL.
+ *
+ * Argument must contain NULL to signalize its end.
+ *
+ * @list The list to count the number of element.
+ * @return The number of element in list.
+ */
+static size_t list_size(char **list)
+{
+   size_t size;
+
+   for (size = 0; list[size] != NULL; size++);
+
+   return size;
+}
+
 struct in_str;
 static int u_boot_cli_readline(struct in_str *i);
 
diff --git a/common/cli_hush_upstream.c b/common/cli_hush_upstream.c
index 84227a248e..b806c5c653 100644
--- a/common/cli_hush_upstream.c
+++ b/common/cli_hush_upstream.c
@@ -3486,7 +3486,6 @@ static int o_get_last_ptr(o_string *o, int n)
return ((int)(uintptr_t)list[n-1]) + string_start;
 }
 
-#ifndef __U_BOOT__
 /*
  * Globbing routines.
  *
@@ -3741,8 +3740,10 @@ static int glob_needed(const char *s)
  */
 static int perform_glob(o_string *o, int n)
 {
+#ifndef __U_BOOT__
glob_t globdata;
int gr;
+#endif /* __U_BOOT__ */
char *pattern;
 
debug_printf_glob("start perform_glob: n:%d o->data:%p\n", n, o->data);
@@ -3751,13 +3752,16 @@ static int perform_glob(o_string *o, int n)
pattern = o->data + o_get_last_ptr(o, n);
debug_printf_glob("glob pattern '%s'\n", pattern);
if (!glob_needed(pattern)) {
+#ifndef __U_BOOT__
  literal:
+#endif /* __U_BOOT__ */
/* unbackslash last string in o in place, fix length */
o->length = unbackslash(pattern) - o->data;
debug_printf_glob("glob pattern '%s' is literal\n", pattern);
return o_save_ptr_helper(o, n);
}
 
+#ifndef __U_BOOT__
memset(, 0, sizeof(globdata));
/* Can't use GLOB_NOCHECK: it does not unescape the string.
 * If we glob "*.\*" and don't find anything, we need
@@ -3793,16 +3797,22 @@ static int perform_glob(o_string *o, int n)
if (DEBUG_GLOB)
debug_print_list("perform_glob returning", o, n);
return n;
+#else /* __U_BOOT__ */
+   /*
+* NOTE We only use perform glob to call unbackslash to remove backslash
+* from string once expanded.
+* So, it seems OK to return this if no previous return was done.
+*/
+   return o_save_ptr_helper(o, n);
+#endif /* __U_BOOT__ */
 }
 
-#endif /* !__U_BOOT__ */
 #endif /* !HUSH_BRACE_EXPANSION */
 
 /* If o->o_expflags & EXP_FLAG_GLOB, glob the string so far remembered.
  * Otherwise, just finish current list[] and start new */
 static int o_save_ptr(o_string *o, int n)
 {
-#ifndef __U_BOOT__
if (o->o_expflags & EXP_FLAG_GLOB) {
/* If o->has_empty_slot, list[n] was already globbed
 * (if it was requested back then when it was filled)
@@ -3810,7 +3820,6 @@ static int o_save_ptr(o_string *o, int n)
if (!o->has_empty_slot)
return perform_glob(o, n); /* o_save_ptr_helper is 
inside */
}
-#endif /* !__U_BOOT__ */
return o_save_ptr_helper(o, n);
 }
 
@@ -5456,7 +5465,20 @@ static int parse_dollar(o_string *as_string,
nommu_addchr(as_string, ch);
if (ch == '}')
break;
+#ifndef __U_BOOT__
if (!isalnum(ch) && ch != '_') {
+#else /* __U_BOOT__ */
+   /*
+* In several places in U-Boot, we use variable like
+* foo# (e.g. serial#), particularly in env.
+* So, we need to authorize # to appear inside
+* variable name and then expand this variable.
+* NOTE Having # in variable name is not permitted in
+* upstream hush but expansion will be done (even though
+* the result will be empty).
+*/
+   if (!isalnum(ch) && ch != '_' && ch != '#') {
+#endif /* __U_BOOT__ */
unsigned end_ch;
 #ifndef __U_BOOT__
unsigned char last_ch;
@@ -7031,7 +7053,20 @@ static NOINLINE int expand_one_var(o_string *output, int 
n,
}
 #endif /* !__U_BOOT__ */
default:
+#ifndef __U_BOOT__
  

[PATCH v11 11/24] cmd: Add new cli command

2023-11-07 Thread Francis Laniel
This command can be used to print the current parser with 'cli get'.
It can also be used to set the current parser with 'cli set'.
For the moment, only one value is valid for set: old.

Signed-off-by: Francis Laniel 
---
 cmd/Makefile  |   2 +
 cmd/cli.c | 114 ++
 common/cli.c  |   3 +-
 doc/usage/cmd/cli.rst |  59 ++
 doc/usage/index.rst   |   1 +
 5 files changed, 178 insertions(+), 1 deletion(-)
 create mode 100644 cmd/cli.c
 create mode 100644 doc/usage/cmd/cli.rst

diff --git a/cmd/Makefile b/cmd/Makefile
index 9a6790cc17..620f69c1c5 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -227,6 +227,8 @@ obj-$(CONFIG_CMD_AVB) += avb.o
 # Foundries.IO SCP03
 obj-$(CONFIG_CMD_SCP03) += scp03.o
 
+obj-$(CONFIG_HUSH_PARSER) += cli.o
+
 obj-$(CONFIG_ARM) += arm/
 obj-$(CONFIG_RISCV) += riscv/
 obj-$(CONFIG_SANDBOX) += sandbox/
diff --git a/cmd/cli.c b/cmd/cli.c
new file mode 100644
index 00..86c6471aa4
--- /dev/null
+++ b/cmd/cli.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const char *gd_flags_to_parser_name(void)
+{
+   if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
+   return "old";
+   return NULL;
+}
+
+static int do_cli_get(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+   const char *current = gd_flags_to_parser_name();
+
+   if (!current) {
+   printf("current cli value is not valid, this should not 
happen!\n");
+   return CMD_RET_FAILURE;
+   }
+
+   printf("%s\n", current);
+
+   return CMD_RET_SUCCESS;
+}
+
+static int parser_string_to_gd_flags(const char *parser)
+{
+   if (!strcmp(parser, "old"))
+   return GD_FLG_HUSH_OLD_PARSER;
+   return -1;
+}
+
+static void reset_parser_gd_flags(void)
+{
+   gd->flags &= ~GD_FLG_HUSH_OLD_PARSER;
+}
+
+static int do_cli_set(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   char *parser_name;
+   int parser_flag;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   parser_name = argv[1];
+
+   parser_flag = parser_string_to_gd_flags(parser_name);
+   if (parser_flag == -1) {
+   printf("Bad value for parser name: %s\n", parser_name);
+   return CMD_RET_USAGE;
+   }
+
+   if (parser_flag == GD_FLG_HUSH_OLD_PARSER &&
+   !CONFIG_IS_ENABLED(HUSH_OLD_PARSER)) {
+   printf("Want to set current parser to old, but its code was not 
compiled!\n");
+   return CMD_RET_FAILURE;
+   }
+
+   reset_parser_gd_flags();
+   gd->flags |= parser_flag;
+
+   cli_init();
+   cli_loop();
+
+   /* cli_loop() should never return. */
+   return CMD_RET_FAILURE;
+}
+
+static struct cmd_tbl parser_sub[] = {
+   U_BOOT_CMD_MKENT(get, 1, 1, do_cli_get, "", ""),
+   U_BOOT_CMD_MKENT(set, 2, 1, do_cli_set, "", ""),
+};
+
+static int do_cli(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   struct cmd_tbl *cp;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   /* drop initial "parser" arg */
+   argc--;
+   argv++;
+
+   cp = find_cmd_tbl(argv[0], parser_sub, ARRAY_SIZE(parser_sub));
+   if (cp)
+   return cp->cmd(cmdtp, flag, argc, argv);
+
+   return CMD_RET_USAGE;
+}
+
+#if CONFIG_IS_ENABLED(SYS_LONGHELP)
+static char cli_help_text[] =
+   "get - print current cli\n"
+   "set - set the current cli, possible value is: old"
+   ;
+#endif
+
+U_BOOT_CMD(cli, 3, 1, do_cli,
+  "cli",
+#if CONFIG_IS_ENABLED(SYS_LONGHELP)
+  cli_help_text
+#endif
+);
diff --git a/common/cli.c b/common/cli.c
index e5fe1060d0..d419671e8c 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -268,7 +268,8 @@ void cli_loop(void)
 void cli_init(void)
 {
 #ifdef CONFIG_HUSH_PARSER
-   if (!(gd->flags & GD_FLG_HUSH_OLD_PARSER))
+   if (!(gd->flags & GD_FLG_HUSH_OLD_PARSER)
+   && CONFIG_IS_ENABLED(HUSH_OLD_PARSER))
gd->flags |= GD_FLG_HUSH_OLD_PARSER;
u_boot_hush_start();
 #endif
diff --git a/doc/usage/cmd/cli.rst b/doc/usage/cmd/cli.rst
new file mode 100644
index 00..89ece3203d
--- /dev/null
+++ b/doc/usage/cmd/cli.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+cli command
+===
+
+Synopis
+---
+
+::
+
+cli get
+cli set cli_flavor
+
+Description
+---
+
+The cli command permits getting and changing the current parser at runtime.
+
+cli get
+~~~
+
+It shows the current value of the parser used by the CLI.
+
+cli set
+~~~
+
+It permits setting the value of the parser used by the CLI.
+
+Possible values are old and 2021.
+Note that, to use a specific parser its code should have been compiled, that
+is to say 

[PATCH v11 10/24] global_data.h: add GD_FLG_HUSH_OLD_PARSER flag

2023-11-07 Thread Francis Laniel
This flag is used to indicate we are using the hush parser.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 common/cli.c  | 2 ++
 include/asm-generic/global_data.h | 4 
 2 files changed, 6 insertions(+)

diff --git a/common/cli.c b/common/cli.c
index 3916a7b10a..e5fe1060d0 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -268,6 +268,8 @@ void cli_loop(void)
 void cli_init(void)
 {
 #ifdef CONFIG_HUSH_PARSER
+   if (!(gd->flags & GD_FLG_HUSH_OLD_PARSER))
+   gd->flags |= GD_FLG_HUSH_OLD_PARSER;
u_boot_hush_start();
 #endif
 
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index e8c6412e3f..0a9b6bd92a 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -697,6 +697,10 @@ enum gd_flags {
 * @GD_FLG_BLOBLIST_READY: bloblist is ready for use
 */
GD_FLG_BLOBLIST_READY = 0x80,
+   /**
+* @GD_FLG_HUSH_OLD_PARSER: Use hush old parser.
+*/
+   GD_FLG_HUSH_OLD_PARSER = 0x100,
 };
 
 #endif /* __ASSEMBLY__ */
-- 
2.34.1



[PATCH v11 08/24] cli: Port Busybox 2021 hush to U-Boot

2023-11-07 Thread Francis Laniel
Adds new file cli_hush_2021.c, it is a copy of Busybox hush file as it was of
time to commit 37460f5da.
This commit modifies Busybox hush to not compile some part specific to Busybox
and adds some code needed by U-Boot.
The modifications consists mainly on adding code #if(n)def guards.

For the moment, this refurbished flavor of hush only permits running command
without any keywords (i.e., if and for are not recognized) or variable expansion
(i.e., echo $foo prints foo and not value stored in variable foo).

A new file was also added to define some functions specific to U-Boot.

Signed-off-by: Francis Laniel 
Signed-off-by: Harald Seiler 
---
 common/cli_hush_2021.c | 274 
 common/cli_hush_upstream.c | 501 -
 2 files changed, 774 insertions(+), 1 deletion(-)
 create mode 100644 common/cli_hush_2021.c

diff --git a/common/cli_hush_2021.c b/common/cli_hush_2021.c
new file mode 100644
index 00..6d109933b8
--- /dev/null
+++ b/common/cli_hush_2021.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file defines the compilation unit for the new hush shell version.  The
+ * actual implementation from upstream BusyBox can be found in
+ * `cli_hush_2021_upstream.c` which is included at the end of this file.
+ *
+ * This "wrapper" technique is used to keep the changes to the upstream version
+ * as minmal as possible.  Instead, all defines and redefines necessary are 
done
+ * here, outside the upstream sources.  This will hopefully make upgrades to
+ * newer revisions much easier.
+ *
+ * Copyright (c) 2021, Harald Seiler, DENX Software Engineering, h...@denx.de
+ */
+
+#include  /* readline */
+#include 
+#include  /* malloc, free, realloc*/
+#include /* isalpha, isdigit */
+#include 
+#include 
+#include 
+#include 
+#include /* find_cmd */
+#include 
+
+/*
+ * BusyBox Version: UPDATE THIS WHEN PULLING NEW UPSTREAM REVISION!
+ */
+#define BB_VER "1.34.0.git37460f5daff9"
+
+/*
+ * Define hush features by the names used upstream.
+ */
+#define ENABLE_HUSH_INTERACTIVE1
+#define ENABLE_FEATURE_EDITING 1
+/* No MMU in U-Boot */
+#define BB_MMU 0
+#define USE_FOR_NOMMU(...) __VA_ARGS__
+#define USE_FOR_MMU(...)
+
+/*
+ * Size-saving "small" ints (arch-dependent)
+ */
+#if CONFIG_IS_ENABLED(X86) || CONFIG_IS_ENABLED(X86_64) || 
CONFIG_IS_ENABLED(MIPS)
+/* add other arches which benefit from this... */
+typedef signed char smallint;
+typedef unsigned char smalluint;
+#else
+/* for arches where byte accesses generate larger code: */
+typedef int smallint;
+typedef unsigned smalluint;
+#endif
+
+/*
+ * Alignment defines used by BusyBox.
+ */
+#define ALIGN1 __attribute__((aligned(1)))
+#define ALIGN2 __attribute__((aligned(2)))
+#define ALIGN4 __attribute__((aligned(4)))
+#define ALIGN8 __attribute__((aligned(8)))
+#define ALIGN_PTR  __attribute__((aligned(sizeof(void*
+
+/*
+ * Miscellaneous compiler/platform defines.
+ */
+#define FAST_FUNC /* not used in U-Boot */
+#define UNUSED_PARAM   __always_unused
+#define ALWAYS_INLINE  __always_inline
+#define NOINLINE   noinline
+
+/*
+ * Defines to provide equivalents to what libc/BusyBox defines.
+ */
+#define EOF(-1)
+#define EXIT_SUCCESS   0
+#define EXIT_FAILURE   1
+
+/*
+ * Stubs to provide libc/BusyBox functions based on U-Boot equivalents where it
+ * makes sense.
+ */
+#define utoa   simple_itoa
+
+static void __noreturn xfunc_die(void)
+{
+   panic("HUSH died!");
+}
+
+#define bb_error_msg_and_die(format, ...) do { \
+panic("HUSH: " format, __VA_ARGS__); \
+} while (0);
+
+#define bb_simple_error_msg_and_die(msg) do { \
+panic_str("HUSH: " msg); \
+} while (0);
+
+/* fdprintf() is used for debug output. */
+static int __maybe_unused fdprintf(int fd, const char *format, ...)
+{
+   va_list args;
+   uint i;
+
+   assert(fd == 2);
+
+   va_start(args, format);
+   i = vprintf(format, args);
+   va_end(args);
+
+   return i;
+}
+
+static void bb_verror_msg(const char *s, va_list p, const char* strerr)
+{
+   /* TODO: what to do with strerr arg? */
+   vprintf(s, p);
+}
+
+static void bb_error_msg(const char *s, ...)
+{
+   va_list p;
+
+   va_start(p, s);
+   bb_verror_msg(s, p, NULL);
+   va_end(p);
+}
+
+static void *xmalloc(size_t size)
+{
+   void *p = NULL;
+   if (!(p = malloc(size)))
+   panic("out of memory");
+   return p;
+}
+
+static void *xzalloc(size_t size)
+{
+   void *p = xmalloc(size);
+   memset(p, 0, size);
+   return p;
+}
+
+static void *xrealloc(void *ptr, size_t size)
+{
+   void *p = NULL;
+   if (!(p = realloc(ptr, size)))
+   panic("out of memory");
+   return p;
+}
+
+#define xstrdupstrdup
+#define 

[PATCH v11 09/24] cli: Add menu for hush parser

2023-11-07 Thread Francis Laniel
For the moment, the menu contains only entry: HUSH_OLD_PARSER which is the
default.
The goal is to prepare the field to add a new hush parser which guarantees
actual behavior is still correct.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 cmd/Kconfig | 13 +
 common/Makefile |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index fd16c3a48e..f3a00ee59b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -23,6 +23,19 @@ config HUSH_PARSER
  If disabled, you get the old, much simpler behaviour with a somewhat
  smaller memory footprint.
 
+menu "Hush flavor to use"
+   depends on HUSH_PARSER
+
+   config HUSH_OLD_PARSER
+   bool "Use hush old parser"
+   default y
+   help
+ This option enables the old flavor of hush based on hush 
Busybox from
+ 2005.
+
+ It is actually the default U-Boot shell when decided to use 
hush as shell.
+endmenu
+
 config CMDLINE_EDITING
bool "Enable command line editing"
depends on CMDLINE
diff --git a/common/Makefile b/common/Makefile
index cdeadf7202..23851a68e2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -8,7 +8,7 @@ ifndef CONFIG_SPL_BUILD
 obj-y += init/
 obj-y += main.o
 obj-y += exports.o
-obj-$(CONFIG_HUSH_PARSER) += cli_hush.o
+obj-$(CONFIG_HUSH_OLD_PARSER) += cli_hush.o
 obj-$(CONFIG_AUTOBOOT) += autoboot.o
 
 # # boards
-- 
2.34.1



[PATCH v11 05/24] test: hush: Test hush commands list

2023-11-07 Thread Francis Laniel
Verifies behavior of commands separated by ';', '&&' and '||'.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 test/hush/Makefile |  1 +
 test/hush/list.c   | 79 ++
 2 files changed, 80 insertions(+)
 create mode 100644 test/hush/list.c

diff --git a/test/hush/Makefile b/test/hush/Makefile
index feb4f71956..ff4fe7700b 100644
--- a/test/hush/Makefile
+++ b/test/hush/Makefile
@@ -6,3 +6,4 @@
 obj-y += cmd_ut_hush.o
 obj-y += if.o
 obj-y += dollar.o
+obj-y += list.o
diff --git a/test/hush/list.c b/test/hush/list.c
new file mode 100644
index 00..052cf2783c
--- /dev/null
+++ b/test/hush/list.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int hush_test_semicolon(struct unit_test_state *uts)
+{
+   /* A; B = B truth table. */
+   ut_asserteq(1, run_command("false; false", 0));
+   ut_assertok(run_command("false; true", 0));
+   ut_assertok(run_command("true; true", 0));
+   ut_asserteq(1, run_command("true; false", 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_semicolon, 0);
+
+static int hush_test_and(struct unit_test_state *uts)
+{
+   /* A && B truth table. */
+   ut_asserteq(1, run_command("false && false", 0));
+   ut_asserteq(1, run_command("false && true", 0));
+   ut_assertok(run_command("true && true", 0));
+   ut_asserteq(1, run_command("true && false", 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_and, 0);
+
+static int hush_test_or(struct unit_test_state *uts)
+{
+   /* A || B truth table. */
+   ut_asserteq(1, run_command("false || false", 0));
+   ut_assertok(run_command("false || true", 0));
+   ut_assertok(run_command("true || true", 0));
+   ut_assertok(run_command("true || false", 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_or, 0);
+
+static int hush_test_and_or(struct unit_test_state *uts)
+{
+   /* A && B || C truth table. */
+   ut_asserteq(1, run_command("false && false || false", 0));
+   ut_asserteq(1, run_command("false && false || true", 0));
+   ut_asserteq(1, run_command("false && true || true", 0));
+   ut_asserteq(1, run_command("false && true || false", 0));
+   ut_assertok(run_command("true && true || false", 0));
+   ut_asserteq(1, run_command("true && false || false", 0));
+   ut_assertok(run_command("true && false || true", 0));
+   ut_assertok(run_command("true && true || true", 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_and_or, 0);
+
+static int hush_test_or_and(struct unit_test_state *uts)
+{
+   /* A || B && C truth table. */
+   ut_asserteq(1, run_command("false || false && false", 0));
+   ut_asserteq(1, run_command("false || false && true", 0));
+   ut_assertok(run_command("false || true && true", 0));
+   ut_asserteq(1, run_command("false || true && false", 0));
+   ut_assertok(run_command("true || true && false", 0));
+   ut_assertok(run_command("true || false && false", 0));
+   ut_assertok(run_command("true || false && true", 0));
+   ut_assertok(run_command("true || true && true", 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_or_and, 0);
-- 
2.34.1



[PATCH v11 06/24] test: hush: Test hush loops

2023-11-07 Thread Francis Laniel
The added tests verifies correct behavior of for, while and until loops.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 test/hush/Makefile |  1 +
 test/hush/loop.c   | 65 ++
 2 files changed, 66 insertions(+)
 create mode 100644 test/hush/loop.c

diff --git a/test/hush/Makefile b/test/hush/Makefile
index ff4fe7700b..a2d98815e5 100644
--- a/test/hush/Makefile
+++ b/test/hush/Makefile
@@ -7,3 +7,4 @@ obj-y += cmd_ut_hush.o
 obj-y += if.o
 obj-y += dollar.o
 obj-y += list.o
+obj-y += loop.o
diff --git a/test/hush/loop.c b/test/hush/loop.c
new file mode 100644
index 00..ca777e38fe
--- /dev/null
+++ b/test/hush/loop.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int hush_test_for(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+
+   ut_assertok(run_command("for loop_i in foo bar quux quux; do echo 
$loop_i; done", 0));
+   ut_assert_nextline("foo");
+   ut_assert_nextline("bar");
+   ut_assert_nextline("quux");
+   ut_assert_nextline("quux");
+   ut_assert_console_end();
+
+   puts("Beware: this test set local variable loop_i and it cannot be 
unset!");
+
+   return 0;
+}
+HUSH_TEST(hush_test_for, 0);
+
+static int hush_test_while(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+
+   /* Exit status is that of test, so 1 since test is false to quit the 
loop. */
+   ut_asserteq(1, run_command("while test -z \"$loop_foo\"; do echo bar; 
loop_foo=quux; done", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   puts("Beware: this test set local variable loop_foo and it cannot be 
unset!");
+
+   return 0;
+}
+HUSH_TEST(hush_test_while, 0);
+
+static int hush_test_until(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+   env_set("loop_bar", "bar");
+
+   /*
+* WARNING We have to use environment variable because it is not 
possible
+* resetting local variable.
+*/
+   ut_assertok(run_command("until test -z \"$loop_bar\"; do echo quux; 
setenv loop_bar; done", 0));
+   ut_assert_nextline("quux");
+   ut_assert_console_end();
+
+   /*
+* Loop normally resets foo environment variable, but we reset it here 
in
+* case the test failed.
+*/
+   env_set("loop_bar", NULL);
+   return 0;
+}
+HUSH_TEST(hush_test_until, 0);
-- 
2.34.1



[PATCH v11 04/24] test: hush: Test hush variable expansion

2023-11-07 Thread Francis Laniel
Verifies shell variables are replaced by their values.

Reviewed-by: Simon Glass 
Signed-off-by: Francis Laniel 
---
 test/hush/Makefile   |   1 +
 test/hush/dollar.c   | 167 +++
 test/py/tests/test_ut.py |   8 +-
 3 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 test/hush/dollar.c

diff --git a/test/hush/Makefile b/test/hush/Makefile
index a3c9ae5106..feb4f71956 100644
--- a/test/hush/Makefile
+++ b/test/hush/Makefile
@@ -5,3 +5,4 @@
 
 obj-y += cmd_ut_hush.o
 obj-y += if.o
+obj-y += dollar.o
diff --git a/test/hush/dollar.c b/test/hush/dollar.c
new file mode 100644
index 00..defb2c3fd0
--- /dev/null
+++ b/test/hush/dollar.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int hush_test_simple_dollar(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline_empty();
+   ut_assert_console_end();
+
+   ut_assertok(run_command("echo ${dollar_foo}", 0));
+   ut_assert_nextline_empty();
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_foo=bar", 0));
+
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("echo ${dollar_foo}", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_foo=\\$bar", 0));
+
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline("$bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_foo='$bar'", 0));
+
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline("$bar");
+   ut_assert_console_end();
+
+   ut_asserteq(1, run_command("dollar_foo=bar quux", 0));
+   /* Next line contains error message */
+   ut_assert_skipline();
+   ut_assert_console_end();
+
+   ut_asserteq(1, run_command("dollar_foo='bar quux", 0));
+   /* Next line contains error message */
+   ut_assert_skipline();
+   ut_assert_console_end();
+
+   ut_asserteq(1, run_command("dollar_foo=bar quux\"", 0));
+   /* Two next lines contain error message */
+   ut_assert_skipline();
+   ut_assert_skipline();
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_foo='bar \"quux'", 0));
+
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   /*
+* This one is buggy.
+* ut_assert_nextline("bar \"quux");
+* ut_assert_console_end();
+*
+* So, let's reset output:
+*/
+   console_record_reset_enable();
+
+   ut_asserteq(1, run_command("dollar_foo=\"bar 'quux\"", 0));
+   /* Next line contains error message */
+   ut_assert_skipline();
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_foo='bar quux'", 0));
+   ut_assertok(run_command("echo $dollar_foo", 0));
+   ut_assert_nextline("bar quux");
+   ut_assert_console_end();
+
+   puts("Beware: this test set local variable dollar_foo and it cannot be 
unset!");
+
+   return 0;
+}
+HUSH_TEST(hush_test_simple_dollar, 0);
+
+static int hush_test_env_dollar(struct unit_test_state *uts)
+{
+   env_set("env_foo", "bar");
+   console_record_reset_enable();
+
+   ut_assertok(run_command("echo $env_foo", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("echo ${env_foo}", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   /* Environment variables have priority over local variable */
+   ut_assertok(run_command("env_foo=quux", 0));
+   ut_assertok(run_command("echo ${env_foo}", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   /* Clean up setting the variable */
+   env_set("env_foo", NULL);
+
+   puts("Beware: this test set local variable env_foo and it cannot be 
unset!");
+
+   return 0;
+}
+HUSH_TEST(hush_test_env_dollar, 0);
+
+static int hush_test_command_dollar(struct unit_test_state *uts)
+{
+   console_record_reset_enable();
+
+   ut_assertok(run_command("dollar_bar=\"echo bar\"", 0));
+
+   ut_assertok(run_command("$dollar_bar", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("${dollar_bar}", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_bar=\"echo\nbar\"", 0));
+
+   ut_assertok(run_command("$dollar_bar", 0));
+   ut_assert_nextline("bar");
+   ut_assert_console_end();
+
+   ut_assertok(run_command("dollar_bar='echo bar\n'", 0));
+
+   

[PATCH v11 03/24] test/py: hush_if_test: Remove the test file

2023-11-07 Thread Francis Laniel
5804ebfeb1ce ("test: hush: Test hush if/else") translated this test to a C test,
so this python file is no more needed.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 test/py/tests/test_hush_if_test.py | 197 -
 1 file changed, 197 deletions(-)
 delete mode 100644 test/py/tests/test_hush_if_test.py

diff --git a/test/py/tests/test_hush_if_test.py 
b/test/py/tests/test_hush_if_test.py
deleted file mode 100644
index 3b4b6fcaf4..00
--- a/test/py/tests/test_hush_if_test.py
+++ /dev/null
@@ -1,197 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-# Copyright (c) 2015-2016, NVIDIA CORPORATION. All rights reserved.
-
-# Test operation of the "if" shell command.
-
-import os
-import os.path
-import pytest
-
-# TODO: These tests should be converted to a C test.
-# For more information please take a look at the thread
-# https://lists.denx.de/pipermail/u-boot/2019-October/388732.html
-
-pytestmark = pytest.mark.buildconfigspec('hush_parser')
-
-# The list of "if test" conditions to test.
-subtests = (
-# Base if functionality.
-
-('true', True),
-('false', False),
-
-# Basic operators.
-
-('test aaa = aaa', True),
-('test aaa = bbb', False),
-
-('test aaa != bbb', True),
-('test aaa != aaa', False),
-
-('test aaa < bbb', True),
-('test bbb < aaa', False),
-
-('test bbb > aaa', True),
-('test aaa > bbb', False),
-
-('test 123 -eq 123', True),
-('test 123 -eq 456', False),
-
-('test 123 -ne 456', True),
-('test 123 -ne 123', False),
-
-('test 123 -lt 456', True),
-('test 123 -lt 123', False),
-('test 456 -lt 123', False),
-
-('test 123 -le 456', True),
-('test 123 -le 123', True),
-('test 456 -le 123', False),
-
-('test 456 -gt 123', True),
-('test 123 -gt 123', False),
-('test 123 -gt 456', False),
-
-('test 456 -ge 123', True),
-('test 123 -ge 123', True),
-('test 123 -ge 456', False),
-
-# Octal tests
-
-('test 010 -eq 010', True),
-('test 010 -eq 011', False),
-
-('test 010 -ne 011', True),
-('test 010 -ne 010', False),
-
-# Hexadecimal tests
-
-('test 0x200 -gt 0x201', False),
-('test 0x200 -gt 0x200', False),
-('test 0x200 -gt 0x1ff', True),
-
-# Mixed tests
-
-('test 010 -eq 10', False),
-('test 010 -ne 10', True),
-('test 0xa -eq 10', True),
-('test 0xa -eq 012', True),
-
-('test 200 -gt 0x1ff', False),
-('test 0x200 -gt 1ff', True),
-('test 0x200 -lt 1ff', False),
-('test 0x200 -eq 200', False),
-('test 0x200 -ne 200', True),
-
-('test -z ""', True),
-('test -z "aaa"', False),
-
-('test -n "aaa"', True),
-('test -n ""', False),
-
-# Inversion of simple tests.
-
-('test ! aaa = aaa', False),
-('test ! aaa = bbb', True),
-('test ! ! aaa = aaa', True),
-('test ! ! aaa = bbb', False),
-
-# Binary operators.
-
-('test aaa != aaa -o bbb != bbb', False),
-('test aaa != aaa -o bbb = bbb', True),
-('test aaa = aaa -o bbb != bbb', True),
-('test aaa = aaa -o bbb = bbb', True),
-
-('test aaa != aaa -a bbb != bbb', False),
-('test aaa != aaa -a bbb = bbb', False),
-('test aaa = aaa -a bbb != bbb', False),
-('test aaa = aaa -a bbb = bbb', True),
-
-# Inversion within binary operators.
-
-('test ! aaa != aaa -o ! bbb != bbb', True),
-('test ! aaa != aaa -o ! bbb = bbb', True),
-('test ! aaa = aaa -o ! bbb != bbb', True),
-('test ! aaa = aaa -o ! bbb = bbb', False),
-
-('test ! ! aaa != aaa -o ! ! bbb != bbb', False),
-('test ! ! aaa != aaa -o ! ! bbb = bbb', True),
-('test ! ! aaa = aaa -o ! ! bbb != bbb', True),
-('test ! ! aaa = aaa -o ! ! bbb = bbb', True),
-)
-
-def exec_hush_if(u_boot_console, expr, result):
-"""Execute a shell "if" command, and validate its result."""
-
-config = u_boot_console.config.buildconfig
-maxargs = int(config.get('config_sys_maxargs', '0'))
-args = len(expr.split(' ')) - 1
-if args > maxargs:
-u_boot_console.log.warning('CONFIG_SYS_MAXARGS too low; need ' +
-str(args))
-pytest.skip()
-
-cmd = 'if ' + expr + '; then echo true; else echo false; fi'
-response = u_boot_console.run_command(cmd)
-assert response.strip() == str(result).lower()
-
-@pytest.mark.buildconfigspec('cmd_echo')
-@pytest.mark.parametrize('expr,result', subtests)
-def test_hush_if_test(u_boot_console, expr, result):
-"""Test a single "if test" condition."""
-
-exec_hush_if(u_boot_console, expr, result)
-
-def test_hush_z(u_boot_console):
-"""Test the -z operator"""
-u_boot_console.run_command('setenv ut_var_nonexistent')
-u_boot_console.run_command('setenv ut_var_exists 1')
-exec_hush_if(u_boot_console, 'test -z "$ut_var_nonexistent"', True)
-exec_hush_if(u_boot_console, 'test -z "$ut_var_exists"', False)
-

[PATCH v11 01/24] test: Add framework to test hush behavior

2023-11-07 Thread Francis Laniel
Introduce a new subcommand to ut: ut hush.
For the moment, this command does nothing, future commits will add tests which
will be run on command call.

Note that CONFIG_HUSH_PARSER must be defined to compile this new subcommand.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 include/test/hush.h | 15 +++
 include/test/suites.h   |  1 +
 test/Makefile   |  3 +++
 test/cmd_ut.c   |  6 ++
 test/hush/Makefile  |  6 ++
 test/hush/cmd_ut_hush.c | 20 
 6 files changed, 51 insertions(+)
 create mode 100644 include/test/hush.h
 create mode 100644 test/hush/Makefile
 create mode 100644 test/hush/cmd_ut_hush.c

diff --git a/include/test/hush.h b/include/test/hush.h
new file mode 100644
index 00..cca66544a0
--- /dev/null
+++ b/include/test/hush.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#ifndef __TEST_HUSH_H__
+#define __TEST_HUSH_H__
+
+#include 
+
+/* Declare a new environment test */
+#define HUSH_TEST(_name, _flags)   UNIT_TEST(_name, _flags, hush_test)
+
+#endif /* __TEST_HUSH_H__ */
diff --git a/include/test/suites.h b/include/test/suites.h
index ad4fc926f4..fc0f9334c0 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -42,6 +42,7 @@ int do_ut_env(struct cmd_tbl *cmdtp, int flag, int argc, char 
*const argv[]);
 int do_ut_exit(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_fdt(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
+int do_ut_hush(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
diff --git a/test/Makefile b/test/Makefile
index 8e1fed2c28..10cf6a7976 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -17,6 +17,9 @@ obj-$(CONFIG_FUZZ) += fuzz/
 ifndef CONFIG_SANDBOX_VPL
 obj-$(CONFIG_UNIT_TEST) += lib/
 endif
+ifneq ($(CONFIG_HUSH_PARSER),)
+obj-$(CONFIG_$(SPL_)CMDLINE) += hush/
+endif
 obj-$(CONFIG_$(SPL_)CMDLINE) += print_ut.o
 obj-$(CONFIG_$(SPL_)CMDLINE) += str_ut.o
 obj-$(CONFIG_UT_TIME) += time_ut.o
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 2d5b80f992..2f96dfa934 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -118,6 +118,9 @@ static struct cmd_tbl cmd_ut_sub[] = {
 #ifdef CONFIG_CMD_ADDRMAP
U_BOOT_CMD_MKENT(addrmap, CONFIG_SYS_MAXARGS, 1, do_ut_addrmap, "", ""),
 #endif
+#if CONFIG_IS_ENABLED(HUSH_PARSER)
+   U_BOOT_CMD_MKENT(hush, CONFIG_SYS_MAXARGS, 1, do_ut_hush, "", ""),
+#endif
 #ifdef CONFIG_CMD_LOADM
U_BOOT_CMD_MKENT(loadm, CONFIG_SYS_MAXARGS, 1, do_ut_loadm, "", ""),
 #endif
@@ -210,6 +213,9 @@ U_BOOT_LONGHELP(ut,
 #ifdef CONFIG_CONSOLE_TRUETYPE
"\nfont - font command"
 #endif
+#if CONFIG_IS_ENABLED(HUSH_PARSER)
+   "\nhush - Test hush behavior"
+#endif
 #ifdef CONFIG_CMD_LOADM
"\nloadm - loadm command parameters and loading memory blob"
 #endif
diff --git a/test/hush/Makefile b/test/hush/Makefile
new file mode 100644
index 00..dfa2a92615
--- /dev/null
+++ b/test/hush/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2021
+# Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+
+obj-y += cmd_ut_hush.o
diff --git a/test/hush/cmd_ut_hush.c b/test/hush/cmd_ut_hush.c
new file mode 100644
index 00..48a1adbf28
--- /dev/null
+++ b/test/hush/cmd_ut_hush.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int do_ut_hush(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+   struct unit_test *tests = UNIT_TEST_SUITE_START(hush_test);
+   const int n_ents = UNIT_TEST_SUITE_COUNT(hush_test);
+
+   return cmd_ut_category("hush", "hush_test_",
+  tests, n_ents, argc, argv);
+}
-- 
2.34.1



[PATCH v11 02/24] test: hush: Test hush if/else

2023-11-07 Thread Francis Laniel
As asked in commit 9c6bf1715f6a ("test/py: hush_if_test: Add tests to cover
octal/hex values"), this commit translates test_hush_if_test.py to a C test.

Signed-off-by: Francis Laniel 
Reviewed-by: Simon Glass 
---
 test/hush/Makefile |   1 +
 test/hush/if.c | 316 +
 2 files changed, 317 insertions(+)
 create mode 100644 test/hush/if.c

diff --git a/test/hush/Makefile b/test/hush/Makefile
index dfa2a92615..a3c9ae5106 100644
--- a/test/hush/Makefile
+++ b/test/hush/Makefile
@@ -4,3 +4,4 @@
 # Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
 
 obj-y += cmd_ut_hush.o
+obj-y += if.o
diff --git a/test/hush/if.c b/test/hush/if.c
new file mode 100644
index 00..b7200e32ec
--- /dev/null
+++ b/test/hush/if.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021
+ * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * All tests will execute the following:
+ * if condition_to_test; then
+ *   true
+ * else
+ *   false
+ * fi
+ * If condition is true, command returns 1, 0 otherwise.
+ */
+const char *if_format = "if %s; then true; else false; fi";
+
+static int hush_test_if_base(struct unit_test_state *uts)
+{
+   char if_formatted[128];
+
+   sprintf(if_formatted, if_format, "true");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "false");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_if_base, 0);
+
+static int hush_test_if_basic_operators(struct unit_test_state *uts)
+{
+   char if_formatted[128];
+
+   sprintf(if_formatted, if_format, "test aaa = aaa");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test aaa = bbb");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test aaa != bbb");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test aaa != aaa");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test aaa < bbb");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test bbb < aaa");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test bbb > aaa");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test aaa > bbb");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -eq 123");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -eq 456");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -ne 456");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -ne 123");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -lt 456");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -lt 123");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 456 -lt 123");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -le 456");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -le 123");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 456 -le 123");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 456 -gt 123");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -gt 123");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -gt 456");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 456 -ge 123");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -ge 123");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 123 -ge 456");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   return 0;
+}
+HUSH_TEST(hush_test_if_basic_operators, 0);
+
+static int hush_test_if_octal(struct unit_test_state *uts)
+{
+   char if_formatted[128];
+
+   sprintf(if_formatted, if_format, "test 010 -eq 010");
+   ut_assertok(run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 010 -eq 011");
+   ut_asserteq(1, run_command(if_formatted, 0));
+
+   sprintf(if_formatted, if_format, "test 010 -ne 011");
+   

[PATCH v11 00/24] Modernize U-Boot shell

2023-11-07 Thread Francis Laniel
Hi.


During 2021 summer, Sean Anderson wrote a contribution to add a new shell, based
on LIL, to U-Boot [1, 2].
While one of the goals of this contribution was to address the fact actual
U-Boot shell, which is based on Busybox hush, is old there was a discussion
about adding a new shell versus updating the actual one [3, 4].

So, in this series, with Harald Seiler, we updated the actual U-Boot shell to
reflect what is currently in Busybox source code.
Basically, this contribution is about taking a snapshot of Busybox shell/hush.c
file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.

This contribution was written to be as backward-compatible as possible to avoid
breaking the existing.
So, the 2021 hush flavor offers the same as the actual, that is to say:
1. Variable expansion.
2. Instruction lists (;, && and ||).
3. If, then and else.
4. Loops (for, while and until).
No new features offered by Busybox hush were implemented (e.g. functions).

It is possible to change the parser at runtime using the "cli" command:
=> cli print
old
=> cli set 2021
=> cli print
2021
=> cli set old
The default parser is the old one.
Note that to use both parser, you would need to set both CONFIG_HUSH_2021_PARSER
and CONFIG_HUSH_OLD_PARSER.

In terms of testing, new unit tests were added to ut to ensure the new behavior
is the same as the old one and it does not add regression.
Nonetheless, if old behavior was buggy and fixed upstream, the fix is then added
to U-Boot [5].
In sandbox, all of these tests pass smoothly:
=> printenv board
board=sandbox
=> ut hush
Running 20 hush tests
...
Failures: 0
=> parser set 2021
=> ut hush
Running 20 hush tests
...
Failures: 0

Thanks to the effort of Harald Seiler, I was successful booting a board:
=> printenv fdtfile
fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
=> cli get
old
=> boot
...
root@lepotato:~#
root@lepotato:~# reboot
...
=> cli set 2021
=> cli get
2021
=> printenv fdtfile
fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
=> boot
...
root@lepotato:~#

I had to not use CONFIG_HUSH_2021_PARSER for the keymile board.
Indeed, the keymile board family is the only set of boards to call
get_local_var(), set_local_var() and unset_local_var().
Sadly, these functions are static in this contribution.
I could have change all of them to introduce code like this:
*_local_var(/*...*/)
{
if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
return *_local_var_old(/*...*/);
if (gd->flags & GD_FLG_HUSH_2021_PARSER)
return *_local_var_2021(/*...*/);
}
But this would have mean renaming all old hush functions calls and I did not
want to change the old hush particularly to avoid breaking things.
Instead, I change the keymile board to use environment variable instead of local
ones.
I think this particularities can be addressed in future works.

I also had to enable CONFIG_LTO for kirkwoord sheevaplug and phytec bk4r1, so
they do not hit their limits.

For all these reasons, I marked this contribution as RFC to indeed collect your
opinions.
My goal is not to change suddenly actual shell to this one, we clearly need a
transition period to think about it.
I think it is better to see this contribution as a proof of concept which shows
it is possible to update the actual shell.

If you want to review it - your review will really be appreciated - here are
some information regarding the commits:
* commits marked as "test:" deal with unit tests.
* commit "cli: Add Busybox upstream hush.c file." copies Busybox shell/hush.c
into U-Boot tree, this explain why this commit contains around 12000 additions.
* commit "cli: Port Busybox 2021 hush to U-Boot." modifies previously added file
to permit us to use this as new shell.
The really good idea of #include'ing Busybox code into a wrapper file to define
some particular functions while minimizing modifications to upstream code comes
from Harald Seiler.
* commit "cmd: Add new parser command" adds a new command which permits
selecting parser at runtime.
I am not really satisfied with the fact it calls cli_init() and cli_loop() each
time the parser is set, so your reviews would be welcomed.
* Other commits focus on enabling features we need (e.g. if).

Changes since:
 v2:
  * Added a small fix to compile sandbox with NO_SDL=1.
  * Added a command to change parser at runtime.
  * Added 2021 parser function to all run_command*().
 v3:
  * Various bug fixes pointed by the CI.
  * Added upstream busybox hush commits until 6th February 2022.
 v4:
  * Various cleaning.
  * Modified python test to accept failure output when the test are designed to
  fail.
  * Bumped upstream busybox hush commits until 24h March 2022.
 v5:
  * Bumped upstream busybox hush commits until 30th January 2023.
  * Fix how hush interprets '<' and '>', indeed we needed to escape them but I
  removed this behavior as tests are handled by test command and not hush
  itself. This permitted to have the ut fdt to pass.
  * Fix a problem with how 

Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 11:27:08AM +, Andre Przywara wrote:
> On Tue, 7 Nov 2023 01:08:15 +
> Simon Glass  wrote:
> 
> Hi Simon,
> 
> > On Mon, 6 Nov 2023 at 21:55, Andre Przywara  wrote:
> > >
> > > On Mon, 6 Nov 2023 13:38:39 -0700
> > > Simon Glass  wrote:
> > >
> > > Hi Simon,
> > >  
> > > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  
> > > > wrote:  
> > > > >
> > > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > > Simon Glass  wrote:
> > > > >
> > > > > Hi,
> > > > >  
> > > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara 
> > > > > >  wrote:  
> > > > > > >
> > > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > > Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >  
> > > > > > > > Hi Heinrich,
> > > > > > > >
> > > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > > >  wrote:  
> > > > > > > > >
> > > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:  
> > > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > > Heinrich Schuchardt  
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Heinrich,
> > > > > > > > > >  
> > > > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the 
> > > > > > > > > >> seed CSR. It
> > > > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > > > >>
> > > > > > > > > >> A RNG driver based on the seed CSR is provided. It depends 
> > > > > > > > > >> on
> > > > > > > > > >> mseccfg.sseed being set in the SBI firmware.  
> > > > > > > > > >
> > > > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > > > respective Arm
> > > > > > > > > > functionality:
> > > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > > >
> > > > > > > > > > And I see that you seem to use the same mechanism to probe 
> > > > > > > > > > and init the
> > > > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature 
> > > > > > > > > > is not
> > > > > > > > > > implemented.
> > > > > > > > > > One downside of this approach is that the driver is always 
> > > > > > > > > > loaded (and
> > > > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > > > available.
> > > > > > > > > > That doesn't seem too much of a problem on the first 
> > > > > > > > > > glance, but it
> > > > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > > > devices
> > > > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > > > without
> > > > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > > > VExpress64# rng 0
> > > > > > > > > > No RNG device  
> > > > > > > >
> > > > > > > > Why do we get this? If the device is not there, the bind() 
> > > > > > > > function
> > > > > > > > can return -ENODEV
> > > > > > > >
> > > > > > > > I see this in U-Boot:
> > > > > > > >
> > > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > > >
> > > > > > > > We should not use this.  
> > > > > > >
> > > > > > > Agreed.
> > > > > > >  
> > > > > > > > Use the devicetree.  
> > > > > > >
> > > > > > > No, this is definitely not something for the DT, at least not on 
> > > > > > > ARM.
> > > > > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > > > > Similar to PCI and USB devices, which we don't probe via the DT 
> > > > > > > as well.
> > > > > > >
> > > > > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > > > > before, but
> > > > > > > it's the simplest solution and fits in nicely otherwise.
> > > > > > >
> > > > > > > I was wondering if it might be something for UCLASS_CPU, 
> > > > > > > something like
> > > > > > > a "CPU feature bus": to let devices register on one on the many 
> > > > > > > CPU
> > > > > > > features (instead of compatible strings), then only bind() those
> > > > > > > drivers it the respective bit is set.
> > > > > > >
> > > > > > > Does that make sense? Would that be doable without boiling the 
> > > > > > > ocean?
> > > > > > > As I don't know if we see many users apart from this.  
> > > > > >
> > > > > > I have seen this so many times, where people want to avoid putting
> > > > > > things in the DT and then are surprised that everything is 
> > > > > > difficult,
> > > > > > broken and confusing. Why not just follow the rules? It is not just
> > > > > > about whether we can avoid it, etc. It is about how devices fit
> > > > > > together cohesively in the system, and how U-Boot operates.  
> > > > >
> > > > > A devicetree is only for peripherals *that cannot be located by 
> > > > > probing*.  
> > > >
> > > > I have to stop you there. It absolutely is not limited to that.  
> > >
> > > I am very sorry, but I - (and seemingly everyone else in the kernel DT
> > > community?) - seem to disagree here.  
> > 
> > Really? Where is that even coming from? Certainly not the DT spec.
> 
> It seems to be common 

[PATCH] clk: exynos: Add header guard for clk-pll.h

2023-11-07 Thread Sam Protsenko
The clk-pll.h is going to be included in multiple files soon. Add
missing header guard to prevent possible build errors in future.

Signed-off-by: Sam Protsenko 
Fixes: 166097e87753 ("clk: exynos: add clock driver for Exynos7420 Soc")
---
 drivers/clk/exynos/clk-pll.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/exynos/clk-pll.h b/drivers/clk/exynos/clk-pll.h
index c79aac44258b..7b7af5e67612 100644
--- a/drivers/clk/exynos/clk-pll.h
+++ b/drivers/clk/exynos/clk-pll.h
@@ -5,4 +5,9 @@
  * Thomas Abraham 
  */
 
+#ifndef __EXYNOS_CLK_PLL_H
+#define __EXYNOS_CLK_PLL_H
+
 unsigned long pll145x_get_rate(unsigned int *con1, unsigned long fin_freq);
+
+#endif /* __EXYNOS_CLK_PLL_H */
-- 
2.39.2



[PATCH] MAINTAINERS: Fix Sam Protsenko mail

2023-11-07 Thread Sam Protsenko
Sam works for Linaro again. Use his work e-mail address for ANDROID AB
subsystem.

Signed-off-by: Sam Protsenko 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cde778bc4d3d..d21f66b0b67b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -58,7 +58,7 @@ F:lib/acpi/
 
 ANDROID AB
 M: Igor Opaniuk 
-R: Sam Protsenko 
+R: Sam Protsenko 
 S: Maintained
 F: cmd/ab_select.c
 F: common/android_ab.c
-- 
2.39.2



[PATCH] serial: s5p: Use dev_read_addr_ptr() to get base address

2023-11-07 Thread Sam Protsenko
As the address read from device tree is being cast to a pointer, it's
better to use dev_read_addr_ptr() API for getting that address. The more
detailed explanation can be found in commit a12a73b66476 ("drivers: use
dev_read_addr_ptr when cast to pointer").

Signed-off-by: Sam Protsenko 
---
 drivers/serial/serial_s5p.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index c24d9bca84c9..7d04dcff54fc 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -221,13 +221,11 @@ static int s5p_serial_of_to_plat(struct udevice *dev)
 {
struct s5p_serial_plat *plat = dev_get_plat(dev);
const ulong port_type = dev_get_driver_data(dev);
-   fdt_addr_t addr;
 
-   addr = dev_read_addr(dev);
-   if (addr == FDT_ADDR_T_NONE)
+   plat->reg = dev_read_addr_ptr(dev);
+   if (!plat->reg)
return -EINVAL;
 
-   plat->reg = (struct s5p_uart *)addr;
plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
plat->port_id = dev_read_u8_default(dev, "id", dev_seq(dev));
 
-- 
2.39.2



rockpro64 rk3399 dwc3 issue

2023-11-07 Thread Shantur Rathore
Hi all,

I am trying to boot OS via USB3.0 ports on RK3399 base RockPro64.
U-boot is failing to detect the drive in the USB3.0 port.

If I boot linux through other mediums the drive is detected and works fine.
Can anyone please help me figure out the issue?

Kind regards,
Shantur


Re: [GIT PULL] xilinx patches for v2024.01-rc3

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 04:31:23PM +0100, Michal Simek wrote:

> Hi Tom,
> 
> please pull these patches to your tree. Most of them are dt related to
> aligned our dts in u-boot with dt-schema and fix issues around it.
> There are small updates out in spi to fix 64bit support and allow disable
> flash locking code to save some space for our mini configurations.
> And last change was related to reading baudrate from DT which was ack by 
> Simon.
> There are some other things pending but not ready yet that's why I wanted to
> get these patches merged to have more time for testing.
> Gitlab CI is not showing any issue too.
> 
> Thanks,
> Michal
> 
> The following changes since commit 3af0e9556c968fc2c40e3778d8f1e668a90af92e:
> 
>   Prepare v2024.01-rc2 (2023-11-06 14:47:25 -0500)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git
> tags/xilinx-for-v2024.01-rc3
> 
> for you to fetch changes up to 37f500d711ec1f6b25189c1f6022ffe5e70a38ab:
> 
>   dt-bindings: Remove VSC8531 specific RGMII delay definitions (2023-11-07
> 13:47:09 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

2023-11-07 Thread Tom Rini
On Tue, Nov 07, 2023 at 01:10:44AM +, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 6 Nov 2023 at 13:46, Tom Rini  wrote:
> >
> > On Mon, Nov 06, 2023 at 01:38:39PM -0700, Simon Glass wrote:
> > > Hi Andre,
> > >
> > > On Mon, 6 Nov 2023 at 10:26, Andre Przywara  
> > > wrote:
> > > >
> > > > On Sat, 4 Nov 2023 19:45:06 +
> > > > Simon Glass  wrote:
> > > >
> > > > Hi,
> > > >
> > > > > On Sat, 4 Nov 2023 at 17:13, Andre Przywara  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, 3 Nov 2023 13:38:58 -0600
> > > > > > Simon Glass  wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > > Hi Heinrich,
> > > > > > >
> > > > > > > On Wed, 1 Nov 2023 at 14:20, Heinrich Schuchardt
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On 11/1/23 19:05, Andre Przywara wrote:
> > > > > > > > > On Tue, 31 Oct 2023 14:55:50 +0200
> > > > > > > > > Heinrich Schuchardt  wrote:
> > > > > > > > >
> > > > > > > > > Hi Heinrich,
> > > > > > > > >
> > > > > > > > >> The Zkr ISA extension (ratified Nov 2021) introduced the 
> > > > > > > > >> seed CSR. It
> > > > > > > > >> provides an interface to a physical entropy source.
> > > > > > > > >>
> > > > > > > > >> A RNG driver based on the seed CSR is provided. It depends on
> > > > > > > > >> mseccfg.sseed being set in the SBI firmware.
> > > > > > > > >
> > > > > > > > > As you might have seen, I added a similar driver for the 
> > > > > > > > > respective Arm
> > > > > > > > > functionality:
> > > > > > > > > https://lore.kernel.org/u-boot/20230830113230.3925868-1-andre.przyw...@arm.com/
> > > > > > > > >
> > > > > > > > > And I see that you seem to use the same mechanism to probe 
> > > > > > > > > and init the
> > > > > > > > > driver: U_BOOT_DRVINFO and fail in probe() if the feature is 
> > > > > > > > > not
> > > > > > > > > implemented.
> > > > > > > > > One downside of this approach is that the driver is always 
> > > > > > > > > loaded (and
> > > > > > > > > visible in the DM tree), even with the feature not being 
> > > > > > > > > available.
> > > > > > > > > That doesn't seem too much of a problem on the first glance, 
> > > > > > > > > but it
> > > > > > > > > occupies a device number, and any subsequent other DM_RNG 
> > > > > > > > > devices
> > > > > > > > > (like virtio-rng) typically get higher device numbers. So 
> > > > > > > > > without
> > > > > > > > > the feature, but with virtio-rng, I get:
> > > > > > > > > VExpress64# rng 0
> > > > > > > > > No RNG device
> > > > > > >
> > > > > > > Why do we get this? If the device is not there, the bind() 
> > > > > > > function
> > > > > > > can return -ENODEV
> > > > > > >
> > > > > > > I see this in U-Boot:
> > > > > > >
> > > > > > > U_BOOT_DRVINFO(cpu_arm_rndr) = {
> > > > > > >
> > > > > > > We should not use this.
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > > Use the devicetree.
> > > > > >
> > > > > > No, this is definitely not something for the DT, at least not on 
> > > > > > ARM.
> > > > > > It's perfectly discoverable via the architected CPU ID registers.
> > > > > > Similar to PCI and USB devices, which we don't probe via the DT as 
> > > > > > well.
> > > > > >
> > > > > > It's arguably not proper "driver" material per se, as I've argued 
> > > > > > before, but
> > > > > > it's the simplest solution and fits in nicely otherwise.
> > > > > >
> > > > > > I was wondering if it might be something for UCLASS_CPU, something 
> > > > > > like
> > > > > > a "CPU feature bus": to let devices register on one on the many CPU
> > > > > > features (instead of compatible strings), then only bind() those
> > > > > > drivers it the respective bit is set.
> > > > > >
> > > > > > Does that make sense? Would that be doable without boiling the 
> > > > > > ocean?
> > > > > > As I don't know if we see many users apart from this.
> > > > >
> > > > > I have seen this so many times, where people want to avoid putting
> > > > > things in the DT and then are surprised that everything is difficult,
> > > > > broken and confusing. Why not just follow the rules? It is not just
> > > > > about whether we can avoid it, etc. It is about how devices fit
> > > > > together cohesively in the system, and how U-Boot operates.
> > > >
> > > > A devicetree is only for peripherals *that cannot be located by 
> > > > probing*.
> > >
> > > I have to stop you there. It absolutely is not limited to that.
> >
> > It is limited to that if we're going to keep using the device trees that
> > Linux uses. Full stop. There's not really wiggle room there either.
> 
> That is really the problem, I agree.

And we need to accept that, and what is/isn't something that we can
expect every board developer to have to tweak on top of this.

Heck, maybe part of the issue here is that devicetree-the-spec and
devicetree-the-linux-kernel-input need a little differentiation and some
official statement along the lines of "just because X can be in the
device tree does not mean that X will be defined in the device tree, if
it can be 

  1   2   >