Re: [PATCH v2 07/32] bootm: Drop arguments from bootm_start()
On Thu, 16 Nov 2023 at 06:11, Simon Glass wrote:
>
> This function does not use its arguments. Drop them.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Tom Rini
> ---
Reviewed-by: Ilias Apalodimas
>
> (no changes since v1)
>
> boot/bootm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index cb61485c226c..fda97706fc26 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -69,8 +69,7 @@ static void boot_start_lmb(struct bootm_headers *images)
> static inline void boot_start_lmb(struct bootm_headers *images) { }
> #endif
>
> -static int bootm_start(struct cmd_tbl *cmdtp, int flag, int argc,
> - char *const argv[])
> +static int bootm_start(void)
> {
> memset((void *), 0, sizeof(images));
> images.verify = env_get_yesno("verify");
> @@ -783,7 +782,7 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int
> argc,
> * any error.
> */
> if (states & BOOTM_STATE_START)
> - ret = bootm_start(cmdtp, flag, argc, argv);
> + ret = bootm_start();
>
> if (!ret && (states & BOOTM_STATE_PRE_LOAD))
> ret = bootm_pre_load(cmdtp, flag, argc, argv);
> --
> 2.43.0.rc0.421.g78406f8d94-goog
>
Re: [PATCH v2 05/32] bootstd: Add missing header file from bootdev.h
On Thu, 16 Nov 2023 at 06:11, Simon Glass wrote: > > Add a dm/uclass-id.h to the bootdev header file, since it uses > enum uclass_id > > Signed-off-by: Simon Glass Reviewed-by: Ilias Apalodimas > --- > > (no changes since v1) > > include/bootdev.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/bootdev.h b/include/bootdev.h > index b079a91b5b7f..c1362673d418 100644 > --- a/include/bootdev.h > +++ b/include/bootdev.h > @@ -7,6 +7,7 @@ > #ifndef __bootdev_h > #define __bootdev_h > > +#include > #include > > struct bootflow; > -- > 2.43.0.rc0.421.g78406f8d94-goog >
Re: [PATCH v2 04/32] treewide: Tidy up semicolon after command macros
On Thu, 16 Nov 2023 at 06:11, Simon Glass wrote: > > The U_BOOT_CMD_COMPLETE() macro has a semicolon at the end, perhaps > inadvertently. Some code has taken advantage of this. > > Tidy this up by dropping the semicolon from the macro and adding it to > macro invocations as required. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini > --- Reviewed-by: Ilias Apalodimas > > (no changes since v1) > > board/freescale/common/vid.c | 2 +- > board/xilinx/common/fru.c| 2 +- > board/xilinx/versal/cmds.c | 2 +- > board/xilinx/zynqmp/cmds.c | 2 +- > cmd/btrfs.c | 2 +- > cmd/eeprom.c | 2 +- > cmd/ext2.c | 4 ++-- > cmd/fs.c | 8 > cmd/pinmux.c | 2 +- > cmd/qfw.c| 2 +- > include/command.h| 2 +- > 11 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c > index 5ec3f2a76b19..fc5d400cfe18 100644 > --- a/board/freescale/common/vid.c > +++ b/board/freescale/common/vid.c > @@ -793,4 +793,4 @@ U_BOOT_CMD( > vdd_read, 1, 0, do_vdd_read, > "read VDD", > " - Read the voltage specified in mV" > -) > +); > diff --git a/board/xilinx/common/fru.c b/board/xilinx/common/fru.c > index c916c3d6b4c8..12b21317496a 100644 > --- a/board/xilinx/common/fru.c > +++ b/board/xilinx/common/fru.c > @@ -85,4 +85,4 @@ U_BOOT_CMD( > fru, 8, 1, do_fru, > "FRU table info", > fru_help_text > -) > +); > diff --git a/board/xilinx/versal/cmds.c b/board/xilinx/versal/cmds.c > index 9cc2cdcebf1c..2a74e49aedec 100644 > --- a/board/xilinx/versal/cmds.c > +++ b/board/xilinx/versal/cmds.c > @@ -98,4 +98,4 @@ U_BOOT_LONGHELP(versal, > U_BOOT_CMD(versal, 4, 1, do_versal, >"versal sub-system", >versal_help_text > -) > +); > diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c > index f1f3eff501e1..9524688f27d9 100644 > --- a/board/xilinx/zynqmp/cmds.c > +++ b/board/xilinx/zynqmp/cmds.c > @@ -427,4 +427,4 @@ U_BOOT_CMD( > zynqmp, 9, 1, do_zynqmp, > "ZynqMP sub-system", > zynqmp_help_text > -) > +); > diff --git a/cmd/btrfs.c b/cmd/btrfs.c > index 98daea99e9ed..2843835d08b8 100644 > --- a/cmd/btrfs.c > +++ b/cmd/btrfs.c > @@ -24,4 +24,4 @@ U_BOOT_CMD(btrsubvol, 3, 1, do_btrsubvol, > "list subvolumes of a BTRFS filesystem", > " \n" > " - List subvolumes of a BTRFS filesystem." > -) > +); > diff --git a/cmd/eeprom.c b/cmd/eeprom.c > index 0b6ca8c505fb..322765ad02a0 100644 > --- a/cmd/eeprom.c > +++ b/cmd/eeprom.c > @@ -435,4 +435,4 @@ U_BOOT_CMD( > "The values which can be provided with the -l option are:\n" > CONFIG_EEPROM_LAYOUT_HELP_STRING"\n" > #endif > -) > +); > diff --git a/cmd/ext2.c b/cmd/ext2.c > index 57a99516a6ac..a0ce0cf5796b 100644 > --- a/cmd/ext2.c > +++ b/cmd/ext2.c > @@ -42,7 +42,7 @@ U_BOOT_CMD( > "list files in a directory (default /)", > " [directory]\n" > "- list files from 'dev' on 'interface' in a 'directory'" > -) > +); > > U_BOOT_CMD( > ext2load, 6, 0, do_ext2load, > @@ -50,4 +50,4 @@ U_BOOT_CMD( > " [ [addr [filename [bytes [pos]\n" > "- load binary file 'filename' from 'dev' on 'interface'\n" > " to address 'addr' from ext2 filesystem." > -) > +); > diff --git a/cmd/fs.c b/cmd/fs.c > index 6044f73af5b4..46cb43dcdb5b 100644 > --- a/cmd/fs.c > +++ b/cmd/fs.c > @@ -39,7 +39,7 @@ U_BOOT_CMD( > " If 'bytes' is 0 or omitted, the file is read until the end.\n" > " 'pos' gives the file byte position to start reading from.\n" > " If 'pos' is 0 or omitted, the file is read from the start." > -) > +); > > static int do_save_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, >char *const argv[]) > @@ -56,7 +56,7 @@ U_BOOT_CMD( > " 'bytes' gives the size to save in bytes and is mandatory.\n" > " 'pos' gives the file byte position to start writing to.\n" > " If 'pos' is 0 or omitted, the file is written from the start." > -) > +); > > static int do_ls_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, > char *const argv[]) > @@ -70,7 +70,7 @@ U_BOOT_CMD( > " [ [directory]]\n" > "- List files in directory 'directory' of partition 'part' on\n" > " device type 'interface' instance 'dev'." > -) > +); > > static int do_ln_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, > char *const argv[]) > @@ -84,7 +84,7 @@ U_BOOT_CMD( > " target linkname\n" > "- create a symbolic link to 'target' with the name 'linkname' > on\n" > " device type 'interface' instance 'dev'." > -) > +); > > static int do_fstype_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, >
Re: [PATCH v2 01/32] arm: x86: Drop discarding of command linker-lists
On Thu, 16 Nov 2023 at 06:11, Simon Glass wrote:
>
> Since we can now cleanly disable CMDLINE when needed, drop the rules
> which discard the command code. It will not be built in the first
> place.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Tom Rini
> ---
>
> (no changes since v1)
>
> arch/arm/cpu/u-boot.lds | 3 ---
> arch/x86/cpu/u-boot-64.lds | 4
> arch/x86/cpu/u-boot-spl.lds | 4
> arch/x86/cpu/u-boot.lds | 4
> 4 files changed, 15 deletions(-)
Reviewed-by: Ilias Apalodimas
>
> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> index fc4f63d83489..7724c9332c3b 100644
> --- a/arch/arm/cpu/u-boot.lds
> +++ b/arch/arm/cpu/u-boot.lds
> @@ -14,9 +14,6 @@ OUTPUT_ARCH(arm)
> ENTRY(_start)
> SECTIONS
> {
> -#ifndef CONFIG_CMDLINE
> - /DISCARD/ : { *(__u_boot_list_2_cmd_*) }
> -#endif
> #if defined(CONFIG_ARMV7_SECURE_BASE) && defined(CONFIG_ARMV7_NONSEC)
> /*
> * If CONFIG_ARMV7_SECURE_BASE is true, secure code will not
> diff --git a/arch/x86/cpu/u-boot-64.lds b/arch/x86/cpu/u-boot-64.lds
> index d0398ff00d71..00a6d8691211 100644
> --- a/arch/x86/cpu/u-boot-64.lds
> +++ b/arch/x86/cpu/u-boot-64.lds
> @@ -11,10 +11,6 @@ ENTRY(_start)
>
> SECTIONS
> {
> -#ifndef CONFIG_CMDLINE
> - /DISCARD/ : { *(__u_boot_list_2_cmd_*) }
> -#endif
> -
> #ifdef CONFIG_TEXT_BASE
> . = CONFIG_TEXT_BASE; /* Location of bootcode in flash */
> #endif
> diff --git a/arch/x86/cpu/u-boot-spl.lds b/arch/x86/cpu/u-boot-spl.lds
> index a0a2a06a18cd..50b4b1608552 100644
> --- a/arch/x86/cpu/u-boot-spl.lds
> +++ b/arch/x86/cpu/u-boot-spl.lds
> @@ -11,10 +11,6 @@ ENTRY(_start)
>
> SECTIONS
> {
> -#ifndef CONFIG_CMDLINE
> - /DISCARD/ : { *(__u_boot_list_2_cmd_*) }
> -#endif
> -
> . = IMAGE_TEXT_BASE;/* Location of bootcode in flash */
> __text_start = .;
> .text : {
> diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
> index a31f4220a000..c418ff44aa08 100644
> --- a/arch/x86/cpu/u-boot.lds
> +++ b/arch/x86/cpu/u-boot.lds
> @@ -11,10 +11,6 @@ ENTRY(_start)
>
> SECTIONS
> {
> -#ifndef CONFIG_CMDLINE
> - /DISCARD/ : { *(__u_boot_list_2_cmd_*) }
> -#endif
> -
> . = CONFIG_TEXT_BASE; /* Location of bootcode in flash */
> __text_start = .;
>
> --
> 2.43.0.rc0.421.g78406f8d94-goog
>
Re: [PATCH 1/1] cmd: eficonfig: create shortened boot options
Hi Heinrich On Fri, 17 Nov 2023 at 01:08, Heinrich Schuchardt wrote: > > The boot options created by eficonfig should use shortened device-paths to > avoid problems if drives are enumerated in a different sequence. > > Signed-off-by: Heinrich Schuchardt > --- > cmd/eficonfig.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c > index e6e8a0a488..3d95092109 100644 > --- a/cmd/eficonfig.c > +++ b/cmd/eficonfig.c > @@ -528,6 +528,7 @@ struct efi_device_path > *eficonfig_create_device_path(struct efi_device_path *dp_ > p += fp_size; > *((struct efi_device_path *)p) = END; > > + dp_volume = efi_dp_shorten(dp_volume); efi_dp_shorten can return null. Dont we need to check that here? Thanks /Ilias > dp = efi_dp_append(dp_volume, (struct efi_device_path *)buf); > free(buf); > > -- > 2.40.1 >
Re: [PATCH v5 2/5] fdt: kaslr seed from RNG device
Hi Sean
There are a few reviewed-by tags missing since v3/v4. Any reason you
dropped those? The change log doesn't mention anything
Thanks
/Ilias
On Fri, 17 Nov 2023 at 04:02, wrote:
>
> From: Dhananjay Phadke
>
> Add support for KASLR seed from the RNG device. Invokes dm_rng_read()
> API to read 8-bytes of random bytes. Performs the FDT fixup using event
> spy. To enable use CONFIG_KASLR_RNG_SEED
>
> Signed-off-by: Dhananjay Phadke
> Signed-off-by: Drew Kluemke
> Signed-off-by: Sean Edmond
> ---
> boot/fdt_support.c | 36
> lib/Kconfig| 7 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> index 49d14a949be..12defcf645c 100644
> --- a/boot/fdt_support.c
> +++ b/boot/fdt_support.c
> @@ -12,7 +12,10 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -650,6 +653,39 @@ int fdt_fixup_kaslr_seed(ofnode node, const u8 *seed,
> int len)
> return 0;
> }
>
> +int fdt_rng_kaslr_seed(void *ctx, struct event *event)
> +{
> + u8 rand[8] = {0};
> + struct udevice *dev;
> + int ret;
> + oftree tree = event->data.ft_fixup.tree;
> + ofnode root_node = oftree_root(tree);
> +
> + ret = uclass_first_device_err(UCLASS_RNG, );
> + if (ret) {
> + printf("ERROR: Failed to find RNG device\n");
> + return ret;
> + }
> +
> + ret = dm_rng_read(dev, rand, sizeof(rand));
> + if (ret) {
> + printf("ERROR: RNG read failed, ret=%d\n", ret);
> + return ret;
> + }
> +
> + ret = fdt_fixup_kaslr_seed(root_node, rand, sizeof(rand));
> + if (ret) {
> + printf("ERROR: failed to add kaslr-seed to fdt\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +#if defined(CONFIG_KASLR_RNG_SEED)
> +EVENT_SPY(EVT_FT_FIXUP, fdt_rng_kaslr_seed);
> +#endif
> +
> int fdt_record_loadable(void *blob, u32 index, const char *name,
> uintptr_t load_addr, u32 size, uintptr_t entry_point,
> const char *type, const char *os, const char *arch)
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 19649517a39..4f5dfc00d6f 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -477,6 +477,13 @@ config VPL_TPM
> for the low-level TPM interface, but only one TPM is supported at
> a time by the TPM library.
>
> +config KASLR_RNG_SEED
> + bool "Use RNG driver for KASLR random seed"
> + depends on DM_RNG
> + help
> + This enables support for using the RNG driver as entropy source for
> + KASLR seed populated in kernel's device tree.
> +
> endmenu
>
> menu "Android Verified Boot"
> --
> 2.42.0
>
Re: [PATCH v5 3/3] net: bootp: add config option BOOTP_RANDOM_XID
On Fri, Nov 17, 2023 at 04:48:26PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > The new config option BOOTP_RANDOM_XID will randomize the transaction ID > for each new BOOT/DHCPv4 exchange. > > Signed-off-by: Sean Edmond Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements
On Fri, Nov 17, 2023 at 04:48:25PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > This patch introduces 3 improvements to align with RFC 951: > - retransmission backoff interval maximum is configurable > - initial retranmission backoff interval is configurable > - transaction ID is kept the same for each BOOTP/DHCPv4 request [snip] > diff --git a/cmd/Kconfig b/cmd/Kconfig > index ae846b204dc..93bf752035c 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1717,6 +1717,7 @@ if CMD_NET > config CMD_BOOTP > bool "bootp" > default y > + select LIB_RAND This should be "depends on LIB_RAND || LIB_HW_RAND" and not a select as either one provides the needed interface. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 1/3] net: Additional fixes for dhcp option 209
On Fri, Nov 17, 2023 at 04:48:24PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > Addresses feedback from latest review: > - Enable option 209 by default > - Set pxelinux_configfile to NULL to avoid potential double free > - change hardcoced 209 to a define I was unclear in reply to v4, sorry. This is the kind of commit message I was saying needs to be reworded to say what it's doing, not saying it's in response to review of... -- Tom signature.asc Description: PGP signature
[PATCH v5 3/3] net: bootp: add config option BOOTP_RANDOM_XID
From: Sean Edmond
The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.
Signed-off-by: Sean Edmond
---
changes in v5:
- fix depends for BOOTP_RANDOM_XID:
"depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)"
changes in v3:
- Add depends for BOOTP_RANDOM_XID
cmd/Kconfig | 7 +++
net/bootp.c | 31 +--
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 93bf752035c..baab359c55b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1853,6 +1853,13 @@ config BOOTP_VCI_STRING
default "U-Boot.arm" if ARM
default "U-Boot"
+config BOOTP_RANDOM_XID
+ bool "Send random transaction ID to BOOTP/DHCP server"
+ depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)
+ help
+ Selecting this will allow for a random transaction ID to get
+ selected for each BOOTP/DHCPv4 exchange.
+
if CMD_DHCP6
config DHCP6_PXE_CLIENTARCH
diff --git a/net/bootp.c b/net/bootp.c
index 89425717328..49cd9064436 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -837,22 +837,25 @@ void bootp_request(void)
/* Only generate a new transaction ID for each new BOOTP request */
if (bootp_try == 1) {
- /*
-* Bootp ID is the lower 4 bytes of our ethernet address
-* plus the current time in ms.
-*/
- bootp_id = ((u32)net_ethaddr[2] << 24)
- | ((u32)net_ethaddr[3] << 16)
- | ((u32)net_ethaddr[4] << 8)
- | (u32)net_ethaddr[5];
- bootp_id += get_timer(0);
- bootp_id = htonl(bootp_id);
- bootp_add_id(bootp_id);
- net_copy_u32(>bp_id, _id);
- } else {
- net_copy_u32(>bp_id, _id);
+ if (IS_ENABLED(CONFIG_BOOTP_RANDOM_XID)) {
+ srand(get_ticks() + rand());
+ bootp_id = rand();
+ } else {
+ /*
+* Bootp ID is the lower 4 bytes of our ethernet
address
+* plus the current time in ms.
+*/
+ bootp_id = ((u32)net_ethaddr[2] << 24)
+ | ((u32)net_ethaddr[3] << 16)
+ | ((u32)net_ethaddr[4] << 8)
+ | (u32)net_ethaddr[5];
+ bootp_id += get_timer(0);
+ bootp_id = htonl(bootp_id);
+ }
}
+ bootp_add_id(bootp_id);
+ net_copy_u32(>bp_id, _id);
/*
* Calculate proper packet lengths taking into account the
* variable size of the options field
--
2.42.0
[PATCH v5 1/3] net: Additional fixes for dhcp option 209
From: Sean Edmond
Addresses feedback from latest review:
- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoced 209 to a define
Signed-off-by: Sean Edmond
---
changes in v4:
- rebase master and resolve conflicts
- change commit description for this patch (this is now
an enhancement patch)
- default y for BOOTP_PXE_DHCP_OPTION (feedback from review)
changes in v3:
- add define for option 209 and rfc5071 reference
cmd/Kconfig | 1 +
cmd/pxe.c | 2 ++
net/bootp.c | 4 ++--
net/bootp.h | 2 ++
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index df6d71c103f..ae846b204dc 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1842,6 +1842,7 @@ config BOOTP_PXE_CLIENTARCH
config BOOTP_PXE_DHCP_OPTION
bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
+ default y
depends on BOOTP_PXE
config BOOTP_VCI_STRING
diff --git a/cmd/pxe.c b/cmd/pxe.c
index 21134eb7a30..9404f445187 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -65,6 +65,8 @@ static int pxe_dhcp_option_path(struct pxe_context *ctx,
unsigned long pxefile_a
int ret = get_pxe_file(ctx, pxelinux_configfile, pxefile_addr_r);
free(pxelinux_configfile);
+ /* set to NULL to avoid double-free if DHCP is tried again */
+ pxelinux_configfile = NULL;
return ret;
}
diff --git a/net/bootp.c b/net/bootp.c
index 68002909634..24547cf7bfd 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -603,7 +603,7 @@ static int dhcp_extended(u8 *e, int message_type, struct
in_addr server_ip,
*cnt += 1;
#endif
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
- *e++ = 209; /* PXELINUX Config File */
+ *e++ = DHCP_OPTION_PXE_CONFIG_FILE; /* PXELINUX Config File
*/
*cnt += 1;
}
/* no options, so back up to avoid sending an empty request list */
@@ -914,7 +914,7 @@ static void dhcp_process_options(uchar *popt, uchar *end)
net_boot_file_name[size] = 0;
}
break;
- case 209: /* PXELINUX Config File */
+ case DHCP_OPTION_PXE_CONFIG_FILE: /* PXELINUX Config File
*/
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
/* In case it has already been allocated when
get DHCP Offer packet,
* free first to avoid memory leak.
diff --git a/net/bootp.h b/net/bootp.h
index 4e32b19d424..24b32c73f62 100644
--- a/net/bootp.h
+++ b/net/bootp.h
@@ -91,6 +91,8 @@ typedef enum { INIT,
#define DHCP_NAK 6
#define DHCP_RELEASE 7
+#define DHCP_OPTION_PXE_CONFIG_FILE209 /* "ConfigFile" option
according to rfc5071 */
+
/**/
#endif /* __BOOTP_H__ */
--
2.42.0
[PATCH v5 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements
From: Sean Edmond
This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request
In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.
RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds. This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"
The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients. This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".
Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.
Signed-off-by: Sean Edmond
---
changes in v4:
- Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission
improvements require rand())
changes in v3:
- Set RETRANSMIT_PERIOD_MAX_MS=6
- Add randomization factor to retransmission timeout
changes in v2:
- use env_get_ulong() to get environment variables
cmd/Kconfig | 2 +-
net/bootp.c | 71 +
2 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ae846b204dc..93bf752035c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1717,6 +1717,7 @@ if CMD_NET
config CMD_BOOTP
bool "bootp"
default y
+ select LIB_RAND
help
bootp - boot image via network using BOOTP/TFTP protocol
@@ -1725,7 +1726,6 @@ config CMD_DHCP
depends on CMD_BOOTP
help
Boot image via network using DHCP/TFTP protocol
-
config CMD_DHCP6
bool "dhcp6"
depends on IPV6
diff --git a/net/bootp.c b/net/bootp.c
index 24547cf7bfd..89425717328 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -42,6 +42,22 @@
*/
#define TIMEOUT_MS ((3 + (CONFIG_NET_RETRY_COUNT * 5)) * 1000)
+/*
+ * According to rfc951 : 7.2. Client Retransmission Strategy
+ * "After the 'average' backoff reaches about 60 seconds, it should be
+ * increased no further, but still randomized."
+ *
+ * U-Boot has saturated this backoff at 2 seconds for a long time.
+ * To modify, set the environment variable "bootpretransmitperiodmax"
+ */
+#define RETRANSMIT_PERIOD_MAX_MS 6
+
+/* Retransmission timeout for the initial packet (in milliseconds).
+ * This timeout will double on each retry. To modify, set the
+ * environment variable bootpretransmitperiodinit.
+ */
+#define RETRANSMIT_PERIOD_INIT_MS 250
+
#ifndef CFG_DHCP_MIN_EXT_LEN /* minimal length of extension list */
#define CFG_DHCP_MIN_EXT_LEN 64
#endif
@@ -53,6 +69,7 @@
u32bootp_ids[CFG_BOOTP_ID_CACHE_SIZE];
unsigned int bootp_num_ids;
intbootp_try;
+u32bootp_id;
ulong bootp_start;
ulong bootp_timeout;
char net_nis_domain[32] = {0,}; /* Our NIS domain */
@@ -60,6 +77,7 @@ char net_hostname[32] = {0,}; /* Our hostname */
char net_root_path[CONFIG_BOOTP_MAX_ROOT_PATH_LEN] = {0,}; /* Our bootpath */
static ulong time_taken_max;
+static u32 retransmit_period_max_ms;
#if defined(CONFIG_CMD_DHCP)
static dhcp_state_t dhcp_state = INIT;
@@ -396,6 +414,7 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct
in_addr sip,
static void bootp_timeout_handler(void)
{
ulong time_taken = get_timer(bootp_start);
+ int rand_minus_plus_100;
if (time_taken >= time_taken_max) {
#ifdef CONFIG_BOOTP_MAY_FAIL
@@ -414,8 +433,17 @@ static void bootp_timeout_handler(void)
}
} else {
bootp_timeout *= 2;
- if (bootp_timeout > 2000)
- bootp_timeout = 2000;
+ if (bootp_timeout > retransmit_period_max_ms)
+ bootp_timeout = retransmit_period_max_ms;
+
+ /* Randomize by adding bootp_timeout*RAND, where RAND
+* is a randomization factor between -0.1..+0.1
+*/
+ srand(get_ticks() + rand());
+ rand_minus_plus_100 = ((rand() % 200) - 100);
+ bootp_timeout = bootp_timeout +
+ (((int)bootp_timeout * rand_minus_plus_100) /
1000);
+
net_set_timeout_handler(bootp_timeout, bootp_timeout_handler);
bootp_request();
}
@@ -711,10 +739,14 @@ static int bootp_extended(u8 *e)
void bootp_reset(void)
{
+ char *ep; /* Environment pointer */
+
bootp_num_ids =
[PATCH v5 0/3] BOOTP/DHCPv4 enhancements
From: Sean Edmond In our datacenter application, a single DHCP server is servicing 36000+ clients. Improvements are required to the DHCPv4 retransmission behavior to align with RFC and ensure less pressure is exerted on the server: - retransmission backoff interval maximum is configurable (environment variable bootpretransmitperiodmax) - initial retransmission backoff interval is configurable (environment variable bootpretransmitperiodinit) - transaction ID is kept the same for each BOOTP/DHCPv4 request (not recreated on each retry) For our application we'll use: - bootpretransmitperiodmax=16000 - bootpretransmitperiodinit=2000 A new configuration BOOTP_RANDOM_XID has been added to enable a randomized BOOTP/DHCPv4 transaction ID. Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous patch was accepted. A new patch fixes a possible double free() and addresses latest review comments. changes in v5: - fix depends for BOOTP_RANDOM_XID: "depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)" - add change log to individual patches changes in v4: - rebase master and resolve conflicts - change commit description for DHCP option 209 patch (this is now an enhancement patch) - default y for BOOTP_PXE_DHCP_OPTION (feedback from review) - Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission improvements require rand()) changes in v3: - add define for option 209 and rfc5071 reference - Set RETRANSMIT_PERIOD_MAX_MS=6 - Add randomization factor to retransmission timeout - Add depends for BOOTP_RANDOM_XID changes in v2: - use env_get_ulong() to get environment variables Sean Edmond (3): net: Additional fixes for dhcp option 209 net: bootp: BOOTP/DHCPv4 retransmission improvements net: bootp: add config option BOOTP_RANDOM_XID cmd/Kconfig | 10 ++- cmd/pxe.c | 2 ++ net/bootp.c | 76 + net/bootp.h | 2 ++ 4 files changed, 72 insertions(+), 18 deletions(-) -- 2.42.0
Re: [PATCH v2] usb: dwc3-generic: Use combined glue and ctrl node for RK3588
Hi Marek, On 2023-11-13 04:11, Marek Vasut wrote: > On 11/12/23 16:25, Jonas Karlman wrote: >> Like Rockchip RK3328 and RK3568, the RK3588 also have a single node to >> represent the glue and ctrl for USB 3.0. >> >> Use rk_ops as driver data to select correct ctrl node for RK3588 DWC3. >> >> Signed-off-by: Jonas Karlman >> Reviewed-by: Kever Yang > > Reviewed-by: Marek Vasut > > Do you still want this in 2024.01 ? The MW closed just a few days ago, > but this seems OKish to put in still . It should not matter if this goes to master or next. Next linux DT sync when this may be needed will probably not be until around v6.8-rc1. Regards, Jonas
[PATCH v2 4/4] rockchip: rk3588s-orangepi-5: Build SPI image
Enable building of the SPI image, u-boot-rockchip-spi.bin, now that we
know what bootsource id values BootRom use for SPI flash on RK3588.
Fixes: 28c5f941edf7 ("board: rockchip: Add Xunlong Orange Pi 5")
Signed-off-by: Jonas Karlman
---
v2:
- No change
configs/orangepi-5-rk3588s_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/orangepi-5-rk3588s_defconfig
b/configs/orangepi-5-rk3588s_defconfig
index feb45a53853b..1e33c832ec67 100644
--- a/configs/orangepi-5-rk3588s_defconfig
+++ b/configs/orangepi-5-rk3588s_defconfig
@@ -13,6 +13,7 @@ CONFIG_SF_DEFAULT_MODE=0x2000
CONFIG_DEFAULT_DEVICE_TREE="rk3588s-orangepi-5"
CONFIG_ROCKCHIP_RK3588=y
CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK_R_ADDR=0x60
CONFIG_TARGET_EVB_RK3588=y
--
2.42.0
[PATCH v2 0/4] rockchip: rk3588: Fix SPI flash bootsource id values
The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
At the time the reason for this new bootsource id value 6 was unknown.
Since then the following bootsource id values have been observed on
different RK3588 devices:
- Radxa ROCK 5 Model A - fspim0_pins - rk3588s
- Xunlong Orange Pi 5 - fspim0_pins - rk3588s
brom_bootdevice_id: 3
- FriendlyElec NanoPC-T6 - fspim1_pins - rk3588
- Xunlong Orange Pi 5 Plus - fspim1_pins - rk3588
brom_bootdevice_id: 4
- Radxa ROCK 5 Model B - fspim2_pins - rk3588
brom_bootdevice_id: 6
It has now been confirmed that the BootRom on RK3588 use different
bootsource id values depending on the iomux used by the flash spi
controller, and not by the type of spi nor or spi nand flash used.
This series adjusts the bootsource enum values, updates the boot_devices
array to fix booting from SPI flash on RK3588 devices using fspim1_pins.
It also enable building of a bootable SPI image for affected devices.
Changes in v2:
- Move FSPI M0/M1/M2 enum values from bootrom.h to rk3588.c
- Add t-b tag
John Clark (1):
rockchip: rk3588-nanopc-t6: Build SPI image
Jonas Karlman (2):
rockchip: rk3588: Fix boot from SPI flash
rockchip: rk3588s-orangepi-5: Build SPI image
Slawomir Stepien (1):
rockchip: rk3588-orangepi-5-plus: Build SPI image
arch/arm/include/asm/arch-rockchip/bootrom.h | 1 -
arch/arm/mach-rockchip/rk3588/rk3588.c | 16 ++--
configs/nanopc-t6-rk3588_defconfig | 1 +
configs/orangepi-5-plus-rk3588_defconfig | 1 +
configs/orangepi-5-rk3588s_defconfig | 1 +
5 files changed, 17 insertions(+), 3 deletions(-)
--
2.42.0
[PATCH v2 3/4] rockchip: rk3588-orangepi-5-plus: Build SPI image
From: Slawomir Stepien
Enable building of the SPI image, u-boot-rockchip-spi.bin, now that we
know what bootsource id values BootRom use for SPI flash on RK3588.
Fixes: b51cf8bb09b6 ("board: rockchip: Add Xunlong Orange Pi 5 Plus")
Signed-off-by: Slawomir Stepien
Signed-off-by: Jonas Karlman
---
v2:
- No change
configs/orangepi-5-plus-rk3588_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/orangepi-5-plus-rk3588_defconfig
b/configs/orangepi-5-plus-rk3588_defconfig
index 04736996217e..e1cd753a6d18 100644
--- a/configs/orangepi-5-plus-rk3588_defconfig
+++ b/configs/orangepi-5-plus-rk3588_defconfig
@@ -14,6 +14,7 @@ CONFIG_SF_DEFAULT_MODE=0x2000
CONFIG_DEFAULT_DEVICE_TREE="rk3588-orangepi-5-plus"
CONFIG_ROCKCHIP_RK3588=y
CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK_R_ADDR=0x60
CONFIG_TARGET_EVB_RK3588=y
--
2.42.0
[PATCH v2 1/4] rockchip: rk3588: Fix boot from SPI flash
The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
At the time the reason for this new bootsource id value 6 was unknown.
We now know that the BootRom on RK3588 use different bootsource id
values depending on the iomux used by the flash spi controller, and not
by the type of spi nor or spi nand flash used.
Add the following enum values and use them for RK3588 boot_devices.
- BROM_BOOTSOURCE_FSPI_M0 = 3
- BROM_BOOTSOURCE_FSPI_M1 = 4
- BROM_BOOTSOURCE_FSPI_M2 = 6
Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash")
Signed-off-by: Jonas Karlman
Tested-by: Slawomir Stepien
---
v2:
- Move FSPI M0/M1/M2 enum values from bootrom.h to rk3588.c
- Add t-b tag
arch/arm/include/asm/arch-rockchip/bootrom.h | 1 -
arch/arm/mach-rockchip/rk3588/rk3588.c | 16 ++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
b/arch/arm/include/asm/arch-rockchip/bootrom.h
index 7dab18fbc3fb..4276a0f6811a 100644
--- a/arch/arm/include/asm/arch-rockchip/bootrom.h
+++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
@@ -48,7 +48,6 @@ enum {
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
BROM_BOOTSOURCE_SD = 5,
- BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
BROM_BOOTSOURCE_USB = 10,
BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
};
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index b1f535fad505..7b0349ec2577 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -37,11 +37,23 @@ DECLARE_GLOBAL_DATA_PTR;
#define BUS_IOC_GPIO2D_IOMUX_SEL_H 0x5c
#define BUS_IOC_GPIO3A_IOMUX_SEL_L 0x60
+/**
+ * Boot-device identifiers used by the BROM on RK3588 when device is booted
+ * from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
+ * and not the type of SPI flash used.
+ */
+enum {
+ BROM_BOOTSOURCE_FSPI_M0 = 3,
+ BROM_BOOTSOURCE_FSPI_M1 = 4,
+ BROM_BOOTSOURCE_FSPI_M2 = 6,
+};
+
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
- [BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
+ [BROM_BOOTSOURCE_FSPI_M0] = "/spi@fe2b/flash@0",
+ [BROM_BOOTSOURCE_FSPI_M1] = "/spi@fe2b/flash@0",
+ [BROM_BOOTSOURCE_FSPI_M2] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
- [BROM_BOOTSOURCE_SPINOR_RK3588] = "/spi@fe2b/flash@0",
};
static struct mm_region rk3588_mem_map[] = {
--
2.42.0
[PATCH v2 2/4] rockchip: rk3588-nanopc-t6: Build SPI image
From: John Clark
Enable building of the SPI image, u-boot-rockchip-spi.bin, now that we
know what bootsource id values BootRom use for SPI flash on RK3588.
Fixes: b0b8086898f8 ("board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board")
Signed-off-by: John Clark
Signed-off-by: Jonas Karlman
---
v2:
- No change
configs/nanopc-t6-rk3588_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/nanopc-t6-rk3588_defconfig
b/configs/nanopc-t6-rk3588_defconfig
index 070399ce2a86..daa13a48 100644
--- a/configs/nanopc-t6-rk3588_defconfig
+++ b/configs/nanopc-t6-rk3588_defconfig
@@ -14,6 +14,7 @@ CONFIG_SF_DEFAULT_MODE=0x2000
CONFIG_DEFAULT_DEVICE_TREE="rk3588-nanopc-t6"
CONFIG_ROCKCHIP_RK3588=y
CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK_R_ADDR=0x60
CONFIG_TARGET_NANOPCT6_RK3588=y
--
2.42.0
[PATCH 5/5] global: Drop common.h inclusion
In order to make it easier to move on to dropping common.h from code
directly, remove common.h inclusion from the rest of the header file
which had been including it.
Signed-off-by: Tom Rini
---
board/BuR/common/br_resetc.h | 1 -
board/CZ.NIC/turris_mox/mox_sp.h | 2 --
board/freescale/common/vsc3316_3308.h | 1 -
board/ti/ks2_evm/mux-k2g.h | 1 -
board/tq/tqma6/tqma6_bb.h | 2 --
board/xilinx/zynqmp/xil_io.h | 1 -
disk/part_amiga.h | 1 -
drivers/bios_emulator/include/x86emu.h | 1 -
drivers/crypto/fsl/jobdesc.h | 1 -
drivers/crypto/fsl/rsa_caam.h | 2 --
drivers/ddr/altera/sdram_soc64.h | 1 -
drivers/ddr/marvell/a38x/ddr_ml_wrapper.h | 1 -
drivers/net/fm/fm.h| 1 -
drivers/net/fsl-mc/dpio/qbman_private.h| 1 -
drivers/net/fsl-mc/dpio/qbman_sys.h| 1 +
drivers/net/mscc_eswitch/mscc_mac_table.c | 1 +
drivers/net/mscc_eswitch/mscc_mac_table.h | 2 --
drivers/net/mscc_eswitch/mscc_xfer.c | 1 +
drivers/net/mscc_eswitch/mscc_xfer.h | 2 --
drivers/pci/pcie_layerscape_fixup_common.h | 2 --
drivers/pci_endpoint/pcie-cadence.h| 1 -
drivers/pinctrl/mtmips/pinctrl-mtmips-common.h | 2 --
drivers/usb/gadget/bcm_udc_otg.h | 2 --
fs/btrfs/ctree.h | 1 -
fs/yaffs2/ydirectenv.h | 1 -
lib/libavb/avb_sysdeps.h | 4 +++-
lib/zlib/zlib.h| 1 -
net/arp.h | 2 --
net/link_local.h | 5 +
net/net_rand.h | 1 -
net/ping.h | 1 -
31 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/board/BuR/common/br_resetc.h b/board/BuR/common/br_resetc.h
index ba0689bf2050..999045b867d2 100644
--- a/board/BuR/common/br_resetc.h
+++ b/board/BuR/common/br_resetc.h
@@ -7,7 +7,6 @@
*/
#ifndef __CONFIG_BRRESETC_H__
#define __CONFIG_BRRESETC_H__
-#include
int br_resetc_regget(u8 reg, u8 *dst);
int br_resetc_regset(u8 reg, u8 val);
diff --git a/board/CZ.NIC/turris_mox/mox_sp.h b/board/CZ.NIC/turris_mox/mox_sp.h
index 720880d5df32..c766c7423ac5 100644
--- a/board/CZ.NIC/turris_mox/mox_sp.h
+++ b/board/CZ.NIC/turris_mox/mox_sp.h
@@ -6,8 +6,6 @@
#ifndef _BOARD_CZNIC_TURRIS_MOX_MOX_SP_H_
#define _BOARD_CZNIC_TURRIS_MOX_MOX_SP_H_
-#include
-
enum cznic_a3720_board {
BOARD_UNDEFINED = 0x0,
BOARD_TURRIS_MOX= 0x1,
diff --git a/board/freescale/common/vsc3316_3308.h
b/board/freescale/common/vsc3316_3308.h
index 8d343ba4d654..9725d6d9e390 100644
--- a/board/freescale/common/vsc3316_3308.h
+++ b/board/freescale/common/vsc3316_3308.h
@@ -6,7 +6,6 @@
#ifndef __VSC_CROSSBAR_H_
#define __VSC_CROSSBAR_H_
-#include
#include
#include
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index f24e62850b8b..447e70607f96 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/board/tq/tqma6/tqma6_bb.h b/board/tq/tqma6/tqma6_bb.h
index ca81bdf58535..a2f871af1f83 100644
--- a/board/tq/tqma6/tqma6_bb.h
+++ b/board/tq/tqma6/tqma6_bb.h
@@ -7,8 +7,6 @@
#ifndef __TQMA6_BB__
#define __TQMA6_BB__
-#include
-
int tqma6_bb_board_mmc_getwp(struct mmc *mmc);
int tqma6_bb_board_mmc_getcd(struct mmc *mmc);
int tqma6_bb_board_mmc_init(struct bd_info *bis);
diff --git a/board/xilinx/zynqmp/xil_io.h b/board/xilinx/zynqmp/xil_io.h
index e6caa7c85033..dd823d6f62a5 100644
--- a/board/xilinx/zynqmp/xil_io.h
+++ b/board/xilinx/zynqmp/xil_io.h
@@ -5,7 +5,6 @@
/* FIXME remove this when vivado is fixed */
#include
-#include
#include
#define xil_printf(...)
diff --git a/disk/part_amiga.h b/disk/part_amiga.h
index 42f5eb0f941c..dfa70bdb8a8c 100644
--- a/disk/part_amiga.h
+++ b/disk/part_amiga.h
@@ -7,7 +7,6 @@
#ifndef _DISK_PART_AMIGA_H
#define _DISK_PART_AMIGA_H
-#include
#if CONFIG_IS_ENABLED(ISO_PARTITION)
/* Make the buffers bigger if ISO partition support is enabled -- CD-ROMS
diff --git a/drivers/bios_emulator/include/x86emu.h
b/drivers/bios_emulator/include/x86emu.h
index b28cdc6b8cad..d2650a8d1600 100644
--- a/drivers/bios_emulator/include/x86emu.h
+++ b/drivers/bios_emulator/include/x86emu.h
@@ -42,7 +42,6 @@
#define __X86EMU_X86EMU_H
#include
-#include
#include
#include
#define X86API
diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
index c4501abd26b2..69adfdca95b5 100644
--- a/drivers/crypto/fsl/jobdesc.h
+++ b/drivers/crypto/fsl/jobdesc.h
@@ -7,7 +7,6 @@
#ifndef __JOBDESC_H
#define __JOBDESC_H
-#include
#include
#include "rsa_caam.h"
diff --git
[PATCH 4/5] sandbox: Audit config.h and common.h usage
Remove and replace common.h and config.h in sandbox when it's not needed
and add some explicit includes where needed.
Signed-off-by: Tom Rini
---
arch/sandbox/cpu/cache.c | 1 -
arch/sandbox/cpu/cpu.c | 1 -
arch/sandbox/cpu/sdl.c | 2 +-
arch/sandbox/cpu/spl.c | 1 -
arch/sandbox/cpu/start.c | 2 +-
arch/sandbox/cpu/state.c | 2 +-
arch/sandbox/include/asm/io.h| 2 ++
arch/sandbox/include/asm/state.h | 1 -
arch/sandbox/lib/bootm.c | 1 -
arch/sandbox/lib/fdt_fixup.c | 1 -
arch/sandbox/lib/interrupts.c| 1 -
arch/sandbox/lib/pci_io.c| 1 -
board/sandbox/sandbox.c | 2 +-
13 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/sandbox/cpu/cache.c b/arch/sandbox/cpu/cache.c
index 46c62c0b4461..c8a5e64214b6 100644
--- a/arch/sandbox/cpu/cache.c
+++ b/arch/sandbox/cpu/cache.c
@@ -3,7 +3,6 @@
* Copyright 2020, Heinrich Schuchardt
*/
-#include
#include
#include
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index a1c5c7c4311a..d6475c969c4d 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,7 +5,6 @@
#define LOG_CATEGORY LOGC_SANDBOX
-#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/sdl.c b/arch/sandbox/cpu/sdl.c
index 590e406517bf..ed84646bdab7 100644
--- a/arch/sandbox/cpu/sdl.c
+++ b/arch/sandbox/cpu/sdl.c
@@ -72,7 +72,7 @@ static struct sdl_info {
static void sandbox_sdl_poll_events(void)
{
/*
-* We don't want to include common.h in this file since it uses
+* We don't want to include cpu_func.h in this file since it uses
* system headers. So add a declation here.
*/
extern void reset_cpu(void);
diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index 16b766279833..9ad9da686c6a 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -3,7 +3,6 @@
* Copyright (c) 2016 Google, Inc
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 2589c2eba738..dce804165296 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -3,7 +3,7 @@
* Copyright (c) 2011-2012 The Chromium OS Authors.
*/
-#include
+#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index e38bb248b7ff..2462f990baae 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -3,7 +3,7 @@
* Copyright (c) 2011-2012 The Chromium OS Authors.
*/
-#include
+#include
#include
#include
#include
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 31ab7289b4bd..1ccb25a0fe1e 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -6,6 +6,8 @@
#ifndef __SANDBOX_ASM_IO_H
#define __SANDBOX_ASM_IO_H
+#include
+
enum sandboxio_size_t {
SB_SIZE_8,
SB_SIZE_16,
diff --git a/arch/sandbox/include/asm/state.h b/arch/sandbox/include/asm/state.h
index 59a20595f51d..c84a1f7060f4 100644
--- a/arch/sandbox/include/asm/state.h
+++ b/arch/sandbox/include/asm/state.h
@@ -6,7 +6,6 @@
#ifndef __SANDBOX_STATE_H
#define __SANDBOX_STATE_H
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
index dc8b8e46cb41..270671145a0b 100644
--- a/arch/sandbox/lib/bootm.c
+++ b/arch/sandbox/lib/bootm.c
@@ -4,7 +4,6 @@
* Copyright (c) 2015 Sjoerd Simons
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/fdt_fixup.c b/arch/sandbox/lib/fdt_fixup.c
index a646f2059c2c..e333bd52ea28 100644
--- a/arch/sandbox/lib/fdt_fixup.c
+++ b/arch/sandbox/lib/fdt_fixup.c
@@ -2,7 +2,6 @@
#define LOG_CATEGORY LOGC_ARCH
-#include
#include
#include
diff --git a/arch/sandbox/lib/interrupts.c b/arch/sandbox/lib/interrupts.c
index 4d7cbff802c6..3f6583e11f04 100644
--- a/arch/sandbox/lib/interrupts.c
+++ b/arch/sandbox/lib/interrupts.c
@@ -5,7 +5,6 @@
* found in the LICENSE file.
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/pci_io.c b/arch/sandbox/lib/pci_io.c
index 2038141947ab..6040eacb594f 100644
--- a/arch/sandbox/lib/pci_io.c
+++ b/arch/sandbox/lib/pci_io.c
@@ -8,7 +8,6 @@
* IO space access commands.
*/
-#include
#include
#include
#include
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 9d58860451c5..802596569c64 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -3,8 +3,8 @@
* Copyright (c) 2011 The Chromium OS Authors.
*/
-#include
#include
+#include
#include
#include
#include
--
2.34.1
[PATCH 3/5] arm: Partial cleanup and audit usage of
We need to include directly when a file needs to have
something such as CFG_SYS_SDRAM_SIZE referenced as this file is not
automatically globally included and is most commonly indirectly included
via common.h. Remove most cases of arm including config.h directly, but
add it where needed. This includes a few board-specific fixes.
Signed-off-by: Tom Rini
---
arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 --
arch/arm/include/asm/arch-ls102xa/fsl_serdes.h| 2 --
arch/arm/include/asm/assembler.h | 1 -
arch/arm/include/asm/secure.h | 1 -
arch/arm/include/asm/string.h | 2 --
arch/arm/mach-davinci/include/mach/pinmux_defs.h | 1 -
arch/arm/mach-exynos/exynos4_setup.h | 1 -
arch/arm/mach-exynos/exynos5_setup.h | 1 -
arch/arm/mach-k3/common.c | 1 +
arch/arm/mach-k3/include/mach/clock.h | 2 --
arch/arm/mach-k3/include/mach/j721e_hardware.h| 1 -
arch/arm/mach-k3/include/mach/j721s2_hardware.h | 1 -
arch/arm/mach-k3/r5_mpu.c | 1 +
board/freescale/ls1088a/eth_ls1088aqds.c | 1 +
board/freescale/ls2080aqds/eth.c | 1 +
board/toradex/verdin-am62/verdin-am62.c | 1 +
drivers/ddr/marvell/axp/ddr3_axp.h| 2 ++
17 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index 8f4365175697..9e29350ca4ba 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -7,8 +7,6 @@
#ifndef __FSL_SERDES_H__
#define __FSL_SERDES_H__
-#include
-
#ifdef CONFIG_FSL_LSCH3
enum srds_prtcl {
/*
diff --git a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
index d99a6f318f8b..9244e0a78fd3 100644
--- a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
@@ -6,8 +6,6 @@
#ifndef __FSL_SERDES_H
#define __FSL_SERDES_H
-#include
-
enum srds_prtcl {
/*
* Nobody will check whether the device 'NONE' has been configured,
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 8d42ef4823e9..4fda483b8d8d 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -14,7 +14,6 @@
* assembler source.
*/
-#include
#include
/*
diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h
index c7b00be8e0b9..abfa46470b2c 100644
--- a/arch/arm/include/asm/secure.h
+++ b/arch/arm/include/asm/secure.h
@@ -1,7 +1,6 @@
#ifndef __ASM_SECURE_H
#define __ASM_SECURE_H
-#include
#include
#define __secure __section("._secure.text")
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index ead3f2c35643..c9ecdde0d3d8 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -1,8 +1,6 @@
#ifndef __ASM_ARM_STRING_H
#define __ASM_ARM_STRING_H
-#include
-
/*
* We don't do inline string functions, since the
* optimised inline asm versions are not small.
diff --git a/arch/arm/mach-davinci/include/mach/pinmux_defs.h
b/arch/arm/mach-davinci/include/mach/pinmux_defs.h
index 4901ba49c9bb..120935310807 100644
--- a/arch/arm/mach-davinci/include/mach/pinmux_defs.h
+++ b/arch/arm/mach-davinci/include/mach/pinmux_defs.h
@@ -9,7 +9,6 @@
#define __ASM_ARCH_PINMUX_DEFS_H
#include
-#include
/* SPI0 pin muxer settings */
extern const struct pinmux_config spi0_pins_base[3];
diff --git a/arch/arm/mach-exynos/exynos4_setup.h
b/arch/arm/mach-exynos/exynos4_setup.h
index fbb45eb897e3..23c9011fbc63 100644
--- a/arch/arm/mach-exynos/exynos4_setup.h
+++ b/arch/arm/mach-exynos/exynos4_setup.h
@@ -8,7 +8,6 @@
#ifndef _ORIGEN_SETUP_H
#define _ORIGEN_SETUP_H
-#include
#include
/* Bus Configuration Register Address */
diff --git a/arch/arm/mach-exynos/exynos5_setup.h
b/arch/arm/mach-exynos/exynos5_setup.h
index af7a5afb03cd..e9874a8c1b24 100644
--- a/arch/arm/mach-exynos/exynos5_setup.h
+++ b/arch/arm/mach-exynos/exynos5_setup.h
@@ -8,7 +8,6 @@
#ifndef _SMDK5250_SETUP_H
#define _SMDK5250_SETUP_H
-#include
#include
#define NOT_AVAILABLE 0
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index eff2fff3c706..2bbdd1077652 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -6,6 +6,7 @@
* Lokesh Vutla
*/
+#include
#include
#include
#include
diff --git a/arch/arm/mach-k3/include/mach/clock.h
b/arch/arm/mach-k3/include/mach/clock.h
index e3adbcd9dedc..850067d5afac 100644
--- a/arch/arm/mach-k3/include/mach/clock.h
+++ b/arch/arm/mach-k3/include/mach/clock.h
@@ -7,8 +7,6 @@
#ifndef __ASM_ARCH_CLOCK_H
#define __ASM_ARCH_CLOCK_H
-#include
-
/* Clock
[PATCH 1/5] qe: Add to linux/immap_qe.h
Given how we define QE_MURAM_SIZE today, this header needs to have added to it. Signed-off-by: Tom Rini --- include/linux/immap_qe.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/immap_qe.h b/include/linux/immap_qe.h index 45307f51c103..a692f5dfb373 100644 --- a/include/linux/immap_qe.h +++ b/include/linux/immap_qe.h @@ -11,6 +11,8 @@ #ifndef __IMMAP_QE_H__ #define __IMMAP_QE_H__ +#include + #ifdef CONFIG_MPC83xx #if defined(CONFIG_ARCH_MPC8360) #define QE_MURAM_SIZE 0xc000UL -- 2.34.1
[PATCH 2/5] arc: Cleanup and audit usage of
We need to include directly when a file needs to have
something such as CFG_SYS_SDRAM_SIZE referenced as this file is not
automatically globally included and is most commonly indirectly included
via common.h. Remove most cases of arc including config.h directly, but
add it where needed. Further clean up the tb100 board config.h file so
that we don't rely on config.h being included there for a value used in
a single place.
Signed-off-by: Tom Rini
---
Cc: Alexey Brodkin
Cc: Eugeniy Paltsev
Cc: uboot-snps-...@synopsys.com
---
arch/arc/include/asm/arc-bcr.h | 2 --
arch/arc/include/asm/arcregs.h | 1 -
arch/arc/include/asm/cache.h | 2 --
arch/arc/lib/cpu.c | 1 +
board/abilis/tb100/tb100.c | 4
include/configs/tb100.h| 21 -
6 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arc/include/asm/arc-bcr.h b/arch/arc/include/asm/arc-bcr.h
index 823906d946e4..a6c972bf1e31 100644
--- a/arch/arc/include/asm/arc-bcr.h
+++ b/arch/arc/include/asm/arc-bcr.h
@@ -13,8 +13,6 @@
#define __ARC_BCR_H
#ifndef __ASSEMBLY__
-#include
-
union bcr_di_cache {
struct {
#ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index a9f54f61e0cc..273fb8eed859 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -7,7 +7,6 @@
#define _ASM_ARC_ARCREGS_H
#include
-#include
/*
* ARC architecture has additional address space - auxiliary registers.
diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
index 74cff716ef60..65dff4214830 100644
--- a/arch/arc/include/asm/cache.h
+++ b/arch/arc/include/asm/cache.h
@@ -6,8 +6,6 @@
#ifndef __ASM_ARC_CACHE_H
#define __ASM_ARC_CACHE_H
-#include
-
/*
* As of today we may handle any L1 cache line length right in software.
* For that essentially cache line length is a variable not constant.
diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
index 803dfd425580..593950449f2e 100644
--- a/arch/arc/lib/cpu.c
+++ b/arch/arc/lib/cpu.c
@@ -3,6 +3,7 @@
* Copyright (C) 2013-2014, 2018 Synopsys, Inc. All rights reserved.
*/
+#include
#include
#include
#include
diff --git a/board/abilis/tb100/tb100.c b/board/abilis/tb100/tb100.c
index 3dc9e14ef8c0..eb7d12908134 100644
--- a/board/abilis/tb100/tb100.c
+++ b/board/abilis/tb100/tb100.c
@@ -14,6 +14,10 @@ void reset_cpu(void)
writel(0x1, (void *)CRM_SWRESET);
}
+/*
+ * Ethernet configuration
+ */
+#define ETH0_BASE_ADDRESS 0xFE10
int board_eth_init(struct bd_info *bis)
{
if (designware_initialize(ETH0_BASE_ADDRESS, 0) >= 0)
diff --git a/include/configs/tb100.h b/include/configs/tb100.h
index 1318f5e5ee44..08b6f3219c33 100644
--- a/include/configs/tb100.h
+++ b/include/configs/tb100.h
@@ -21,25 +21,4 @@
*/
#define CFG_SYS_NS16550_CLK1
-/*
- * Even though the board houses Realtek RTL8211E PHY
- * corresponding PHY driver (drivers/net/phy/realtek.c) behaves unexpectedly.
- * In particular "parse_status" reports link is down.
- *
- * Until Realtek PHY driver is fixed fall back to generic PHY driver
- * which implements all required functionality and behaves much more stable.
- *
- *
- */
-
-/*
- * Ethernet configuration
- */
-#define ETH0_BASE_ADDRESS 0xFE10
-#define ETH1_BASE_ADDRESS 0xFE11
-
-/*
- * Console configuration
- */
-
#endif /* _CONFIG_TB100_H_ */
--
2.34.1
[PATCH 2/2] doc: Update board_best_practices.rst to talk about dts files
We do need to list device tree overlay files in a Makefile, to ensure they are built. However, everything else should be handled via one of the CONFIG options. Signed-off-by: Tom Rini --- doc/develop/board_best_practices.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst index f44401eab7d4..a5930be10f78 100644 --- a/doc/develop/board_best_practices.rst +++ b/doc/develop/board_best_practices.rst @@ -24,3 +24,7 @@ which are specific to creating a new board port. Kconfig fragments should reside in the board directory itself rather than in the top-level `configs/` directory. + +* A board may list device tree overlay files in `arch/$(ARCH)/dts/Makfile` but + all device trees themselves should be listed in `CONFIG_DEFAULT_DEVICE_TREE` + or `CONFIG_OF_LIST`. -- 2.34.1
[PATCH 1/2] global: Clean up arch/*/dts/Makefile
With commit 3609e1dc ("dts: automatically build necessary .dtb files")
we now have logic that will ensure that all device trees needed in the
binary are built automatically. Any device tree that the developer needs
while working can still be built normally via make arch/.../foo.dtb so
we can simply drop the rest of this logic.
Suggested-by: Rasmus Villemoes
Signed-off-by: Tom Rini
---
arch/arc/dts/Makefile|8 -
arch/arm/dts/Makefile| 1436 +-
arch/m68k/dts/Makefile | 18 -
arch/microblaze/dts/Makefile |2 -
arch/mips/dts/Makefile | 37 -
arch/nios2/dts/Makefile |2 -
arch/powerpc/dts/Makefile| 32 -
arch/riscv/dts/Makefile |9 -
arch/sandbox/dts/Makefile|5 -
arch/sh/dts/Makefile |2 +-
arch/x86/dts/Makefile| 22 -
arch/xtensa/dts/Makefile |2 -
configs/iot2050_defconfig|1 +
13 files changed, 6 insertions(+), 1570 deletions(-)
diff --git a/arch/arc/dts/Makefile b/arch/arc/dts/Makefile
index 532a8131c599..a71db58d48a9 100644
--- a/arch/arc/dts/Makefile
+++ b/arch/arc/dts/Makefile
@@ -1,13 +1,5 @@
# SPDX-License-Identifier: GPL-2.0+
-dtb-$(CONFIG_TARGET_AXS101) += axs101.dtb
-dtb-$(CONFIG_TARGET_AXS103) += axs103.dtb
-dtb-$(CONFIG_TARGET_NSIM) += nsim.dtb
-dtb-$(CONFIG_TARGET_TB100) += abilis_tb100.dtb
-dtb-$(CONFIG_TARGET_EMSDP) += emsdp.dtb
-dtb-$(CONFIG_TARGET_HSDK) += hsdk.dtb hsdk-4xd.dtb
-dtb-$(CONFIG_TARGET_IOT_DEVKIT) += iot_devkit.dtb
-
include $(srctree)/scripts/Makefile.dts
targets += $(dtb-y)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e0a0d430dab8..a8eb6a156eb1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,424 +1,11 @@
# SPDX-License-Identifier: GPL-2.0+
-dtb-$(CONFIG_TARGET_SMARTWEB) += at91sam9260-smartweb.dtb
-dtb-$(CONFIG_TARGET_TAURUS) += at91sam9g20-taurus.dtb
-dtb-$(CONFIG_TARGET_CORVUS) += at91sam9g45-corvus.dtb
-dtb-$(CONFIG_TARGET_GURNARD) += at91sam9g45-gurnard.dtb
-
-dtb-$(CONFIG_TARGET_SMDKC100) += s5pc1xx-smdkc100.dtb
-dtb-$(CONFIG_TARGET_S5P_GONI) += s5pc1xx-goni.dtb
-dtb-$(CONFIG_ARCH_EXYNOS4) += exynos4210-origen.dtb \
- exynos4210-smdkv310.dtb \
- exynos4210-universal_c210.dtb \
- exynos4210-trats.dtb \
- exynos4412-trats2.dtb \
- exynos4412-odroid.dtb
-
-dtb-$(CONFIG_TARGET_HIKEY) += hi6220-hikey.dtb
-dtb-$(CONFIG_TARGET_HIKEY960) += hi3660-hikey960.dtb
-
-dtb-$(CONFIG_TARGET_POPLAR) += hi3798cv200-poplar.dtb
-
-dtb-$(CONFIG_ARCH_EXYNOS5) += exynos5250-arndale.dtb \
- exynos5250-snow.dtb \
- exynos5250-spring.dtb \
- exynos5250-smdk5250.dtb \
- exynos5420-smdk5420.dtb \
- exynos5420-peach-pit.dtb \
- exynos5800-peach-pi.dtb \
- exynos5422-odroidxu3.dtb
-dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
-dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
-dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
-dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
-
-dtb-$(CONFIG_ARCH_APPLE) += \
- t8103-j274.dtb \
- t8103-j293.dtb \
- t8103-j313.dtb \
- t8103-j456.dtb \
- t8103-j457.dtb
-
-dtb-$(CONFIG_ARCH_DAVINCI) += \
- da850-evm.dtb \
- da850-lcdk.dtb \
- da850-lego-ev3.dtb
-
-dtb-$(CONFIG_ARCH_KIRKWOOD) += \
- kirkwood-atl-sbx81lifkw.dtb \
- kirkwood-atl-sbx81lifxcat.dtb \
- kirkwood-blackarmor-nas220.dtb \
- kirkwood-d2net.dtb \
- kirkwood-dns325.dtb \
- kirkwood-dockstar.dtb \
- kirkwood-dreamplug.dtb \
- kirkwood-ds109.dtb \
- kirkwood-goflexnet.dtb \
- kirkwood-guruplug-server-plus.dtb \
- kirkwood-ib62x0.dtb \
- kirkwood-iconnect.dtb \
- kirkwood-is2.dtb \
- kirkwood-lsxhl.dtb \
- kirkwood-lschlv2.dtb \
- kirkwood-net2big.dtb \
- kirkwood-ns2.dtb \
- kirkwood-ns2lite.dtb \
- kirkwood-ns2max.dtb \
- kirkwood-ns2mini.dtb \
- kirkwood-nsa310s.dtb \
- kirkwood-nsa325.dtb \
- kirkwood-openrd-base.dtb \
- kirkwood-openrd-client.dtb \
- kirkwood-openrd-ultimate.dtb \
- kirkwood-pogo_e02.dtb \
- kirkwood-pogoplug-series-4.dtb \
- kirkwood-sheevaplug.dtb
-
-dtb-$(CONFIG_MACH_S900) += \
- bubblegum_96.dtb
-dtb-$(CONFIG_MACH_S700) += \
- s700-cubieboard7.dtb
-
-dtb-$(CONFIG_ROCKCHIP_PX30) += \
- px30-evb.dtb \
- px30-firefly.dtb \
- px30-engicam-px30-core-ctouch2.dtb \
- px30-engicam-px30-core-ctouch2-of10.dtb \
- px30-engicam-px30-core-edimm2.2.dtb \
- rk3326-odroid-go2.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK3036) += \
- rk3036-sdk.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK3066) += \
- rk3066a-mk808.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK3128) += \
- rk3128-evb.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK3188) += \
- rk3188-radxarock.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK322X) += \
- rk3229-evb.dtb
-
-dtb-$(CONFIG_ROCKCHIP_RK3288) += \
-
Re: [PATCH 2/3] configs: keystone2: Do not include hardware.h
On Fri, Nov 17, 2023 at 04:38:28PM -0600, Andrew Davis wrote: > This is a hacky way to have this file included in all source files that > include common.h, instead just include from the files that need it. > > Signed-off-by: Andrew Davis > --- > drivers/memory/ti-aemif.c| 1 + > drivers/soc/ti/keystone_serdes.c | 1 + > include/configs/ti_armv7_keystone2.h | 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c > index c4bc88c1510..41325eb0f94 100644 > --- a/drivers/memory/ti-aemif.c > +++ b/drivers/memory/ti-aemif.c > @@ -7,6 +7,7 @@ > */ > > #include > +#include > #include > > #define AEMIF_WAITCYCLE_CONFIG (KS2_AEMIF_CNTRL_BASE + 0x4) > diff --git a/drivers/soc/ti/keystone_serdes.c > b/drivers/soc/ti/keystone_serdes.c > index 2ece1a8f647..0e1bf8ff39d 100644 > --- a/drivers/soc/ti/keystone_serdes.c > +++ b/drivers/soc/ti/keystone_serdes.c > @@ -8,6 +8,7 @@ > > #include > #include > +#include > #include > #include > Is there going to be a follow-up to remove common.h from these files then? Thanks. -- Tom signature.asc Description: PGP signature
[PATCH 3/3] ARM: keystone2: Remove unneeded inclusions of common.h
Signed-off-by: Andrew Davis
---
arch/arm/mach-keystone/clock.c| 1 -
arch/arm/mach-keystone/cmd_clock.c| 2 +-
arch/arm/mach-keystone/cmd_mon.c | 1 -
arch/arm/mach-keystone/cmd_poweroff.c | 1 -
arch/arm/mach-keystone/ddr3.c | 2 +-
arch/arm/mach-keystone/ddr3_spd.c | 2 +-
arch/arm/mach-keystone/include/mach/mux-k2g.h | 1 -
arch/arm/mach-keystone/init.c | 1 -
arch/arm/mach-keystone/keystone.c | 1 -
arch/arm/mach-keystone/mon.c | 1 -
arch/arm/mach-keystone/msmc.c | 1 -
arch/arm/mach-keystone/psc.c | 1 -
12 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-keystone/clock.c b/arch/arm/mach-keystone/clock.c
index 0c59515d2eb..4f193794efb 100644
--- a/arch/arm/mach-keystone/clock.c
+++ b/arch/arm/mach-keystone/clock.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/cmd_clock.c
b/arch/arm/mach-keystone/cmd_clock.c
index 72dc394df5f..e9ecc05953a 100644
--- a/arch/arm/mach-keystone/cmd_clock.c
+++ b/arch/arm/mach-keystone/cmd_clock.c
@@ -6,7 +6,7 @@
* Texas Instruments Incorporated,
*/
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/cmd_mon.c b/arch/arm/mach-keystone/cmd_mon.c
index dc97bac8550..c6e7e2c3097 100644
--- a/arch/arm/mach-keystone/cmd_mon.c
+++ b/arch/arm/mach-keystone/cmd_mon.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/cmd_poweroff.c
b/arch/arm/mach-keystone/cmd_poweroff.c
index f0ad9173b96..0ad31ef4e28 100644
--- a/arch/arm/mach-keystone/cmd_poweroff.c
+++ b/arch/arm/mach-keystone/cmd_poweroff.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c
index ea7d0b903cf..ca0fb702d54 100644
--- a/arch/arm/mach-keystone/ddr3.c
+++ b/arch/arm/mach-keystone/ddr3.c
@@ -9,7 +9,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/ddr3_spd.c
b/arch/arm/mach-keystone/ddr3_spd.c
index 6f7f8ab7b40..d4ff442175b 100644
--- a/arch/arm/mach-keystone/ddr3_spd.c
+++ b/arch/arm/mach-keystone/ddr3_spd.c
@@ -5,8 +5,8 @@
* (C) Copyright 2015-2016 Texas Instruments Incorporated,
*/
-#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-keystone/include/mach/mux-k2g.h
b/arch/arm/mach-keystone/include/mach/mux-k2g.h
index 67d47f81721..dfb5ad43506 100644
--- a/arch/arm/mach-keystone/include/mach/mux-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/mux-k2g.h
@@ -9,7 +9,6 @@
#ifndef __ASM_ARCH_MUX_K2G_H
#define __ASM_ARCH_MUX_K2G_H
-#include
#include
#define K2G_PADCFG_REG (KS2_DEVICE_STATE_CTRL_BASE + 0x1000)
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 1954e69e9f0..39afaaa63d6 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index efaabca5a7e..8846df3af48 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
index e91b0d68f4d..b945e19ec77 100644
--- a/arch/arm/mach-keystone/mon.c
+++ b/arch/arm/mach-keystone/mon.c
@@ -8,7 +8,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-keystone/msmc.c b/arch/arm/mach-keystone/msmc.c
index f5cadfbf669..a20e0c98865 100644
--- a/arch/arm/mach-keystone/msmc.c
+++ b/arch/arm/mach-keystone/msmc.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
struct mpax {
diff --git a/arch/arm/mach-keystone/psc.c b/arch/arm/mach-keystone/psc.c
index 145aff8ac66..84d64f3bc40 100644
--- a/arch/arm/mach-keystone/psc.c
+++ b/arch/arm/mach-keystone/psc.c
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
--
2.39.2
[PATCH 2/3] configs: keystone2: Do not include hardware.h
This is a hacky way to have this file included in all source files that include common.h, instead just include from the files that need it. Signed-off-by: Andrew Davis --- drivers/memory/ti-aemif.c| 1 + drivers/soc/ti/keystone_serdes.c | 1 + include/configs/ti_armv7_keystone2.h | 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c index c4bc88c1510..41325eb0f94 100644 --- a/drivers/memory/ti-aemif.c +++ b/drivers/memory/ti-aemif.c @@ -7,6 +7,7 @@ */ #include +#include #include #define AEMIF_WAITCYCLE_CONFIG (KS2_AEMIF_CNTRL_BASE + 0x4) diff --git a/drivers/soc/ti/keystone_serdes.c b/drivers/soc/ti/keystone_serdes.c index 2ece1a8f647..0e1bf8ff39d 100644 --- a/drivers/soc/ti/keystone_serdes.c +++ b/drivers/soc/ti/keystone_serdes.c @@ -8,6 +8,7 @@ #include #include +#include #include #include diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 637e9e4369e..b36207cb5d1 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -52,7 +52,6 @@ #include /* we may include files below only after all above definitions */ -#include #include #ifndef CONFIG_SOC_K2G #define CFG_SYS_HZ_CLOCK ks_clk_get_rate(KS2_CLK1_6) -- 2.39.2
[PATCH 1/3] configs: keystone2: Remove unused SPL_MALLOC_F_SIZE and KEYSTONE_SPL_STACK_SIZE
These are leftover definitions. While here cleanup some leftover comments.
Signed-off-by: Andrew Davis
---
include/configs/ti_armv7_keystone2.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/include/configs/ti_armv7_keystone2.h
b/include/configs/ti_armv7_keystone2.h
index 72c04d8a994..637e9e4369e 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -9,23 +9,10 @@
#ifndef __CONFIG_KS2_EVM_H
#define __CONFIG_KS2_EVM_H
-/* U-Boot Build Configuration */
-
-/* SoC Configuration */
-
/* Memory Configuration */
#define CFG_SYS_LPAE_SDRAM_BASE0x8
#define CFG_MAX_RAM_BANK_SIZE (2 << 30) /* 2GB */
-#ifdef CONFIG_SYS_MALLOC_F_LEN
-#define SPL_MALLOC_F_SIZE CONFIG_SYS_MALLOC_F_LEN
-#else
-#define SPL_MALLOC_F_SIZE 0
-#endif
-
-/* SPL SPI Loader Configuration */
-#define KEYSTONE_SPL_STACK_SIZE(8 * 1024)
-
/* SRAM scratch space entries */
#define SRAM_SCRATCH_SPACE_ADDR0xc0c23fc
@@ -53,8 +40,6 @@
#define CFG_KSNET_SERDES_SGMII2_BASE KS2_SGMII_SERDES2_BASE
#define CFG_KSNET_SERDES_LANES_PER_SGMII KS2_LANES_PER_SGMII_SERDES
-/* EEPROM definitions */
-
/* NAND Configuration */
#define CFG_SYS_NAND_MASK_CLE 0x4000
#define CFG_SYS_NAND_MASK_ALE 0x2000
@@ -63,13 +48,6 @@
#define CFG_SYS_NAND_LARGEPAGE
#define CFG_SYS_NAND_BASE_LIST { 0x3000, }
-
-
-/* U-Boot general configuration */
-
-/* EDMA3 */
-
-
/* Now for the remaining common defines */
#include
--
2.39.2
Re: [PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements
On Fri, Nov 17, 2023 at 01:49:22PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > In our datacenter application, a single DHCP server is servicing 36000+ > clients. > Improvements are required to the DHCPv4 retransmission behavior to align with > RFC and ensure less pressure is exerted on the server: > - retransmission backoff interval maximum is configurable > (environment variable bootpretransmitperiodmax) > - initial retransmission backoff interval is configurable > (environment variable bootpretransmitperiodinit) > - transaction ID is kept the same for each BOOTP/DHCPv4 request > (not recreated on each retry) > > For our application we'll use: > - bootpretransmitperiodmax=16000 > - bootpretransmitperiodinit=2000 > > A new configuration BOOTP_RANDOM_XID has been added to enable a randomized > BOOTP/DHCPv4 transaction ID. > > Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous > patch was accepted. A new patch fixes a possible double free() and > addresses latest review comments. The changes from revision to revision should be below the "---" in a commit and not the commit message itself. Please reword things for v5. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID
On Fri, Nov 17, 2023 at 01:49:25PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > The new config option BOOTP_RANDOM_XID will randomize the transaction ID > for each new BOOT/DHCPv4 exchange. > > Signed-off-by: Sean Edmond > --- > cmd/Kconfig | 7 +++ > net/bootp.c | 31 +-- > 2 files changed, 24 insertions(+), 14 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 93bf752035c..244237e6d60 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1853,6 +1853,13 @@ config BOOTP_VCI_STRING > default "U-Boot.arm" if ARM > default "U-Boot" > > +config BOOTP_RANDOM_XID > + bool "Send random transaction ID to BOOTP/DHCP server" > + depends on CMD_BOOTP && (LIB_RAND || EXYNOS_ACE_SHA || RNG_NPCM) This should be (LIB_RAND || LIB_HW_RAND) -- Tom signature.asc Description: PGP signature
[PATCH v4 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements
From: Sean Edmond
This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request
In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.
RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds. This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"
The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients. This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".
Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.
Signed-off-by: Sean Edmond
---
cmd/Kconfig | 2 +-
net/bootp.c | 71 +
2 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ae846b204dc..93bf752035c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1717,6 +1717,7 @@ if CMD_NET
config CMD_BOOTP
bool "bootp"
default y
+ select LIB_RAND
help
bootp - boot image via network using BOOTP/TFTP protocol
@@ -1725,7 +1726,6 @@ config CMD_DHCP
depends on CMD_BOOTP
help
Boot image via network using DHCP/TFTP protocol
-
config CMD_DHCP6
bool "dhcp6"
depends on IPV6
diff --git a/net/bootp.c b/net/bootp.c
index 24547cf7bfd..89425717328 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -42,6 +42,22 @@
*/
#define TIMEOUT_MS ((3 + (CONFIG_NET_RETRY_COUNT * 5)) * 1000)
+/*
+ * According to rfc951 : 7.2. Client Retransmission Strategy
+ * "After the 'average' backoff reaches about 60 seconds, it should be
+ * increased no further, but still randomized."
+ *
+ * U-Boot has saturated this backoff at 2 seconds for a long time.
+ * To modify, set the environment variable "bootpretransmitperiodmax"
+ */
+#define RETRANSMIT_PERIOD_MAX_MS 6
+
+/* Retransmission timeout for the initial packet (in milliseconds).
+ * This timeout will double on each retry. To modify, set the
+ * environment variable bootpretransmitperiodinit.
+ */
+#define RETRANSMIT_PERIOD_INIT_MS 250
+
#ifndef CFG_DHCP_MIN_EXT_LEN /* minimal length of extension list */
#define CFG_DHCP_MIN_EXT_LEN 64
#endif
@@ -53,6 +69,7 @@
u32bootp_ids[CFG_BOOTP_ID_CACHE_SIZE];
unsigned int bootp_num_ids;
intbootp_try;
+u32bootp_id;
ulong bootp_start;
ulong bootp_timeout;
char net_nis_domain[32] = {0,}; /* Our NIS domain */
@@ -60,6 +77,7 @@ char net_hostname[32] = {0,}; /* Our hostname */
char net_root_path[CONFIG_BOOTP_MAX_ROOT_PATH_LEN] = {0,}; /* Our bootpath */
static ulong time_taken_max;
+static u32 retransmit_period_max_ms;
#if defined(CONFIG_CMD_DHCP)
static dhcp_state_t dhcp_state = INIT;
@@ -396,6 +414,7 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct
in_addr sip,
static void bootp_timeout_handler(void)
{
ulong time_taken = get_timer(bootp_start);
+ int rand_minus_plus_100;
if (time_taken >= time_taken_max) {
#ifdef CONFIG_BOOTP_MAY_FAIL
@@ -414,8 +433,17 @@ static void bootp_timeout_handler(void)
}
} else {
bootp_timeout *= 2;
- if (bootp_timeout > 2000)
- bootp_timeout = 2000;
+ if (bootp_timeout > retransmit_period_max_ms)
+ bootp_timeout = retransmit_period_max_ms;
+
+ /* Randomize by adding bootp_timeout*RAND, where RAND
+* is a randomization factor between -0.1..+0.1
+*/
+ srand(get_ticks() + rand());
+ rand_minus_plus_100 = ((rand() % 200) - 100);
+ bootp_timeout = bootp_timeout +
+ (((int)bootp_timeout * rand_minus_plus_100) /
1000);
+
net_set_timeout_handler(bootp_timeout, bootp_timeout_handler);
bootp_request();
}
@@ -711,10 +739,14 @@ static int bootp_extended(u8 *e)
void bootp_reset(void)
{
+ char *ep; /* Environment pointer */
+
bootp_num_ids = 0;
bootp_try = 0;
bootp_start = get_timer(0);
- bootp_timeout = 250;
+
+ bootp_timeout = env_get_ulong("bootpretransmitperiodinit", 10,
RETRANSMIT_PERIOD_INIT_MS);
+
}
void bootp_request(void)
@@ -726,7 +758,6 @@ void bootp_request(void)
#ifdef
[PATCH v4 1/3] net: Additional fixes for dhcp option 209
From: Sean Edmond
Addresses feedback from latest review:
- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoced 209 to a define
Signed-off-by: Sean Edmond
---
cmd/Kconfig | 1 +
cmd/pxe.c | 2 ++
net/bootp.c | 4 ++--
net/bootp.h | 2 ++
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index df6d71c103f..ae846b204dc 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1842,6 +1842,7 @@ config BOOTP_PXE_CLIENTARCH
config BOOTP_PXE_DHCP_OPTION
bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
+ default y
depends on BOOTP_PXE
config BOOTP_VCI_STRING
diff --git a/cmd/pxe.c b/cmd/pxe.c
index 21134eb7a30..9404f445187 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -65,6 +65,8 @@ static int pxe_dhcp_option_path(struct pxe_context *ctx,
unsigned long pxefile_a
int ret = get_pxe_file(ctx, pxelinux_configfile, pxefile_addr_r);
free(pxelinux_configfile);
+ /* set to NULL to avoid double-free if DHCP is tried again */
+ pxelinux_configfile = NULL;
return ret;
}
diff --git a/net/bootp.c b/net/bootp.c
index 68002909634..24547cf7bfd 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -603,7 +603,7 @@ static int dhcp_extended(u8 *e, int message_type, struct
in_addr server_ip,
*cnt += 1;
#endif
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
- *e++ = 209; /* PXELINUX Config File */
+ *e++ = DHCP_OPTION_PXE_CONFIG_FILE; /* PXELINUX Config File
*/
*cnt += 1;
}
/* no options, so back up to avoid sending an empty request list */
@@ -914,7 +914,7 @@ static void dhcp_process_options(uchar *popt, uchar *end)
net_boot_file_name[size] = 0;
}
break;
- case 209: /* PXELINUX Config File */
+ case DHCP_OPTION_PXE_CONFIG_FILE: /* PXELINUX Config File
*/
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
/* In case it has already been allocated when
get DHCP Offer packet,
* free first to avoid memory leak.
diff --git a/net/bootp.h b/net/bootp.h
index 4e32b19d424..24b32c73f62 100644
--- a/net/bootp.h
+++ b/net/bootp.h
@@ -91,6 +91,8 @@ typedef enum { INIT,
#define DHCP_NAK 6
#define DHCP_RELEASE 7
+#define DHCP_OPTION_PXE_CONFIG_FILE209 /* "ConfigFile" option
according to rfc5071 */
+
/**/
#endif /* __BOOTP_H__ */
--
2.42.0
[PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements
From: Sean Edmond In our datacenter application, a single DHCP server is servicing 36000+ clients. Improvements are required to the DHCPv4 retransmission behavior to align with RFC and ensure less pressure is exerted on the server: - retransmission backoff interval maximum is configurable (environment variable bootpretransmitperiodmax) - initial retransmission backoff interval is configurable (environment variable bootpretransmitperiodinit) - transaction ID is kept the same for each BOOTP/DHCPv4 request (not recreated on each retry) For our application we'll use: - bootpretransmitperiodmax=16000 - bootpretransmitperiodinit=2000 A new configuration BOOTP_RANDOM_XID has been added to enable a randomized BOOTP/DHCPv4 transaction ID. Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous patch was accepted. A new patch fixes a possible double free() and addresses latest review comments. changes in v4: - rebase master and resolve conflicts - change commit description for DHCP option 209 patch (this is now an enhancement patch) - default y for BOOTP_PXE_DHCP_OPTION (feedback from review) - Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission improvements require rand()) changes in v3: - add define for option 209 and rfc5071 reference - Set RETRANSMIT_PERIOD_MAX_MS=6 - Add randomization factor to retransmission timeout - Add depends for BOOTP_RANDOM_XID changes in v2: - use env_get_ulong() to get environment variables Sean Edmond (3): net: Additional fixes for dhcp option 209 net: bootp: BOOTP/DHCPv4 retransmission improvements net: bootp: add config option BOOTP_RANDOM_XID cmd/Kconfig | 10 ++- cmd/pxe.c | 2 ++ net/bootp.c | 76 + net/bootp.h | 2 ++ 4 files changed, 72 insertions(+), 18 deletions(-) -- 2.42.0
[PATCH v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID
From: Sean Edmond
The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.
Signed-off-by: Sean Edmond
---
cmd/Kconfig | 7 +++
net/bootp.c | 31 +--
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 93bf752035c..244237e6d60 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1853,6 +1853,13 @@ config BOOTP_VCI_STRING
default "U-Boot.arm" if ARM
default "U-Boot"
+config BOOTP_RANDOM_XID
+ bool "Send random transaction ID to BOOTP/DHCP server"
+ depends on CMD_BOOTP && (LIB_RAND || EXYNOS_ACE_SHA || RNG_NPCM)
+ help
+ Selecting this will allow for a random transaction ID to get
+ selected for each BOOTP/DHCPv4 exchange.
+
if CMD_DHCP6
config DHCP6_PXE_CLIENTARCH
diff --git a/net/bootp.c b/net/bootp.c
index 89425717328..49cd9064436 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -837,22 +837,25 @@ void bootp_request(void)
/* Only generate a new transaction ID for each new BOOTP request */
if (bootp_try == 1) {
- /*
-* Bootp ID is the lower 4 bytes of our ethernet address
-* plus the current time in ms.
-*/
- bootp_id = ((u32)net_ethaddr[2] << 24)
- | ((u32)net_ethaddr[3] << 16)
- | ((u32)net_ethaddr[4] << 8)
- | (u32)net_ethaddr[5];
- bootp_id += get_timer(0);
- bootp_id = htonl(bootp_id);
- bootp_add_id(bootp_id);
- net_copy_u32(>bp_id, _id);
- } else {
- net_copy_u32(>bp_id, _id);
+ if (IS_ENABLED(CONFIG_BOOTP_RANDOM_XID)) {
+ srand(get_ticks() + rand());
+ bootp_id = rand();
+ } else {
+ /*
+* Bootp ID is the lower 4 bytes of our ethernet
address
+* plus the current time in ms.
+*/
+ bootp_id = ((u32)net_ethaddr[2] << 24)
+ | ((u32)net_ethaddr[3] << 16)
+ | ((u32)net_ethaddr[4] << 8)
+ | (u32)net_ethaddr[5];
+ bootp_id += get_timer(0);
+ bootp_id = htonl(bootp_id);
+ }
}
+ bootp_add_id(bootp_id);
+ net_copy_u32(>bp_id, _id);
/*
* Calculate proper packet lengths taking into account the
* variable size of the options field
--
2.42.0
[PATCH v2 4/4] bootflow: bootmeth_efi: don't free buffer
bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.
Signed-off-by: Shantur Rathore
---
boot/bootmeth_efi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 5e67afed88..045e9ac543 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -160,7 +160,6 @@ static int efiload_read_file(struct bootflow *bflow, ulong
addr)
if (ret)
return log_msg_ret("read", ret);
bflow->buf = map_sysmem(addr, bflow->size);
- bflow->flags |= BOOTFLOWF_STATIC_BUF;
set_efi_bootdev(desc, bflow);
@@ -395,6 +394,12 @@ static int distro_efi_read_bootflow(struct udevice *dev,
struct bootflow *bflow)
{
int ret;
+ /*
+* bootmeth_efi doesn't allocate any buffer neither for bulk nor net
device
+* set flag to avoid freeing static buffer.
+*/
+ bflow->flags |= BOOTFLOWF_STATIC_BUF;
+
if (bootmeth_uses_network(bflow)) {
/* we only support reading from one device, so ignore 'dev' */
ret = distro_efi_read_bootflow_net(bflow);
--
2.40.1
[PATCH v2 3/4] bootflow: bootmeth_efi: Handle fdt not available.
While booting with efi, if fdt isn't available externally,
just use the built-in one.
Signed-off-by: Shantur Rathore
---
boot/bootmeth_efi.c | 10 +-
include/bootflow.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 5917458dc5..5e67afed88 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -313,6 +313,7 @@ static int distro_efi_try_bootflow_files(struct udevice
*dev,
*/
} else {
log_debug("No device tree available\n");
+ bflow->flags |= BOOTFLOWF_USE_BUILTIN_FDT;
}
return 0;
@@ -382,6 +383,7 @@ static int distro_efi_read_bootflow_net(struct bootflow
*bflow)
bflow->fdt_addr = fdt_addr;
} else {
log_debug("No device tree available\n");
+ bflow->flags |= BOOTFLOWF_USE_BUILTIN_FDT;
}
bflow->state = BOOTFLOWST_READY;
@@ -443,7 +445,13 @@ static int distro_efi_boot(struct udevice *dev, struct
bootflow *bflow)
* At some point we can add a real interface to bootefi so we can call
* this directly. For now, go through the CLI, like distro boot.
*/
- snprintf(cmd, sizeof(cmd), "bootefi %lx %lx", kernel, fdt);
+ if (bflow->flags & BOOTFLOWF_USE_BUILTIN_FDT) {
+ log_debug("Booting with built-in fdt\n");
+ snprintf(cmd, sizeof(cmd), "bootefi %lx", kernel);
+ } else {
+ snprintf(cmd, sizeof(cmd), "bootefi %lx %lx", kernel, fdt);
+ }
+
if (run_command(cmd, 0))
return log_msg_ret("run", -EINVAL);
diff --git a/include/bootflow.h b/include/bootflow.h
index fede8f22a2..3890cd4bc2 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -49,6 +49,7 @@ enum bootflow_state_t {
enum bootflow_flags_t {
BOOTFLOWF_USE_PRIOR_FDT = 1 << 0,
BOOTFLOWF_STATIC_BUF= 1 << 1,
+ BOOTFLOWF_USE_BUILTIN_FDT = 1 << 2,
};
/**
--
2.40.1
[PATCH v2 2/4] bootflow: bootmeth_efi: Don't set bootdev again
efi_set_bootdev is already called as part of tftp while doing dhcp_run()
Doing this again crashes U-boot and we don't need to call again.
Signed-off-by: Shantur Rathore
---
boot/bootmeth_efi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 682cf5b23b..5917458dc5 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -360,9 +360,6 @@ static int distro_efi_read_bootflow_net(struct bootflow
*bflow)
return log_msg_ret("sz", -EINVAL);
bflow->size = size;
- /* do the hideous EFI hack */
- efi_set_bootdev("Net", "", bflow->fname, map_sysmem(addr, 0),
- bflow->size);
/* read the DT file also */
fdt_addr_str = env_get("fdt_addr_r");
--
2.40.1
[PATCH v2 1/4] bootflow: bootmeth_efi: Set bootp_arch as hex
bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.
For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.
Setting it as hex string fixes the problem.
Signed-off-by: Shantur Rathore
---
boot/bootmeth_efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 9ba7734911..682cf5b23b 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -339,7 +339,7 @@ static int distro_efi_read_bootflow_net(struct bootflow
*bflow)
ret = env_set("bootp_vci", str);
if (ret)
return log_msg_ret("vcs", ret);
- ret = env_set_ulong("bootp_arch", arch);
+ ret = env_set_hex("bootp_arch", arch);
if (ret)
return log_msg_ret("ars", ret);
--
2.40.1
[PATCH v2 0/4] bootflow: bootmeth_efi: Fix network eif boot.
Currently bootmeth_efi crashes while doing a network (dhcp) boot. This patch series fixes issues and both network and disk boot works. Shantur Rathore (4): bootflow: bootmeth_efi: Set bootp_arch as hex bootflow: bootmeth_efi: Don't set bootdev again bootflow: bootmeth_efi: Handle fdt not available. bootflow: bootmeth_efi: don't free buffer boot/bootmeth_efi.c | 22 -- include/bootflow.h | 1 + 2 files changed, 17 insertions(+), 6 deletions(-) -- 2.40.1
[PATCH V2 4/4] doc: board: anbernic: Update rgxx3 to add new boards
From: Chris Morgan Update the RGxx3 documentation to note that it now supports two new non-Anbernic boards. Also update verbiage around panel detection to note that it is no longer hard coded to the RG503. Signed-off-by: Chris Morgan --- doc/board/anbernic/rgxx3.rst | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/doc/board/anbernic/rgxx3.rst b/doc/board/anbernic/rgxx3.rst index 7d1beb423c..89cc4ee560 100644 --- a/doc/board/anbernic/rgxx3.rst +++ b/doc/board/anbernic/rgxx3.rst @@ -12,18 +12,24 @@ This allows U-Boot to boot the following Anbernic devices: - Anbernic RG353VS - Anbernic RG503 +Additionally, the following very similar non-Anbernic devices are also +supported: + + - Powkiddy RGB30 + - Powkiddy RK2023 + The correct device is detected automatically by comparing ADC values from ADC channel 1. In the event of an RG353V or RG353P, an attempt is then made to probe for an eMMC and if it fails the device is assumed to be an RG353VS or RG353PS. Based on the detected device, the environment variables "board", "board_name", and "fdtfile" are set to the correct values corresponding to the board which can be read by a -boot script to boot with the correct device tree. If the board detected -is not of type RG503 (which currently has only 1 panel revision) a -panel detect is then performed by probing a "dummy" display on the DSI -bus and then querying the display ID. The display ID is then compared -to a table to get the known compatible string for use in Linux, and -this string is saved as an environment variable of "panel". +boot script to boot with the correct device tree. If a board is defined +as requiring panel detection, a panel detect is then performed by +probing a "dummy" display on the DSI bus and then querying the display +ID. The display ID is then compared to a table to get the known +compatible string for use in Linux, and this string is saved as an +environment variable of "panel". FDT fixups are performed in the event of an RG353M to change the device name, or in the event the panel detected does not match the devicetree. -- 2.34.1
[PATCH V2 2/4] board: rockchip: Add Recovery Button for Anbernic RGxx3
From: Chris Morgan
Add support for users to enter recovery mode by holding the function
button when they power up the device.
Since the device has soldered eMMC and sometimes does not expose a clk
pin on the mainboard there is a small chance that a user who flashes a
bad bootloader may not be able to recover if the headers themselves
are valid. As a result this check is done during spl_early_init() to
ensure that it runs as early as possible, and it does so by directly
manipulating the ADC hardware in lieu of loading the ADC driver.
Ideally, once we have an open source TPL stage we can move this to
the TPL stage, so it will run even earlier. It may also be possible
to make this code "more portable", but at the tradeoff of requiring
to be run later in the boot process. For now it's done in a board
specific way to err on the side of "do it early".
Signed-off-by: Chris Morgan
---
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3d0c614623..a93b11cd47 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -6,12 +6,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -20,6 +22,8 @@
#include
#include
+#define BOOT_BROM_DOWNLOAD 0xef08a53c
+
#define GPIO0_BASE 0xfdd6
#define GPIO4_BASE 0xfe77
#define GPIO_SWPORT_DR_L 0x
@@ -33,6 +37,14 @@
#define GPIO_WRITEMASK(bits) ((bits) << 16)
+#define SARADC_BASE0xfe72
+#define SARADC_DATA0x
+#define SARADC_STAS0x0004
+#define SARADC_ADC_STATUS BIT(0)
+#define SARADC_CTRL0x0008
+#define SARADC_INPUT_SRC_MSK 0x7
+#define SARADC_POWER_CTRL BIT(3)
+
#define DTB_DIR"rockchip/"
struct rg3xx_model {
@@ -118,12 +130,64 @@ static const struct rg353_panel rg353_panel_details[] = {
},
};
+/*
+ * The device has internal eMMC, and while some devices have an exposed
+ * clk pin you can ground to force a bypass not all devices do. As a
+ * result it may be possible for some devices to become a perma-brick
+ * if a corrupted TPL or SPL stage with a valid header is flashed to
+ * the internal eMMC. Add functionality to read ADC channel 0 (the func
+ * button) as early as possible in the boot process to provide some
+ * protection against this. If we ever get an open TPL stage, we should
+ * consider moving this function there.
+ */
+void read_func_button(void)
+{
+ int ret;
+ u32 reg;
+
+ /* Turn off SARADC to reset it. */
+ writel(0, (SARADC_BASE + SARADC_CTRL));
+
+ /* Enable channel 0 and power on SARADC. */
+ writel(((0 & SARADC_INPUT_SRC_MSK) | SARADC_POWER_CTRL),
+ (SARADC_BASE + SARADC_CTRL));
+
+ /*
+* Wait for data to be ready. Use timeout of 2us from
+* rockchip_saradc driver.
+*/
+ ret = readl_poll_timeout((SARADC_BASE + SARADC_STAS), reg,
+!(reg & SARADC_ADC_STATUS), 2);
+ if (ret) {
+ printf("ADC Timeout");
+ return;
+ }
+
+ /* Read the data from the SARADC. */
+ reg = readl((SARADC_BASE + SARADC_DATA));
+
+ /* Turn the SARADC back off so it's ready to be used again. */
+ writel(0, (SARADC_BASE + SARADC_CTRL));
+
+ /*
+* If the value is less than 30 the button is being pressed.
+* Reset the device back into Rockchip download mode.
+*/
+ if (reg <= 30) {
+ printf("download key pressed, entering download mode...");
+ writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
+ do_reset(NULL, 0, 0, NULL);
+ }
+};
+
/*
* Start LED very early so user knows device is on. Set color
* to red.
*/
void spl_board_init(void)
{
+ read_func_button();
+
/* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */
writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \
(GPIO_C7 | GPIO_C6 | GPIO_C5),
--
2.34.1
[PATCH V2 3/4] board: rockchip: Add support for RGB30 and RK2023 to RGxx3
From: Chris Morgan
Add support for the Powkiddy RK2023 and RGB30 to the Anbernic RGxx3.
While these devices are manufactured by Powkiddy instead of Anbernic,
the hardware is so similar they can all use the same bootloader.
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
---
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 16
1 file changed, 16 insertions(+)
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index a93b11cd47..dae9dc87c2 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -60,6 +60,8 @@ enum rgxx3_device_id {
RG353P,
RG353V,
RG503,
+ RGB30,
+ RK2023,
/* Devices with duplicate ADC value */
RG353PS,
RG353VS,
@@ -95,6 +97,20 @@ static const struct rg3xx_model rg3xx_model_details[] = {
.fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
.detect_panel = 0,
},
+ [RGB30] = {
+ .adc_value = 383, /* Gathered from second hand information */
+ .board = "rk3566-powkiddy-rgb30",
+ .board_name = "RGB30",
+ .fdtfile = DTB_DIR "rk3566-powkiddy-rgb30.dtb",
+ .detect_panel = 0,
+ },
+ [RK2023] = {
+ .adc_value = 635, /* Observed average from device */
+ .board = "rk3566-powkiddy-rk2023",
+ .board_name = "RK2023",
+ .fdtfile = DTB_DIR "rk3566-powkiddy-rk2023.dtb",
+ .detect_panel = 0,
+ },
/* Devices with duplicate ADC value */
[RG353PS] = {
.adc_value = 860, /* Observed average from device */
--
2.34.1
[PATCH V2 0/4] Add Additional Boards and Features to RGxx3
From: Chris Morgan The RGxx3 is a pseudo-device for U-Boot that works for every Anbernic RGxx3 series device on the market. Add support for another series of very similar devices from Powkiddy. Changes since V1: - Update verbiage around function button to say "recovery" mode instead of calling it "maskrom" mode, which has a specific meaning. Also note that recovery function was done in a board specific manner to ensure it can run early. - Update board level documentation for the RGxx3. Chris Morgan (4): board: rockchip: Refactor panel auto-detect code board: rockchip: Add Recovery Button for Anbernic RGxx3 board: rockchip: Add support for RGB30 and RK2023 to RGxx3 doc: board: anbernic: Update rgxx3 to add new boards board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 195 - doc/board/anbernic/rgxx3.rst | 18 +- 2 files changed, 166 insertions(+), 47 deletions(-) -- 2.34.1
[PATCH V2 1/4] board: rockchip: Refactor panel auto-detect code
From: Chris Morgan
Make the inability to detect a panel using the auto detection code not
fail the entire boot process. This means that if the panel ID cannot
be read we don't set an environment variable for the panel, and if an
environment variable for the panel is not set we don't attempt to
update the compatible string. Changes to the code also ensure that
when there are multiple compatible strings required for the panel
we use them both, which solves some issues that will pop up soon
for the Linux driver.
Signed-off-by: Chris Morgan
---
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 115 +
1 file changed, 74 insertions(+), 41 deletions(-)
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3f1a42d184..3d0c614623 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -40,6 +40,7 @@ struct rg3xx_model {
const char *board;
const char *board_name;
const char *fdtfile;
+ const bool detect_panel;
};
enum rgxx3_device_id {
@@ -54,52 +55,67 @@ enum rgxx3_device_id {
static const struct rg3xx_model rg3xx_model_details[] = {
[RG353M] = {
- 517, /* Observed average from device */
- "rk3566-anbernic-rg353m",
- "RG353M",
- DTB_DIR "rk3566-anbernic-rg353p.dtb", /* Identical devices */
+ .adc_value = 517, /* Observed average from device */
+ .board = "rk3566-anbernic-rg353m",
+ .board_name = "RG353M",
+ /* Device is identical to RG353P. */
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+ .detect_panel = 1,
},
[RG353P] = {
- 860, /* Documented value of 860 */
- "rk3566-anbernic-rg353p",
- "RG353P",
- DTB_DIR "rk3566-anbernic-rg353p.dtb",
+ .adc_value = 860, /* Documented value of 860 */
+ .board = "rk3566-anbernic-rg353p",
+ .board_name = "RG353P",
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+ .detect_panel = 1,
},
[RG353V] = {
- 695, /* Observed average from device */
- "rk3566-anbernic-rg353v",
- "RG353V",
- DTB_DIR "rk3566-anbernic-rg353v.dtb",
+ .adc_value = 695, /* Observed average from device */
+ .board = "rk3566-anbernic-rg353v",
+ .board_name = "RG353V",
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg353v.dtb",
+ .detect_panel = 1,
},
[RG503] = {
- 1023, /* Observed average from device */
- "rk3566-anbernic-rg503",
- "RG503",
- DTB_DIR "rk3566-anbernic-rg503.dtb",
+ .adc_value = 1023, /* Observed average from device */
+ .board = "rk3566-anbernic-rg503",
+ .board_name = "RG503",
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
+ .detect_panel = 0,
},
/* Devices with duplicate ADC value */
[RG353PS] = {
- 860, /* Observed average from device */
- "rk3566-anbernic-rg353ps",
- "RG353PS",
- DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+ .adc_value = 860, /* Observed average from device */
+ .board = "rk3566-anbernic-rg353ps",
+ .board_name = "RG353PS",
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+ .detect_panel = 1,
},
[RG353VS] = {
- 695, /* Gathered from second hand information */
- "rk3566-anbernic-rg353vs",
- "RG353VS",
- DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+ .adc_value = 695, /* Gathered from second hand information */
+ .board = "rk3566-anbernic-rg353vs",
+ .board_name = "RG353VS",
+ .fdtfile = DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+ .detect_panel = 1,
},
};
struct rg353_panel {
const u16 id;
- const char *panel_compat;
+ const char *panel_compat[2];
};
static const struct rg353_panel rg353_panel_details[] = {
- { .id = 0x3052, .panel_compat = "newvision,nv3051d"},
- { .id = 0x3821, .panel_compat = "anbernic,rg353v-panel-v2"},
+ {
+ .id = 0x3052,
+ .panel_compat[0] = "anbernic,rg353p-panel",
+ .panel_compat[1] = "newvision,nv3051d",
+ },
+ {
+ .id = 0x3821,
+ .panel_compat[0] = "anbernic,rg353v-panel-v2",
+ .panel_compat[1] = NULL,
+ },
};
/*
@@ -298,11 +314,10 @@ int rgxx3_detect_display(void)
if (!panel) {
printf("Unable to identify panel_id %x\n",
(panel_id[0] << 8) |
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 08:53:49PM +0100, Jonas Karlman wrote:
> On 2023-11-17 20:07, Tom Rini wrote:
> > On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote:
> >>
> >> On 11/17/23 12:50 PM, Tom Rini wrote:
> >>> On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote:
> On lis 14, 2023 15:06, Quentin Schulz wrote:
> > Hi Jonas,
> Hi Quentin
>
> > On 11/12/23 11:26, Jonas Karlman wrote:
> >> The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from
> >> SPI
> >> NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
> >>
> >> At the time the reason for this new bootsource id value 6 was unknown.
> >>
> >> We now know that the BootRom on RK3588 use different bootsource id
> >> values depending on the iomux used by the flash spi controller, and not
> >> by the type of spi nor or spi nand flash used.
> >>
> >> Add the following defines and use them for RK3588 boot_devices.
> >>
> >> - BROM_BOOTSOURCE_FSPI_M0 = 3
> >> - BROM_BOOTSOURCE_FSPI_M1 = 4
> >> - BROM_BOOTSOURCE_FSPI_M2 = 6
> >>
> >> Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
> >> NOR flash")
> >> Signed-off-by: Jonas Karlman
> >> ---
> >>arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
> >>arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
> >>2 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
> >> b/arch/arm/include/asm/arch-rockchip/bootrom.h
> >> index 7dab18fbc3fb..f78337397d63 100644
> >> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> >> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> >> @@ -47,8 +47,10 @@ enum {
> >>BROM_BOOTSOURCE_EMMC = 2,
> >>BROM_BOOTSOURCE_SPINOR = 3,
> >>BROM_BOOTSOURCE_SPINAND = 4,
> >> + BROM_BOOTSOURCE_FSPI_M0 = 3,
> >> + BROM_BOOTSOURCE_FSPI_M1 = 4,
> > I'm a bit wary of two pairs of enums sharing the same value, especially
> > when
> > we want to use them as offset in a static definition of an array.
> >
> > Should we #ifdef it (meh) for RK3588?
> > Should we add a suffix like before for identifying RK3588-specific
> > options?
> >
> > At the very least explicit that those are RK3588-specific in a comment
> > for
> > both conflicts (the ones that apply to everything except RK3588 to say
> > to
> > use only for !RK3588, and the ones that apply to RK3588 only)?
> Can you say why it is so important to know that given enum is specific
> to given CPU here in the
> header file? I think that the enums in the bootrom.h should be as
> generic as possible.
>
> By using the possible enums in a static array, "solves" the problem of
> assigning the boot source to
> specific CPU. There is not need to make such grouping in the bootrom.h.
> >>> Do we have any insight as to why Rockchip re-used those values? Looking
> >>> at the header I see RK3588 has a different SPINOR value than others.
> >>> Does RK3588 share the same value for other sources? How much of
> >>> bootrom.h is still correct for RK3588? I'd rather not have to move to
> >>> having bootrom_${soc}.h like so many other headers are, and if it's just
> >>> these values, it might be cleaner to #if .. #else .. #endif the whole
> >>> enum, and then re-evaluate things abased on whatever the next new SoC
> >>> does here.
> >>>
> >> Which c specification does u-boot follow? Duplicate values in enumerations
> >> are explicitly allowed in c as far as I ever have known.
> >>
> >> "The use of enumerators with = may produce enumeration constants with
> >> values
> >> that duplicate other values in the same enumeration."
> >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
> >
> > Sorry I wasn't clear. It's less about C specification and more about
> > readability. We could do, but I feel is odd readability-wise is:
> > enum {
> > BROM_BOOTSOURCE_NAND = 1,
> > BROM_BOOTSOURCE_EMMC = 2,
> > BROM_BOOTSOURCE_SPINOR = 3,
> > BROM_BOOTSOURCE_SPINAND = 4,
> > BROM_BOOTSOURCE_SD = 5,
> > BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3,
> > BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4,
> > BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5,
> > BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
> > BROM_BOOTSOURCE_USB = 10,
> > BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
> > };
> >
> > But how many of the other values are still correct for RK3588? The TRM I
> > found quickly does say that NAND and SD/eMMC are valid options, and USB,
> > but I didn't see a table that mapped back to the values here.
> >
>
> Remaining values that is supported should be same, the only difference
> for RK3588 is that the old SPINOR=3/SPINAND=4 values now map to flash
> spi iomux M0 and M1, and compared to bootrom in
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On 2023-11-17 20:07, Tom Rini wrote:
> On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote:
>>
>> On 11/17/23 12:50 PM, Tom Rini wrote:
>>> On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote:
On lis 14, 2023 15:06, Quentin Schulz wrote:
> Hi Jonas,
Hi Quentin
> On 11/12/23 11:26, Jonas Karlman wrote:
>> The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
>> NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
>>
>> At the time the reason for this new bootsource id value 6 was unknown.
>>
>> We now know that the BootRom on RK3588 use different bootsource id
>> values depending on the iomux used by the flash spi controller, and not
>> by the type of spi nor or spi nand flash used.
>>
>> Add the following defines and use them for RK3588 boot_devices.
>>
>> - BROM_BOOTSOURCE_FSPI_M0 = 3
>> - BROM_BOOTSOURCE_FSPI_M1 = 4
>> - BROM_BOOTSOURCE_FSPI_M2 = 6
>>
>> Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR
>> flash")
>> Signed-off-by: Jonas Karlman
>> ---
>>arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
>>arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
>>2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
>> b/arch/arm/include/asm/arch-rockchip/bootrom.h
>> index 7dab18fbc3fb..f78337397d63 100644
>> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
>> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
>> @@ -47,8 +47,10 @@ enum {
>> BROM_BOOTSOURCE_EMMC = 2,
>> BROM_BOOTSOURCE_SPINOR = 3,
>> BROM_BOOTSOURCE_SPINAND = 4,
>> +BROM_BOOTSOURCE_FSPI_M0 = 3,
>> +BROM_BOOTSOURCE_FSPI_M1 = 4,
> I'm a bit wary of two pairs of enums sharing the same value, especially
> when
> we want to use them as offset in a static definition of an array.
>
> Should we #ifdef it (meh) for RK3588?
> Should we add a suffix like before for identifying RK3588-specific
> options?
>
> At the very least explicit that those are RK3588-specific in a comment for
> both conflicts (the ones that apply to everything except RK3588 to say to
> use only for !RK3588, and the ones that apply to RK3588 only)?
Can you say why it is so important to know that given enum is specific to
given CPU here in the
header file? I think that the enums in the bootrom.h should be as generic
as possible.
By using the possible enums in a static array, "solves" the problem of
assigning the boot source to
specific CPU. There is not need to make such grouping in the bootrom.h.
>>> Do we have any insight as to why Rockchip re-used those values? Looking
>>> at the header I see RK3588 has a different SPINOR value than others.
>>> Does RK3588 share the same value for other sources? How much of
>>> bootrom.h is still correct for RK3588? I'd rather not have to move to
>>> having bootrom_${soc}.h like so many other headers are, and if it's just
>>> these values, it might be cleaner to #if .. #else .. #endif the whole
>>> enum, and then re-evaluate things abased on whatever the next new SoC
>>> does here.
>>>
>> Which c specification does u-boot follow? Duplicate values in enumerations
>> are explicitly allowed in c as far as I ever have known.
>>
>> "The use of enumerators with = may produce enumeration constants with values
>> that duplicate other values in the same enumeration."
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
>
> Sorry I wasn't clear. It's less about C specification and more about
> readability. We could do, but I feel is odd readability-wise is:
> enum {
> BROM_BOOTSOURCE_NAND = 1,
> BROM_BOOTSOURCE_EMMC = 2,
> BROM_BOOTSOURCE_SPINOR = 3,
> BROM_BOOTSOURCE_SPINAND = 4,
> BROM_BOOTSOURCE_SD = 5,
> BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3,
> BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4,
> BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5,
> BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
> BROM_BOOTSOURCE_USB = 10,
> BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
> };
>
> But how many of the other values are still correct for RK3588? The TRM I
> found quickly does say that NAND and SD/eMMC are valid options, and USB,
> but I didn't see a table that mapped back to the values here.
>
Remaining values that is supported should be same, the only difference
for RK3588 is that the old SPINOR=3/SPINAND=4 values now map to flash
spi iomux M0 and M1, and compared to bootrom in other SoCs cannot be
used to determine if SPI NOR or SPI NAND was the boot source. The new
value 6 maps to flash spi iomux M2. What type of flash spi media the
device was booted from, nor/nand, does not matter for RK3588.
Guess I can add a enum for the rk3588 FSPI_M0/M1/M2 values directly
Re: [PATCH] bootstd: Avoid freeing a non-allocated buffer
On Wed, Nov 15, 2023 at 06:35:23PM -0700, Simon Glass wrote: > EFI applications can be very large and thus used to cause boot failures > when malloc() space was exhausted. > > A recent changed fixed this by using the kernel_addr_r environment var > as the address of the buffer. However, it still frees the buffer when > the bootflow is discarded. > > Fix this by introducing a flag to indicate whether the buffer was > allocated, or not. > > Note that kernel_addr_r is not the last word here. It might be better > to use lmb to place images. But there is a lot of refactoring to do > before we can remove the environment variables. The distro scripts rely > on them so it is safe for bootstd to do so too. > > Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file > > Signed-off-by: Simon Glass > Reported by: Simon Glass > Reported by: Shantur Rathore > Reviewed-by: Heinrich Schuchardt > Tested-by: Shantur Rathore Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] spl: fix TPL_SYS_MALLOC_F description
On Tue, Nov 14, 2023 at 11:30:17AM +, John Keeping wrote: > This config option enables the malloc() pool in TPL not the SPL. Fix > the description to accurately reflect this. > > Fixes: fd8497dae54 (spl: Create proper symbols for enabling the malloc() pool) > Signed-off-by: John Keeping > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] virtio: rng: gracefully handle 0 byte returns
On Tue, Nov 07, 2023 at 04:09:00PM +, Andre Przywara wrote: > According to the virtio v1.x "entropy device" specification, a virtio-rng > device is supposed to always return at least one byte of entropy. > However the virtio v0.9 spec does not mention such a requirement. > > The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always > returns 8 bytes less of entropy than requested. If 8 bytes or less are > requested, it will return 0 bytes. > This behaviour makes U-Boot's virtio_rng_read() implementation go into an > endless loop, hanging the system. > > Work around this problem by always requesting 8 bytes more than needed, > but only if a previous call to virtqueue_get_buf() returned 0 bytes. > > This should never trigger on a v1.x spec compliant implementation, but > fixes the hang on the Arm FVP. > > Signed-off-by: Andre Przywara > Reported-by: Peter Hoyes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Thu, Oct 26, 2023 at 09:32:20AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This fixes a regression in the eMMC fast boot mode case where the buffer
> was missing 464 bytes.
>
> The code figures out how many bytes must at least be fetched to honor
> the current read, rounds that up to the ss->pagesize [which is a no-op
> in the USB download case because that has ->pagesize==1], fetches that
> many bytes, but then recorded the original upper bound as the new end of
> the valid data. However, this did not take into account the rounding up
> to the ss->pagesize. Fix this by recording the actual bytes downloaded.
>
> Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of
> spl_load_simple_fit() to get full FIT size")
> Signed-off-by: Marcel Ziswiler
> Acked-by: Rasmus Villemoes
> Reviewed-by: Fabio Estevam
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
On Fri, Oct 27, 2023 at 01:23:54PM +1300, Chris Packham wrote: > This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
On Fri, Oct 27, 2023 at 01:23:52PM +1300, Chris Packham wrote: > This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
On Fri, Oct 27, 2023 at 01:23:53PM +1300, Chris Packham wrote: > This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/2] imx: spl_imx_romapi: fix comment about stream(usb) download failure
On Thu, Oct 26, 2023 at 09:32:19AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Fix comment about Stream(USB) download failure.
>
> Fixes: 1cbebc786276 ("imx: add rom api support")
> Signed-off-by: Marcel Ziswiler
> Reviewed-by: Fabio Estevam
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 0/3] Revert HAFDBS changes
On Fri, Nov 10, 2023 at 06:38:40PM +1300, Chris Packham wrote: > On Fri, 10 Nov 2023, 10:33 am Tom Rini, wrote: > > > On Fri, Oct 27, 2023 at 01:22:37PM -0400, Tom Rini wrote: > > > On Fri, Oct 27, 2023 at 10:49:47AM +0100, Pierre-Clément Tosi wrote: > > > > Hi Chris, > > > > > > > > On Fri, Oct 27, 2023 at 01:23:51PM +1300, Chris Packham wrote: > > > > > As discussed this series reverts the HAFDBS changes that caused an > > issue > > > > > on AC5/AC5X. I think there are some improvements that can be made to > > the > > > > > initial memory map for the AC5/AC5X but so far nothing I've found > > makes > > > > > it compatible with the HAFDBS changes. > > > > > > > > Would you mind briefly explaining what those issues are and/or point > > me to the > > > > discussion where it was decided to revert these patches? > > > > > > > > The feature is quite useful for users of CONFIG_CMO_BY_VA_ONLY, to > > speed up the > > > > boot sequence: instead of reverting these patches altogether, would a > > reasonable > > > > alternative be to put them behind a build option? > > > > > > > > Also, could you confirm that the "initial memory map" you are > > referring to above > > > > only describes actual memory as, IIRC, some boards were using mappings > > **much** > > > > larger than their DRAM address space? > > > > > > The most details are in this thread: > > > > > https://lore.kernel.org/u-boot/CAFOYHZC_Dveax85n0fLr5BFyZcLqsvUssn=j0ohyvn75bta...@mail.gmail.com/ > > > with some follow-up in: > > > > > https://lore.kernel.org/u-boot/CAFOYHZB7jJWwD24oWzx6u55w2whHYjK56f=qyn0lwu4z8ds...@mail.gmail.com/ > > > > Checking to see if you have any feedback for these platforms? I would > > like to have them working again one way or another in v2024.01, thanks. > > > > Either this series or > https://lore.kernel.org/u-boot/20231018205358.1557234-1-judge.pack...@gmail.com/ > will get the AC5X boards back working. I'm out of other ideas but happy to > test patches. Following up here on the cover letter as well that I've applied the revert for now. I'm happy to revert the revert if we can get the AC5X platforms fixed, and perhaps a little documentation about what was going wrong as I believe the other thread at least hinted that other platforms might be doing a workaround as well but didn't spell out why. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote:
>
> On 11/17/23 12:50 PM, Tom Rini wrote:
> > On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote:
> > > On lis 14, 2023 15:06, Quentin Schulz wrote:
> > > > Hi Jonas,
> > > Hi Quentin
> > >
> > > > On 11/12/23 11:26, Jonas Karlman wrote:
> > > > > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from
> > > > > SPI
> > > > > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
> > > > >
> > > > > At the time the reason for this new bootsource id value 6 was unknown.
> > > > >
> > > > > We now know that the BootRom on RK3588 use different bootsource id
> > > > > values depending on the iomux used by the flash spi controller, and
> > > > > not
> > > > > by the type of spi nor or spi nand flash used.
> > > > >
> > > > > Add the following defines and use them for RK3588 boot_devices.
> > > > >
> > > > > - BROM_BOOTSOURCE_FSPI_M0 = 3
> > > > > - BROM_BOOTSOURCE_FSPI_M1 = 4
> > > > > - BROM_BOOTSOURCE_FSPI_M2 = 6
> > > > >
> > > > > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
> > > > > NOR flash")
> > > > > Signed-off-by: Jonas Karlman
> > > > > ---
> > > > >arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
> > > > >arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
> > > > >2 files changed, 6 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > > > b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > > > index 7dab18fbc3fb..f78337397d63 100644
> > > > > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > > > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > > > @@ -47,8 +47,10 @@ enum {
> > > > > BROM_BOOTSOURCE_EMMC = 2,
> > > > > BROM_BOOTSOURCE_SPINOR = 3,
> > > > > BROM_BOOTSOURCE_SPINAND = 4,
> > > > > + BROM_BOOTSOURCE_FSPI_M0 = 3,
> > > > > + BROM_BOOTSOURCE_FSPI_M1 = 4,
> > > > I'm a bit wary of two pairs of enums sharing the same value, especially
> > > > when
> > > > we want to use them as offset in a static definition of an array.
> > > >
> > > > Should we #ifdef it (meh) for RK3588?
> > > > Should we add a suffix like before for identifying RK3588-specific
> > > > options?
> > > >
> > > > At the very least explicit that those are RK3588-specific in a comment
> > > > for
> > > > both conflicts (the ones that apply to everything except RK3588 to say
> > > > to
> > > > use only for !RK3588, and the ones that apply to RK3588 only)?
> > > Can you say why it is so important to know that given enum is specific to
> > > given CPU here in the
> > > header file? I think that the enums in the bootrom.h should be as generic
> > > as possible.
> > >
> > > By using the possible enums in a static array, "solves" the problem of
> > > assigning the boot source to
> > > specific CPU. There is not need to make such grouping in the bootrom.h.
> > Do we have any insight as to why Rockchip re-used those values? Looking
> > at the header I see RK3588 has a different SPINOR value than others.
> > Does RK3588 share the same value for other sources? How much of
> > bootrom.h is still correct for RK3588? I'd rather not have to move to
> > having bootrom_${soc}.h like so many other headers are, and if it's just
> > these values, it might be cleaner to #if .. #else .. #endif the whole
> > enum, and then re-evaluate things abased on whatever the next new SoC
> > does here.
> >
> Which c specification does u-boot follow? Duplicate values in enumerations
> are explicitly allowed in c as far as I ever have known.
>
> "The use of enumerators with = may produce enumeration constants with values
> that duplicate other values in the same enumeration."
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
Sorry I wasn't clear. It's less about C specification and more about
readability. We could do, but I feel is odd readability-wise is:
enum {
BROM_BOOTSOURCE_NAND = 1,
BROM_BOOTSOURCE_EMMC = 2,
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
BROM_BOOTSOURCE_SD = 5,
BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3,
BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4,
BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5,
BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
BROM_BOOTSOURCE_USB = 10,
BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
};
But how many of the other values are still correct for RK3588? The TRM I
found quickly does say that NAND and SD/eMMC are valid options, and USB,
but I didn't see a table that mapped back to the values here.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On 11/17/23 12:50 PM, Tom Rini wrote:
On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote:
On lis 14, 2023 15:06, Quentin Schulz wrote:
Hi Jonas,
Hi Quentin
On 11/12/23 11:26, Jonas Karlman wrote:
The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
At the time the reason for this new bootsource id value 6 was unknown.
We now know that the BootRom on RK3588 use different bootsource id
values depending on the iomux used by the flash spi controller, and not
by the type of spi nor or spi nand flash used.
Add the following defines and use them for RK3588 boot_devices.
- BROM_BOOTSOURCE_FSPI_M0 = 3
- BROM_BOOTSOURCE_FSPI_M1 = 4
- BROM_BOOTSOURCE_FSPI_M2 = 6
Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash")
Signed-off-by: Jonas Karlman
---
arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
b/arch/arm/include/asm/arch-rockchip/bootrom.h
index 7dab18fbc3fb..f78337397d63 100644
--- a/arch/arm/include/asm/arch-rockchip/bootrom.h
+++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
@@ -47,8 +47,10 @@ enum {
BROM_BOOTSOURCE_EMMC = 2,
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
+ BROM_BOOTSOURCE_FSPI_M0 = 3,
+ BROM_BOOTSOURCE_FSPI_M1 = 4,
I'm a bit wary of two pairs of enums sharing the same value, especially when
we want to use them as offset in a static definition of an array.
Should we #ifdef it (meh) for RK3588?
Should we add a suffix like before for identifying RK3588-specific options?
At the very least explicit that those are RK3588-specific in a comment for
both conflicts (the ones that apply to everything except RK3588 to say to
use only for !RK3588, and the ones that apply to RK3588 only)?
Can you say why it is so important to know that given enum is specific to given
CPU here in the
header file? I think that the enums in the bootrom.h should be as generic as
possible.
By using the possible enums in a static array, "solves" the problem of
assigning the boot source to
specific CPU. There is not need to make such grouping in the bootrom.h.
Do we have any insight as to why Rockchip re-used those values? Looking
at the header I see RK3588 has a different SPINOR value than others.
Does RK3588 share the same value for other sources? How much of
bootrom.h is still correct for RK3588? I'd rather not have to move to
having bootrom_${soc}.h like so many other headers are, and if it's just
these values, it might be cleaner to #if .. #else .. #endif the whole
enum, and then re-evaluate things abased on whatever the next new SoC
does here.
Which c specification does u-boot follow? Duplicate values in
enumerations are explicitly allowed in c as far as I ever have known.
"The use of enumerators with = may produce enumeration constants with
values that duplicate other values in the same enumeration."
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
Re: [PATCH 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file
On 11/17/23 8:27 AM, Romain Naour wrote: Hello Andrew, All, Le 03/11/2023 à 20:20, Andrew Davis a écrit : On 11/3/23 2:06 PM, Nishanth Menon wrote: On 13:51-20231103, Andrew Davis wrote: On 11/2/23 7:38 PM, Nishanth Menon wrote: Add defconfig fragments for J721E based BeagleBone AI-64 and corresponding customized environment. Signed-off-by: Nishanth Menon --- board/ti/j721e/beagleboneai64.env | 19 board/ti/j721e/beagleboneai64_a72.config | 55 board/ti/j721e/beagleboneai64_r5.config | 19 Beagle boards are not TI boards, add the board support to board/beagle/ Huh, why bring in commercials and organization changes here? am335x and am62 are under the TI umbrella. The SoCs used are yes, the boards are not, we only make our EVM/SK line of boards in house. We did AM335x wrong, in board/ti/am335x/board.c we tried to support like 11 different boards in one file. And while it might have made adding our own extra EVMs easier, it only made things less clear for folks trying to add their own AM335x based boards[0]. We don't integrate support for any other board partner like this. Our friends over at Toradex or Phytec are currently upstreaming boards based on K3 SoCs and in doing so have shown us some areas we can improve. We focus on these little short-cuts to make adding our EVMs (or boards that look like our EVMs) easy. But that only leads to extra work and code duplication for external boards. If something is actually common to the SoC then lets move it to arch/arm/mach-k3/j721e. Tricks like board-variants.c only hide the issue and doesn't help folks wanting to add their boards based on our SoCs to their board// directory. I'm starting a new custom board bring-up based on a j721e SoC (without any SOM) and adding a now board variant from the u-boot provided in the TI SDK (based on 2023.04) is far from easy for the reasons mentioned above (extra work and code duplication for external boards). Also the build break for j7200/j721e SoC as soon as CONFIG_TARGET_J721E_A72_EVM and CONFIG_TARGET_J7200_A72_EVM are undefined: The issue is we didn't properly split J7200 support from J721e and now that there are differences between the two, the only way we have to check which is which is to check the TARGET board, not the SOC (as there is no SOC_K3_J7200, but we are working on that [0]). So currently adding new J721E/J7200 TARGET boards breaks things :( https://source.denx.de/u-boot/u-boot/-/blob/v2023.10/arch/arm/mach-k3/arm64-mmu.c?ref_type=tags#L71 I always wonder if I should work on top of EVMs board or create a new board// directory for customer boards. New board// would be preferred, we do things in our EVM board/ti/ dir that are specific to our EVMs, and there will be more churn, etc.. If adding a new board// for our SoCs is difficult just let us know, we are working several issues to make it more easy going forward and guiding feedback always helps. Andrew [0] https://lore.kernel.org/all/20231106165044.xrmlxoyfbnkmpb5v@revolt/ Best regards, Romain Andrew [0] See "Software Design" https://jaycarlson.net/embedded-linux/#am335x $ git grep beagle board/|cut -d ':' -f1|sort -u board/ti/am335x/board.c board/ti/am335x/board.h board/ti/am57xx/board.c board/ti/am62x/beagleplay_a53.config board/ti/am62x/beagleplay_r5.config board/ti/am62x/MAINTAINERS board/ti/beagle/beagle.c board/ti/beagle/Kconfig board/ti/beagle/led.c board/ti/beagle/MAINTAINERS board/ti/beagle/Makefile board/ti/j721e/beagleboneai64_a72.config board/ti/j721e/beagleboneai64_r5.config board/ti/j721e/MAINTAINERS board/timll/devkit8000/README
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote:
> On lis 14, 2023 15:06, Quentin Schulz wrote:
> > Hi Jonas,
>
> Hi Quentin
>
> > On 11/12/23 11:26, Jonas Karlman wrote:
> > > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
> > > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
> > >
> > > At the time the reason for this new bootsource id value 6 was unknown.
> > >
> > > We now know that the BootRom on RK3588 use different bootsource id
> > > values depending on the iomux used by the flash spi controller, and not
> > > by the type of spi nor or spi nand flash used.
> > >
> > > Add the following defines and use them for RK3588 boot_devices.
> > >
> > > - BROM_BOOTSOURCE_FSPI_M0 = 3
> > > - BROM_BOOTSOURCE_FSPI_M1 = 4
> > > - BROM_BOOTSOURCE_FSPI_M2 = 6
> > >
> > > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR
> > > flash")
> > > Signed-off-by: Jonas Karlman
> > > ---
> > > arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
> > > arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
> > > 2 files changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > index 7dab18fbc3fb..f78337397d63 100644
> > > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > > @@ -47,8 +47,10 @@ enum {
> > > BROM_BOOTSOURCE_EMMC = 2,
> > > BROM_BOOTSOURCE_SPINOR = 3,
> > > BROM_BOOTSOURCE_SPINAND = 4,
> > > + BROM_BOOTSOURCE_FSPI_M0 = 3,
> > > + BROM_BOOTSOURCE_FSPI_M1 = 4,
> >
> > I'm a bit wary of two pairs of enums sharing the same value, especially when
> > we want to use them as offset in a static definition of an array.
> >
> > Should we #ifdef it (meh) for RK3588?
> > Should we add a suffix like before for identifying RK3588-specific options?
> >
> > At the very least explicit that those are RK3588-specific in a comment for
> > both conflicts (the ones that apply to everything except RK3588 to say to
> > use only for !RK3588, and the ones that apply to RK3588 only)?
>
> Can you say why it is so important to know that given enum is specific to
> given CPU here in the
> header file? I think that the enums in the bootrom.h should be as generic as
> possible.
>
> By using the possible enums in a static array, "solves" the problem of
> assigning the boot source to
> specific CPU. There is not need to make such grouping in the bootrom.h.
Do we have any insight as to why Rockchip re-used those values? Looking
at the header I see RK3588 has a different SPINOR value than others.
Does RK3588 share the same value for other sources? How much of
bootrom.h is still correct for RK3588? I'd rather not have to move to
having bootrom_${soc}.h like so many other headers are, and if it's just
these values, it might be cleaner to #if .. #else .. #endif the whole
enum, and then re-evaluate things abased on whatever the next new SoC
does here.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 06/32] bootstd: Introduce programmable boot
On Wed, Nov 15, 2023 at 09:10:06PM -0700, Simon Glass wrote:
> At present bootstd requires CONFIG_CMDLINE to operate. Add a new
> 'programmable' boot which can be used when no command line is available.
> For now it does almost nothing, since most bootmeths require the
> command line.
>
> Signed-off-by: Simon Glass
[snip]
> @@ -67,6 +68,14 @@ void main_loop(void)
>
> autoboot_command(s);
>
> + if (IS_ENABLED(CONFIG_BOOTSTD_PROG)) {
> + int ret;
> +
> + ret = bootstd_prog_boot();
> + printf("Standard boot failed (err=%dE)\n", ret);
> + }
> +
> cli_loop();
> +
> panic("No CLI available");
I think this this brings in at least a 3rd option now, we should try and
condense things a little or clean it up maybe. We have common/autoboot.c
which is what will fire off menu_show() and drop things in to that menu
instead of the cmdline (but that does have cmdline as an option to run,
and I suspect that just exits gracefully from the cmd). With CMDLINE=n,
cli_loop prints we can't do anything and then panics, so we should also
maybe panic() in the case it bootstd_prog_boot fails rather than
continue?
--
Tom
signature.asc
Description: PGP signature
[PATCH 2/2] board: st: common: simplify MTD device parsing
Simplify the way all MTD devices are parsed.
Signed-off-by: Patrice Chotard
---
board/st/common/stm32mp_dfu.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
index ded3bf81961..77edb86e78c 100644
--- a/board/st/common/stm32mp_dfu.c
+++ b/board/st/common/stm32mp_dfu.c
@@ -123,24 +123,9 @@ void set_dfu_alt_info(char *interface, char *devstr)
/* probe all MTD devices */
mtd_probe_devices();
- /* probe SPI flash device on a bus */
- if (!uclass_get_device(UCLASS_SPI_FLASH, 0, )) {
- mtd = get_mtd_device_nm("nor0");
- if (!IS_ERR_OR_NULL(mtd))
+ mtd_for_each_device(mtd)
+ if (!mtd_is_partition(mtd))
board_get_alt_info_mtd(mtd, buf);
-
- mtd = get_mtd_device_nm("nor1");
- if (!IS_ERR_OR_NULL(mtd))
- board_get_alt_info_mtd(mtd, buf);
- }
-
- mtd = get_mtd_device_nm("nand0");
- if (!IS_ERR_OR_NULL(mtd))
- board_get_alt_info_mtd(mtd, buf);
-
- mtd = get_mtd_device_nm("spi-nand0");
- if (!IS_ERR_OR_NULL(mtd))
- board_get_alt_info_mtd(mtd, buf);
}
if (IS_ENABLED(CONFIG_DFU_VIRT)) {
--
2.25.1
[PATCH 1/2] board: st: common: Fix board_get_alt_info_mtd()
Since MTD devices are partioned, we got the following
error when command "dfu 0" is executed:
DFU alt info setting: done
ERROR: Too many arguments for nor0
ERROR: DFU entities configuration failed!
ERROR: (partition table does not match dfu_alt_info?)
Fixes: 31325e1b8b9c ("stm32mp1: dynamically build DFU_ALT_INFO")
Signed-off-by: Patrice Chotard
---
board/st/common/stm32mp_dfu.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
index a8eb8d5cae2..ded3bf81961 100644
--- a/board/st/common/stm32mp_dfu.c
+++ b/board/st/common/stm32mp_dfu.c
@@ -73,7 +73,6 @@ static void board_get_alt_info_mmc(struct udevice *dev, char
*buf)
static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf)
{
struct mtd_info *part;
- bool first = true;
const char *name;
int len, partnum = 0;
@@ -86,17 +85,13 @@ static void board_get_alt_info_mtd(struct mtd_info *mtd,
char *buf)
"mtd %s=", name);
len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
- "%s raw 0x0 0x%llx ",
+ "%s raw 0x0 0x%llx",
name, mtd->size);
list_for_each_entry(part, >partitions, node) {
partnum++;
- if (!first)
- len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, ";");
- first = false;
-
len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
- "%s_%s part %d",
+ ";%s_%s part %d",
name, part->name, partnum);
}
}
--
2.25.1
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On lis 14, 2023 15:06, Quentin Schulz wrote:
> Hi Jonas,
Hi Quentin
> On 11/12/23 11:26, Jonas Karlman wrote:
> > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI
> > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6.
> >
> > At the time the reason for this new bootsource id value 6 was unknown.
> >
> > We now know that the BootRom on RK3588 use different bootsource id
> > values depending on the iomux used by the flash spi controller, and not
> > by the type of spi nor or spi nand flash used.
> >
> > Add the following defines and use them for RK3588 boot_devices.
> >
> > - BROM_BOOTSOURCE_FSPI_M0 = 3
> > - BROM_BOOTSOURCE_FSPI_M1 = 4
> > - BROM_BOOTSOURCE_FSPI_M2 = 6
> >
> > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR
> > flash")
> > Signed-off-by: Jonas Karlman
> > ---
> > arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++-
> > arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++--
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > index 7dab18fbc3fb..f78337397d63 100644
> > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> > @@ -47,8 +47,10 @@ enum {
> > BROM_BOOTSOURCE_EMMC = 2,
> > BROM_BOOTSOURCE_SPINOR = 3,
> > BROM_BOOTSOURCE_SPINAND = 4,
> > + BROM_BOOTSOURCE_FSPI_M0 = 3,
> > + BROM_BOOTSOURCE_FSPI_M1 = 4,
>
> I'm a bit wary of two pairs of enums sharing the same value, especially when
> we want to use them as offset in a static definition of an array.
>
> Should we #ifdef it (meh) for RK3588?
> Should we add a suffix like before for identifying RK3588-specific options?
>
> At the very least explicit that those are RK3588-specific in a comment for
> both conflicts (the ones that apply to everything except RK3588 to say to
> use only for !RK3588, and the ones that apply to RK3588 only)?
Can you say why it is so important to know that given enum is specific to given
CPU here in the
header file? I think that the enums in the bootrom.h should be as generic as
possible.
By using the possible enums in a static array, "solves" the problem of
assigning the boot source to
specific CPU. There is not need to make such grouping in the bootrom.h.
--
Slawomir Stepien
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Fri, Nov 17, 2023 at 01:13:07PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Fri, Nov 17, 2023 at 11:25 AM Tom Rini wrote: > > > OK. Fabio, please send me your patchwork username off-list and I'll get > > you added and you can start managing patches there. I've started using > > some of the b4 + patchwork integration just recently and it's very nice. > > In the meantime, could you pleas directly apply this series from Marcel? I've put it in my list for before the next -rc. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
Hi Tom, On Fri, Nov 17, 2023 at 11:25 AM Tom Rini wrote: > OK. Fabio, please send me your patchwork username off-list and I'll get > you added and you can start managing patches there. I've started using > some of the b4 + patchwork integration just recently and it's very nice. In the meantime, could you pleas directly apply this series from Marcel? Thanks
[PATCH] boards: Disable NET on platforms without NETDEVICES
None of these platforms enabled a networking devices, and disabled CMD_NET. Given that we used to gate network support on CMD_NET rather than NET, we disable CONFIG_NET on these platforms now. Signed-off-by: Tom Rini --- Cc: Simon Glass Cc: Heinrich Schuchardt Cc: Matthias Winker Cc: Philip Oberfichtner Cc: Minkyu Kang Cc: Jaehoon Chung Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Sergey Temerkhanov --- configs/efi-x86_app32_defconfig | 3 +-- configs/efi-x86_app64_defconfig | 3 +-- configs/imx6q_bosch_acc_defconfig | 3 +-- configs/origen_defconfig| 2 +- configs/s5pc210_universal_defconfig | 2 +- configs/stm32mp25_defconfig | 2 +- configs/thunderx_88xx_defconfig | 2 +- configs/trats2_defconfig| 2 +- configs/trats_defconfig | 2 +- 9 files changed, 9 insertions(+), 12 deletions(-) diff --git a/configs/efi-x86_app32_defconfig b/configs/efi-x86_app32_defconfig index 682ba5b89576..e2e6f42c9a9d 100644 --- a/configs/efi-x86_app32_defconfig +++ b/configs/efi-x86_app32_defconfig @@ -21,7 +21,6 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_BOOTZ=y CONFIG_CMD_PART=y # CONFIG_CMD_SCSI is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y @@ -36,7 +35,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="bzImage" -CONFIG_USE_ROOTPATH=y +# CONFIG_NET is not set CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_REGEX is not set diff --git a/configs/efi-x86_app64_defconfig b/configs/efi-x86_app64_defconfig index d6b6c3d82995..14b5cd0fa0ee 100644 --- a/configs/efi-x86_app64_defconfig +++ b/configs/efi-x86_app64_defconfig @@ -22,7 +22,6 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_BOOTZ=y CONFIG_CMD_PART=y # CONFIG_CMD_SCSI is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y @@ -38,7 +37,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="bzImage" -CONFIG_USE_ROOTPATH=y +# CONFIG_NET is not set CONFIG_REGMAP=y CONFIG_SYSCON=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/imx6q_bosch_acc_defconfig b/configs/imx6q_bosch_acc_defconfig index 05bab034e0f9..6abb7954ba2d 100644 --- a/configs/imx6q_bosch_acc_defconfig +++ b/configs/imx6q_bosch_acc_defconfig @@ -63,7 +63,6 @@ CONFIG_CMD_PART=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SOURCE is not set # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_NET is not set # CONFIG_CMD_BLOCK_CACHE is not set # CONFIG_CMD_SLEEP is not set # CONFIG_CMD_MP is not set @@ -82,7 +81,7 @@ CONFIG_SYS_MMC_ENV_PART=1 CONFIG_ENV_WRITEABLE_LIST=y CONFIG_ENV_ACCESS_IGNORE_FORCE=y CONFIG_VERSION_VARIABLE=y -CONFIG_TFTP_BLOCKSIZE=512 +# CONFIG_NET is not set CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_DM_BOOTCOUNT=y diff --git a/configs/origen_defconfig b/configs/origen_defconfig index 3a71d6e582a7..5e55b712df9e 100644 --- a/configs/origen_defconfig +++ b/configs/origen_defconfig @@ -35,13 +35,13 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y # CONFIG_CMD_SLEEP is not set CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DFU_MMC=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200 CONFIG_MMC_DW=y diff --git a/configs/s5pc210_universal_defconfig b/configs/s5pc210_universal_defconfig index f585c510635a..ac236c82a1fc 100644 --- a/configs/s5pc210_universal_defconfig +++ b/configs/s5pc210_universal_defconfig @@ -33,7 +33,6 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y # CONFIG_CMD_SLEEP is not set CONFIG_CMD_EXT4_WRITE=y @@ -42,6 +41,7 @@ CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +# CONFIG_NET is not set CONFIG_DFU_MMC=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200 CONFIG_SYS_I2C_S3C24X0=y diff --git a/configs/stm32mp25_defconfig b/configs/stm32mp25_defconfig index 8423943f091c..75f27c98b441 100644 --- a/configs/stm32mp25_defconfig +++ b/configs/stm32mp25_defconfig @@ -23,7 +23,6 @@ CONFIG_CMD_MEMTEST=y CONFIG_CMD_CLK=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADB is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_RNG=y @@ -31,6 +30,7 @@ CONFIG_CMD_TIMER=y CONFIG_CMD_REGULATOR=y CONFIG_CMD_LOG=y CONFIG_OF_LIVE=y +# CONFIG_NET is not set CONFIG_GPIO_HOG=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_STM32F7=y diff --git a/configs/thunderx_88xx_defconfig b/configs/thunderx_88xx_defconfig index 5c24b38bb1fa..0c71b298ada5 100644 --- a/configs/thunderx_88xx_defconfig +++ b/configs/thunderx_88xx_defconfig @@ -32,8 +32,8 @@ CONFIG_SYS_BOOTM_LEN=0x80 # CONFIG_CMD_EDITENV is not set # CONFIG_CMD_SAVEENV is not set # CONFIG_CMD_ENV_EXISTS is not set -# CONFIG_CMD_NET is not set
Re: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU
On Fri, Nov 17, 2023 at 04:35:22PM +0100, Heinrich Schuchardt wrote: > On 8/17/23 19:41, Tom Rini wrote: > > The implementation of this option in lib/fwu_updates/fwu_gpt.c is wholly > > dependent on DFU, so make that a requirement here. > > > > Signed-off-by: Tom Rini > > --- > > I'm honestly not sure how to best proceed here as > > drivers/fwu-mdata/gpt_blk.c doesn't need DFU, but both files are > > controlled by this single symbol. > > > > Cc: Masami Hiramatsu > > Cc: Jassi Brar > > Cc: Sughosh Ganu > > Cc: Ilias Apalodimas > > Cc: Heinrich Schuchardt > > --- > > drivers/fwu-mdata/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig > > index 42736a5e43b0..0bd5fef4abfa 100644 > > --- a/drivers/fwu-mdata/Kconfig > > +++ b/drivers/fwu-mdata/Kconfig > > @@ -15,7 +15,7 @@ config FWU_MDATA_GPT_BLK > > bool "FWU Metadata access for GPT partitioned Block devices" > > select PARTITION_TYPE_GUID > > select PARTITION_UUIDS > > - depends on FWU_MDATA && BLK && EFI_PARTITION > > + depends on FWU_MDATA && BLK && EFI_PARTITION && DFU > > Hello Tom, > > This looks like the wrong level of configuration to add a DFU dependency. > > EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW select DFU and > EFI_CAPSULE_FIRMWARE. > > We probably should let CONFIG_FWU_MDATA depend on EFI_CAPSULE_ON_DISK. OK, but that doesn't address the dependency? The code in lib/fwu_updates/fwu_gpt.c needs DFU and is under FWU_MDATA_GPT_BLK. It provides fwu_plat_get_alt_num() which is called by fwu_get_image_index() and is under FWU_MULTI_BANK_UPDATE and in turn called by efi_firmware_raw_set_image() which is under EFI_CAPSULE_FIRMWARE_RAW. If both lib/fwu_updates/fwu_gpt.c and drivers/fwu-mdata/gpt_blk.c should be under the same symbol then it needs to depend on DFU, since it's a direct dependency in the code. We could change it up to EFI_CAPSULE_FIRMWARE_RAW I guess, but I'm not sure that's cleaner. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU
On 8/17/23 19:41, Tom Rini wrote: The implementation of this option in lib/fwu_updates/fwu_gpt.c is wholly dependent on DFU, so make that a requirement here. Signed-off-by: Tom Rini --- I'm honestly not sure how to best proceed here as drivers/fwu-mdata/gpt_blk.c doesn't need DFU, but both files are controlled by this single symbol. Cc: Masami Hiramatsu Cc: Jassi Brar Cc: Sughosh Ganu Cc: Ilias Apalodimas Cc: Heinrich Schuchardt --- drivers/fwu-mdata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig index 42736a5e43b0..0bd5fef4abfa 100644 --- a/drivers/fwu-mdata/Kconfig +++ b/drivers/fwu-mdata/Kconfig @@ -15,7 +15,7 @@ config FWU_MDATA_GPT_BLK bool "FWU Metadata access for GPT partitioned Block devices" select PARTITION_TYPE_GUID select PARTITION_UUIDS - depends on FWU_MDATA && BLK && EFI_PARTITION + depends on FWU_MDATA && BLK && EFI_PARTITION && DFU Hello Tom, This looks like the wrong level of configuration to add a DFU dependency. EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW select DFU and EFI_CAPSULE_FIRMWARE. We probably should let CONFIG_FWU_MDATA depend on EFI_CAPSULE_ON_DISK. Best regards Heinrich help Enable support for accessing FWU Metadata on GPT partitioned block devices.
Re: bootstd: Support for distro specific EFI folders
On 11/16/23 19:45, Shantur Rathore wrote: On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt wrote: On 11/16/23 17:52, Shantur Rathore wrote: Hi Simon, Currently bootstd - bootmethod_efi only looks for the default bootxx64.efi in /EFI/boot folder only. Generally many distros end up putting their bootloaders in EFI/ folders like EFI/ubuntu and EFI/debian etc. In x86 worlds, the NVRAM is modified and new boot entries are added to support these but in the U-boot world the NVRAM variables are read-only. I guess you are referring to UEFI boot options. These typically are not stored in non-volatile RAM but on a SPI flash device. Thanks for correcting me. What would be the best way to implement this? I was thinking of having a "efi_prefixes" environment variable which can be set to "ubuntu debian centos" etc and bootmethod_efi can try all of them. Will bootmethod_efi be able to support multiple entries ( thinking of multiboot ) ? On my laptop I have: EFI/Microsoft/Boot/bootmgr.efi EFI/Microsoft/Boot/memtest.efi EFI/Boot/bootx64.efi EFI/Boot/fbx64.efi EFI/Boot/mmx64.efi EFI/debian/shimx64.efi EFI/debian/grubx64.efi EFI/debian/mmx64.efi EFI/debian/fbx64.efi EFI/ubuntu/grubx64.efi EFI/ubuntu/shimx64.efi EFI/ubuntu/mmx64.efi Obviously each installed operating system provides multiple EFI binaries and non uses the fallback file name BOOT.EFI. A value "ubuntu debian centos" would not be able to describe which file you are looking for. We already have the U-Boot command line eficonfig and efidebug commands to set up UEFI boot options which can describe which EFI binary to load and which command line to pass to it. These are considered by the existing boot flows. So, I am building a new RockPro64 based cluster and using Canonical MAAS to set them up automatically, booting them up using DHCP and installing them over the network. I configured an Armbian image using Packer to be compatible with MAAS and it happily installs it. As part of installation process, a grub-install is run which installs the grub efi, this EFI ends up in EFI/debian instead of expected EFI/boot. To be able to make it boot, I have to add commands to move it to EFI/boot. I am trying to find a way in U-Boot that would allow me to skip this step. With eficonfig if I understand correctly, it would need manual intervention to create boot entries. If you are installing the shim-signed package on Ubuntu, the EFI boot option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the content of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() and therefore should work with current U-Boot. Patches are pending upstream to make EFI variables writable from Linux if they are stored in the RPMB partition in the eMMC. See this series: https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ Would it be possible to save it in SPI Flash as the U-Boot environment ? Currently this is not supported by U-Boot. The U-Boot environment variables can be stored in lots of different places SPI flash is only one of these. But none of these locations is protected from OS access which would be preferable for UEFI variables for security reasons. To support boards without eMMC the right way forward would be writing a new implementation of the OP-TEE standalone MM which writes the variables to SPI flash instead of the RPMB partition and ensures that the SPI flash' MMIO registers are protected against access from the non-secure world. Best regards Heinrich
[PATCH] tqma6: Fix DDR configuration
Initially investigating a Linux network issue causing a lot of drop and poor network performances on a custom system based on a TQMA6A module (based on an iMX6Q), [1st link below]. I eventually correlated my observations with a contention at the NIC level when in concurrency with the graphics pipeline. Troubleshooting this in the kernel lead to disabling DMA bursts accesses made by the IPU in order to avoid triggering the QoS at the interconnect level, reducing from 50 to 10% the drop rate on eth0, [2nd link below]. The solution worked on my setup but not on others, which still suffered from abnormally high drop rates even with this "fix". After looking a while into TQ Systems BSP I figured out a number of differences in recent U-Boot out-of-tree patches they had in their repository [3rd link]. Parsing the differences one after the other lead me to this final solution. The reset pad of the DDR controller was apparently misconfigured, Bit 18-19 picturing the "DDR select field". The current value b11 is reserved. The only defined value as of version 6 of the iMX6Q manual was b00 "DDR3 and LPDDR2 mode". In practice no register difference has been spotted after changing this configuration but all issues tracked thus far just vanished. All previous fixes have been proven irrelevant. Just clearing this field solved all our network issues and the drop rate as measured by iperf3 felt back to 0%. Link: https://lore.kernel.org/netdev/20231012193410.3d1812cf@xps-13/ Link: https://lists.freedesktop.org/archives/dri-devel/2023-October/428251.html Link: https://github.com/tq-systems/u-boot-tqmaxx/commit/15eb6abbefbf6916c28467b85485911dad3da6bc Signed-off-by: Miquel Raynal --- board/tq/tqma6/tqma6q.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/tq/tqma6/tqma6q.cfg b/board/tq/tqma6/tqma6q.cfg index a49489aed3f..a345c4de93d 100644 --- a/board/tq/tqma6/tqma6q.cfg +++ b/board/tq/tqma6/tqma6q.cfg @@ -36,7 +36,7 @@ DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x8030 DATA 4, MX6_IOM_DRAM_CAS, 0x8030 DATA 4, MX6_IOM_DRAM_RAS, 0x8030 DATA 4, MX6_IOM_GRP_ADDDS, 0x0030 -DATA 4, MX6_IOM_DRAM_RESET, 0x000C3030 +DATA 4, MX6_IOM_DRAM_RESET, 0x3030 DATA 4, MX6_IOM_DRAM_SDCKE0, 0x3000 DATA 4, MX6_IOM_DRAM_SDCKE1, 0x DATA 4, MX6_IOM_DRAM_SDBA2, 0x -- 2.34.1
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Fri, Nov 17, 2023 at 08:48:00AM -0600, Adam Ford wrote: > On Fri, Nov 17, 2023 at 8:41 AM Tom Rini wrote: > > > > On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > > > > > A new variant of the i.MX8MP System-on-module from Beacon is > > > available which contains 4GB of RAM vs 6GB. The memory > > > timings are slightly different, so a different config is necessary > > > to build the different timing file. > > > > > > Signed-off-by: Adam Ford > > > > Might this be a case for using config fragments instead? > > I didn't realize U-Boot was supporting that. I'll submit a V2 with > the defconfig option removed. Is there an example you can direct me > to that does this already? The beagleplay boards are currently handled via config fragments as well as a few asus platforms (grouper, transformer-t30). I just now noticed the latter places the fragments in a configs subdirectory which is nice I think when there's going to be a number of fragments, but not required. > > thanks! > > adam > > See doc/develop/board_best_practices.rst > > > > -- > > Tom -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Fri, Nov 17, 2023 at 8:41 AM Tom Rini wrote: > > On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > > > A new variant of the i.MX8MP System-on-module from Beacon is > > available which contains 4GB of RAM vs 6GB. The memory > > timings are slightly different, so a different config is necessary > > to build the different timing file. > > > > Signed-off-by: Adam Ford > > Might this be a case for using config fragments instead? I didn't realize U-Boot was supporting that. I'll submit a V2 with the defconfig option removed. Is there an example you can direct me to that does this already? thanks! adam > See doc/develop/board_best_practices.rst > > -- > Tom
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > A new variant of the i.MX8MP System-on-module from Beacon is > available which contains 4GB of RAM vs 6GB. The memory > timings are slightly different, so a different config is necessary > to build the different timing file. > > Signed-off-by: Adam Ford Might this be a case for using config fragments instead? See doc/develop/board_best_practices.rst -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file
Hello Andrew, All, Le 03/11/2023 à 20:20, Andrew Davis a écrit : > On 11/3/23 2:06 PM, Nishanth Menon wrote: >> On 13:51-20231103, Andrew Davis wrote: >>> On 11/2/23 7:38 PM, Nishanth Menon wrote: Add defconfig fragments for J721E based BeagleBone AI-64 and corresponding customized environment. Signed-off-by: Nishanth Menon --- board/ti/j721e/beagleboneai64.env | 19 board/ti/j721e/beagleboneai64_a72.config | 55 board/ti/j721e/beagleboneai64_r5.config | 19 >>> >>> Beagle boards are not TI boards, add the board support to board/beagle/ >> >> Huh, why bring in commercials and organization changes here? am335x >> and am62 are under the TI umbrella. >> > > The SoCs used are yes, the boards are not, we only make our EVM/SK > line of boards in house. > > We did AM335x wrong, in board/ti/am335x/board.c we tried to support > like 11 different boards in one file. And while it might have made adding > our own extra EVMs easier, it only made things less clear for folks trying > to add their own AM335x based boards[0]. > > We don't integrate support for any other board partner like this. Our > friends over at Toradex or Phytec are currently upstreaming boards based > on K3 SoCs and in doing so have shown us some areas we can improve. > > We focus on these little short-cuts to make adding our EVMs (or boards > that look like our EVMs) easy. But that only leads to extra work and > code duplication for external boards. > > If something is actually common to the SoC then lets move it to > arch/arm/mach-k3/j721e. Tricks like board-variants.c only hide the > issue and doesn't help folks wanting to add their boards based on our > SoCs to their board// directory. I'm starting a new custom board bring-up based on a j721e SoC (without any SOM) and adding a now board variant from the u-boot provided in the TI SDK (based on 2023.04) is far from easy for the reasons mentioned above (extra work and code duplication for external boards). Also the build break for j7200/j721e SoC as soon as CONFIG_TARGET_J721E_A72_EVM and CONFIG_TARGET_J7200_A72_EVM are undefined: https://source.denx.de/u-boot/u-boot/-/blob/v2023.10/arch/arm/mach-k3/arm64-mmu.c?ref_type=tags#L71 I always wonder if I should work on top of EVMs board or create a new board// directory for customer boards. Best regards, Romain > > Andrew > > [0] See "Software Design" https://jaycarlson.net/embedded-linux/#am335x > >> $ git grep beagle board/|cut -d ':' -f1|sort -u >> board/ti/am335x/board.c >> board/ti/am335x/board.h >> board/ti/am57xx/board.c >> board/ti/am62x/beagleplay_a53.config >> board/ti/am62x/beagleplay_r5.config >> board/ti/am62x/MAINTAINERS >> board/ti/beagle/beagle.c >> board/ti/beagle/Kconfig >> board/ti/beagle/led.c >> board/ti/beagle/MAINTAINERS >> board/ti/beagle/Makefile >> board/ti/j721e/beagleboneai64_a72.config >> board/ti/j721e/beagleboneai64_r5.config >> board/ti/j721e/MAINTAINERS >> board/timll/devkit8000/README >>
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Fri, Nov 17, 2023 at 09:17:27AM +0100, Stefano Babic wrote:
> Hi Tom, Marcel,
>
> On 16.11.23 19:42, Tom Rini wrote:
> > On Thu, Nov 16, 2023 at 10:57:27AM +, Marcel Ziswiler wrote:
> > > Hi Tom
> > >
> > > On Thu, 2023-11-02 at 08:09 +0100, Marcel Ziswiler wrote:
> > > > Hi Stefano
> > > >
> > > > On Thu, 2023-10-26 at 10:36 +0200, Stefano Babic wrote:
> > > > > On 26.10.23 10:29, Rasmus Villemoes wrote:
> > > > > > On 26/10/2023 09.32, Marcel Ziswiler wrote:
> > > > > > > From: Marcel Ziswiler
> > > > > > >
> > > > > > > This fixes a regression in the eMMC fast boot mode case where the
> > > > > > > buffer
> > > > > > > was missing 464 bytes.
> > > > > > >
> > > > > > > The code figures out how many bytes must at least be fetched to
> > > > > > > honor
> > > > > > > the current read, rounds that up to the ss->pagesize [which is a
> > > > > > > no-op
> > > > > > > in the USB download case because that has ->pagesize==1], fetches
> > > > > > > that
> > > > > > > many bytes, but then recorded the original upper bound as the new
> > > > > > > end of
> > > > > > > the valid data. However, this did not take into account the
> > > > > > > rounding up
> > > > > > > to the ss->pagesize. Fix this by recording the actual bytes
> > > > > > > downloaded.
> > > > > > >
> > > > > > > Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of
> > > > > > > spl_load_simple_fit() to get full FIT
> > > > > > > size")
> > > > > > > Signed-off-by: Marcel Ziswiler
> > > > > > >
> > > > > >
> > > > > > Thanks for reporting and fixing this, and sorry for the trouble.
> > > > > >
> > > > > > Acked-by: Rasmus Villemoes
> > > > > >
> > > > >
> > > > > And thanks for all your work - I will apply this fix soon.
> > > >
> > > > Any news on applying this fix? Note that master still stays broken as
> > > > of today.
> > >
> > > And two weeks later still broken!
> >
> > I've put this in my not to forget queue for the next -rc.
> >
> > > Anyway, I feel i.MX maintainership seems rather stalled at times most of
> > > the time. I don't want to criticise
> > > anybody knowing how busy our trade can get. However, if it helps the
> > > cause Toradex would be ready to step up.
> > > Let me know what you think. Thanks!
> >
> > I would be happy to see an additional custodian for the imx tree, if
> > that's agreeable with Stefano.
>
> I have rather less time for U-Boot and it won't be better in the near
> future. Fabio is co-maintainer and he has accepted to take over the
> repository and go on maintaining u-boot-imx. Just let him some time to be
> confident with patchwork and CI.
OK. Fabio, please send me your patchwork username off-list and I'll get
you added and you can start managing patches there. I've started using
some of the b4 + patchwork integration just recently and it's very nice.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200
On Fri, Nov 17, 2023 at 02:00:43PM +0530, Neha Malcom Francis wrote:
> Hi Tom
>
> On 17/11/23 00:10, Tom Rini wrote:
> > On Thu, Nov 16, 2023 at 11:43:50AM +0530, Neha Malcom Francis wrote:
> > > Hi Tom,
> > >
> > > Trying to bring back this series here.
> > >
> > > On 03/10/23 20:40, Tom Rini wrote:
> > > > On Tue, Oct 03, 2023 at 07:57:04PM +0530, Kumar, Udit wrote:
> > > > >
> > > > > On 10/3/2023 1:40 PM, Keerthy wrote:
> > > > > > Enable ESM initialization for J7200
> > > > > >
> > > > > > Signed-off-by: Keerthy
> > > > > > ---
> > > > > > board/ti/j721e/evm.c | 6 --
> > > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
> > > > > > index 42fa94b7a5..070b28326f 100644
> > > > > > --- a/board/ti/j721e/evm.c
> > > > > > +++ b/board/ti/j721e/evm.c
> > > > > > @@ -543,7 +543,8 @@ void spl_board_init(void)
> > > > > > }
> > > > > > #ifdef CONFIG_ESM_K3
> > > > > > - if (board_ti_k3_is("J721EX-PM2-SOM")) {
> > > > > > + if ((board_ti_k3_is("J721EX-PM2-SOM")) ||
> > > > > > + IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) {
> > > > >
> > > > >
> > > > > Could we align on one kind of check, For J721E check is done against
> > > > > board-id, whereas for J7200 checking
> > > >
> > > > We should look at figuring out how to split this file in two. One for
> > > > "generic J721E systems" and one for "TI EVMs", as I've mentioned in
> > > > other threads, so that it's easier for custom platforms to drop code
> > > > they don' require.
> > > >
> > >
> > > Yes that does make sense. Would it be okay if we solve that problem
> > > separately in a different patch series? We can move along with this
> > > current
> > > series for now (after making the required change in CONFIG/board-id for
> > > v2)
> > > since ESM support is important for these platforms.
> >
> > Well, I think part of the answer to your question is (and this is a more
> > general TI one too), what outstanding changes need to come in now to
> > make existing platforms functional for v2024.01 ? My first thought is
> > that this series would be taken to -next, if I took it now, which means
> > there's time before it would be in master, and so if it really makes the
> > re-org later easier, we could take it, but if not, can we re-org then do
> > this? But if we need this to deal with regressions, OK, yes, we can take
> > it like this now.
> >
>
> Maybe focusing on the re-org after having in the changes would help give
> more perspective on how we can split? Not sure just a thought... in that
> case I prefer taking this in and having a working error signaling module in
> rather than delaying it if that's okay.
OK, please rebase on top of whatever other series are needed (and note
so in the cover letter) and mark it as non-RFC, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Fri, Nov 17, 2023 at 03:49:57PM +0200, Eugen Hristev wrote: > On 11/17/23 15:46, Tom Rini wrote: > > On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: > > > On 11/17/23 15:40, Tom Rini wrote: > > > > On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: > > > > > > > > > Several AT91 boards are quite close to their SPL size limit. For > > > > > example, > > > > > sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and > > > > > doesn't > > > > > even fit with older GCCs. > > > > > > > > > > All AT91 processors should have thumb support. Enable > > > > > SYS_THUMB_BUILD. This > > > > > shrinks SPL by around 30%. > > > > > > > > > > [...] > > > > > > > > Applied to u-boot/next, thanks! > > > > > > > > > > so I'd assume that it would go through at91 tree. > > > > Ah, sorry. Since it was blocking two other series from coming in and you > > had gotten it tested I had assumed I could pull it to -next now to > > unblock that work. > > This is yet another time at91 patches get applied directly. Maybe you do not > really need an at91 maintainer ? U-Boot does not tend to have the strict sub-tree breakdown that the kernel does. Given what happened last time I was hoping that reaching out and then that you were able to have the changes tested would be sufficient for changes going to -next, rather than the current release. In future I will just wait for changes to come via the at91 tree, like I do for some other areas where the overall custodian prefers to have a more strict policy. Sorry. -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] treewide: use linux/time.h for time conversion defines
On Thu, Nov 09, 2023 at 08:10:04PM +0300, Igor Prusov wrote: > Now that we have time conversion defines from in time.h there is no need > for each driver to define their own version. > > Signed-off-by: Igor Prusov > Reviewed-by: Svyatoslav Ryhel # tegra > Reviewed-by: Eugen Hristev #at91 > Reviewed-by: Caleb Connolly #qcom geni > Reviewed-by: Stefan Bosch #nanopi2 > Reviewed-by: Patrice Chotard Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On 11/17/23 15:46, Tom Rini wrote: On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: On 11/17/23 15:40, Tom Rini wrote: On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: Several AT91 boards are quite close to their SPL size limit. For example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't even fit with older GCCs. All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This shrinks SPL by around 30%. [...] Applied to u-boot/next, thanks! so I'd assume that it would go through at91 tree. Ah, sorry. Since it was blocking two other series from coming in and you had gotten it tested I had assumed I could pull it to -next now to unblock that work. This is yet another time at91 patches get applied directly. Maybe you do not really need an at91 maintainer ?
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: > On 11/17/23 15:40, Tom Rini wrote: > > On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: > > > > > Several AT91 boards are quite close to their SPL size limit. For example, > > > sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't > > > even fit with older GCCs. > > > > > > All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. > > > This > > > shrinks SPL by around 30%. > > > > > > [...] > > > > Applied to u-boot/next, thanks! > > > > so I'd assume that it would go through at91 tree. Ah, sorry. Since it was blocking two other series from coming in and you had gotten it tested I had assumed I could pull it to -next now to unblock that work. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On 11/17/23 15:40, Tom Rini wrote: On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: Several AT91 boards are quite close to their SPL size limit. For example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't even fit with older GCCs. All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This shrinks SPL by around 30%. [...] Applied to u-boot/next, thanks! so I'd assume that it would go through at91 tree.
Re: [PATCH v2 2/2] cmd: bcb: extend BCB C API to allow read/write the fields
On Fri, Nov 10, 2023 at 05:59:55AM +, Dmitrii Merkurev wrote: > Currently BCB C API only allows to modify 'command' BCB field. > Extend it so that we can also read and modify all the available > BCB fields (command, status, recovery, stage). > > Co-developed-by: Cody Schuffelen > Signed-off-by: Cody Schuffelen > Signed-off-by: Dmitrii Merkurev > Cc: Eugeniu Rosca > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Cc: Mattijs Korpershoek > Cc: Sean Anderson > Cc: Cody Schuffelen > Tested-by: Mattijs Korpershoek # on vim3 > Reviewed-by: Mattijs Korpershoek Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] cmd: bcb: support various block device interfaces for BCB command
On Fri, Nov 10, 2023 at 05:59:54AM +, Dmitrii Merkurev wrote: > Currently BCB command-line, C APIs and implementation only > support MMC interface. Extend it to allow various block > device interfaces. > > Signed-off-by: Dmitrii Merkurev > Cc: Eugeniu Rosca > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Cc: Mattijs Korpershoek > Cc: Sean Anderson > Cc: Cody Schuffelen > Tested-by: Mattijs Korpershoek # on vim3 > Reviewed-by: Mattijs Korpershoek Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] poplar: provide more space for kernel image
On Thu, Nov 09, 2023 at 11:34:35PM +0100, Igor Opaniuk wrote: > Adjust mem layout, providing more space for linux kernel image. > > This fixes the problem: > ERROR: FDT image overlaps OS image (OS=0x3000..0x3258) > > Signed-off-by: Igor Opaniuk > Reviewed-by: Sam Protsenko Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/2] poplar: use random mac address
On Thu, Nov 09, 2023 at 11:34:34PM +0100, Igor Opaniuk wrote: > Set CONFIG_NET_RANDOM_ETHADDR=y, which sets random eth address in > case there is no configuration provided neither in CONFIG_ETHADDR > nor in "ethaddr" env variable. > > This fixes the problem: > poplar# dhcp > Error: ethernet@9841000 address not set. > > Signed-off-by: Igor Opaniuk > Reviewed-by: Sam Protsenko Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] linux/time.h: Add Linux time conversion defines
On Thu, Nov 09, 2023 at 08:10:02PM +0300, Igor Prusov wrote: > Currently there are no defines for time conversion in time.h, which > leads to drivers declaring those locally or not using defines at all, so > add them from Linux. > > Signed-off-by: Igor Prusov > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] spi: meson_spifc_a1: Use define for time interval
On Thu, Nov 09, 2023 at 08:10:03PM +0300, Igor Prusov wrote: > Use USEC_PER_MSEC define for timeout to sync code with Linux version. > > Signed-off-by: Igor Prusov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/2] dm: core: Correct reference to DM_SPL in SPL_DM_STATS
On Sun, Nov 12, 2023 at 01:03:46PM -0700, Simon Glass wrote: > This does not existing anymore. Update SPL_DM_STATS to use the correct > Kconfig option, which is SPL_DM > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] blk: Drop reference to DM_SPL
On Sun, Nov 12, 2023 at 01:03:47PM -0700, Simon Glass wrote: > The intent here is to only allow SPL_LEGACY_BLK if !SPL_DM - i.e. that > when driver model is enabled in SPL, legacy block cannot be used. > > However this combination is used by about 240 boards, so we cannot > disallow it, at least not yet. > > So just drop the condition. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: btrfs: fix reading when length specified
On Sat, Nov 11, 2023 at 08:19:04AM -0700, Sam Edwards wrote: > The btrfs read function limits the read length to ensure that it > and the read offset do not together exceed the size of the file. > However, this size was only being queried if the read length was > passed a value of zero (meaning "whole file"), and the size is > defaulted to 0 otherwise. This means the clamp will just zero out > the length if one is specified, preventing reading of the file. > > Fix this by checking the file size unconditionally, and unifying > the default length and clamping logic as a single range check instead. > > This bug was discovered when trying to boot Linux with initrd= via > 'bootefi' from a btrfs partition. The EFI stub entered an infinite > loop of zero-length reads while trying to read the initrd, and the > boot process stalled indefinitely. > > Signed-off-by: Sam Edwards > Reviewed-by: Qu Wenruo Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: ext4: Remove unused parameter from ext4_mount
On Wed, Nov 08, 2023 at 12:51:09PM -0500, Sean Anderson wrote: > The part_length parameter is not used. Remove it. > > Signed-off-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sysreset: Fix unsupported request return values
On Wed, Nov 08, 2023 at 08:51:10AM +, Paul Barker wrote: > The description of the sysreset request method in says that > the return value should be -EPROTONOSUPPORT if the requested reset type > is not supported by this device. > > Signed-off-by: Paul Barker > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test: eth: Don't crash if env_get returns NULL
On Sat, Oct 28, 2023 at 06:57:27PM -0400, Sean Anderson wrote:
> env_get can return NULL if it fails to find the variable. Check its result
> before using it.
>
> Fixes: 6d9764c2a87 ("dm: test: Add a new test case against dm eth codes for
> NULL pointer access")
> Fixes: df33fd28897 ("test: eth: Add test for ethernet addresses")
> Signed-off-by: Sean Anderson
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] bootm: Enable legacy VxWorks booting from FITs
On Fri, Oct 27, 2023 at 04:07:40PM -0400, Sean Anderson wrote: > This works without issue, so don't fail. > > Signed-off-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] powerpc: mpc8xx: Remove usage of common.h
On Mon, Nov 06, 2023 at 07:12:04PM +0100, Christophe Leroy wrote: > Remove inclusion of common.h and add relevant > includes when necessary. > > Signed-off-by: Christophe Leroy Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: cssi: Remove usage of common.h
On Mon, Nov 06, 2023 at 07:12:05PM +0100, Christophe Leroy wrote: > Remove inclusion of common.h and add relevant > includes when necessary. > > Signed-off-by: Christophe Leroy Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: enable LZ4 compression support
On Mon, Nov 06, 2023 at 11:14:03AM +0100, David Oberhollenzer wrote: > The structure is identical to the existing compressor implementations, > trivially adding lz4 decompression to sqfs_decompress. > > The changes were tested using a sandbox build. An LZ4 compressed > squashfs image was bound as a host block device. > > Signed-off-by: David Oberhollenzer > Reviewed-by: Joao Marcos Costa Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: remove unused declarations
On Mon, Nov 06, 2023 at 11:03:20AM +0100, David Oberhollenzer wrote: > This patch removes a number of struct and macro declaration that > were found through `git-grep` to be unused. Most of those are > related to compressor options and super block flags. > > For reading a SquashFS image, we do not need the compressor options > or the flags. Those only encode settings used for packing the image, > mksquashfs uses them when appending data to an existing image. The > kernel implementation does not touch those, and we don't need them > either. > > Signed-off-by: David Oberhollenzer Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
