Re: [PATCH 1/2] cmd: kaslrseed: add command to generate value from hwrng
Am 15. Oktober 2021 14:54:03 MESZ schrieb Kever Yang
:
>Reviewed-by: Kever Yang
>
>
>Thanks,
>- Kever
>
>Chris Morgan 于2021年8月26日周四 上午12:23写道：
>>
>> From: Chris Morgan
>>
>> Allow the kaslr-seed value in the chosen node to be set from a hardware
>> rng source.
>>
>> Tested on a Rockchip PX30 (Odroid Go Advance), you must have loaded
>> the devicetree first and prepared it for editing. On my device the
>> workflow goes as follows:
>>
>> setenv dtb_loadaddr "0x01f0"
>> load mmc 0:1 ${dtb_loadaddr} rk3326-odroid-go2.dtb
>> fdt addr ${dtb_loadaddr}
>> fdt resize
>> kaslrseed
This seems overly complicated. Why don't you add the seed in the board fixup
routines in dependence on a Kconfig symbol.
Best regards
Heinrich
>>
>> and the output can be seen here:
>> fdt print /chosen
>> chosen {
>> kaslr-seed = <0x6f61df74 0x6f7b996c>;
>> stdout-path = "serial2:115200n8";
>> };
>>
>> Signed-off-by: Chris Morgan
>> ---
>> cmd/Kconfig | 7 +
>> cmd/Makefile| 1 +
>> cmd/kaslrseed.c | 81 +
>> 3 files changed, 89 insertions(+)
>> create mode 100644 cmd/kaslrseed.c
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index ffef3cc76c..e62adff939 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -1790,6 +1790,13 @@ config CMD_RNG
>> help
>> Print bytes from the hardware random number generator.
>>
>> +config CMD_KASLRSEED
>> + bool "kaslrseed"
>> + depends on DM_RNG
>> + help
>> + Set the kaslr-seed in the chosen node with entropy provided by a
>> + hardware random number generator.
>> +
>> config CMD_SLEEP
>> bool "sleep"
>> default y
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index ed3669411e..34cbda72f5 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -131,6 +131,7 @@ obj-$(CONFIG_CMD_REGINFO) += reginfo.o
>> obj-$(CONFIG_CMD_REISER) += reiser.o
>> obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
>> obj-$(CONFIG_CMD_RNG) += rng.o
>> +obj-$(CONFIG_CMD_KASLRSEED) += kaslrseed.o
>> obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
>> obj-$(CONFIG_CMD_RTC) += rtc.o
>> obj-$(CONFIG_SANDBOX) += host.o
>> diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
>> new file mode 100644
>> index 00..27c2648c91
>> --- /dev/null
>> +++ b/cmd/kaslrseed.c
>> @@ -0,0 +1,81 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * The 'kaslrseed' command takes bytes from the hardware random number
>> + * generator and uses them to set the kaslr-seed value in the chosen node.
>> + *
>> + * Copyright (c) 2021, Chris Morgan
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static int do_kaslr_seed(struct cmd_tbl *cmdtp, int flag, int argc, char
>> *const argv[])
>> +{
>> + size_t n = 0x8;
>> + struct udevice *dev;
>> + u64 *buf;
>> + int nodeoffset;
>> + int ret = CMD_RET_SUCCESS;
>> +
>> + if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
>> + printf("No RNG device\n");
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + buf = malloc(n);
>> + if (!buf) {
>> + printf("Out of memory\n");
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + if (dm_rng_read(dev, buf, n)) {
>> + printf("Reading RNG failed\n");
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + if (!working_fdt) {
>> + printf("No FDT memory address configured. Please configure\n"
>> + "the FDT address via \"fdt addr \"
>> command.\n"
>> + "Aborting!\n");
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + ret = fdt_check_header(working_fdt);
>> + if (ret < 0) {
>> + printf("fdt_chosen: %s\n", fdt_strerror(ret));
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
>> + if (nodeoffset < 0) {
>> + printf("Reading chosen node failed\n");
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
>> sizeof(buf));
>> + if (ret < 0) {
>> + printf("Unable to set kaslr-seed on chosen node: %s\n",
>> fdt_strerror(ret));
>> + return CMD_RET_FAILURE;
>> + }
>> +
>> + free(buf);
>> +
>> + return ret;
>> +}
>> +
>> +#ifdef CONFIG_SYS_LONGHELP
>> +static char kaslrseed_help_text[] =
>> + "[n]\n"
>> + " - append random bytes to chosen kaslr-seed node\n";
>> +#endif
>> +
>> +U_BOOT_CMD(
>> + kaslrseed, 1, 0, do_kaslr_seed,
>> + "feed bytes from the hardware random number generator to the
>> kaslr-seed",
>> + kaslrseed_help_text
>> +);
>> --
>> 2.25.1
>>
Re: [PATCH v3 01/18] Create a new boot/ directory
> rename {common => boot}/image-board.c (100%)
Before accepting this series we need to fix common/image-board.c which
have mistakes!
patch there >
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
On Fri, Oct 15, 2021 at 2:48 AM Simon Glass wrote:
>
> Quite a lot of the code in common/relates to booting and images. Before
> adding more it seems like a good time to move the code into its own
> directory.
>
> Most files with 'boot' or 'image' in them are moved, except:
>
> - autoboot.c which relates to U-Boot automatically running a script
> - bootstage.c which relates to U-Boot timing
>
> Drop the removal of boot* files from the output directory, since this
> interfers with the symlinks created by tools and there does not appear
> to be any such file from my brief testing.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> Kconfig | 2 ++
> Makefile| 3 ++-
> README | 1 +
> common/Kconfig.boot => boot/Kconfig | 0
> boot/Makefile | 34 +
> {common => boot}/android_ab.c | 0
> {common => boot}/boot_fit.c | 0
> {common => boot}/bootm.c| 0
> {common => boot}/bootm_os.c | 0
> {common => boot}/bootretry.c| 0
> {common => boot}/common_fit.c | 0
> {common => boot}/fdt_region.c | 0
> {common => boot}/image-android-dt.c | 0
> {common => boot}/image-android.c| 0
> {common => boot}/image-board.c | 0
> {common => boot}/image-cipher.c | 0
> {common => boot}/image-fdt.c| 0
> {common => boot}/image-fit-sig.c| 0
> {common => boot}/image-fit.c| 0
> {common => boot}/image-host.c | 0
> {common => boot}/image-sig.c| 0
> {common => boot}/image.c| 0
> common/Kconfig | 2 --
> common/Makefile | 22 ---
> doc/android/boot-image.rst | 2 +-
> scripts/Makefile.spl| 4 ++--
> tools/Makefile | 18 +++
> 27 files changed, 51 insertions(+), 37 deletions(-)
> rename common/Kconfig.boot => boot/Kconfig (100%)
> create mode 100644 boot/Makefile
> rename {common => boot}/android_ab.c (100%)
> rename {common => boot}/boot_fit.c (100%)
> rename {common => boot}/bootm.c (100%)
> rename {common => boot}/bootm_os.c (100%)
> rename {common => boot}/bootretry.c (100%)
> rename {common => boot}/common_fit.c (100%)
> rename {common => boot}/fdt_region.c (100%)
> rename {common => boot}/image-android-dt.c (100%)
> rename {common => boot}/image-android.c (100%)
> rename {common => boot}/image-board.c (100%)
> rename {common => boot}/image-cipher.c (100%)
> rename {common => boot}/image-fdt.c (100%)
> rename {common => boot}/image-fit-sig.c (100%)
> rename {common => boot}/image-fit.c (100%)
> rename {common => boot}/image-host.c (100%)
> rename {common => boot}/image-sig.c (100%)
> rename {common => boot}/image.c (100%)
>
> diff --git a/Kconfig b/Kconfig
> index 931a22806e4..c46f4fce862 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -466,6 +466,8 @@ endmenu # General setup
>
> source "api/Kconfig"
>
> +source "boot/Kconfig"
> +
> source "common/Kconfig"
>
> source "cmd/Kconfig"
> diff --git a/Makefile b/Makefile
> index f911f703443..4e064acdcff 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -804,6 +804,7 @@ HAVE_VENDOR_COMMON_LIB = $(if $(wildcard
> $(srctree)/board/$(VENDOR)/common/Makef
>
> libs-$(CONFIG_API) += api/
> libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
> +libs-y += boot/
> libs-y += cmd/
> libs-y += common/
> libs-$(CONFIG_OF_EMBED) += dts/
> @@ -2076,7 +2077,7 @@ CLEAN_DIRS += $(MODVERDIR) \
> $(filter-out include, $(shell ls -1 $d 2>/dev/null
>
> CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h tools/version.h \
> - boot* u-boot* MLO* SPL System.map fit-dtb.blob* \
> + u-boot* MLO* SPL System.map fit-dtb.blob* \
>u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
>lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
>idbloader.img flash.bin flash.log defconfig keep-syms-lto.c
> diff --git a/README b/README
> index 840b192aae5..49c79ca6a2d 100644
> --- a/README
> +++ b/README
> @@ -144,6 +144,7 @@ Directory Hierarchy:
>/xtensa Files generic to Xtensa architecture
> /api Machine/arch-independent API for external apps
> /board Board-dependent files
> +/boot Support for images and booting
> /cmd U-Boot commands functions
> /commonMisc architecture-independent functions
> /configs Board default configuration files
> diff --git a/common/Kconfig.boot b/boot/Kconfig
> similarity
Re: [PATCH] image: fix select_ramdisk for raw initrd
Hi Simon
plz ignore this patch
proper solution problem there >
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
On Fri, Oct 15, 2021 at 6:15 PM Artem Lapkin wrote:
>
> Problem
>
> We have unbootable raw initrd images because, select_ramdisk for raw
> initrd images ignore submited select addr and setup rd_datap value to 0
>
> Solution: setup rd_datap value from select
>
> Signed-off-by: Artem Lapkin
> ---
> common/image-board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/image-board.c b/common/image-board.c
> index e7660352e9..e3c6ea806a 100644
> --- a/common/image-board.c
> +++ b/common/image-board.c
> @@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images, const
> char *select, u8 arch,
> end = strchr(select, ':');
> if (end) {
> *rd_lenp = hextoul(++end, NULL);
> - *rd_datap = rd_addr;
> + *rd_datap = hextoul(select, NULL);
> processed = true;
> }
> }
> --
> 2.25.1
>
[PATCH] image-board: fix wrong implementation ram disk address setup from cmdline
Problem
Wrong implementation logic: ramdisk cmdline image address always ignored!
Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
We have unbootable raw initrd images because, select_ramdisk for raw
initrd images ignore submited select addr and setup rd_datap value to 0
Come-from:
https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
Signed-off-by: Artem Lapkin
---
common/image-board.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/image-board.c b/common/image-board.c
index e7660352e9..e7063016ef 100644
--- a/common/image-board.c
+++ b/common/image-board.c
@@ -333,7 +333,7 @@ static int select_ramdisk(bootm_headers_t *images, const
char *select, u8 arch,
if (select) {
ulong default_addr;
- bool done = true;
+ bool done = false;
if (CONFIG_IS_ENABLED(FIT)) {
/*
@@ -351,13 +351,13 @@ static int select_ramdisk(bootm_headers_t *images, const
char *select, u8 arch,
_uname_config)) {
debug("* ramdisk: config '%s' from image at
0x%08lx\n",
fit_uname_config, rd_addr);
+ done = true;
} else if (fit_parse_subimage(select, default_addr,
_addr,
_uname_ramdisk)) {
debug("* ramdisk: subimage '%s' from image at
0x%08lx\n",
fit_uname_ramdisk, rd_addr);
- } else {
- done = false;
+ done = true;
}
}
if (!done) {
--
2.25.1
[PATCH1/1]sqfs: sqfs_tokenize() should fill the tokens list instead of free items
We can delete two lines of code to avoid double free bug, but still a wild
pointers bug.
A test for wild pointers:
sqfsls host 0 1//2/3//4/5
Fill the tokens list can solve it well.
Signed-off-by: Jincheng Wang
---
fs/squashfs/sqfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index e2d91c654c..50d3f8b71e 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -303,8 +303,9 @@ static int sqfs_tokenize(char **tokens, int count,
const char *str)
aux = strtok(!j ? strc : NULL, "/");
tokens[j] = strdup(aux);
if (!tokens[j]) {
- for (i = 0; i < j; i++)
- free(tokens[i]);
+ /* fill tokens list to avoid wild pointers being freed*/
+ for (i = j + 1; i < count; i++)
+ tokens[i] = 0;
ret = -ENOMEM;
goto free_strc;
}
--
2.27.0
[PATCH v7 7/7] bootm: Tidy up use of autostart env var
This has different semantics in different places. Go with the bootm method
and put it in a common function so that the behaviour is consistent in
U-Boot. Update the docs.
To be clear, this changes the way that 'bootelf' and standalone boot
work. Before, if autostart was set to "fred" or "YES", for example, they
would consider that a "yes". This may change behaviour for some boards,
but the only in-tree boards which mention autostart use "no" to disable
it, which will still work.
Signed-off-by: Simon Glass
Suggested-by: Wolfgang Denk
---
Changes in v7:
- Go into more detail about the change of behaviour with autostart
- Update the cover letter
Changes in v6:
- Add new patch to tidy up use of autostart env var
cmd/bootm.c | 4 +---
cmd/elf.c | 3 +--
common/bootm_os.c | 5 +
doc/usage/environment.rst | 4 ++--
env/common.c | 7 +++
include/env.h | 7 +++
6 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 92468d09a1f..b82a872a86c 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -140,9 +140,7 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd)
{
- const char *ep = env_get("autostart");
-
- if (ep && !strcmp(ep, "yes")) {
+ if (env_get_autostart()) {
char *local_args[2];
local_args[0] = (char *)cmd;
local_args[1] = NULL;
diff --git a/cmd/elf.c b/cmd/elf.c
index d75b21461c2..2b33c50bd02 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -41,7 +41,6 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
- const char *ep = env_get("autostart");
int rcode = 0;
/* Consume 'bootelf' */
@@ -69,7 +68,7 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
else
addr = load_elf_image_shdr(addr);
- if (ep && !strcmp(ep, "no"))
+ if (!env_get_autostart())
return rcode;
printf("## Starting application at 0x%08lx ...\n", addr);
diff --git a/common/bootm_os.c b/common/bootm_os.c
index 39623f9126b..f30dcebbf7d 100644
--- a/common/bootm_os.c
+++ b/common/bootm_os.c
@@ -26,12 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
static int do_bootm_standalone(int flag, int argc, char *const argv[],
bootm_headers_t *images)
{
- char *s;
int (*appl)(int, char *const[]);
- /* Don't start if "autostart" is set to "no" */
- s = env_get("autostart");
- if ((s != NULL) && !strcmp(s, "no")) {
+ if (!env_get_autostart()) {
env_set_hex("filesize", images->os.image_len);
return 0;
}
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index c4fd07aa939..1a31c157999 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -165,8 +165,8 @@ autostart
be automatically started (by internally calling
"bootm")
-If set to "no", a standalone image passed to the
-"bootm" command will be copied to the load address
+If unset, or set to anything other than "yes", a standalone image passed to
+the "bootm" command will be copied to the load address
(and eventually uncompressed), but NOT be started.
This can be used to load and uncompress arbitrary
data.
diff --git a/env/common.c b/env/common.c
index 81e9e0b2aaf..ef9502a34f7 100644
--- a/env/common.c
+++ b/env/common.c
@@ -47,6 +47,13 @@ int env_get_yesno(const char *var)
1 : 0;
}
+bool env_get_autostart(void)
+{
+ const char *val = env_get("autostart");
+
+ return val && !strcmp(val, "yes");
+}
+
/*
* Look up the variable from the default environment
*/
diff --git a/include/env.h b/include/env.h
index d5e2bcb530f..fdad495691f 100644
--- a/include/env.h
+++ b/include/env.h
@@ -143,6 +143,13 @@ int env_get_f(const char *name, char *buf, unsigned int
len);
*/
int env_get_yesno(const char *var);
+/**
+ * env_get_autostart() - Check if autostart is enabled
+ *
+ * @return true if the "autostart" env var exists and is set to "yes"
+ */
+bool env_get_autostart(void);
+
/**
* env_set() - set an environment variable
*
--
2.33.0.1079.g6e70778dc9-goog
[PATCH v7 6/7] doc: Improve environment documentation
Make various updates suggested during review of the rST conversion. Signed-off-by: Simon Glass Suggested-by: Wolfgang Denk --- Changes in v7: - A few more tweaks Changes in v6: - Move all updates to a separate patch - More updates and improvements Changes in v5: - Minor updates as suggested by Wolfgang Changes in v4: - Add new patch to move environment documentation to rST doc/usage/environment.rst | 36 +++- doc/usage/index.rst | 1 + 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst index a2410607e9f..c4fd07aa939 100644 --- a/doc/usage/environment.rst +++ b/doc/usage/environment.rst @@ -4,16 +4,20 @@ Environment Variables = U-Boot supports user configuration using Environment Variables which -can be made persistent by saving to Flash memory. +can be made persistent by saving to persistent storage, for example flash +memory. -Environment Variables are set using "setenv", printed using -"printenv", and saved to Flash using "saveenv". Using "setenv" +Environment Variables are set using "env set" (alias "setenv"), printed using +"env print" (alias "printenv"), and saved to persistent storage using +"env save" (alias "saveenv"). Using "env set" without a value can be used to delete a variable from the -environment. As long as you don't save the environment you are +environment. As long as you don't save the environment, you are working with an in-memory copy. In case the Flash area containing the environment is erased by accident, a default environment is provided. -Some configuration options can be set using Environment Variables. +Some configuration is controlled by Environment Variables, so that setting the +variable can adjust the behaviour of U-Boot (e.g. autoboot delay, autoloading +from tftp). Text-based Environment -- @@ -90,16 +94,24 @@ environment but work is underway to address this. List of environment variables - +Some configuration options can be set using Environment Variables. In many cases +the value in the default environment comes from a CONFIG option - see +`include/env_default.h`) for this. + This is most-likely not complete: baudrate -see CONFIG_BAUDRATE +Current baud rate used by the serial console. The built-in value is set by +CONFIG_BAUDRATE (see `drivers/serial/Kconfig`) bootdelay -see CONFIG_BOOTDELAY +Current autoboot delay. The built-in value is set by CONFIG_BOOTDELAY (see +`common/Kconfig`) bootcmd -see CONFIG_BOOTCOMMAND +Defines a command string that is automatically executed when no character +is read on the console interface within a cetain boot delay after reset. +The built-in value is set by CONFIG_BOOTCOMMAND (see `common/Kconfig`) bootargs Boot arguments when booting an RTOS image @@ -145,7 +157,7 @@ autoload if set to "no" (any string beginning with 'n'), "bootp" will just load perform a lookup of the configuration from the BOOTP server, but not try to -load any image using TFTP +load any image using TFTP or DHCP. autostart if set to "yes", an image loaded using the "bootp", @@ -311,6 +323,8 @@ vlan Ethernet is encapsulated/received over 802.1q VLAN tagged frames. +Note: This appears not to be used in U-Boot. See `README.VLAN`. + bootpretryperiod Period during which BOOTP/DHCP sends retries. Unsigned value, in milliseconds. If not set, the period will @@ -352,6 +366,10 @@ flash or offset in NAND flash. boards currently use other variables for these purposes, and some boards use these variables for other purposes. +Also note that most of these variables are just a commonly used set of variable +names, used in some other variable definitions, but are not hard-coded anywhere +in U-Boot code. + = == == Image File Name RAM Address Flash Location = == == diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 356f2a56181..1a79d1c03eb 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -5,6 +5,7 @@ Use U-Boot :maxdepth: 1 dfu + environment fdt_overlays fit netconsole -- 2.33.0.1079.g6e70778dc9-goog
[PATCH v7 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE
Add mention of this option this it does a similar thing to the text environment. Suggested-by: Rasmus Villemoes Signed-off-by: Simon Glass --- Changes in v7: - Add new patch to explain the relationship with DEFAULT_ENV_FILE doc/usage/environment.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst index 667fd193ea1..a2410607e9f 100644 --- a/doc/usage/environment.rst +++ b/doc/usage/environment.rst @@ -454,3 +454,18 @@ The signature of the callback functions is:: include/search.h The return value is 0 if the variable change is accepted and 1 otherwise. + + +External environment file +- + +The `CONFIG_USE_DEFAULT_ENV_FILE` option provides a way to bypass the +environment generation in U-Boot. If enabled, then `CONFIG_DEFAULT_ENV_FILE` +provides the name of a file which is converted into the environment, +completely bypassing the standard environment variables in `env_default.h`. + +The format is the same as accepted by the mkenvimage tool: lines containing +key=value pairs, blank lines and lines beginning with # are ignored. + +Future work may unify this feature with the text-based environment, perhaps +moving the contents of `env_default.h` to a text file. -- 2.33.0.1079.g6e70778dc9-goog
[PATCH v7 4/7] sandbox: Use a text-based environment
Use a text file for the environment instead of the #define settings. Signed-off-by: Simon Glass --- (no changes since v3) Changes in v3: - Add new patch to use a text-based environment for sandbox board/sandbox/sandbox.env | 25 + include/configs/sandbox.h | 29 - 2 files changed, 25 insertions(+), 29 deletions(-) create mode 100644 board/sandbox/sandbox.env diff --git a/board/sandbox/sandbox.env b/board/sandbox/sandbox.env new file mode 100644 index 000..0f8d95b8db0 --- /dev/null +++ b/board/sandbox/sandbox.env @@ -0,0 +1,25 @@ +stdin=serial +#ifdef CONFIG_SANDBOX_SDL +stdin+=,cros-ec-keyb,usbkbd +#endif +stdout=serial,vidconsole +stderr=serial,vidconsole + +ethaddr=00:00:11:22:33:44 +eth2addr=00:00:11:22:33:48 +eth3addr=00:00:11:22:33:45 +eth4addr=00:00:11:22:33:48 +eth5addr=00:00:11:22:33:46 +eth6addr=00:00:11:22:33:47 +ipaddr=1.2.3.4 + +/* + * These are used for distro boot which is not supported. But once bootmethod + * is provided these will be used again. + */ +bootm_size=0x1000 +kernel_addr_r=0x100 +fdt_addr_r=0xc0 +ramdisk_addr_r=0x200 +scriptaddr=0x1000 +pxefile_addr_r=0x2000 diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index c19232f202f..c703a1330c0 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -64,37 +64,8 @@ #define CONFIG_LCD_BMP_RLE8 #define CONFIG_KEYBOARD - -#define SANDBOX_SERIAL_SETTINGS "stdin=serial,cros-ec-keyb,usbkbd\0" \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" -#else -#define SANDBOX_SERIAL_SETTINGS"stdin=serial\0" \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" #endif -#define SANDBOX_ETH_SETTINGS "ethaddr=00:00:11:22:33:44\0" \ - "eth2addr=00:00:11:22:33:48\0" \ - "eth3addr=00:00:11:22:33:45\0" \ - "eth4addr=00:00:11:22:33:48\0" \ - "eth5addr=00:00:11:22:33:46\0" \ - "eth6addr=00:00:11:22:33:47\0" \ - "ipaddr=1.2.3.4\0" - -#define MEM_LAYOUT_ENV_SETTINGS \ - "bootm_size=0x1000\0" \ - "kernel_addr_r=0x100\0" \ - "fdt_addr_r=0xc0\0" \ - "ramdisk_addr_r=0x200\0" \ - "scriptaddr=0x1000\0" \ - "pxefile_addr_r=0x2000\0" - -#define CONFIG_EXTRA_ENV_SETTINGS \ - SANDBOX_SERIAL_SETTINGS \ - SANDBOX_ETH_SETTINGS \ - MEM_LAYOUT_ENV_SETTINGS - #ifndef CONFIG_SPL_BUILD #define CONFIG_SYS_IDE_MAXBUS 1 #define CONFIG_SYS_ATA_IDE0_OFFSET 0 -- 2.33.0.1079.g6e70778dc9-goog
[PATCH v7 3/7] env: Allow U-Boot scripts to be placed in a .env file
At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. Add a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board//env directory called .env (or common.env if you want the same environment for all boards). The environment variables should be of the form "var=value". Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. In many cases environment variables need access to the U-Boot CONFIG variables to select different options. Enable this so that the environment scripts can be as useful as the ones currently in the board config files. This uses the C preprocessor, means that comments can be included in the environment using /* ... */ Also support += to allow variables to be appended to. This is needed when using the preprocessor. Signed-off-by: Simon Glass --- Changes in v7: - Use 'env' basename instead of 'environment' for intermediate output files - Show a message indicating the source text file being used - Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined - Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name - Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty - Rewrite the documentation - Drop the use of common.env - Update awk script to output the whole CONFIG string, or just a comment Changes in v6: - Combine the two env2string.awk patches into one Changes in v5: - Explain how to include the common.env file - Explain why variables starting with _ , and / are not supported - Expand the definition of how to declare an environment variable - Explain what happens to empty variables - Update maintainer - Move use of += to this patch - Explain that environment variables may not end in + Changes in v4: - Move this from being part of configuring U-Boot to part of building it - Don't put the environment in autoconf.mk as it is not needed - Add documentation in rST format instead of README - Drop mention of import/export - Update awk script to ignore blank lines, as generated by clang - Add documentation in rST format instead of README Changes in v3: - Adjust Makefile to generate the .inc and .h files in separate fules - Add more detail in the README about the format of .env files - Improve the comment about " in the awk script - Correctly terminate environment files with \n - Define __UBOOT_CONFIG__ when collecting environment files Changes in v2: - Move .env file from include/configs to board/ - Use awk script to process environment since it is much easier on the brain - Add information and updated example script to README - Add dependency rule so that the environment is rebuilt when it changes - Add separate patch to enable C preprocessor for environment files - Enable var+=value form to simplify composing variables in multiple steps MAINTAINERS | 7 Makefile | 66 - config.mk | 2 + doc/usage/environment.rst | 77 ++- env/Kconfig | 18 + env/embedded.c| 1 + include/env_default.h | 11 ++ scripts/env2string.awk| 63 8 files changed, 243 insertions(+), 2 deletions(-) create mode 100644 scripts/env2string.awk diff --git a/MAINTAINERS b/MAINTAINERS index 71f468c00a8..36846528368 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -738,6 +738,13 @@ F: test/env/ F: tools/env* F: tools/mkenvimage.c +ENVIRONMENT AS TEXT +M: Simon Glass +R: Wolfgang Denk +S: Maintained +F: doc/usage/environment.rst +F: scripts/env2string.awk + FPGA M: Michal Simek S: Maintained diff --git a/Makefile b/Makefile index f911f703443..ba99a644b63 100644 --- a/Makefile +++ b/Makefile @@ -513,6 +513,7 @@ version_h := include/generated/version_autogenerated.h timestamp_h := include/generated/timestamp_autogenerated.h defaultenv_h := include/generated/defaultenv_autogenerated.h dt_h := include/generated/dt.h +env_h := include/generated/environment.h no-dot-config-targets := clean clobber mrproper distclean \ help %docs check% coccicheck \ @@ -1785,6 +1786,69 @@ quiet_cmd_sym ?= SYM $@ u-boot.sym: u-boot FORCE $(call if_changed,sym) +# Environment processing +# --- + +# Directory where we expect the .env file, if it exists +ENV_DIR := $(srctree)/board/$(BOARDDIR) + +# Basename of .env file, stripping quotes +ENV_SOURCE_FILE := $(CONFIG_ENV_SOURCE_FILE:"%"=%) + +# Filename of .env file +ENV_FILE_CFG := $(ENV_DIR)/$(ENV_SOURCE_FILE).env
[PATCH v7 2/7] doc: Move environment documentation to rST
Move this from the README to rST format. Drop i2cfast since it is obviously obsolete and breaks the formatting. Other changes and improvements are in a following patch. Signed-off-by: Simon Glass --- (no changes since v6) Changes in v6: - Move all updates to a separate patch Changes in v5: - Minor updates as suggested by Wolfgang Changes in v4: - Add new patch to move environment documentation to rST README| 328 doc/usage/environment.rst | 381 ++ 2 files changed, 381 insertions(+), 328 deletions(-) create mode 100644 doc/usage/environment.rst diff --git a/README b/README index 840b192aae5..f20bc38a41c 100644 --- a/README +++ b/README @@ -2999,334 +2999,6 @@ TODO. For now: just type "help ". -Environment Variables: -== - -U-Boot supports user configuration using Environment Variables which -can be made persistent by saving to Flash memory. - -Environment Variables are set using "setenv", printed using -"printenv", and saved to Flash using "saveenv". Using "setenv" -without a value can be used to delete a variable from the -environment. As long as you don't save the environment you are -working with an in-memory copy. In case the Flash area containing the -environment is erased by accident, a default environment is provided. - -Some configuration options can be set using Environment Variables. - -List of environment variables (most likely not complete): - - baudrate - see CONFIG_BAUDRATE - - bootdelay- see CONFIG_BOOTDELAY - - bootcmd - see CONFIG_BOOTCOMMAND - - bootargs - Boot arguments when booting an RTOS image - - bootfile - Name of the image to load with TFTP - - bootm_low- Memory range available for image processing in the bootm - command can be restricted. This variable is given as - a hexadecimal number and defines lowest address allowed - for use by the bootm command. See also "bootm_size" - environment variable. Address defined by "bootm_low" is - also the base of the initial memory mapping for the Linux - kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and - bootm_mapsize. - - bootm_mapsize - Size of the initial memory mapping for the Linux kernel. - This variable is given as a hexadecimal number and it - defines the size of the memory region starting at base - address bootm_low that is accessible by the Linux kernel - during early boot. If unset, CONFIG_SYS_BOOTMAPSZ is used - as the default value if it is defined, and bootm_size is - used otherwise. - - bootm_size - Memory range available for image processing in the bootm - command can be restricted. This variable is given as - a hexadecimal number and defines the size of the region - allowed for use by the bootm command. See also "bootm_low" - environment variable. - - bootstopkeysha256, bootdelaykey, bootstopkey - See README.autoboot - - updatefile - Location of the software update file on a TFTP server, used - by the automatic software update feature. Please refer to - documentation in doc/README.update for more details. - - autoload - if set to "no" (any string beginning with 'n'), - "bootp" will just load perform a lookup of the - configuration from the BOOTP server, but not try to - load any image using TFTP - - autostart- if set to "yes", an image loaded using the "bootp", - "rarpboot", "tftpboot" or "diskboot" commands will - be automatically started (by internally calling - "bootm") - - If set to "no", a standalone image passed to the - "bootm" command will be copied to the load address - (and eventually uncompressed), but NOT be started. - This can be used to load and uncompress arbitrary - data. - - fdt_high - if set this restricts the maximum address that the - flattened device tree will be copied into upon boot. - For example, if you have a system with 1 GB memory - at physical address 0x1000, while Linux kernel - only recognizes the first 704 MB as low memory, you - may need to set fdt_high as 0x3C00 to have the - device tree blob be copied to the maximum address - of the 704 MB low memory, so that Linux kernel can - access it during the boot procedure. - - If this is set to the special value 0x then - the fdt will not be copied at all on boot. For this - to work it must reside in
[PATCH v7 1/7] sandbox: Drop distro_boot
This is a complicated set of #defines and it is painful to convert to a
text file. We can (once pending patches are applied) provide the same
functionality with bootmethod. Drop this for sandbox to allow conversion
to a text-file environment.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/configs/sandbox.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 24c9a84fa35..c19232f202f 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -49,16 +49,6 @@
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
-#define BOOT_TARGET_DEVICES(func) \
- func(HOST, host, 1) \
- func(HOST, host, 0)
-
-#ifdef __ASSEMBLY__
-#define BOOTENV
-#else
-#include
-#endif
-
#define CONFIG_KEEP_SERVERADDR
#define CONFIG_UDP_CHECKSUM
#define CONFIG_TIMESTAMP
@@ -103,7 +93,6 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
SANDBOX_SERIAL_SETTINGS \
SANDBOX_ETH_SETTINGS \
- BOOTENV \
MEM_LAYOUT_ENV_SETTINGS
#ifndef CONFIG_SPL_BUILD
--
2.33.0.1079.g6e70778dc9-goog
[PATCH v7 0/7] env: Allow environment in text files
One barrier to completing the 7-year-long Kconfig migration is that the default environment is implemented using ad-hoc CONFIG options. At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is not really feasible to move the environment to Kconfig as it is hundreds of lines of text in some cases. Even considering the current situation, it is painful to add large amounts of text to the config-header file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. This is already supported by the CONFIG_USE_DEFAULT_ENV_FILE feature. but that does not support use of CONFIG options or comments, so is best suited for use by other build systems wanting to define the U-Boot environment. Add a feature that brings in a .env file associated with the board config, if present. To use it, create a file board/.env or use CONFIG_ENV_SOURCE_FILE to set a filename. The environment variables should be of the form "var=value". Values can extend to multiple lines. This series converts the existing environment documentation to rST and updates it to explain how to use this. Note: this series was originally sent eight years ago: https://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-...@chromium.org/ It has been updated to work with Kconfig, etc. Some review comments in that patch were infeasible so I have not addressed them. I would like this series to be considered independently, on its merits. Rather than deal with the complexity of rewriting the distro-boot script, this is disabled for sandbox. The forthcoming bootmethod approach should provide the same functionality without needing the complex scripting in the environment. Migration needs more thought, although it can be done later. It may be possible to do migrate automatically, using buildman to extract the built-in environmnent from the ELF file. This would produce a pretty ugly conversion though, since it would drop all the intermediate variables used to create the environment. Better would be to parse the config.h file, figure out the components of CONFIG_EXTRA_ENV_SETTINGS then output these as separate pieces in the file. It is not clear how easy that would be, nor whether the result would be very pretty. Also the __stringify() macro needs to be handled somehow. This series is available at u-boot-dm/env-working Comments welcome. Changes in v7: - Use 'env' basename instead of 'environment' for intermediate output files - Show a message indicating the source text file being used - Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined - Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name - Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty - Rewrite the documentation - Drop the use of common.env - Update awk script to output the whole CONFIG string, or just a comment - Add new patch to explain the relationship with DEFAULT_ENV_FILE - A few more tweaks - Go into more detail about the change of behaviour with autostart - Update the cover letter Changes in v6: - Move all updates to a separate patch - Combine the two env2string.awk patches into one - Move all updates to a separate patch - More updates and improvements - Add new patch to tidy up use of autostart env var Changes in v5: - Minor updates as suggested by Wolfgang - Explain how to include the common.env file - Explain why variables starting with _ , and / are not supported - Expand the definition of how to declare an environment variable - Explain what happens to empty variables - Update maintainer - Move use of += to this patch - Explain that environment variables may not end in + - Minor updates as suggested by Wolfgang Changes in v4: - Add new patch to move environment documentation to rST - Move this from being part of configuring U-Boot to part of building it - Don't put the environment in autoconf.mk as it is not needed - Add documentation in rST format instead of README - Drop mention of import/export - Update awk script to ignore blank lines, as generated by clang - Add documentation in rST format instead of README - Add new patch to move environment documentation to rST Changes in v3: - Adjust Makefile to generate the .inc and .h files in separate fules - Add more detail in the README about the format of .env files - Improve the comment about " in the awk script - Correctly terminate environment files with \n - Define __UBOOT_CONFIG__ when collecting environment files - Add new patch to use a text-based environment for sandbox Changes in v2: - Move .env file from include/configs to board/ - Use awk script to process environment since it is much easier on the brain - Add information and updated example script to README - Add dependency rule so that the environment is rebuilt when it changes - Add separate patch to enable C preprocessor for environment files -
Re: External dts building
Hi Giulio, On Thu, 14 Oct 2021 at 21:06, Giulio Benetti wrote: > > Hi Simon, > > > Il giorno 15 ott 2021, alle ore 02:53, Simon Glass ha > > scritto: > > > > Hi Giulio, > > > >> On Thu, 14 Oct 2021 at 15:12, Giulio Benetti > >> wrote: > >> > >> Hi Simon, > >> > >> Il giorno 14 ott 2021, alle ore 22:43, Simon Glass ha > >> scritto: > >> > >> Hi Giulio, > >> > >> On Thu, 14 Oct 2021 at 13:23, Giulio Benetti > >> wrote: > >> > >> > >> Hi Simon, > >> > >> > >> Il giorno 14 ott 2021, alle ore 20:24, Simon Glass ha > >> scritto: > >> > >> > >> Hi, > >> > >> > >> On Thu, 14 Oct 2021 at 07:46, Tom Rini wrote: > >> > >> > >> On Thu, Oct 14, 2021 at 02:53:30AM +0200, Giulio Benetti wrote: > >> > >> > >> Hello All, > >> > >> > >> is there a way to pass a dts file without touching the > >> arch/arm/boot/dts/Makefile? > >> > >> > >> On Buildroot we support the possibility to pass an external dts by copying > >> it to the uboot sources to > >> > >> be built but since uboot version 2020.01 it doesn’t work anymore. > >> > >> > >> So I’ve proposed a patch to prepend the dts file in the Makefile above, > >> but this has drawbacks, like we reconfigure(it keeps adding files every > >> time). > >> > >> > >> So I ask you, is there a more canonical way already to achieve this? > >> > >> > >> Not exactly, and it's something we're very much actively discussing > >> > >> right now. > >> > >> > >> Are you using 'make DEVICE_TREE=xxx' ? > >> > >> > >> Yes but it doesn’t work if you don’t add an entry into > >> arch/arm/dts/Makefile > >> > >> Before version 2020.01 worked, but not after it. > >> > >> > >> What board are you building? > >> > >> > >> A20-OLinuXino-Lime_defconfig for but without CONFIG_DEFAULT_DEVICE_TREE > >> undefined, > >> so if you try to pass DEVICE_TREE= pointing to an external .dts file > >> copied to arch/arm/dts/ make doesn’t find the entry in Makefile and it > >> can’t build it. > >> > >> This is useful in build systems like Buildroot where you can provide an > >> external defconfig as well as an external .dts file. > >> > >> So here the solution I see is to create an entry in arch/arm/dts/Makefile > >> on the top of the file afte copying the .dts file we want to build. > >> But on Buildroot they’ve pointed me to ask upstream(here) if there’s a > >> more canonical way or to work together to achieve the goal: > >> > >> https://patchwork.ozlabs.org/project/buildroot/patch/20210209201303.195093-1-giulio.bene...@benettiengineering.com/ > > > > How about not disabling CONFIG_DEFAULT_DEVICE_TREE ? That should work OK. > > But if I’m not wrong the problem of the dts/Makefile remains. If .dts file is > not assigned to dtb-y it won’t be built. > > And in the case of Buildroot we have 2 ways to use external dts files: > 1) patch uboot adding the dts and the entry in dts/Makefile > 2) copy .dts file(let’s say located in ~/my-folder/my.dts) to > arch/arm/dts/my.dts and prepend > the dtb-y += my.dts in arch/arm/dts/Makefile and here problem arises. > Because it can work once but we need to make it possible to have ‘make > uboot-rebuild/reconfigure’ > (Buildroot has such targets). This way is not easy at all to prepend the > dtb-y at the top of the file without re-prepending it again and again. > > It worked up to uboot < 2020.01, but I still haven’t bisected to see the > “offending” commit. > Maybe I can try and find out why it behaves like that. > > What about that? Have you tried EXT_DTB? It looks like DEVICE_TREE is designed for changing the name of the file. EXT_DTB=/tmp/b/sandbox/u-boot.dtb CROSS_COMPILE=/home/sglass/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi- make O=/tmp/b/snow -j30 snow_defconfig all You need to compile it first though. For your case, I did a bisect with: git bisect run make -s DEVICE_TREE=try CROSS_COMPILE=/home/sglass/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi- O=/tmp/b/snow -j30 mrproper snow_defconfig all and got: a3444bd09af (refs/bisect/bad) Revert "Ensure device tree DTS is compiled" +Masahiro Yamada who might know BTW if you rely on this feature, once it is working again, we should add a test for it. Regards, Simon
Re: Broken build with disabling OpenSSL crypto
On Friday 15 October 2021 09:35:43 Alex G. wrote:
> On 10/15/21 6:34 AM, Pali Rohár wrote:
> > On Wednesday 06 October 2021 17:05:24 Alex G. wrote:
> > > Hi Jernej,
> > >
> > > On 10/6/21 4:27 PM, Jernej Škrabec wrote:
> > > > Hi everyone!
> > > >
> > > > Commit cb9faa6f98ae ("tools: Use a single target-independent config to
> > > > enable
> > > > OpenSSL") recently introduced option to disable usage of OpenSSL via
> > > > CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit
> > > > b4f3cc2c42d9
> > > > ("tools: kwbimage: Do not hide usage of secure header under
> > > > CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That
> > > > totally
> > > > defeats the purpose of first commit. I suggest that it gets reverted.
> > > >
> > > > I would like disable OpenSSL for my usage, since it gives me troubles
> > > > when
> > > > cross-compiling U-Boot inside LibreELEC build system. It's not needed
> > > > for our
> > > > case anyway.
> > > >
> > > > Best regards,
> > > >
> > >
> > > Can you please give the following diff a try, and if it works for you,
> > > submit as patch?
> >
> > This change is incorrect and will break mvebu builds. mvebu requires
> > kwbimage for building boot images and so you cannot disable it or make
> > it optional.
> >
>
> If kwbimage is required and missing the CI builds and tests don't catch
> that. I ran buildman with the change, and nothing broke. Sounds like that
> needs to be addressed.
It is possible that tests do not covert all scenarios.
> That being said, I'm not okay with making everyone a slave to OpenSSL
> because of any given platform.
>
> I propose to revert commit b4f3cc2c42d9 ("tools: kwbimage: Do not hide usage
> of secure header under CONFIG_ARMADA_38X"), and rework it such that it
> doesn't force libcrypto on everyone. And we very likely need a CI test
> against libcrypto linkage when TOOLS_LIBCRYPTO is not set.
Reverting that commit is not a solution as it can lead to broken
kwbimage (when crypto stuff is not enabled). Plus there is lot of other
changes and fixes in kwboot and kwbimage...
Some information with another approach how to solve build issues are in
this email:
https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/
> Alex
>
> > >
> > > diff --git a/tools/Makefile b/tools/Makefile
> > > index 4a86321f64..7f72ff9645 100644
> > > --- a/tools/Makefile
> > > +++ b/tools/Makefile
> > > @@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix
> > > lib/aes/, \
> > >
> > > # Cryptographic helpers that depend on openssl/libcrypto
> > > LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
> > > - fdt-libcrypto.o)
> > > + fdt-libcrypto.o) \
> > > + kwbimage.o
> > >
> > > ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
> > >
> > > @@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
> > > imximage.o \
> > > imx8image.o \
> > > imx8mimage.o \
> > > - kwbimage.o \
> > > lib/md5.o \
> > > lpc32xximage.o \
> > > mxsimage.o \
> > > @@ -169,8 +169,8 @@ HOST_EXTRACFLAGS +=
> > > -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
> > > HOST_EXTRACFLAGS+= -DCONFIG_FIT_CIPHER
> > > endif
> > >
> > > -# MXSImage needs LibSSL
> > > -ifneq
> > > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
> > > +# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
> > > +ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
> > > HOSTCFLAGS_kwbimage.o += \
> > > $(shell pkg-config --cflags libssl libcrypto 2> /dev/null ||
> > > echo "")
> > > HOSTLDLIBS_mkimage += \
Pull request, u-boot-tegra/master
Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks. The following changes since commit 10cd8efe1a7eacd63907ba95bd8442bc2cdce461: Merge branch '2021-10-12-assorted-fixes-and-updates' (2021-10-13 10:14:35 -0400) are available in the git repository at: https://source.denx.de/u-boot/custodians/u-boot-tegra.git master for you to fetch changes up to a0ba216ed420a8953f57f777256f310370b95338: ARM: tegra: Copy memory-region-names property (2021-10-13 14:18:30 -0700) Thierry Reding (9): fdtdec: Allow using fdtdec_get_carveout() in loops fdtdec: Support retrieving the name of a carveout fdtdec: Support compatible string list for reserved memory fdtdec: Reorder fdtdec_set_carveout() parameters for consistency fdtdec: Support reserved-memory flags ARM: tegra: Support multiple reserved memory regions ARM: tegra: Support EMC frequency tables on Tegra210 ARM: tegra: Refactor DT update helpers ARM: tegra: Copy memory-region-names property arch/arm/cpu/armv8/fsl-layerscape/soc.c | 3 +- arch/arm/include/asm/arch-tegra/board.h | 10 +++ arch/arm/mach-tegra/dt-setup.c | 147 arch/riscv/lib/fdt_fixup.c | 2 +- board/nvidia/p2371-2180/p2371-2180.c| 94 ++-- board/nvidia/p2771-/p2771-.c| 98 ++--- board/nvidia/p3450-/p3450-.c| 96 ++--- include/configs/tegra210-common.h | 2 +- include/fdtdec.h| 39 ++--- lib/fdtdec.c| 99 ++--- lib/fdtdec_test.c | 7 +- lib/optee/optee.c | 4 +- test/dm/fdtdec.c| 28 +++--- 13 files changed, 321 insertions(+), 308 deletions(-)
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi all, On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog > > > > wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit > > > > > : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > > > > >> > > wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > >> > > > OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > >> > > > built and > > > > >> > > > appended to U-Boot > > > > >> > > >- OF_EMBED - for development purposes, the devicetree is > > > > >> > > > embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is > > > > >> > > > needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > > > > >> > > > don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > >> > > > Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > > > >> > > > devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > > > >> > > > bootloader and its > > > > >> > > > caller may have a better idea about the hardware available in > > > > >> > > > the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > > > > >> > > > be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing > > > > >> > > > devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based > > > > >> > > on > > > > >> > > command line parameters, and the device tree you put in this > > > > >> > > series > > > > >> > > has various hardcoded values which normally do not > > > > >> > > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device trees > > > > >> > for > > > > >> > platforms that are capable of and can / do have a device tree to > > > > >> > give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for a > > > > >> few months now. I've been signalling a change like this for over a > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro > > > > >> people. I sent a patch (below) to try to explain things. I hope it is > > > > >> not a surprise! > > > > >> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > > > > >> Ilias' series and this one we can get ourselves on a stronger > > > > >> footing. > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > > > > >> For more context: > > > > >> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > >> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the > > > > >> u-boot.dtsi but there was not much interest there (in fact the > > > > >> maintainer would prefer there was no special support even for booting > > > > >> Linux directly!) > > > > > > > > > > i understand their point of view and agree with it. > > > > >> > > > > >> But in any case it doesn't really help U-Boot. I > > > > >> think the path forward might be to run QEMU twice, once to get its > > > > >> generated tree and once to
Re: [PATCH 4/4] Convert CONFIG_USB_EHCI_IS_TDI to Kconfig
On Sat, Oct 09, 2021 at 03:27:35PM +0200, Marek Behún wrote: > From: Marek Behún > > On mvebu this is defined if and only if !ARM64. > > Otherwise it is defined for boards with ARCH_MX23, ARCH_TEGRA and > ARCH_ZYNQ, and also for SOC_AR934X (tplink_wdr4300). > > Signed-off-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/4] Drop CONFIG_USB_EHCI_KIRKWOOD
On Sat, Oct 09, 2021 at 03:27:34PM +0200, Marek Behún wrote: > From: Marek Behún > > This config option doesn't do anything. > > nas220 uses USB_EHCI_MARVELL. > > Signed-off-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] Convert CONFIG_USB_EHCI_MXS to Kconfig
On Sat, Oct 09, 2021 at 03:27:33PM +0200, Marek Behún wrote: > From: Marek Behún > > This option is only used for > mx23evk_defconfig > mx23_olinuxino_defconfig > which are the only i.MX23 boards. > > Add depend on ARCH_MX23 and default to y. > > Signed-off-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] Rename CONFIG_EHCI_IS_TDI to CONFIG_USB_EHCI_IS_TDI
On Sat, Oct 09, 2021 at 03:27:32PM +0200, Marek Behún wrote: > From: Marek Behún > > In preparation for moving this option to Kconfig, rename it to be > consistent with other USB EHCI Kconfig options. > > Signed-off-by: Marek Behún Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/6] Remove unused CONFIG_CONS_NONE
On Mon, Oct 04, 2021 at 11:59:54AM +0200, Patrick Delaunay wrote: > Remove the latest reference of CONFIG_CONS_NONE in code > > Signed-off-by: Patrick Delaunay > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/6] Remove unused CONFIG_SYS_FLASH_AMD_CHECK_DQ7
On Mon, Oct 04, 2021 at 11:59:53AM +0200, Patrick Delaunay wrote: > Remove the latest reference of CONFIG_SYS_FLASH_AMD_CHECK_DQ7 in code > > Signed-off-by: Patrick Delaunay > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/6] Remove unused CONFIG_NO_RELOCATION
On Mon, Oct 04, 2021 at 11:59:52AM +0200, Patrick Delaunay wrote: > Remove the latest reference of CONFIG_NO_RELOCATION in code > > Signed-off-by: Patrick Delaunay > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/6] am33x: Remove unused define CONFIG_MUSB_HOST
On Mon, Oct 04, 2021 at 11:59:51AM +0200, Patrick Delaunay wrote: > This define was left over from a previous revision, and was never used. > > Signed-off-by: Patrick Delaunay > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/6] scripts: remove some configs in config_whitelist.txt
On Mon, Oct 04, 2021 at 11:59:50AM +0200, Patrick Delaunay wrote:
> Remove some config finishing by _ badly added by
> scripts/build-whitelist.sh when joker is used in comments.
>
> for example:
> doc/uImage.FIT/command_syntax_extensions.txt:
> ... #ifdef CONFIG_OF_* |...
>
> cmd/nvedit.c:# error Define one of CONFIG_ENV_IS_IN_{EEPROM| \
> FLASH|MMC|FAT|EXT4|\
>
> Remove also configs only used in comments:
> - CONFIG_BOOGER in include/linux/kconfig.h
> - CONFIG_COMMANDS
> - CONFIG_INIT_IGNORE_ERROR
> - CONFIG_REG_*
> - CONFIG_HOTPLUG : drivers/watchdog/omap_wdt.c:18
>
> Signed-off-by: Patrick Delaunay
> Reviewed-by: Simon Glass
> Tested-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
We would need to quirk out Card Detect case and for that we allow
configuring SD/SDIO family of pins.
Signed-off-by: Andy Shevchenko
---
arch/x86/cpu/tangier/pinmux.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
index acf97e3af51d..8385167b2b6b 100644
--- a/arch/x86/cpu/tangier/pinmux.c
+++ b/arch/x86/cpu/tangier/pinmux.c
@@ -37,8 +37,9 @@ struct mrfld_family {
.npins = (e) - (s) + 1, \
}
-/* Now we only support I2C family of pins */
+/* Now we only support SD/SDIO and I2C families of pins */
static struct mrfld_family mrfld_families[] = {
+ MRFLD_FAMILY(3, 37, 56),
MRFLD_FAMILY(7, 101, 114),
};
@@ -125,6 +126,34 @@ static int mrfld_pinconfig_protected(unsigned int pin, u32
mask, u32 bits)
return ret;
}
+static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
+{
+ struct mrfld_pinctrl *pinctrl;
+ struct udevice *dev;
+ void __iomem *bufcfg;
+ u32 v, value;
+ int ret;
+
+ ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
+ if (ret)
+ return ret;
+
+ pinctrl = dev_get_priv(dev);
+
+ bufcfg = mrfld_get_bufcfg(pinctrl, pin);
+ if (!bufcfg)
+ return -EINVAL;
+
+ value = readl(bufcfg);
+ v = (value & ~mask) | (bits & mask);
+ writel(v, bufcfg);
+
+ debug("v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
+ v, (u32)bufcfg, bits, mask, bufcfg);
+
+ return 0;
+}
+
static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
{
bool is_protected;
@@ -133,10 +162,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
u32 mask;
int ret;
- /* For now we only support just protected Family of pins */
is_protected = ofnode_read_bool(pin_node, "protected");
- if (!is_protected)
- return -ENOTSUPP;
pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1);
if (pad_offset == -1)
@@ -152,7 +178,10 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
if (mode & ~mask)
return -ENOTSUPP;
- ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ if (is_protected)
+ ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ else
+ ret = mrfld_pinconfig(pad_offset, mask, mode);
return ret;
}
--
2.33.0
[PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
There are two PCB designs in the wild which use the opposite
signaling for SD card detect. This makes U-Boot working in one case
and failing in the other. Quirk this out by disconnecting SD card
detect pin from the PCB by switching to mode 3.
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
Signed-off-by: Andy Shevchenko
---
arch/x86/dts/edison.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 2c8cf6c07102..04e8a4e457c8 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -94,6 +94,7 @@
sdcard: mmc@ff3fa000 {
compatible = "intel,sdhci-tangier";
reg = <0xff3fa000 0x1000>;
+ cd-inverted;
};
pmu: power@ff00b000 {
@@ -131,6 +132,17 @@
compatible = "intel,pinctrl-tangier";
reg = <0xff0c 0x8000>;
+ /*
+* Disconnect SD card detect, so it won't affect the reality
+* on two different PCB designs where it's using the opposite
+* signaling: Edison/Arduino uses Active Low, while SparkFun
+* went with Active High.
+*/
+ sd_cd@0 {
+ pad-offset = <37>;
+ mode-func = <3>;
+ };
+
/*
* Initial configuration came from the firmware.
* Which quite likely has been used in the phones, where I2C #8,
--
2.33.0
Re: [PATCH v2] board: gateworks: venice: add imx8mn-gw7902 support
On 15.10.21 19:06, Tim Harvey wrote: > A grep for SERIAL_SUPPORT (which was renamed to SERIAL) shows all the > boards in your master-next that got merged like mine that currently > likely need fixups: > $ git grep SERIAL_SUPPORT configs/ > configs/imx8mm-cl-iot-gate-optee_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y > configs/imx8mn_venice_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y > configs/iot2050_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y Thanks, but this board was already fixed in master (ce543d0d). Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
Re: [PATCH v2] board: gateworks: venice: add imx8mn-gw7902 support
On Wed, Oct 6, 2021 at 4:45 PM Tim Harvey wrote:
>
> The GW7902 is based on the i.MX 8M Mini / Nano SoC featuring:
> - LPDDR4 DRAM
> - eMMC FLASH
> - Gateworks System Controller
> - LTE CAT M1 modem
> - USB 2.0 HUB
> - M.2 Socket with USB2.0, PCIe, and dual-SIM
> - IMX8M FEC
> - PCIe based GbE
> - RS232/RS485/RS422 serial transceiver
> - GPS
> - CAN bus
> - WiFi / Bluetooth
> - MIPI header (DSI/CSI/GPIO/PWM/I2S)
> - PMIC
>
> To add support for the i.MX8M Nano GW7902:
> - Add imx8mn-venice dts/defconfig/include
> - Add imx8mn-gw7902 dts
> - Add imx8mn-2gb lpddr4 dram configs
> - Add misc support for IMX8M Nano SoC
> - rename imx8mm-venice.c to venice.c as it is no longer imx8mm specific
> - update README with differences for IMX8MN vs IMX8MM
>
> Signed-off-by: Tim Harvey
> ---
> v2:
> - rebase on origin/master
> - remove unused fdt_pack_reg function
> ---
> arch/arm/dts/Makefile |2 +
> arch/arm/dts/imx8mn-venice-gw7902-u-boot.dtsi | 29 +
> arch/arm/dts/imx8mn-venice-gw7902.dts | 888 ++
> arch/arm/dts/imx8mn-venice-u-boot.dtsi| 222 +++
> arch/arm/dts/imx8mn-venice.dts| 152 ++
> arch/arm/mach-imx/imx8m/Kconfig |7 +
> board/gateworks/venice/Kconfig| 15 +
> board/gateworks/venice/MAINTAINERS|6 +-
> board/gateworks/venice/Makefile | 10 +-
> board/gateworks/venice/README |3 +-
> board/gateworks/venice/gsc.c | 13 +
> .../gateworks/venice/imximage-8mn-lpddr4.cfg | 10 +
> board/gateworks/venice/lpddr4_timing.h|5 +
> ...lpddr4_timing.c => lpddr4_timing_imx8mm.c} |0
> .../lpddr4_timing_imx8mn_2gb_dual_die.c | 1444
> .../lpddr4_timing_imx8mn_2gb_single_die.c | 1445 +
> board/gateworks/venice/spl.c | 31 +-
> .../venice/{imx8mm_venice.c => venice.c} |0
> configs/imx8mn_venice_defconfig | 114 ++
> include/configs/imx8mn_venice.h | 114 ++
> 20 files changed, 4503 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/dts/imx8mn-venice-gw7902-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mn-venice-gw7902.dts
> create mode 100644 arch/arm/dts/imx8mn-venice-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mn-venice.dts
> create mode 100644 board/gateworks/venice/imximage-8mn-lpddr4.cfg
> rename board/gateworks/venice/{lpddr4_timing.c => lpddr4_timing_imx8mm.c}
> (100%)
> create mode 100644 board/gateworks/venice/lpddr4_timing_imx8mn_2gb_dual_die.c
> create mode 100644
> board/gateworks/venice/lpddr4_timing_imx8mn_2gb_single_die.c
> rename board/gateworks/venice/{imx8mm_venice.c => venice.c} (100%)
> create mode 100644 configs/imx8mn_venice_defconfig
> create mode 100644 include/configs/imx8mn_venice.h
>
Stefano,
I noticed you have applied my first version of this patch into your
imx master-next tree which is now broken because of some other patches
that required it to be rebased:
7abf178bb815 power: Tidy up #undef of CONFIG_DM_PMIC
2a7360666871 serial: Rename SERIAL_SUPPORT to SERIAL
103c5f180694 mmc: Rename MMC_SUPPORT to MMC
7cfbba36e9f8 Convert CONFIG_SYS_MALLOC_LEN to Kconfig
148b8bb4b6bd imx: Finish migration of IMX_CONFIG to Kconfig
49c8ef0e45a9 Convert CONFIG_SYS_LOAD_ADDR to Kconfig
72d81360aabd global: Convert CONFIG_LOADADDR to CONFIG_SYS_LOADADDR
15e7b7682474 Convert CONFIG_SYS_I2C_MXC et al to Kconfig
This v2 patch here was rebased on top of origin/master to take care of this.
A grep for SERIAL_SUPPORT (which was renamed to SERIAL) shows all the
boards in your master-next that got merged like mine that currently
likely need fixups:
$ git grep SERIAL_SUPPORT configs/
configs/imx8mm-cl-iot-gate-optee_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y
configs/imx8mn_venice_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y
configs/iot2050_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y
configs/kontron-sl-mx6ul_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y
configs/kontron-sl-mx8mm_defconfig:CONFIG_SPL_SERIAL_SUPPORT=y
A quick test shows all the above with the exception of perhaps
iot2050_defconfig are not buildable.
How do you wish us to proceed? I have a set of patches that I can
submit to resolve this but I'm not clear if I should squash them and
if you should perhaps squash them into the original commit before
requesting a git pull to master?
imx8mn_venice: fix SERIAL
imx8mn_venice: fix MMC_SUPPORT
imx8mn_venice: fix SYS_MALLOC_LEN
imx8mn-venice: fix IMX_CONFIG
imx8mn_venice: fix loadaddr
imx8mn-venice: fix I2C
Or should you revert and instead apply this v2 version that takes care
of these things?
What are your plans for requesting a git pull to master?
Best regards,
Tim
[1] https://source.denx.de/u-boot/custodians/u-boot-imx/-/tree/master-next
> --
> 2.17.1
>
Re: [PATCH 2/2] env: mmc: Add support for redundant env in both eMMC boot partitions
On Wed, Oct 06, 2021 at 06:29:54PM +0200, Marek Vasut wrote: > Currently the MMC environment driver supports storing redundant environment > only in one eMMC partition at different offsets. This is sub-optimal, since > if this one boot partition is erased, both copies of environment are lost. > Since the eMMC has two boot partitions, add support for storing one copy of > environment in each of the two boot partitions. > > To enable this functionality, select CONFIG_SYS_REDUNDAND_ENVIRONMENT to > indicate redundant environment should be used. Set CONFIG_SYS_MMC_ENV_PART > to 1 to indicate environment should be stored in eMMC boot partition. Set > CONFIG_ENV_OFFSET equal to CONFIG_ENV_OFFSET_REDUND, and both to the offset > from start of eMMC boot partition where the environment should be located. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Jaehoon Chung > Cc: Peng Fan > Cc: Stefano Babic > --- > env/mmc.c | 47 ++- > 1 file changed, 42 insertions(+), 5 deletions(-) > > diff --git a/env/mmc.c b/env/mmc.c > index e111d8e5881..465b104559b 100644 > --- a/env/mmc.c > +++ b/env/mmc.c > @@ -26,6 +26,18 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +/* > + * In case the environment is redundant, stored in eMMC hardware boot > + * partition and the environment and redundant environment offsets are > + * identical, store the environment and redundant environment in both > + * eMMC boot partitions, one copy in each. > + * */ > +#if (defined(CONFIG_SYS_REDUNDAND_ENVIRONMENT) && \ > + (CONFIG_SYS_MMC_ENV_PART == 1) && \ > + (CONFIG_ENV_OFFSET == CONFIG_ENV_OFFSET_REDUND)) > +#define ENV_MMC_HWPART_REDUND > +#endif This needs to be documented in more than just the header, it should be in Kconfig at least. And if we could enable this directly via a Kconfig option instead, that would be even better. -- Tom signature.asc Description: PGP signature
Re: [PATCH] loads: Block writes into LMB reserved areas of U-Boot
On 10/15/21 6:09 PM, Tom Rini wrote: [...] This code looks OK but I don't know what lmb_reserve() and lmb_free() do. Can you add comments to the header file? Not here, the entire LMB stuff needs (better) documentation, that's where (all) such clarification should go. Is that you saying you'll do such a follow-up patch, given you've touched this code the most of late? Maybe, I won't promise you anything except I add it to my roll of todo paper.
Re: [PATCH 1/6 v4] serial: qcom: add support for GENI serial driver
чт, 14 окт. 2021 г. в 18:10, Simon Glass : > Hi Dzmitry, > > On Fri, 8 Oct 2021 at 00:46, Dzmitry Sankouski > wrote: > > > > Generic Interface (GENI) Serial Engine (SE) based uart > > can be found on newer qualcomm SOCs, starting from SDM845. > > Tested on Samsung SM-G9600(starqltechn) > > by chain-loading u-boot with stock bootloader. > > > > Signed-off-by: Dzmitry Sankouski > > Cc: Ramon Fried > > Cc: Tom Rini > > --- > > Changes for v2: > > - change functions return type to void, where possible > > - remove '.' from summary line > > Changes for v3: > > - move function open brace on new line > > - use tab between define name and value > > - define: wrap expression with braces, remove braces from constants > > Changes for v4: > > - add linux/delay.h header > > > > MAINTAINERS | 1 + > > .../serial/msm-geni-serial.txt| 6 + > > drivers/serial/Kconfig| 17 + > > drivers/serial/Makefile | 1 + > > drivers/serial/serial_msm_geni.c | 603 ++ > > 5 files changed, 628 insertions(+) > > create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt > > create mode 100644 drivers/serial/serial_msm_geni.c > > Reviewed-by: Simon Glass > > Some nits below > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 776ff703b9..52ddc99cda 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -390,6 +390,7 @@ F: drivers/gpio/msm_gpio.c > > F: drivers/mmc/msm_sdhci.c > > F: drivers/phy/msm8916-usbh-phy.c > > F: drivers/serial/serial_msm.c > > +F: drivers/serial/serial_msm_geni.c > > F: drivers/smem/msm_smem.c > > F: drivers/usb/host/ehci-msm.c > > > > diff --git a/doc/device-tree-bindings/serial/msm-geni-serial.txt > b/doc/device-tree-bindings/serial/msm-geni-serial.txt > > new file mode 100644 > > index 00..9eadc2561b > > --- /dev/null > > +++ b/doc/device-tree-bindings/serial/msm-geni-serial.txt > > @@ -0,0 +1,6 @@ > > +Qualcomm GENI UART > > + > > +Required properties: > > +- compatible: must be "qcom,msm-geni-uart" > > +- reg: start address and size of the registers > > +- clock: interface clock (must accept baudrate as a frequency) > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > > index 93348c0929..b420a5720d 100644 > > --- a/drivers/serial/Kconfig > > +++ b/drivers/serial/Kconfig > > @@ -278,6 +278,14 @@ config DEBUG_UART_S5P > > will need to provide parameters to make this work. The driver > will > > be available until the real driver-model serial is running. > > > > +config DEBUG_UART_MSM_GENI > > Do you need this? Most drivers just use the existing DEBUG_UART Kconfig. > Documentation for CONFIG_DEBUG_UART says: `- Enable the CONFIG for your UART to tell it to provide this interface (e.g. CONFIG_DEBUG_UART_NS16550)` Debug functionality is controlled by chip specific CONFIG_DEBUG_UART_*. So no serial driver uses plain DEBUG_UART for adding debug functionality. > > + bool "Qualcomm snapdragon" > > + depends on ARCH_SNAPDRAGON > > + help > > + Select this to enable a debug UART using the serial_msm > driver. You > > + will need to provide parameters to make this work. The driver > will > > + be available until the real driver-model serial is running. > > + > > config DEBUG_UART_MESON > > bool "Amlogic Meson" > > depends on MESON_SERIAL > > @@ -783,6 +791,15 @@ config MSM_SERIAL > > for example APQ8016 and MSM8916. > > Single baudrate is supported in current implementation > (115200). > > > > +config MSM_GENI_SERIAL > > + bool "Qualcomm on-chip GENI UART" > > + help > > + Support UART based on Generic Interface (GENI) Serial Engine > (SE), used on Qualcomm Snapdragon SoCs. > > + Should support all qualcomm SOCs with Qualcomm Universal > Peripheral (QUP) Wrapper cores, > > 80cols > > > + i.e. newer ones, starting from SDM845. > > + Driver works in FIFO mode. > > + Multiple baudrates supported. > > + > > config OCTEON_SERIAL_BOOTCMD > > bool "MIPS Octeon PCI remote bootcmd input" > > depends on ARCH_OCTEON > > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile > > index 3cbea8156f..d44caf4ea2 100644 > > --- a/drivers/serial/Makefile > > +++ b/drivers/serial/Makefile > > @@ -62,6 +62,7 @@ obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o > > obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o > > obj-$(CONFIG_BCM283X_PL011_SERIAL) += serial_bcm283x_pl011.o > > obj-$(CONFIG_MSM_SERIAL) += serial_msm.o > > +obj-$(CONFIG_MSM_GENI_SERIAL) += serial_msm_geni.o > > obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o > > obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o > > obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o > > diff --git a/drivers/serial/serial_msm_geni.c > b/drivers/serial/serial_msm_geni.c > > new file mode 100644
Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE
Hi Tom, Tom Rini writes: > On Wed, Oct 13, 2021 at 01:36:00PM -0400, Thomas Fitzsimmons wrote: >> Simon Glass writes: >> >> [...] >> >> > On Wed, 13 Oct 2021 at 10:26, Thomas Fitzsimmons >> > wrote: >> >> >> >> Simon Glass writes: >> >> >> >> [...] >> >> >> >> >> > I think one option is better than two. I have a slight preference for >> >> >> > OF_PRIOR_STAGE because it is board-agnostic, but I'm not sure it >> >> >> > matters, since some of these boards are doing strange things anyway >> >> >> > and cannot use OF_PRIOR_STAGE. So let's go with this. >> >> >> >> >> >> For now it's easier getting rid of OF_PRIOR_STAGE than OF_BOARD. >> >> >> Once we unify OF_PRIOR_STAGE/OF_BOARD and OF_HOSTFILE, then >> >> >> I can send a patch on top of that, which removes the >> >> >> board_fdt_blob_setup() >> >> >> and just stores the address in a similar fashion to the removed >> >> >> 'prior_stage_fdt_address'. That way we can get rid of architecture >> >> >> specific constructs wrt to DT in gd. The callback is a bit more of a >> >> >> pain to >> >> >> maintain for multiple boards but is more flexible than an address in a >> >> >> register. In any case we can do something along the lines of: >> >> >> >> >> >> Check register (or blob list or whatever) >> >> >> if (valid dtb) >> >> >> fixup/amend/use (depending on what we decide) >> >> >> else >> >> >>arch specific callback >> >> >> >> >> >> That should give us enough flexibility to deal with future boards >> >> >> (famous >> >> >> last words). >> >> > >> >> > SGTM >> >> >> >> This sounds like a good generalization that would still work for the >> >> bcm7445 and bcm7260 boards. I'll test this approach on the evaluation >> >> boards I have. >> >> >> >> For the BCM7445 I may be able to import the evaluation board device tree >> >> that Broadcom publishes as part of stblinux. At runtime I may need to >> >> merge some of the in-memory items generated by BOLT, but I'll try to >> >> make this work. >> > >> > That would be good. >> > >> >> The BCM7260 DTS is not publicly available though, as far as I know. >> > >> > Presumably it can be dumped from U-Boot? >> >> Technically, yes, but I wouldn't want to publish the result for various >> reasons; e.g., it would be specific to the evaluation boards I have, and >> it may contain vendor-specific fields. I'd much rather this one remain >> a stub, until/unless Broadcom publishes a generic BCM7260 DTS under a >> free license. > > Also note that the notion that the U-Boot source tree _must_ contain a > dts for a given board is something we're very much debating still, in > another thread, if you're inclined to read and chime in there as well > with more details about the broadcom use case and technical/legal > limitations. Thanks! Sure. I read through [1]; here are my thoughts from the BCM7445/BCM7260 perspective. First of all, for background, BCM7445 and BCM7260 are partial ports of U-Boot. They're meant to allow using nice U-Boot features like hush and FIT image loading on these platforms. But they do not handle low-level initialization -- that's done by BOLT, the proprietary first-and-second-stage bootloader -- and they don't support configuring all of the hardware on these boards. Instead these ports include a small set of drivers (e.g., SPI, eMMC, serial) and configuration that is needed to make use of the higher level features. At the time I contributed the BCM7445 support, README called OF_CONTROL an experimental feature, and device driver configuration was alternatively allowed to live in board-specific header files. My initial local implementation did that, but then I switched to OF_CONTROL before submitting the patches, since then I could get some of U-Boot's driver configuration from the prior stage (BOLT) dynamically, instead of hard-coding addresses in U-Boot source code. The proposed new policy would require me to (re-)add these hard-coded values, albeit in a DTS, not a header file. IMO that's probably a good/fair requirement for the non-technical reasons in [1]. The second section of [1] says: "Every board in U-Boot must include a devicetree sufficient to build and boot that board on suitable hardware (or emulation)." I initially read that as "boot to Linux", and so I was thinking the device tree checked into the U-Boot tree had to be sufficient to boot Linux and configure every device that Linux supports. One of Simon's responses [2] clarified for me that the policy proposal was about the control DTB for U-Boot. Now I believe the intent of the proposed policy (stated in the "Devicetree source" section of [1]) is something like "each port in U-Boot must have an in-tree device tree that is sufficient to boot/run *U-Boot itself* on at least one representative board designed around that SoC". That would make sense to me; it would permit not-full-Linux device trees that configure only the device drivers that the port needs to support a subset of U-Boot features. This would allow
Re: HiFive Unmatched: U-Boot stuck when loading Ramdisk
On Fri, Oct 15, 2021 at 06:29:09PM +0300, David Abdurachmanov wrote:
> On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel wrote:
> >
> > Hello,
> >
> > I hope this is the right way to report u-boot issues. I tried to reach
> > out to the RISC-V subsystem maintainer beforehand but didn't receive a
> > response, hence sending this to the ML.
> >
> > We are currently working on Alpine Linux support for the Hifive
> > Unmatched and at least two of our developers have access to a board
> > presently. While working on Alpine support, we noticed that U-Boot with
> > sifive_unmatched_defconfig gets stuck while loading the Alpine
> > initramfs. The last message received on the SiFive UART is:
> >
> > Loading Ramdisk to ffa72000, end fc19 ...
> >
> > Afterwards, U-Boot is stuck. We ran into this problem on two different
> > boards independently. Both with u-boot-2021.10 as well as u-boot master
> > (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set
> > initrd_high manually (i.e. change the address region the Ramdisk is
> > loaded to) everything works as expected. For example, `setenv
> > initrd_high 0x8500`. Maybe the default address region used for the
> > Ramdisk overlaps with the U-Boot stack/text region or something?
> >
> > I am not familiar with U-Boot internals, but briefly looking at the code
> > and how the default Ramdisk address region is calculated, it seems to me
> > that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration
> > for the Unmatched and Unleashed doesn't. If I set it manually everything
> > works as expected. For example:
> >
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index d63a5f62fb..e1d3cb4ec4 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -25,6 +25,7 @@
> >
> > #endif
> >
> > +#define CONFIG_SYS_BOOTMAPSZ (256 << 20)
> > #define CONFIG_SYS_SDRAM_BASE 0x8000
> > #define CONFIG_SYS_INIT_SP_ADDR
> > (CONFIG_SYS_SDRAM_BASE + SZ_2M)
> >
> > This causes the Ramdisk to be loaded to 8f9f7000, end 8b3d by
> > default which, looking at the Unmatched memory map, seems to be a more
> > sensible address region for the Ramdisk:
> >
> > Moving Image from 0x8400 to 0x8020, end=811a9000
> > ## Flattened Device Tree blob at 8800
> >Booting using the fdt blob at 0x8800
> >Loading Ramdisk to 8f9f7000, end 8b3d ... OK
> >Loading Device Tree to 8f9f1000, end 8f9f660b
> > ... OK
> >
> > If there is a better place to report this issue let me know. If you need
> > more information to reproduce/debug this issue I would be very happy to
> > help.
>
> Could you try these two changes together (see below)?
>
> diff --git a/include/configs/sifive-unmatched.h
> b/include/configs/sifive-unmatched.h
> index 7157295..7254e06 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -67,7 +67,7 @@
> "scriptaddr=0x8810\0" \
> "pxefile_addr_r=0x8820\0" \
> "ramdisk_addr_r=0x8830\0" \
> - "kernel_comp_addr_r=0x9000\0" \
> + "kernel_comp_addr_r=0x9030\0" \
> "kernel_comp_size=0x400\0" \
> "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
> "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
>
> diff --git a/include/configs/sifive-unmatched.h
> b/include/configs/sifive-unmatched.h
> index 7254e06..3b72304 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -62,6 +62,8 @@
> "name=system,size=-,bootable,type=${type_guid_gpt_system};"
> #define CONFIG_EXTRA_ENV_SETTINGS \
> + "fdt_high=0x\0" \
> + "initrd_high=0x\0" \
> "kernel_addr_r=0x8400\0" \
> "fdt_addr_r=0x8800\0" \
> "scriptaddr=0x8810\0" \
This second one is a hard NAK. The root problem is, I believe, that
risc-v, until the current dev tree (so v2022.01) doesn't set the flag to
prevent itself from being overwritten when preparing to boot the OS. So
the correct change is indeed to set CONFIG_SYS_BOOTMAPSZ as this does
tell U-Boot to always contain kernel/dtb/initrd to within that size
window, from start of memory (roughly). Disabling dtb/initrd relocation
on the otherhand introduces the different frequent failure of dtb being
loaded at 4-but-not-8-byte-aligned addresses and thus being unusable.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] loads: Block writes into LMB reserved areas of U-Boot
On Fri, Oct 15, 2021 at 04:23:27PM +0200, Marek Vasut wrote:
> On 10/14/21 5:10 PM, Simon Glass wrote:
> [...]
> > > @@ -137,6 +138,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp, int
> > > flag, int argc,
> > >
> > > static ulong load_serial(long offset)
> > > {
> > > + struct lmb lmb;
> > > charrecord[SREC_MAXRECLEN + 1]; /* buffer for one
> > > S-Record */
> > > charbinbuf[SREC_MAXBINLEN]; /* buffer for binary
> > > data */
> > > int binlen; /* no. of data bytes in
> > > S-Rec. */
> > > @@ -147,6 +149,9 @@ static ulong load_serial(long offset)
> > > ulong start_addr = ~0;
> > > ulong end_addr = 0;
> > > int line_count = 0;
> > > + long ret;
> > > +
> > > + lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
> > >
> > > while (read_record(record, SREC_MAXRECLEN + 1) >= 0) {
> > > type = srec_decode(record, , , binbuf);
> > > @@ -172,7 +177,14 @@ static ulong load_serial(long offset)
> > > } else
> > > #endif
> > > {
> > > + ret = lmb_reserve(, store_addr, binlen);
> > > + if (ret) {
> > > + printf("\nCannot overwrite reserved area
> > > (%08lx..%08lx)\n",
> > > + store_addr, store_addr + binlen);
> > > + return ret;
> > > + }
> > > memcpy((char *)(store_addr), binbuf, binlen);
> > > + lmb_free(, store_addr, binlen);
> > > }
> > > if ((store_addr) < start_addr)
> > > start_addr = store_addr;
> > > --
> > > 2.33.0
> > >
> >
> > Reviewed-by: Simon Glass
> >
> > This code looks OK but I don't know what lmb_reserve() and lmb_free()
> > do. Can you add comments to the header file?
>
> Not here, the entire LMB stuff needs (better) documentation, that's where
> (all) such clarification should go.
Is that you saying you'll do such a follow-up patch, given you've
touched this code the most of late?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] board_f: Copy GD to new GD even if relocation disabled
On 10/14/21 3:52 AM, Peng Fan (OSS) wrote:
[...]
diff --git a/common/board_f.c b/common/board_f.c
index 3dc0eaa59c..2161a7411d 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -674,6 +674,7 @@ static int reloc_bloblist(void)
static int setup_reloc(void)
{
if (gd->flags & GD_FLG_SKIP_RELOC) {
+ memcpy(gd->new_gd, (char *)gd, sizeof(gd_t));
debug("Skipping relocation due to flag\n");
return 0;
}
I still think my patch is better :)
https://patchwork.ozlabs.org/project/uboot/patch/20211013095445.18428-1-peng@oss.nxp.com/
But anyway if you prefer, you could have a v2 to include dtb relocation.
Your patch does not reflect the gd->reloc_off update in new_gd in case
GD_SKIP_RELOC_FLAG is NOT set, that's a bug. This patch does not have
that problem. I thought about expanding the if above to deduplicate the
memcpy, but that looked rather ugly, but we can try that instead.
Re: [PATCH] loads: Block writes into LMB reserved areas of U-Boot
On 10/14/21 5:10 PM, Simon Glass wrote:
[...]
@@ -137,6 +138,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp, int flag,
int argc,
static ulong load_serial(long offset)
{
+ struct lmb lmb;
charrecord[SREC_MAXRECLEN + 1]; /* buffer for one S-Record
*/
charbinbuf[SREC_MAXBINLEN]; /* buffer for binary data
*/
int binlen; /* no. of data bytes in S-Rec.
*/
@@ -147,6 +149,9 @@ static ulong load_serial(long offset)
ulong start_addr = ~0;
ulong end_addr = 0;
int line_count = 0;
+ long ret;
+
+ lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
while (read_record(record, SREC_MAXRECLEN + 1) >= 0) {
type = srec_decode(record, , , binbuf);
@@ -172,7 +177,14 @@ static ulong load_serial(long offset)
} else
#endif
{
+ ret = lmb_reserve(, store_addr, binlen);
+ if (ret) {
+ printf("\nCannot overwrite reserved area
(%08lx..%08lx)\n",
+ store_addr, store_addr + binlen);
+ return ret;
+ }
memcpy((char *)(store_addr), binbuf, binlen);
+ lmb_free(, store_addr, binlen);
}
if ((store_addr) < start_addr)
start_addr = store_addr;
--
2.33.0
Reviewed-by: Simon Glass
This code looks OK but I don't know what lmb_reserve() and lmb_free()
do. Can you add comments to the header file?
Not here, the entire LMB stuff needs (better) documentation, that's
where (all) such clarification should go.
Re: [PATCH 1/2] arm64: Add missing GD_FLG_SKIP_RELOC handling
On 10/14/21 3:55 AM, Peng Fan (OSS) wrote: [...] diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 680e674fa3..28c8356aee 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -104,6 +104,10 @@ ENTRY(_main) bic sp, x0, #0xf /* 16-byte alignment for ABI compliance */ ldr x18, [x18, #GD_NEW_GD] /* x18 <- gd->new_gd */ + /* Skip relocation in case gd->gd_flags & GD_FLG_SKIP_RELOC */ + ldr x0, [x18, #GD_FLAGS] /* x0 <- gd->flags */ You are using new_gd, that means bit 11 needs to be set after new_gd has been filled with gd. I would prefer use gd, not new_gd. Both gd and newgd have GD_FLG_SKIP_RELOC set very early on, in u-boot that's currently done by one board in mach_cpu_init, so that should be no problem. Moreover, both gd and newgd flags must be identical as far as I can tell.
[PATCH v2] lmb: Reserve U-Boot separately if relocation is disabled
From: Marek Vasut In case U-Boot starts with GD_FLG_SKIP_RELOC, the U-Boot code is not relocated, however the stack and heap is at the end of DRAM after relocation. Reserve a LMB area for the non-relocated U-Boot code so it won't be overwritten. Signed-off-by: Marek Vasut Cc: Simon Glass Cc: Tom Rini --- V2: Make this fully generic --- lib/lmb.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/lmb.c b/lib/lmb.c index 676b3a0bda..d868633899 100644 --- a/lib/lmb.c +++ b/lib/lmb.c @@ -13,6 +13,7 @@ #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -144,6 +145,10 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp, ulong end, ulong align) bank_end = end - 1; lmb_reserve(lmb, sp, bank_end - sp + 1); + + if (gd->flags & GD_FLG_SKIP_RELOC) + lmb_reserve(lmb, (phys_addr_t)_start, gd->mon_len); + break; } } -- 2.33.0
[PATCH v2] board_f: Copy GD to new GD even if relocation disabled
From: Marek Vasut
Even if U-Boot has relocation disabled via GD_FLG_SKIP_RELOC , the
relocated stage of U-Boot still picks GD from new_gd location. The
U-Boot itself is not relocated, but GD might be, so copy the GD to
new GD location even if relocation is disabled.
Signed-off-by: Marek Vasut
Cc: Peng Fan
Cc: Simon Glass
Cc: Tom Rini
---
V2: Deduplicate memcpy. The patch is better viewed with git show -w
---
common/board_f.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 3dc0eaa59c..7595eaa5b1 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -674,29 +674,33 @@ static int reloc_bloblist(void)
static int setup_reloc(void)
{
if (gd->flags & GD_FLG_SKIP_RELOC) {
- debug("Skipping relocation due to flag\n");
- return 0;
- }
-
+ gd->reloc_off = 0;
+ } else {
#ifdef CONFIG_SYS_TEXT_BASE
#ifdef ARM
- gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start;
+ gd->reloc_off = gd->relocaddr - (unsigned
long)__image_copy_start;
#elif defined(CONFIG_M68K)
- /*
-* On all ColdFire arch cpu, monitor code starts always
-* just after the default vector table location, so at 0x400
-*/
- gd->reloc_off = gd->relocaddr - (CONFIG_SYS_TEXT_BASE + 0x400);
+ /*
+* On all ColdFire arch cpu, monitor code starts always
+* just after the default vector table location, so at 0x400
+*/
+ gd->reloc_off = gd->relocaddr - (CONFIG_SYS_TEXT_BASE + 0x400);
#elif !defined(CONFIG_SANDBOX)
- gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE;
+ gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE;
#endif
#endif
+ }
+
memcpy(gd->new_gd, (char *)gd, sizeof(gd_t));
- debug("Relocation Offset is: %08lx\n", gd->reloc_off);
- debug("Relocating to %08lx, new gd at %08lx, sp at %08lx\n",
- gd->relocaddr, (ulong)map_to_sysmem(gd->new_gd),
- gd->start_addr_sp);
+ if (gd->flags & GD_FLG_SKIP_RELOC) {
+ debug("Skipping relocation due to flag\n");
+ } else {
+ debug("Relocation Offset is: %08lx\n", gd->reloc_off);
+ debug("Relocating to %08lx, new gd at %08lx, sp at %08lx\n",
+ gd->relocaddr, (ulong)map_to_sysmem(gd->new_gd),
+ gd->start_addr_sp);
+ }
return 0;
}
--
2.33.0
Re: HiFive Unmatched: U-Boot stuck when loading Ramdisk
On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel wrote:
>
> Hello,
>
> I hope this is the right way to report u-boot issues. I tried to reach
> out to the RISC-V subsystem maintainer beforehand but didn't receive a
> response, hence sending this to the ML.
>
> We are currently working on Alpine Linux support for the Hifive
> Unmatched and at least two of our developers have access to a board
> presently. While working on Alpine support, we noticed that U-Boot with
> sifive_unmatched_defconfig gets stuck while loading the Alpine
> initramfs. The last message received on the SiFive UART is:
>
> Loading Ramdisk to ffa72000, end fc19 ...
>
> Afterwards, U-Boot is stuck. We ran into this problem on two different
> boards independently. Both with u-boot-2021.10 as well as u-boot master
> (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set
> initrd_high manually (i.e. change the address region the Ramdisk is
> loaded to) everything works as expected. For example, `setenv
> initrd_high 0x8500`. Maybe the default address region used for the
> Ramdisk overlaps with the U-Boot stack/text region or something?
>
> I am not familiar with U-Boot internals, but briefly looking at the code
> and how the default Ramdisk address region is calculated, it seems to me
> that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration
> for the Unmatched and Unleashed doesn't. If I set it manually everything
> works as expected. For example:
>
> diff --git a/include/configs/sifive-unmatched.h
> b/include/configs/sifive-unmatched.h
> index d63a5f62fb..e1d3cb4ec4 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -25,6 +25,7 @@
>
> #endif
>
> +#define CONFIG_SYS_BOOTMAPSZ (256 << 20)
> #define CONFIG_SYS_SDRAM_BASE 0x8000
> #define CONFIG_SYS_INIT_SP_ADDR
> (CONFIG_SYS_SDRAM_BASE + SZ_2M)
>
> This causes the Ramdisk to be loaded to 8f9f7000, end 8b3d by
> default which, looking at the Unmatched memory map, seems to be a more
> sensible address region for the Ramdisk:
>
> Moving Image from 0x8400 to 0x8020, end=811a9000
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9f7000, end 8b3d ... OK
>Loading Device Tree to 8f9f1000, end 8f9f660b ...
> OK
>
> If there is a better place to report this issue let me know. If you need
> more information to reproduce/debug this issue I would be very happy to
> help.
Could you try these two changes together (see below)?
diff --git a/include/configs/sifive-unmatched.h
b/include/configs/sifive-unmatched.h
index 7157295..7254e06 100644
--- a/include/configs/sifive-unmatched.h
+++ b/include/configs/sifive-unmatched.h
@@ -67,7 +67,7 @@
"scriptaddr=0x8810\0" \
"pxefile_addr_r=0x8820\0" \
"ramdisk_addr_r=0x8830\0" \
- "kernel_comp_addr_r=0x9000\0" \
+ "kernel_comp_addr_r=0x9030\0" \
"kernel_comp_size=0x400\0" \
"type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
"type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
diff --git a/include/configs/sifive-unmatched.h
b/include/configs/sifive-unmatched.h
index 7254e06..3b72304 100644
--- a/include/configs/sifive-unmatched.h
+++ b/include/configs/sifive-unmatched.h
@@ -62,6 +62,8 @@
"name=system,size=-,bootable,type=${type_guid_gpt_system};"
#define CONFIG_EXTRA_ENV_SETTINGS \
+ "fdt_high=0x\0" \
+ "initrd_high=0x\0" \
"kernel_addr_r=0x8400\0" \
"fdt_addr_r=0x8800\0" \
"scriptaddr=0x8810\0" \
>
> Greetings,
> Sören
Re: [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file
Hi Wolfgang, On Fri, 15 Oct 2021 at 08:32, Wolfgang Denk wrote: > > Dear Simon Glass, > > In message > <20211014122254.v6.4.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you > wrote: > > At present U-Boot environment variables, and thus scripts, are defined > > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text > > to this file and dealing with quoting and newlines is harder than it > > should be. It would be better if we could just type the script into a > > text file and have it included by U-Boot. > > > > Add a feature that brings in a .env file associated with the board > > config, if present. To use it, create a file in a board//env > > directory called .env (or common.env if you want the same > > environment for all boards). > > Argh... did you bother to read my comments? Apparently not. > > Thus: > > NAKed by: Wolfgang Denk > > > I really think your fixed filename proposal does not work well in > reality. The file name should be Kconfig configurable. See [1] > for details. > > [1] https://lists.denx.de/pipermail/u-boot/2021-October/462668.html Yes I saw that but I forgot to look at it. I think it makes sense - we do that with devicetree, for example. Is that the only thing holding you back? I haven't seen any positive comments to this series yet... Regards, Simon
HiFive Unmatched: U-Boot stuck when loading Ramdisk
Hello, I hope this is the right way to report u-boot issues. I tried to reach out to the RISC-V subsystem maintainer beforehand but didn't receive a response, hence sending this to the ML. We are currently working on Alpine Linux support for the Hifive Unmatched and at least two of our developers have access to a board presently. While working on Alpine support, we noticed that U-Boot with sifive_unmatched_defconfig gets stuck while loading the Alpine initramfs. The last message received on the SiFive UART is: Loading Ramdisk to ffa72000, end fc19 ... Afterwards, U-Boot is stuck. We ran into this problem on two different boards independently. Both with u-boot-2021.10 as well as u-boot master (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set initrd_high manually (i.e. change the address region the Ramdisk is loaded to) everything works as expected. For example, `setenv initrd_high 0x8500`. Maybe the default address region used for the Ramdisk overlaps with the U-Boot stack/text region or something? I am not familiar with U-Boot internals, but briefly looking at the code and how the default Ramdisk address region is calculated, it seems to me that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration for the Unmatched and Unleashed doesn't. If I set it manually everything works as expected. For example: diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index d63a5f62fb..e1d3cb4ec4 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -25,6 +25,7 @@ #endif +#define CONFIG_SYS_BOOTMAPSZ (256 << 20) #define CONFIG_SYS_SDRAM_BASE 0x8000 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + SZ_2M) This causes the Ramdisk to be loaded to 8f9f7000, end 8b3d by default which, looking at the Unmatched memory map, seems to be a more sensible address region for the Ramdisk: Moving Image from 0x8400 to 0x8020, end=811a9000 ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Loading Ramdisk to 8f9f7000, end 8b3d ... OK Loading Device Tree to 8f9f1000, end 8f9f660b ... OK If there is a better place to report this issue let me know. If you need more information to reproduce/debug this issue I would be very happy to help. Greetings, Sören
Re: [PATCH v5 2/2] firmware: zynqmp: return status in EL2 from xilinx_pm_request.
On 10/14/21 14:43, Adrian Fiergolski wrote: This patch fixes xilinx_pm_request to return a valid status from xilinx_pm_request in EL2. Signed-off-by: Adrian Fiergolski --- drivers/firmware/firmware-zynqmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/firmware-zynqmp.c b/drivers/firmware/firmware-zynqmp.c index 8273437dd9..34ad7fb985 100644 --- a/drivers/firmware/firmware-zynqmp.c +++ b/drivers/firmware/firmware-zynqmp.c @@ -208,7 +208,7 @@ int __maybe_unused xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32 arg2, ret_payload[4] = (u32)regs.regs[2]; } - ret = (ret_payload) ? ret_payload[0] : 0; + ret = (int)regs.regs[0]; } return ret; } I have tested this series and our expectation that regs.regs[0] is return value is not unfortunately correct. mmio_read/write are not aligned to it. And when you try to boot you will see hang without any message. I sent 2 patches as suggestion how we could do it via ipi_req(). Please take a look at it and let me know your opinion. Thanks, Michal
[PATCH 2/2] firmware: zynqmp: fix write to an uninitialised pointer in ipi_req()
When a caller is not interested in the returned message, the ret_payload
pointer is set to NULL in the u-boot-sources. In this case, under EL3, the
memory from address 0x0 would be overwritten by ipi_req() with the returned
IPI message, damaging the original data under this address. The patch, in
case ret_payload is NULL, assigns the pointer to the array holding the IPI
message being sent.
Signed-off-by: Adrian Fiergolski
Signed-off-by: Michal Simek
---
Based on origin series from Adrian. That's why also adding his SoB line.
https://lore.kernel.org/r/20211014124349.1429696-1-adrian.fiergol...@fastree3d.com
Adrian: The patch is just suggestion how we could avoid that NULL pointer
writes but done in ipi_req()
---
drivers/firmware/firmware-zynqmp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 1391aab0a160..7e498d8169e8 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -30,6 +30,10 @@ static int ipi_req(const u32 *req, size_t req_len, u32 *res,
size_t res_maxlen)
{
struct zynqmp_ipi_msg msg;
int ret;
+ u32 buffer[PAYLOAD_ARG_CNT];
+
+ if (!res)
+ res = buffer;
if (req_len > PMUFW_PAYLOAD_ARG_CNT ||
res_maxlen > PMUFW_PAYLOAD_ARG_CNT)
--
2.33.1
[PATCH 1/2] firmware: zynqmp: Handle errors from ipi_req properly
There are multiple errors what can happen in ipi_req but they are not
propagated properly. That's why propage all error properly.
Signed-off-by: Michal Simek
---
drivers/firmware/firmware-zynqmp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index c22bdca282fc..1391aab0a160 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -165,6 +165,7 @@ int __maybe_unused xilinx_pm_request(u32 api_id, u32 arg0,
u32 arg1, u32 arg2,
* firmware API is limited by the SMC call size
*/
u32 regs[] = {api_id, arg0, arg1, arg2, arg3};
+ int ret;
if (api_id == PM_FPGA_LOAD) {
/* Swap addr_hi/low because of incompatibility */
@@ -174,7 +175,10 @@ int __maybe_unused xilinx_pm_request(u32 api_id, u32 arg0,
u32 arg1, u32 arg2,
regs[2] = temp;
}
- ipi_req(regs, PAYLOAD_ARG_CNT, ret_payload, PAYLOAD_ARG_CNT);
+ ret = ipi_req(regs, PAYLOAD_ARG_CNT, ret_payload,
+ PAYLOAD_ARG_CNT);
+ if (ret)
+ return ret;
#else
return -EPERM;
#endif
--
2.33.1
[PATCH] arm: mvebu: Add missing "if SPL"
We can only select SPL_SKIP_LOWLEVEL_INIT if SPL is enabled, otherwise
we get a warning about unmet dependencies on platforms that don't use
SPL.
Fixes: cf47a8cf8f7e ("arm: mvebu: Select SPL_SKIP_LOWLEVEL_INIT on
ARMADA_32BIT")
Cc: Stefan Roese
Signed-off-by: Tom Rini
---
arch/arm/mach-mvebu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 54dff9986b41..c9dbef2e6392 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -11,7 +11,7 @@ config ARMADA_32BIT
select SPL_DM if SPL
select SPL_DM_SEQ_ALIAS if SPL
select SPL_OF_CONTROL if SPL
- select SPL_SKIP_LOWLEVEL_INIT
+ select SPL_SKIP_LOWLEVEL_INIT if SPL
select SPL_SIMPLE_BUS if SPL
select SUPPORT_SPL
select TRANSLATION_OFFSET
--
2.25.1
Re: [PATCH v6 7/7] bootm: Tidy up use of autostart env var
Dear Simon Glass, In message <20211014182257.468649-6-...@chromium.org> you wrote: > This has different semantics in different places. Go with the bootm method > and put it in a common function so that the behaviour is consistent in > U-Boot. Update the docs. > > Signed-off-by: Simon Glass > Suggested-by: Wolfgang Denk It should be noted that this commit changes the behaviour of U-Boot for "autostart" users, thus it has the potential of breaking existent systems. The problematic cases are in do_bootelf() [cmd/elf.c] and do_bootm_standalone() [common/bootm_os.c]; the 3rd place where this is used - bootm_maybe_autostart() [cmd/bootm.c] - does not change. Or am I missing something? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_
Re: Broken build with disabling OpenSSL crypto
On 10/15/21 6:34 AM, Pali Rohár wrote:
On Wednesday 06 October 2021 17:05:24 Alex G. wrote:
Hi Jernej,
On 10/6/21 4:27 PM, Jernej Škrabec wrote:
Hi everyone!
Commit cb9faa6f98ae ("tools: Use a single target-independent config to enable
OpenSSL") recently introduced option to disable usage of OpenSSL via
CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit b4f3cc2c42d9
("tools: kwbimage: Do not hide usage of secure header under
CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That totally
defeats the purpose of first commit. I suggest that it gets reverted.
I would like disable OpenSSL for my usage, since it gives me troubles when
cross-compiling U-Boot inside LibreELEC build system. It's not needed for our
case anyway.
Best regards,
Can you please give the following diff a try, and if it works for you, submit
as patch?
This change is incorrect and will break mvebu builds. mvebu requires
kwbimage for building boot images and so you cannot disable it or make
it optional.
If kwbimage is required and missing the CI builds and tests don't catch
that. I ran buildman with the change, and nothing broke. Sounds like
that needs to be addressed.
That being said, I'm not okay with making everyone a slave to OpenSSL
because of any given platform.
I propose to revert commit b4f3cc2c42d9 ("tools: kwbimage: Do not hide
usage of secure header under CONFIG_ARMADA_38X"), and rework it such
that it doesn't force libcrypto on everyone. And we very likely need a
CI test against libcrypto linkage when TOOLS_LIBCRYPTO is not set.
Alex
diff --git a/tools/Makefile b/tools/Makefile
index 4a86321f64..7f72ff9645 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \
# Cryptographic helpers that depend on openssl/libcrypto
LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
- fdt-libcrypto.o)
+ fdt-libcrypto.o) \
+ kwbimage.o
ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
@@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
imximage.o \
imx8image.o \
imx8mimage.o \
- kwbimage.o \
lib/md5.o \
lpc32xximage.o \
mxsimage.o \
@@ -169,8 +169,8 @@ HOST_EXTRACFLAGS+=
-DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER
endif
-# MXSImage needs LibSSL
-ifneq
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
+# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
+ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
HOSTCFLAGS_kwbimage.o += \
$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
HOSTLDLIBS_mkimage += \
Re: [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file
Dear Simon Glass, In message <20211014122254.v6.4.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you wrote: > At present U-Boot environment variables, and thus scripts, are defined > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text > to this file and dealing with quoting and newlines is harder than it > should be. It would be better if we could just type the script into a > text file and have it included by U-Boot. > > Add a feature that brings in a .env file associated with the board > config, if present. To use it, create a file in a board//env > directory called .env (or common.env if you want the same > environment for all boards). Argh... did you bother to read my comments? Apparently not. Thus: NAKed by: Wolfgang Denk I really think your fixed filename proposal does not work well in reality. The file name should be Kconfig configurable. See [1] for details. [1] https://lists.denx.de/pipermail/u-boot/2021-October/462668.html Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "There's always been Tower of Babel sort of bickering inside Unix, but this is the most extreme form ever. This means at least several years of confusion." - Bill Gates, founder and chairman of Microsoft, about the Open Systems Foundation
Re: [PATCH v2 09/13] env: Use string pointer instead of indexes in env_get_f()
Hi Simon, On Thu, 14 Oct 2021 18:40:02 -0600 Simon Glass wrote: > > -static int env_match(const char *env, const char *s1, int i2) > > +static const char *matching_name_get_value(const char *p, const > > char *name) > > OK so this is the function where I would like a nice comment, please. Now that I look at it, I notice that it also works for cases when name is "abc=def" (it matches just "abc"). This was the purpose of env_match() before, but env_get_f() does not use it that way, and this functionality can now be removed. This would simplify the code to something like len = strlen(name); if (p[len] == '=' && !strncmp(p, name, len)) return [len + 1]; return NULL; And this is simple enough to be inlined into env_get_f(). I will refactor this and send v3. Marek
Re: [PATCH v3 1/3] dm: core: Bind another driver with the same compatible string
On 10/14/21 17:09, Simon Glass wrote:
Hi Michal,
On Wed, 6 Oct 2021 at 08:19, Michal Simek wrote:
When one IP can have multiple configurations (like timer and PWM) covered
by multiple drivers. Because it is the same IP it should also have the same
compatible string.
Current code look for the first driver which matches compatible string and
call bind function. If this is not the right driver which is express by
returning -ENODEV ("Driver XYZ refuses to bind") there is no reason not to
continue over compatible list to try to find out different driver with the
same compatible string which match it.
When the first compatible string is found core looks for driver bind()
function. If if assigned driver refuse to bind, core continue in a loop to
check if there is another driver which match compatible string.
This driver is going to be used with cdnc,ttc driver which has driver as
timer and also can be used as PWM. The difference is done via #pwm-cells
property in DT.
Signed-off-by: Michal Simek
---
Changes in v3:
- New patch in series
drivers/core/lists.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Can you refactor this to avoid the 'goto'? E.g. put the loop in a new function?
Sent v4 with adding one more loop. There are so many parameters use that
new function won't really help.
Also, if pre_reloc_only, it still quits. Don't you want it to continue
in that case too?
Also fixed in v4.
Finally, can you add such a driver to sandbox test.dts and add a check
in test/dm/core.c or similar so that this behaviour is tested?
When the patch is acked I will take a look at writing test case for it.
I have tested it with pwm driver to see proper behavior.
Thanks,
Michal
[PATCH v4 3/4] pwm: Add driver for cadence TTC
TTC has three modes of operations. Timer, PWM and input counters.
There is already driver for timer under CADENCE_TTC_TIMER which is used for
ZynqMP R5 configuration.
This driver is targeting PWM which is for example configuration which can
be used for fan control.
The driver has been tested on Xilinx Kria SOM platform where fan is
connected to one PL pin. When TTC output is connected via EMIO to PL pin
TTC pwm can be configured and tested for example like this:
pwm config 0 0 1 1200
pwm enable 0 0
pwm config 0 0 1 1400
pwm config 0 0 1 1600
Signed-off-by: Michal Simek
Reviewed-by: Sean Anderson
---
Changes in v4:
- - Add reviewed-by tag
Changes in v3:
- Add bind function to check pwm-cells to recognize PWM driver
- Use timer-width in prescaler calculation
- Record timer width in platdata instead of timer mask
- Also disable wave out in config function
Changes in v2:
- Detect pwm-cells property for PWM driver
- Fix all macro names
- Use BIT and GENMASK macros
- Introduce TTC_REG macro for reg offsets
- Use FIELD_PREP
- Move cadence_ttc_pwm_of_to_plat() below probe
- Introduce struct cadence_ttc_pwm_plat
- Read timer-width from DT
- Use NSEC_PER_SEC macro
- Use clock_ctrl variable instead of x - all reported by Sean
MAINTAINERS | 1 +
drivers/pwm/Kconfig | 7 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-cadence-ttc.c | 261 ++
4 files changed, 270 insertions(+)
create mode 100644 drivers/pwm/pwm-cadence-ttc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 71f468c00a8f..d8873e520c8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -599,6 +599,7 @@ F: drivers/mmc/zynq_sdhci.c
F: drivers/mtd/nand/raw/zynq_nand.c
F: drivers/net/phy/xilinx_phy.c
F: drivers/net/zynq_gem.c
+F: drivers/pwm/pwm-cadence-ttc.c
F: drivers/serial/serial_zynq.c
F: drivers/reset/reset-zynqmp.c
F: drivers/rtc/zynqmp_rtc.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 669d3fa4fc59..ec205ae4fa8a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -15,6 +15,13 @@ config PWM_AT91
help
Support for PWM hardware on AT91 based SoC.
+config PWM_CADENCE_TTC
+ bool "Enable support for the Cadence TTC PWM"
+ depends on DM_PWM && !CADENCE_TTC_TIMER
+ help
+ Cadence TTC can be configured as timer which is done via
+ CONFIG_CADENCE_TTC_TIMER or as PWM. This is covering only PWM now.
+
config PWM_CROS_EC
bool "Enable support for the Chrome OS EC PWM"
depends on DM_PWM
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 55f2bc081d25..54413c689cac 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,6 +11,7 @@
obj-$(CONFIG_DM_PWM) += pwm-uclass.o
obj-$(CONFIG_PWM_AT91) += pwm-at91.o
+obj-$(CONFIG_PWM_CADENCE_TTC) += pwm-cadence-ttc.o
obj-$(CONFIG_PWM_CROS_EC) += cros_ec_pwm.o
obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
diff --git a/drivers/pwm/pwm-cadence-ttc.c b/drivers/pwm/pwm-cadence-ttc.c
new file mode 100644
index ..dc3b314b0cce
--- /dev/null
+++ b/drivers/pwm/pwm-cadence-ttc.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2021 Xilinx, Inc. Michal Simek
+ */
+
+#define LOG_CATEGORY UCLASS_PWM
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CLOCK_CONTROL 0
+#define COUNTER_CONTROL0xc
+#define INTERVAL_COUNTER 0x24
+#define MATCH_1_COUNTER0x30
+
+#define CLK_FALLING_EDGE BIT(6)
+#define CLK_SRC_EXTERNAL BIT(5)
+#define CLK_PRESCALE_MASK GENMASK(4, 1)
+#define CLK_PRESCALE_ENABLEBIT(0)
+
+#define COUNTER_WAVE_POL BIT(6)
+#define COUNTER_WAVE_DISABLE BIT(5)
+#define COUNTER_RESET BIT(4)
+#define COUNTER_MATCH_ENABLE BIT(3)
+#define COUNTER_DECREMENT_ENABLE BIT(2)
+#define COUNTER_INTERVAL_ENABLEBIT(1)
+#define COUNTER_COUNTING_DISABLE BIT(0)
+
+#define NSEC_PER_SEC 10L
+
+#define TTC_REG(reg, channel) ((reg) + (channel) * sizeof(u32))
+#define TTC_CLOCK_CONTROL(reg, channel) \
+ TTC_REG((reg) + CLOCK_CONTROL, (channel))
+#define TTC_COUNTER_CONTROL(reg, channel) \
+ TTC_REG((reg) + COUNTER_CONTROL, (channel))
+#define TTC_INTERVAL_COUNTER(reg, channel) \
+ TTC_REG((reg) + INTERVAL_COUNTER, (channel))
+#define TTC_MATCH_1_COUNTER(reg, channel) \
+ TTC_REG((reg) + MATCH_1_COUNTER, (channel))
+
+struct cadence_ttc_pwm_plat {
+ u8 *regs;
+ u32 timer_width;
+};
+
+struct cadence_ttc_pwm_priv {
+ u8 *regs;
+ u32 timer_width;
+ u32 timer_mask;
+ unsigned long frequency;
+ bool invert[2];
+};
+
+static int cadence_ttc_pwm_set_invert(struct udevice *dev, uint
[PATCH v4 4/4] arm: zynqmp: Enable PWM command and cadence ttc pwm driver
Enable PWM ttc driver and command in generic image. Signed-off-by: Michal Simek --- Changes in v4: - New patch in the series configs/xilinx_zynqmp_virt_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 7401078c113e..94a45f293b9b 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -52,6 +52,7 @@ CONFIG_CMD_FPGA_LOADBP=y CONFIG_CMD_FPGA_LOADP=y CONFIG_CMD_FPGA_LOAD_SECURE=y CONFIG_CMD_GPIO=y +CONFIG_CMD_PWM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -160,6 +161,8 @@ CONFIG_XILINX_AXIEMAC=y CONFIG_ZYNQ_GEM=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_PWM=y +CONFIG_PWM_CADENCE_TTC=y CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y CONFIG_RTC_ZYNQMP=y -- 2.33.1
[PATCH v4 2/4] timer: cadence: Add bind function to driver
When DT node has pwm-cells property it shouldn't be bind as timer driver
but as PWM driver. That's why make sure that this property is checked.
Signed-off-by: Michal Simek
Reviewed-by: Sean Anderson
Reviewed-by: Simon Glass
---
Changes in v4:
- Add reviewed-by tags
Changes in v3:
- New patch in series
drivers/timer/cadence-ttc.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/timer/cadence-ttc.c b/drivers/timer/cadence-ttc.c
index 2f95d45ecd7a..2eff45060ad6 100644
--- a/drivers/timer/cadence-ttc.c
+++ b/drivers/timer/cadence-ttc.c
@@ -97,6 +97,17 @@ static int cadence_ttc_of_to_plat(struct udevice *dev)
return 0;
}
+static int cadence_ttc_bind(struct udevice *dev)
+{
+ const char *cells;
+
+ cells = dev_read_prop(dev, "#pwm-cells", NULL);
+ if (cells)
+ return -ENODEV;
+
+ return 0;
+}
+
static const struct timer_ops cadence_ttc_ops = {
.get_count = cadence_ttc_get_count,
};
@@ -114,4 +125,5 @@ U_BOOT_DRIVER(cadence_ttc) = {
.priv_auto = sizeof(struct cadence_ttc_priv),
.probe = cadence_ttc_probe,
.ops = _ttc_ops,
+ .bind = cadence_ttc_bind,
};
--
2.33.1
[PATCH v4 1/4] dm: core: Bind another driver with the same compatible string
When one IP can have multiple configurations (like timer and PWM) covered
by multiple drivers. Because it is the same IP it should also have the same
compatible string.
Current code look for the first driver which matches compatible string and
call bind function. If this is not the right driver which is express by
returning -ENODEV ("Driver XYZ refuses to bind") there is no reason not to
continue over compatible list to try to find out different driver with the
same compatible string which match it.
When the first compatible string is found core looks for driver bind()
function. If if assigned driver refuse to bind, core continue in a loop to
check if there is another driver which match compatible string.
This driver is going to be used with cdnc,ttc driver which has driver as
timer and also can be used as PWM. The difference is done via #pwm-cells
property in DT.
Signed-off-by: Michal Simek
---
Changes in v4:
- Remove goto from code
- Also continue on prereloc case
Changes in v3:
- New patch in series
When this is acked I will spent my time on writing test for it.
---
drivers/core/lists.c | 84 +++-
1 file changed, 52 insertions(+), 32 deletions(-)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 5d4f2ea0e3ad..8b655db68edb 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -221,45 +221,65 @@ int lists_bind_fdt(struct udevice *parent, ofnode node,
struct udevice **devp,
compat = compat_list + i;
log_debug(" - attempt to match compatible string '%s'\n",
compat);
-
- for (entry = driver; entry != driver + n_ents; entry++) {
- ret = driver_check_compatible(entry->of_match, ,
- compat);
- if ((drv) && (drv == entry))
- break;
- if (!ret)
+ entry = driver;
+
+ while (1) {
+ for (; entry != driver + n_ents; entry++) {
+ ret = driver_check_compatible(entry->of_match,
+ , compat);
+ if (drv && drv == entry)
+ break;
+ if (!ret)
+ break;
+ }
+ /*
+* Reach the last entry - time to look at next
+* compatible string.
+*/
+ if (entry == driver + n_ents)
break;
- }
- if (entry == driver + n_ents)
- continue;
-
- if (pre_reloc_only) {
- if (!ofnode_pre_reloc(node) &&
- !(entry->flags & DM_FLAG_PRE_RELOC)) {
- log_debug("Skipping device pre-relocation\n");
- return 0;
+
+ if (pre_reloc_only) {
+ if (!ofnode_pre_reloc(node) &&
+ !(entry->flags & DM_FLAG_PRE_RELOC)) {
+ log_debug("Skipping device
pre-relocation\n");
+ entry++;
+ continue;
+ }
}
- }
- log_debug(" - found match at '%s': '%s' matches '%s'\n",
- entry->name, entry->of_match->compatible,
- id->compatible);
- ret = device_bind_with_driver_data(parent, entry, name,
- id->data, node, );
- if (ret == -ENODEV) {
- log_debug("Driver '%s' refuses to bind\n", entry->name);
- continue;
- }
- if (ret) {
- dm_warn("Error binding driver '%s': %d\n", entry->name,
- ret);
- return log_msg_ret("bind", ret);
- } else {
+ log_debug(" - found match at '%s': '%s' matches
'%s'\n",
+ entry->name, entry->of_match->compatible,
+ id->compatible);
+ ret = device_bind_with_driver_data(parent, entry, name,
+ id->data, node,
+ );
+ /*
+* Driver found but didn't bind properly try another one
+*/
+ if (ret == -ENODEV) {
+ log_debug("Driver '%s' refuses to bind\n",
+
[PATCH v2 9/9] board: sl28: enable USB periheral support and gadgets
Enable support to update the board via the DFU protocol and make it possible to export the block devices via USB mass storage protocol. This will not work out of the box, yet. You have to change the dr_mode of the usb0 controller to peripheral manually to make it work. True, OTG support will hopefully coming soon. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 5b3ba58d39..0da31a4e54 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -39,12 +39,14 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x23 CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_NVEDIT_EFI=y +CONFIG_CMD_DFU=y CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_RNG=y @@ -90,9 +92,12 @@ CONFIG_FSL_DSPI=y CONFIG_NXP_FSPI=y CONFIG_USB=y # CONFIG_SPL_DM_USB is not set +CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_FSL is not set CONFIG_USB_DWC3=y CONFIG_USB_DWC3_LAYERSCAPE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y -- 2.30.2
[PATCH v2 7/9] usb: dwc3: add layerscape support
Add support for the proper dwc3 device tree binding support as specified
in the offical device tree spec.
Initially, add support for the LS1028A support. Other SoCs should be
easy to add by just adding the corresponding compatible string.
Unfortunately, the device trees of all other layerscape SoCs are not
converted and uses a wrong compatible string only known in u-boot.
To maintain backwards compatibility with current u-boot device trees,
add the generic "fsl,layerscape-dwc3" compatible string.
OTG mode is not supported yet. The dr_mode in the devicetree will either
have to be set to peripheral or host.
Signed-off-by: Michael Walle
---
drivers/usb/dwc3/Kconfig | 10 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-layerscape.c | 222 +
3 files changed, 233 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-layerscape.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 93707e05fb..62aa65bf0c 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -53,6 +53,16 @@ config USB_DWC3_UNIPHIER
Support of USB2/3 functionality in Socionext UniPhier platforms.
Say 'Y' here if you have one such device.
+config USB_DWC3_LAYERSCAPE
+ bool "Freescale Layerscape platform support"
+ depends on DM_USB && USB_DWC3
+ depends on !USB_XHCI_FSL
+ help
+ Select this for Freescale Layerscape Platforms.
+
+ Host and Peripheral operation modes are supported. OTG is not
+ supported.
+
menu "PHY Subsystem"
config USB_DWC3_PHY_OMAP
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 6e3e024e97..0dd1ba87cd 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_USB_DWC3_MESON_G12A) += dwc3-meson-g12a.o
obj-$(CONFIG_USB_DWC3_MESON_GXL) += dwc3-meson-gxl.o
obj-$(CONFIG_USB_DWC3_GENERIC) += dwc3-generic.o
obj-$(CONFIG_USB_DWC3_UNIPHIER)+= dwc3-uniphier.o
+obj-$(CONFIG_USB_DWC3_LAYERSCAPE) += dwc3-layerscape.o
obj-$(CONFIG_USB_DWC3_PHY_OMAP)+= ti_usb_phy.o
obj-$(CONFIG_USB_DWC3_PHY_SAMSUNG) += samsung_usb_phy.o
diff --git a/drivers/usb/dwc3/dwc3-layerscape.c
b/drivers/usb/dwc3/dwc3-layerscape.c
new file mode 100644
index 00..79cf71f7a8
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-layerscape.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Layerscape DWC3 Glue layer
+ *
+ * Copyright (C) 2021 Michael Walle
+ *
+ * Based on dwc3-generic.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "gadget.h"
+#include
+
+struct dwc3_layerscape_plat {
+ fdt_addr_t base;
+ u32 maximum_speed;
+ enum usb_dr_mode dr_mode;
+};
+
+struct dwc3_layerscape_priv {
+ void *base;
+ struct dwc3 dwc3;
+ struct phy_bulk phys;
+};
+
+struct dwc3_layerscape_host_priv {
+ struct xhci_ctrl xhci_ctrl;
+ struct dwc3_layerscape_priv gen_priv;
+};
+
+static int dwc3_layerscape_probe(struct udevice *dev,
+struct dwc3_layerscape_priv *priv)
+{
+ int rc;
+ struct dwc3_layerscape_plat *plat = dev_get_plat(dev);
+ struct dwc3 *dwc3 = >dwc3;
+
+ dwc3->dev = dev;
+ dwc3->maximum_speed = plat->maximum_speed;
+ dwc3->dr_mode = plat->dr_mode;
+ if (CONFIG_IS_ENABLED(OF_CONTROL))
+ dwc3_of_parse(dwc3);
+
+ rc = dwc3_setup_phy(dev, >phys);
+ if (rc && rc != -ENOTSUPP)
+ return rc;
+
+ priv->base = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
+ dwc3->regs = priv->base + DWC3_GLOBALS_REGS_START;
+
+ rc = dwc3_init(dwc3);
+ if (rc) {
+ unmap_physmem(priv->base, MAP_NOCACHE);
+ return rc;
+ }
+
+ return 0;
+}
+
+static int dwc3_layerscape_remove(struct udevice *dev,
+ struct dwc3_layerscape_priv *priv)
+{
+ struct dwc3 *dwc3 = >dwc3;
+
+ dwc3_remove(dwc3);
+ dwc3_shutdown_phy(dev, >phys);
+ unmap_physmem(dwc3->regs, MAP_NOCACHE);
+
+ return 0;
+}
+
+static int dwc3_layerscape_of_to_plat(struct udevice *dev)
+{
+ struct dwc3_layerscape_plat *plat = dev_get_plat(dev);
+ ofnode node = dev_ofnode(dev);
+
+ plat->base = dev_read_addr(dev);
+
+ plat->maximum_speed = usb_get_maximum_speed(node);
+ if (plat->maximum_speed == USB_SPEED_UNKNOWN) {
+ dev_dbg(dev, "No USB maximum speed specified. Using super
speed\n");
+ plat->maximum_speed = USB_SPEED_SUPER;
+ }
+
+ plat->dr_mode = usb_get_dr_mode(node);
+ if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
+ dev_err(dev, "Invalid usb mode setup\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+int
[PATCH v2 6/9] usb: dwc3: Enable undefined length INCR burst type
[backport from linux commit d9612c2f0449e24983a8b689603210486a930c90]
Enable the undefined length INCR burst type and set INCRx.
Different platform may has the different burst size type.
In order to get best performance, we need to tune the burst
size to one special value, instead of the default value.
Signed-off-by: Michael Walle
---
drivers/usb/dwc3/core.c | 69 +
drivers/usb/dwc3/core.h | 16 ++
2 files changed, 85 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4fb6b59d50..ce1c0e88c2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -462,6 +462,53 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
mdelay(100);
}
+/* set global incr burst type configuration registers */
+static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
+{
+ struct udevice *dev = dwc->dev;
+ u32 cfg;
+
+ if (!dwc->incrx_size)
+ return;
+
+ cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
+
+ /* Enable Undefined Length INCR Burst and Enable INCRx Burst */
+ cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
+ if (dwc->incrx_mode)
+ cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
+ switch (dwc->incrx_size) {
+ case 256:
+ cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
+ break;
+ case 128:
+ cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
+ break;
+ case 64:
+ cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
+ break;
+ case 32:
+ cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
+ break;
+ case 16:
+ cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
+ break;
+ case 8:
+ cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
+ break;
+ case 4:
+ cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
+ break;
+ case 1:
+ break;
+ default:
+ dev_err(dev, "Invalid property\n");
+ break;
+ }
+
+ dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
+}
+
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -593,6 +640,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc, dwc->fladj);
+ dwc3_set_incr_burst_type(dwc);
+
return 0;
err1:
@@ -916,6 +965,8 @@ void dwc3_of_parse(struct dwc3 *dwc)
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
u8 hird_threshold;
+ u32 val;
+ int i;
/* default to highest possible threshold */
lpm_nyet_threshold = 0xff;
@@ -984,6 +1035,24 @@ void dwc3_of_parse(struct dwc3 *dwc)
| (dwc->is_utmi_l1_suspend << 4);
dev_read_u32(dev, "snps,quirk-frame-length-adjustment", >fladj);
+
+ /*
+* Handle property "snps,incr-burst-type-adjustment".
+* Get the number of value from this property:
+* result <= 0, means this property is not supported.
+* result = 1, means INCRx burst mode supported.
+* result > 1, means undefined length burst mode supported.
+*/
+ dwc->incrx_mode = INCRX_BURST_MODE;
+ dwc->incrx_size = 0;
+ for (i = 0; i < 8; i++) {
+ if (dev_read_u32_index(dev, "snps,incr-burst-type-adjustment",
+ i, ))
+ break;
+
+ dwc->incrx_mode = INCRX_UNDEF_LENGTH_BURST_MODE;
+ dwc->incrx_size = max(dwc->incrx_size, val);
+ }
}
int dwc3_init(struct dwc3 *dwc)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 62e4df74fa..d7cce3a861 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -139,6 +139,17 @@
/* Bit fields */
+/* Global SoC Bus Configuration INCRx Register 0 */
+#define DWC3_GSBUSCFG0_INCR256BRSTENA (1 << 7) /* INCR256 burst */
+#define DWC3_GSBUSCFG0_INCR128BRSTENA (1 << 6) /* INCR128 burst */
+#define DWC3_GSBUSCFG0_INCR64BRSTENA (1 << 5) /* INCR64 burst */
+#define DWC3_GSBUSCFG0_INCR32BRSTENA (1 << 4) /* INCR32 burst */
+#define DWC3_GSBUSCFG0_INCR16BRSTENA (1 << 3) /* INCR16 burst */
+#define DWC3_GSBUSCFG0_INCR8BRSTENA(1 << 2) /* INCR8 burst */
+#define DWC3_GSBUSCFG0_INCR4BRSTENA(1 << 1) /* INCR4 burst */
+#define DWC3_GSBUSCFG0_INCRBRSTENA (1 << 0) /* undefined length enable */
+#define DWC3_GSBUSCFG0_INCRBRST_MASK 0xff
+
/* Global Configuration Register */
#define DWC3_GCTL_PWRDNSCALE(n)((n) << 19)
#define DWC3_GCTL_U2RSTECN (1 << 16)
@@ -818,6 +829,8 @@ struct dwc3 {
u8 lpm_nyet_threshold;
u8 hird_threshold;
u32 fladj;
+ u8 incrx_mode;
+ u32 incrx_size;
unsigneddelayed_status:1;
unsigned
[PATCH v2 8/9] board: sl28: switch to dwc3 driver
Now that the DWC3 USB driver has support for the layerscape platform, use it. This will have the benefit that peripheral mode will work. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 4e25dafaaf..5b3ba58d39 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -91,6 +91,8 @@ CONFIG_NXP_FSPI=y CONFIG_USB=y # CONFIG_SPL_DM_USB is not set CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y +# CONFIG_USB_XHCI_FSL is not set +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_LAYERSCAPE=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y -- 2.30.2
[PATCH v2 4/9] usb: common: silence dubious errors
Both dr_mode and maximum-speed properties are usually optional. Drivers
will still try to fetch the properties nonetheless, which leads to error
messages, although they are no errors. Change pr_err() to pr_debug().
Signed-off-by: Michael Walle
---
drivers/usb/common/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 43564c9fba..ee0c064f1f 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -29,7 +29,7 @@ enum usb_dr_mode usb_get_dr_mode(ofnode node)
dr_mode = ofnode_read_string(node, "dr_mode");
if (!dr_mode) {
- pr_err("usb dr_mode not found\n");
+ pr_debug("usb dr_mode not found\n");
return USB_DR_MODE_UNKNOWN;
}
@@ -64,7 +64,7 @@ enum usb_device_speed usb_get_maximum_speed(ofnode node)
max_speed = ofnode_read_string(node, "maximum-speed");
if (!max_speed) {
- pr_err("usb maximum-speed not found\n");
+ pr_debug("usb maximum-speed not found\n");
return USB_SPEED_UNKNOWN;
}
--
2.30.2
[PATCH v2 5/9] usb: dwc3: Add frame length adjustment quirk
[backport from linux commit db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3]
Add adjust_frame_length_quirk for writing to fladj register
which adjusts (micro)frame length to value provided by
"snps,quirk-frame-length-adjustment" property thus avoiding
USB 2.0 devices to time-out over a longer run
Signed-off-by: Michael Walle
---
drivers/usb/dwc3/core.c | 26 ++
drivers/usb/dwc3/core.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index dfd7cf683f..4fb6b59d50 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -93,6 +93,27 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
return 0;
}
+/*
+ * dwc3_frame_length_adjustment - Adjusts frame length if required
+ * @dwc3: Pointer to our controller context structure
+ * @fladj: Value of GFLADJ_30MHZ to adjust frame length
+ */
+static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
+{
+ u32 reg;
+
+ if (dwc->revision < DWC3_REVISION_250A)
+ return;
+
+ if (fladj == 0)
+ return;
+
+ reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
+ reg &= ~DWC3_GFLADJ_30MHZ_MASK;
+ reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | fladj;
+ dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
+}
+
/**
* dwc3_free_one_event_buffer - Frees one event buffer
* @dwc: Pointer to our controller context structure
@@ -569,6 +590,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err1;
+ /* Adjust Frame Length */
+ dwc3_frame_length_adjustment(dwc, dwc->fladj);
+
return 0;
err1:
@@ -958,6 +982,8 @@ void dwc3_of_parse(struct dwc3 *dwc)
dwc->hird_threshold = hird_threshold
| (dwc->is_utmi_l1_suspend << 4);
+
+ dev_read_u32(dev, "snps,quirk-frame-length-adjustment", >fladj);
}
int dwc3_init(struct dwc3 *dwc)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 1502cb859a..62e4df74fa 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -115,6 +115,7 @@
#define DWC3_GEVNTCOUNT(n) (0xc40c + (n * 0x10))
#define DWC3_GHWPARAMS80xc600
+#define DWC3_GFLADJ0xc630
/* Device Registers */
#define DWC3_DCFG 0xc700
@@ -233,6 +234,10 @@
/* Global HWPARAMS6 Register */
#define DWC3_GHWPARAMS6_EN_FPGA(1 << 7)
+/* Global Frame Length Adjustment Register */
+#define DWC3_GFLADJ_30MHZ_SDBND_SEL(1 << 7)
+#define DWC3_GFLADJ_30MHZ_MASK 0x3f
+
/* Device Configuration Register */
#define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
@@ -812,6 +817,7 @@ struct dwc3 {
u8 test_mode_nr;
u8 lpm_nyet_threshold;
u8 hird_threshold;
+ u32 fladj;
unsigneddelayed_status:1;
unsignedep0_bounced:1;
--
2.30.2
[PATCH v2 1/9] dm: core: add ofnode_for_each_compatible_node()
Add a helper to iterate over all nodes with a given compatible string.
Signed-off-by: Michael Walle
Reviewed-by: Simon Glass
---
include/dm/ofnode.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 6a714d0c7b..0f680e5aa6 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -1009,6 +1009,30 @@ ofnode ofnode_by_prop_value(ofnode from, const char
*propname,
ofnode_valid(node); \
node = ofnode_next_subnode(node))
+/**
+ * ofnode_for_each_compatible_node() - iterate over all nodes with a given
+ *compatible string
+ *
+ * @node: child node (ofnode, lvalue)
+ * @compat: compatible string to match
+ *
+ * This is a wrapper around a for loop and is used like so:
+ *
+ * ofnode node;
+ *
+ * ofnode_for_each_compatible_node(node, parent, compatible) {
+ * Use node
+ * ...
+ * }
+ *
+ * Note that this is implemented as a macro and @node is used as
+ * iterator in the loop.
+ */
+#define ofnode_for_each_compatible_node(node, compat) \
+ for (node = ofnode_by_compatible(ofnode_null(), compat); \
+ofnode_valid(node); \
+node = ofnode_by_compatible(node, compat))
+
/**
* ofnode_get_child_count() - get the child count of a ofnode
*
--
2.30.2
[PATCH v2 2/9] test: dm: add test for ofnode_for_each_compatible_node()
Check that all matching nodes have the correct compatible and that there
is at least one match.
Signed-off-by: Michael Walle
---
test/dm/ofnode.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index 49efabe871..cea0746bb3 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -333,3 +333,21 @@ static int dm_test_ofnode_conf(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_ofnode_conf, 0);
+
+static int dm_test_ofnode_for_each_compatible_node(struct unit_test_state *uts)
+{
+ const char compatible[] = "denx,u-boot-fdt-test";
+ bool found = false;
+ ofnode node;
+
+ ofnode_for_each_compatible_node(node, compatible) {
+ ut_assert(ofnode_device_is_compatible(node, compatible));
+ found = true;
+ }
+
+ /* There should be at least one matching node */
+ ut_assert(found);
+
+ return 0;
+}
+DM_TEST(dm_test_ofnode_for_each_compatible_node, UT_TESTF_SCAN_FDT);
--
2.30.2
[PATCH v2 3/9] armv8: fsl-layerscape: rework the dwc3 snooping enable code
Instead of looking at all USB (host) devices, just search all DWC3
device tree nodes. This will (1) fix a panic if of_match is zero and (2)
also apply the fixup if the controller is in peripheral mode. Both
happen when the DWC3 USB controller driver is used.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 28 -
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 41f3e95019..55b0bb50f3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -919,25 +919,23 @@ __weak int fsl_board_late_init(void)
#define DWC3_GSBUSCFG0_CACHETYPE(n)(((n) & 0x)\
<< DWC3_GSBUSCFG0_CACHETYPE_SHIFT)
-void enable_dwc3_snooping(void)
+static void enable_dwc3_snooping(void)
{
- int ret;
- u32 val;
- struct udevice *bus;
- struct uclass *uc;
+ static const char * const compatibles[] = {
+ "fsl,layerscape-dwc3",
+ "fsl,ls1028a-dwc3",
+ };
fdt_addr_t dwc3_base;
+ ofnode node;
+ u32 val;
+ int i;
- ret = uclass_get(UCLASS_USB, );
- if (ret)
- return;
-
- uclass_foreach_dev(bus, uc) {
- if (!strcmp(bus->driver->of_match->compatible,
"fsl,layerscape-dwc3")) {
- dwc3_base = devfdt_get_addr(bus);
- if (dwc3_base == FDT_ADDR_T_NONE) {
- dev_err(bus, "dwc3 regs missing\n");
+ for (i = 0; i < ARRAY_SIZE(compatibles); i++) {
+ ofnode_for_each_compatible_node(node, compatibles[i]) {
+ dwc3_base = ofnode_get_addr(node);
+ if (dwc3_base == FDT_ADDR_T_NONE)
continue;
- }
+
val = in_le32(dwc3_base + DWC3_GSBUSCFG0);
val &= ~DWC3_GSBUSCFG0_CACHETYPE(~0);
val |= DWC3_GSBUSCFG0_CACHETYPE(0x);
--
2.30.2
[PATCH v2 0/9] usb: dwc3: add Layerscape SoC support
Primarily, this will add support for peripheral mode on Layerscape SoCs. For this to work, we have to backport two fixes from linux and fix the fixup code for the DWC3 controller (which enables snooping because the SoC has wrong startup defaults). As a first user of the driver, enable it on the Kontron SL28 board, where both host and peripheral mode was tested. OTG mode is not supported. For this to work, one would need to read the hardware status of the OTG pin in the bind() op. But it isn't allowed to access the hardware in the bind() op (if I understand Simon correctly). changes since v1: - added test case for the new ofnode_for_each_compatible_node() Michael Walle (9): dm: core: add ofnode_for_each_compatible_node() test: dm: add test for ofnode_for_each_compatible_node() armv8: fsl-layerscape: rework the dwc3 snooping enable code usb: common: silence dubious errors usb: dwc3: Add frame length adjustment quirk usb: dwc3: Enable undefined length INCR burst type usb: dwc3: add layerscape support board: sl28: switch to dwc3 driver board: sl28: enable USB periheral support and gadgets arch/arm/cpu/armv8/fsl-layerscape/soc.c | 28 ++- configs/kontron_sl28_defconfig | 9 +- drivers/usb/common/common.c | 4 +- drivers/usb/dwc3/Kconfig| 10 ++ drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/core.c | 95 ++ drivers/usb/dwc3/core.h | 22 +++ drivers/usb/dwc3/dwc3-layerscape.c | 222 include/dm/ofnode.h | 24 +++ test/dm/ofnode.c| 18 ++ 10 files changed, 415 insertions(+), 18 deletions(-) create mode 100644 drivers/usb/dwc3/dwc3-layerscape.c -- 2.30.2
[PATCH] net: gem: Disable broadcast setting
There is no need for GEM to accepts broadcast packets because they are not handled by u-boot anyway. That's why use HW IP feature and don't waste time on these packats which will be dropped anyway. Signed-off-by: Michal Simek --- drivers/net/zynq_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index ff599822673c..c309c3c95499 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -60,6 +60,7 @@ #define ZYNQ_GEM_NWCFG_SPEED1000x0001 /* 100 Mbps operation */ #define ZYNQ_GEM_NWCFG_SPEED1000 0x0400 /* 1Gbps operation */ #define ZYNQ_GEM_NWCFG_FDEN0x0002 /* Full Duplex mode */ +#define ZYNQ_GEM_NWCFG_NO_BRDC BIT(5) /* No broadcast */ #define ZYNQ_GEM_NWCFG_FSREM 0x0002 /* FCS removal */ #define ZYNQ_GEM_NWCFG_SGMII_ENBL 0x0800 /* SGMII Enable */ #define ZYNQ_GEM_NWCFG_PCS_SEL 0x0800 /* PCS select */ @@ -77,6 +78,7 @@ #define ZYNQ_GEM_NWCFG_INIT(ZYNQ_GEM_DBUS_WIDTH | \ ZYNQ_GEM_NWCFG_FDEN | \ + ZYNQ_GEM_NWCFG_NO_BRDC | \ ZYNQ_GEM_NWCFG_FSREM | \ ZYNQ_GEM_NWCFG_MDCCLKDIV) -- 2.33.1
Re: [PATCH 1/1] rockchip: px30: add support for HW RNG for Odroid Go Advance
Reviewed-by: Kever Yang
Thanks,
- Kever
Chris Morgan 于2021年8月26日周四 上午12:24写道：
>
> From: Chris Morgan
>
> The Odroid Go Advance has a hardware random number generator present.
> The device does not have an upstream Linux driver, but does have a
> U-Boot driver. Add the appropriate node so that the hardware RNG can be
> used in U-Boot.
>
> Signed-off-by: Chris Morgan
> ---
> arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> index 741e8dd935..6d4edc5855 100644
> --- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> +++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> @@ -16,6 +16,12 @@
> serial2 =
> spi0 =
> };
> +
> + rng: rng@ff0b {
> + compatible = "rockchip,cryptov2-rng";
> + reg = <0x0 0xff0b 0x0 0x4000>;
> + status = "okay";
> + };
> };
>
> {
> --
> 2.25.1
>
Re: [PATCH 1/2] cmd: kaslrseed: add command to generate value from hwrng
Reviewed-by: Kever Yang
Thanks,
- Kever
Chris Morgan 于2021年8月26日周四 上午12:23写道：
>
> From: Chris Morgan
>
> Allow the kaslr-seed value in the chosen node to be set from a hardware
> rng source.
>
> Tested on a Rockchip PX30 (Odroid Go Advance), you must have loaded
> the devicetree first and prepared it for editing. On my device the
> workflow goes as follows:
>
> setenv dtb_loadaddr "0x01f0"
> load mmc 0:1 ${dtb_loadaddr} rk3326-odroid-go2.dtb
> fdt addr ${dtb_loadaddr}
> fdt resize
> kaslrseed
>
> and the output can be seen here:
> fdt print /chosen
> chosen {
> kaslr-seed = <0x6f61df74 0x6f7b996c>;
> stdout-path = "serial2:115200n8";
> };
>
> Signed-off-by: Chris Morgan
> ---
> cmd/Kconfig | 7 +
> cmd/Makefile| 1 +
> cmd/kaslrseed.c | 81 +
> 3 files changed, 89 insertions(+)
> create mode 100644 cmd/kaslrseed.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ffef3cc76c..e62adff939 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1790,6 +1790,13 @@ config CMD_RNG
> help
> Print bytes from the hardware random number generator.
>
> +config CMD_KASLRSEED
> + bool "kaslrseed"
> + depends on DM_RNG
> + help
> + Set the kaslr-seed in the chosen node with entropy provided by a
> + hardware random number generator.
> +
> config CMD_SLEEP
> bool "sleep"
> default y
> diff --git a/cmd/Makefile b/cmd/Makefile
> index ed3669411e..34cbda72f5 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -131,6 +131,7 @@ obj-$(CONFIG_CMD_REGINFO) += reginfo.o
> obj-$(CONFIG_CMD_REISER) += reiser.o
> obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
> obj-$(CONFIG_CMD_RNG) += rng.o
> +obj-$(CONFIG_CMD_KASLRSEED) += kaslrseed.o
> obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
> obj-$(CONFIG_CMD_RTC) += rtc.o
> obj-$(CONFIG_SANDBOX) += host.o
> diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
> new file mode 100644
> index 00..27c2648c91
> --- /dev/null
> +++ b/cmd/kaslrseed.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The 'kaslrseed' command takes bytes from the hardware random number
> + * generator and uses them to set the kaslr-seed value in the chosen node.
> + *
> + * Copyright (c) 2021, Chris Morgan
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int do_kaslr_seed(struct cmd_tbl *cmdtp, int flag, int argc, char
> *const argv[])
> +{
> + size_t n = 0x8;
> + struct udevice *dev;
> + u64 *buf;
> + int nodeoffset;
> + int ret = CMD_RET_SUCCESS;
> +
> + if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
> + printf("No RNG device\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + buf = malloc(n);
> + if (!buf) {
> + printf("Out of memory\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (dm_rng_read(dev, buf, n)) {
> + printf("Reading RNG failed\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (!working_fdt) {
> + printf("No FDT memory address configured. Please configure\n"
> + "the FDT address via \"fdt addr \" command.\n"
> + "Aborting!\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + ret = fdt_check_header(working_fdt);
> + if (ret < 0) {
> + printf("fdt_chosen: %s\n", fdt_strerror(ret));
> + return CMD_RET_FAILURE;
> + }
> +
> + nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
> + if (nodeoffset < 0) {
> + printf("Reading chosen node failed\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
> sizeof(buf));
> + if (ret < 0) {
> + printf("Unable to set kaslr-seed on chosen node: %s\n",
> fdt_strerror(ret));
> + return CMD_RET_FAILURE;
> + }
> +
> + free(buf);
> +
> + return ret;
> +}
> +
> +#ifdef CONFIG_SYS_LONGHELP
> +static char kaslrseed_help_text[] =
> + "[n]\n"
> + " - append random bytes to chosen kaslr-seed node\n";
> +#endif
> +
> +U_BOOT_CMD(
> + kaslrseed, 1, 0, do_kaslr_seed,
> + "feed bytes from the hardware random number generator to the
> kaslr-seed",
> + kaslrseed_help_text
> +);
> --
> 2.25.1
>
Re: [PATCH] rockchip: px30: sync serial flash controller bindings with mainline
Reviewed-by: Kever Yang
Thanks,
- Kever
Chris Morgan 于2021年8月21日周六 上午9:47写道：
>
> From: Chris Morgan
>
> The devicetree submitted and approved for the mainline linux kernel is
> slightly different than the one present here. This syncs both
> devicetrees (for the Rockchip SFC node at least) present on the PX30
> and the Odroid Go Advance. Changes include renaming the flash node,
> reordering the values in the SFC node for the rk3326-odroid-go2,
> changing the name of the cs pinctrl node to cs0, and updating the
> u-boot specific tree to utilize the new flash node value.
>
> Signed-off-by: Chris Morgan
> ---
> arch/arm/dts/px30.dtsi | 4 ++--
> arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 2 +-
> arch/arm/dts/rk3326-odroid-go2.dts | 8
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
> index aaa8ae2235..ef706486dc 100644
> --- a/arch/arm/dts/px30.dtsi
> +++ b/arch/arm/dts/px30.dtsi
> @@ -967,7 +967,7 @@
> clocks = < SCLK_SFC>, < HCLK_SFC>;
> clock-names = "clk_sfc", "hclk_sfc";
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cs _bus4>;
> + pinctrl-0 = <_clk _cs0 _bus4>;
> power-domains = < PX30_PD_MMC_NAND>;
> status = "disabled";
> };
> @@ -1953,7 +1953,7 @@
> <1 RK_PA1 3 _pull_none>;
> };
>
> - sfc_cs: sfc-cs {
> + sfc_cs0: sfc-cs0 {
> rockchip,pins =
> <1 RK_PA4 3 _pull_none>;
> };
> diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> index 741e8dd935..0990005a15 100644
> --- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> +++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> @@ -70,7 +70,7 @@
> u-boot,dm-pre-reloc;
> };
>
> -_flash {
> +&{/sfc@ff3a/flash@0} {
> u-boot,dm-pre-reloc;
> };
>
> diff --git a/arch/arm/dts/rk3326-odroid-go2.dts
> b/arch/arm/dts/rk3326-odroid-go2.dts
> index 6f91f5040b..4e3dceecbe 100644
> --- a/arch/arm/dts/rk3326-odroid-go2.dts
> +++ b/arch/arm/dts/rk3326-odroid-go2.dts
> @@ -618,18 +618,18 @@
> };
>
> {
> + pinctrl-0 = <_clk _cs0 _bus2>;
> + pinctrl-names = "default";
> #address-cells = <1>;
> #size-cells = <0>;
> - pinctrl-names = "default";
> - pinctrl-0 = <_clk _cs _bus2>;
> status = "okay";
>
> - spi_flash: xt25f128b@0 {
> + flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <10800>;
> spi-rx-bus-width = <2>;
> - spi-tx-bus-width = <2>;
> + spi-tx-bus-width = <1>;
> };
> };
>
> --
> 2.25.1
>
Re: [PATCH 2/2] doc: rockchip: write all brand names with a capital
Reviewed-by: Kever Yang Thanks, - Kever Johan Jonker 于2021年8月21日周六 上午1:33写道： > > Brand names are supposed to be written with a capital, > so change them all. > > Signed-off-by: Johan Jonker > --- > doc/board/rockchip/rockchip.rst | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst > index 8d75efc0..144cb98e 100644 > --- a/doc/board/rockchip/rockchip.rst > +++ b/doc/board/rockchip/rockchip.rst > @@ -16,10 +16,10 @@ Rockchip boards > Rockchip is SoC solutions provider for tablets & PCs, streaming media > TV boxes, AI audio & vision, IoT hardware. > > -A wide range of Rockchip SoCs with associated boardsare supported in > +A wide range of Rockchip SoCs with associated boards are supported in > mainline U-Boot. > > -List of mainline supported rockchip boards: > +List of mainline supported Rockchip boards: > > * rk3036 > - Rockchip Evb-RK3036 (evb-rk3036) > @@ -93,7 +93,7 @@ To build TF-A:: > make realclean > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 > > -Specify the PLAT= with desired rockchip platform to build TF-A for. > +Specify the PLAT= with desired Rockchip platform to build TF-A for. > > U-Boot > ^^ > @@ -130,7 +130,7 @@ Flashing > SD Card > ^^^ > > -All rockchip platforms, except rk3128 (which doesn't use SPL) are now > +All Rockchip platforms, except rk3128 (which doesn't use SPL) are now > supporting single boot image using binman and pad_cat. > > To write an image that boots from an SD card (assumed to be /dev/sda):: > @@ -141,7 +141,7 @@ To write an image that boots from an SD card (assumed to > be /dev/sda):: > eMMC > > > -eMMC flash would probe on mmc0 in most of the rockchip platforms. > +eMMC flash would probe on mmc0 in most of the Rockchip platforms. > > Create GPT partition layout as defined in configurations:: > > @@ -164,7 +164,7 @@ Program the flash:: > sudo fastboot -i 0x2207 flash loader1 idbloader.img > sudo fastboot -i 0x2207 flash loader2 u-boot.itb > > -Note: for rockchip 32-bit platforms the U-Boot proper image > +Note: for Rockchip 32-bit platforms the U-Boot proper image > is u-boot-dtb.img > > SPI > @@ -227,8 +227,8 @@ Note: > TODO > > > -- Add rockchip idbloader image building > -- Add rockchip TPL image building > +- Add Rockchip idbloader image building > +- Add Rockchip TPL image building > - Document SPI flash boot > - Add missing SoC's with it boards list > > -- > 2.20.1 >
Re: [PATCH 1/2] doc: rockchip: sort rockchip support list for rk3188
Reviewed-by: Kever Yang Thanks, - Kever Johan Jonker 于2021年8月21日周六 上午1:33写道： > > In the list of mainline U-boot supported Rockchip boards > rk3188 is placed below under the name rv3188. Give back it's > original name and sort the list in alphabetical order. > > Signed-off-by: Johan Jonker > --- > doc/board/rockchip/rockchip.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst > index fbb99839..8d75efc0 100644 > --- a/doc/board/rockchip/rockchip.rst > +++ b/doc/board/rockchip/rockchip.rst > @@ -26,6 +26,8 @@ List of mainline supported rockchip boards: > - Kylin (kylin_rk3036) > * rk3128 > - Rockchip Evb-RK3128 (evb-rk3128) > +* rk3188 > + - Radxa Rock (rock) > * rk3229 > - Rockchip Evb-RK3229 (evb-rk3229) > * rk3288 > @@ -75,8 +77,6 @@ List of mainline supported rockchip boards: > * rv1108 > - Rockchip Evb-rv1108 (evb-rv1108) > - Elgin-R1 (elgin-rv1108) > -* rv3188 > - - Radxa Rock (rock) > > Building > > -- > 2.20.1 >
Re: [PATCH] rockchip: rk33xx: Drop ROCKCHIP_USB2_PHY on boards without it
Reviewed-by: Kever Yang Thanks, - Kever Peter Robinson 于2021年8月12日周四 下午5:11写道： > > The 64 bit rk33xx chips don't have the ROCKCHIP_USB2_PHY IP so > drop the configs as they were likely copied over from other > boards during enablement. > > Signed-off-by: Peter Robinson > --- > configs/lion-rk3368_defconfig | 1 - > configs/nanopc-t4-rk3399_defconfig| 1 - > configs/roc-pc-mezzanine-rk3399_defconfig | 1 - > configs/roc-pc-rk3399_defconfig | 1 - > configs/rock-pi-n10-rk3399pro_defconfig | 1 - > 5 files changed, 5 deletions(-) > > diff --git a/configs/lion-rk3368_defconfig b/configs/lion-rk3368_defconfig > index 5f7d101814..90a2878e50 100644 > --- a/configs/lion-rk3368_defconfig > +++ b/configs/lion-rk3368_defconfig > @@ -94,7 +94,6 @@ CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > CONFIG_USB_DWC2=y > -CONFIG_ROCKCHIP_USB2_PHY=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_DWC2_OTG=y > CONFIG_SPL_TINY_MEMSET=y > diff --git a/configs/nanopc-t4-rk3399_defconfig > b/configs/nanopc-t4-rk3399_defconfig > index a94f428def..62833c386b 100644 > --- a/configs/nanopc-t4-rk3399_defconfig > +++ b/configs/nanopc-t4-rk3399_defconfig > @@ -51,7 +51,6 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > CONFIG_USB_DWC3=y > -CONFIG_ROCKCHIP_USB2_PHY=y > CONFIG_USB_KEYBOARD=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig > b/configs/roc-pc-mezzanine-rk3399_defconfig > index 8d0f57021b..6aa47490c1 100644 > --- a/configs/roc-pc-mezzanine-rk3399_defconfig > +++ b/configs/roc-pc-mezzanine-rk3399_defconfig > @@ -69,7 +69,6 @@ CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > CONFIG_USB_DWC3=y > CONFIG_USB_DWC3_GENERIC=y > -CONFIG_ROCKCHIP_USB2_PHY=y > CONFIG_USB_KEYBOARD=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig > index 4e5c90439d..b03ee3664f 100644 > --- a/configs/roc-pc-rk3399_defconfig > +++ b/configs/roc-pc-rk3399_defconfig > @@ -66,7 +66,6 @@ CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > CONFIG_USB_DWC3=y > CONFIG_USB_DWC3_GENERIC=y > -CONFIG_ROCKCHIP_USB2_PHY=y > CONFIG_USB_KEYBOARD=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > diff --git a/configs/rock-pi-n10-rk3399pro_defconfig > b/configs/rock-pi-n10-rk3399pro_defconfig > index e5df6779de..17442a0d84 100644 > --- a/configs/rock-pi-n10-rk3399pro_defconfig > +++ b/configs/rock-pi-n10-rk3399pro_defconfig > @@ -60,7 +60,6 @@ CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > CONFIG_USB_DWC3=y > CONFIG_USB_DWC3_GENERIC=y > -CONFIG_ROCKCHIP_USB2_PHY=y > CONFIG_USB_KEYBOARD=y > # CONFIG_USB_KEYBOARD_FN_KEYS is not set > CONFIG_USB_GADGET=y > -- > 2.31.1 >
[PATCH] arm64: zynqmp: Fix sgmii clock input freq for p-a2197
Input frequency for sgmii is 125MHz on all Xilinx designs.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
index c893fd8f..5d21795de9d0 100644
--- a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
@@ -46,7 +46,7 @@
si5332_1: si5332_1 { /* clk0_sgmii - u142 */
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <>; /* FIXME */
+ clock-frequency = <12500>;
};
si5332_2: si5332_2 { /* clk1_usb - u142 */
--
2.33.1
Re: [PATCH 1/2] rockchip: px30: add support for setting cpll clock
Reviewed-by: Kever Yang
Thanks,
- Kever
Chris Morgan 于2021年8月6日周五 上午12:49写道：
>
> From: Chris Morgan
>
> Starting with commit 92f1e9a4b31c ("clk: Detect failure to set
> defaults") the clk driver for the PX30 for the Odroid Go Advance would
> no longer probe correctly, because setting the cpll and gpu clocks are
> not supported with the clk_px30 U-Boot driver. This adds support for
> setting the cpll clock to the clk_px30 driver. Another patch will
> update the U-Boot specific device-tree to remove the GPU clock which is
> not used by U-Boot.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/clk/rockchip/clk_px30.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
> index 6b746f4c65..89784f9aa1 100644
> --- a/drivers/clk/rockchip/clk_px30.c
> +++ b/drivers/clk/rockchip/clk_px30.c
> @@ -1262,6 +1262,9 @@ static ulong px30_clk_set_rate(struct clk *clk, ulong
> rate)
> case PLL_NPLL:
> ret = px30_clk_set_pll_rate(priv, NPLL, rate);
> break;
> + case PLL_CPLL:
> + ret = px30_clk_set_pll_rate(priv, CPLL, rate);
> + break;
> case ARMCLK:
> ret = px30_armclk_set_clk(priv, rate);
> break;
> --
> 2.25.1
>
Re: [PATCH 2/2] rockchip: board: remove SCLK_GPU from U-Boot DT
Reviewed-by: Kever Yang
Thanks,
- Kever
Chris Morgan 于2021年8月6日周五 上午12:49写道：
>
> From: Chris Morgan
>
> Starting with commit 92f1e9a4b31c ("clk: Detect failure to set
> defaults") the clk driver for the PX30 would fail to probe for the
> Odroid Go Advance. This patch is to remove the clock for the GPU from
> the U-Boot specific devicetree, as that clock is not supported by the
> U-Boot clk_px30 driver.
>
> Signed-off-by: Chris Morgan
> ---
> arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> index 00767d2abd..c330286bc5 100644
> --- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> +++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> @@ -9,8 +9,18 @@
> };
> };
>
> +/* U-Boot clk driver for px30 cannot set GPU_CLK */
> {
> u-boot,dm-pre-reloc;
> + assigned-clocks = < PLL_NPLL>,
> + < ACLK_BUS_PRE>, < ACLK_PERI_PRE>,
> + < HCLK_BUS_PRE>, < HCLK_PERI_PRE>,
> + < PCLK_BUS_PRE>, < PLL_CPLL>;
> +
> + assigned-clock-rates = <118800>,
> + <2>, <2>,
> + <15000>, <15000>,
> + <1>, <1700>;
> };
>
> {
> --
> 2.25.1
>
Re: [PATCH] mmc: rockchip_sdhci: enable strobe line for HS400
On 2021/10/15 下午4:41, Yifeng Zhao wrote: The default configuration of rk3399 EMMC PHY does not enable the strobe line, and EMMC controller will got data transmission error at HS400 mode. Signed-off-by: Yifeng Zhao Reviewed-by: Kever Yang Thanks, - Kever --- drivers/mmc/rockchip_sdhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c index 1ac00587d4..278473899c 100644 --- a/drivers/mmc/rockchip_sdhci.c +++ b/drivers/mmc/rockchip_sdhci.c @@ -143,6 +143,9 @@ static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32 clock) writel(RK_CLRSETBITS(3 << 12, freqsel << 12), >emmcphy_con[0]); writel(RK_CLRSETBITS(1 << 1, 1 << 1), >emmcphy_con[6]); + /* REN Enable on STRB Line for HS400 */ + writel(RK_CLRSETBITS(0, 1 << 9), >emmcphy_con[2]); + read_poll_timeout(readl, >emmcphy_status, dllrdy, PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000); }
Re: [PATCH v2] clk: rockchip: rk3568: update clks
On 2021/10/12 下午4:43, Elaine Zhang wrote:
fix up ppll init freq.
support tclk_emmc.
add freq (26M) for mmc device.
fix up the sfc clk rate unit error.
Change in V2:
remove change id.
Signed-off-by: Elaine Zhang
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/include/asm/arch-rockchip/cru_rk3568.h | 2 +-
drivers/clk/rockchip/clk_rk3568.c | 11 +--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
index 6c59033f03a6..399f19ad21ec 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
@@ -14,7 +14,7 @@
#define APLL_HZ (816 * MHz)
#define GPLL_HZ (1188 * MHz)
#define CPLL_HZ (1000 * MHz)
-#define PPLL_HZ(100 * MHz)
+#define PPLL_HZ(200 * MHz)
/* RK3568 pll id */
enum rk3568_pll_id {
diff --git a/drivers/clk/rockchip/clk_rk3568.c
b/drivers/clk/rockchip/clk_rk3568.c
index 553c6c0dafbd..d5e45e7602c7 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -1441,6 +1441,7 @@ static ulong rk3568_sdmmc_set_clk(struct rk3568_clk_priv
*priv,
switch (rate) {
case OSC_HZ:
+ case 26 * MHz:
src_clk = CLK_SDMMC_SEL_24M;
break;
case 400 * MHz:
@@ -1507,7 +1508,7 @@ static ulong rk3568_sfc_get_clk(struct rk3568_clk_priv
*priv)
case SCLK_SFC_SEL_125M:
return 125 * MHz;
case SCLK_SFC_SEL_150M:
- return 150 * KHz;
+ return 150 * MHz;
default:
return -ENOENT;
}
@@ -1534,7 +1535,7 @@ static ulong rk3568_sfc_set_clk(struct rk3568_clk_priv
*priv, ulong rate)
case 125 * MHz:
src_clk = SCLK_SFC_SEL_125M;
break;
- case 150 * KHz:
+ case 150 * MHz:
src_clk = SCLK_SFC_SEL_150M;
break;
default:
@@ -2406,6 +2407,9 @@ static ulong rk3568_clk_get_rate(struct clk *clk)
case BCLK_EMMC:
rate = rk3568_emmc_get_bclk(priv);
break;
+ case TCLK_EMMC:
+ rate = OSC_HZ;
+ break;
#ifndef CONFIG_SPL_BUILD
case ACLK_VOP:
rate = rk3568_aclk_vop_get_clk(priv);
@@ -2582,6 +2586,9 @@ static ulong rk3568_clk_set_rate(struct clk *clk, ulong
rate)
case BCLK_EMMC:
ret = rk3568_emmc_set_bclk(priv, rate);
break;
+ case TCLK_EMMC:
+ ret = OSC_HZ;
+ break;
#ifndef CONFIG_SPL_BUILD
case ACLK_VOP:
ret = rk3568_aclk_vop_set_clk(priv, rate);
Re: [PATCH] board/km: update MAINTAINERS files
On Tue, Oct 12, 2021 at 08:50:38AM +0200, Holger Brunck wrote: > Update the e-mail addresses and person responsible. > > Signed-off-by: Holger Brunck > CC: Aleksandar Gerasimovski > CC: Rainer Boschung Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] pytest: Show a message when sandbox crashes
On Fri, Oct 08, 2021 at 09:15:23AM -0600, Simon Glass wrote: > When a test hands on a real board there is no way on the console to obtain > any information about why it hung. > > With sandbox we can actually find out that it died and get a signal or > exit code. Add this to make it easier to figure out what happened. > > So instead of: > > test/py/u_boot_spawn.py:171: in expect > c = os.read(self.fd, 1024).decode(errors='replace') > E OSError: [Errno 5] Input/output error > > We get: > > test/py/u_boot_spawn.py:171: in expect > c = os.read(self.fd, 1024).decode(errors='replace') > E ValueError: U-Boot exited with signal 11 (Signals.SIGSEGV) > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pci: Fix printf format for regions
On Fri, Oct 08, 2021 at 05:01:24PM +0200, Pali Rohár wrote: > Correct printf format for unsigned long long is %llx and not %llxx. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/5] pci: Fix showing registers
On Thu, Oct 07, 2021 at 02:51:01PM +0200, Pali Rohár wrote: > Header type is 7-bit number so use all 7 bits when detecting header type > and not only 2 bits. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] pci: Fix showing bars
On Thu, Oct 07, 2021 at 02:51:00PM +0200, Pali Rohár wrote: > Header type is 7-bit number so properly clear upper 8th bit which > indicates multifunction device. > > And do not try to show bars for unsupported header types. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] pci: Skip configuring invalid P2P bridge devices
On Thu, Oct 07, 2021 at 02:50:58PM +0200, Pali Rohár wrote: > Function dm_pci_hose_probe_bus() expects that bus is valid PCI device with > Bridge header type (0x01). So add check before touching PCI config space to > prevent misconfiguring some non-standard device. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] pci: Fix configuring BARs
On Thu, Oct 07, 2021 at 02:50:59PM +0200, Pali Rohár wrote: > Number of BARs is defined by header type, not by class code. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] pci: Skip configuring PCI Rom Address for unsupported header types
On Thu, Oct 07, 2021 at 02:50:57PM +0200, Pali Rohár wrote: > PCI Rom Address is currently supported only for Normal (0x00) and > Bridge (0x01) header types. Fix code accordingly. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pytest: Shorten traceback length by default
On Tue, Oct 05, 2021 at 08:18:00PM -0600, Simon Glass wrote: > This produces a lot of code output which is not very helpful and is quite > annoying to wade through. Use the short format by default. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: Update to LLVM-13
On Tue, Oct 05, 2021 at 01:51:38PM -0400, Tom Rini wrote: > - Switch sources and CI scripts to install and use LLVM-13 > - Update to latest "focal" tag. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/4] tools: Separate image types which depend on OpenSSL
Hello! I did more investigation for this topic during working on kwboot improvements, which resulted in this patch series: https://lore.kernel.org/u-boot/20210924210716.29752-1-ka...@kernel.org/ The result is that kwbimage is used only for: Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS. This information is now also in manpage: https://lore.kernel.org/u-boot/20210924210716.29752-39-ka...@kernel.org/ So, Orion, Discovery, A3700, A7k, A8k and CN913x does *not* use kwbimage and so they do do not need to select libcrypto. Therefore you can drop selection of libcrypto from ARCH_ORION5X. ARCH_KIRKWOOD includes only Kirkwood (which required kwbimage), but does not use any crypto. So selecting unused crypto seems suspicious for anybody who look at it... And it is there only for transitional kwbimage dependency, which is very unintuitive. With ARCH_MVEBU it is quite complicated as it is used for both 32-bit SoCs (XP, 375, 38x) and also 64-bit SoCs (3700, 7k, 8k). kwbimage is used only for 32-bit mvebu SoCs. I do not know how to express this correctly. But I would rather suggest to introduce a new option which specify that tools/kwbimage.o is required and this dependency would selects its direct (crypto) dependency. Otherwise nobody would remember in future why non-crypto platforms are selecting crypto functionality, or why 64-bit platforms are enabling crypto functionality which is not used at all. On Thursday 14 October 2021 22:19:13 Samuel Holland wrote: > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected. > Use Makefile logic to conditionally link the files. > > When building for platforms which use those image types, automatically > select TOOLS_LIBCRYPTO, since it is required for the build to complete. > > Signed-off-by: Samuel Holland > --- > > Changes in v3: > - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best >as I can tell, using the suggestions from Pali Rohár) > > Changes in v2: > - Refactored the first patch on top of TOOLS_LIBCRYPTO > > arch/arm/Kconfig | 3 +++ > arch/arm/mach-imx/mxs/Kconfig | 2 ++ > scripts/config_whitelist.txt | 1 - > tools/Makefile| 19 +-- > tools/mxsimage.c | 3 --- > 5 files changed, 10 insertions(+), 18 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index d8c041a877..380ad4f670 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -566,6 +566,7 @@ config ARCH_KIRKWOOD > select BOARD_EARLY_INIT_F > select CPU_ARM926EJS > select GPIO_EXTRA_HEADER > + select TOOLS_LIBCRYPTO > > config ARCH_MVEBU > bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" > @@ -580,12 +581,14 @@ config ARCH_MVEBU > select OF_CONTROL > select OF_SEPARATE > select SPI > + select TOOLS_LIBCRYPTO > imply CMD_DM > > config ARCH_ORION5X > bool "Marvell Orion" > select CPU_ARM926EJS > select GPIO_EXTRA_HEADER > + select TOOLS_LIBCRYPTO > > config TARGET_STV0991 > bool "Support stv0991" > diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig > index b2026a3758..6f138d25e9 100644 > --- a/arch/arm/mach-imx/mxs/Kconfig > +++ b/arch/arm/mach-imx/mxs/Kconfig > @@ -3,6 +3,7 @@ if ARCH_MX23 > config MX23 > bool > default y > + select TOOLS_LIBCRYPTO > > choice > prompt "MX23 board select" > @@ -34,6 +35,7 @@ if ARCH_MX28 > config MX28 > bool > default y > + select TOOLS_LIBCRYPTO > > choice > prompt "MX28 board select" > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index 3a6865dc70..bea6b6f83b 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -838,7 +838,6 @@ CONFIG_MXC_UART_BASE > CONFIG_MXC_USB_FLAGS > CONFIG_MXC_USB_PORT > CONFIG_MXC_USB_PORTSC > -CONFIG_MXS > CONFIG_MXS_AUART > CONFIG_MXS_AUART_BASE > CONFIG_MXS_OCOTP > diff --git a/tools/Makefile b/tools/Makefile > index 999fd46531..a9b3d982d8 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -94,9 +94,11 @@ ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix > lib/ecdsa/, ecdsa-libcrypto. > AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \ > aes-encrypt.o aes-decrypt.o) > > -# Cryptographic helpers that depend on openssl/libcrypto > -LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \ > - fdt-libcrypto.o) > +# Cryptographic helpers and image types that depend on openssl/libcrypto > +LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \ > + lib/fdt-libcrypto.o \ > + kwbimage.o \ > + mxsimage.o > > ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o > > @@ -118,10 +120,8 @@ dumpimage-mkimage-objs := aisimage.o \ >
Re: Broken build with disabling OpenSSL crypto
On Wednesday 06 October 2021 17:05:24 Alex G. wrote:
> Hi Jernej,
>
> On 10/6/21 4:27 PM, Jernej Škrabec wrote:
> > Hi everyone!
> >
> > Commit cb9faa6f98ae ("tools: Use a single target-independent config to
> > enable
> > OpenSSL") recently introduced option to disable usage of OpenSSL via
> > CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit
> > b4f3cc2c42d9
> > ("tools: kwbimage: Do not hide usage of secure header under
> > CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That
> > totally
> > defeats the purpose of first commit. I suggest that it gets reverted.
> >
> > I would like disable OpenSSL for my usage, since it gives me troubles when
> > cross-compiling U-Boot inside LibreELEC build system. It's not needed for
> > our
> > case anyway.
> >
> > Best regards,
> >
>
> Can you please give the following diff a try, and if it works for you, submit
> as patch?
This change is incorrect and will break mvebu builds. mvebu requires
kwbimage for building boot images and so you cannot disable it or make
it optional.
> Alex
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 4a86321f64..7f72ff9645 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/,
> \
>
> # Cryptographic helpers that depend on openssl/libcrypto
> LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
> - fdt-libcrypto.o)
> + fdt-libcrypto.o) \
> + kwbimage.o
>
> ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
>
> @@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
> imximage.o \
> imx8image.o \
> imx8mimage.o \
> - kwbimage.o \
> lib/md5.o \
> lpc32xximage.o \
> mxsimage.o \
> @@ -169,8 +169,8 @@ HOST_EXTRACFLAGS +=
> -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
> HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER
> endif
>
> -# MXSImage needs LibSSL
> -ifneq
> ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
> +# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
> +ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
> HOSTCFLAGS_kwbimage.o += \
> $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
> HOSTLDLIBS_mkimage += \
Re: [PATCH] cmd: pxe_utils: Check fdtcontroladdr in label_boot
On Thu, 14 Oct 2021 12:24:45 -0600
Simon Glass wrote:
Hi Simon,
> On Thu, 14 Oct 2021 at 02:40, Peter Hoyes wrote:
> >
> > From: Peter Hoyes
> >
> > If using OF_CONTROL, fdtcontroladdr is set to the fdt used to configure
> > U-Boot. When using PXE, if no fdt is defined in the menu file, and
> > there is no fdt at fdt_addr, add fall back on fdtcontroladdr too.
> >
> > We are developing board support for the Armv8r64 FVP using
> > config_distro_bootcmd. We are also using OF_BOARD and would like the
> > PXE boot option to default to the fdt provided by board_fdt_blob_setup.
> >
> > Signed-off-by: Peter Hoyes
> > ---
> > cmd/pxe_utils.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> > index 067c24e5ff..8f8e69ca97 100644
> > --- a/cmd/pxe_utils.c
> > +++ b/cmd/pxe_utils.c
> > @@ -556,7 +556,10 @@ static int label_boot(struct cmd_tbl *cmdtp, struct
> > pxe_label *label)
> > * Scenario 2: If there is an fdt_addr specified, pass it along to
> > * bootm, and adjust argc appropriately.
> > *
> > -* Scenario 3: fdt blob is not available.
> > +* Scenario 3: If there is an fdtcontroladdr specified, pass it
> > along to
> > +* bootm, and adjust argc appropriately.
> > +*
> > +* Scenario 4: fdt blob is not available.
> > */
> > bootm_argv[3] = env_get("fdt_addr_r");
> >
> > @@ -646,6 +649,9 @@ static int label_boot(struct cmd_tbl *cmdtp, struct
> > pxe_label *label)
> > if (!bootm_argv[3])
> > bootm_argv[3] = env_get("fdt_addr");
> >
> > + if (!bootm_argv[3])
> > + bootm_argv[3] = env_get("fdtcontroladdr");
> > +
> > if (bootm_argv[3]) {
> > if (!bootm_argv[2])
> > bootm_argv[2] = "-";
> > --
> > 2.25.1
> >
>
> This is a bit strange as fdtcontroladdr is the control dtb that U-Boot
> uses.
Yes, that is the idea. This DTB should be as good as any, and this is the
last check before giving up on DTs completely, so "U-Boot's DTB" (actually
there is no such thing) is better than none at all. In fact EFI boot does
the very same thing:
https://source.denx.de/u-boot/u-boot/-/blob/master/include/config_distro_bootcmd.h#L144-L148
> Can you not set fdt_addr to that, if you need to? Is it not
> already set to that?
According to doc/README.distro, fdt_addr is reserved for DTBs residing at
a (fixed?) ROM address. We don't really know yet where the DT comes from,
the cleanest seems to be to be passed down from TF-A, in which case this
would definitely not be ROM. board_fdt_blob_setup() knows this address,
and this is what will be written to $fdtcontroladdr.
FWIW, this patch looks good to me.
Cheers,
Andre
> Also, there is a clean-up series for this code outstanding. I will
> send v3 and copy you, if you are able to review it.
>
> Regards,
> Simon
Re: [PATCH v2] sandbox: Remove OF_HOSTFILE
> > [...] > > This patch does not apply cleanly on top you your other series. > > Can you please resend it? Done! Cheers /Ilias > > Regards, > Simon
[PATCH v3] sandbox: Remove OF_HOSTFILE
OF_HOSTFILE is used on sandbox configs only. Although it's pretty
unique and rarely causes confusion, we are better of having simpler
config options for the DTB.
So let's replace that with the existing OF_BOARD. U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production)
Signed-off-by: Ilias Apalodimas
---
Note that this must be applied on top of
https://lore.kernel.org/u-boot/20211011210016.135929-1-ilias.apalodi...@linaro.org/
changes since v2:
- Rebased on top of the updated OF_BOARD patchset
Changes since v1:
- Added internal error value on board_fdt_blob_setup(). Arguably
we can just check against NULL and simplify this even more if we
don't care about the errno
- OF_BOARD is now default for sandbox builds
Makefile| 6 ++---
arch/arm/mach-stm32mp/boot_params.c | 3 ++-
arch/sandbox/cpu/cpu.c | 27 +
arch/sandbox/include/asm/u-boot-sandbox.h | 8 --
board/AndesTech/ax25-ae350/ax25-ae350.c | 2 ++
board/Marvell/octeontx/board-fdt.c | 3 ++-
board/Marvell/octeontx2/board-fdt.c | 3 ++-
board/Marvell/octeontx2/board.c | 3 ++-
board/armltd/vexpress64/vexpress64.c| 7 --
board/broadcom/bcmstb/bcmstb.c | 3 ++-
board/emulation/qemu-arm/qemu-arm.c | 3 ++-
board/emulation/qemu-ppce500/qemu-ppce500.c | 3 ++-
board/emulation/qemu-riscv/qemu-riscv.c | 3 ++-
board/highbank/highbank.c | 3 ++-
board/raspberrypi/rpi/rpi.c | 8 --
board/sifive/unleashed/unleashed.c | 3 ++-
board/sifive/unmatched/unmatched.c | 3 ++-
board/socrates/socrates.c | 4 ++-
board/xen/xenguest_arm64/xenguest_arm64.c | 7 --
board/xilinx/common/board.c | 3 ++-
configs/sandbox64_defconfig | 1 -
configs/sandbox_defconfig | 1 -
configs/sandbox_flattree_defconfig | 1 -
configs/sandbox_noinst_defconfig| 1 -
configs/sandbox_spl_defconfig | 1 -
configs/tools-only_defconfig| 1 -
doc/develop/devicetree/control.rst | 7 +++---
dts/Kconfig | 10 +---
include/fdtdec.h| 4 ++-
lib/fdtdec.c| 14 +--
scripts/Makefile.spl| 4 +--
31 files changed, 81 insertions(+), 69 deletions(-)
diff --git a/Makefile b/Makefile
index 3014788e14e8..cf3d98d00a62 100644
--- a/Makefile
+++ b/Makefile
@@ -957,7 +957,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
endif
-INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
+INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb
ifneq ($(CONFIG_SPL_TARGET),)
INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
endif
@@ -1423,7 +1423,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
- $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
\
+ $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
\
,$(UBOOT_BIN)) FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
@@ -1437,7 +1437,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
ifdef U_BOOT_ITS
u-boot.itb: u-boot-nodtb.bin \
- $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
+ $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
$(U_BOOT_ITS) FORCE
$(call if_changed,mkfitimage)
$(BOARD_SIZE_CHECK)
diff --git a/arch/arm/mach-stm32mp/boot_params.c
b/arch/arm/mach-stm32mp/boot_params.c
index 84647e70398b..e91ef1b2fc70 100644
--- a/arch/arm/mach-stm32mp/boot_params.c
+++ b/arch/arm/mach-stm32mp/boot_params.c
@@ -33,10 +33,11 @@ void save_boot_params(unsigned long r0, unsigned long r1,
unsigned long r2,
* Use the saved FDT address provided by TF-A at boot time (NT_FW_CONFIG =
* Non Trusted Firmware configuration file) when the pointer is valid
*/
-void *board_fdt_blob_setup(void)
+void *board_fdt_blob_setup(int *err)
{
log_debug("%s: nt_fw_dtb=%lx\n", __func__, nt_fw_dtb);
+ *err = 0;
/* use external device tree only if address is valid */
if (nt_fw_dtb >= STM32_DDR_BASE) {
if (fdt_magic(nt_fw_dtb) == FDT_MAGIC)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 48636ab63919..9887d09272a3 100644
--- a/arch/sandbox/cpu/cpu.c
+++
[PATCH] mmc: rockchip_sdhci: enable strobe line for HS400
The default configuration of rk3399 EMMC PHY does not enable the strobe line, and EMMC controller will got data transmission error at HS400 mode. Signed-off-by: Yifeng Zhao --- drivers/mmc/rockchip_sdhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c index 1ac00587d4..278473899c 100644 --- a/drivers/mmc/rockchip_sdhci.c +++ b/drivers/mmc/rockchip_sdhci.c @@ -143,6 +143,9 @@ static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32 clock) writel(RK_CLRSETBITS(3 << 12, freqsel << 12), >emmcphy_con[0]); writel(RK_CLRSETBITS(1 << 1, 1 << 1), >emmcphy_con[6]); + /* REN Enable on STRB Line for HS400 */ + writel(RK_CLRSETBITS(0, 1 << 9), >emmcphy_con[2]); + read_poll_timeout(readl, >emmcphy_status, dllrdy, PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000); } -- 2.17.1
Re: [PATCH v3 00/18] pxe: Refactoring to tidy up and prepare for bootflow
hi Simon
I am still testing this patchset for master branch! need more time
(but looks like works)
BTW: i have get some problems from prev your commits for example
unbootable raw initrd images
https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
i have send this patch maybe your can identificate problem more
properly (to much changes from v2021.07 - v2021.10
boot process for v2021.07 works well )
Tnx for your work
On Fri, Oct 15, 2021 at 2:48 AM Simon Glass wrote:
>
> This collects together the patches previously sent relating to PXE.
>
> Firstly, it moves the boot code out of common/ and into a new boot/
> directory. This helps to collect these related files in one place, as
> common/ is quite large.
>
> Secondly, it provides patache so clean up the PXE code and refactor it
> into something closer to a module that can be called, teasing apart its
> reliance on the command-line interpreter to access filesystems and the
> like. Also it now uses function arguments and its own context struct
> internally rather than environment variables, which is very hard to
> follow. No core functional change is intended.
>
> Changes in v3:
> - Rebase to -master
>
> Changes in v2:
> - Rebase to -next
> - Split out from the bootmethod patches
>
> Simon Glass (18):
> Create a new boot/ directory
> pxe: Move API comments to the header files
> pxe: Use a context pointer
> pxe: Move do_getfile() into the context
> pxe: Add a userdata field to the context
> pxe: Tidy up the is_pxe global
> pxe: Move pxe_utils files
> pxe: Tidy up some comments in pxe_utils
> pxe: Tidy up code style a little in pxe_utils
> pxe: Move common parsing coding into pxe_util
> pxe: Clean up the use of bootfile
> pxe: Drop get_bootfile_path()
> lib: Add tests for simple_itoa()
> lib: Add a function to convert a string to a hex value
> pxe: Return the file size from the getfile() function
> pxe: Refactor sysboot to have one helper
> doc: Move distro boot doc to rST
> pxe: Allow calling the pxe_get logic directly
>
> Kconfig | 2 +
> Makefile | 3 +-
> README| 1 +
> common/Kconfig.boot => boot/Kconfig | 0
> boot/Makefile | 37 ++
> {common => boot}/android_ab.c | 0
> {common => boot}/boot_fit.c | 0
> {common => boot}/bootm.c | 0
> {common => boot}/bootm_os.c | 0
> {common => boot}/bootretry.c | 0
> {common => boot}/common_fit.c | 0
> {common => boot}/fdt_region.c | 0
> {common => boot}/image-android-dt.c | 0
> {common => boot}/image-android.c | 0
> {common => boot}/image-board.c| 0
> {common => boot}/image-cipher.c | 0
> {common => boot}/image-fdt.c | 0
> {common => boot}/image-fit-sig.c | 0
> {common => boot}/image-fit.c | 0
> {common => boot}/image-host.c | 0
> {common => boot}/image-sig.c | 0
> {common => boot}/image.c | 0
> {cmd => boot}/pxe_utils.c | 512 +++---
> cmd/Makefile | 4 +-
> cmd/pxe.c | 136 +++---
> cmd/pxe_utils.h | 91
> cmd/sysboot.c | 114 +++--
> common/Kconfig| 2 -
> common/Makefile | 22 -
> doc/android/boot-image.rst| 2 +-
> doc/{README.distro => develop/distro.rst} | 177
> doc/develop/index.rst | 1 +
> include/pxe_utils.h | 253 +++
> include/vsprintf.h| 25 +-
> lib/vsprintf.c| 20 +-
> scripts/Makefile.spl | 4 +-
> test/print_ut.c | 41 ++
> tools/Makefile| 18 +-
> 38 files changed, 874 insertions(+), 591 deletions(-)
> rename common/Kconfig.boot => boot/Kconfig (100%)
> create mode 100644 boot/Makefile
> rename {common => boot}/android_ab.c (100%)
> rename {common => boot}/boot_fit.c (100%)
> rename {common => boot}/bootm.c (100%)
> rename {common => boot}/bootm_os.c (100%)
> rename {common => boot}/bootretry.c (100%)
> rename {common => boot}/common_fit.c (100%)
> rename {common => boot}/fdt_region.c (100%)
> rename {common => boot}/image-android-dt.c (100%)
> rename {common => boot}/image-android.c (100%)
> rename {common => boot}/image-board.c (100%)
> rename {common => boot}/image-cipher.c (100%)
> rename {common => boot}/image-fdt.c (100%)
> rename {common => boot}/image-fit-sig.c (100%)
> rename {common => boot}/image-fit.c (100%)
> rename {common => boot}/image-host.c (100%)
> rename {common =>
[PATCH] image: fix select_ramdisk for raw initrd
Problem
We have unbootable raw initrd images because, select_ramdisk for raw
initrd images ignore submited select addr and setup rd_datap value to 0
Solution: setup rd_datap value from select
Signed-off-by: Artem Lapkin
---
common/image-board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/image-board.c b/common/image-board.c
index e7660352e9..e3c6ea806a 100644
--- a/common/image-board.c
+++ b/common/image-board.c
@@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images, const
char *select, u8 arch,
end = strchr(select, ':');
if (end) {
*rd_lenp = hextoul(++end, NULL);
- *rd_datap = rd_addr;
+ *rd_datap = hextoul(select, NULL);
processed = true;
}
}
--
2.25.1
[PATCH] common: Kconfig.boot: add config SPL_FIT_RSASSA_PSS
The padding pss is only supported on u-boot and tools since
commit 2bbed3ff8c7f ("image: Use Kconfig to enable FIT_RSASSA_PSS on host")
This commit adds the config SPL_FIT_RSASSA_PSS to support
the padding pss in the SPL.
Signed-off-by: Philippe Reynes
---
common/Kconfig.boot | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 9b84a8d005..c948d58094 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -175,6 +175,13 @@ config SPL_FIT_SIGNATURE_MAX_SIZE
device memory. Assure this size does not extend past expected storage
space.
+config SPL_FIT_RSASSA_PSS
+ bool "Support rsassa-pss signature scheme of FIT image contents in SPL"
+ depends on SPL_FIT_SIGNATURE
+ help
+ Enable this to support the pss padding algorithm as described
+ in the rfc8017 (https://tools.ietf.org/html/rfc8017) in SPL.
+
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
select SPL_FIT
--
2.17.1
[PATCH] lib: rsa: rsa-verify: also check that padding is not NULL
This commit adds a check on the padding in the function rsa_verify_key
to avoid using a NULL pointer.
Signed-off-by: Philippe Reynes
---
lib/rsa/rsa-verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 600c93ab81..83f7564101 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -340,7 +340,7 @@ static int rsa_verify_key(struct image_sign_info *info,
struct padding_algo *padding = info->padding;
int hash_len;
- if (!prop || !sig || !hash || !checksum)
+ if (!prop || !sig || !hash || !checksum || !padding)
return -EIO;
if (sig_len != (prop->num_bits / 8)) {
--
2.17.1
Re: [PATCH 1/2] arm: imx: move spl_imx_romapi.c to imx8m/ subdirectory
On 15/10/2021 11.02, Peng Fan (OSS) wrote:
>
>
> On 2021/10/14 20:52, Rasmus Villemoes wrote:
>> Currently, if one builds for an iMX platform != imx8m and selects
>> CONFIG_SPL_BOOTROM_SUPPORT, the build breaks because some
>> definitions (struct rom_api, the enum boot_dev_type_e and various
>> QUERY_* macros) are only exposed by the sys_proto.h header when
>> CONFIG_IMX8M=y.
>
> i.MX8ULP also use rom api.
Sorry about that, I thought I was working on top of 2021.10, but now I
see that I was working from 2021.07, which did just have
#ifdef CONFIG_IMX8M
struct rom_api {
OK, so the first patch should go (which leaves the possibility of
selecting an option for which the build will break, but news at 11 I guess).
That leaves the second (I'll respin), along with the complete lack of
documentation of the ROM API.
There's also no documentation anywhere that I can find on the USB
protocol to use from the host for the iMX8MP, can you please provide me
with a pointer to that? E.g. the reference manual for i.MX 8M Dual/8M
QuadLite/8M Quad has a section "6.1.8.2 Serial Download Protocol (SDP)",
but there's no similar thing in the RM for i.MX 8M Plus.
Rasmus
