Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case

2023-11-17 Thread Stefano Babic

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.


Thanks,
Stefano

--
=
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=



Re: [PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200

2023-11-17 Thread Neha Malcom Francis

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.


--
Thanking You
Neha Malcom Francis


Re: [PATCH v2] net: designware: Add bitbang feature for designware driver

2023-11-17 Thread Paul Barker
On Fri, Nov 17, 2023 at 10:04:53AM +0800, Jim Liu wrote:
> Add bb_miiphy_bus function for designware bitbang feature.
> 
> Signed-off-by: Jim Liu 
> ---
> Changes for v2:
>- add bitbang delay dts read
>- modify printf to debug
> ---
>  drivers/net/designware.c | 105 +++
>  drivers/net/designware.h |   5 ++
>  2 files changed, 110 insertions(+)
> 
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index a174344b3e..e86f96fc1a 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -767,6 +767,31 @@ int designware_eth_probe(struct udevice *dev)
>   priv->bus = miiphy_get_dev_by_name(dev->name);
>   priv->dev = dev;
>  
> +#if defined(CONFIG_BITBANGMII) && CONFIG_IS_ENABLED(DM_GPIO)
> + if (dev_read_bool(dev, "snps,bitbang-mii")) {
> + debug("\n%s: use bitbang mii..\n", dev->name);
> + ret = gpio_request_by_name(dev, "snps,mdc-gpio", 0,
> +&priv->mdc_gpio, GPIOD_IS_OUT | 
> GPIOD_IS_OUT_ACTIVE);
> + if (ret) {
> + printf("no mdc-gpio\n");
> + return ret;
> + }
> + ret = gpio_request_by_name(dev, "snps,mdio-gpio", 0,
> +&priv->mdio_gpio, GPIOD_IS_OUT | 
> GPIOD_IS_OUT_ACTIVE);
> + if (ret) {
> + printf("no mdio-gpio\n");
> + return ret;
> + }
> +
> + priv->bb_delay = dev_read_u32_default(dev, 
> "snps,bitbang-delay", 1);
> +
> + bb_miiphy_buses[0].priv = priv;
> + sprintf(bb_miiphy_buses[0].name, dev->name);

If designware_eth_probe() is called for multiple Ethernet interfaces
then only the last interface to be probed will have a working MDIO bus.

We should either support multiple buses here or raise an error if there
is an attempt to probe a second interface.

(I spotted the same issue in the ravb driver while extending it to
support a board with two Ethernet interfaces)

Thanks,
Paul


signature.asc
Description: PGP signature


RE: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Mihai.Sain
Hi Eugen,

I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, 
sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board.
I used the latest u-boot/master branch for this test.
I noticed that the file size of the binaries have beed reduced with aprox 
150KiB due to CONFIG_SYS_THUMB_BUILD=y.
After flashing the new binaries on these boards I can confirm that on all 
boards the linux kernel was booted properly from mmc, qspi-flash, nand-flash 
and usb.
I tested using bootm and bootz commands.

Best regards,
Mihai Sain



On 11/16/23 20:47, Tom Rini wrote:
> On Sat, Nov 04, 2023 at 10:27:42PM -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%.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>> This has been BUILD TESTED ONLY!
>
> We in turn need this for Sean's other cleanup series to go in. Is this 
> OK? Would it be safer if it was only for CPU_V7A ? I do have 
> recollections of thumb being sometimes buggy prior to v7a cores. Thanks!
>

Hi Tom,

I would like this to be tested on a few boards at least. There are boards with 
Cortex A5, A7 and ARM926 which are important, one of each of them and booting 
Linux should be enough I think.
Nicolas, Aubin ? I remember you guys have also a CI tool that is fairly easy to 
use if you just push a branch/commit.

+ Mihai as well.

Eugen


Re: [PATCH] bootstd: Avoid freeing a non-allocated buffer

2023-11-17 Thread Shantur Rathore
On Thu, Nov 16, 2023 at 1:35 AM 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 
Tested-by: Shantur Rathore 
> ---
>
>  boot/bootflow.c | 3 ++-
>  boot/bootmeth_efi.c | 1 +
>  include/bootflow.h  | 5 -
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/boot/bootflow.c b/boot/bootflow.c
> index 6922e7e0c4e7..1ea2966ae9a5 100644
> --- a/boot/bootflow.c
> +++ b/boot/bootflow.c
> @@ -467,7 +467,8 @@ void bootflow_free(struct bootflow *bflow)
> free(bflow->name);
> free(bflow->subdir);
> free(bflow->fname);
> -   free(bflow->buf);
> +   if (!(bflow->flags & BOOTFLOWF_STATIC_BUF))
> +   free(bflow->buf);
> free(bflow->os_name);
> free(bflow->fdt_fname);
> free(bflow->bootmeth_priv);
> diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> index ae936c8daa18..9ba7734911e1 100644
> --- a/boot/bootmeth_efi.c
> +++ b/boot/bootmeth_efi.c
> @@ -160,6 +160,7 @@ 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);
>
> diff --git a/include/bootflow.h b/include/bootflow.h
> index 44d3741eacae..fede8f22a2b8 100644
> --- a/include/bootflow.h
> +++ b/include/bootflow.h
> @@ -43,9 +43,12 @@ enum bootflow_state_t {
>   * and it is using the prior-stage FDT, which is the U-Boot control FDT.
>   * This is only possible with the EFI bootmeth (distro-efi) and only when
>   * CONFIG_OF_HAS_PRIOR_STAGE is enabled
> + * @BOOTFLOWF_STATIC_BUF: Indicates that @bflow->buf is statically set, 
> rather
> + * than being allocated by malloc().
>   */
>  enum bootflow_flags_t {
> BOOTFLOWF_USE_PRIOR_FDT = 1 << 0,
> +   BOOTFLOWF_STATIC_BUF= 1 << 1,
>  };
>
>  /**
> @@ -72,7 +75,7 @@ enum bootflow_flags_t {
>   * @fname: Filename of bootflow file (allocated)
>   * @logo: Logo to display for this bootflow (BMP format)
>   * @logo_size: Size of the logo in bytes
> - * @buf: Bootflow file contents (allocated)
> + * @buf: Bootflow file contents (allocated unless @flags & 
> BOOTFLOWF_STATIC_BUF)
>   * @size: Size of bootflow file in bytes
>   * @err: Error number received (0 if OK)
>   * @os_name: Name of the OS / distro being booted, or NULL if not known
> --
> 2.43.0.rc0.421.g78406f8d94-goog
>


Re: [PATCH v3 5/5] pmic: qcom: dont use dev_read_addr to get USID

2023-11-17 Thread Sumit Garg
On Tue, 14 Nov 2023 at 19:18, Caleb Connolly  wrote:
>
> Linux DTs stuff a value indicating if the USID is a USID or a GSID in the
> reg property, the Linux SPMI driver then reads the two address cells
> separately. U-boot's dev_read_addr() doesn't know how to handle this, so
> use ofnode_read_u32_index() to get just the USID.
>
> The Qcom pmic driver doesn't have support for GSID handling, so just
> ignore the second value for now.
>

Since you are trying to add Linux DT bindings compatibility here, I
suggest you drop custom u-boot binding here:
doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt.

-Sumit

> Signed-off-by: Caleb Connolly 
> ---
>  drivers/power/pmic/pmic_qcom.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/pmic/pmic_qcom.c b/drivers/power/pmic/pmic_qcom.c
> index ad8daf43f06f..f2ac6494811d 100644
> --- a/drivers/power/pmic/pmic_qcom.c
> +++ b/drivers/power/pmic/pmic_qcom.c
> @@ -66,12 +66,19 @@ static const struct udevice_id pmic_qcom_ids[] = {
>  static int pmic_qcom_probe(struct udevice *dev)
>  {
> struct pmic_qcom_priv *priv = dev_get_priv(dev);
> +   int ret;
>
> -   priv->usid = dev_read_addr(dev);
> -
> -   if (priv->usid == FDT_ADDR_T_NONE)
> +   /*
> +* dev_read_addr() can't be used here because the reg property 
> actually
> +* contains two discrete values, not a single 64-bit address.
> +* The address is the first value.
> +*/
> +   ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 0, &priv->usid);
> +   if (ret < 0)
> return -EINVAL;
>
> +   debug("usid: %d\n", priv->usid);
> +
> return 0;
>  }
>
>
> --
> 2.42.1
>


[PATCH V3] riscv: binman: fix the load field format

2023-11-17 Thread Randolph
Using /bits/ 64 prefix for 64 bits address

Signed-off-by: Randolph 
Reviewed-by: Simon Glass 
---
 arch/riscv/dts/binman.dtsi | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
index 6b4eb8dc7b..9271de0ddf 100644
--- a/arch/riscv/dts/binman.dtsi
+++ b/arch/riscv/dts/binman.dtsi
@@ -5,9 +5,6 @@
 
 #include 
 
-#define U64_TO_U32_H(addr) (((addr) >> 32) & 0x)
-#define U64_TO_U32_L(addr) ((addr) & 0x)
-
 / {
binman: binman {
multiple-images;
@@ -36,8 +33,7 @@
os = "U-Boot";
arch = "riscv";
compression = "none";
-   load = ;
+   load = /bits/ 64 ;
 
uboot_blob: blob-ext {
filename = "u-boot-nodtb.bin";
@@ -50,7 +46,7 @@
os = "Linux";
arch = "riscv";
compression = "none";
-   load = ;
+   load = /bits/ 64 ;
 
linux_blob: blob-ext {
filename = "Image";
@@ -64,10 +60,8 @@
os = "opensbi";
arch = "riscv";
compression = "none";
-   load = 
;
-   entry = 
;
+   load = /bits/ 64 
;
+   entry = /bits/ 64 
;
 
opensbi_blob: opensbi {
filename = "fw_dynamic.bin";
-- 
2.34.1



[PATCH v2 0/6] some LED patches

2023-11-17 Thread Rasmus Villemoes
I wanted to add support for ti,lp5562, and found an old submission
from Doug. While trying to modify that to work in current U-Boot, I
found a problem with the "move label handling to core" patches.

Patch 1 is a prerequisite for the ti,lp5562 driver, which turned out
to be needed by Christian as well.

Patch 2 is an attempt at (quick-)fixing the mentioned "move label
handling to core" problem. The real fix consists of changing remaining
drivers to not bind the same driver to the top node as to the child
nodes, but I can't test those other drivers.

Patch 3 introduces a helper which should allow removing some
boilerplate in most individual drivers, and 4,5 apply that in the gpio
and pwm drivers. Converting remaining drivers is trivial, but left out
for now.

Finally patch 6 is the reworked lp5562 driver. While I've changed it
to match existing DT bindings (with the goal of making it work with
our .dts that is known to work with the linux driver), most of the
logic is unchanged from Doug's original patch, so he is still listed
as author.

Changes in v2: Interchange order of patches 1 and 2, add a few R-bs,
and try to trim down the commit message in patch 2.

Doug Zobel (1):
  led: add TI LP5562 LED driver

Rasmus Villemoes (5):
  led-uclass: honour ->label field populated by driver's own .bind
  led-uclass: do not create fallback label for top-level node
  led: introduce led_bind_generic()
  led: led_gpio: use led_bind_generic() helper
  led: led_pwm: use led_bind_generic() helper

 doc/device-tree-bindings/leds/leds-lp5562.txt |  63 ++
 drivers/led/Kconfig   |   8 +
 drivers/led/Makefile  |   1 +
 drivers/led/led-uclass.c  |  22 +-
 drivers/led/led_gpio.c|  15 +-
 drivers/led/led_lp5562.c  | 578 ++
 drivers/led/led_pwm.c |  14 +-
 include/led.h |   8 +
 8 files changed, 681 insertions(+), 28 deletions(-)
 create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt
 create mode 100644 drivers/led/led_lp5562.c

-- 
2.40.1.1.g1c60b9335d



[PATCH v2 1/6] led-uclass: honour ->label field populated by driver's own .bind

2023-11-17 Thread Rasmus Villemoes
If the driver's own .bind method has populated uc_plat->label, don't
override that. This is necessary for an upcoming driver for ti,lp5562,
where the DT binding unfortunately says to use "chan-name" and not
"label".

Reviewed-by: Christian Gmeiner 
Reviewed-by: Marek Vasut 
Signed-off-by: Rasmus Villemoes 
---
 drivers/led/led-uclass.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 68ca3c29702..009f1080197 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
const char *default_state;
 
-   uc_plat->label = dev_read_string(dev, "label");
+   if (!uc_plat->label)
+   uc_plat->label = dev_read_string(dev, "label");
+
if (!uc_plat->label)
uc_plat->label = ofnode_get_name(dev_ofnode(dev));
 
-- 
2.40.1.1.g1c60b9335d



[PATCH v2 3/6] led: introduce led_bind_generic()

2023-11-17 Thread Rasmus Villemoes
All existing drivers in drivers/led/ contain a .bind method that does
exactly the same thing, with just the actual driver name
differing. Create a helper so all those individual methods can be
changed to one-liners.

Reviewed-by: Marek Vasut 
Signed-off-by: Rasmus Villemoes 
---
 drivers/led/led-uclass.c | 18 ++
 include/led.h|  8 
 2 files changed, 26 insertions(+)

diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 0232fa84def..a4be56fc258 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -11,9 +11,27 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+int led_bind_generic(struct udevice *parent, const char *driver_name)
+{
+   struct udevice *dev;
+   ofnode node;
+   int ret;
+
+   dev_for_each_subnode(node, parent) {
+   ret = device_bind_driver_to_node(parent, driver_name,
+ofnode_get_name(node),
+node, &dev);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 int led_get_by_label(const char *label, struct udevice **devp)
 {
struct udevice *dev;
diff --git a/include/led.h b/include/led.h
index 329041008c1..a6353166289 100644
--- a/include/led.h
+++ b/include/led.h
@@ -110,4 +110,12 @@ enum led_state_t led_get_state(struct udevice *dev);
  */
 int led_set_period(struct udevice *dev, int period_ms);
 
+/**
+ * led_bind_generic() - bind children of parent to given driver
+ *
+ * @parent:  Top-level LED device
+ * @driver_name: Driver for handling individual child nodes
+ */
+int led_bind_generic(struct udevice *parent, const char *driver_name);
+
 #endif
-- 
2.40.1.1.g1c60b9335d



[PATCH v2 4/6] led: led_gpio: use led_bind_generic() helper

2023-11-17 Thread Rasmus Villemoes
Use the helper led_bind_generic() to reduce code duplication.

Signed-off-by: Rasmus Villemoes 
---
 drivers/led/led_gpio.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index fbed151b5d9..71421de628c 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 
 struct led_gpio_priv {
struct gpio_desc gpio;
@@ -80,19 +79,7 @@ static int led_gpio_remove(struct udevice *dev)
 
 static int led_gpio_bind(struct udevice *parent)
 {
-   struct udevice *dev;
-   ofnode node;
-   int ret;
-
-   dev_for_each_subnode(node, parent) {
-   ret = device_bind_driver_to_node(parent, "gpio_led",
-ofnode_get_name(node),
-node, &dev);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
+   return led_bind_generic(parent, "gpio_led");
 }
 
 static const struct led_ops gpio_led_ops = {
-- 
2.40.1.1.g1c60b9335d



[PATCH v2 2/6] led-uclass: do not create fallback label for top-level node

2023-11-17 Thread Rasmus Villemoes
Many existing drivers, and led-uclass itself, rely on uc_plat->label
being NULL for the device representing the top node, as opposed to the
child nodes representing individual LEDs. This means that the drivers
whose .probe methods rely on this were broken by 83c63f0d1185 ("led:
Move OF "label" property parsing to core"), and also that the top node
wrongly shows up with 'led list'.

Binding the same driver to the top node as to the individual child
nodes is arguably wrong, and the approach of using a UCLASS_NOP driver
for the top node is probably better - this has for example been done
in commits 01074697801b and 910b01c27c04.

Until remaining affected drivers are fixed, we can use a heuristic
that only sets the label to the fallback value derived from the node
name if the node does not have a "compatible" property - i.e., if it
has been bound to the LED driver explicitly via
device_bind_driver_to_node(). This is similar to what e3aa76644c2a did
for gpio_led, but that fix was then supplanted by 01074697801b.

Fixes: 83c63f0d1185 ("led: Move OF "label" property parsing to core")
Signed-off-by: Rasmus Villemoes 
---
 drivers/led/led-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 009f1080197..0232fa84def 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -74,7 +74,7 @@ static int led_post_bind(struct udevice *dev)
if (!uc_plat->label)
uc_plat->label = dev_read_string(dev, "label");
 
-   if (!uc_plat->label)
+   if (!uc_plat->label && !dev_read_string(dev, "compatible"))
uc_plat->label = ofnode_get_name(dev_ofnode(dev));
 
uc_plat->default_state = LEDST_COUNT;
-- 
2.40.1.1.g1c60b9335d



[PATCH v2 6/6] led: add TI LP5562 LED driver

2023-11-17 Thread Rasmus Villemoes
From: Doug Zobel 

Driver for the TI LP5562 4 channel LED controller. Supports
independent on/off control of all 4 channels. Supports LED_BLINK on 3
independent channels: blue/green/red. The white channel can blink, but
shares the blue channel blink rate.

Heavily based on patch originally from Doug Zobel [1].

I have modified it so it matches the DT bindings in the linux tree,
and also follows the linux driver implementation more closely. This
should address Tom's concerns, and also matches my goal of making the
U-Boot driver work with our existing .dts which is known to work in
linux.

As our boards only have the R,G,B outputs connected, I have not
actually tested how the white channel behaves, but the R,G,B work
exactly as expected.

[1] 
https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/

Cc: Doug Zobel 
Signed-off-by: Rasmus Villemoes 
---
 doc/device-tree-bindings/leds/leds-lp5562.txt |  63 ++
 drivers/led/Kconfig   |   8 +
 drivers/led/Makefile  |   1 +
 drivers/led/led_lp5562.c  | 578 ++
 4 files changed, 650 insertions(+)
 create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt
 create mode 100644 drivers/led/led_lp5562.c

diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt 
b/doc/device-tree-bindings/leds/leds-lp5562.txt
new file mode 100644
index 000..4e0c742959a
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-lp5562.txt
@@ -0,0 +1,63 @@
+LEDs connected to TI LP5562 controller
+
+This driver works with a TI LP5562 4-channel LED controller.
+CONFIG_LED_BLINK is supported using the controller engines.  However
+there are only 3 engines available for the 4 channels.  This means
+that the blue and white channels share the same engine.  When both
+blue and white LEDs are set to blink, they will share the same blink
+rate.  Changing the blink rate of the blue LED will affect the white
+LED and vice-versa.  Manual on/off is handled independently for all 4
+channels.
+
+Required properties:
+  - compatible : should be "ti,lp5562".
+  - #address-cells : must be 1.
+  - #size-cells : must be 0.
+  - reg : LP5562 LED controller I2C address.
+
+Optional properties:
+  - enable-gpios : Enable GPIO
+  - clock-mode : u8, configures the clock mode:
+  - 0 # automode
+  - 1 # internal
+  - 2 # external
+
+Each LED is represented as a sub-node of the ti,lp5562 device.
+
+LED sub-node required properties:
+  - reg : Zero-based channel identifier:
+- 0 red
+- 1 green
+- 2 blue
+- 3 white
+
+LED sub-node optional properties:
+  - chan-name : name of LED
+  - max-cur : LED current at max brightness in 100uA steps (0x00 - 0xFF)
+Default : 100 (10 mA)
+
+Example:
+leds0: lp5562@30 {
+compatible = "ti,lp5562";
+#address-cells = <1>;
+#size-cells = <0>;
+enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
+reg = <0x30>;
+   clock-mode = /bits/8 <1>;
+
+led@0 {
+reg = <0>;
+chan-name = "red";
+max-cur = /bits/ 8 <200>; /* 20mA */
+};
+led@1 {
+reg = <1>;
+chan-name = "green";
+max-cur = /bits/ 8 <200>; /* 20mA */
+};
+led@2 {
+reg = <2>;
+chan-name = "blue";
+max-cur = /bits/ 8 <200>; /* 20mA */
+};
+};
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 996b757e6d0..9837960198d 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -49,6 +49,14 @@ config LED_CORTINA
  This option enables support for LEDs connected to the Cortina
  Access CA SOCs.
 
+config LED_LP5562
+   bool "LED Support for LP5562"
+   depends on LED && DM_I2C
+   help
+ This option enables support for LEDs connected to the TI LP5562
+ 4 channel I2C LED controller.  Driver fully supports blink on the
+ B/G/R LEDs.  White LED can blink, but re-uses the period from blue.
+
 config LED_PWM
bool "LED PWM"
depends on LED && DM_PWM
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 49ae91961d5..2bcb8589087 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
 obj-$(CONFIG_LED_PWM) += led_pwm.o
 obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
 obj-$(CONFIG_LED_CORTINA) += led_cortina.o
+obj-$(CONFIG_LED_LP5562) += led_lp5562.o
diff --git a/drivers/led/led_lp5562.c b/drivers/led/led_lp5562.c
new file mode 100644
index 000..87479ec5515
--- /dev/null
+++ b/drivers/led/led_lp5562.c
@@ -0,0 +1,578 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Doug Zobel 
+ *
+ * Driver for TI lp5562 4 

[PATCH v2 5/6] led: led_pwm: use led_bind_generic() helper

2023-11-17 Thread Rasmus Villemoes
Use the helper led_bind_generic() to reduce code duplication.

Signed-off-by: Rasmus Villemoes 
---
 drivers/led/led_pwm.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c
index 7c8eae9337b..ae6de3087ab 100644
--- a/drivers/led/led_pwm.c
+++ b/drivers/led/led_pwm.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define LEDS_PWM_DRIVER_NAME   "led_pwm"
@@ -136,18 +135,7 @@ static int led_pwm_of_to_plat(struct udevice *dev)
 
 static int led_pwm_bind(struct udevice *parent)
 {
-   struct udevice *dev;
-   ofnode node;
-   int ret;
-
-   dev_for_each_subnode(node, parent) {
-   ret = device_bind_driver_to_node(parent, LEDS_PWM_DRIVER_NAME,
-ofnode_get_name(node),
-node, &dev);
-   if (ret)
-   return ret;
-   }
-   return 0;
+   return led_bind_generic(parent, LEDS_PWM_DRIVER_NAME);
 }
 
 static const struct led_ops led_pwm_ops = {
-- 
2.40.1.1.g1c60b9335d



Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Eugen Hristev

On 11/17/23 11:15, mihai.s...@microchip.com wrote:

Hi Eugen,

I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, 
sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board.
I used the latest u-boot/master branch for this test.
I noticed that the file size of the binaries have beed reduced with aprox 
150KiB due to CONFIG_SYS_THUMB_BUILD=y.
After flashing the new binaries on these boards I can confirm that on all 
boards the linux kernel was booted properly from mmc, qspi-flash, nand-flash 
and usb.
I tested using bootm and bootz commands.


Thank you Mihai,

Tom, Sean, are you okay with this going in the next merge window ?
It is definitely not a fix, so that would be the best.

Eugen



Best regards,
Mihai Sain



On 11/16/23 20:47, Tom Rini wrote:

On Sat, Nov 04, 2023 at 10:27:42PM -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%.

Signed-off-by: Sean Anderson 
---
This has been BUILD TESTED ONLY!


We in turn need this for Sean's other cleanup series to go in. Is this
OK? Would it be safer if it was only for CPU_V7A ? I do have
recollections of thumb being sometimes buggy prior to v7a cores. Thanks!



Hi Tom,

I would like this to be tested on a few boards at least. There are boards with 
Cortex A5, A7 and ARM926 which are important, one of each of them and booting 
Linux should be enough I think.
Nicolas, Aubin ? I remember you guys have also a CI tool that is fairly easy to 
use if you just push a branch/commit.

+ Mihai as well.

Eugen




[PATCH] sbp1: Add support for IBM SBP1 board

2023-11-17 Thread Naresh Solanki
From: Patrick Rudolph 

Add defconfig & devicetree for IBM SBP1 board BMC based on AST2600 SoC.

Signed-off-by: Patrick Rudolph 
Signed-off-by: Naresh Solanki 
---

 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/ast2600-sbp1.dts |  96 ++
 configs/ibm-sbp1_defconfig| 126 ++
 3 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/ast2600-sbp1.dts
 create mode 100644 configs/ibm-sbp1_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc..85514fb8ba 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1353,7 +1353,9 @@ dtb-$(CONFIG_BCM6878) += \
bcm96878.dtb
 
 dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
-dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
+dtb-$(CONFIG_ASPEED_AST2600) += \
+   ast2600-evb.dtb \
+   ast2600-sbp1.dtb
 
 dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
 
diff --git a/arch/arm/dts/ast2600-sbp1.dts b/arch/arm/dts/ast2600-sbp1.dts
new file mode 100644
index 00..5c862e2c1c
--- /dev/null
+++ b/arch/arm/dts/ast2600-sbp1.dts
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+#include 
+#include "ast2600-evb.dts"
+
+/ {
+   model = "IBM SBP1";
+   compatible = "ibm,sbp1-bmc", "aspeed,ast2600";
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>;
+   };
+
+   chosen {
+   stdout-path = &uart1;
+   };
+
+   aliases {
+   mmc0 = &emmc;
+   mmc1 = &sdhci0;
+   mmc2 = &sdhci1;
+   ethernet0 = &mac2;
+   ethernet1 = &mac3;
+   };
+
+   cpus {
+   cpu@0 {
+   clock-frequency = <12>;
+   };
+   cpu@1 {
+   clock-frequency = <12>;
+   };
+   };
+
+};
+
+&uart1 {
+   bootph-all;
+   status = "okay";
+};
+
+&uart5 {
+   status = "disabled";
+};
+
+&mdio {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_mdio3_default &pinctrl_mdio4_default>;
+};
+
+&mac0 {
+   status = "disabled";
+};
+
+&mac1 {
+   status = "disabled";
+};
+
+&gpio0 {
+   status = "okay";
+   line_50 {
+   gpio-hog;
+   gpios = <50 GPIO_ACTIVE_LOW>;
+   output-low;
+   line-name = "BMC_MAC1_RESET_N";
+   };
+   line_175 {
+   gpio-hog;
+   gpios = <175 GPIO_ACTIVE_LOW>;
+   output-low;
+   line-name = "BMC_MAC0_RESET_N";
+   };
+};
+
+&spi1 {
+   status = "disabled";
+};
+
+&spi2 {
+   status = "disabled";
+};
+
+&emmc {
+   status = "disabled";
+};
+
+&sdhci0 {
+   status = "disabled";
+};
+
+&sdhci1 {
+   status = "disabled";
+};
diff --git a/configs/ibm-sbp1_defconfig b/configs/ibm-sbp1_defconfig
new file mode 100644
index 00..cf667217cc
--- /dev/null
+++ b/configs/ibm-sbp1_defconfig
@@ -0,0 +1,126 @@
+CONFIG_ARM=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_SPL_SYS_THUMB_BUILD=y
+CONFIG_ARCH_ASPEED=y
+CONFIG_TEXT_BASE=0x8000
+CONFIG_SYS_MALLOC_LEN=0x200
+CONFIG_SYS_MALLOC_F_LEN=0x800
+CONFIG_ASPEED_AST2600=y
+CONFIG_TARGET_EVB_AST2600=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds"
+CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_OFFSET=0xe
+CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="ast2600-sbp1"
+CONFIG_DM_RESET=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8300
+CONFIG_SPL_SIZE_LIMIT=0x1
+CONFIG_SPL=y
+# CONFIG_ARMV7_NONSEC is not set
+CONFIG_SYS_LOAD_ADDR=0x8300
+CONFIG_SPL_PAYLOAD="u-boot.img"
+CONFIG_BUILD_TARGET="u-boot-with-spl.bin"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_FIT=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x1
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200n8 root=/dev/ram rw earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run bootspi"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x8300
+CONFIG_SPL_BSS_MAX_SIZE=0x100
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_CBSIZE=256
+CONFIG_SYS_PBSIZE=276
+CONFIG_CMD_BOOTZ=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+CONFIG_CMD_EEPROM=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=

Re: [PATCH v4 00/16] Introduce initial TI's J784S4 and AM69 support

2023-11-17 Thread Bryan Brattlof
On November 17, 2023 thus sayeth Kumar, Udit:
> > On Wed, Nov 15, 2023 at 2:54 PM Maxime Ripard  
> > wrote:
> > > On Sun, Oct 01, 2023 at 10:25:29PM +0530, Apurva Nandan wrote:
> > >

...

> > > 
> > > SoC:   J784S4 SR1.0 HS-FS
> > > Model: Texas Instruments J784S4 EVM
> > Maybe something changed but I'm surprised about it reporting an EVM
> > board. I was expecting something like
> > 
> > Model: Texas Instruments AM69 SK
> > Board: AM69-SK rev E2
> > 
> > Did you use the am69_sk_a72/r5  defconfigs?
> 
> Please apply AM69 config fragment
> 
> https://lore.kernel.org/all/20231001165545.494212-16-a-nan...@ti.com/
> 
> make ARCH=arm j784s4_evm_a72_defconfig am69_sk_a72.config
> make ARCH=arm
> 
> OR
> 
> make ARCH=arm j784s4_evm_r5_defconfig am69_sk_r5.config
> make ARCH=arm
    

Just a heads up, adding the ARCH variable isn't really needed and I've 
heard of this causing problems for others :)

~Bryan


Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Tom Rini
On Fri, Nov 17, 2023 at 01:58:35PM +0200, Eugen Hristev wrote:
> On 11/17/23 11:15, mihai.s...@microchip.com wrote:
> > Hi Eugen,
> > 
> > I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, 
> > sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board.
> > I used the latest u-boot/master branch for this test.
> > I noticed that the file size of the binaries have beed reduced with aprox 
> > 150KiB due to CONFIG_SYS_THUMB_BUILD=y.
> > After flashing the new binaries on these boards I can confirm that on all 
> > boards the linux kernel was booted properly from mmc, qspi-flash, 
> > nand-flash and usb.
> > I tested using bootm and bootz commands.
> 
> Thank you Mihai,
> 
> Tom, Sean, are you okay with this going in the next merge window ?
> It is definitely not a fix, so that would be the best.

Thanks. I was looking at this for a series to go in to -next at this
point, so v2024.04 release.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 00/15] nand: Add sandbox tests

2023-11-17 Thread Tom Rini
On Sat, 04 Nov 2023 16:37:38 -0400, Sean Anderson wrote:

> This series tests raw nand flash in sandbox and fixes various bugs discovered 
> in
> the process. I've tried to do things in a contemporary manner, avoiding the
> (numerous) variations present on only a few boards. The test is pretty 
> minimal.
> Future work could test the rest of the nand API as well as the MTD API.
> 
> Bloat (for v1) at [1] (for boards with SPL_NAND_SUPPORT enabled). Almost
> everything grows by a few bytes due to nand_page_size. A few boards grow more,
> mostly those using nand_spl_loaders.c. CI at [2].
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Tom Rini
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!

-- 
Tom




Re: [PATCH v7 00/26] spl: Use common function for loading/parsing images

2023-11-17 Thread Tom Rini
On Wed, 08 Nov 2023 11:48:32 -0500, Sean Anderson wrote:

> This series adds support for loading all image types (Legacy (with and without
> LZMA), FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR,
> NET, FAT, EXT, NVMe, and semihosting load methods. It does this by 
> introducing a
> helper function which handles the minutiae of invoking the proper parsing
> function, and reading the rest of the image.
> 
> Hopefully, this will make it easier for load methods to support all image 
> types
> that U-Boot supports, without having undocumented unsupported image types. I
> applied this to several loaders which were invoking spl_load_simple_fit and/or
> spl_parse_image_header, but I did not use it with others (e.g. DFU/RAM) which
> had complications in the mix.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom




Re: [PATCH] fs/squashfs: remove unused declarations

2023-11-17 Thread Tom Rini
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


Re: [PATCH] fs/squashfs: enable LZ4 compression support

2023-11-17 Thread Tom Rini
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] board: cssi: Remove usage of common.h

2023-11-17 Thread Tom Rini
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] powerpc: mpc8xx: Remove usage of common.h

2023-11-17 Thread Tom Rini
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] bootm: Enable legacy VxWorks booting from FITs

2023-11-17 Thread Tom Rini
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] test: eth: Don't crash if env_get returns NULL

2023-11-17 Thread Tom Rini
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] sysreset: Fix unsupported request return values

2023-11-17 Thread Tom Rini
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] fs: ext4: Remove unused parameter from ext4_mount

2023-11-17 Thread Tom Rini
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] fs: btrfs: fix reading when length specified

2023-11-17 Thread Tom Rini
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 v3 2/2] blk: Drop reference to DM_SPL

2023-11-17 Thread Tom Rini
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 v3 1/2] dm: core: Correct reference to DM_SPL in SPL_DM_STATS

2023-11-17 Thread Tom Rini
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 2/3] spi: meson_spifc_a1: Use define for time interval

2023-11-17 Thread Tom Rini
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 1/3] linux/time.h: Add Linux time conversion defines

2023-11-17 Thread Tom Rini
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 v1 1/2] poplar: use random mac address

2023-11-17 Thread Tom Rini
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 v1 2/2] poplar: provide more space for kernel image

2023-11-17 Thread Tom Rini
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 v2 1/2] cmd: bcb: support various block device interfaces for BCB command

2023-11-17 Thread Tom Rini
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 v2 2/2] cmd: bcb: extend BCB C API to allow read/write the fields

2023-11-17 Thread Tom Rini
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] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Eugen Hristev

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] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Tom Rini
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

2023-11-17 Thread Eugen Hristev

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 3/3] treewide: use linux/time.h for time conversion defines

2023-11-17 Thread Tom Rini
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

2023-11-17 Thread Tom Rini
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 RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200

2023-11-17 Thread Tom Rini
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 v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case

2023-11-17 Thread Tom Rini
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 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file

2023-11-17 Thread Romain Naour
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] arm64: imx: imx8mp-beacon: Add support for 4GB Variant

2023-11-17 Thread Tom Rini
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] arm64: imx: imx8mp-beacon: Add support for 4GB Variant

2023-11-17 Thread Adam Ford
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

2023-11-17 Thread Tom Rini
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


[PATCH] tqma6: Fix DDR configuration

2023-11-17 Thread Miquel Raynal
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: bootstd: Support for distro specific EFI folders

2023-11-17 Thread Heinrich Schuchardt

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


Re: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU

2023-11-17 Thread Heinrich Schuchardt

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: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU

2023-11-17 Thread Tom Rini
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


[PATCH] boards: Disable NET on platforms without NETDEVICES

2023-11-17 Thread Tom Rini
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
 CONFIG_SYS_RELOC_GD_EN

Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case

2023-11-17 Thread Fabio Estevam
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


Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case

2023-11-17 Thread Tom Rini
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 1/4] rockchip: rk3588: Fix boot from SPI flash

2023-11-17 Thread Slawomir Stepien
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


[PATCH 1/2] board: st: common: Fix board_get_alt_info_mtd()

2023-11-17 Thread Patrice Chotard
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, &mtd->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



[PATCH 2/2] board: st: common: simplify MTD device parsing

2023-11-17 Thread Patrice Chotard
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, &dev)) {
-   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



Re: [PATCH v2 06/32] bootstd: Introduce programmable boot

2023-11-17 Thread Tom Rini
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


Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash

2023-11-17 Thread Tom Rini
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 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file

2023-11-17 Thread Andrew Davis

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

2023-11-17 Thread John Clark



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 1/4] rockchip: rk3588: Fix boot from SPI flash

2023-11-17 Thread Tom Rini
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 0/3] Revert HAFDBS changes

2023-11-17 Thread Tom Rini
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 v1 1/2] imx: spl_imx_romapi: fix comment about stream(usb) download failure

2023-11-17 Thread Tom Rini
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 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"

2023-11-17 Thread Tom Rini
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 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"

2023-11-17 Thread Tom Rini
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 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"

2023-11-17 Thread Tom Rini
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 v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case

2023-11-17 Thread Tom Rini
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] virtio: rng: gracefully handle 0 byte returns

2023-11-17 Thread Tom Rini
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] spl: fix TPL_SYS_MALLOC_F description

2023-11-17 Thread Tom Rini
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] bootstd: Avoid freeing a non-allocated buffer

2023-11-17 Thread Tom Rini
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 1/4] rockchip: rk3588: Fix boot from SPI flash

2023-11-17 Thread Jonas Karlman
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 1/4] rockchip: rk3588: Fix boot from SPI flash

2023-11-17 Thread Tom Rini
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 

[PATCH V2 1/4] board: rockchip: Refactor panel auto-detect code

2023-11-17 Thread Chris Morgan
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) | panel_

[PATCH V2 0/4] Add Additional Boards and Features to RGxx3

2023-11-17 Thread Chris Morgan
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 3/4] board: rockchip: Add support for RGB30 and RK2023 to RGxx3

2023-11-17 Thread Chris Morgan
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 2/4] board: rockchip: Add Recovery Button for Anbernic RGxx3

2023-11-17 Thread Chris Morgan
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 4/4] doc: board: anbernic: Update rgxx3 to add new boards

2023-11-17 Thread Chris Morgan
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 0/4] bootflow: bootmeth_efi: Fix network eif boot.

2023-11-17 Thread Shantur Rathore
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 1/4] bootflow: bootmeth_efi: Set bootp_arch as hex

2023-11-17 Thread Shantur Rathore
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 2/4] bootflow: bootmeth_efi: Don't set bootdev again

2023-11-17 Thread Shantur Rathore
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 3/4] bootflow: bootmeth_efi: Handle fdt not available.

2023-11-17 Thread Shantur Rathore
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 4/4] bootflow: bootmeth_efi: don't free buffer

2023-11-17 Thread Shantur Rathore
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 v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID

2023-11-17 Thread seanedmond
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->bp_id, &bootp_id);
-   } else {
-   net_copy_u32(&bp->bp_id, &bootp_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->bp_id, &bootp_id);
/*
 * Calculate proper packet lengths taking into account the
 * variable size of the options field
-- 
2.42.0



[PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements

2023-11-17 Thread seanedmond
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 1/3] net: Additional fixes for dhcp option 209

2023-11-17 Thread seanedmond
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 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements

2023-11-17 Thread seanedmond
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 CONFIG

Re: [PATCH v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID

2023-11-17 Thread Tom Rini
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


Re: [PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements

2023-11-17 Thread Tom Rini
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


[PATCH 1/3] configs: keystone2: Remove unused SPL_MALLOC_F_SIZE and KEYSTONE_SPL_STACK_SIZE

2023-11-17 Thread Andrew Davis
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



[PATCH 2/3] configs: keystone2: Do not include hardware.h

2023-11-17 Thread Andrew Davis
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 3/3] ARM: keystone2: Remove unneeded inclusions of common.h

2023-11-17 Thread Andrew Davis
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



Re: [PATCH 2/3] configs: keystone2: Do not include hardware.h

2023-11-17 Thread Tom Rini
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 1/2] global: Clean up arch/*/dts/Makefile

2023-11-17 Thread Tom Rini
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) += \
-  

[PATCH 2/2] doc: Update board_best_practices.rst to talk about dts files

2023-11-17 Thread Tom Rini
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 2/5] arc: Cleanup and audit usage of

2023-11-17 Thread Tom Rini
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 1/5] qe: Add to linux/immap_qe.h

2023-11-17 Thread Tom Rini
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 3/5] arm: Partial cleanup and audit usage of

2023-11-17 Thread Tom Rini
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 Define

  1   2   >