Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled
On 5/15/24 02:50, Marek Vasut wrote:
On 5/15/24 2:22 AM, Tim Harvey wrote:
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Thanks for working on this one, this is really nice.
The general direction of always supplying a seed for KASLR is right. But
there are some items to observe:
We already have multiple places where /chosen/kaslr-seed is set, e.g.
arch/arm/cpu/armv8/sec_firmware.c and board/xilinx/common/board.c.
Some boards are using the kaslrseed command to initialize
/chosen/kaslr-seed from DM_RNG.
It does not make sense to set it multiple times from different sources
of randomness. I am missing the necessary clean-up in this patch.
For CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y the right way forward could be
moving sec_firmware_get_random() into the driver model. Tom is the
maintainer for this code.
For Xilinx boards your patch obsoletes part of the code in
ft_board_setup() of board/xilinx/common/board.c. CCing Michal as maintainer.
The kaslrseed command similarly becomes obsolete with your patch and
should be removed. 'git grep -n CMD_KASLR' indicates which defconfigs
would be impacted.
label_boot_kaslrseed() needs review too.
kaslr-seed is not compatible with measured boot if the device-tree is
measured. When booting via EFI in efi_try_purge_kaslr_seed() we can
safely remove the value because it is not used anyway; we provide the
EFI_RNG_PROTOCOL instead. We also support measured boot via the legacy
Linux entry point. See patch dec166d6b2c2 ("bootm: Support boot
measurement"). We should not populate kaslr-seed if
CONFIG_MEASURE_DEVICETREE=y. CCing Eddie and Ilias as they have been
working on measured boot.
If we have DM_RNG enabled poulate this value automatically when
nits
%s/poulate/populate/
Best regards
Heinrich
fdt_chosen is called.
Signed-off-by: Tim Harvey
---
boot/fdt_support.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..cd3069baf450 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ struct udevice *dev;
+ size_t len = 0x8;
+ u64 *data;
+
+ data = malloc(len);
Can you allocate this 8 byte array on stack , i.e. u64 data[2]; ?
cmd/kaslrseed.c could use similar clean up (and
lib/efi_loader/efi_dt_fixup.c and boot/pxe_utils.c ... uhhh). Maybe you
can deduplicate this functionality into common code shared by all those
duplicates before the duplication gets out of control ?
lib/kaslrseed.c looks like a good place to put the common stuff.
+ if (!data)
+ return -ENOMEM;
+
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (!err)
+ err = dm_rng_read(dev, data, len);
+ if (!err)
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", data, len);
+ if (err < 0) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
You're missing free() here, but it shouldn't be needed if you allocate
the array on stack, which is better/simpler.
[PATCH] fs: relax ext4_write_file() dependency
ext4_write_file() depends on CONFIG_EXT4_WRITE. Allow build without
CONFIG_CMD_EXT4_WRITE.
Signed-off-by: Baruch Siach
---
fs/fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fs.c b/fs/fs.c
index bed1f7242f41..0c47943f3339 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -224,7 +224,7 @@ static struct fstype_info fstypes[] = {
.exists = ext4fs_exists,
.size = ext4fs_size,
.read = ext4_read_file,
-#ifdef CONFIG_CMD_EXT4_WRITE
+#ifdef CONFIG_EXT4_WRITE
.write = ext4_write_file,
.ln = ext4fs_create_link,
#else
--
2.43.0
[PATCH v1 2/2] configs: openbmc: Revise size of environment and use preboot
Revise CONFIG_ENV_SIZE and Add CONFIG_USE_PREBOOT Signed-off-by: DelphineCCChiu --- configs/ast2600_openbmc_spl_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/ast2600_openbmc_spl_defconfig b/configs/ast2600_openbmc_spl_defconfig index efd683570f..f930108e1c 100644 --- a/configs/ast2600_openbmc_spl_defconfig +++ b/configs/ast2600_openbmc_spl_defconfig @@ -14,7 +14,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL_DRIVERS_MISC_SUPPORT=y -CONFIG_ENV_SIZE=0x1 +CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0xE CONFIG_SPL=y CONFIG_SPL_STACK_R_ADDR=0x9030 @@ -58,7 +58,6 @@ CONFIG_CMD_BOOTZ=y # CONFIG_CMD_IMI is not set # CONFIG_CMD_XIMG is not set CONFIG_CMD_MEMTEST=y -CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_CLK=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y @@ -140,3 +139,5 @@ CONFIG_SPL_TINY_MEMSET=y CONFIG_TPM=y CONFIG_SPL_TPM=y # CONFIG_EFI_LOADER is not set +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="" -- 2.25.1
[PATCH v1 0/2] mem_test: Support to save mtest result in environment
1. Set mtest_result in environment after doing mtest in u-boot so that user can check the result in user space. 2. Revise CONFIG_ENV_SIZE and Add CONFIG_USE_PREBOOT DelphineCCChiu (2): mem_test: Support to save mtest result in environment configs: openbmc: Revise size of environment and use preboot cmd/mem.c | 8 configs/ast2600_openbmc_spl_defconfig | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.25.1
[PATCH v1 1/2] mem_test: Support to save mtest result in environment
Set mtest_result in environment after doing mtest in u-boot so that user
can check the result in user space.
Signed-off-by: DelphineCCChiu
---
cmd/mem.c | 8
1 file changed, 8 insertions(+)
diff --git a/cmd/mem.c b/cmd/mem.c
index 392ed1756b..bb6a3d2e60 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -943,6 +944,13 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int
argc,
ret = errs != 0;
}
+ if (errs == 0)
+ env_set("memtest_result", "pass");
+ else
+ env_set("memtest_result", "fail");
+
+ env_save();
+
return ret;
}
#endif /* CONFIG_CMD_MEMTEST */
--
2.25.1
Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled
On 5/15/24 2:22 AM, Tim Harvey wrote:
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Thanks for working on this one, this is really nice.
If we have DM_RNG enabled poulate this value automatically when
fdt_chosen is called.
Signed-off-by: Tim Harvey
---
boot/fdt_support.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..cd3069baf450 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ struct udevice *dev;
+ size_t len = 0x8;
+ u64 *data;
+
+ data = malloc(len);
Can you allocate this 8 byte array on stack , i.e. u64 data[2]; ?
cmd/kaslrseed.c could use similar clean up (and
lib/efi_loader/efi_dt_fixup.c and boot/pxe_utils.c ... uhhh). Maybe you
can deduplicate this functionality into common code shared by all those
duplicates before the duplication gets out of control ?
lib/kaslrseed.c looks like a good place to put the common stuff.
+ if (!data)
+ return -ENOMEM;
+
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (!err)
+ err = dm_rng_read(dev, data, len);
+ if (!err)
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", data,
len);
+ if (err < 0) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
You're missing free() here, but it shouldn't be needed if you allocate
the array on stack, which is better/simpler.
[PATCH 2/2] doc: Update netconsole examples
As I understand the env command documentation the subcommand style is preferred, though the old format is still fully supported. Signed-off-by: Fiona Klute --- doc/usage/netconsole.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst index 0c983e6970..b5832843f3 100644 --- a/doc/usage/netconsole.rst +++ b/doc/usage/netconsole.rst @@ -24,9 +24,9 @@ can be used for network console. For example, if your server IP is 192.168.1.1, you could use:: - => setenv nc 'setenv stdout nc;setenv stdin nc' - => setenv ncip 192.168.1.1 - => saveenv + => env set nc 'env set stdout nc; env set stdin nc' + => env set ncip 192.168.1.1 + => env save => run nc On the host side, please use this script to access the console -- 2.43.0
[PATCH 1/2] doc: Detailed example for netconsole setup
This adds details that I would have liked to have readily available,
in particular how to activate the network interface before enabling
netconsole, and how to integrate netconsole so you can use the U-Boot
prompt.
Signed-off-by: Fiona Klute
---
doc/usage/netconsole.rst | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
index 2aa3b9ccc5..0c983e6970 100644
--- a/doc/usage/netconsole.rst
+++ b/doc/usage/netconsole.rst
@@ -18,7 +18,9 @@ broadcast address and port are used. If it is set to an
IP
address of 0 (or 0.0.0.0) then no messages are sent to the network.
The source / listening port can be configured separately by setting
the 'ncinport' environment variable and the destination port can be
-configured by setting the 'ncoutport' environment variable.
+configured by setting the 'ncoutport' environment variable. Note that
+you need to set up the network interface (e.g. using DHCP) before it
+can be used for network console.
For example, if your server IP is 192.168.1.1, you could use::
@@ -107,3 +109,32 @@ as follows:
Note that unlike the U-Boot implementation the Linux netconsole is
unidirectional, i. e. you have console output only in Linux.
+
+Setup via environment
+-
+
+If persistent environment is enabled in your U-Boot configuration, you
+can configure the network console using the environment. For example::
+
+ => env set autoload no
+ => env set hostname "u-boot"
+ => env set bootdelay 5
+ => env set nc 'dhcp; env set stdout nc; env set stdin nc'
+ => env set ncip 192.168.1.1
+ => env set preboot "${preboot}; run nc;"
+ => env save
+ => reset
+
+``autoload no`` tells the ``dhcp`` command to configure the network
+interface without trying to load an image. ``hostname "u-boot"`` sets
+the hostname to be sent in DHCP requests, so they are easy to
+recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
+to make sure the network interface is set up before enabling
+netconsole.
+
+Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
+before trying to find any boot options, so you can interact with it if
+desired.
+
+``env save`` stores the settings persistently, and ``reset`` then
+triggers a fresh start that will use the changed settings.
--
2.43.0
Re: [PATCH 0/5] *** phyCORE-AM62x: DDR detection / Inject DDR timing deltas ***
Tested-by: John Ma On 5/7/24 08:17, Wadim Egorov wrote: PHYTEC stores details about the hardware in an EEPROM on the SoM. We can utilize this information and chose the proper DDR timings accordingly. Due to the limited SRAM memory on the AM62x, the concept was to store only the DDR timings deltas and not their full set, see Patch 4 & 5. The last patch adds support for a 1 GB and 4 GB RAM variant of the phyCORE-AM62x. Patch 4 & 5 are based on https://patchwork.ozlabs.org/project/uboot/list/?series=404273 Wadim Egorov (5): board: phytec: Make AM6 SoM detection depend on I2C board: phytec: Fix function definitions in AM6x SOM detection arm: mach-k3: am625: Call do_board_detect() before DDR probing board: phytec: common: Introduce a method to inject DDR timings deltas board: phytec: am62x: Add support for 1 & 4 GB RAM variants arch/arm/mach-k3/am625_init.c | 2 + board/phytec/common/Kconfig | 2 + board/phytec/common/am6_som_detection.c | 18 +- board/phytec/common/am6_som_detection.h | 8 + board/phytec/common/k3/Makefile | 1 + board/phytec/common/k3/k3_ddrss_patch.c | 68 ++ board/phytec/common/k3/k3_ddrss_patch.h | 28 +++ board/phytec/phycore_am62x/MAINTAINERS| 1 + board/phytec/phycore_am62x/phycore-am62x.c| 152 - board/phytec/phycore_am62x/phycore-ddr-data.h | 206 ++ configs/phycore_am62x_a53_defconfig | 4 + configs/phycore_am62x_r5_defconfig| 4 + 12 files changed, 483 insertions(+), 11 deletions(-) create mode 100644 board/phytec/common/k3/k3_ddrss_patch.c create mode 100644 board/phytec/common/k3/k3_ddrss_patch.h create mode 100644 board/phytec/phycore_am62x/phycore-ddr-data.h
[PATCH] fdt: add kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled poulate this value automatically when
fdt_chosen is called.
Signed-off-by: Tim Harvey
---
boot/fdt_support.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..cd3069baf450 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ struct udevice *dev;
+ size_t len = 0x8;
+ u64 *data;
+
+ data = malloc(len);
+ if (!data)
+ return -ENOMEM;
+
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (!err)
+ err = dm_rng_read(dev, data, len);
+ if (!err)
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", data,
len);
+ if (err < 0) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
+ }
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
abuf_data(), abuf_size());
--
2.25.1
Re: [PATCH 09/13] syscon: Probe device first in syscon_get_regmap
在2024年5月14日五月 下午3:50，Jonas Karlman写道： > Hi Jiaxun, [...] >> +return ERR_PTR(ret); > > Please explain in more details what the issue this is trying to solve. > > Typically syscon_get_regmap() is called on a udevice returned from a > uclass_get_device call, and that should trigger a probe for the device > and its parents. > > Adding device_probe() here possible just hides an issue that exists > somewhere else. In what instance are you ending up with a call to > this function with a udevice that has not been probed? Hi Jonas, Thanks for the reply, my problem is in [PATCH 10/13] I'm using dev->parent directly to get parent device and then use that pointer to access syscon_get_regmap. There is no chance to invoke uclass_get_device_* as what we need is just the parent device. I can think of two solution without touching syscon code here. First would be performing uclass_get_device_by_ofnode against parent's ofnode, which seems a little bit overkilling. Second would be trigger probing in dev_get_parent. Thanks - Jiaxun > > Also, please add a new test to test/dm/regmap.c if this solves a real > issue. > > Regards, > Jonas > >> priv = dev_get_uclass_priv(dev); >> return priv->regmap; >> } >> -- - Jiaxun
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On 5/14/24 8:34 PM, Tim Harvey wrote:
Hi,
diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
index e16e5410bd9..ce1de659d8c 100644
--- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
+++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
@@ -121,6 +121,9 @@ build configuration:
- Defconfig:
CONFIG_IMX_HAB=y
+ CONFIG_FSL_CAAM=y
+ CONFIG_ARCH_MISC_INIT=y
+ CONFIG_SPL_CRYPTO=y
Hi Marek,
Thanks for wrapping the dts bits with a config item.
Is there any other reason to build with CONFIG_IMX_HAB than to use a
signed image? I see that there are several ARCH_MX6 and ARCH_MX7
configs that have this enabled (not ARCH_IMX8M so this certainly
doesn't break anything) and I'm not sure what the value of that is.
I think those few either enabled in preemptively in anticipation of
possibly using HAB, or are wrong. I suspect it should be disabled for
those, as it only adds to the board boot time and I am not even sure if
those machines would boot correctly.
Francesco, maybe you do have MX7 Colibri ?
I notice that FSL_CAAM is selected when you select IMX_HAB... is there
any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
IMX_HAB as well (future patch perhaps)?
ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
on MX8M I think . As for SPL_CRYPTO, that should be selected by
SPL_FSL_CAAM I think.
- Kconfig:
We definitely need to describe the additional requirements here. Maybe
something like:
- Tools:
cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
- Files: (created with NXP IMX_CST_TOOL)
SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): CSF_KEY
IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): IMG_KEY
The following works fine for me on v2024.01
export CST_DIR=/usr/src/nxp/cst-3.3.2/
export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
export PATH=$CST_DIR/linux64/bin:$PATH
make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
But with the above defines and your series this fails:
ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
make
BINMAN .binman_stamp
Wrote map file './image.map' to show errors
binman: Error 1 running 'cst -i
./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
0:error:02001002:system library:fopen:No such file or
directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
pem','r')
0:error:20074002:BIO routines:file_ctrl:system lib:crypto/bio/bss_file.c:290:
make: *** [Makefile:1126: .binman_stamp] Error 1
So how is it that the default for nxp,img-crt
IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
vs ln them.
So what am I missing here?
I think CST is using both the certificate and the key files. Try and run
strace on the CST to test that:
$ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst@0
Re: [PATCH] clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present
On Wed, May 1, 2024 at 4:12 PM Sam Protsenko wrote: > > On Wed, Apr 10, 2024 at 9:53 PM Sean Anderson wrote: > > > > On 3/7/24 19:04, Sam Protsenko wrote: > > > Sometimes clocks provided to a consumer might not have .set_rate > > > operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag > > > set. In that case it's usually possible to find a parent up the tree > > > which is capable of setting the rate (div, pll, etc). Implement a simple > > > lookup procedure for such cases, to traverse the clock tree until > > > .set_rate capable parent is found, and use that parent to actually > > > change the rate. The search will stop once the first .set_rate capable > > > clock is found, which is usually enough to handle most cases. > > > > > > Signed-off-by: Sam Protsenko > > > --- > > [snip] > > > > > Can you give an example of where this is needed? > > > > Sure. In my case it's needed for eMMC enablement on E850-96 board. > eMMC node in the device tree [1] is a gate clock > (CLK_GOUT_MMC_EMBD_SDCLKIN), so the MMC driver won't be able to change > its rate. But that clock actually has CLK_SET_RATE_PARENT flag set in > the clock driver [2]. So the right thing to do in this case (and > that's basically how it's done in Linux kernel too) is to traverse the > clock tree upwards, and try to find the parent capable to do .set_rate > (which is usually a divider clock), and use it to change the clock > rate. I'm working on exynos_dw_mmc driver [3] right now, making it use > CCF clocks, but I can't do that before this patch is applied. > > Grepping the U-Boot tree I can see the CLK_SET_RATE_PARENT flag is > also used in various IMX clock drivers and STM32MP13 clock driver. I > guess without this change those flags will be basically ignored. > > Thanks! > Hi Sean, Just wanted to check if you think my explanation above is ok and the patch can be applied? I'm finishing my new patch series for enabling MMC on E850-96, but this patch has to be applied first. Thanks! > [1] > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos850.dtsi#L408 > [2] > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/clk/exynos/clk-exynos850.c#L353 > [3] > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/mmc/exynos_dw_mmc.c#L117 > > > --Sean
Re: [PATCH] imx: hab: add documentation about the required keys/certs
On Sun, May 12, 2024 at 10:08 PM Marek Vasut wrote:
>
> On 5/8/24 9:23 AM, Claudius Heine wrote:
> > Hi Marek,
>
> Hi,
>
> > On 2024-05-07 3:28 pm, Marek Vasut wrote:
> >> On 5/7/24 3:06 PM, Claudius Heine wrote:
> >>> For CST to find the certificates and keys for signing, some keys and
> >>> certs need to be copied into the u-boot build directory.
> >>
> >> Make sure to CC "NXP i.MX U-Boot Team" , else NXP is not informed. Use
> >> scripts/get_maintainer to get the full list or just reuse the CC list
> >> from patches in this thread.
> >
> > I send the patch with `--to-cmd scripts/get_maintainer.pl`, maybe I
> > should have used `--cc-cmd`, but that would not change the list of
> > recipients.
>
> Should now be fixed in
> [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry
>
> >>> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> index ce1de659d8..42214df21a 100644
> >>> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> @@ -144,6 +144,22 @@ The signing is activated by wrapping SPL and
> >>> fitImage sections into nxp-imx8mcst
> >>> etype, which is done automatically in
> >>> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
> >>> in case CONFIG_IMX_HAB Kconfig symbol is enabled.
> >>> +Per default the HAB keys and certificates need to be located in the
> >>> build
> >>> +directory, this means copying the following files from the HAB keys
> >>> directory
> >>> +flat (e.g. removing the `keys` and `cert` subdirectory) into the
> >>> u-boot build
> >>> +directory for the CST Code Signing Tool to locate them:
> >>
> >> Do symlink(s) work too ?
> >
> > I have not tested it, but I don't see any reason why it would not. I
> > also don't see a reason for mentioning it. I want to keep it simple, if
> > the dev whats to do things differently, they are free to do so.
>
> "
> Per default the HAB keys and certificates need to be located in the
> build directory, this means {+creating a symbolic link or +}copying the
> following...
> "
>
> Please test it and add it in V2 if it works, I think symlink is better
> than bluntly copying files around, esp. for crypto material.
Hi Marek and Claudius,
Yes, this documentation is needed as well but I'm still unclear why
the old method before this series did not require the usr_key.pem
files, why I don't have the *usr_key.pem files in my crts dir created
(long ago) with cst-3.3.1 and cst-3.3.2, and what I need to do to
generate them now that they are apparently needed.
Best Regards,
Tim
>
> >>> +- `crts/SRK_1_2_3_4_table.bin`
> >>> +- `crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem`
> >>> +- `keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem`
> >>> +- `crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem`
> >>> +- `keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem`
> >>> +- `keys/key_pass.txt`
> >>> +
> >>> +The paths to the SRK table and the certificates can be modified via
> >>> changes to
> >>> +the nxp_imx8mcst device tree node
> >>
> >> "nodes", plural, there are two, one for SPL and one for fitImage.
> >
> > Well, I was thinking here more generally about the node type and was
> > assuming that the person reading this knows how many they have of that
> > type. But I can add a `s` in v2.
>
> Use "node(s)" which covers both options.
>
> >> It would be good to mention the DT properties which govern the crypto
> >> material paths -- nxp,srk-table, nxp,csf-crt, nxp,img-crt -- somewhere
> >> around this sentence.
> >
> > This is something that should be documented with the changes where that
> > code was added, IMO. I only documented here what I found out and have
> > used myself, I haven't used those.
> >
> > I would be interested in reading how to best overwrite those paths and
> > the image structured from board u-boot.dtsi files myself.
> >
> > If you want to can pickup my patch and integrate it into your series and
> > extend it.
>
> I'll keep it in mind for V3.
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Thu, May 2, 2024 at 6:05 PM Marek Vasut wrote:
>
> Update documentation and use nxp_imx8mcst binman etype for signing
> of flash.bin instead of previous horrible shell scripting.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "NXP i.MX U-Boot Team"
> Cc: Adam Ford
> Cc: Alper Nebi Yasak
> Cc: Andrejs Cainikovs
> Cc: Angus Ainslie
> Cc: Emanuele Ghidoli
> Cc: Fabio Estevam
> Cc: Francesco Dolcini
> Cc: Marcel Ziswiler
> Cc: Rasmus Villemoes
> Cc: Simon Glass
> Cc: Stefan Eichenberger
> Cc: Stefano Babic
> Cc: Tim Harvey
> Cc: Tom Rini
> Cc: ker...@puri.sm
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> V2: Document the automatic signing in case CONFIG_IMX_HAB is enabled
> ---
> doc/imx/habv4/csf_examples/mx8m/csf.sh| 92
> doc/imx/habv4/csf_examples/mx8m/csf_fit.txt | 30 --
> doc/imx/habv4/csf_examples/mx8m/csf_spl.txt | 33 --
> doc/imx/habv4/guides/mx8m_spl_secure_boot.txt | 100 +++---
> 4 files changed, 14 insertions(+), 241 deletions(-)
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
>
> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> index e16e5410bd9..ce1de659d8c 100644
> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> @@ -121,6 +121,9 @@ build configuration:
> - Defconfig:
>
>CONFIG_IMX_HAB=y
> + CONFIG_FSL_CAAM=y
> + CONFIG_ARCH_MISC_INIT=y
> + CONFIG_SPL_CRYPTO=y
>
Hi Marek,
Thanks for wrapping the dts bits with a config item.
Is there any other reason to build with CONFIG_IMX_HAB than to use a
signed image? I see that there are several ARCH_MX6 and ARCH_MX7
configs that have this enabled (not ARCH_IMX8M so this certainly
doesn't break anything) and I'm not sure what the value of that is.
I notice that FSL_CAAM is selected when you select IMX_HAB... is there
any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
IMX_HAB as well (future patch perhaps)?
> - Kconfig:
>
We definitely need to describe the additional requirements here. Maybe
something like:
- Tools:
cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
- Files: (created with NXP IMX_CST_TOOL)
SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): CSF_KEY
IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): IMG_KEY
The following works fine for me on v2024.01
export CST_DIR=/usr/src/nxp/cst-3.3.2/
export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
export PATH=$CST_DIR/linux64/bin:$PATH
make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
But with the above defines and your series this fails:
ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
make
BINMAN .binman_stamp
Wrote map file './image.map' to show errors
binman: Error 1 running 'cst -i
./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
0:error:02001002:system library:fopen:No such file or
directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
pem','r')
0:error:20074002:BIO routines:file_ctrl:system lib:crypto/bio/bss_file.c:290:
make: *** [Makefile:1126: .binman_stamp] Error 1
So how is it that the default for nxp,img-crt
IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
vs ln them.
So what am I missing here?
Best Regards,
Tim
> @@ -131,92 +134,17 @@ build configuration:
>
> The CSF contains all the commands that the HAB executes during the secure
> boot. These commands instruct the HAB code on which memory areas of the image
> -to authenticate, which keys to install, use and etc.
> -
> -CSF examples are available under doc/imx/habv4/csf_examples/ directory.
> -
> -CSF "Blocks" line for csf_spl.txt can be generated as follows:
> -
> -```
> -spl_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_SPL_TEXT_BASE=/
> s@.*=@@p" .config) - 0x40)) )
> -spl_block_size=$(printf "0x%x" $(stat -tc %s u-boot-spl-ddr.bin))
> -sed -i "/Blocks = / s@.*@ Blocks = $spl_block_base 0x0 $spl_block_size
> \"flash.bin\"@" csf_spl.txt
> -```
> -
> -The resulting line looks as follows:
> -```
> - Blocks = 0x7e0fc0 0x0 0x306f0 "flash.bin"
> -```
> -
> -The columns mean:
> - - CONFIG_SPL_TEXT_BASE - 0x40 -- Start address of signed data, in DRAM
> - - 0x0 -- Start address of signed data, in "flash.bin"
> - - 0x306f0 -- Length of signed data,
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On Tue, May 14, 2024 at 5:05 AM Dragan Simic wrote:
>
> Hello all,
>
> On 2024-05-14 01:02, Marek Vasut wrote:
> > On 5/13/24 10:52 PM, Tim Harvey wrote:
> >> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
> >>>
> >>> On 4/29/24 6:48 PM, Tim Harvey wrote:
> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
> >
> > On 4/27/24 2:11 AM, Tim Harvey wrote:
> >
> > [...]
> >
> >> diff --git a/include/mmc.h b/include/mmc.h
> >> index 4b8327f1f93b..7243bd761202 100644
> >> --- a/include/mmc.h
> >> +++ b/include/mmc.h
> >> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >> #define MMC_TIMING_MMC_HS2009
> >> #define MMC_TIMING_MMC_HS40010
> >>
> >> +/* emmc hardware partition values */
> >> +enum emmc_hwpart {
> >> + EMMC_HWPART_DEFAULT = 0,
> >
> > One more thing ... eMMC hardware partition 0 and 7 are both
> > referring to
> > USER HW partition. Have a look at the git log, there have been
> > patches
> > which handled this case in the MMC subsystem from about a year ago.
>
> I can't find what you are referring to. I assume you are talking
> about
> calling the first name something other than 'user' as technically
> it's
> not (but it gets treated as user).
>
> Can you find the commit or discussion you are thinking about?
> >>>
> >>> It seems this whole thing is much older:
> >>>
> >>> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
> >>> CONFIG_SPL_FRAMEWORK")
> >>>
> >>> +* We need to check what the partition is configured
> >>> to.
> >>> +* 1 and 2 match up to boot0 / boot1 and 7 is user
> >>> data
> >>> +* which is the first physical partition (0).
> >>> +*/
> >>> + int part = (mmc->part_config >> 3) &
> >>> PART_ACCESS_MASK;
> >>> +
> >>> + if (part == 7)
> >>> + part = 0;
> >> Sorry, I haven't been able to work on U-Boot for the past week or so
> >> and am just getting back to this.
> >
> > No worries.
> >
> >> I'm glad you pointed this out as it made me aware that there is a bit
> >> of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
> >> BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
> >>
> >> I'm going to add an enumerated type for each and update the various
> >> places where a 'conversion' as above is done but I'm still a bit torn
> >> on naming conventions.
> >>
> >> Consider the following:
> >> - the eMMC spec refers to boot partitions and gp partitions as 1 based
> >> - the Linux kernel device names for these are 0 based
> >> - U-Boot does not currently refer to the boot devices by names but
> >> does currently refer to the gp's by names using 1-based names (the
> >> 'mmc hwpartition' command)
> >>
> >> Personally I would like to name the boot partitions 'boot0' and
> >> 'boot1' to match Linux but I think I should name the gp's
> >> 'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
> >> command.
> >>
> >> What do you think?
> >
> > I agree.
> >
> > Maybe you could also check this with Ulf (Linux MMC maintainer) and
> > Avri (mmc-utils), both on To:, so we would be consistent and in sync ?
>
> As I promised earlier, I went through a few JEDEC standards and some
> publicly available JEDEC documents and presentations, and my conclusion
> is that no official numbering scheme for the partitions seems to be
> defined there.
>
> However, I'd propose that we keep "boot0" and "boot1", because that's
> pretty much become a de facto standard, and also switch to using "gp0"
> through "gp3" for the general-purpose partitions. That switch might
> be some kind of a backward-incompatible change, but it would follow
> the names of the corresponding GP_SIZE_MULT_GP0 ... GP_SIZE_MULT_GP3
> fields in the EXT_CSD register, as defined by JEDEC, and it would also
> be more consistent with the numbering of the boot partitions.
>
> Though, general-purpose partitions are mentioned as GPP1 ... GPP4 in
> one place in the JEDEC standard, which just confirms that no official
> numbering scheme seems to be defined. Moreover, the boot partitions
> are more than once referred to as "boot partition 1" and "boot partition
> 2" in the JEDEC standard, which means we're already not following the
> standard with "boot0" and "boot1".
>
> Frankly, it's all a bit contradictory and confusing, but I think that
> the increased consistency would outweigh the backward-incompatible
> downside of the switch to "gp0" through "gp3".
Dragan,
Thanks for your freedback and sorry for the late reply.
I also went over the spec and found that they used 1 based naming in
their referencing of the partitions but noticed that Linux uses 0
based naming for both boot partitions as well as gp's when creating
devs. Seeing as both Linux and U-Boot tend to use 0 based naming I
wanted to go that route but then I noticed the 'mmc
Re: [PATCH] scripts: gen_compile_commands: fix invalid escape sequence warning
On Fri, May 03, 2024 at 05:18:36PM +0200, Caleb Connolly wrote:
> Since Python 3.12 unrecognised escape sequences trigger a SyntaxWarning.
> Convert the '\#' string to a raw string so the backslash is correctly
> used as a literal.
>
> Ported from Linux commit dae4a0171e25 ("gen_compile_commands: fix invalid
> escape sequence warning").
>
> This updates the script to be in-line with Linux 6.9-rc6.
>
> Signed-off-by: Caleb Connolly
> Reviewed-by: João Marcos Costa
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] arm: mach-k3: Move code specific to a SoC into that SoC's directory
On Fri, May 10, 2024 at 03:21:24PM -0500, Andrew Davis wrote: > Each SoC now has a directory in mach-k3, let's move the SoC specific > files into their respective directories. > > Signed-off-by: Andrew Davis Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Init virtio before loading ENV from EXT4 or FAT
On Wed, May 01, 2024 at 10:54:09AM +0200, Fiona Klute wrote:
> Specifying a file in an EXT4 or FAT partition on a virtio device as
> environment location failed because virtio hadn't been initialized by
> the time the environment was loaded. This patch mirrors commit
> 54ee5ae84191 ("Add SCSI scan for ENV in EXT4 or FAT") in issue and
> fix, just for a different kind of block device.
>
> The additional include in include/virtio.h is needed so all functions
> called there are defined, the alternative would have been to include
> dm/device.h separately in the env/ sources.
>
> Checkpatch suggests using "if (IS_ENABLED(CONFIG...))" instead of
> "#if defined(CONFIG_...)", I'm sticking to the style of the existing
> code here.
>
> Signed-off-by: Fiona Klute
> CC: Joe Hershberger
> CC: Bin Meng
> CC: Rogier Stam
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1] crypto: nuvoton: npcm_sha: Support SHA 384/512
On Mon, Apr 29, 2024 at 02:38:03PM +0800, Jim Liu wrote: > 1. Use vendor naming rule to rename each function > 2. add SHA 384/512 support > > Signed-off-by: Jim Liu Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] armv8: generic_timer: Use event stream for udelay
On Wed, May 01, 2024 at 09:16:33AM +0100, Peter Hoyes wrote: > From: Peter Hoyes > > Polling cntpct_el0 in a tight loop for delays is inefficient. > This is particularly apparent on Arm FVPs, which do not simulate > real time, meaning that a 1s sleep can take a couple of orders > of magnitude longer to execute in wall time. > > If running at EL2 or above (where CNTHCTL_EL2 is available), enable > the cntpct_el0 event stream temporarily and use wfe to implement > the delay more efficiently. The event period is chosen as a > trade-off between efficiency and the fact that Arm FVPs do not > typically simulate real time. > > This is only implemented for Armv8 boards, where an architectural > timer exists, and only enabled by default for the ARCH_VEXPRESS64 > board family. > > Signed-off-by: Peter Hoyes > Reviewed-by: Andre Przywara Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] arm: Move sev() and wfe() definitions to common Arm header file
On Wed, May 01, 2024 at 09:16:32AM +0100, Peter Hoyes wrote: > From: Peter Hoyes > > The sev() and wfe() asm macros are currently defined only for > mach-exynos. As these are common Arm instructions, move them to the > common asm/system.h header file, for both Armv7 and Armv8, so they > can be used by other machines. > > wfe may theoretically trigger a context switch if an interrupt occurs > so add a memory barrier to this call. > > Signed-off-by: Peter Hoyes > Reviewed-by: Andre Przywara Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] sandbox: make function 'do_undefined' properly compiles for PowerPC
On Wed, May 01, 2024 at 12:55:10AM +0800, WHR wrote: > The 2 bytes 0x is too short for being a PowerPC instruction, resulting > in an error similar to: > /tmp/ccW8yjie.s: Assembler messages: > /tmp/ccW8yjie.s: Error: unaligned opcodes detected in executable segment > /tmp/ccW8yjie.s:223: Error: instruction address is not a multiple of 4 > make[2]: *** [/tmp/ccyF4HIC.mk:17: /tmp/ccCKUFuF.ltrans5.ltrans.o] Error 1 > > Signed-off-by: WHR Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] zfs: fix function 'zlib_decompress' pointlessly calling itself
On Wed, May 01, 2024 at 12:40:38AM +0800, WHR wrote: > In order to prevent crashing due to infinite recursion and actually > decompress the requested data, call the zlib function 'uncompress' > instead. > > Signed-off-by: WHR Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] zfs: recognize zpools formatted with features support
On Wed, May 01, 2024 at 12:28:32AM +0800, WHR wrote: > Currently no features are implemented, only the zpool version 5000 that > indicating the features support, is recognized. Since it is possible for > OpenZFS to create a pool with features support enabled, but without > enabling any actual feature, this change enables U-Boot to read such > pools. > > Signed-off-by: WHR Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] u-boot-riscv/master
On Tue, May 14, 2024 at 09:28:54PM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit c8ffd1356d42223cbb8c86280a083cc3c93e6426: > > Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" > (2024-05-13 09:15:51 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 2b8dc36b4c515979da330a96d9fcc9bbbe5385fa: > > andes: Unify naming policy for Andes related source (2024-05-14 18:50:47 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/20690 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] Please pull qcom/qcom-main
On Tue, May 14, 2024 at 09:01:24AM +0200, Caleb Connolly wrote: > Hi Tom, > > This patch for master fixes framebuffer video on almost all Qualcomm platforms > where the framebuffer is initialised by the first stage bootloader. > > The following changes since commit 5c5565cfec92eb7377ff7fe197612c6a813bb6c7: > > Merge patch series "arm: davinci: Migrate da850-evm to OF_UPSTREAM" > (2024-05-07 11:59:26 -0600) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-snapdragon.git qcom-main > > for you to fetch changes up to 3ceaa825869bd43e9a2ec00a90589cc84885bd40: > > mach-snapdragon: do carveouts for qcs404 only (2024-05-14 09:00:41 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/13] syscon: Probe device first in syscon_get_regmap
Hi Jiaxun,
On 2024-05-13 20:13, Jiaxun Yang wrote:
> When bootph-all is enabled for a syscon driver, the device
> may leave unprobed when syscon_get_regmap is called by another
> driver.
>
> Perform device_probe in syscon_get_regmap, there is no side
> affect as device_probe will return 0 quickly for an activated
> device.
>
> Signed-off-by: Jiaxun Yang
> ---
> drivers/core/syscon-uclass.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
> index f0e69d7216b3..b09f7013194d 100644
> --- a/drivers/core/syscon-uclass.c
> +++ b/drivers/core/syscon-uclass.c
> @@ -32,10 +32,14 @@
> */
> struct regmap *syscon_get_regmap(struct udevice *dev)
> {
> + int ret;
> struct syscon_uc_info *priv;
>
> if (device_get_uclass_id(dev) != UCLASS_SYSCON)
> return ERR_PTR(-ENOEXEC);
> + ret = device_probe(dev);
> + if (ret)
> + return ERR_PTR(ret);
Please explain in more details what the issue this is trying to solve.
Typically syscon_get_regmap() is called on a udevice returned from a
uclass_get_device call, and that should trigger a probe for the device
and its parents.
Adding device_probe() here possible just hides an issue that exists
somewhere else. In what instance are you ending up with a call to
this function with a udevice that has not been probed?
Also, please add a new test to test/dm/regmap.c if this solves a real
issue.
Regards,
Jonas
> priv = dev_get_uclass_priv(dev);
> return priv->regmap;
> }
>
Re: [PATCH v3] sysreset: add Qualcomm PSHOLD reset driver
On Tue, 14 May 2024 12:15:02 +0200, Robert Marko wrote: > Number of Qualcomm ARMv7 SoC-s did not use PSCI but rather used PSHOLD > (Qualcomm Power Supply Hold Reset) bit to trigger reset or poweroff. > > Qualcomm IPQ40XX is one of them, so provide a simple sysreset driver based > on the upstream Linux one, it is DT compatible as well. > > > [...] Applied, thanks! [1/1] sysreset: add Qualcomm PSHOLD reset driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/93738072fea1 Best regards, -- Caleb Connolly
[PATCH 3/3] drivers: misc: Add driver to access ZynqMP efuses
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
drivers/misc/Kconfig| 8 ++
drivers/misc/Makefile | 1 +
drivers/misc/zynqmp_efuse.c | 213
3 files changed, 222 insertions(+)
create mode 100644 drivers/misc/zynqmp_efuse.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
Security Monitor can be transitioned on any security failures,
like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+ bool "Enable ZynqMP eFUSE Driver"
+ depends on ZYNQMP_FIRMWARE
+ help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security
related
+ and cannot be read back (i.e. AES key).
+
choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..0cfc42a4f39
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK 0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES (4)
+#define SOC_VER_SIZE (0x4)
+#define EFUSE_MEMORY_SIZE (0x177)
+#define UNUSED_SPACE (0x8)
+#define ZYNQMP_NVMEM_SIZE (SOC_VER_SIZE + UNUSED_SPACE + \
+EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET (0x0)
+#define EFUSE_START_OFFSET (0xC)
+#define EFUSE_END_OFFSET (0xFC)
+#define EFUSE_PUF_START_OFFSET (0x100)
+#define EFUSE_PUF_MID_OFFSET (0x140)
+#define EFUSE_PUF_END_OFFSET (0x17F)
+#define EFUSE_NOT_ENABLED (29)
+#define EFUSE_READ (0)
+#define EFUSE_WRITE(1)
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src: address of the buffer to store the data to be write/read
+ * @size: no of words to be read/write
+ * @offset:offset to be read/write`
+ * @flag: 0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+ u64 src;
+ u32 size;
+ u32 offset;
+ u32 flag;
+ u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_access(struct udevice *dev, unsigned int offset,
+ void *val, size_t bytes, unsigned int flag,
+ unsigned int pufflag)
+{
+ size_t words = bytes / WORD_INBYTES;
+ ulong dma_addr, dma_buf;
+ struct xilinx_efuse *efuse;
+ char *data;
+ int ret, value;
+
+ if (bytes % WORD_INBYTES != 0) {
+ dev_err(dev, "Bytes requested should be word aligned\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (pufflag == 0 && offset % WORD_INBYTES) {
+ dev_err(dev, "Offset requested should be word aligned\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (pufflag == 1 && flag == EFUSE_WRITE) {
+ memcpy(, val, bytes);
+ if ((offset == EFUSE_PUF_START_OFFSET ||
+offset == EFUSE_PUF_MID_OFFSET) &&
+ value & P_USER_0_64_UPPER_MASK) {
+ dev_err(dev, "Only lower 4 bytes are allowed to be
programmed in P_USER_0 & P_USER_64\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (offset == EFUSE_PUF_END_OFFSET &&
+ (value & P_USER_127_LOWER_4_BIT_MASK)) {
+ dev_err(dev, "Only MSB 28 bits are allowed to be
programmed for P_USER_127\n");
+ return -EOPNOTSUPP;
+ }
+ }
+
+ efuse = dma_alloc_coherent(sizeof(struct xilinx_efuse), _addr);
+ if (!efuse)
+ return -ENOMEM;
+
+ data =
[PATCH 0/3] Add eFuse access for ZynqMP
From: Lukas Funke This series adds a driver to read and write ZynqMP eFuses [1]. The driver can be accessed by the 'efuse_read' and 'efuse_write' subcommands of the 'zynqmp' command. Example: => zynqmp efuse_read 0xc 0xc : 85 66 b1 32 43 f2 4a 02 00 00 00 40 .f.https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/eFUSE Lukas Funke (3): firmware: zynqmp: Add support to access efuses amd64: zynqmp: Add command to program efuses drivers: misc: Add driver to access ZynqMP efuses board/xilinx/zynqmp/cmds.c | 101 ++ drivers/firmware/firmware-zynqmp.c | 31 + drivers/misc/Kconfig | 8 ++ drivers/misc/Makefile | 1 + drivers/misc/zynqmp_efuse.c| 213 + include/zynqmp_firmware.h | 2 + 6 files changed, 356 insertions(+) create mode 100644 drivers/misc/zynqmp_efuse.c -- 2.30.2
[PATCH 2/3] amd64: zynqmp: Add command to program efuses
From: Lukas Funke
Add subcommands to read/write eFuses using u-boot. The subcommands
through the 'zynqmp' command.
Example:
=> zynqmp efuse_read 0xc 0xc
: 85 36 b1 3c 34 f2 3b 01 00 00 00 40 .f.
---
board/xilinx/zynqmp/cmds.c | 101 +
1 file changed, 101 insertions(+)
diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index bf39c5472ea..e8d70ffecd6 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -16,6 +16,9 @@
#include
#include
#include
+#include
+#include
+#include
static int do_zynqmp_verify_secure(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
@@ -340,6 +343,99 @@ static int do_zynqmp_sha3(struct cmd_tbl *cmdtp, int flag,
return CMD_RET_SUCCESS;
}
+static int do_zynqmp_efuse_read(struct cmd_tbl *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ struct udevice *dev;
+ u32 offset, len;
+ u8 buf[32];
+ int ret;
+
+ if (!CONFIG_IS_ENABLED(ZYNQMP_EFUSE)) {
+ printf("Failed: not supported\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc > cmdtp->maxargs || argc < (cmdtp->maxargs - 1))
+ return CMD_RET_USAGE;
+
+ memset(buf, 0, sizeof(buf));
+
+ offset = hextoul(argv[2], NULL);
+ len = hextoul(argv[3], NULL);
+
+ if (len > sizeof(buf)) {
+ printf("Failed: length exceeds buffer size");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(zynqmp_efuse), );
+ if (ret) {
+ printf("Failed to initialize zynqmp_efuse: %d\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = misc_read(dev, offset, (void *)buf, len);
+ if (ret) {
+ printf("Failed: cannot read efuse at 0x%x, errocode %d\n",
+ offset, ret);
+ return CMD_RET_FAILURE;
+ }
+
+ if (CONFIG_IS_ENABLED(HEXDUMP))
+ print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_zynqmp_efuse_write(struct cmd_tbl *cmdtp, int flag,
+int argc, char * const argv[])
+{
+ struct udevice *dev;
+ u64 value;
+ u32 offset, len;
+ u8 buf[sizeof(u64)];
+ int ret;
+
+ if (!CONFIG_IS_ENABLED(ZYNQMP_EFUSE)) {
+ printf("Failed: not supported\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc > cmdtp->maxargs || argc < (cmdtp->maxargs - 1))
+ return CMD_RET_USAGE;
+
+ memset(buf, 0, sizeof(buf));
+
+ offset = hextoul(argv[2], NULL);
+ len = hextoul(argv[3], NULL);
+
+ if (len <= sizeof(u64)) {
+ value = hextoul(argv[4], NULL);
+ memcpy(buf, , sizeof(value));
+ } else {
+ printf("Cannot write more than %zu byte to efuse\n",
sizeof(u64));
+ return CMD_RET_FAILURE;
+ }
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(zynqmp_efuse), );
+ if (ret) {
+ printf("Failed to initialize zynqmp_efuse: %d\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = misc_write(dev, offset, (void *)buf, sizeof(buf));
+ if (ret) {
+ printf("Failed: cannot read efuse at 0x%x, errocode 0x%x\n",
+ offset, ret);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(secure, 5, 0, do_zynqmp_verify_secure, "", ""),
U_BOOT_CMD_MKENT(pmufw, 4, 0, do_zynqmp_pmufw, "", ""),
@@ -348,6 +444,8 @@ static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(aes, 9, 0, do_zynqmp_aes, "", ""),
U_BOOT_CMD_MKENT(rsa, 7, 0, do_zynqmp_rsa, "", ""),
U_BOOT_CMD_MKENT(sha3, 5, 0, do_zynqmp_sha3, "", ""),
+ U_BOOT_CMD_MKENT(efuse_read, 4, 0, do_zynqmp_efuse_read, "", ""),
+ U_BOOT_CMD_MKENT(efuse_write, 5, 0, do_zynqmp_efuse_write, "", ""),
#ifdef CONFIG_DEFINE_TCM_OCM_MMAP
U_BOOT_CMD_MKENT(tcminit, 3, 0, do_zynqmp_tcm_init, "", ""),
#endif
@@ -422,6 +520,9 @@ U_BOOT_LONGHELP(zynqmp,
" 48 bytes hash value into srcaddr\n"
" Optional key_addr can be specified for saving sha3 hash value\n"
" Note: srcaddr/srclen should not be 0\n"
+ "zynqmp efuse_read offset len - read efuse at given offset\n"
+ "zynqmp efuse_write offset len value - write value of length \n"
+ " to efuse at given offset\n"
);
U_BOOT_CMD(
--
2.30.2
[PATCH 1/3] firmware: zynqmp: Add support to access efuses
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index f99507d86c6..7483f2a8709 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -210,6 +210,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
}
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+
+ if (!idcode || !version)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+ *idcode = ret_payload[1];
+ *version = ret_payload[2];
+
+ return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+
+ if (!out)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+ lower_32_bits(address), 0, 0, ret_payload);
+
+ *out = ret_payload[1];
+
+ return ret;
+}
+
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
{
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32
arg2,
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32
value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
int zynqmp_mmio_read(const u32 address, u32 *value);
int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
--
2.30.2
Re: [PATCH] sunxi: SPL SPI: add support for the V3s SoC
On Tue, 14 May 2024 01:43:19 +0200
Michael Walle wrote:
Hi Michael,
> The V3s is identical regarding register layout, clocks and resets to
> the sun6i variants. Therefore, we can just add the MACH_SUN8I_V3S to
> the sun6i compatible ones.
Interesting, I was a bit surprised that this would be all we need, but
indeed everything else falls into place, when none of the newer SoCs are
used.
Regression-tested on an H616.
> SPI boot was tested on a custom board with a Gigadevice GD25Q64 8MiB
> SPI flash.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arch/arm/mach-sunxi/Kconfig | 2 +-
> arch/arm/mach-sunxi/spl_spi_sunxi.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index ddf9414b08e..17666814c52 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1078,7 +1078,7 @@ config SPL_STACK_R_ADDR
>
> config SPL_SPI_SUNXI
> bool "Support for SPI Flash on Allwinner SoCs in SPL"
> - depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUNXI_H3_H5
> || MACH_SUN50I || MACH_SUN8I_R40 || SUN50I_GEN_H6 || MACH_SUNIV ||
> SUNXI_GEN_NCAT2
> + depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUNXI_H3_H5
> || MACH_SUN50I || MACH_SUN8I_R40 || MACH_SUN8I_V3S || SUN50I_GEN_H6 ||
> MACH_SUNIV || SUNXI_GEN_NCAT2
> help
> Enable support for SPI Flash. This option allows SPL to read from
> sunxi SPI Flash. It uses the same method as the boot ROM, so does
> diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> index 7acb44f52ae..d7abdc2e401 100644
> --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> @@ -140,7 +140,8 @@ static bool is_sun6i_gen_spi(void)
> {
> return IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I) ||
> IS_ENABLED(CONFIG_SUN50I_GEN_H6) ||
> -IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2);
> +IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2) ||
> +IS_ENABLED(CONFIG_MACH_SUN8I_V3S);
> }
>
> static uintptr_t spi0_base_address(void)
[PATCH 2/2] MAINTAINERS: add usb gadget regex to u-boot-dfu tree
We try to split work with Marek on USB as following: - Mattijs handles usb gadget - Marek handles the rest of usb Add additional gadget patterns to the maintainers file so that I get cc'ed more often on USB gadget patches. Signed-off-by: Mattijs Korpershoek --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 05217db79f7e..7fd3dd85e0a9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1017,8 +1017,10 @@ F: common/update.c F: doc/api/dfu.rst F: doc/usage/dfu.rst F: drivers/dfu/ +F: drivers/usb/*/*gadget* F: drivers/usb/gadget/ F: include/dfu.h +F: include/linux/usb/gadget.h DRIVER MODEL M: Simon Glass -- 2.44.0
[PATCH 1/2] MAINTAINERS: add tree link for fastboot
Fastboot patches go through the u-boot-dfu tree. Add a link in the maintainers file for it. Signed-off-by: Mattijs Korpershoek --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6853288975c0..05217db79f7e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1118,6 +1118,7 @@ F:test/py/tests/test_event_dump.py FASTBOOT M: Mattijs Korpershoek S: Maintained +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git F: cmd/fastboot.c F: doc/android/fastboot*.rst F: include/fastboot.h -- 2.44.0
[PATCH 0/2] MAINTAINERS: updates for fastboot and usb gadget
I've noticed that I'm missing quite some usb gadget patches such as [1] since I'm not always cc'ed. With Marek, we agreed on the following split: - I take care of usb gadget side - Marek handles the rest Update the maintainers file to make sure I get included on gadget related patches. While at it, also update FASTBOOT entry to point towards the u-boot-dfu tree. [1] https://lore.kernel.org/all/20240412202611.3565052-1-alexander.sverd...@siemens.com/ Signed-off-by: Mattijs Korpershoek --- Mattijs Korpershoek (2): MAINTAINERS: add tree link for fastboot MAINTAINERS: add usb gadget regex to u-boot-dfu tree MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) --- base-commit: c8ffd1356d42223cbb8c86280a083cc3c93e6426 change-id: 20240514-gadget-maintainer-cf40fcf2bab4 Best regards, -- Mattijs Korpershoek
[GIT PULL] u-boot-riscv/master
Hi Tom,
The following changes since commit c8ffd1356d42223cbb8c86280a083cc3c93e6426:
Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"
(2024-05-13 09:15:51 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-riscv.git
for you to fetch changes up to 2b8dc36b4c515979da330a96d9fcc9bbbe5385fa:
andes: Unify naming policy for Andes related source (2024-05-14 18:50:47
+0800)
CI result shows no issue:
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/20690
- RISC-V: Add NULL check after parsing compatible string
- Board: Add Milk-V Mars CM board
- Andes: Unify naming policy
Hanyuan Zhao (1):
riscv: add NULL check before calling strlen in the riscv cpu's get_desc()
Heinrich Schuchardt (6):
board: starfive: function to read eMMC size
board: add support for Milk-V Mars CM
doc: Milk-V Mars CM and Milk-V Mars CM Lite
configs: visionfive2: enable SPL_YMODEM_SUPPORT
starfive: add mac vendor sub-command
riscv: simplify backtrace report
Leo Yu-Chi Liang (1):
andes: Unify naming policy for Andes related source
arch/riscv/Kconfig | 4 +-
arch/riscv/cpu/{andesv5 => andes}/Kconfig | 4 +-
arch/riscv/cpu/{andesv5 => andes}/Makefile | 0
arch/riscv/cpu/{andesv5 => andes}/cache.c | 12 +-
arch/riscv/cpu/{andesv5 => andes}/cpu.c| 0
arch/riscv/cpu/{andesv5 => andes}/spl.c| 0
arch/riscv/include/asm/arch-jh7110/eeprom.h| 7 +
arch/riscv/lib/interrupts.c| 16 +-
board/{AndesTech => andestech}/ae350/Kconfig | 6 +-
board/{AndesTech => andestech}/ae350/MAINTAINERS | 2 +-
board/{AndesTech => andestech}/ae350/Makefile | 0
board/{AndesTech => andestech}/ae350/ae350.c | 2 +-
board/starfive/visionfive2/Kconfig | 9 +
board/starfive/visionfive2/spl.c | 28 ++-
board/starfive/visionfive2/starfive_visionfive2.c | 11 +-
.../starfive/visionfive2/visionfive2-i2c-eeprom.c | 43 -
configs/starfive_visionfive2_defconfig | 1 +
doc/board/{AndesTech => andestech}/adp-ag101p.rst | 0
doc/board/{AndesTech => andestech}/ae350.rst | 0
doc/board/{AndesTech => andestech}/index.rst | 0
doc/board/index.rst| 2 +-
doc/board/starfive/index.rst | 3 +-
doc/board/starfive/milk-v_mars_cm.rst | 193 +
drivers/cache/Kconfig | 6 +-
drivers/cache/Makefile | 2 +-
drivers/cache/{cache-v5l2.c => cache-andes-l2.c} | 40 ++---
drivers/cpu/riscv_cpu.c| 2 +-
27 files changed, 337 insertions(+), 56 deletions(-)
rename arch/riscv/cpu/{andesv5 => andes}/Kconfig (91%)
rename arch/riscv/cpu/{andesv5 => andes}/Makefile (100%)
rename arch/riscv/cpu/{andesv5 => andes}/cache.c (90%)
rename arch/riscv/cpu/{andesv5 => andes}/cpu.c (100%)
rename arch/riscv/cpu/{andesv5 => andes}/spl.c (100%)
rename board/{AndesTech => andestech}/ae350/Kconfig (91%)
rename board/{AndesTech => andestech}/ae350/MAINTAINERS (95%)
rename board/{AndesTech => andestech}/ae350/Makefile (100%)
rename board/{AndesTech => andestech}/ae350/ae350.c (99%)
rename doc/board/{AndesTech => andestech}/adp-ag101p.rst (100%)
rename doc/board/{AndesTech => andestech}/ae350.rst (100%)
rename doc/board/{AndesTech => andestech}/index.rst (100%)
create mode 100644 doc/board/starfive/milk-v_mars_cm.rst
rename drivers/cache/{cache-v5l2.c => cache-andes-l2.c} (84%)
Best regards,
Leo
Re: [RFC 02/14] efi_loader: library function efi_dp_merge
On 5/14/24 14:58, Mark Kettenis wrote:
Date: Tue, 14 May 2024 14:49:47 +0200
From: Heinrich Schuchardt
Hi Heinrich,
On 4/26/24 17:47, Ilias Apalodimas wrote:
Hi Heinrich
On Fri, 26 Apr 2024 at 17:53, Heinrich Schuchardt
wrote:
On 26.04.24 16:30, Ilias Apalodimas wrote:
Hi Heinrich,
On Fri, 26 Apr 2024 at 17:13, Heinrich Schuchardt
wrote:
Provide a function to append a device_path to a list of device paths
that is separated by final end nodes.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_device_path.c | 31 +++
2 files changed, 34 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9600941aa32..a7d7b8324f1 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -944,6 +944,9 @@ struct efi_load_option {
struct efi_device_path *efi_dp_from_lo(struct efi_load_option *lo,
const efi_guid_t *guid);
+struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
+efi_uintn_t *size,
+const struct efi_device_path *dp2);
struct efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2,
bool split_end_node);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 46aa59b9e40..16cbe41d32f 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -270,6 +270,37 @@ struct efi_device_path *efi_dp_dup(const struct
efi_device_path *dp)
return ndp;
}
+/**
+ * efi_dp_merge() - Concatenate two device paths separated by final end node
+ *
+ * @dp1: first device path
+ * @size: pointer to length of @dp1, total size on return
+ * @dp2: second device path
+ *
+ * Return: concatenated device path or NULL
+ */
+struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
+efi_uintn_t *size,
+const struct efi_device_path *dp2)
+{
+ efi_uintn_t len, len1, len2;
+ struct efi_device_path *dp;
+ u8 *p;
+
+ len1 = *size;
+ len2 = efi_dp_size(dp2) + sizeof(END);
+ len = len1 + len2;
+ dp = efi_alloc(len);
+ if (!dp)
+ return NULL;
+ memcpy(dp, dp1, len1);
+ p = (u8 *)dp + len1;
+ memcpy(p, dp2, len2);
+ *size = len;
Can't we just use efi_dp_concat()?
efi_dp_concat cannot be used to put a device-path end-node in between
two device-paths that are concatenated. We need that separator in the
load options.
I am not sure I am following you. It's been a few years so please bear
with me until I manage to re-read that code and page it back to
memory.
What I remember though is that the format of the DP looks like this:
Loaded image DP - end node - initrd GUID DP (without and end node) -
initrd - end of device path.
So to jump from the special initrd GUID to the actual DP that contains
the initrd you need to do an efi_dp_next(). Also, efi_dp_concat() will
inject an end node with a DEVICE_PATH_SUB_TYPE_END type if the third
argument is 'true'.
What am I missing?
Let us assume
dp1 = /vmlinux/endnode/initrd/endnode
dp2 = /dtb/endnode
and we invoke dp_concat(dp1, dp2, true):
sz1 is calculated via the efi_dp_size() function which looks for the
*first* device-path end node.
sz1 = efi_dp_size(dp1) = sizeof(/vmlinux)
sz1 will not include initrd and its endnode.
So dp_concat(/vmlinux/endnode/initrd/endnode, /dtb/endnode, true)
will return:
/vmlinux/endnode/dtb/endnode
but in our boot option we want
/vmlinux/endnode/initrd/endnode/dtb/endnode
That makes me realize a potential flaw with the design of this boot
option. The concept of an initrd is Linux-specific, but the concept
of loading a DTB to pass along to an EFI image far less so. So how
would this work if I want to only pass the DTB? Would that be:
/vmlinux/endnode/endnode/dtb/endnode
Hello Mark,
We have a VenMedia() device path node with specific GUIDs for initrd and
dtb prefixed to these paths. See patch 03/14.
We don't rely on the position. So in your case:
/vmlinux/endnode/dtb/endnode
where the device path 'dtb' would consist of multiple nodes, e.g.:
VenMedia(EFI_FDT_GUID)/HD(1,GPT, ...)/\dir\filename.dtb
Best regards
Heinrich
?
[PATCH] Revert "arm: dts: bcm283x: Add minimal smbios information"
This reverts commit 33041972727e84d3f95e26c83322521f61827584.
With the ability to generate this SMBIOS details autmotically the
small amount of details that this patch provided are generated
automatically so this is now obsolete so we can just drop it.
Signed-off-by: Peter Robinson
---
arch/arm/dts/bcm283x-u-boot.dtsi | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi b/arch/arm/dts/bcm283x-u-boot.dtsi
index 8c17c6f6a52..ec0f93dd850 100644
--- a/arch/arm/dts/bcm283x-u-boot.dtsi
+++ b/arch/arm/dts/bcm283x-u-boot.dtsi
@@ -6,25 +6,6 @@
* (C) Copyright 2016 Fabian Vogt
*/
-/ {
- smbios {
- compatible = "u-boot,sysinfo-smbios";
- smbios {
- system {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- baseboard {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- chassis {
- manufacturer = "raspberrypi";
- };
- };
- };
-};
-
{
skip-init;
bootph-all;
--
2.45.0
Re: [PATCH 6/6] usb: dwc3: gadget: Disable GUSB2PHYCFG.SUSPHY for End Transfer
Hi Alexander,
Thank you for the patch.
On ven., avril 12, 2024 at 22:26, "A. Sverdlin"
wrote:
> From: Thinh Nguyen
>
> Upstream Linux commit 3aa07f72894d.
>
> If there's a disconnection while operating in eSS, there may be a delay
> in VBUS drop response from the connector. In that case, the internal
> link state may drop to operate in usb2 speed while the controller thinks
> the VBUS is still high. The driver must make sure to disable
> GUSB2PHYCFG.SUSPHY when sending endpoint command while in usb2 speed.
> The End Transfer command may be called, and only that command needs to
> go through at this point. Let's keep it simple and unconditionally
> disable GUSB2PHYCFG.SUSPHY whenever we issue the command.
>
> This scenario is not seen in real hardware. In a rare case, our
> prototype type-c controller/interface may have a slow response
> triggerring this issue.
>
> Signed-off-by: Thinh Nguyen
> Link:
> https://lore.kernel.org/r/5651117207803c26e2f22ddf4e5ce9e865dcf7c7.1668045468.git.thinh.ngu...@synopsys.com
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Alexander Sverdlin
I've dropped Greg from the cc list as I understand by [1] that he
prefers to not receives responses on this.
Reviewed-by: Mattijs Korpershoek
[1] https://lore.kernel.org/r/all/2024041354-exciting-suggest-b896@gregkh/
> ---
> drivers/usb/dwc3/gadget.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index c14d7870b9461..debfd4d6781db 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -316,7 +316,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
>*
>* DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
>*/
> - if (dwc->gadget.speed <= USB_SPEED_HIGH) {
> + if (dwc->gadget.speed <= USB_SPEED_HIGH ||
> + DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_ENDTRANSFER) {
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> saved_config |= DWC3_GUSB2PHYCFG_SUSPHY;
> --
> 2.44.0
Re: [PATCH 5/6] usb: dwc3: gadget: properly check ep cmd
Hi Alexander, Thank you for the patch. On ven., avril 12, 2024 at 22:26, "A. Sverdlin" wrote: > From: Felipe Balbi > > Upstream Linux commit 514f227b. > > The cmd argument we pass to > dwc3_send_gadget_ep_cmd() could contain extra > arguments embedded. When checking for StartTransfer > command, we need to make sure to match only lower 4 > bits which contain the actual command and ignore the > rest. > > Reported-by: Janusz Dziedzic > Signed-off-by: Felipe Balbi > [A. Sverdlin: cherry-picked only DWC3_DEPCMD_CMD() define] > Signed-off-by: Alexander Sverdlin Reviewed-by: Mattijs Korpershoek > --- > drivers/usb/dwc3/core.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h > index 1e7eda89a34c9..7709ab793f36d 100644 > --- a/drivers/usb/dwc3/core.h > +++ b/drivers/usb/dwc3/core.h > @@ -405,6 +405,8 @@ > #define DWC3_DEPCMD_SETTRANSFRESOURCE(0x02 << 0) > #define DWC3_DEPCMD_SETEPCONFIG (0x01 << 0) > > +#define DWC3_DEPCMD_CMD(x) ((x) & 0xf) > + > /* The EP number goes 0..31 so ep0 is always out and ep1 is always in */ > #define DWC3_DALEPENA_EP(n) (1 << n) > > -- > 2.44.0
Re: [RFC 02/14] efi_loader: library function efi_dp_merge
> Date: Tue, 14 May 2024 14:49:47 +0200
> From: Heinrich Schuchardt
Hi Heinrich,
> On 4/26/24 17:47, Ilias Apalodimas wrote:
> > Hi Heinrich
> >
> > On Fri, 26 Apr 2024 at 17:53, Heinrich Schuchardt
> > wrote:
> >>
> >> On 26.04.24 16:30, Ilias Apalodimas wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Fri, 26 Apr 2024 at 17:13, Heinrich Schuchardt
> >>> wrote:
>
> Provide a function to append a device_path to a list of device paths
> that is separated by final end nodes.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 3 +++
> lib/efi_loader/efi_device_path.c | 31 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9600941aa32..a7d7b8324f1 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -944,6 +944,9 @@ struct efi_load_option {
>
> struct efi_device_path *efi_dp_from_lo(struct efi_load_option *lo,
> const efi_guid_t *guid);
> +struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
> +efi_uintn_t *size,
> +const struct efi_device_path *dp2);
> struct efi_device_path *efi_dp_concat(const struct efi_device_path
> *dp1,
> const struct efi_device_path
> *dp2,
> bool split_end_node);
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 46aa59b9e40..16cbe41d32f 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -270,6 +270,37 @@ struct efi_device_path *efi_dp_dup(const struct
> efi_device_path *dp)
> return ndp;
> }
>
> +/**
> + * efi_dp_merge() - Concatenate two device paths separated by final end
> node
> + *
> + * @dp1: first device path
> + * @size: pointer to length of @dp1, total size on return
> + * @dp2: second device path
> + *
> + * Return: concatenated device path or NULL
> + */
> +struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
> +efi_uintn_t *size,
> +const struct efi_device_path *dp2)
> +{
> + efi_uintn_t len, len1, len2;
> + struct efi_device_path *dp;
> + u8 *p;
> +
> + len1 = *size;
> + len2 = efi_dp_size(dp2) + sizeof(END);
> + len = len1 + len2;
> + dp = efi_alloc(len);
> + if (!dp)
> + return NULL;
> + memcpy(dp, dp1, len1);
> + p = (u8 *)dp + len1;
> + memcpy(p, dp2, len2);
> + *size = len;
> >>>
> >>> Can't we just use efi_dp_concat()?
> >>
> >> efi_dp_concat cannot be used to put a device-path end-node in between
> >> two device-paths that are concatenated. We need that separator in the
> >> load options.
> >
> > I am not sure I am following you. It's been a few years so please bear
> > with me until I manage to re-read that code and page it back to
> > memory.
> >
> > What I remember though is that the format of the DP looks like this:
> >
> > Loaded image DP - end node - initrd GUID DP (without and end node) -
> > initrd - end of device path.
> > So to jump from the special initrd GUID to the actual DP that contains
> > the initrd you need to do an efi_dp_next(). Also, efi_dp_concat() will
> > inject an end node with a DEVICE_PATH_SUB_TYPE_END type if the third
> > argument is 'true'.
> >
> > What am I missing?
>
> Let us assume
>
> dp1 = /vmlinux/endnode/initrd/endnode
> dp2 = /dtb/endnode
>
> and we invoke dp_concat(dp1, dp2, true):
>
> sz1 is calculated via the efi_dp_size() function which looks for the
> *first* device-path end node.
>
> sz1 = efi_dp_size(dp1) = sizeof(/vmlinux)
>
> sz1 will not include initrd and its endnode.
>
> So dp_concat(/vmlinux/endnode/initrd/endnode, /dtb/endnode, true)
> will return:
>
> /vmlinux/endnode/dtb/endnode
>
> but in our boot option we want
>
> /vmlinux/endnode/initrd/endnode/dtb/endnode
That makes me realize a potential flaw with the design of this boot
option. The concept of an initrd is Linux-specific, but the concept
of loading a DTB to pass along to an EFI image far less so. So how
would this work if I want to only pass the DTB? Would that be:
/vmlinux/endnode/endnode/dtb/endnode
?
Re: [RFC 12/14] efi_loader: return binary from efi_dp_from_lo()
On 4/28/24 15:28, Ilias Apalodimas wrote:
Hi Heinrich
On Fri, 26 Apr 2024 at 17:14, Heinrich Schuchardt
wrote:
Up to now efi_dp_from_lo() only could return the initrd or fdt device-path.
Allow returning the binary device-path to.
Why do we need this?
In patch 14/14 I add this line:
+ dp = efi_get_dp_from_boot(NULL);
The binary path indicates the partition on which to search for the
default dtb as indicated by $fdtfile.
I should have added an explanation in the commit message.
Best regards
Heinrich
Thanks
/Ilias
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 75fe95c9c1e..c8893f5626b 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1140,17 +1140,18 @@ ssize_t efi_dp_check_length(const struct
efi_device_path *dp,
}
/**
- * efi_dp_from_lo() - Get the instance of a VenMedia node in a
- *multi-instance device path that matches
- *a specific GUID. This kind of device paths
- *is found in Boot options describing an
- *initrd location
+ * efi_dp_from_lo() - get device-path from load option
*
- * @lo:EFI_LOAD_OPTION containing a valid device path
- * @guid: guid to search for
+ * The load options in U-Boot may contain multiple concatenated device-paths.
+ * The first device-path indicates the EFI binary to execute. Subsequent
+ * device-paths start with a VenMedia node where the GUID identifies the
+ * function (initrd or fdt).
+ *
+ * @lo:EFI load option containing a valid device path
+ * @guid: GUID identifying device-path or NULL for the EFI binary
*
* Return:
- * device path including the VenMedia node or NULL.
+ * device path excluding the matched VenMedia node or NULL.
* Caller must free the returned value.
*/
struct
@@ -1161,6 +1162,9 @@ efi_device_path *efi_dp_from_lo(struct efi_load_option
*lo,
struct efi_device_path_vendor *vendor;
int lo_len = lo->file_path_length;
+ if (!guid)
+ return efi_dp_dup(fp);
+
for (; lo_len >= sizeof(struct efi_device_path);
lo_len -= fp->length, fp = (void *)fp + fp->length) {
if (lo_len < 0 || efi_dp_check_length(fp, lo_len) < 0)
--
2.43.0
Re: [PATCH 4/6] usb: dwc3: gadget: Check ENBLSLPM before sending ep command
Hi Alexander,
Thank you for the patch.
On ven., avril 12, 2024 at 22:26, "A. Sverdlin"
wrote:
> From: Thinh Nguyen
>
> Upstream Linux commit 87dd96111b0b.
>
> When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
> GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint
> command.
>
> Current implementation only save and restore GUSB2PHYCFG.SUSPHY
> configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and
> GUSB2PHYCFG.SUSPHY settings. Restore them after the command is
> completed.
>
> DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
>
> Signed-off-by: Thinh Nguyen
> Signed-off-by: Felipe Balbi
> Signed-off-by: Alexander Sverdlin
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/usb/dwc3/gadget.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 00845dbadd27a..c14d7870b9461 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -301,26 +301,35 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned
> ep,
> unsigned cmd, struct dwc3_gadget_ep_cmd_params *params)
> {
> u32 timeout = 500;
> + u32 saved_config = 0;
> u32 reg;
>
> - int susphy = false;
> int ret = -EINVAL;
>
> /*
> - * Synopsys Databook 2.60a states, on section 6.3.2.5.[1-8], that if
> - * we're issuing an endpoint command, we must check if
> - * GUSB2PHYCFG.SUSPHY bit is set. If it is, then we need to clear it.
> + * When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
> + * GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an
> + * endpoint command.
>*
> - * We will also set SUSPHY bit to what it was before returning as stated
> - * by the same section on Synopsys databook.
> + * Save and clear both GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY
> + * settings. Restore them after the command is completed.
> + *
> + * DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
>*/
> if (dwc->gadget.speed <= USB_SPEED_HIGH) {
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> - susphy = true;
> + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY;
> reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> }
> +
> + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) {
> + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM;
> + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
> + }
> +
> + if (saved_config)
> + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> }
>
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
> @@ -350,9 +359,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
> udelay(1);
> } while (1);
>
> - if (unlikely(susphy)) {
> + if (saved_config) {
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> - reg |= DWC3_GUSB2PHYCFG_SUSPHY;
> + reg |= saved_config;
> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> }
>
> --
> 2.44.0
Re: [PATCH 3/6] usb: dwc3: gadget: only resume USB2 PHY in <=HIGHSPEED
Hi Alexander,
Thank you for the patch.
On ven., avril 12, 2024 at 22:26, "A. Sverdlin"
wrote:
> From: Felipe Balbi
>
> Upstream Linux commit ab2a92e7a608.
>
> As a micro-power optimization, let's only resume the
> USB2 PHY if we're working on <=HIGHSPEED. If we're
> gonna work on SUPERSPEED or SUPERSPEED+, there's no
> point in resuming the USB2 PHY.
>
> Fixes: 2b0f11df84bb ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds")
> Signed-off-by: Felipe Balbi
> Signed-off-by: Alexander Sverdlin
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/usb/dwc3/gadget.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 8f6513752f085..00845dbadd27a 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -314,11 +314,13 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned
> ep,
>* We will also set SUSPHY bit to what it was before returning as stated
>* by the same section on Synopsys databook.
>*/
> - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> - if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> - susphy = true;
> - reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> + if (dwc->gadget.speed <= USB_SPEED_HIGH) {
> + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> + if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> + susphy = true;
> + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> + }
> }
>
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
> --
> 2.44.0
Re: [PATCH 2/6] usb: dwc3: gadget: clear SUSPHY bit before ep cmds
Hi Alexander,
Thank you for the patch.
On ven., avril 12, 2024 at 22:26, "A. Sverdlin"
wrote:
> From: Felipe Balbi
>
> Upstream Linux commit 2b0f11df84bb.
>
> Synopsys Databook 2.60a has a note that if we're
> sending an endpoint command we _must_ make sure that
> DWC3_GUSB2PHY(n).SUSPHY bit is cleared.
>
> This patch implements that particular detail.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Alexander Sverdlin
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/usb/dwc3/gadget.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 17c19285f1c24..8f6513752f085 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -302,8 +302,25 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned
> ep,
> {
> u32 timeout = 500;
> u32 reg;
> +
> + int susphy = false;
> int ret = -EINVAL;
>
> + /*
> + * Synopsys Databook 2.60a states, on section 6.3.2.5.[1-8], that if
> + * we're issuing an endpoint command, we must check if
> + * GUSB2PHYCFG.SUSPHY bit is set. If it is, then we need to clear it.
> + *
> + * We will also set SUSPHY bit to what it was before returning as stated
> + * by the same section on Synopsys databook.
> + */
> + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> + if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> + susphy = true;
> + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> + }
> +
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR1(ep), params->param1);
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR2(ep), params->param2);
> @@ -331,6 +348,12 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned
> ep,
> udelay(1);
> } while (1);
>
> + if (unlikely(susphy)) {
> + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> + reg |= DWC3_GUSB2PHYCFG_SUSPHY;
> + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> + }
> +
> return ret;
> }
>
> --
> 2.44.0
Re: [RFC 02/14] efi_loader: library function efi_dp_merge
On 4/26/24 17:47, Ilias Apalodimas wrote:
Hi Heinrich
On Fri, 26 Apr 2024 at 17:53, Heinrich Schuchardt
wrote:
On 26.04.24 16:30, Ilias Apalodimas wrote:
Hi Heinrich,
On Fri, 26 Apr 2024 at 17:13, Heinrich Schuchardt
wrote:
Provide a function to append a device_path to a list of device paths
that is separated by final end nodes.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_device_path.c | 31 +++
2 files changed, 34 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9600941aa32..a7d7b8324f1 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -944,6 +944,9 @@ struct efi_load_option {
struct efi_device_path *efi_dp_from_lo(struct efi_load_option *lo,
const efi_guid_t *guid);
+struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
+efi_uintn_t *size,
+const struct efi_device_path *dp2);
struct efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2,
bool split_end_node);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 46aa59b9e40..16cbe41d32f 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -270,6 +270,37 @@ struct efi_device_path *efi_dp_dup(const struct
efi_device_path *dp)
return ndp;
}
+/**
+ * efi_dp_merge() - Concatenate two device paths separated by final end node
+ *
+ * @dp1: first device path
+ * @size: pointer to length of @dp1, total size on return
+ * @dp2: second device path
+ *
+ * Return: concatenated device path or NULL
+ */
+struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
+efi_uintn_t *size,
+const struct efi_device_path *dp2)
+{
+ efi_uintn_t len, len1, len2;
+ struct efi_device_path *dp;
+ u8 *p;
+
+ len1 = *size;
+ len2 = efi_dp_size(dp2) + sizeof(END);
+ len = len1 + len2;
+ dp = efi_alloc(len);
+ if (!dp)
+ return NULL;
+ memcpy(dp, dp1, len1);
+ p = (u8 *)dp + len1;
+ memcpy(p, dp2, len2);
+ *size = len;
Can't we just use efi_dp_concat()?
efi_dp_concat cannot be used to put a device-path end-node in between
two device-paths that are concatenated. We need that separator in the
load options.
I am not sure I am following you. It's been a few years so please bear
with me until I manage to re-read that code and page it back to
memory.
What I remember though is that the format of the DP looks like this:
Loaded image DP - end node - initrd GUID DP (without and end node) -
initrd - end of device path.
So to jump from the special initrd GUID to the actual DP that contains
the initrd you need to do an efi_dp_next(). Also, efi_dp_concat() will
inject an end node with a DEVICE_PATH_SUB_TYPE_END type if the third
argument is 'true'.
What am I missing?
Let us assume
dp1 = /vmlinux/endnode/initrd/endnode
dp2 = /dtb/endnode
and we invoke dp_concat(dp1, dp2, true):
sz1 is calculated via the efi_dp_size() function which looks for the
*first* device-path end node.
sz1 = efi_dp_size(dp1) = sizeof(/vmlinux)
sz1 will not include initrd and its endnode.
So dp_concat(/vmlinux/endnode/initrd/endnode, /dtb/endnode, true)
will return:
/vmlinux/endnode/dtb/endnode
but in our boot option we want
/vmlinux/endnode/initrd/endnode/dtb/endnode
I introduced an new function efi_dp_merge().
Instead we could change the arguments to:
* @sz1:
* * 0 to concatenate
* * 1 to concatenate with end node added as separator
* * size of dp1 excluding last end node to concatenate with end node as
* separator in case dp1 contains an end node
struct
efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2,
size_t sz1)
and replace
sz1 = efi_dp_size(dp1);
by
if (sz1 < sizeof(struct efi_device_path)
sz1 = efi_dp_size(dp1);
Best regards
Heinrich
Thanks
/Ilias
Best regards
Heinrich
Thanks
/Ilias
+
+ return dp;
+}
+
/**
* efi_dp_concat() - Concatenate two device paths and add and terminate them
* with an end node.
--
2.43.0
Re: [PATCH 1/6] usb: dwc3: gadget: combine return points into a single one
Hi Alexander,
Thank you for the patch.
On ven., avril 12, 2024 at 22:26, "A. Sverdlin"
wrote:
> From: Felipe Balbi
>
> Upstream Linux commit c0ca324d09a0.
>
> dwc3_send_gadget_ep_cmd() had three return
> points. That becomes a pain to track when we need to
> debug something or if we need to add more code
> before returning.
>
> Let's combine all three return points into a single
> one just by introducing a local 'ret' variable.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Alexander Sverdlin
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/usb/dwc3/gadget.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 69d9fe40e2f87..17c19285f1c24 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -302,6 +302,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
> {
> u32 timeout = 500;
> u32 reg;
> + int ret = -EINVAL;
>
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
> dwc3_writel(dwc->regs, DWC3_DEPCMDPAR1(ep), params->param1);
> @@ -313,7 +314,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
> if (!(reg & DWC3_DEPCMD_CMDACT)) {
> dev_vdbg(dwc->dev, "Command Complete --> %d\n",
> DWC3_DEPCMD_STATUS(reg));
> - return 0;
> + ret = 0;
> + break;
> }
>
> /*
> @@ -321,11 +323,15 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned
> ep,
>* interrupt context.
>*/
> timeout--;
> - if (!timeout)
> - return -ETIMEDOUT;
> + if (!timeout) {
> + ret = -ETIMEDOUT;
> + break;
> + }
>
> udelay(1);
> } while (1);
> +
> + return ret;
> }
>
> static dma_addr_t dwc3_trb_dma_offset(struct dwc3_ep *dep,
> --
> 2.44.0
Re: Distro Boot instructions with examples
Thanks for your suggestions. I read the docs and it seems that maybe the standard boot procedure is a bit too much, the current u-boot config for raspberry pi CM4 is very simple and I'd like to keep it that way. By default the u-boot environment on CM4 is kept on the boot FAT partition. Would it be a good solution to simply copy all the CM4 related (but not u-boot) files like the kernel image, the device trees and the rpi config files (config.txt, cmdline.txt) to the rootfs partition and only tell u-boot that they are available there? I suppose that the files *.elf files should also stay on the /boot partition along with the uboot.env. Best regards, Antoni On Tue, May 7, 2024 at 5:46 PM Mark Kettenis wrote: > > From: Igor Opaniuk > > Date: Tue, 7 May 2024 16:30:17 +0200 > > > > Hello Antoni, > > > > On Tue, May 7, 2024 at 4:14 PM Antoni Jankowski > > wrote: > > > > > > Hi, > > > > > > I've recently learned about the Distro Boot feature of u-boot. This > sounds > > > interesting, however the official instructions are sparse and examples > seem > > > to be non-existent. > > > > > > The platform I'm working with at the moment is a raspberry pi CM4, are > > > there any examples of how to implement this concept? Distro Boot seems > to > > > be suitable for updating all the rootfs at once, including what > usually is > > > a separate boot partition. > > > > > > Best regards, > > > Antoni > > > > There is a nice manual from Toradex about Distro Boot integration [1]. > > You can also find a bunch of examples of integration of existing boards > > just by grep-ing: > > > > u-boot.git$ grep -ine "config_distro_bootcmd" -r ./include/configs/ > > ./include/configs/pico-imx6ul.h:86:#include > > ./include/configs/kp_imx6q_tpc.h:84:#include > > ./include/configs/imx8mp_venice.h:21:#include > > ./include/configs/stm32f746-disco.h:30:#include > > ... > > > > Hope this helps. > > > > [1] > https://developer.toradex.com/linux-bsp/os-development/boot/distro-boot/ > > However, "distro boot" is being superseded by "standard boot" in > recent versions of U-Boot and the raspberry pi boards have already > moved on. See doc/develop/bootstd.rst for some documentation on > "standard boot". >
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
Hello all,
On 2024-05-14 01:02, Marek Vasut wrote:
On 5/13/24 10:52 PM, Tim Harvey wrote:
On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
On 4/29/24 6:48 PM, Tim Harvey wrote:
On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
On 4/27/24 2:11 AM, Tim Harvey wrote:
[...]
diff --git a/include/mmc.h b/include/mmc.h
index 4b8327f1f93b..7243bd761202 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -381,6 +381,21 @@ enum mmc_voltage {
#define MMC_TIMING_MMC_HS2009
#define MMC_TIMING_MMC_HS40010
+/* emmc hardware partition values */
+enum emmc_hwpart {
+ EMMC_HWPART_DEFAULT = 0,
One more thing ... eMMC hardware partition 0 and 7 are both
referring to
USER HW partition. Have a look at the git log, there have been
patches
which handled this case in the MMC subsystem from about a year ago.
I can't find what you are referring to. I assume you are talking
about
calling the first name something other than 'user' as technically
it's
not (but it gets treated as user).
Can you find the commit or discussion you are thinking about?
It seems this whole thing is much older:
7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
CONFIG_SPL_FRAMEWORK")
+* We need to check what the partition is configured
to.
+* 1 and 2 match up to boot0 / boot1 and 7 is user
data
+* which is the first physical partition (0).
+*/
+ int part = (mmc->part_config >> 3) &
PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
Sorry, I haven't been able to work on U-Boot for the past week or so
and am just getting back to this.
No worries.
I'm glad you pointed this out as it made me aware that there is a bit
of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
I'm going to add an enumerated type for each and update the various
places where a 'conversion' as above is done but I'm still a bit torn
on naming conventions.
Consider the following:
- the eMMC spec refers to boot partitions and gp partitions as 1 based
- the Linux kernel device names for these are 0 based
- U-Boot does not currently refer to the boot devices by names but
does currently refer to the gp's by names using 1-based names (the
'mmc hwpartition' command)
Personally I would like to name the boot partitions 'boot0' and
'boot1' to match Linux but I think I should name the gp's
'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
command.
What do you think?
I agree.
Maybe you could also check this with Ulf (Linux MMC maintainer) and
Avri (mmc-utils), both on To:, so we would be consistent and in sync ?
As I promised earlier, I went through a few JEDEC standards and some
publicly available JEDEC documents and presentations, and my conclusion
is that no official numbering scheme for the partitions seems to be
defined there.
However, I'd propose that we keep "boot0" and "boot1", because that's
pretty much become a de facto standard, and also switch to using "gp0"
through "gp3" for the general-purpose partitions. That switch might
be some kind of a backward-incompatible change, but it would follow
the names of the corresponding GP_SIZE_MULT_GP0 ... GP_SIZE_MULT_GP3
fields in the EXT_CSD register, as defined by JEDEC, and it would also
be more consistent with the numbering of the boot partitions.
Though, general-purpose partitions are mentioned as GPP1 ... GPP4 in
one place in the JEDEC standard, which just confirms that no official
numbering scheme seems to be defined. Moreover, the boot partitions
are more than once referred to as "boot partition 1" and "boot partition
2" in the JEDEC standard, which means we're already not following the
standard with "boot0" and "boot1".
Frankly, it's all a bit contradictory and confusing, but I think that
the increased consistency would outweigh the backward-incompatible
downside of the switch to "gp0" through "gp3".
Re: [PATCH 2/2] net: sun8i_emac: add support for the V3s
On Mon, 13 May 2024 22:56:09 +0200
Michael Walle wrote:
Hi,
> Add the compatible string for the emac found on the V3s SoC. The SoC
> only supports the internal PHY. There are no (R)MII signals on any pins.
>
> Signed-off-by: Michael Walle
Nice, that seems indeed all we need for that SoC.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> drivers/net/sun8i_emac.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 8bff4fe9a9e..94bcd40acb8 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -893,6 +893,11 @@ static const struct emac_variant emac_variant_r40 = {
> .syscon_offset = 0x164,
> };
>
> +static const struct emac_variant emac_variant_v3s = {
> + .syscon_offset = 0x30,
> + .soc_has_internal_phy = true,
> +};
> +
> static const struct emac_variant emac_variant_a64 = {
> .syscon_offset = 0x30,
> .support_rmii = true,
> @@ -910,6 +915,8 @@ static const struct udevice_id sun8i_emac_eth_ids[] = {
> .data = (ulong)_variant_h3 },
> { .compatible = "allwinner,sun8i-r40-gmac",
> .data = (ulong)_variant_r40 },
> + { .compatible = "allwinner,sun8i-v3s-emac",
> + .data = (ulong)_variant_v3s },
> { .compatible = "allwinner,sun50i-a64-emac",
> .data = (ulong)_variant_a64 },
> { .compatible = "allwinner,sun50i-h6-emac",
[PATCH v2 3/3] arm: dts: drop downstream IPQ4019 DTSI
We want to use OF_UPSTREAM on IPQ40XX as its well supported upstream, so
lets drop our downstream DTSI.
Signed-off-by: Robert Marko
Acked-by: Caleb Connolly
---
arch/arm/dts/qcom-ipq4019.dtsi | 202 -
1 file changed, 202 deletions(-)
delete mode 100644 arch/arm/dts/qcom-ipq4019.dtsi
diff --git a/arch/arm/dts/qcom-ipq4019.dtsi b/arch/arm/dts/qcom-ipq4019.dtsi
deleted file mode 100644
index f9489e42ea..00
--- a/arch/arm/dts/qcom-ipq4019.dtsi
+++ /dev/null
@@ -1,202 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2019 Sartura Ltd.
- *
- * Author: Robert Marko
- */
-
- /dts-v1/;
-
-#include "skeleton.dtsi"
-#include
-#include
-#include
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- model = "Qualcomm Technologies, Inc. IPQ4019";
- compatible = "qcom,ipq4019";
-
- aliases {
- serial0 = _uart1;
- spi0 = _spi1;
- };
-
- reserved-memory {
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges;
-
- smem_mem: smem_region: smem@87e0 {
- reg = <0x87e0 0x08>;
- no-map;
- };
-
- tz@87e8 {
- reg = <0x87e8 0x18>;
- no-map;
- };
- };
-
- smem {
- compatible = "qcom,smem";
- memory-region = <_mem>;
- };
-
- soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
- compatible = "simple-bus";
-
- gcc: clock-controller@180 {
- compatible = "qcom,gcc-ipq4019";
- reg = <0x180 0x6>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- bootph-all;
- };
-
- rng: rng@22000 {
- compatible = "qcom,prng";
- reg = <0x22000 0x140>;
- clocks = < GCC_PRNG_AHB_CLK>;
- status = "disabled";
- };
-
- soc_gpios: pinctrl@100 {
- compatible = "qcom,ipq4019-pinctrl";
- reg = <0x100 0x30>;
- gpio-controller;
- gpio-count = <100>;
- gpio-bank-name="soc";
- #gpio-cells = <2>;
- bootph-all;
- };
-
- blsp1_uart1: serial@78af000 {
- compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
- reg = <0x78af000 0x200>;
- clock = < GCC_BLSP1_UART1_APPS_CLK>;
- bit-rate = <0xFF>;
- status = "disabled";
- bootph-all;
- };
-
- blsp1_spi1: spi@78b5000 {
- compatible = "qcom,spi-qup-v2.2.1";
- reg = <0x78b5000 0x600>;
- clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "disabled";
- bootph-all;
- };
-
- mdio: mdio@9 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "qcom,ipq4019-mdio";
- reg = <0x9 0x64>;
- status = "disabled";
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-
- ethphy1: ethernet-phy@1 {
- reg = <1>;
- };
-
- ethphy2: ethernet-phy@2 {
- reg = <2>;
- };
-
- ethphy3: ethernet-phy@3 {
- reg = <3>;
- };
-
- ethphy4: ethernet-phy@4 {
- reg = <4>;
- };
- };
-
- usb3_ss_phy: ssphy@9a000 {
- compatible = "qcom,usb-ss-ipq4019-phy";
- #phy-cells = <0>;
- reg = <0x9a000 0x800>;
- reg-names = "phy_base";
- resets = < USB3_UNIPHY_PHY_ARES>;
- reset-names = "por_rst";
- status = "disabled";
- };
-
- usb3_hs_phy: hsphy@a6000 {
- compatible = "qcom,usb-hs-ipq4019-phy";
- #phy-cells = <0>;
- reg = <0xa6000 0x40>;
- reg-names = "phy_base";
- resets =
[PATCH v2 1/3] mach-ipq40xx: add CPU specific code
Provide basic DRAM info population from DT, cache setting and the
board_init stub.
Signed-off-by: Robert Marko
Acked-by: Caleb Connolly
---
Changes in v2:
* Drop
arch/arm/mach-ipq40xx/Makefile | 7 ++
arch/arm/mach-ipq40xx/cpu.c| 43 ++
2 files changed, 50 insertions(+)
create mode 100644 arch/arm/mach-ipq40xx/Makefile
create mode 100644 arch/arm/mach-ipq40xx/cpu.c
diff --git a/arch/arm/mach-ipq40xx/Makefile b/arch/arm/mach-ipq40xx/Makefile
new file mode 100644
index 00..d611de9933
--- /dev/null
+++ b/arch/arm/mach-ipq40xx/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2024 Sartura Ltd.
+#
+# Author: Robert Marko
+
+obj-y += cpu.o
diff --git a/arch/arm/mach-ipq40xx/cpu.c b/arch/arm/mach-ipq40xx/cpu.c
new file mode 100644
index 00..92c34d6111
--- /dev/null
+++ b/arch/arm/mach-ipq40xx/cpu.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CPU code for Qualcomm IPQ40xx SoC
+ *
+ * Copyright (c) 2024 Sartura Ltd.
+ *
+ * Author: Robert Marko
+ */
+
+#include
+#include
+
+int dram_init(void)
+{
+ int ret;
+
+ ret = fdtdec_setup_memory_banksize();
+ if (ret)
+ return ret;
+ return fdtdec_setup_mem_size_base();
+}
+
+/*
+ * Enable/Disable D-cache.
+ * I-cache is already enabled in start.S
+ */
+void enable_caches(void)
+{
+ dcache_enable();
+}
+
+void disable_caches(void)
+{
+ dcache_disable();
+}
+
+/*
+ * In case boards need specific init code, they can override this stub.
+ */
+int __weak board_init(void)
+{
+ return 0;
+}
--
2.45.0
[PATCH v2 2/3] mach-ipq40xx: use OF_UPSTREAM
Now that drivers are compatible enough with the upstream DTS, there is no reason to not use the upstream DTS, so imply OF_UPSTREAM by default. Signed-off-by: Robert Marko Acked-by: Caleb Connolly --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 39ad03acd2..914a7552b4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -769,6 +769,7 @@ config ARCH_IPQ40XX select CLK_QCOM_IPQ4019 select PINCTRL_QCOM_IPQ4019 imply CMD_DM + imply OF_UPSTREAM config ARCH_KEYSTONE bool "TI Keystone" -- 2.45.0
Re: [PATCH 1/2] clk: sunxi: add EMAC and EPHY clocks and resets for the V3s SoC
On Mon, 13 May 2024 22:56:08 +0200
Michael Walle wrote:
Hi,
> Add the clock gate registers as well as the reset register bits for the
> EMAC and EPHY for the V3s. These are needed by the sun8i network driver.
>
> Signed-off-by: Michael Walle
Compared against the manual and the Linux driver:
Reviewed-by: Andre Przywara
Thanks!
Andre
> ---
> drivers/clk/sunxi/clk_v3s.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/clk/sunxi/clk_v3s.c b/drivers/clk/sunxi/clk_v3s.c
> index 6524c13540e..0402d5ed190 100644
> --- a/drivers/clk/sunxi/clk_v3s.c
> +++ b/drivers/clk/sunxi/clk_v3s.c
> @@ -17,6 +17,7 @@ static struct ccu_clk_gate v3s_gates[] = {
> [CLK_BUS_MMC0] = GATE(0x060, BIT(8)),
> [CLK_BUS_MMC1] = GATE(0x060, BIT(9)),
> [CLK_BUS_MMC2] = GATE(0x060, BIT(10)),
> + [CLK_BUS_EMAC] = GATE(0x060, BIT(17)),
> [CLK_BUS_SPI0] = GATE(0x060, BIT(20)),
> [CLK_BUS_OTG] = GATE(0x060, BIT(24)),
>
> @@ -31,6 +32,8 @@ static struct ccu_clk_gate v3s_gates[] = {
> [CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
> [CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
>
> + [CLK_BUS_EPHY] = GATE(0x070, BIT(0)),
> +
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
>
> [CLK_USB_PHY0] = GATE(0x0cc, BIT(8)),
> @@ -45,12 +48,15 @@ static struct ccu_reset v3s_resets[] = {
> [RST_BUS_MMC0] = RESET(0x2c0, BIT(8)),
> [RST_BUS_MMC1] = RESET(0x2c0, BIT(9)),
> [RST_BUS_MMC2] = RESET(0x2c0, BIT(10)),
> + [RST_BUS_EMAC] = RESET(0x2c0, BIT(17)),
> [RST_BUS_SPI0] = RESET(0x2c0, BIT(20)),
> [RST_BUS_OTG] = RESET(0x2c0, BIT(24)),
>
> [RST_BUS_TCON0] = RESET(0x2c4, BIT(4)),
> [RST_BUS_DE]= RESET(0x2c4, BIT(12)),
>
> + [RST_BUS_EPHY] = RESET(0x2c8, BIT(2)),
> +
> [RST_BUS_I2C0] = RESET(0x2d8, BIT(0)),
> [RST_BUS_I2C1] = RESET(0x2d8, BIT(1)),
> [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
[PATCH v3] sysreset: add Qualcomm PSHOLD reset driver
Number of Qualcomm ARMv7 SoC-s did not use PSCI but rather used PSHOLD
(Qualcomm Power Supply Hold Reset) bit to trigger reset or poweroff.
Qualcomm IPQ40XX is one of them, so provide a simple sysreset driver based
on the upstream Linux one, it is DT compatible as well.
Signed-off-by: Robert Marko
Reviewed-by: Caleb Connolly
---
Changes in v3:
* Drop
Changes in v2:
* Use QCOM instead of MSM naming
drivers/sysreset/Kconfig| 6 +++
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_qcom-pshold.c | 55 +
3 files changed, 62 insertions(+)
create mode 100644 drivers/sysreset/sysreset_qcom-pshold.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index b64bfadb20..121194e441 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -240,6 +240,12 @@ config SYSRESET_RAA215300
help
Add support for the system reboot via the Renesas RAA215300 PMIC.
+config SYSRESET_QCOM_PSHOLD
+ bool "Support sysreset for Qualcomm SoCs via PSHOLD"
+ depends on ARCH_IPQ40XX
+ help
+ Add support for the system reboot on Qualcomm SoCs via PSHOLD.
+
endif
endmenu
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index d59299aa31..a6a0584585 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -29,4 +29,5 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
obj-$(CONFIG_$(SPL_TPL_)SYSRESET_AT91) += sysreset_at91.o
obj-$(CONFIG_$(SPL_TPL_)SYSRESET_X86) += sysreset_x86.o
obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
+obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
diff --git a/drivers/sysreset/sysreset_qcom-pshold.c
b/drivers/sysreset/sysreset_qcom-pshold.c
new file mode 100644
index 00..4529047853
--- /dev/null
+++ b/drivers/sysreset/sysreset_qcom-pshold.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm PSHOLD reset driver
+ *
+ * Copyright (c) 2024 Sartura Ltd.
+ *
+ * Author: Robert Marko
+ * Based on the Linux msm-poweroff driver.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+struct qcom_pshold_priv {
+ phys_addr_t base;
+};
+
+static int qcom_pshold_request(struct udevice *dev, enum sysreset_t type)
+{
+ struct qcom_pshold_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->base);
+ mdelay(1);
+
+ return 0;
+}
+
+static struct sysreset_ops qcom_pshold_ops = {
+ .request = qcom_pshold_request,
+};
+
+static int qcom_pshold_probe(struct udevice *dev)
+{
+ struct qcom_pshold_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr(dev);
+ return priv->base == FDT_ADDR_T_NONE ? -EINVAL : 0;
+}
+
+static const struct udevice_id qcom_pshold_ids[] = {
+ { .compatible = "qcom,pshold", },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(qcom_pshold) = {
+ .name = "qcom_pshold",
+ .id = UCLASS_SYSRESET,
+ .of_match = qcom_pshold_ids,
+ .probe = qcom_pshold_probe,
+ .priv_auto = sizeof(struct qcom_pshold_priv),
+ .ops= _pshold_ops,
+};
--
2.45.0
Re: [PATCH 1/1] riscv: add NULL check before calling strlen in the riscv cpu's get_desc()
On Mon, May 06, 2024 at 05:10:06PM +0800, Hanyuan Zhao wrote: > Without the NULL check, if the devicetree that u-boot loads does not have a > compatible property then a store access fault will be raised and force the > machine to reset, due to the NULL pointer we passed to strlen. This commit > adds this check and will return -ENOSPC to indicate the get_desc failed. > > Signed-off-by: Hanyuan Zhao > --- > drivers/cpu/riscv_cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Hi, On Fri, 03 May 2024 09:00:38 +0200, Benjamin Hahn wrote: > Set CONFIG_USB_GADGET_MANUFACTURER to PHYTEC for all PHYTEC boards. > > Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu (u-boot-dfu) [1/1] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/371b379edbf3488d77bc321dc5d2a0e22e067744 -- Mattijs
Re: [PATCH 1/1] riscv: simplify backtrace report
On Tue, May 14, 2024 at 07:51:42AM +0200, Heinrich Schuchardt wrote: > * We already have a header 'backtrace', there is no need to repeat the > word backtrace on every line. > * Add a blank line before the backtrace section of the crash report for > improved readability. > * If U-Boot is compiled without backtrace, there is no need to write a > message at all. > * Avoid #ifdef. We prefer functions to always be compiled and let > the linker remove them if not needed. > * Foresee 3 digits for the backtrace index. > > For testing the 'exception' command can be used. > > Signed-off-by: Heinrich Schuchardt > --- > arch/riscv/lib/interrupts.c | 16 +--- > 1 file changed, 5 insertions(+), 11 deletions(-) Reviewed-by: Leo Yu-Chi Liang
[PATCH v3 1/1] andes: Unify naming policy for Andes related source
Signed-off-by: Leo Yu-Chi Liang
---
arch/riscv/Kconfig| 4 +-
arch/riscv/cpu/{andesv5 => andes}/Kconfig | 4 +-
arch/riscv/cpu/{andesv5 => andes}/Makefile| 0
arch/riscv/cpu/{andesv5 => andes}/cache.c | 12 +++---
arch/riscv/cpu/{andesv5 => andes}/cpu.c | 0
arch/riscv/cpu/{andesv5 => andes}/spl.c | 0
board/{AndesTech => andestech}/ae350/Kconfig | 6 +--
.../ae350/MAINTAINERS | 2 +-
board/{AndesTech => andestech}/ae350/Makefile | 0
board/{AndesTech => andestech}/ae350/ae350.c | 2 +-
doc/board/index.rst | 2 +-
drivers/cache/Kconfig | 6 +--
drivers/cache/Makefile| 2 +-
.../cache/{cache-v5l2.c => cache-andes-l2.c} | 40 +--
14 files changed, 40 insertions(+), 40 deletions(-)
rename arch/riscv/cpu/{andesv5 => andes}/Kconfig (91%)
rename arch/riscv/cpu/{andesv5 => andes}/Makefile (100%)
rename arch/riscv/cpu/{andesv5 => andes}/cache.c (90%)
rename arch/riscv/cpu/{andesv5 => andes}/cpu.c (100%)
rename arch/riscv/cpu/{andesv5 => andes}/spl.c (100%)
rename board/{AndesTech => andestech}/ae350/Kconfig (91%)
rename board/{AndesTech => andestech}/ae350/MAINTAINERS (95%)
rename board/{AndesTech => andestech}/ae350/Makefile (100%)
rename board/{AndesTech => andestech}/ae350/ae350.c (99%)
rename drivers/cache/{cache-v5l2.c => cache-andes-l2.c} (84%)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 7e20ef63bb..fa3b016c52 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -80,7 +80,7 @@ config SPL_ZERO_MEM_BEFORE_USE
Sifive core devices that uses L2 cache to store SPL.
# board-specific options below
-source "board/AndesTech/ae350/Kconfig"
+source "board/andestech/ae350/Kconfig"
source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
source "board/openpiton/riscv64/Kconfig"
@@ -93,7 +93,7 @@ source "board/thead/th1520_lpi4a/Kconfig"
source "board/xilinx/mbv/Kconfig"
# platform-specific options below
-source "arch/riscv/cpu/andesv5/Kconfig"
+source "arch/riscv/cpu/andes/Kconfig"
source "arch/riscv/cpu/cv1800b/Kconfig"
source "arch/riscv/cpu/fu540/Kconfig"
source "arch/riscv/cpu/fu740/Kconfig"
diff --git a/arch/riscv/cpu/andesv5/Kconfig b/arch/riscv/cpu/andes/Kconfig
similarity index 91%
rename from arch/riscv/cpu/andesv5/Kconfig
rename to arch/riscv/cpu/andes/Kconfig
index e3efb0de8f..120fec5e54 100644
--- a/arch/riscv/cpu/andesv5/Kconfig
+++ b/arch/riscv/cpu/andes/Kconfig
@@ -1,4 +1,4 @@
-config RISCV_NDS
+config RISCV_ANDES
bool
select ARCH_EARLY_INIT_R
select SYS_CACHE_SHIFT_6
@@ -8,7 +8,7 @@ config RISCV_NDS
imply ANDES_PLMT_TIMER
imply SPL_ANDES_PLMT_TIMER
imply ANDES_PLICSW if (RISCV_MMODE || SPL_RISCV_MMODE)
- imply V5L2_CACHE
+ imply ANDES_L2_CACHE
imply SPL_CPU
imply SPL_OPENSBI
imply SPL_LOAD_FIT
diff --git a/arch/riscv/cpu/andesv5/Makefile b/arch/riscv/cpu/andes/Makefile
similarity index 100%
rename from arch/riscv/cpu/andesv5/Makefile
rename to arch/riscv/cpu/andes/Makefile
diff --git a/arch/riscv/cpu/andesv5/cache.c b/arch/riscv/cpu/andes/cache.c
similarity index 90%
rename from arch/riscv/cpu/andesv5/cache.c
rename to arch/riscv/cpu/andes/cache.c
index 269bb27f75..7d3df8722d 100644
--- a/arch/riscv/cpu/andesv5/cache.c
+++ b/arch/riscv/cpu/andes/cache.c
@@ -12,21 +12,21 @@
#include
#include
-#ifdef CONFIG_V5L2_CACHE
+#ifdef CONFIG_ANDES_L2_CACHE
void enable_caches(void)
{
struct udevice *dev;
int ret;
ret = uclass_get_device_by_driver(UCLASS_CACHE,
- DM_DRIVER_GET(v5l2_cache),
+ DM_DRIVER_GET(andes_l2_cache),
);
if (ret) {
- log_debug("Cannot enable v5l2 cache\n");
+ log_debug("Cannot enable Andes L2 cache\n");
} else {
ret = cache_enable(dev);
if (ret)
- log_debug("v5l2 cache enable failed\n");
+ log_debug("Failed to enable Andes L2 cache\n");
}
}
@@ -78,7 +78,7 @@ void dcache_enable(void)
asm volatile("csrsi %0, 0x2" :: "i"(CSR_MCACHE_CTL));
#endif
-#ifdef CONFIG_V5L2_CACHE
+#ifdef CONFIG_ANDES_L2_CACHE
cache_ops(cache_enable);
#endif
}
@@ -89,7 +89,7 @@ void dcache_disable(void)
asm volatile("csrci %0, 0x2" :: "i"(CSR_MCACHE_CTL));
#endif
-#ifdef CONFIG_V5L2_CACHE
+#ifdef CONFIG_ANDES_L2_CACHE
cache_ops(cache_disable);
#endif
}
diff --git a/arch/riscv/cpu/andesv5/cpu.c b/arch/riscv/cpu/andes/cpu.c
similarity index 100%
rename from arch/riscv/cpu/andesv5/cpu.c
rename to arch/riscv/cpu/andes/cpu.c
diff --git a/arch/riscv/cpu/andesv5/spl.c b/arch/riscv/cpu/andes/spl.c
similarity index 100%
rename from arch/riscv/cpu/andesv5/spl.c
[PULL] Please pull qcom/qcom-main
Hi Tom, This patch for master fixes framebuffer video on almost all Qualcomm platforms where the framebuffer is initialised by the first stage bootloader. The following changes since commit 5c5565cfec92eb7377ff7fe197612c6a813bb6c7: Merge patch series "arm: davinci: Migrate da850-evm to OF_UPSTREAM" (2024-05-07 11:59:26 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-snapdragon.git qcom-main for you to fetch changes up to 3ceaa825869bd43e9a2ec00a90589cc84885bd40: mach-snapdragon: do carveouts for qcs404 only (2024-05-14 09:00:41 +0200) Sam Day (1): mach-snapdragon: do carveouts for qcs404 only arch/arm/mach-snapdragon/board.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-)
