Re: [PATCH v3 03/20] drivers: reset: Handle gracefully NULL pointers

[Kishon Vijay Abraham I]

Hi Simon,

On 04/05/21 10:28 pm, Simon Glass wrote:
> Hi Kishon,
> 
> On Tue, 4 May 2021 at 04:42, Kishon Vijay Abraham I  wrote:
>>
>> The reset framework provides devm_reset_control_get_optional()
>> which can return NULL (not an error case). So all the other reset_ops
>> should handle NULL gracefully. Prepare the way for a managed reset
>> API by handling NULL pointers without crashing nor failing.
>>
>> Signed-off-by: Vignesh Raghavendra 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/reset/reset-uclass.c | 35 ++-
>>  1 file changed, 30 insertions(+), 5 deletions(-)
> 
> I am still not a fan of this. There is no way to know whether the
> reset API call actually did anything. Normally we return -EINVAL or
> something like that when the value is invalid (e.g. see GPIO uclass).

The reset modification is more in-line with how clk uclass is designed.

There every API first checks if the clock is valid and returns 0 (will
be the case for optional clocks)
   if (!clk_valid(clk))
return 0;

If you don't prefer this approach, I'll drop this patch and handle it
appropriately in the client driver (serdes driver). Please let me know.

> 
> The function you mention says:  * Returns a struct reset_ctl or a
> dummy reset controller if it failed.
> 
> But it does not appear to do that?

Right, looks like it's incorrect from when the patch was actually
introduced. It was returning "NULL" for optional resets.

commit 139e4a1cbe60de96d4febbc6db5882929801ca46
Author: Jean-Jacques Hiblot 
Date:   Wed Sep 9 15:37:03 2020 +0530

drivers: reset: Add a managed API to get reset controllers from the DT

Thanks
Kishon

Re: [PATCH v7 2/8] drivers: clk: add fu740 support

[Green Wan]

Thanks, I'll check the dependency.

On Tue, May 4, 2021 at 5:54 PM Dimitri John Ledkov
 wrote:
>
> "Hi,
>
> On Thu, Apr 22, 2021 at 10:15 AM Green Wan  wrote:
> >
> > Add fu740 support. One abstract layer is added for supporting
> > multiple chips such as fu540 and fu740.
> >
> > Signed-off-by: Green Wan 
> > ---
> >  drivers/clk/sifive/Kconfig   |   8 +-
> >  drivers/clk/sifive/Makefile  |   4 +-
> >  drivers/clk/sifive/fu540-prci.c  | 769 +--
> >  drivers/clk/sifive/fu540-prci.h  |  22 +
> >  drivers/clk/sifive/fu740-prci.c  | 158 +++
> >  drivers/clk/sifive/fu740-prci.h  |  22 +
> >  drivers/clk/sifive/sifive-prci.c | 733 +
> >  drivers/clk/sifive/sifive-prci.h | 323 +
> >  8 files changed, 1286 insertions(+), 753 deletions(-)
> >  create mode 100644 drivers/clk/sifive/fu540-prci.h
> >  create mode 100644 drivers/clk/sifive/fu740-prci.c
> >  create mode 100644 drivers/clk/sifive/fu740-prci.h
> >  create mode 100644 drivers/clk/sifive/sifive-prci.c
> >  create mode 100644 drivers/clk/sifive/sifive-prci.h
> >
> > diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> > index c4d0a1f9b1..20fc004b59 100644
> > --- a/drivers/clk/sifive/Kconfig
> > +++ b/drivers/clk/sifive/Kconfig
> > @@ -6,11 +6,11 @@ config CLK_SIFIVE
> > help
> >   SoC drivers for SiFive Linux-capable SoCs.
> >
> > -config CLK_SIFIVE_FU540_PRCI
> > -   bool "PRCI driver for SiFive FU540 SoCs"
> > +config CLK_SIFIVE_PRCI
> > +   bool "PRCI driver for SiFive SoCs"
> > depends on CLK_SIFIVE
>
> Since the above is done in this patch, I would expect to remove all
> references to the CLK_SIFIVE_FU540_PRCI config option at the same
> time. Specifically:
>
> $ git grep CLK_SIFIVE_FU540_PRCI
> arch/riscv/cpu/fu540/Kconfig:   imply CLK_SIFIVE_FU540_PRCI
> drivers/reset/Kconfig:  depends on DM_RESET && CLK_SIFIVE_FU540_PRCI
> && TARGET_SIFIVE_UNLEASHED
>
> If above references were fixed, it remove the need to manually add
> "CONFIG_CLK_SIFIVE_PRCI=y" to unleashed config in the "board: sifive:
> add HiFive Unmatched board support" patch.
>
> Leaving left over references to the removed config options is
> confusing, and makes the patch not self contained.
>
>
> > select CLK_ANALOGBITS_WRPLL_CLN28HPC
> > help
> >   Supports the Power Reset Clock interface (PRCI) IP block found in
> > - FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
> > - enable this driver.
> > + FU540/FU740 SoCs. If this kernel is meant to run on a SiFive 
> > FU540/
> > + FU740 SoCs, enable this driver.
> > diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
> > index b224279afb..51348b1ddc 100644
> > --- a/drivers/clk/sifive/Makefile
> > +++ b/drivers/clk/sifive/Makefile
> > @@ -1,3 +1,5 @@
> >  # SPDX-License-Identifier: GPL-2.0+
> >
> > -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
> > +obj-y += sifive-prci.o
> > +
> > +obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o fu740-prci.o
> > diff --git a/drivers/clk/sifive/fu540-prci.c 
> > b/drivers/clk/sifive/fu540-prci.c
> > index b3882d0b77..ceb2c6fab0 100644
> > --- a/drivers/clk/sifive/fu540-prci.c
> > +++ b/drivers/clk/sifive/fu540-prci.c
> > @@ -5,6 +5,8 @@
> >   * Copyright (C) 2018 SiFive, Inc.
> >   * Wesley Terpstra
> >   * Paul Walmsley
> > + * Zong Li
> > + * Pragnesh Patel
> >   *
> >   * This program is free software; you can redistribute it and/or modify
> >   * it under the terms of the GNU General Public License version 2 as
> > @@ -15,632 +17,48 @@
> >   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >   * GNU General Public License for more details.
> >   *
> > - * The FU540 PRCI implements clock and reset control for the SiFive
> > - * FU540-C000 chip.   This driver assumes that it has sole control
> > - * over all PRCI resources.
> > - *
> > - * This driver is based on the PRCI driver written by Wesley Terpstra.
> > - *
> > - * Refer, commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
> > - * https://github.com/riscv/riscv-linux
> > - *
> >   * References:
> >   * - SiFive FU540-C000 manual v1p0, Chapter 7 "Clocking and Reset"
> >   */
> >
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> >  #include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -
> > -/*
> > - * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
> > - * hfclk and rtcclk
> > - */
> > -#define EXPECTED_CLK_PARENT_COUNT  2
> > -
> > -/*
> > - * Register offsets and bitmasks
> > - */
> > -
> > -/* COREPLLCFG0 */
> > -#define PRCI_COREPLLCFG0_OFFSET0x4
> > -#define PRCI_COREPLLCFG0_DIVR_SHIFT0
> > -#define PRCI_COREPLLCFG0_DIVR_MASK (0x3f << 
> > PRCI_COREPLLCFG0_DIVR_SHIFT)
> > 

Re: [PATCH v7 8/8] drivers: net: macb: add fu740 support

[Green Wan]

Hi Dimitri,

Thanks for looking into this.

On Tue, May 4, 2021 at 5:33 PM Dimitri John Ledkov
 wrote:
>
> Hi,
>
> On Thu, Apr 22, 2021 at 10:15 AM Green Wan  wrote:
> >
> > From: David Abdurachmanov 
> >
> > Add fu740 support to macb ethernet driver
> >
> > There is a PLL HW quirk in FU740. The VSC8541XMV-02 specification
> > requires 125 +/-0.0125 Mhz. But the most close value can be output
> > by PLL is 125.125 MHz and out of VSC8541XMV-02 spec.
> >
>
> In the Linux kernel driver for this
> drivers/net/ethernet/cadence/macb_main.c it is not marked as
> compatible with "sifive,fu740-c000-gem" and it does not have a similar
> fix (and appears to use 125.0 MHz).
> Should a similar fix be contributed to the Linux kernel?

You're right. We also notice some refinement should be made here.
We're working on the way to solve it.

>
> As otherwise at the moment, one cannot pass the dtb from u-boot to
> linux, as that leads to loss of network since the kernel doesn't know
> about "sifive,fu740-c000-gem". If linux kernel contribution is not
> forthcoming, would it be possible to have u-boot dtb to be compatible
> with _both_  "sifive,fu540-c000-gem" and "sifive,fu740-c000-gem" on
> unmatched boards, such that if one (mistakenly) uses u-boots dtb with
> vanilla linux kernel networking still works? And then adjust the test
> to check for "sifive,fu740-c000-gem" compatible string first.
>

Not sure whether I get it correct. I think the best case is to have
Linux driver support both compatible string. And I'm a bit reluctant
to handle incorrect DTB passed situations. It might end up with
propagating issues and harder to trace back the root cause. I'll check
with colleagues and see if we can resolve that concern.

Thanks,

> > Signed-off-by: David Abdurachmanov 
> > Signed-off-by: Green Wan 
> > Reviewed-by: Ramon Fried 
> > Reviewed-by: Bin Meng 
> > ---
> >  drivers/net/macb.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index 57ea45e2dc..bf70525c54 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -591,8 +591,17 @@ static int macb_sifive_clk_init(struct udevice *dev, 
> > ulong rate)
> >  * 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
> >  * and output clock on GMII output signal GTX_CLK
> >  * 1 = MII mode. Use MII input signal TX_CLK in TX logic
> > +*
> > +* FU740 have a PLL HW quirk. The 125.125 Mhz is actually out of
> > +* VSC8541XMV-02 specification. The tolerance level is +/-100ppm.
> > +* Which means the range should be in between 125MHz +/-0.0125.
> > +* But the most close value can be output by PLL is 125.125 MHz.
> >  */
> > -   writel(rate != 12500, gemgxl_regs);
> > +   if (device_is_compatible(dev, "sifive,fu540-c000-gem"))
> > +   writel(rate != 12500, gemgxl_regs);
> > +   else if (device_is_compatible(dev, "sifive,fu740-c000-gem"))
> > +   writel(rate != 125125000, gemgxl_regs);
> > +
> > return 0;
> >  }
> >
> > @@ -1507,6 +1516,8 @@ static const struct udevice_id macb_eth_ids[] = {
> > { .compatible = "cdns,zynq-gem" },
> > { .compatible = "sifive,fu540-c000-gem",
> >   .data = (ulong)_config },
> > +   { .compatible = "sifive,fu740-c000-gem",
> > + .data = (ulong)_config },
> > { .compatible = "microchip,mpfs-mss-gem",
> >   .data = (ulong)_config },
> > { }
> > --
> > 2.31.0
> >
>
>
> --
> Regards,
>
> Dimitri.

Re: [RFC 1/2] net: net_up, net_down

[Ramon Fried]

On Mon, May 3, 2021 at 2:55 PM Ian Ray  wrote:
>
> Calls made to eth_halt() by network operations (ping, nfs, tftp, etc.)
> break netconsole if it is already running.
>
> * Maintain the network up / down state based on a reference count,
>   using new APIs net_up() and net_down().
>
> Note that when network is brought up by netconsole client, then network
> will remain up until reboot (because there is no way to stop netconsole
> itself).
>
> * Remove net_loop_last_protocol, eth_is_on_demand_init(), and
>   eth_set_last_protocol().  This functionality is replaced by
>   net_up() / net_down().
>
> * Replace usage of eth_init(), eth_halt() with net_up() and
>   net_down() in net.c, ping.c, tftp.c, and netconsole.c.
>
> Signed-off-by: Ian Ray 
> ---
>  drivers/net/netconsole.c | 26 +++--
>  include/net.h| 23 ++-
>  net/net.c| 75 
> +---
>  net/ping.c   |  1 -
>  net/tftp.c   |  4 ---
>  net/wol.c|  1 -
>  6 files changed, 59 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index f1d0630..b6d2e22 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -27,11 +27,6 @@ static short nc_out_port; /* target output port */
>  static short nc_in_port; /* source input port */
>  static const char *output_packet; /* used by first send udp */
>  static int output_packet_len;
> -/*
> - * Start with a default last protocol.
> - * We are only interested in NETCONS or not.
> - */
> -enum proto_t net_loop_last_protocol = BOOTP;
>
>  static void nc_wait_arp_handler(uchar *pkt, unsigned dest,
>  struct in_addr sip, unsigned src,
> @@ -177,7 +172,6 @@ static void nc_send_packet(const char *buf, int len)
>  #else
> struct eth_device *eth;
>  #endif
> -   int inited = 0;
> uchar *pkt;
> uchar *ether;
> struct in_addr ip;
> @@ -200,29 +194,17 @@ static void nc_send_packet(const char *buf, int len)
> return;
> }
>
> -   if (!eth_is_active(eth)) {
> -   if (eth_is_on_demand_init()) {
> -   if (eth_init() < 0)
> -   return;
> -   eth_set_last_protocol(NETCONS);
> -   } else {
> -   eth_init_state_only();
> -   }
> -
> -   inited = 1;
> +   if (net_up(NETCONS) < 0) {
> +   return;
> }
> +
> pkt = (uchar *)net_tx_packet + net_eth_hdr_size() + IP_UDP_HDR_SIZE;
> memcpy(pkt, buf, len);
> ether = nc_ether;
> ip = nc_ip;
> net_send_udp_packet(ether, ip, nc_out_port, nc_in_port, len);
>
> -   if (inited) {
> -   if (eth_is_on_demand_init())
> -   eth_halt();
> -   else
> -   eth_halt_state_only();
> -   }
> +   net_down();
>  }
>
>  static int nc_stdio_start(struct stdio_dev *dev)
> diff --git a/include/net.h b/include/net.h
> index 1bf9867..cc6be60 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -599,6 +599,9 @@ int net_loop(enum proto_t);
>  /* Load failed. Start again. */
>  int net_start_again(void);
>
> +int net_up(enum proto_t protocol);
> +int net_down(void);
> +
>  /* Get size of the ethernet header when we send */
>  int net_eth_hdr_size(void);
>
> @@ -706,26 +709,6 @@ int nc_input_packet(uchar *pkt, struct in_addr src_ip, 
> unsigned dest_port,
> unsigned src_port, unsigned len);
>  #endif
>
> -static __always_inline int eth_is_on_demand_init(void)
> -{
> -#if defined(CONFIG_NETCONSOLE) && !defined(CONFIG_SPL_BUILD)
> -   extern enum proto_t net_loop_last_protocol;
> -
> -   return net_loop_last_protocol != NETCONS;
> -#else
> -   return 1;
> -#endif
> -}
> -
> -static inline void eth_set_last_protocol(int protocol)
> -{
> -#if defined(CONFIG_NETCONSOLE) && !defined(CONFIG_SPL_BUILD)
> -   extern enum proto_t net_loop_last_protocol;
> -
> -   net_loop_last_protocol = protocol;
> -#endif
> -}
> -
>  /*
>   * Check if autoload is enabled. If so, use either NFS or TFTP to download
>   * the boot file.
> diff --git a/net/net.c b/net/net.c
> index 28d9eeb..45d4f19 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -404,6 +404,51 @@ void net_init(void)
>   * Main network processing loop.
>   */
>
> +static int up_ref;
> +static bool up;
> +static bool keep_up;
> +
> +/// Bring net up/active if needed.
> +int net_up(enum proto_t protocol)
> +{
> +   int ret;
> +   if (!up) {
> +   eth_halt();
> +   eth_set_current();
> +   ret = eth_init();
> +   if (ret < 0) {
> +   debug_cond(DEBUG_INT_STATE, "net_up failed\n");
> +   eth_halt();
> +   return ret;
> +   }
> +   up = true;
> +   

Re: [PATCH 00/49] image: Reduce #ifdefs and ad-hoc defines in image code

[Tom Rini]

On Tue, May 04, 2021 at 07:24:25PM -0400, Sean Anderson wrote:
> Hi Tom,
> 
> On 5/4/21 5:40 PM, Tom Rini wrote:
> > On Mon, May 03, 2021 at 05:10:47PM -0600, Simon Glass wrote:
> > 
> > > Much of the image-handling code predates the introduction of Kconfig and
> > > has quite a few #ifdefs in it. It also uses its own IMAGE_... defines to
> > > help reduce the #ifdefs, which is unnecessary now that we can use
> > > IS_ENABLED() et al.
> > > 
> > > The image code is also where quite a bit of code is shared with the host
> > > tools. At present this uses a lot of checks of USE_HOSTCC.
> > > 
> > > This series introduces 'host' Kconfig options and a way to use
> > > CONFIG_IS_ENABLED() to check them. This works in a similar way to SPL, so
> > > 
> > > CONFIG_IS_ENABLED(FIT)
> > > 
> > > will evaluate to true on the host build (USE_HOSTCC) if CONFIG_HOST_FIT is
> > > enabled. This allows quite a bit of clean-up of the image.h header file
> > > and many of the image C files.
> > > 
> > > The 'host' Kconfig options should help to solve a more general problem in
> > > that we mostly want the host tools to build with all features enabled, no
> > > matter which features the 'target' build actually uses. This is a pain to
> > > arrange at present, but with 'host' Kconfigs, we can just define them all
> > > to y.
> > > 
> > > There are cases where the host tools do not have features which are
> > > present on the target, for example environment and physical addressing.
> > > To help with this, some of the core image code is split out into
> > > image-board.c and image-host.c files.
> > > 
> > > Even with these changes, some #ifdefs remain (101 down to 42 in
> > > common/image*). But the code is somewhat easier to follow and there are
> > > fewer build paths.
> > > 
> > > In service of the above, this series includes a patch to add an API 
> > > function
> > > for zstd, so the code can be dropped from bootm.c
> > > 
> > > It also introduces a function to handle manual relocation.
> > 
> > I like this idea overall.  The good news is this reduces the size in a
> > few places.  The bad news, but I can live with if we can't restructure
> > the changes more, is a few functions grow a bit.  This shows the good
> > and the bad (something like sama5d2_ptc_ek_mmc shows only growth, to be
> > clear):
> What tool do you use to generate this output? Thanks.

buildman will give that for you.  This was from my world build
before/after wrapper, but for a single machine I have:
#!/bin/bash

# Initial and constant buildman args
ARGS="-devl"
ALL=0
KEEP=0

# Find our arguments
while test $# -ne 0; do
if [ "$1" == "--all" ]; then
ALL=1
shift 1
elif [ "$1" == "--branch" ]; then
BRANCH=$2
shift 2
elif [ "$1" == "--keep" ]; then
KEEP=1
ARGS="$ARGS -k"
shift 1
else
MACHINE=$1
shift
fi
done

if [ -z $MACHINE ]; then
echo Usage: $0 MACHINE [--all] [--keep] [--branch BRANCH]
exit 1
fi

# If not all, then only first/last
if [ $ALL -ne 1 ]; then
ARGS="$ARGS --step 0"
fi

if [ ! -z $BRANCH ]; then
ARGS="$ARGS -b $BRANCH"
else
ARGS="$ARGS -b `git rev-parse --abbrev-ref HEAD`"
fi

mkdir -p /tmp/$MACHINE

export SOURCE_DATE_EPOCH=`date +%s`
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SBC $MACHINE
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SsB $MACHINE

[ $KEEP -eq 0 ] && rm -rf /tmp/$MACHINE

In a script called "uboot-size-test.sh" to dig in to individual cases
more.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/49] image: Reduce #ifdefs and ad-hoc defines in image code

[Sean Anderson]

Hi Tom,

On 5/4/21 5:40 PM, Tom Rini wrote:

On Mon, May 03, 2021 at 05:10:47PM -0600, Simon Glass wrote:


Much of the image-handling code predates the introduction of Kconfig and
has quite a few #ifdefs in it. It also uses its own IMAGE_... defines to
help reduce the #ifdefs, which is unnecessary now that we can use
IS_ENABLED() et al.

The image code is also where quite a bit of code is shared with the host
tools. At present this uses a lot of checks of USE_HOSTCC.

This series introduces 'host' Kconfig options and a way to use
CONFIG_IS_ENABLED() to check them. This works in a similar way to SPL, so

CONFIG_IS_ENABLED(FIT)

will evaluate to true on the host build (USE_HOSTCC) if CONFIG_HOST_FIT is
enabled. This allows quite a bit of clean-up of the image.h header file
and many of the image C files.

The 'host' Kconfig options should help to solve a more general problem in
that we mostly want the host tools to build with all features enabled, no
matter which features the 'target' build actually uses. This is a pain to
arrange at present, but with 'host' Kconfigs, we can just define them all
to y.

There are cases where the host tools do not have features which are
present on the target, for example environment and physical addressing.
To help with this, some of the core image code is split out into
image-board.c and image-host.c files.

Even with these changes, some #ifdefs remain (101 down to 42 in
common/image*). But the code is somewhat easier to follow and there are
fewer build paths.

In service of the above, this series includes a patch to add an API function
for zstd, so the code can be dropped from bootm.c

It also introduces a function to handle manual relocation.


I like this idea overall.  The good news is this reduces the size in a
few places.  The bad news, but I can live with if we can't restructure
the changes more, is a few functions grow a bit.  This shows the good
and the bad (something like sama5d2_ptc_ek_mmc shows only growth, to be
clear):

What tool do you use to generate this output? Thanks.

--Sean


 px30-core-edimm2.2-px30: all -36 rodata -24 text -12
u-boot: add: 0/0, grow: 3/-4 bytes: 36/-48 (-12)
  function   old new   delta
  boot_get_fdt   896 924 +28
  image_decomp   372 376  +4
  boot_get_ramdisk   868 872  +4
  do_bootm_vxworks   552 540 -12
  do_bootm_rtems 124 112 -12
  do_bootm_plan9 228 216 -12
  do_bootm_netbsd324 312 -12
 odroid-c2  : all -105 bss +128 rodata -65 text -168
u-boot: add: 0/0, grow: 2/-3 bytes: 108/-172 (-64)
  function   old new   delta
  images 504 608+104
  image_decomp   372 376  +4
  image_setup_linux  108  96 -12
  boot_get_ramdisk   620 580 -40
  boot_get_fdt   660 540-120
 origen : all +47 bss +96 rodata -57 text +8
u-boot: add: 0/0, grow: 15/-2 bytes: 180/-104 (76)
  function   old new   delta
  images 288 340 +52
  do_bootm_states   13041348 +44
  do_bootz   164 176 +12
  do_bootm_vxworks   332 344 +12
  image_setup_libfdt 168 176  +8
  image_decomp   156 164  +8
  bootm_find_images  212 220  +8
  boot_prep_linux276 284  +8
  image_setup_linux   54  58  +4
  do_bootm_standalone 60  64  +4
  do_bootm_plan9 104 108  +4
  do_bootm_netbsd168 172  +4
  boot_prep_vxworks   48  52  +4
  boot_jump_vxworks6  10  +4
  boot_jump_linux148 152  +4
  boot_get_ramdisk   420 392 -28
  

Re: [PATCH 4/4] malloc: Fix sbrk clearing memory after freeing it instead of before

[Sean Anderson]

On 5/4/21 11:26 AM, Simon Glass wrote:

Hi Sean,

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:


This fixes memory being cleared after releasing it. Instead, clear memory
before releasing it. In addition, suppress valgrind warnings about writing
to free'd memory.

Signed-off-by: Sean Anderson 
---

  common/dlmalloc.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 05c8fd87e7..ea51bdf6a6 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -592,11 +592,13 @@ void *sbrk(ptrdiff_t increment)
 ulong new = old + increment;

 /*
-* if we are giving memory back make sure we clear it out since
-* we set MORECORE_CLEARS to 1
+* if we are allocating memory make sure we clear it out since we set
+* MORECORE_CLEARS to 1
  */
-   if (increment < 0)
-   memset((void *)new, 0, -increment);
+   if (increment > 0) {
+   VALGRIND_MAKE_MEM_UNDEFINED(old, increment);
+   memset((void *)old, 0, increment);
+   }


Can you explain this a bit more? What is the difference?


As it turns out, this patch is wrong. We need to clear memory when we
release it if SYS_MALLOC_CLEAR_ON_INIT is set, since calloc assumes that
memory has already been cleared if it gets it from sbrk.


Do you need the cast?


Yes (but this is moot)

common/dlmalloc.c: In function ‘sbrk’:
common/dlmalloc.c:600:10: warning: passing argument 1 of ‘memset’ makes pointer 
from integer without a cast [-Wint-conversion]
  600 |   memset(old, 0, increment);
  |  ^~~
  |  |
  |  ulong {aka long unsigned int}
In file included from include/common.h:21,
 from common/dlmalloc.c:1:
include/linux/string.h:111:22: note: expected ‘void *’ but argument is of type 
‘ulong’ {aka ‘long unsigned int’}
  111 | extern void * memset(void *,int,__kernel_size_t);
  |  ^~

--Sean





 if ((new < mem_malloc_start) || (new > mem_malloc_end))
 return (void *)MORECORE_FAILURE;
--
2.31.0



Regards,
Simon

Re: [PATCH 3/4] doc: sandbox: Document how to run sandbox with valgrind

[Sean Anderson]

On 5/4/21 11:26 AM, Simon Glass wrote:

Hi Sean,

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:


This documents how to get more detailed results from valgrind made possible
by the last two commits.

Signed-off-by: Sean Anderson 
---

  doc/arch/sandbox.rst | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)


Reviewed-by: Simon Glass 

This looks good. I wonder if CONFIG_VALGRIND could become a build
variable as well, so you don't need to update the CONFIG?


Are there any existing examples of things which work like that?

--Sean

[PATCH 1/5] arm: dts: k3-am642: Add ddr node

[Dave Gerlach]

Introduce ddr node for am642 needed for all ddr configurations.

Also, introduce the 1600MTs DDR4 configuration that is supported on the
am642-evm.

Signed-off-by: Dave Gerlach 
---
 arch/arm/dts/k3-am64-ddr.dtsi  | 2205 
 arch/arm/dts/k3-am64-evm-ddr4-1600MTs.dtsi | 2187 +++
 arch/arm/dts/k3-am642-r5-evm.dts   |2 +
 3 files changed, 4394 insertions(+)
 create mode 100644 arch/arm/dts/k3-am64-ddr.dtsi
 create mode 100644 arch/arm/dts/k3-am64-evm-ddr4-1600MTs.dtsi

diff --git a/arch/arm/dts/k3-am64-ddr.dtsi b/arch/arm/dts/k3-am64-ddr.dtsi
new file mode 100644
index ..026a547f0e3a
--- /dev/null
+++ b/arch/arm/dts/k3-am64-ddr.dtsi
@@ -0,0 +1,2205 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+   memorycontroller: memorycontroller@f30 {
+   compatible = "ti,am64-ddrss";
+   reg = <0x00 0x0f308000 0x00 0x4000>,
+ <0x00 0x43014000 0x00 0x100>;
+   reg-names = "cfg", "ctrl_mmr_lp4";
+   power-domains = <_pds 138 TI_SCI_PD_SHARED>,
+   <_pds 55 TI_SCI_PD_SHARED>;
+   clocks = <_clks 138 0>, <_clks 16 4>;
+   ti,ddr-freq1 = ;
+   ti,ddr-freq2 = ;
+   ti,ddr-fhs-cnt = ;
+
+   u-boot,dm-spl;
+
+   ti,ctl-data = <
+   DDRSS_CTL_0_DATA
+   DDRSS_CTL_1_DATA
+   DDRSS_CTL_2_DATA
+   DDRSS_CTL_3_DATA
+   DDRSS_CTL_4_DATA
+   DDRSS_CTL_5_DATA
+   DDRSS_CTL_6_DATA
+   DDRSS_CTL_7_DATA
+   DDRSS_CTL_8_DATA
+   DDRSS_CTL_9_DATA
+   DDRSS_CTL_10_DATA
+   DDRSS_CTL_11_DATA
+   DDRSS_CTL_12_DATA
+   DDRSS_CTL_13_DATA
+   DDRSS_CTL_14_DATA
+   DDRSS_CTL_15_DATA
+   DDRSS_CTL_16_DATA
+   DDRSS_CTL_17_DATA
+   DDRSS_CTL_18_DATA
+   DDRSS_CTL_19_DATA
+   DDRSS_CTL_20_DATA
+   DDRSS_CTL_21_DATA
+   DDRSS_CTL_22_DATA
+   DDRSS_CTL_23_DATA
+   DDRSS_CTL_24_DATA
+   DDRSS_CTL_25_DATA
+   DDRSS_CTL_26_DATA
+   DDRSS_CTL_27_DATA
+   DDRSS_CTL_28_DATA
+   DDRSS_CTL_29_DATA
+   DDRSS_CTL_30_DATA
+   DDRSS_CTL_31_DATA
+   DDRSS_CTL_32_DATA
+   DDRSS_CTL_33_DATA
+   DDRSS_CTL_34_DATA
+   DDRSS_CTL_35_DATA
+   DDRSS_CTL_36_DATA
+   DDRSS_CTL_37_DATA
+   DDRSS_CTL_38_DATA
+   DDRSS_CTL_39_DATA
+   DDRSS_CTL_40_DATA
+   DDRSS_CTL_41_DATA
+   DDRSS_CTL_42_DATA
+   DDRSS_CTL_43_DATA
+   DDRSS_CTL_44_DATA
+   DDRSS_CTL_45_DATA
+   DDRSS_CTL_46_DATA
+   DDRSS_CTL_47_DATA
+   DDRSS_CTL_48_DATA
+   DDRSS_CTL_49_DATA
+   DDRSS_CTL_50_DATA
+   DDRSS_CTL_51_DATA
+   DDRSS_CTL_52_DATA
+   DDRSS_CTL_53_DATA
+   DDRSS_CTL_54_DATA
+   DDRSS_CTL_55_DATA
+   DDRSS_CTL_56_DATA
+   DDRSS_CTL_57_DATA
+   DDRSS_CTL_58_DATA
+   DDRSS_CTL_59_DATA
+   DDRSS_CTL_60_DATA
+   DDRSS_CTL_61_DATA
+   DDRSS_CTL_62_DATA
+   DDRSS_CTL_63_DATA
+   DDRSS_CTL_64_DATA
+   DDRSS_CTL_65_DATA
+   DDRSS_CTL_66_DATA
+   DDRSS_CTL_67_DATA
+   DDRSS_CTL_68_DATA
+   DDRSS_CTL_69_DATA
+   DDRSS_CTL_70_DATA
+   DDRSS_CTL_71_DATA
+   DDRSS_CTL_72_DATA
+   DDRSS_CTL_73_DATA
+   DDRSS_CTL_74_DATA
+   DDRSS_CTL_75_DATA
+   DDRSS_CTL_76_DATA
+   DDRSS_CTL_77_DATA
+   DDRSS_CTL_78_DATA
+   DDRSS_CTL_79_DATA
+   DDRSS_CTL_80_DATA
+   DDRSS_CTL_81_DATA
+   DDRSS_CTL_82_DATA
+   DDRSS_CTL_83_DATA
+   

Re: [PATCH 5/8] net: dwc_eth_qos: add dwc eqos for imx support

[Daniil Stas]

Hi, i think there are some issues with this patch.

> @@ -1131,6 +1205,7 @@ static int eqos_start(struct udevice *dev)
>   }
>  
>   /* Configure MTL */
> + writel(0x60, >mtl_regs->txq0_quantum_weight - 0x100);
>  
>   /* Enable Store and Forward mode for TX */
>   /* Program Tx operating mode */

What is this address: >mtl_regs->txq0_quantum_weight - 0x100?
Isn't it outside of MTL registers range?

> @@ -1144,7 +1219,9 @@ static int eqos_start(struct udevice *dev)
>  
>   /* Enable Store and Forward mode for RX, since no jumbo frame */
>   setbits_le32(>mtl_regs->rxq0_operation_mode,
> -  EQOS_MTL_RXQ0_OPERATION_MODE_RSF);
> +  EQOS_MTL_RXQ0_OPERATION_MODE_RSF |
> +  EQOS_MTL_RXQ0_OPERATION_MODE_FEP |
> +  EQOS_MTL_RXQ0_OPERATION_MODE_FUP);
>  
>   /* Transmit/Receive queue fifo size; use all RAM for 1 queue */
>   val = readl(>mac_regs->hw_feature1);

Why do you set FEP and FUP bits? It can lead to data corruption as they
allow accepting erroneous packets.

I think these options should only be used in some debugging mode but not
in production.

> @@ -1220,6 +1297,19 @@ static int eqos_start(struct udevice *dev)
>   eqos->config->config_mac <<
>   EQOS_MAC_RXQ_CTRL0_RXQ0EN_SHIFT);
>  
> + clrsetbits_le32(>mac_regs->rxq_ctrl0,
> + EQOS_MAC_RXQ_CTRL0_RXQ0EN_MASK <<
> + EQOS_MAC_RXQ_CTRL0_RXQ0EN_SHIFT,
> + 0x2 <<
> + EQOS_MAC_RXQ_CTRL0_RXQ0EN_SHIFT);
> +

This line just overrides the value set in the previous line.
Is it a mistake?

> + /* enable promise mode */
> + setbits_le32(>mac_regs->unused_004[1],
> +  0x1);
> +

Isn't this mode also useful only for debugging?

Re: [PATCH 00/49] image: Reduce #ifdefs and ad-hoc defines in image code

[Simon Glass]

Hi Tom,

On Tue, 4 May 2021 at 15:40, Tom Rini  wrote:
>
> On Mon, May 03, 2021 at 05:10:47PM -0600, Simon Glass wrote:
>
> > Much of the image-handling code predates the introduction of Kconfig and
> > has quite a few #ifdefs in it. It also uses its own IMAGE_... defines to
> > help reduce the #ifdefs, which is unnecessary now that we can use
> > IS_ENABLED() et al.
> >
> > The image code is also where quite a bit of code is shared with the host
> > tools. At present this uses a lot of checks of USE_HOSTCC.
> >
> > This series introduces 'host' Kconfig options and a way to use
> > CONFIG_IS_ENABLED() to check them. This works in a similar way to SPL, so
> >
> >CONFIG_IS_ENABLED(FIT)
> >
> > will evaluate to true on the host build (USE_HOSTCC) if CONFIG_HOST_FIT is
> > enabled. This allows quite a bit of clean-up of the image.h header file
> > and many of the image C files.
> >
> > The 'host' Kconfig options should help to solve a more general problem in
> > that we mostly want the host tools to build with all features enabled, no
> > matter which features the 'target' build actually uses. This is a pain to
> > arrange at present, but with 'host' Kconfigs, we can just define them all
> > to y.
> >
> > There are cases where the host tools do not have features which are
> > present on the target, for example environment and physical addressing.
> > To help with this, some of the core image code is split out into
> > image-board.c and image-host.c files.
> >
> > Even with these changes, some #ifdefs remain (101 down to 42 in
> > common/image*). But the code is somewhat easier to follow and there are
> > fewer build paths.
> >
> > In service of the above, this series includes a patch to add an API function
> > for zstd, so the code can be dropped from bootm.c
> >
> > It also introduces a function to handle manual relocation.
>
> I like this idea overall.  The good news is this reduces the size in a
> few places.  The bad news, but I can live with if we can't restructure
> the changes more, is a few functions grow a bit.  This shows the good
> and the bad (something like sama5d2_ptc_ek_mmc shows only growth, to be
> clear):
> px30-core-edimm2.2-px30: all -36 rodata -24 text -12
>u-boot: add: 0/0, grow: 3/-4 bytes: 36/-48 (-12)
>  function   old new   
> delta
>  boot_get_fdt   896 924 
> +28
>  image_decomp   372 376  
> +4
>  boot_get_ramdisk   868 872  
> +4
>  do_bootm_vxworks   552 540 
> -12
>  do_bootm_rtems 124 112 
> -12
>  do_bootm_plan9 228 216 
> -12
>  do_bootm_netbsd324 312 
> -12
> odroid-c2  : all -105 bss +128 rodata -65 text -168
>u-boot: add: 0/0, grow: 2/-3 bytes: 108/-172 (-64)
>  function   old new   
> delta
>  images 504 608
> +104
>  image_decomp   372 376  
> +4
>  image_setup_linux  108  96 
> -12
>  boot_get_ramdisk   620 580 
> -40
>  boot_get_fdt   660 540
> -120
> origen : all +47 bss +96 rodata -57 text +8
>u-boot: add: 0/0, grow: 15/-2 bytes: 180/-104 (76)
>  function   old new   
> delta
>  images 288 340 
> +52
>  do_bootm_states   13041348 
> +44
>  do_bootz   164 176 
> +12
>  do_bootm_vxworks   332 344 
> +12
>  image_setup_libfdt 168 176  
> +8
>  image_decomp   156 164  
> +8
>  bootm_find_images  212 220  
> +8
>  boot_prep_linux276 284  
> +8
>  image_setup_linux   54  58  
> +4
>  do_bootm_standalone 60  64  
> +4
>  do_bootm_plan9 104 108  
> +4
>  do_bootm_netbsd168 172  
> +4
>  boot_prep_vxworks   48  52  
> +4
>  boot_jump_vxworks 

Re: [PATCH 00/49] image: Reduce #ifdefs and ad-hoc defines in image code

[Tom Rini]

On Mon, May 03, 2021 at 05:10:47PM -0600, Simon Glass wrote:

> Much of the image-handling code predates the introduction of Kconfig and
> has quite a few #ifdefs in it. It also uses its own IMAGE_... defines to
> help reduce the #ifdefs, which is unnecessary now that we can use
> IS_ENABLED() et al.
> 
> The image code is also where quite a bit of code is shared with the host
> tools. At present this uses a lot of checks of USE_HOSTCC.
> 
> This series introduces 'host' Kconfig options and a way to use
> CONFIG_IS_ENABLED() to check them. This works in a similar way to SPL, so
> 
>CONFIG_IS_ENABLED(FIT)
> 
> will evaluate to true on the host build (USE_HOSTCC) if CONFIG_HOST_FIT is
> enabled. This allows quite a bit of clean-up of the image.h header file
> and many of the image C files.
> 
> The 'host' Kconfig options should help to solve a more general problem in
> that we mostly want the host tools to build with all features enabled, no
> matter which features the 'target' build actually uses. This is a pain to
> arrange at present, but with 'host' Kconfigs, we can just define them all
> to y.
> 
> There are cases where the host tools do not have features which are
> present on the target, for example environment and physical addressing.
> To help with this, some of the core image code is split out into
> image-board.c and image-host.c files.
> 
> Even with these changes, some #ifdefs remain (101 down to 42 in
> common/image*). But the code is somewhat easier to follow and there are
> fewer build paths.
> 
> In service of the above, this series includes a patch to add an API function
> for zstd, so the code can be dropped from bootm.c
> 
> It also introduces a function to handle manual relocation.

I like this idea overall.  The good news is this reduces the size in a
few places.  The bad news, but I can live with if we can't restructure
the changes more, is a few functions grow a bit.  This shows the good
and the bad (something like sama5d2_ptc_ek_mmc shows only growth, to be
clear):
px30-core-edimm2.2-px30: all -36 rodata -24 text -12
   u-boot: add: 0/0, grow: 3/-4 bytes: 36/-48 (-12)
 function   old new   delta
 boot_get_fdt   896 924 +28
 image_decomp   372 376  +4
 boot_get_ramdisk   868 872  +4
 do_bootm_vxworks   552 540 -12
 do_bootm_rtems 124 112 -12
 do_bootm_plan9 228 216 -12
 do_bootm_netbsd324 312 -12
odroid-c2  : all -105 bss +128 rodata -65 text -168
   u-boot: add: 0/0, grow: 2/-3 bytes: 108/-172 (-64)
 function   old new   delta
 images 504 608+104
 image_decomp   372 376  +4
 image_setup_linux  108  96 -12
 boot_get_ramdisk   620 580 -40
 boot_get_fdt   660 540-120
origen : all +47 bss +96 rodata -57 text +8
   u-boot: add: 0/0, grow: 15/-2 bytes: 180/-104 (76)
 function   old new   delta
 images 288 340 +52
 do_bootm_states   13041348 +44
 do_bootz   164 176 +12
 do_bootm_vxworks   332 344 +12
 image_setup_libfdt 168 176  +8
 image_decomp   156 164  +8
 bootm_find_images  212 220  +8
 boot_prep_linux276 284  +8
 image_setup_linux   54  58  +4
 do_bootm_standalone 60  64  +4
 do_bootm_plan9 104 108  +4
 do_bootm_netbsd168 172  +4
 boot_prep_vxworks   48  52  +4
 boot_jump_vxworks6  10  +4
 boot_jump_linux148 152  +4
 boot_get_ramdisk   420 392 -28
 boot_get_fdt   420 344 -76

And looking at 

[PATCH 2/5] arm: mach-k3: am642: Add support for triggering ddr init from SPL

[Dave Gerlach]

In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().

Signed-off-by: Dave Gerlach 
---
 arch/arm/mach-k3/am642_init.c | 6 ++
 board/ti/am64x/Kconfig| 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 8931aaabf2f9..f9f28194e0d3 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -131,6 +131,12 @@ void board_init_f(ulong dummy)
 
/* Output System Firmware version info */
k3_sysfw_print_ver();
+
+#if defined(CONFIG_K3_AM64_DDRSS)
+   ret = uclass_get_device(UCLASS_RAM, 0, );
+   if (ret)
+   panic("DRAM init failed: %d\n", ret);
+#endif
 }
 
 u32 spl_boot_mode(const u32 boot_device)
diff --git a/board/ti/am64x/Kconfig b/board/ti/am64x/Kconfig
index a49e22266983..6cee535df70e 100644
--- a/board/ti/am64x/Kconfig
+++ b/board/ti/am64x/Kconfig
@@ -19,6 +19,9 @@ config TARGET_AM642_R5_EVM
select SYS_THUMB_BUILD
select K3_LOAD_SYSFW
select SOC_K3_AM642
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
imply SYS_K3_SPL_ATF
 
 endchoice
-- 
2.28.0

[PATCH 0/5] arm: mach-k3: k3-am64: Add DDR configuration and enable

[Dave Gerlach]

This series adds the required configuration needed to use the new common
k3-ddrss driver on am64 and also adds the required dts data needed to
enable DDR usage on the k3-am642-evm platform.

This series depends on the AM64 base support series [1] and the Common
K3 DDRSS series here [2].

Regards,
Dave

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=240546
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=241946

Dave Gerlach (2):
  arm: dts: k3-am642: Add ddr node
  arm: mach-k3: am642: Add support for triggering ddr init from SPL

Nishanth Menon (3):
  arm: dts: k3-am64-main: Add GPIO nodes
  arm: dts: k3-am642-r5-evm: Add GPIO DDR VTT regulator
  configs: am64x_evm_r5: Enable GPIO regulator

 arch/arm/dts/k3-am64-ddr.dtsi  | 2205 
 arch/arm/dts/k3-am64-evm-ddr4-1600MTs.dtsi | 2187 +++
 arch/arm/dts/k3-am64-main.dtsi |   44 +
 arch/arm/dts/k3-am642-r5-evm.dts   |   30 +
 arch/arm/mach-k3/am642_init.c  |6 +
 board/ti/am64x/Kconfig |3 +
 configs/am64x_evm_r5_defconfig |8 +
 7 files changed, 4483 insertions(+)
 create mode 100644 arch/arm/dts/k3-am64-ddr.dtsi
 create mode 100644 arch/arm/dts/k3-am64-evm-ddr4-1600MTs.dtsi

-- 
2.28.0

[PATCH 5/5] configs: am64x_evm_r5: Enable GPIO regulator

[Dave Gerlach]

From: Nishanth Menon 

Enable GPIO regulator.

Signed-off-by: Nishanth Menon 
Signed-off-by: Dave Gerlach 
---
 configs/am64x_evm_r5_defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index 0fa4ae90b59b..a9f206d3d1ab 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x8
@@ -28,6 +29,7 @@ CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_SPI_FLASH=y
 CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
 CONFIG_SPL_POWER_DOMAIN=y
 CONFIG_SPL_REMOTEPROC=y
 CONFIG_SPL_SPI_LOAD=y
@@ -56,6 +58,8 @@ CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
 CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_GPIO=y
+CONFIG_DA8XX_GPIO=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
 CONFIG_DM_MMC=y
@@ -74,6 +78,10 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
 CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_SPL_DM_REGULATOR_GPIO=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
-- 
2.28.0

[PATCH 3/5] arm: dts: k3-am64-main: Add GPIO nodes

[Dave Gerlach]

From: Nishanth Menon 

Add main domain GPIO nodes.

Signed-off-by: Nishanth Menon 
Signed-off-by: Dave Gerlach 
---
 arch/arm/dts/k3-am64-main.dtsi | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 5f85950daef7..ff65857d1ebf 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -402,4 +402,48 @@
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
};
+
+   main_gpio0: gpio@60 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x0060 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = <77 0 IRQ_TYPE_EDGE_RISING>,
+<77 1 IRQ_TYPE_EDGE_RISING>,
+<77 2 IRQ_TYPE_EDGE_RISING>,
+<77 3 IRQ_TYPE_EDGE_RISING>,
+<77 4 IRQ_TYPE_EDGE_RISING>,
+<77 5 IRQ_TYPE_EDGE_RISING>,
+<77 6 IRQ_TYPE_EDGE_RISING>,
+<77 7 IRQ_TYPE_EDGE_RISING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 77 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 77 0>;
+   clock-names = "gpio";
+   };
+
+   main_gpio1: gpio@601000 {
+   compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+   reg = <0x00 0x00601000 0x00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = <78 0 IRQ_TYPE_EDGE_RISING>,
+<78 1 IRQ_TYPE_EDGE_RISING>,
+<78 2 IRQ_TYPE_EDGE_RISING>,
+<78 3 IRQ_TYPE_EDGE_RISING>,
+<78 4 IRQ_TYPE_EDGE_RISING>,
+<78 5 IRQ_TYPE_EDGE_RISING>,
+<78 6 IRQ_TYPE_EDGE_RISING>,
+<78 7 IRQ_TYPE_EDGE_RISING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <69>;
+   ti,davinci-gpio-unbanked = <0>;
+   power-domains = <_pds 78 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 78 0>;
+   clock-names = "gpio";
+   };
 };
-- 
2.28.0

[PATCH 4/5] arm: dts: k3-am642-r5-evm: Add GPIO DDR VTT regulator

[Dave Gerlach]

From: Nishanth Menon 

Add DDR VTT regulator.

Signed-off-by: Nishanth Menon 
Signed-off-by: Dave Gerlach 
---
 arch/arm/dts/k3-am642-r5-evm.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index 67db28f70db7..f253c1636df3 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -61,6 +61,16 @@
clock-frequency = <2>;
u-boot,dm-spl;
};
+
+   vtt_supply: vtt-supply {
+   compatible = "regulator-gpio";
+   regulator-name = "vtt";
+   regulator-min-microvolt = <0>;
+   regulator-max-microvolt = <330>;
+   gpios = <_gpio0 12 GPIO_ACTIVE_HIGH>;
+   states = <0 0x0 330 0x1>;
+   u-boot,dm-spl;
+   };
 };
 
 _main {
@@ -124,6 +134,13 @@
AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0)/* 
(C20) MMC1_SDWP */
>;
};
+
+   ddr_vtt_pins_default: ddr-vtt-pins-default {
+   u-boot,dm-spl;
+   pinctrl-single,pins = <
+   AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7)   /* 
(L18) OSPI0_CSN1.GPIO0_12 */
+   >;
+   };
 };
 
  {
@@ -150,6 +167,12 @@
pinctrl-0 = <_uart1_pins_default>;
 };
 
+ {
+   vtt-supply = <_supply>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_vtt_pins_default>;
+};
+
  {
/delete-property/ power-domains;
clocks = <_200mhz>;
@@ -168,4 +191,9 @@
pinctrl-0 = <_mmc1_pins_default>;
 };
 
+_gpio0 {
+   u-boot,dm-spl;
+   /delete-property/ power-domains;
+};
+
 #include "k3-am642-evm-u-boot.dtsi"
-- 
2.28.0

Re: [PATCH v1 00/23] phy: marvell: Sync Armada 3k/7k/8k SERDES code with Marvell version

[Pali Rohár]

On Thursday 29 April 2021 11:00:17 Stefan Roese wrote:
> Hi Marek,
> 
> (Added Tom and Simon to Cc)
> 
> On 29.04.21 10:27, Marek Behun wrote:
> > On Thu, 29 Apr 2021 08:46:36 +0200
> > Stefan Roese  wrote:
> > 
> > > > phy: marvell: add RX training command
> > > 
> > > Applied to u-boot-marvell/master
> > > 
> > > Thanks,
> > > Stefan
> > 
> > Stefan, do you think it would make sense to at least create a special
> > mechanism for these platform commands? For example via a top-level
> > command "plat", i.e. instead of
> >> rx_training params
> > we would call
> >> plat rx_training params
> > 
> > The plat command could list all registered platform specific commands...
> 
> Not sure. If you want to split it up, then we would perhaps also
> need to add a mechanism for board specific commands as well. E.g. for
> commands not common for a platform but only for specific boards. My
> feeling is that this makes things overly complex. And I also don't see
> a real problem with the current "flat" structure of these commands
> being "global". Again, I mention the many already existing board and
> platform specific commands in current mainline.
> 
> Perhaps other people can comment on this use / introduction of
> platform specific U-Boot commands?
> 
> BTW: Again, we can definitely rename this specific "rx_training"
> command, if you feel this is absolutely misleading. IIRC, then I already
> made a suggestion for this.

Hello! "rx_training" is definitely ambiguous and I strongly suggest to
rename this command (if is going to be merged in current form).

My first impression was that this command is suppose to do some DDR3/4
training sequence but it is doing something totally different.

I'm also not a big fan of these custom vendor specific/proprietary
commands. And I rather would like to see generic command with an API so
other boards and vendors could implement it too.

But if this comphy rx training code is something specific to Marvell
platforms and there is no other platform which needs such abstraction
then lets have it as custom vendor specific command.

I hope that Tom or Simon have better knowledge of U-Boot code and
hardware on which is U-Boot running and can say if there are other
platforms for such command or not.

And if "plat" command is too complex for this, what about renaming this
command to something like "mvebu_comphy_rx_training" or something
similar? To express that it is Marvell specific and also mention that it
is for comphy. And not for ddr, uart or ethernet phy.


Same applies for Marvell command "bubt" which is already present in
U-Boot codebase. It has totally insane name as abbreviation of Burn
UBooT and moreover on A3720 is does not even work with U-Boot image but
rather with "big" image in specific custom format which contains
concatenation of Cortex-M3 Secure Firmware, Cortex-A53 Trusted Firmware
and U-Boot. And I think this "bubt" is example of command which should
not be vendor specific but rather generic U-Boot command as its purpose
is to update vendor specific boot image stored in nand/eMMC either via
TFTP or from uSD card. So this command could have been called "fwupdate"
or similar to express that is updated vendor specific firmware or U-Boot
bootloader in vendor specific format (if U-Boot needs to have some
encapsulation) for current board to current "boot device/partition".

> Thanks,
> Stefan

Re: Weirdness of ofnode_get_addr_size()

[Jan Kiszka]

On 04.05.21 22:01, Dario Binacchi wrote:
> Hi Jan,
>
>> Il 04/05/2021 17:26 Simon Glass  ha scritto:
>>
>>
>> Hi Jan,
>>
>> On Sun, 2 May 2021 at 01:53, Jan Kiszka  wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to make some sense of ofnode_get_addr_size() in order to fix
>>> [1] properly.
>>>
>>> First, the documentation if this functions says "This does no address
>>> translation". But the node-pointer path happily calls
>>> of_translate_address(), as the result of a6a45cd32539. For not
>>> offset-bases path, it calls fdtdec_get_addr_size() which does no
>>> translation.
>>>
>>> Related to [1]: The node-pointer path cleanly calls
>>> of_n_addr/size_cells() in order to retrieve the configured number of
>>> cells. But the offset-based path simply calls fdtdec_get_addr_size()
>>> which assumes that the number of cells is derived from the physical
>>> address width of that platform.
>>>
>>> So, what is that functions actually supposed to do?
>>
>> +Dario Binacchi +Mario Six
>>
>> I suspect the code has got ahead of the docs.
>>
>> d64b9cdcd47 fdt: translate address if #size-cells = <0>
>
> I submitted a patch to revert the commit:
> https://patchwork.ozlabs.org/project/uboot/patch/20210501150527.10273-6-dario...@libero.it/
>

But of_translate_address is still part of ofnode_get_addr_size, just
called under less conditions.

And that is only one of the inconsistencies, at least as it looks to me.

Jan

RE: [PATCH] cli: Fix command line underrun

[Wang, Peng]

Please discard this patch. I reviewed this patch and noticed that it forgot to 
take care the *np. The test that was performed may be incomplete.

On the other hand, it's strange that the cursor can be moved back beyond the 
prompt while it should be stopped by the "if (*np == 0)" check.

Since we do not have a hardware to run a test at this moment, we may provide 
only an untested patch update in a near future for your reference.

Regards,
Peng

Peng Wang | T +1 602-438-3778



NOTE: Artesyn Embedded Computing is now part of the SMART Global Holdings, Inc. 
family of companies

-Original Message-
From: Wang, Peng 
Sent: Tuesday, May 04, 2021 12:40 AM
To: u-boot@lists.denx.de
Cc: tr...@konsulko.com
Subject: [PATCH] cli: Fix command line underrun

>From 7a3110962cd1482793a9912fa14e5d9961e9f01a Mon Sep 17 00:00:00 2001
From: "peng.w...@smartm.com" 
Date: Mon, 3 May 2021 23:53:29 -0700
Subject: [PATCH] cli: Fix command line underrun

This patch adds a column position check to fix the cli issue that backspace 
doesn't stop at the prompt.

Signed-off-by: peng.w...@smartm.com 
---
 common/cli_readline.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/cli_readline.c b/common/cli_readline.c index 
c7614a4c90..bce670733f 100644
--- a/common/cli_readline.c
+++ b/common/cli_readline.c
@@ -45,8 +45,10 @@ static char *delete_char (char *buffer, char *p, int *colp, 
int *np, int plen)
}
}
} else {
-   puts(erase_seq);
-   (*colp)--;
+   if (*colp > plen) {
+   puts(erase_seq);
+   (*colp)--;
+   }
}
(*np)--;
 
--
2.31.1.windows.1

Re: Weirdness of ofnode_get_addr_size()

[Dario Binacchi]

Hi Jan,

> Il 04/05/2021 17:26 Simon Glass  ha scritto:
> 
>  
> Hi Jan,
> 
> On Sun, 2 May 2021 at 01:53, Jan Kiszka  wrote:
> >
> > Hi,
> >
> > I'm trying to make some sense of ofnode_get_addr_size() in order to fix
> > [1] properly.
> >
> > First, the documentation if this functions says "This does no address
> > translation". But the node-pointer path happily calls
> > of_translate_address(), as the result of a6a45cd32539. For not
> > offset-bases path, it calls fdtdec_get_addr_size() which does no
> > translation.
> >
> > Related to [1]: The node-pointer path cleanly calls
> > of_n_addr/size_cells() in order to retrieve the configured number of
> > cells. But the offset-based path simply calls fdtdec_get_addr_size()
> > which assumes that the number of cells is derived from the physical
> > address width of that platform.
> >
> > So, what is that functions actually supposed to do?
> 
> +Dario Binacchi +Mario Six
> 
> I suspect the code has got ahead of the docs.
> 
> d64b9cdcd47 fdt: translate address if #size-cells = <0>

I submitted a patch to revert the commit:
https://patchwork.ozlabs.org/project/uboot/patch/20210501150527.10273-6-dario...@libero.it/

Thanks and regards,
Dario

> e8d5291824e core: ofnode: Fix translation for #size-cells == 0
> 
> Regards,
> Simon
> 
> >
> > Jan
> >
> > [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg405446.html

Re: [RFC 4/7] pinctrl: mscc: Fix multiple definition error

[Daniel Schwierzeck]

Am Montag, den 03.05.2021, 16:48 -0400 schrieb Tom Rini:
> With gcc-11 we get a multiple errors here as the declarations for
> mscc_pinctrl_ops and mscc_gpio_ops are missing an extern.
> 
> CC: Gregory CLEMENT 
> Cc: Lars Povlsen 
> Cc: Horatiu Vultur 
> Signed-off-by: Tom Rini 
> ---
>  drivers/pinctrl/mscc/mscc-common.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Daniel Schwierzeck 

-- Daniel

Re: [PATCH] pinctrl: mscc: fix multiple definitions

[Daniel Schwierzeck]

Am Dienstag, den 04.05.2021, 14:45 -0400 schrieb Tom Rini:
> On Tue, May 04, 2021 at 08:40:40PM +0200, Daniel Schwierzeck wrote:
> 
> > gcc-11 complains about multiple definitions:
> > 
> > /opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd:
> > drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-
> > common.h:64: multiple definition of `mscc_pinctrl_ops';
> > drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-
> > common.h:64: first defined here
> > /opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd:
> > drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-
> > common.h:66: multiple definition of `mscc_gpio_ops';
> > drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-
> > common.h:66: first defined here
> > 
> > mscc_pinctrl_ops and mscc_gpio_ops are instantiated in mscc-
> > common.c and
> > just referenced by SoC specific pinctrl drivers. Annotate the
> > exports
> > in mscc-common.h with `extern` to avoid creating new instances
> > when including mscc-common.h.
> > 
> > Signed-off-by: Daniel Schwierzeck 
> 
> I posted this yesterday as part of:
> https://patchwork.ozlabs.org/project/uboot/list/?series=241916=*
> BTW.

okay, I only saw your patch 7/7 in my inbox ;)

-- 
- Daniel

Re: [PATCH] pinctrl: mscc: fix multiple definitions

[Tom Rini]

On Tue, May 04, 2021 at 08:40:40PM +0200, Daniel Schwierzeck wrote:

> gcc-11 complains about multiple definitions:
> 
> /opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd: 
> drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-common.h:64: 
> multiple definition of `mscc_pinctrl_ops'; 
> drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-common.h:64: 
> first defined here
> /opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd: 
> drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-common.h:66: 
> multiple definition of `mscc_gpio_ops'; 
> drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-common.h:66: 
> first defined here
> 
> mscc_pinctrl_ops and mscc_gpio_ops are instantiated in mscc-common.c and
> just referenced by SoC specific pinctrl drivers. Annotate the exports
> in mscc-common.h with `extern` to avoid creating new instances
> when including mscc-common.h.
> 
> Signed-off-by: Daniel Schwierzeck 

I posted this yesterday as part of:
https://patchwork.ozlabs.org/project/uboot/list/?series=241916=*
BTW.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] pinctrl: mscc: fix multiple definitions

[Daniel Schwierzeck]

gcc-11 complains about multiple definitions:

/opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd: 
drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-common.h:64: 
multiple definition of `mscc_pinctrl_ops'; 
drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-common.h:64: first 
defined here
/opt/gcc-11.0.20210426-nolibc/mips-linux/bin/mips-linux-ld.bfd: 
drivers/pinctrl/mscc/pinctrl-ocelot.o:drivers/pinctrl/mscc/mscc-common.h:66: 
multiple definition of `mscc_gpio_ops'; 
drivers/pinctrl/mscc/mscc-common.o:drivers/pinctrl/mscc/mscc-common.h:66: first 
defined here

mscc_pinctrl_ops and mscc_gpio_ops are instantiated in mscc-common.c and
just referenced by SoC specific pinctrl drivers. Annotate the exports
in mscc-common.h with `extern` to avoid creating new instances
when including mscc-common.h.

Signed-off-by: Daniel Schwierzeck 

---

 drivers/pinctrl/mscc/mscc-common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mscc/mscc-common.h 
b/drivers/pinctrl/mscc/mscc-common.h
index 3c5c1faf84..9eb1321f89 100644
--- a/drivers/pinctrl/mscc/mscc-common.h
+++ b/drivers/pinctrl/mscc/mscc-common.h
@@ -61,6 +61,6 @@ int mscc_pinctrl_probe(struct udevice *dev, int num_func,
   const struct mscc_pin_data *mscc_pins, int num_pins,
   char * const *function_names,
   const unsigned long *mscc_gpios);
-const struct pinctrl_ops mscc_pinctrl_ops;
 
-const struct dm_gpio_ops mscc_gpio_ops;
+extern const struct pinctrl_ops mscc_pinctrl_ops;
+extern const struct dm_gpio_ops mscc_gpio_ops;
-- 
2.31.1

[PATCH v5 10/10] am335x: add support for cape detect functionality

[Kory Maincent]

Update the Kconfig and the board file to make the am335x board compatible
with cape detection.

Signed-off-by: Kory Maincent 
---

Change Since v1:
 - Remove CAPE_EEPROM_BUS_NUM from board header

 arch/arm/mach-omap2/am33xx/Kconfig | 1 +
 board/ti/am335x/board.c| 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/Kconfig 
b/arch/arm/mach-omap2/am33xx/Kconfig
index 9a98e8a0a9..11e54cd293 100644
--- a/arch/arm/mach-omap2/am33xx/Kconfig
+++ b/arch/arm/mach-omap2/am33xx/Kconfig
@@ -34,6 +34,7 @@ config TARGET_AM335X_EVM
select DM_GPIO
select DM_SERIAL
select TI_I2C_BOARD_DETECT
+   select SUPPORT_EXTENSION_SCAN
imply CMD_DM
imply SPL_DM
imply SPL_DM_SEQ_ALIAS
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index c7476b3a8c..5959ff73dc 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include "../common/board_detect.h"
+#include "../common/cape_detect.h"
 #include "board.h"
 
 DECLARE_GLOBAL_DATA_PTR;
-- 
2.17.1

[PATCH v5 09/10] arm: am335x: add support for i2c2 bus

[Kory Maincent]

The am335x from BeagleBone use i2c EEPROM to detect capes.
The memory is wired to i2c bus 2 therefore it need to be enabled.

Add i2c2 clock, pinmux description and pinmux enable function.

Signed-off-by: Kory Maincent 
---
 arch/arm/mach-omap2/am33xx/clock_am33xx.c |  1 +
 board/ti/am335x/board.c   |  2 ++
 board/ti/am335x/board.h   |  1 +
 board/ti/am335x/mux.c | 15 +++
 4 files changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c 
b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
index cf71192360..3a7ac60264 100644
--- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
+++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
@@ -220,6 +220,7 @@ void enable_basic_clocks(void)
>gpio2clkctrl,
>gpio3clkctrl,
>i2c1clkctrl,
+   >i2c2clkctrl,
>cpgmac0clkctrl,
>spi0clkctrl,
>rtcclkctrl,
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index bc1657e88f..c7476b3a8c 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -77,8 +77,10 @@ static struct ctrl_dev *cdev = (struct ctrl_dev 
*)CTRL_DEVICE_BASE;
 void do_board_detect(void)
 {
enable_i2c0_pin_mux();
+   enable_i2c2_pin_mux();
 #if !CONFIG_IS_ENABLED(DM_I2C)
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
+   i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED2, CONFIG_SYS_OMAP24_I2C_SLAVE2);
 #endif
if (ti_i2c_eeprom_am_get(CONFIG_EEPROM_BUS_ADDRESS,
 CONFIG_EEPROM_CHIP_ADDRESS))
diff --git a/board/ti/am335x/board.h b/board/ti/am335x/board.h
index 48df914af9..c2962111c1 100644
--- a/board/ti/am335x/board.h
+++ b/board/ti/am335x/board.h
@@ -93,5 +93,6 @@ void enable_uart3_pin_mux(void);
 void enable_uart4_pin_mux(void);
 void enable_uart5_pin_mux(void);
 void enable_i2c0_pin_mux(void);
+void enable_i2c2_pin_mux(void);
 void enable_board_pin_mux(void);
 #endif
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 03adcd2b76..e450ff64d8 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -124,6 +124,14 @@ static struct module_pin_mux i2c1_pin_mux[] = {
{-1},
 };
 
+static struct module_pin_mux i2c2_pin_mux[] = {
+   {OFFSET(uart1_ctsn), (MODE(3) | RXACTIVE |
+   PULLUDEN | PULLUP_EN | SLEWCTRL)},  /* I2C_DATA */
+   {OFFSET(uart1_rtsn), (MODE(3) | RXACTIVE |
+   PULLUDEN | PULLUP_EN | SLEWCTRL)},  /* I2C_SCLK */
+   {-1},
+};
+
 static struct module_pin_mux spi0_pin_mux[] = {
{OFFSET(spi0_sclk), (MODE(0) | RXACTIVE | PULLUDEN)},   /* SPI0_SCLK */
{OFFSET(spi0_d0), (MODE(0) | RXACTIVE |
@@ -308,6 +316,11 @@ void enable_i2c0_pin_mux(void)
configure_module_pin_mux(i2c0_pin_mux);
 }
 
+void enable_i2c2_pin_mux(void)
+{
+   configure_module_pin_mux(i2c2_pin_mux);
+}
+
 /*
  * The AM335x GP EVM, if daughter card(s) are connected, can have 8
  * different profiles.  These profiles determine what peripherals are
@@ -367,6 +380,7 @@ void enable_board_pin_mux(void)
 #else
configure_module_pin_mux(mmc1_pin_mux);
 #endif
+   configure_module_pin_mux(i2c2_pin_mux);
} else if (board_is_gp_evm()) {
/* General Purpose EVM */
unsigned short profile = detect_daughter_board_profile();
@@ -411,6 +425,7 @@ void enable_board_pin_mux(void)
 #else
configure_module_pin_mux(mmc1_pin_mux);
 #endif
+   configure_module_pin_mux(i2c2_pin_mux);
} else if (board_is_pb()) {
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
-- 
2.17.1

[PATCH v5 07/10] arm: sunxi: add support for DIP detection to CHIP board

[Kory Maincent]

Add the extension_board_scan specific function to scan the information
of the EEPROM on one-wire and fill the extension struct.
Add the Kconfig symbol to enable the needs to detect DIPs.

Signed-off-by: Kory Maincent 
Reviewed-by: Maxime Ripard 
---

Change since v1:
- Replace TARGET_CHIP options by CHIP_DIP_SCAN

Change since v2:
- Fix typo
- Place the Kconfig symbol in that patch

Change since v3:
- Replace imply CMD_EXTENSION by select option. Remove the build test on
  CMD_EXTENSION in the chip.c file.

 arch/arm/mach-sunxi/Kconfig |   9 
 board/sunxi/Makefile|   1 +
 board/sunxi/chip.c  | 100 
 3 files changed, 110 insertions(+)
 create mode 100644 board/sunxi/chip.c

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 8e9012dbbf..bc8509b72a 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1089,3 +1089,12 @@ config BLUETOOTH_DT_DEVICE_FIXUP
  flipped elsewise.
 
 endif
+
+config CHIP_DIP_SCAN
+   bool "Enable DIPs detection for CHIP board"
+   select SUPPORT_EXTENSION_SCAN
+   select W1
+   select W1_GPIO
+   select W1_EEPROM
+   select W1_EEPROM_DS24XXX
+   select CMD_EXTENSION
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index c4e13f8c38..d96b7897b6 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_SUN7I_GMAC)  += gmac.o
 obj-$(CONFIG_MACH_SUN4I)   += dram_sun4i_auto.o
 obj-$(CONFIG_MACH_SUN5I)   += dram_sun5i_auto.o
 obj-$(CONFIG_MACH_SUN7I)   += dram_sun5i_auto.o
+obj-$(CONFIG_CHIP_DIP_SCAN)+= chip.o
diff --git a/board/sunxi/chip.c b/board/sunxi/chip.c
new file mode 100644
index 00..cde04bebe9
--- /dev/null
+++ b/board/sunxi/chip.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021
+ * Köry Maincent, Bootlin, 
+ * Based on initial code from Maxime Ripard
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define for_each_w1_device(b, d) \
+   for (device_find_first_child(b, d); *d; device_find_next_child(d))
+
+#define dip_convert(field) \
+   (   \
+   (sizeof(field) == 1) ? field :  \
+   (sizeof(field) == 2) ? be16_to_cpu(field) : \
+   (sizeof(field) == 4) ? be32_to_cpu(field) : \
+   -1  \
+   )
+
+#define DIP_MAGIC  0x50494843  /* CHIP */
+
+struct dip_w1_header {
+   u32 magic;  /* CHIP */
+   u8  version;/* spec version */
+   u32 vendor_id;
+   u16 product_id;
+   u8  product_version;
+   charvendor_name[32];
+   charproduct_name[32];
+   u8  rsvd[36];   /* rsvd for future spec versions */
+   u8  data[16];   /* user data, per-dip specific */
+} __packed;
+
+int extension_board_scan(struct list_head *extension_list)
+{
+   struct extension *dip;
+   struct dip_w1_header w1_header;
+   struct udevice *bus, *dev;
+   u32 vid;
+   u16 pid;
+   int ret;
+
+   int num_dip = 0;
+
+   sunxi_gpio_set_pull(SUNXI_GPD(2), SUNXI_GPIO_PULL_UP);
+
+   ret = w1_get_bus(0, );
+   if (ret) {
+   printf("one wire interface not found\n");
+   return 0;
+   }
+
+   for_each_w1_device(bus, ) {
+   if (w1_get_device_family(dev) != W1_FAMILY_DS2431)
+   continue;
+
+   ret = device_probe(dev);
+   if (ret) {
+   printf("Couldn't probe device %s: error %d",
+  dev->name, ret);
+   continue;
+   }
+
+   w1_eeprom_read_buf(dev, 0, (u8 *)_header, sizeof(w1_header));
+
+   if (w1_header.magic != DIP_MAGIC)
+   continue;
+
+   vid = dip_convert(w1_header.vendor_id);
+   pid = dip_convert(w1_header.product_id);
+
+   printf("DIP: %s (0x%x) from %s (0x%x)\n",
+  w1_header.product_name, pid,
+  w1_header.vendor_name, vid);
+
+   dip = calloc(1, sizeof(struct extension));
+   if (!dip) {
+   printf("Error in memory allocation\n");
+   return num_dip;
+   }
+
+   snprintf(dip->overlay, sizeof(dip->overlay), "dip-%x-%x.dtbo",
+vid, pid);
+   strncpy(dip->name, w1_header.product_name, 32);
+   strncpy(dip->owner, w1_header.vendor_name, 32);
+   list_add_tail(>list, extension_list);
+   num_dip++;
+   }
+   return num_dip;
+}
-- 
2.17.1

[PATCH v5 06/10] w1: replace dt detection by automatic detection

[Kory Maincent]

This patch changes the functioning of the detection of w1 devices.
The old way was a comparison between detected w1 and the ones described in
the device tree. Now it will just look for the driver matching the family
id of the w1 detected.

The patch is inspired from Maxime Ripard code.

Signed-off-by: Kory Maincent 
Reviewed-by: Maxime Ripard 
---

Change since v2:
- drop the remove action of devicetree match in the W1 EEPROMs drivers.
- move the w1_device_register function to w1-uclass.
- update the w1_device_register function to be compatible with automatic
  detection and devicetree detection. I will not bind the device if it as
  been found in the devicetree.
- update the w1 device driver list to have only two parameters in the
  U_BOOT_W1_DEVICE function.

 drivers/w1-eeprom/ds24xxx.c  |  7 +++
 drivers/w1-eeprom/ds2502.c   |  6 +++
 drivers/w1-eeprom/w1-eeprom-uclass.c | 31 
 drivers/w1/w1-uclass.c   | 76 +++-
 include/w1-eeprom.h  |  2 -
 include/w1.h | 17 +++
 6 files changed, 104 insertions(+), 35 deletions(-)

diff --git a/drivers/w1-eeprom/ds24xxx.c b/drivers/w1-eeprom/ds24xxx.c
index d12fd5754e..4be378b43d 100644
--- a/drivers/w1-eeprom/ds24xxx.c
+++ b/drivers/w1-eeprom/ds24xxx.c
@@ -53,3 +53,10 @@ U_BOOT_DRIVER(ds24xxx) = {
.ops= _ops,
.probe  = ds24xxx_probe,
 };
+
+u8 family_supported[] = {
+   W1_FAMILY_DS24B33,
+   W1_FAMILY_DS2431,
+};
+
+U_BOOT_W1_DEVICE(ds24xxx, family_supported);
diff --git a/drivers/w1-eeprom/ds2502.c b/drivers/w1-eeprom/ds2502.c
index b3d68d7f05..a67f5edd0f 100644
--- a/drivers/w1-eeprom/ds2502.c
+++ b/drivers/w1-eeprom/ds2502.c
@@ -243,3 +243,9 @@ U_BOOT_DRIVER(ds2502) = {
.ops= _ops,
.probe  = ds2502_probe,
 };
+
+u8 family_supported[] = {
+   W1_FAMILY_DS2502,
+};
+
+U_BOOT_W1_DEVICE(ds2502, family_supported);
diff --git a/drivers/w1-eeprom/w1-eeprom-uclass.c 
b/drivers/w1-eeprom/w1-eeprom-uclass.c
index 97a9d43b03..7a02af3dd6 100644
--- a/drivers/w1-eeprom/w1-eeprom-uclass.c
+++ b/drivers/w1-eeprom/w1-eeprom-uclass.c
@@ -37,37 +37,6 @@ int w1_eeprom_read_buf(struct udevice *dev, unsigned int 
offset,
return ops->read_buf(dev, offset, buf, count);
 }
 
-int w1_eeprom_register_new_device(u64 id)
-{
-   u8 family = id & 0xff;
-   int ret;
-   struct udevice *dev;
-
-   for (ret = uclass_first_device(UCLASS_W1_EEPROM, );
-!ret && dev;
-uclass_next_device()) {
-   if (ret || !dev) {
-   debug("cannot find w1 eeprom dev\n");
-   return ret;
-   }
-   if (dev_get_driver_data(dev) == family) {
-   struct w1_device *w1;
-
-   w1 = dev_get_parent_plat(dev);
-   if (w1->id) /* device already in use */
-   continue;
-   w1->id = id;
-   debug("%s: Match found: %s:%s %llx\n", __func__,
- dev->name, dev->driver->name, id);
-   return 0;
-   }
-   }
-
-   debug("%s: No matches found: error %d\n", __func__, ret);
-
-   return ret;
-}
-
 int w1_eeprom_get_id(struct udevice *dev, u64 *id)
 {
struct w1_device *w1 = dev_get_parent_plat(dev);
diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
index 8bc6cb13f4..16aeeb6303 100644
--- a/drivers/w1/w1-uclass.c
+++ b/drivers/w1/w1-uclass.c
@@ -4,9 +4,11 @@
  * Copyright (c) 2015 Free Electrons
  * Copyright (c) 2015 NextThing Co.
  * Copyright (c) 2018 Microchip Technology, Inc.
+ * Copyright (c) 2021 Bootlin
  *
  * Maxime Ripard 
  * Eugen Hristev 
+ * Kory Maincent 
  *
  */
 
@@ -26,6 +28,76 @@ struct w1_bus {
u64 search_id;
 };
 
+int w1_bus_find_dev(const struct udevice *bus, u64 id, struct udevice
+**devp)
+{
+   struct udevice *dev;
+   u8 family = id & 0xff;
+   int ret;
+
+   for (ret = uclass_first_device(UCLASS_W1_EEPROM, );
+   !ret && dev;
+   uclass_next_device()) {
+   if (ret || !dev) {
+   debug("cannot find w1 eeprom dev\n");
+   return -ENODEV;
+   }
+
+   if (dev_get_driver_data(dev) == family) {
+   *devp = dev;
+   return 0;
+   }
+   }
+
+   return -ENODEV;
+}
+
+int w1_register_new_device(u64 id, struct udevice *bus)
+{
+   u8 family = id & 0xff;
+   int n_ents, ret;
+   struct udevice *dev;
+
+   struct w1_driver_entry *start, *entry;
+
+   start = ll_entry_start(struct w1_driver_entry, w1_driver_entry);
+   n_ents = ll_entry_count(struct w1_driver_entry, w1_driver_entry);
+
+   for (entry = start; entry != start + n_ents; entry++) {
+   const u8 *match_family;
+   

[PATCH v5 08/10] configs: CHIP: add support for DIP detect functionality

[Kory Maincent]

This commit enables using the extension board detection mechanism on
CHIP boards

Signed-off-by: Kory Maincent 
Acked-by: Maxime Ripard 
---
 configs/CHIP_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/CHIP_defconfig b/configs/CHIP_defconfig
index a70ee31d40..8d40da090b 100644
--- a/configs/CHIP_defconfig
+++ b/configs/CHIP_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
+CONFIG_CHIP_DIP_SCAN=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
 CONFIG_USB0_VBUS_PIN="PB10"
-- 
2.17.1

[PATCH v5 05/10] am57xx: add support for cape detect functionality

[Kory Maincent]

This commit enables using the extension board detection mechanism on
AM57xx based platforms.

Signed-off-by: Kory Maincent 
---

Change Since v1:
 - Remove CAPE_EEPROM_BUS_NUM from the header

 arch/arm/mach-omap2/omap5/Kconfig | 1 +
 board/ti/am57xx/board.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap5/Kconfig 
b/arch/arm/mach-omap2/omap5/Kconfig
index a7132dae09..4c2f990b28 100644
--- a/arch/arm/mach-omap2/omap5/Kconfig
+++ b/arch/arm/mach-omap2/omap5/Kconfig
@@ -36,6 +36,7 @@ config TARGET_AM57XX_EVM
select CMD_DDR3
select DRA7XX
select TI_I2C_BOARD_DETECT
+   select SUPPORT_EXTENSION_SCAN
imply DM_THERMAL
imply SCSI
imply SPL_THERMAL
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 73063faee6..05c26c74d9 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -43,6 +43,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/cape_detect.h"
 #include "mux_data.h"
 
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
-- 
2.17.1

[PATCH v5 02/10] cmd: add support for a new "extension" command

[Kory Maincent]

This patch adds a new "extension" command, which aims at detecting
extension boards connected to the hardware platform, and apply the
Device Tree overlays that describe the hardware present on those
extension boards.

In order to enable this mechanism, board-specific code must implement
the extension_board_scan() function that fills in a linked list of
"struct extension", each describing one extension board. In addition,
the board-specific code must select the SUPPORT_EXTENSION_SCAN Kconfig
boolean.

Based on this:

 - "extension scan" makes the generic code call the board-specific
   extension_board_scan() function to retrieve the list of detected
   extension boards.

 - "extension list" allows to list the detected extension boards.

 - "extension apply |all" allows to apply the Device Tree
   overlay(s) corresponding to one, or all, extension boards

The latter requires two environment variables to exist and set one variable
to run:

 - extension_overlay_addr: the RAM address where to load the Device
   Tree overlays

 - extension_overlay_cmd: the U-Boot command to load one overlay.
   Indeed, the location and mechanism to load DT overlays is very setup
   specific.

 - extension_overlay_name: set by the command: the name of the DT which
   will be load during the execution.

When calling the command described in the extension_overlay_cmd
variable, the variable extension_overlay_name will be defined. So a
typical extension_overlay_cmd will look like this:

  extension_overlay_cmd=load mmc 0:1 $extension_overlay_addr 
/boot/$extension_overlay_name

Here is an example on how to use it:
=> run loadfdt
=> fdt addr $fdtaddr
=> setenv extension_overlay_addr 0x1000
=> setenv extension_overlay_cmd 'load mmc 0:1 ${extension_overlay_addr} 
/boot/${extension_overlay_name}'
=> extension scan
Found 1 extension board(s).
=> extension apply 0
519 bytes read in 3 ms (168.9 KiB/s)

Signed-off-by: Kory Maincent 
Reviewed-by: Maxime Ripard 
---

Change since v1:
 - Add list_for_each_entry loop bracket
 - Move doc location and update it to rST

Change since v3:
 - Update commit message

 cmd/Kconfig   |  12 +++
 cmd/Makefile  |   1 +
 cmd/extension_board.c | 167 ++
 doc/usage/extension.rst   | 111 +
 include/extension_board.h |  31 +++
 5 files changed, 322 insertions(+)
 create mode 100644 cmd/extension_board.c
 create mode 100644 doc/usage/extension.rst
 create mode 100644 include/extension_board.h

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 9e8b69258f..f962bb7141 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -332,6 +332,18 @@ config CMD_FDT
help
  Do FDT related setup before booting into the Operating System.
 
+config SUPPORT_EXTENSION_SCAN
+   bool
+
+config CMD_EXTENSION
+   bool "Extension board management command"
+   select CMD_FDT
+   depends on SUPPORT_EXTENSION_SCAN
+   help
+ Enables the "extension" command, which allows to detect
+ extension boards connected to the system, and apply
+ corresponding Device Tree overlays.
+
 config CMD_GO
bool "go"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index 4977fa15f4..9d10e07f0e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_CMD_DIAG) += diag.o
 endif
 obj-$(CONFIG_CMD_ADTIMG) += adtimg.o
 obj-$(CONFIG_CMD_ABOOTIMG) += abootimg.o
+obj-$(CONFIG_CMD_EXTENSION) += extension_board.o
 obj-$(CONFIG_CMD_ECHO) += echo.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
 obj-$(CONFIG_CMD_EEPROM) += eeprom.o
diff --git a/cmd/extension_board.c b/cmd/extension_board.c
new file mode 100644
index 00..6ad9765d84
--- /dev/null
+++ b/cmd/extension_board.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021
+ * Köry Maincent, Bootlin, 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(extension_list);
+
+static int extension_apply(struct extension *extension)
+{
+   char *overlay_cmd;
+   ulong extrasize, overlay_addr;
+   struct fdt_header *blob;
+
+   if (!working_fdt) {
+   printf("No FDT memory address configured. Please configure\n"
+  "the FDT address via \"fdt addr \" command.\n");
+   return CMD_RET_FAILURE;
+   }
+
+   overlay_cmd = env_get("extension_overlay_cmd");
+   if (!overlay_cmd) {
+   printf("Environment extension_overlay_cmd is missing\n");
+   return CMD_RET_FAILURE;
+   }
+
+   overlay_addr = env_get_hex("extension_overlay_addr", 0);
+   if (!overlay_addr) {
+   printf("Environment extension_overlay_addr is missing\n");
+   return CMD_RET_FAILURE;
+   }
+
+   env_set("extension_overlay_name", extension->overlay);
+   if (run_command(overlay_cmd, 0) != 0)
+   return CMD_RET_FAILURE;
+
+   extrasize = 

[PATCH v5 04/10] ti/common: add support for extension_scan_board function

[Kory Maincent]

The BeagleBone platforms all use a common mechanism to discover and
identify extension boards (called "capes"): each extension board has an
I2C-connected EEPROM describing itself.

This patch implements a generic extension_scan_board() feature that can
be used by all BeagleBone platforms to read those I2C EEPROMs and fill
in the list of "extension" structures.

Following commits will enable this common logic on two BeagleBone
platforms.

Signed-off-by: Kory Maincent 
---

Change Since v1:
 - Use CAPE_EEPROM_BUS_NUM in Kconfig in place of the board header

 board/ti/common/Kconfig   |  6 +++
 board/ti/common/Makefile  |  1 +
 board/ti/common/cape_detect.c | 96 +++
 board/ti/common/cape_detect.h | 28 ++
 4 files changed, 131 insertions(+)
 create mode 100644 board/ti/common/cape_detect.c
 create mode 100644 board/ti/common/cape_detect.h

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 9ead7ca038..49edd98014 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -16,6 +16,12 @@ config EEPROM_CHIP_ADDRESS
default 0x50
depends on TI_I2C_BOARD_DETECT
 
+config CAPE_EEPROM_BUS_NUM
+   int "Cape EEPROM's I2C bus address"
+   range 0 8
+   default 2
+   depends on CMD_EXTENSION
+
 config TI_COMMON_CMD_OPTIONS
bool "Enable cmd options on TI platforms"
imply CMD_ASKENV
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index cb97f226ae..3172d87b46 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -2,3 +2,4 @@
 # Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
 
 obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
+obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
diff --git a/board/ti/common/cape_detect.c b/board/ti/common/cape_detect.c
new file mode 100644
index 00..2e6105cfbf
--- /dev/null
+++ b/board/ti/common/cape_detect.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021
+ * Köry Maincent, Bootlin, 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "cape_detect.h"
+
+static void sanitize_field(char *text, size_t size)
+{
+   char *c = NULL;
+
+   for (c = text; c < text + (int)size; c++) {
+   if (*c == 0xFF)
+   *c = 0;
+   }
+}
+
+int extension_board_scan(struct list_head *extension_list)
+{
+   struct extension *cape;
+   struct am335x_cape_eeprom_id eeprom_header;
+
+   int num_capes = 0;
+   int ret, i;
+   struct udevice *dev;
+   unsigned char addr;
+
+   char process_cape_part_number[17] = {'0'};
+   char process_cape_version[5] = {'0'};
+   uint8_t cursor = 0;
+
+   for (addr = CAPE_EEPROM_FIRST_ADDR; addr <= CAPE_EEPROM_LAST_ADDR; 
addr++) {
+   ret = i2c_get_chip_for_busnum(CONFIG_CAPE_EEPROM_BUS_NUM, addr, 
1, );
+   if (ret)
+   continue;
+
+   /* Move the read cursor to the beginning of the EEPROM */
+   dm_i2c_write(dev, 0, , 1);
+   ret = dm_i2c_read(dev, 0, (uint8_t *)_header,
+ sizeof(struct am335x_cape_eeprom_id));
+   if (ret) {
+   printf("Cannot read i2c EEPROM\n");
+   continue;
+   }
+
+   if (eeprom_header.header != CAPE_MAGIC)
+   continue;
+
+   sanitize_field(eeprom_header.board_name, 
sizeof(eeprom_header.board_name));
+   sanitize_field(eeprom_header.version, 
sizeof(eeprom_header.version));
+   sanitize_field(eeprom_header.manufacturer, 
sizeof(eeprom_header.manufacturer));
+   sanitize_field(eeprom_header.part_number, 
sizeof(eeprom_header.part_number));
+
+   /* Process cape part_number */
+   memset(process_cape_part_number, 0, 
sizeof(process_cape_part_number));
+   strncpy(process_cape_part_number, eeprom_header.part_number, 
16);
+   /* Some capes end with '.' */
+   for (i = 15; i >= 0; i--) {
+   if (process_cape_part_number[i] == '.')
+   process_cape_part_number[i] = '\0';
+   else
+   break;
+   }
+
+   /* Process cape version */
+   memset(process_cape_version, 0, sizeof(process_cape_version));
+   strncpy(process_cape_version, eeprom_header.version, 4);
+   for (i = 0; i < 4; i++) {
+   if (process_cape_version[i] == 0)
+   process_cape_version[i] = '0';
+   }
+
+   printf("BeagleBone Cape: %s (0x%x)\n", 
eeprom_header.board_name, addr);
+
+   cape = calloc(1, sizeof(struct extension));
+   if (!cape) {
+   printf("Error in memory allocation\n");
+   

[PATCH v5 03/10] pytest: add sandbox test for "extension" command

[Kory Maincent]

This commit extends the sandbox to implement a dummy
extension_board_scan() function and enables the extension command in
the sandbox configuration. It then adds a test that checks the proper
functionality of the extension command by applying two Device Tree
overlays to the sandbox Device Tree.

Signed-off-by: Kory Maincent 
---
 arch/Kconfig|  2 ++
 arch/sandbox/dts/Makefile   |  1 +
 arch/sandbox/dts/overlay0.dts   |  9 ++
 arch/sandbox/dts/overlay1.dts   |  9 ++
 board/sandbox/sandbox.c | 23 +++
 test/py/tests/test_extension.py | 52 +
 6 files changed, 96 insertions(+)
 create mode 100644 arch/sandbox/dts/overlay0.dts
 create mode 100644 arch/sandbox/dts/overlay1.dts
 create mode 100644 test/py/tests/test_extension.py

diff --git a/arch/Kconfig b/arch/Kconfig
index e61a7528ba..6c4b81a486 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -121,6 +121,7 @@ config SANDBOX
select SUPPORT_OF_CONTROL
select SYSRESET_CMD_POWEROFF
select IRQ
+   select SUPPORT_EXTENSION_SCAN
imply BITREVERSE
select BLOBLIST
imply CMD_DM
@@ -165,6 +166,7 @@ config SANDBOX
imply BOOTARGS_SUBST
imply PHY_FIXED
imply DM_DSA
+   imply CMD_EXTENSION
 
 config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/Makefile b/arch/sandbox/dts/Makefile
index d231dc2877..3e5dc67d53 100644
--- a/arch/sandbox/dts/Makefile
+++ b/arch/sandbox/dts/Makefile
@@ -6,6 +6,7 @@ else
 dtb-$(CONFIG_SANDBOX) += sandbox.dtb
 endif
 dtb-$(CONFIG_UT_DM) += test.dtb
+dtb-$(CONFIG_CMD_EXTENSION) += overlay0.dtbo overlay1.dtbo
 
 targets += $(dtb-y)
 
diff --git a/arch/sandbox/dts/overlay0.dts b/arch/sandbox/dts/overlay0.dts
new file mode 100644
index 00..70c6cf77aa
--- /dev/null
+++ b/arch/sandbox/dts/overlay0.dts
@@ -0,0 +1,9 @@
+/dts-v1/;
+/plugin/;
+
+&{/buttons} {
+   btn3 {
+   gpios = <_a 5 0>;
+   label = "button3";
+   };
+};
diff --git a/arch/sandbox/dts/overlay1.dts b/arch/sandbox/dts/overlay1.dts
new file mode 100644
index 00..51621b3110
--- /dev/null
+++ b/arch/sandbox/dts/overlay1.dts
@@ -0,0 +1,9 @@
+/dts-v1/;
+/plugin/;
+
+&{/buttons} {
+   btn4 {
+   gpios = <_a 5 0>;
+   label = "button4";
+   };
+};
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 902b99ed50..dcd73451a3 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -14,6 +14,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 /*
  * Pointer to initial global data area
@@ -79,6 +82,26 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
return fdt_add_mem_rsv(fdt, 0x00d02000, 0x4000);
 }
 
+#ifdef CONFIG_CMD_EXTENSION
+int extension_board_scan(struct list_head *extension_list)
+{
+   struct extension *extension;
+   int i;
+
+   for (i = 0; i < 2; i++) {
+   extension = calloc(1, sizeof(struct extension));
+   snprintf(extension->overlay, sizeof(extension->overlay), 
"overlay%d.dtbo", i);
+   snprintf(extension->name, sizeof(extension->name), "extension 
board %d", i);
+   snprintf(extension->owner, sizeof(extension->owner), "sandbox");
+   snprintf(extension->version, sizeof(extension->version), "1.1");
+   snprintf(extension->other, sizeof(extension->other), 
"Fictionnal extension board");
+   list_add_tail(>list, extension_list);
+   }
+
+   return i;
+}
+#endif
+
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
diff --git a/test/py/tests/test_extension.py b/test/py/tests/test_extension.py
new file mode 100644
index 00..4712f9bfe3
--- /dev/null
+++ b/test/py/tests/test_extension.py
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier:  GPL-2.0+
+# Copyright (c) 2020
+# Author: Kory Maincent 
+
+# Test U-Boot's "extension" commands.
+
+import os
+import pytest
+import u_boot_utils
+
+overlay_addr = 0x1000
+
+SANDBOX_DTB='arch/sandbox/dts/sandbox.dtb'
+OVERLAY_DIR='arch/sandbox/dts/'
+
+def load_dtb(u_boot_console):
+u_boot_console.log.action('Loading devicetree to RAM...')
+u_boot_console.run_command('host load hostfs - $fdt_addr_r %s' % 
(os.path.join(u_boot_console.config.build_dir, SANDBOX_DTB)))
+u_boot_console.run_command('fdt addr $fdt_addr_r')
+
+@pytest.mark.buildconfigspec('cmd_fdt')
+def test_extension(u_boot_console):
+"""Test the 'extension' command."""
+
+load_dtb(u_boot_console)
+
+output = u_boot_console.run_command('extension list')
+assert('No extension' in output)
+
+output = u_boot_console.run_command('extension scan')
+assert output == 'Found 2 extension board(s).'
+
+output = u_boot_console.run_command('extension list')
+assert('overlay0.dtbo' in output)
+assert('overlay1.dtbo' in output)
+
+u_boot_console.run_command_list([
+'setenv extension_overlay_addr %s' % (overlay_addr),
+   

[PATCH v5 01/10] fdt_support: move fdt_valid from cmd_fdt.c to fdt_support.c

[Kory Maincent]

Move the fdt_valid function to fdt_support.
This changes allow to be able to test the validity of a devicetree in
other c files.

Update code syntax.

Signed-off-by: Kory Maincent 
Reviewed-by: Tom Rini 
Reviewed-by: Maxime Ripard 
---
 cmd/fdt.c | 49 ---
 common/fdt_support.c  | 46 
 include/fdt_support.h |  2 ++
 3 files changed, 48 insertions(+), 49 deletions(-)

diff --git a/cmd/fdt.c b/cmd/fdt.c
index 89ab572d8d..f1e2fc2fd8 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -27,7 +27,6 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
-static int fdt_valid(struct fdt_header **blobp);
 static int fdt_parse_prop(char *const*newval, int count, char *data, int *len);
 static int fdt_print(const char *pathp, char *prop, int depth);
 static int is_printable_string(const void *data, int len);
@@ -732,54 +731,6 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
 
 //
 
-/**
- * fdt_valid() - Check if an FDT is valid. If not, change it to NULL
- *
- * @blobp: Pointer to FDT pointer
- * @return 1 if OK, 0 if bad (in which case *blobp is set to NULL)
- */
-static int fdt_valid(struct fdt_header **blobp)
-{
-   const void *blob = *blobp;
-   int err;
-
-   if (blob == NULL) {
-   printf ("The address of the fdt is invalid (NULL).\n");
-   return 0;
-   }
-
-   err = fdt_check_header(blob);
-   if (err == 0)
-   return 1;   /* valid */
-
-   if (err < 0) {
-   printf("libfdt fdt_check_header(): %s", fdt_strerror(err));
-   /*
-* Be more informative on bad version.
-*/
-   if (err == -FDT_ERR_BADVERSION) {
-   if (fdt_version(blob) <
-   FDT_FIRST_SUPPORTED_VERSION) {
-   printf (" - too old, fdt %d < %d",
-   fdt_version(blob),
-   FDT_FIRST_SUPPORTED_VERSION);
-   }
-   if (fdt_last_comp_version(blob) >
-   FDT_LAST_SUPPORTED_VERSION) {
-   printf (" - too new, fdt %d > %d",
-   fdt_version(blob),
-   FDT_LAST_SUPPORTED_VERSION);
-   }
-   }
-   printf("\n");
-   *blobp = NULL;
-   return 0;
-   }
-   return 1;
-}
-
-//
-
 /*
  * Parse the user's input, partially heuristic.  Valid formats:
  * <0x00112233 4 05>   - an array of cells.  Numbers follow standard
diff --git a/common/fdt_support.c b/common/fdt_support.c
index e624bbdf40..9ff512d9cf 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1896,3 +1896,49 @@ int fdt_overlay_apply_verbose(void *fdt, void *fdto)
return err;
 }
 #endif
+
+/**
+ * fdt_valid() - Check if an FDT is valid. If not, change it to NULL
+ *
+ * @blobp: Pointer to FDT pointer
+ * @return 1 if OK, 0 if bad (in which case *blobp is set to NULL)
+ */
+int fdt_valid(struct fdt_header **blobp)
+{
+   const void *blob = *blobp;
+   int err;
+
+   if (!blob) {
+   printf("The address of the fdt is invalid (NULL).\n");
+   return 0;
+   }
+
+   err = fdt_check_header(blob);
+   if (err == 0)
+   return 1;   /* valid */
+
+   if (err < 0) {
+   printf("libfdt fdt_check_header(): %s", fdt_strerror(err));
+   /*
+* Be more informative on bad version.
+*/
+   if (err == -FDT_ERR_BADVERSION) {
+   if (fdt_version(blob) <
+   FDT_FIRST_SUPPORTED_VERSION) {
+   printf(" - too old, fdt %d < %d",
+  fdt_version(blob),
+  FDT_FIRST_SUPPORTED_VERSION);
+   }
+   if (fdt_last_comp_version(blob) >
+   FDT_LAST_SUPPORTED_VERSION) {
+   printf(" - too new, fdt %d > %d",
+  fdt_version(blob),
+  FDT_LAST_SUPPORTED_VERSION);
+   }
+   }
+   printf("\n");
+   *blobp = NULL;
+   return 0;
+   }
+   return 1;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 46eb1dbbb2..412cbb99c1 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -342,6 +342,8 @@ int fdt_setup_simplefb_node(void *fdt, int node, u64 
base_address, u32 width,
 
 int fdt_overlay_apply_verbose(void *fdt, void *fdto);
 
+int 

[PATCH v5 00/10] Add support for extension boards detection and DT overlays application

[Kory Maincent]

This series of patches aims at proposing a generic U-Boot mechanism to
detect extension boards connected to the HW platform, and apply the
appropriate Device Tree overlays depending on the detected extension
boards.

Indeed, numerous popular platforms, such as the BeagleBone or the
RaspberryPi, feature some kind of extension board mechanism. These
extension boards are often discoverable through some kind of EEPROM
(connected on I2C, 1-wire, etc.) and require Device Tree overlays to be
applied at the U-Boot level to provide a complete HW description to the
Linux kernel. However, currently this logic is usually implemented
ad-hoc in downstream forks of U-Boot.

This series proposes to bring a HW-agnostic and generic solution to
this problem to upstream U-Boot. The series shows that it is generic
enough by implementing its usage for 2 different families of HW
platforms and expansion boards:

 - The BeagleBone Black and BeagleBone AI, that use extension boards
   where the EEPROM describing the extension boards is connected over
   I2C.

 - The CHIP, that uses extension boards where the EEPROM describing the
   extension boards is connected over 1-wire.

The patch series implements a new command called "extension", with two
sub-commands:

 - "extension scan" to detect available extension boards

 - "extension list" will simply list the detected extension boards

 - "extension apply" will allow to apply the Device Tree overlays
   corresponding to one extension board or to all expansion boards

Note that the name "extension" has been chosen to not refer to any
particular board-specific terminology for extension boards ("cape" for
BeagleBone, "DIP" for CHIP, "hat" for RaspberryPi, etc.). However, we
welcome suggestions of other names and are definitely willing to use a
different naming.

The "extension apply" command requires two environment variables to be
defined so that it knows how to apply DT overlays. This is described
in more details in PATCH 1.

This generic code requires board-specific code for the detection and
enumeration of extension boards. This is simply implemented in the form
of a board-specific extension_board_scan() function, which fills in a
list of detected extension boards.

In detail:

 - PATCH 1 move fdt_valid function to fdt_support file
 - PATCH 2 implements the generic command and logic
 - PATCH 3 implements the python test for the "extension" command
 - PATCH 4 implements the board-specific code for the BeagleBone platforms
 - PATCH 5 enables the mechanism for the BeagleBone AI
 - PATCH 6 review the detection mechanism of one-wire devices
 - PATCH 7 and 8 enable the mechanism for the CHIP
 - PATCH 9 and 10 enable the mechanism for the BeagleBone Black

Thanks in advance for your review and feedback

Change since v1:
- remove the one wire devicetree description of the CHIP board
- rewrite the detection of w1 to makes it automatic and not devicetree
  dependent
- replace Kconfig CHIP board target by Kconfig CHIP_DIP_SCAN simple option
- rewrite doc to rST syntax
- make few syntax update

Change since v2:
- review the detection of w1 to makes it compatible with automatic
  detection alongside the devicetree description detection
- update the patch separation between the mechanism for the CHIP and the
  configuration activation

Change since v3:
- Update commit messages on the extension command patch
- Remove a test on CMD_EXTENSION in the chip.c file.

Change since v4:
- Rebase on master

Kory Maincent (10):
  fdt_support: move fdt_valid from cmd_fdt.c to fdt_support.c
  cmd: add support for a new "extension" command
  pytest: add sandbox test for "extension" command
  ti/common: add support for extension_scan_board function
  am57xx: add support for cape detect functionality
  w1: replace dt detection by automatic detection
  arm: sunxi: add support for DIP detection to CHIP board
  configs: CHIP: add support for DIP detect functionality
  arm: am335x: add support for i2c2 bus
  am335x: add support for cape detect functionality

 arch/Kconfig  |   2 +
 arch/arm/mach-omap2/am33xx/Kconfig|   1 +
 arch/arm/mach-omap2/am33xx/clock_am33xx.c |   1 +
 arch/arm/mach-omap2/omap5/Kconfig |   1 +
 arch/arm/mach-sunxi/Kconfig   |   9 ++
 arch/sandbox/dts/Makefile |   1 +
 arch/sandbox/dts/overlay0.dts |   9 ++
 arch/sandbox/dts/overlay1.dts |   9 ++
 board/sandbox/sandbox.c   |  23 +++
 board/sunxi/Makefile  |   1 +
 board/sunxi/chip.c| 100 +
 board/ti/am335x/board.c   |   3 +
 board/ti/am335x/board.h   |   1 +
 board/ti/am335x/mux.c |  15 ++
 board/ti/am57xx/board.c   |   1 +
 board/ti/common/Kconfig   |   6 +
 board/ti/common/Makefile  |   1 +
 board/ti/common/cape_detect.c |  96 +
 

Re: [PATCH v4 2/6] lib: ecdsa: Add skeleton to implement ecdsa verification in u-boot

[Simon Glass]

Hi Alex,

On Thu, 29 Apr 2021 at 10:10, Simon Glass  wrote:
>
> Hi Alex,
>
> On Mon, 26 Apr 2021 at 07:21, Alex G.  wrote:
> >
> >
> >
> > On 4/23/21 11:56 PM, Simon Glass wrote:
> > > Hi Tom, Alex,
> > >
> > > On Fri, 23 Apr 2021 at 12:47, Tom Rini  wrote:
> > >>
> > >> On Fri, Apr 23, 2021 at 11:55:57AM +1200, Simon Glass wrote:
> > >>> Hi Alex,
> > >>>
> > >>> On Thu, 22 Apr 2021 at 07:30, Alex G.  wrote:
> > 
> >  On 4/21/21 2:15 AM, Simon Glass wrote:
> > > Hi Alexandru,
> > >
> > > On Fri, 16 Apr 2021 at 08:07, Alexandru Gagniuc 
> > >  wrote:
> > >>
> > >> Prepare the source tree for accepting implementations of the ECDSA
> > >> algorithm. This patch deals with the boring aspects of Makefiles and
> > >> Kconfig files.
> > >>
> > >> Signed-off-by: Alexandru Gagniuc 
> > >> ---
> > >>include/image.h  | 10 +-
> > >>include/u-boot/rsa.h |  2 +-
> > >>lib/Kconfig  |  1 +
> > >>lib/Makefile |  1 +
> > >>lib/ecdsa/Kconfig| 23 +++
> > >>lib/ecdsa/Makefile   |  1 +
> > >>lib/ecdsa/ecdsa-verify.c | 13 +
> > >>7 files changed, 45 insertions(+), 6 deletions(-)
> > >>create mode 100644 lib/ecdsa/Kconfig
> > >>create mode 100644 lib/ecdsa/Makefile
> > >>create mode 100644 lib/ecdsa/ecdsa-verify.c
> > >
> > > Reviewed-by: Simon Glass 
> > >
> > > nit below
> > >
> > >>
> > >> diff --git a/include/image.h b/include/image.h
> > >> index 3ff3c035a7..9b95f6783b 100644
> > >> --- a/include/image.h
> > >> +++ b/include/image.h
> > >> @@ -1224,20 +1224,20 @@ int calculate_hash(const void *data, int 
> > >> data_len, const char *algo,
> > >>#if defined(USE_HOSTCC)
> > >># if defined(CONFIG_FIT_SIGNATURE)
> > >>#  define IMAGE_ENABLE_SIGN1
> > >> -#  define IMAGE_ENABLE_VERIFY  1
> > >> +#  define IMAGE_ENABLE_VERIFY_RSA  1
> > >>#  define IMAGE_ENABLE_VERIFY_ECDSA1
> > >>#  define FIT_IMAGE_ENABLE_VERIFY  1
> > >>#  include 
> > >># else
> > >>#  define IMAGE_ENABLE_SIGN0
> > >> -#  define IMAGE_ENABLE_VERIFY  0
> > >> +#  define IMAGE_ENABLE_VERIFY_RSA  0
> > >># define IMAGE_ENABLE_VERIFY_ECDSA 0
> > >>#  define FIT_IMAGE_ENABLE_VERIFY  0
> > >># endif
> > >>#else
> > >># define IMAGE_ENABLE_SIGN 0
> > >> -# define IMAGE_ENABLE_VERIFY   CONFIG_IS_ENABLED(RSA_VERIFY)
> > >> -# define IMAGE_ENABLE_VERIFY_ECDSA 0
> > >> +# define IMAGE_ENABLE_VERIFY_RSA   CONFIG_IS_ENABLED(RSA_VERIFY)
> > >> +# define IMAGE_ENABLE_VERIFY_ECDSA 
> > >> CONFIG_IS_ENABLED(ECDSA_VERIFY)
> > >
> > > Since we are using Kconfig now, can we drop this IMAGE_... stuff and
> > > just use CONFIG_IS_ENABLED() in the code?
> > 
> >  CONFIG_IS_ENABLED() doesn't work for host tools.
> > >>>
> > >>> I wonder if that and IS_ENABLED() can be fixed?
> > >>
> > >> Not super easily?  Some sort of seeing about cleaning up the code we
> > >> share with userspace would be nice, yes.  But it should also probably
> > >> means that for the user side of things we always enable a bunch of stuff
> > >> so that in the end we end up with (nearly) target-agnostic tools.
> > >
> > > (just to be clear, this discussion should not hold up this patch IMO)
> > >
> > > Yes and in fact at present we allow some things to be disabled in
> > > tools where we probably should not.
> > >
> > > My original question was about CONFIG_IS_ENABLED(). I wonder if it
> > > doesn't work because the CONFIG is not enabled or because of some
> > > other reason?
> >
> > CONFIG_IS_ENABLED() macro isn't available when compiling host tools. I
> > suspect nobody implemented it host-side?
>
> I think it should map to IS_ENABLED(). But also, do we include
> kconfig.h in the tools?

Just a note that I sent a series to enable CONFIG_IS_ENABLED on the host.

Regards,
Simon

Re: [PATCH 04/49] btrfs: Use U-Boot API for decompression

[Simon Glass]

Hi Marek,

On Mon, 3 May 2021 at 17:45, Marek Behun  wrote:
>
> On Mon,  3 May 2021 17:10:51 -0600
> Simon Glass  wrote:
>
> > Use the common function to avoid code duplication.
> >
> > Signed-off-by: Simon Glass 
>
> Is this tested? Why only zstd?

No, there are no tests for zstd, as I mentioned in the other patch.
Are you able to add some to the compression.c file? It should really
be done if we expect it to keep working in U-Boot.

The other compression algos already have a suitable function, so don't
need to be reworked.

Regards,
Simon

Re: [PATCH v3] dm: core: Add address translation in fdt_get_resource

[Simon Glass]

On Tue, 4 May 2021 at 04:02, Patrick Delaunay
 wrote:
>
> Today of_address_to_resource() is called only in
> ofnode_read_resource() for livetree support and
> fdt_get_resource() is called when livetree is not supported.
>
> The fdt_get_resource() doesn't do the address translation
> so when it is required, but the address translation is done
> by ofnode_read_resource() caller, for example in
> drivers/firmware/scmi/smt.c::scmi_dt_get_smt_buffer() {
> ...
> ret = ofnode_read_resource(args.node, 0, );
> if (ret)
> return ret;
>
> faddr = cpu_to_fdt32(resource.start);
> paddr = ofnode_translate_address(args.node, );
> ...
>
> The both behavior should be aligned and the address translation
> must be called in fdt_get_resource() and removed for each caller.
>
> Fixes: a44810123f9e ("dm: core: Add dev_read_resource() to read device 
> resources")
> Signed-off-by: Patrick Delaunay 
> ---
>
> This patch allows to remove the workaround in smci/smt.c
> introduced by [1].
>
> But it impact with all user of
> - ofnode_read_resource
> - ofnode_read_resource_byname
> - dev_read_resource
> - dev_read_resource_byname
>
> After my first check, the only impacts are in drivers/net/mscc_eswitch
> => I remove the unnecessary translate after code review,
>this patch need to be verify on real hardware
>
> I proposed to merge the workaround [1] as soon as possible to avoid issue
> on stm32mp1 platform and this patch can be merged when it will be acked
> by mscc_eswitch maintainers and other API users.
>
> [1] "scmi: translate the resource only when livetree is not activated"
> http://patchwork.ozlabs.org/project/uboot/list/?series=236526=*
>
>
> Changes in v3:
> - add test dm_test_read_resource
>
> Changes in v2:
> - remove translate in luton_switch.c:luton_probe()
>
>  drivers/firmware/scmi/smt.c   | 12 +
>  drivers/net/mscc_eswitch/jr2_switch.c |  4 +--
>  drivers/net/mscc_eswitch/luton_switch.c   |  5 +---
>  drivers/net/mscc_eswitch/ocelot_switch.c  |  4 +--
>  drivers/net/mscc_eswitch/serval_switch.c  |  4 +--
>  drivers/net/mscc_eswitch/servalt_switch.c |  4 +--
>  lib/fdtdec.c  |  6 -
>  test/dm/test-fdt.c| 33 +++
>  8 files changed, 44 insertions(+), 28 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v3 03/20] drivers: reset: Handle gracefully NULL pointers

[Simon Glass]

Hi Kishon,

On Tue, 4 May 2021 at 04:42, Kishon Vijay Abraham I  wrote:
>
> The reset framework provides devm_reset_control_get_optional()
> which can return NULL (not an error case). So all the other reset_ops
> should handle NULL gracefully. Prepare the way for a managed reset
> API by handling NULL pointers without crashing nor failing.
>
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/reset/reset-uclass.c | 35 ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)

I am still not a fan of this. There is no way to know whether the
reset API call actually did anything. Normally we return -EINVAL or
something like that when the value is invalid (e.g. see GPIO uclass).

The function you mention says:  * Returns a struct reset_ctl or a
dummy reset controller if it failed.

But it does not appear to do that?

Regards,
Simon

Re: [PATCH v3 01/20] dm: core: Add helper to compare node names

[Simon Glass]

Hi,

On Tue, 4 May 2021 at 04:42, Kishon Vijay Abraham I  wrote:
>
> Add helper to compare node names.
>
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/core/ofnode.c | 13 +
>  include/dm/ofnode.h   | 10 ++
>  2 files changed, 23 insertions(+)

Is there no change to last time?

Reviewed-by: Simon Glass 

Re: [PATCH 03/17] x86: Allow coreboot serial driver to guess the UART

[Andy Shevchenko]

On Tue, May 04, 2021 at 09:26:19AM -0600, Simon Glass wrote:
> On Fri, 30 Apr 2021 at 12:41, Andy Shevchenko  
> wrote:
> > On Fri, Apr 30, 2021 at 9:14 PM Simon Glass  wrote:
> > > On Thu, 29 Apr 2021 at 17:01, Bin Meng  wrote:
> > > > On Fri, Apr 30, 2021 at 12:10 AM Simon Glass  wrote:
> > > > > On Sun, 25 Apr 2021 at 18:21, Bin Meng  wrote:
> > > > > > On Sun, Apr 25, 2021 at 10:10 AM Simon Glass  
> > > > > > wrote:
> > > > > > > On Sun, 25 Apr 2021 at 13:49, Bin Meng  wrote:
> > > > > > > > On Sat, Apr 24, 2021 at 12:56 PM Simon Glass 
> > > > > > > >  wrote:
> > > > > > > > > On Thu, 8 Apr 2021 at 14:23, Bin Meng  
> > > > > > > > > wrote:
> > > > > > > > > > On Wed, Apr 7, 2021 at 12:32 PM Simon Glass 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > At present this driver relies on coreboot to provide 
> > > > > > > > > > > information about
> > > > > > > > > > > the console UART. However if coreboot is not compiled 
> > > > > > > > > > > with the UART
> > > > > > > > > > > enabled, the information is left out. This configuration 
> > > > > > > > > > > is quite
> > > > > > > > > > > common, e.g. with shipping x86-based Chrome OS 
> > > > > > > > > > > Chromebooks.
> > > > > > > > > > >
> > > > > > > > > > > Add a way to determine the UART settings in this case, 
> > > > > > > > > > > using a
> > > > > > > > > > > hard-coded list of PCI IDs.
> >
> > I don't like this either, so -1 from me.
> >
> > What coreboot should do is either provide serial information or SPCR ACPI 
> > table.
> > Otherwise if it does not provide it, I think it's on purpose, and we
> > have to respect this.
> >
> > The patch is ugly hack in my opinion. Sorry.
> >
> > You may make it less ugly by checking PCI class rather than IDs.
> 
> I have not been able to distinguish a pattern on Intel SoCs yet.
> Perhaps you can help with that as there must be a way...
> 
> 
> >
> > > > > > > > > > Why not just simply put a serial node in the device tree 
> > > > > > > > > > and we are all done?
> > > > > > > > >
> > > > > > > > > See my other email...I am trying to make this boot on any 
> > > > > > > > > board that
> > > > > > > > > coreboot supports.
> > > > > > > >
> > > > > > > > But this solution does not scale. One has to put all known 
> > > > > > > > UARTs into
> > > > > > > > serial_coreboot.c.
> > > > > > >
> > > > > > > Yes that's right...but this is only for when coreboot does not 
> > > > > > > enable
> > > > > > > serial. Also the number of new platforms is not that great.
> > > > > > >
> > > > > > > >
> > > > > > > > Why not patch coreboot instead? Why coreboot does not provide a 
> > > > > > > > cbinfo
> > > > > > > > with serial?
> > > > > > >
> > > > > > > Because it does not even set up the serial device in that case, so
> > > > > > > doesn't know the details. The driver is completely missing.
> > > > > >
> > > > > > Sigh. Is it possible to upstream a patch to coreboot to enable that?
> > > > >
> > > > > Well I'm not even sure upstream coreboot boots on the various
> > > > > Chromebooks I am targetting. If it does, then serial is probablt
> > > > > enabled. But certainly for chromebooks, it is not. My goal is to have
> > > > > U-Boot boot on a chromebook in altfw mode with serial enabled.
> > > > >
> > > > > >
> > > > > > I don't like the current approach because it ends up duplicating all
> > > > > > UART IDs/info in C.
> > > > >
> > > > > Yes. Do you think it would be better to put it in the devicetree? I
> > > > > suppose we could add some more stuff to the compatible string,
> > > > > although U-Boot does not support the PCI compatible strings at
> > > > > present.
> > > >
> > > > Putting it in the device tree also looks odd, because it only matters
> > > > on a dedicated board.
> > >
> > > Right, but that is the nature of trying to run the same image on
> > > different hardware.
> > >
> > > >
> > > > > What do you suggest?
> > > >
> > > > Or parse the ACPI table coreboot has set up? But that might be another
> > > > huge monster :(
> > >
> > > Yes, even worse...
> 
> All of the suggestions so far do not solve the problem, so we are left
> without serial output, or something else...?

You are truing to solve Coreboot issue in U-Boot, doesn't seem to be quite
right.

Yes, I prefer no serial than some "smart" hack. It will encourage people who
want to have serial out of Coreboot to whine to coreboot project and see what
they will do about it.

-- 
With Best Regards,
Andy Shevchenko

Re: Unable to boot u-boot image from nand storage imx6ull.

[Tim Harvey]

On Tue, May 4, 2021 at 9:28 AM Navin Sankar  wrote:
>
> On 04/05/21 8:49 pm, Tim Harvey wrote:
>
> On Sat, May 1, 2021 at 2:32 AM Navin Sankar  wrote:
>
> Hello all,
>
> Ported uboot to seeed studio based imx6ull board.
>
> NAND Part Number - mt29f4g08abaeawp
>
> NAND Size - 512 MBytes
>
> Both the SPL and U-BOOT image boot successfully from SD card.
>
> While with nand flash, SPL boot's fine. But SPL didn't boot the u-boot from 
> nand flash.
>
>
> => mtdparts
>
> device nand0 , # parts = 4
>  #: namesizeoffset  mask_flags
>  0: spl 0x0008  0x  0
>  1: uboot   0x0010  0x0008  0
>  2: uboot-dup   0x0010  0x0018  0
>  3: ubi 0x1fd8  0x0028  0
>
> active partition: nand0,0 - (spl) 0x0008 @ 0x
>
> defaults:
> mtdids  : nand0=gpmi-nand
> mtdparts: gpmi-nand:512k(spl),1m(uboot),1m(uboot-dup),-(ubi)
>
>
> And I flashed the SPL and u-boot image from SD card.
>
> Here is flashing result,
>
> Initially erased the nand chip
>
>
> => nand erase.chip
>
> NAND erase.chip: device 0 whole chip
> Skipping bad block at  0x1ff0
> Skipping bad block at  0x1ff4
> Skipping bad block at  0x1ff8
> Skipping bad block at  0x1ffc
>
> OK
>
>
> Then flashed the SPL
>
> => ext4load mmc 0:1 $loadaddr SPL
> 35840 bytes read in 4 ms (8.5 MiB/s)
> => nand erase.part spl
>
> NAND erase.part: device 0 offset 0x0, size 0x8
> Erasing at 0x4 -- 100% complete.
> OK
> => nandbcb init $loadaddr 0x0 $filesize
> device 0 offset 0x0, size 0x8c00
> Skipping bad block at  0x1ff0
> Skipping bad block at  0x1ff4
> Skipping bad block at  0x1ff8
> Skipping bad block at  0x1ffc
>
> Write firmware0 @0x20 offset, 0x9000 bytes written: OK
> Write firmware1 @0x1010 offset, 0x9000 bytes written: OK
> NAND FCB write to 0x400 offset 0x0 written: OK
> NAND FCB write to 0x400 offset 0x4 written: OK
> NAND FCB write to 0x400 offset 0x8 written: OK
> NAND FCB write to 0x400 offset 0xc written: OK
> NAND DBBT write to 0x10 offset 0x1000 written: OK
> DBBT data write to 0x104000 offset 0x1000 written: OK
> NAND DBBT write to 0x14 offset 0x1000 written: OK
> DBBT data write to 0x144000 offset 0x1000 written: OK
> NAND DBBT write to 0x18 offset 0x1000 written: OK
> DBBT data write to 0x184000 offset 0x1000 written: OK
> NAND DBBT write to 0x1c offset 0x1000 written: OK
> DBBT data write to 0x1c4000 offset 0x1000 written: OK
>
>
> Afterwards flashed the uboot image,
>
> => ext4load mmc 0:1 $loadaddr u-boot-dtb.img
> 624580 bytes read in 29 ms (20.5 MiB/s)
> => nand erase.part uboot
>
> NAND erase.part: device 0 offset 0x8, size 0x10
> Erasing at 0x14 -- 100% complete.
> OK
> => nand erase.part uboot-dup
>
> NAND erase.part: device 0 offset 0x18, size 0x10
> Erasing at 0x24 -- 100% complete.
> OK
> => nand write $loadaddr uboot $filesize
>
> NAND write: device 0 offset 0x8, size 0x987c4
>  624580 bytes written: OK
>
>
> Everything work's fine, but it didn't boot the u-boot image from nand storage.
>
> U-Boot SPL 2021.07-rc1-02889-gf6058bbb94-dirty (May 01 2021 - 14:12:55 +0530)
> Trying to boot from NAND
>
>
> Any hint?
>
> Navin,
>
> Everything above makes sense but the important thing is what you set
> CONFIG_SYS_SPL_ARGS_ADDR as that is where the SPL will attempt to load
> U-Boot from. Check that value and make sure its 0x8 and if it is
> correct add some debug prints around the loading of the U-Boot image
> to make sure everything goes as planned.
>
> Best regards,
>
> Tim
>
> Hi Tim,
>
> Assigned CONFIG_SYS_SPL_ARGS_ADDR to 0x8 and added some debug prints
>
> SPL loads the uboot the image successfully in RAM (crossed checked by 
> printing the image header and flashed image)
>
> and SPL also reaches the image entry point.
>
> image entry point: 0x8780
>
> But still the uboot image is not booting.
>

Navin,

Maybe use hexdump to dump what was loaded to RAM to verify contents
and ensure there isn't a raw nand/ECC issue?

Because you say this boots from microSD we can assume your dram setup
and everything is good so it must be the content of what's getting
loaded to RAM?

Tim

Re: Unable to boot u-boot image from nand storage imx6ull.

[Navin Sankar]

On 04/05/21 8:49 pm, Tim Harvey wrote:

On Sat, May 1, 2021 at 2:32 AM Navin Sankar  wrote:

Hello all,

Ported uboot to seeed studio based imx6ull board.

 NAND Part Number - mt29f4g08abaeawp

 NAND Size - 512 MBytes

Both the SPL and U-BOOT image boot successfully from SD card.

While with nand flash, SPL boot's fine. But SPL didn't boot the u-boot from 
nand flash.


=> mtdparts

device nand0 , # parts = 4
  #: namesizeoffset  mask_flags
  0: spl 0x0008  0x  0
  1: uboot   0x0010  0x0008  0
  2: uboot-dup   0x0010  0x0018  0
  3: ubi 0x1fd8  0x0028  0

active partition: nand0,0 - (spl) 0x0008 @ 0x

defaults:
mtdids  : nand0=gpmi-nand
mtdparts: gpmi-nand:512k(spl),1m(uboot),1m(uboot-dup),-(ubi)


And I flashed the SPL and u-boot image from SD card.

Here is flashing result,

Initially erased the nand chip


=> nand erase.chip

NAND erase.chip: device 0 whole chip
Skipping bad block at  0x1ff0
Skipping bad block at  0x1ff4
Skipping bad block at  0x1ff8
Skipping bad block at  0x1ffc

OK


Then flashed the SPL

=> ext4load mmc 0:1 $loadaddr SPL
35840 bytes read in 4 ms (8.5 MiB/s)
=> nand erase.part spl

NAND erase.part: device 0 offset 0x0, size 0x8
Erasing at 0x4 -- 100% complete.
OK
=> nandbcb init $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x8c00
Skipping bad block at  0x1ff0
Skipping bad block at  0x1ff4
Skipping bad block at  0x1ff8
Skipping bad block at  0x1ffc

Write firmware0 @0x20 offset, 0x9000 bytes written: OK
Write firmware1 @0x1010 offset, 0x9000 bytes written: OK
NAND FCB write to 0x400 offset 0x0 written: OK
NAND FCB write to 0x400 offset 0x4 written: OK
NAND FCB write to 0x400 offset 0x8 written: OK
NAND FCB write to 0x400 offset 0xc written: OK
NAND DBBT write to 0x10 offset 0x1000 written: OK
DBBT data write to 0x104000 offset 0x1000 written: OK
NAND DBBT write to 0x14 offset 0x1000 written: OK
DBBT data write to 0x144000 offset 0x1000 written: OK
NAND DBBT write to 0x18 offset 0x1000 written: OK
DBBT data write to 0x184000 offset 0x1000 written: OK
NAND DBBT write to 0x1c offset 0x1000 written: OK
DBBT data write to 0x1c4000 offset 0x1000 written: OK


Afterwards flashed the uboot image,

=> ext4load mmc 0:1 $loadaddr u-boot-dtb.img
624580 bytes read in 29 ms (20.5 MiB/s)
=> nand erase.part uboot

NAND erase.part: device 0 offset 0x8, size 0x10
Erasing at 0x14 -- 100% complete.
OK
=> nand erase.part uboot-dup

NAND erase.part: device 0 offset 0x18, size 0x10
Erasing at 0x24 -- 100% complete.
OK
=> nand write $loadaddr uboot $filesize

NAND write: device 0 offset 0x8, size 0x987c4
  624580 bytes written: OK


Everything work's fine, but it didn't boot the u-boot image from nand storage.

U-Boot SPL 2021.07-rc1-02889-gf6058bbb94-dirty (May 01 2021 - 14:12:55 +0530)
Trying to boot from NAND


Any hint?


Navin,

Everything above makes sense but the important thing is what you set
CONFIG_SYS_SPL_ARGS_ADDR as that is where the SPL will attempt to load
U-Boot from. Check that value and make sure its 0x8 and if it is
correct add some debug prints around the loading of the U-Boot image
to make sure everything goes as planned.

Best regards,

Tim


Hi Tim,

Assigned CONFIG_SYS_SPL_ARGS_ADDR to 0x8 and added some debug prints

SPL loads the uboot the image successfully in RAM (crossed checked by 
printing the image header and flashed image)


and SPL also reaches the image entry point 
.


image entry point: 0x8780

But still the uboot image is not booting.


Thanks and Regards,
Navin Sankar N V

Re: [PATCH 2/4] malloc: Annotate allocator for valgrind

[Simon Glass]

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:
>
> This annotates malloc and friends so that valgrind can track the heap. To
> do this, we need to follow a few rules:
>
> * Call VALGRIND_MALLOCLIKE_BLOCK whenever we malloc something
> * Call VALGRIND_FREELIKE_BLOCK whenever we free something (generally after
>   we have done our bookkeeping)
> * Call VALGRIND_RESIZEINPLACE_BLOCK whenever we change the size of an
>   allocation. Generally this just needs to happen in realloc, but only if
>   the address stays the same.
>
> In addition to the above, dlmalloc itself tends to make a lot of accesses
> which we know are safe, but which would be unsafe outside of dlmalloc. For
> this reason, we provide a suppression file which ignores errors ocurring in
> dlmalloc.c
>
> Signed-off-by: Sean Anderson 
> ---
>
>  common/dlmalloc.c  | 29 -
>  common/malloc_simple.c | 10 ++
>  include/malloc.h   |  4 
>  scripts/u-boot.supp| 30 ++
>  4 files changed, 72 insertions(+), 1 deletion(-)
>  create mode 100644 scripts/u-boot.supp

Reviewed-by: Simon Glass 

Re: [PATCH 1/4] Add valgrind headers to U-Boot

[Simon Glass]

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:
>
> Valgrind uses magic code sequences to define an ABI that the client may use
> to request behavior from the host. In particular, this may be used to
> inform valgrind about custom allocators, such as the one used in U-Boot.
>
> This adds headers defining these sequences to U-Boot. It also adds a config
> option to disable emission of these sequences entirely, in the (likely)
> event that the user does not wish to use valgrind. Note that this option
> was originally called NVALGRIND, but was renamed (and inverted) to
> CONFIG_VALGRIND.
>
> These headers were copied from valgrind 3.16.1-4 as distributed in Arch
> Linux. They are licensed with the bzip2 1.16 license. This appears to be a
> BSD license with some clauses from Zlib.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  Kconfig |   14 +
>  Licenses/README |1 +
>  Licenses/bzip2-1.0.6.txt|   30 +
>  include/valgrind/memcheck.h |  251 ++
>  include/valgrind/valgrind.h | 7106 +++
>  5 files changed, 7402 insertions(+)
>  create mode 100644 Licenses/bzip2-1.0.6.txt
>  create mode 100644 include/valgrind/memcheck.h
>  create mode 100644 include/valgrind/valgrind.h

Reviewed-by: Simon Glass 

Re: [PATCH 3/4] doc: sandbox: Document how to run sandbox with valgrind

[Simon Glass]

Hi Sean,

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:
>
> This documents how to get more detailed results from valgrind made possible
> by the last two commits.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  doc/arch/sandbox.rst | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

This looks good. I wonder if CONFIG_VALGRIND could become a build
variable as well, so you don't need to update the CONFIG?

Regards,
Simon

Re: [PATCH 03/17] x86: Allow coreboot serial driver to guess the UART

[Simon Glass]

Hi Bin and Andy,

On Fri, 30 Apr 2021 at 12:41, Andy Shevchenko  wrote:
>
> On Fri, Apr 30, 2021 at 9:14 PM Simon Glass  wrote:
> > On Thu, 29 Apr 2021 at 17:01, Bin Meng  wrote:
> > > On Fri, Apr 30, 2021 at 12:10 AM Simon Glass  wrote:
> > > > On Sun, 25 Apr 2021 at 18:21, Bin Meng  wrote:
> > > > > On Sun, Apr 25, 2021 at 10:10 AM Simon Glass  
> > > > > wrote:
> > > > > > On Sun, 25 Apr 2021 at 13:49, Bin Meng  wrote:
> > > > > > > On Sat, Apr 24, 2021 at 12:56 PM Simon Glass  
> > > > > > > wrote:
> > > > > > > > On Thu, 8 Apr 2021 at 14:23, Bin Meng  
> > > > > > > > wrote:
> > > > > > > > > On Wed, Apr 7, 2021 at 12:32 PM Simon Glass 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > At present this driver relies on coreboot to provide 
> > > > > > > > > > information about
> > > > > > > > > > the console UART. However if coreboot is not compiled with 
> > > > > > > > > > the UART
> > > > > > > > > > enabled, the information is left out. This configuration is 
> > > > > > > > > > quite
> > > > > > > > > > common, e.g. with shipping x86-based Chrome OS Chromebooks.
> > > > > > > > > >
> > > > > > > > > > Add a way to determine the UART settings in this case, 
> > > > > > > > > > using a
> > > > > > > > > > hard-coded list of PCI IDs.
>
> I don't like this either, so -1 from me.
>
> What coreboot should do is either provide serial information or SPCR ACPI 
> table.
> Otherwise if it does not provide it, I think it's on purpose, and we
> have to respect this.
>
> The patch is ugly hack in my opinion. Sorry.
>
> You may make it less ugly by checking PCI class rather than IDs.

I have not been able to distinguish a pattern on Intel SoCs yet.
Perhaps you can help with that as there must be a way...


>
> > > > > > > > > Why not just simply put a serial node in the device tree and 
> > > > > > > > > we are all done?
> > > > > > > >
> > > > > > > > See my other email...I am trying to make this boot on any board 
> > > > > > > > that
> > > > > > > > coreboot supports.
> > > > > > >
> > > > > > > But this solution does not scale. One has to put all known UARTs 
> > > > > > > into
> > > > > > > serial_coreboot.c.
> > > > > >
> > > > > > Yes that's right...but this is only for when coreboot does not 
> > > > > > enable
> > > > > > serial. Also the number of new platforms is not that great.
> > > > > >
> > > > > > >
> > > > > > > Why not patch coreboot instead? Why coreboot does not provide a 
> > > > > > > cbinfo
> > > > > > > with serial?
> > > > > >
> > > > > > Because it does not even set up the serial device in that case, so
> > > > > > doesn't know the details. The driver is completely missing.
> > > > >
> > > > > Sigh. Is it possible to upstream a patch to coreboot to enable that?
> > > >
> > > > Well I'm not even sure upstream coreboot boots on the various
> > > > Chromebooks I am targetting. If it does, then serial is probablt
> > > > enabled. But certainly for chromebooks, it is not. My goal is to have
> > > > U-Boot boot on a chromebook in altfw mode with serial enabled.
> > > >
> > > > >
> > > > > I don't like the current approach because it ends up duplicating all
> > > > > UART IDs/info in C.
> > > >
> > > > Yes. Do you think it would be better to put it in the devicetree? I
> > > > suppose we could add some more stuff to the compatible string,
> > > > although U-Boot does not support the PCI compatible strings at
> > > > present.
> > >
> > > Putting it in the device tree also looks odd, because it only matters
> > > on a dedicated board.
> >
> > Right, but that is the nature of trying to run the same image on
> > different hardware.
> >
> > >
> > > > What do you suggest?
> > >
> > > Or parse the ACPI table coreboot has set up? But that might be another
> > > huge monster :(
> >
> > Yes, even worse...

All of the suggestions so far do not solve the problem, so we are left
without serial output, or something else...?

Regards,
Simon

Re: [PATCH] Makefile: allow to override python3

[Simon Glass]

On Sat, 1 May 2021 at 14:13, Andrey Zhizhikin
 wrote:
>
> Python3 taken from the PATH causes build issues when pylibfdt bindings are
> generated with Yocto SDK.
>
> Python3 provided as a part of SDK is not compatible with host Python3,
> therefore binding build breaks with following errors:
>
> scripts/dtc/pylibfdt/libfdt_wrap.c:154:11: fatal error: Python.h: No such 
> file or directory
>   154 | # include 
>   |   ^~
>
> Do not enforce the python3 from the PATH and make it conditionally-assigned
> so it can be overridden from outside of build system. Keep the default
> assignment to point to version that is taken from the PATH.
>
> Similar fix has been introduced in b48bfc74ee ("tools: allow to override
> python"), where conditional assignment is used for python executable to
> address similar build errors.
>
> Signed-off-by: Andrey Zhizhikin 
> Cc: Simon Glass 
> Fixes: e91610da7c ("kconfig: re-sync with Linux 4.17-rc4")
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: Weirdness of ofnode_get_addr_size()

[Simon Glass]

Hi Jan,

On Sun, 2 May 2021 at 01:53, Jan Kiszka  wrote:
>
> Hi,
>
> I'm trying to make some sense of ofnode_get_addr_size() in order to fix
> [1] properly.
>
> First, the documentation if this functions says "This does no address
> translation". But the node-pointer path happily calls
> of_translate_address(), as the result of a6a45cd32539. For not
> offset-bases path, it calls fdtdec_get_addr_size() which does no
> translation.
>
> Related to [1]: The node-pointer path cleanly calls
> of_n_addr/size_cells() in order to retrieve the configured number of
> cells. But the offset-based path simply calls fdtdec_get_addr_size()
> which assumes that the number of cells is derived from the physical
> address width of that platform.
>
> So, what is that functions actually supposed to do?

+Dario Binacchi +Mario Six

I suspect the code has got ahead of the docs.

d64b9cdcd47 fdt: translate address if #size-cells = <0>
e8d5291824e core: ofnode: Fix translation for #size-cells == 0

Regards,
Simon

>
> Jan
>
> [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg405446.html

Re: [PATCH 4/4] malloc: Fix sbrk clearing memory after freeing it instead of before

[Simon Glass]

Hi Sean,

On Sun, 2 May 2021 at 20:55, Sean Anderson  wrote:
>
> This fixes memory being cleared after releasing it. Instead, clear memory
> before releasing it. In addition, suppress valgrind warnings about writing
> to free'd memory.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  common/dlmalloc.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> index 05c8fd87e7..ea51bdf6a6 100644
> --- a/common/dlmalloc.c
> +++ b/common/dlmalloc.c
> @@ -592,11 +592,13 @@ void *sbrk(ptrdiff_t increment)
> ulong new = old + increment;
>
> /*
> -* if we are giving memory back make sure we clear it out since
> -* we set MORECORE_CLEARS to 1
> +* if we are allocating memory make sure we clear it out since we set
> +* MORECORE_CLEARS to 1
>  */
> -   if (increment < 0)
> -   memset((void *)new, 0, -increment);
> +   if (increment > 0) {
> +   VALGRIND_MAKE_MEM_UNDEFINED(old, increment);
> +   memset((void *)old, 0, increment);
> +   }

Can you explain this a bit more? What is the difference?

Do you need the cast?

>
> if ((new < mem_malloc_start) || (new > mem_malloc_end))
> return (void *)MORECORE_FAILURE;
> --
> 2.31.0
>

Regards,
Simon

Re: [PATCH v1 1/6] lib: add crypt subsystem

[Simon Glass]

Hi Steffen,

On Sat, 1 May 2021 at 03:51, Steffen Jaeckel
 wrote:
>
> Hi Simon,
>
> On 4/29/21 6:10 PM, Simon Glass wrote:
> >> diff --git a/include/crypt.h b/include/crypt.h
> >> new file mode 100644
> >> index 00..e0be2832ff
> >> --- /dev/null
> >> +++ b/include/crypt.h
> >> @@ -0,0 +1,13 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> +/* Copyright (C) 2020 Steffen Jaeckel  */
> >> +
> >> +/**
> >> + * Compare should with the processed passphrase.
> >> + *
> >> + * @should  The crypt-style string to compare against
> >> + * @passphrase  The plaintext passphrase
> >> + * @equal   Pointer to an int where the result is stored
> >> + * '0' = unequal
> >> + * '1' = equal
> >
> > Can this be a return value from the function? true/false
>
> ... the next patch in the series changes the return type to int ... I'll
> rework those to make this better visible.
>
> The concept stayed the same as IMO this would complicate the handling in
> the caller and with this pattern the usage is a lot easier:
> * return value indicates success of the operation
> * `equal` argument returns whether the given crypt-style string equals
> the hashed passphrase

Well that's up to you, but it is pretty common in U-Boot to return an
error code or a true/false value.

>
>
> >> + */
> >> +void crypt_compare(const char *should, const char *passphrase, int 
> >> *equal);
> >> diff --git a/lib/Kconfig b/lib/Kconfig
> >> index 6d2d41de30..c7c0b87ec7 100644
> >> --- a/lib/Kconfig
> >> +++ b/lib/Kconfig
> >> @@ -297,6 +297,7 @@ config AES
> >>
> >>  source lib/rsa/Kconfig
> >>  source lib/crypto/Kconfig
> >> +source lib/crypt/Kconfig
> >>
> >>  config TPM
> >> bool "Trusted Platform Module (TPM) Support"
> >> diff --git a/lib/Makefile b/lib/Makefile
> >> index 6825671955..f0d91986b1 100644
> >> --- a/lib/Makefile
> >> +++ b/lib/Makefile
> >> @@ -65,6 +65,7 @@ obj-$(CONFIG_FIT_SIGNATURE) += hash-checksum.o
> >>  obj-$(CONFIG_SHA1) += sha1.o
> >>  obj-$(CONFIG_SHA256) += sha256.o
> >>  obj-$(CONFIG_SHA512_ALGO) += sha512.o
> >> +obj-$(CONFIG_CRYPT_PW) += crypt/
> >>
> >>  obj-$(CONFIG_$(SPL_)ZLIB) += zlib/
> >>  obj-$(CONFIG_$(SPL_)ZSTD) += zstd/
> >> diff --git a/lib/crypt/Kconfig b/lib/crypt/Kconfig
> >> new file mode 100644
> >> index 00..6f828cefd6
> >> --- /dev/null
> >> +++ b/lib/crypt/Kconfig
> >> @@ -0,0 +1,29 @@
> >> +config CRYPT_PW
> >> +   bool "Add crypt support for password-based unlock"
> >> +   help
> >> + Enable support for crypt-style hashed passphrases.
> >> + This will then be used as the mechanism of choice to
> >> + verify whether the entered password to unlock the
> >> + console is correct or not.
> >> + To make it fully functional, one has also to enable
> >> + CONFIG_AUTOBOOT_KEYED and CONFIG_AUTOBOOT_ENCRYPTION
> >
> > So should CRYPT_PW depend on one or both of those?
>
> Should it depend or can it also select?

Depend is better, as I understand it, but not sure if this applies to you:

https://docs.zephyrproject.org/1.14.0/guides/kconfig/index.html#select-pitfalls

>
> > ...
> >> diff --git a/lib/crypt/crypt-sha256.c b/lib/crypt/crypt-sha256.c
> >> new file mode 100644
> >> index 00..37127d41e1
> >> --- /dev/null
> >> +++ b/lib/crypt/crypt-sha256.c
> >> @@ -0,0 +1,313 @@
> >> +/* One way encryption based on the SHA256-based Unix crypt implementation.
> >> + *
> >> + * Written by Ulrich Drepper  in 2007 [1].
> >> + * Modified by Zack Weinberg  in 2017, 2018.
> >> + * Composed by Björn Esser  in 2018.
> >> + * Modified by Björn Esser  in 2020.
> >> + * Modified by Steffen Jaeckel  in 
> >> 2020.
> >> + * To the extent possible under law, the named authors have waived all
> >> + * copyright and related or neighboring rights to this work.
> >> + *
> >> + * See https://creativecommons.org/publicdomain/zero/1.0/ for further
> >> + * details.
> >> + *
> >> + * This file is a modified except from [2], lines 648 up to 909.
> >> + *
> >> + * [1]  https://www.akkadia.org/drepper/sha-crypt.html
> >> + * [2]  https://www.akkadia.org/drepper/SHA-crypt.txt
> >
> > Can you add SPDX to the new files?
>
> Sure, after we're done with those files I'll see which parts I can
> upstream to libxcrypt.

OK.

Regards,
Simon

Re: Unable to boot u-boot image from nand storage imx6ull.

[Tim Harvey]

On Sat, May 1, 2021 at 2:32 AM Navin Sankar  wrote:
>
> Hello all,
>
> Ported uboot to seeed studio based imx6ull board.
>
> NAND Part Number - mt29f4g08abaeawp
>
> NAND Size - 512 MBytes
>
> Both the SPL and U-BOOT image boot successfully from SD card.
>
> While with nand flash, SPL boot's fine. But SPL didn't boot the u-boot from 
> nand flash.
>
>
> => mtdparts
>
> device nand0 , # parts = 4
>  #: namesizeoffset  mask_flags
>  0: spl 0x0008  0x  0
>  1: uboot   0x0010  0x0008  0
>  2: uboot-dup   0x0010  0x0018  0
>  3: ubi 0x1fd8  0x0028  0
>
> active partition: nand0,0 - (spl) 0x0008 @ 0x
>
> defaults:
> mtdids  : nand0=gpmi-nand
> mtdparts: gpmi-nand:512k(spl),1m(uboot),1m(uboot-dup),-(ubi)
>
>
> And I flashed the SPL and u-boot image from SD card.
>
> Here is flashing result,
>
> Initially erased the nand chip
>
>
> => nand erase.chip
>
> NAND erase.chip: device 0 whole chip
> Skipping bad block at  0x1ff0
> Skipping bad block at  0x1ff4
> Skipping bad block at  0x1ff8
> Skipping bad block at  0x1ffc
>
> OK
>
>
> Then flashed the SPL
>
> => ext4load mmc 0:1 $loadaddr SPL
> 35840 bytes read in 4 ms (8.5 MiB/s)
> => nand erase.part spl
>
> NAND erase.part: device 0 offset 0x0, size 0x8
> Erasing at 0x4 -- 100% complete.
> OK
> => nandbcb init $loadaddr 0x0 $filesize
> device 0 offset 0x0, size 0x8c00
> Skipping bad block at  0x1ff0
> Skipping bad block at  0x1ff4
> Skipping bad block at  0x1ff8
> Skipping bad block at  0x1ffc
>
> Write firmware0 @0x20 offset, 0x9000 bytes written: OK
> Write firmware1 @0x1010 offset, 0x9000 bytes written: OK
> NAND FCB write to 0x400 offset 0x0 written: OK
> NAND FCB write to 0x400 offset 0x4 written: OK
> NAND FCB write to 0x400 offset 0x8 written: OK
> NAND FCB write to 0x400 offset 0xc written: OK
> NAND DBBT write to 0x10 offset 0x1000 written: OK
> DBBT data write to 0x104000 offset 0x1000 written: OK
> NAND DBBT write to 0x14 offset 0x1000 written: OK
> DBBT data write to 0x144000 offset 0x1000 written: OK
> NAND DBBT write to 0x18 offset 0x1000 written: OK
> DBBT data write to 0x184000 offset 0x1000 written: OK
> NAND DBBT write to 0x1c offset 0x1000 written: OK
> DBBT data write to 0x1c4000 offset 0x1000 written: OK
>
>
> Afterwards flashed the uboot image,
>
> => ext4load mmc 0:1 $loadaddr u-boot-dtb.img
> 624580 bytes read in 29 ms (20.5 MiB/s)
> => nand erase.part uboot
>
> NAND erase.part: device 0 offset 0x8, size 0x10
> Erasing at 0x14 -- 100% complete.
> OK
> => nand erase.part uboot-dup
>
> NAND erase.part: device 0 offset 0x18, size 0x10
> Erasing at 0x24 -- 100% complete.
> OK
> => nand write $loadaddr uboot $filesize
>
> NAND write: device 0 offset 0x8, size 0x987c4
>  624580 bytes written: OK
>
>
> Everything work's fine, but it didn't boot the u-boot image from nand storage.
>
> U-Boot SPL 2021.07-rc1-02889-gf6058bbb94-dirty (May 01 2021 - 14:12:55 +0530)
> Trying to boot from NAND
>
>
> Any hint?
>

Navin,

Everything above makes sense but the important thing is what you set
CONFIG_SYS_SPL_ARGS_ADDR as that is where the SPL will attempt to load
U-Boot from. Check that value and make sure its 0x8 and if it is
correct add some debug prints around the loading of the U-Boot image
to make sure everything goes as planned.

Best regards,

Tim

Re: [PATCH v2] cmd: gpt: Add option to write GPT partitions to environment variable

[Heinrich Schuchardt]

On 5/3/21 9:29 PM, Farhan Ali wrote:
> Hi Heinrich,
>
> I was wondering if there are any other changes necessary?

Nothing on my side.

The patch was reviewed by Simon and now is is assigned to Tom.

https://patchwork.ozlabs.org/project/uboot/patch/20210226181733.19307-1-farhan@broadcom.com/

He should be able to tell you why it wasn't merged yet.

Best regards

Heinrich
>
> Thanks
>
> Farhan
>
> On Thu, Mar 4, 2021 at 8:08 PM Simon Glass  > wrote:
>
> On Fri, 26 Feb 2021 at 13:17, Farhan Ali  > wrote:
> >
> > This change would enhance the existing 'gpt read' command to allow
> > (optionally) writing of the read GPT partitions to an environment
> > variable in the UBOOT partitions layout format. This would allow users
> > to easily change the overall partition settings by editing said
> variable
> > and then using the variable in the 'gpt write' and 'gpt verify'
> commands.
> >
> > Signed-off-by: Farhan Ali  >
> > Cc: Simon Glass mailto:s...@chromium.org>>
> > Cc: Heinrich Schuchardt  >
> > Cc: Corneliu Doban mailto:cdo...@broadcom.com>>
> > Cc: Rayagonda Kokatanur  >
> > Cc: Rasmus Villemoes  >
> >
> > ---
> > Changes for v2:
> >    - Checked for argv[4] existence before calling do_get_gpt_info
> >    - Added missing update to doc/README.gpt
> > ---
> >  cmd/gpt.c      | 46 ++
> >  doc/README.gpt | 17 +
> >  2 files changed, 55 insertions(+), 8 deletions(-)
> >
>
> Reviewed-by: Simon Glass mailto:s...@chromium.org>>
>

Re: [PATCH] ARM: stm32: Enable UNZIP on DHSOM by default

[Patrick DELAUNAY]

Hi,

On 5/3/21 1:31 PM, Marek Vasut wrote:

The CMD_UNZIP provides the 'gzwrite' command, which is convenient
for writing e.g. gz-compressed images to eMMC from U-Boot.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
  configs/stm32mp15_dhcom_basic_defconfig | 1 +
  configs/stm32mp15_dhcor_basic_defconfig | 1 +
  2 files changed, 2 insertions(+)



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH] ARM: stm32: Add additional ID register check for KSZ8851 presence

[Patrick DELAUNAY]

Hi,

On 5/3/21 1:31 PM, Marek Vasut wrote:

Currently the code sets eth1addr only if /ethernet1 alias exists in DT,
the node pointed to by the alias has "micrel,ks8851-mll" compatible
string, and the KSZ8851 CCR register read indicates programmed EEPROM
is not connected.

This is not sufficient to detect cases where the DT still contains the
KSZ8851 nodes, but the chip itself is not present. Extend the detection
to handle these cases.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
  board/dhelectronics/dh_stm32mp1/board.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index 49b12c4c042..ac1af718d4a 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -86,6 +86,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define KS_CCR_EEPROM BIT(9)
  #define KS_BE0BIT(12)
  #define KS_BE1BIT(13)
+#define KS_CIDER   0xC0
+#define CIDER_ID   0x8870
  
  int setup_mac_address(void)

  {
@@ -123,11 +125,18 @@ int setup_mac_address(void)
 * is present. If EEPROM is present, it must contain valid
 * MAC address.
 */
-   u32 reg, ccr;
+   u32 reg, cider, ccr;
reg = fdt_get_base_address(gd->fdt_blob, off);
if (!reg)
goto out_set_ethaddr;
  
+	writew(KS_BE0 | KS_BE1 | KS_CIDER, reg + 2);

+   cider = readw(reg);
+   if ((cider & 0xfff0) != CIDER_ID) {
+   skip_eth1 = true;
+   goto out_set_ethaddr;
+   }
+
writew(KS_BE0 | KS_BE1 | KS_CCR, reg + 2);
ccr = readw(reg);
if (ccr & KS_CCR_EEPROM) {



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [Uboot-stm32] [PATCH] arm: dts: stm32mp157c-odyssey-som: enable the RNG1

[Patrick DELAUNAY]

Hi,

On 4/19/21 7:55 PM, Grzegorz Szymaszek wrote:

Enable the true random number generator. It can be used, for example, to
generate partition UUIDs when partitioning with the gpt command. The
generator is already enabled in the device trees of several other
STM32MP1‐based boards, like DKx or DHCOM.

Signed-off-by: Grzegorz Szymaszek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
  arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi 
b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
index 83ff2e7ce1..e367a311c4 100644
--- a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
+++ b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
@@ -258,6 +258,10 @@
status = "okay";
  };
  
+ {

+   status = "okay";
+};
+
   {
pinctrl-names = "default", "opendrain", "sleep";
pinctrl-0 = <_b4_pins_a>;



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH] reset: stm32: Fix bank and offset computation

[Patrick DELAUNAY]

Hi Patrice,

On 4/28/21 1:42 PM, Patrice Chotard wrote:

BITS_PER_LONG is used to represent register's size which is 32.
But when compiled on arch64, BITS_PER_LONG is then equal to 64.

Fix bank and offset computation to make it work on arch32 and
arch64 and ensure that register's size is always equal to 32.

Signed-off-by: Patrice Chotard 
Signed-off-by: Pankaj Dev 
---

  drivers/reset/stm32-reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/reset/stm32-reset.c b/drivers/reset/stm32-reset.c
index daa2e47ebb..bbc6b135a9 100644
--- a/drivers/reset/stm32-reset.c
+++ b/drivers/reset/stm32-reset.c
@@ -40,8 +40,8 @@ static int stm32_reset_free(struct reset_ctl *reset_ctl)
  static int stm32_reset_assert(struct reset_ctl *reset_ctl)
  {
struct stm32_reset_priv *priv = dev_get_priv(reset_ctl->dev);
-   int bank = (reset_ctl->id / BITS_PER_LONG) * 4;
-   int offset = reset_ctl->id % BITS_PER_LONG;
+   int bank = (reset_ctl->id / (sizeof(u32) * BITS_PER_BYTE)) * 4;
+   int offset = reset_ctl->id % (sizeof(u32) * BITS_PER_BYTE);
  
  	dev_dbg(reset_ctl->dev, "reset id = %ld bank = %d offset = %d)\n",

reset_ctl->id, bank, offset);
@@ -61,8 +61,8 @@ static int stm32_reset_assert(struct reset_ctl *reset_ctl)
  static int stm32_reset_deassert(struct reset_ctl *reset_ctl)
  {
struct stm32_reset_priv *priv = dev_get_priv(reset_ctl->dev);
-   int bank = (reset_ctl->id / BITS_PER_LONG) * 4;
-   int offset = reset_ctl->id % BITS_PER_LONG;
+   int bank = (reset_ctl->id / (sizeof(u32) * BITS_PER_BYTE)) * 4;
+   int offset = reset_ctl->id % (sizeof(u32) * BITS_PER_BYTE);
  
  	dev_dbg(reset_ctl->dev, "reset id = %ld bank = %d offset = %d)\n",

reset_ctl->id, bank, offset);



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH v3 5/7] image-fdt: save no-map parameter of reserve-memory

[Patrick DELAUNAY]

Hi Simon,

On 4/29/21 6:10 PM, Simon Glass wrote:

Hi Patrick,

On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay
 wrote:

Save the no-map information present in 'reserved-memory' node to allow
correct handling when the MMU is configured in board to avoid
speculative access.

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

  common/image-fdt.c | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

Where is no-map documented?



In linux: 
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt


in U-Boot: doc/device-tree-bindings/reserved-memory/reserved-memory.txt:55

no-map (optional) - empty property
    - Indicates the operating system must not create a virtual mapping
  of the region as part of its standard mapping of system memory,
  nor permit speculative access to it under any circumstances other
  than under the control of the device driver using the region.


But I will add this indication in the commit message.




Reviewed-by: Simon Glass 



Thanks,

Patrick

Re: [PATCH v3 2/7] lmb: add lmb_is_reserved_flags

[Patrick DELAUNAY]

On 4/29/21 6:10 PM, Simon Glass wrote:

Hi Patrick,

On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay
 wrote:

Add a new function lmb_is_reserved_flags to check is a
address is reserved with a specific flags.

This function can be used to check if an address was
reserved with no-map flags with:

lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

  include/lmb.h |  1 +
  lib/lmb.c | 10 --
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/lmb.h b/include/lmb.h
index aa196c63bf..6537d56e18 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -91,6 +91,7 @@ extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, 
phys_addr_t base,
   phys_size_t size);
  extern phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr);
  extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
+extern int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags);

drop extern and please add a function comment



I chosed to use extern to by aligned with other function and the linux 
memblock library.


But I will drop them in v4




  extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size);

  extern void lmb_dump_all(struct lmb *lmb);
diff --git a/lib/lmb.c b/lib/lmb.c
index 69700bf9ba..e270e86186 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -443,7 +443,7 @@ phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t 
addr)
 return 0;
  }

-int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
+int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags)
  {
 int i;

@@ -451,11 +451,17 @@ int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
 phys_addr_t upper = lmb->reserved.region[i].base +
 lmb->reserved.region[i].size - 1;
 if ((addr >= lmb->reserved.region[i].base) && (addr <= upper))
-   return 1;
+   return !!((lmb->reserved.region[i].flags & flags)
+  == flags);

I don't know what flags is since there is no comment, but it seems
that you should drop the !!()



Yes, it is a old C-coding habit.



 }
 return 0;
  }

+int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
+{
+   return lmb_is_reserved_flags(lmb, addr, LMB_NONE);
+}
+
  __weak void board_lmb_reserve(struct lmb *lmb)
  {
 /* please define platform specific board_lmb_reserve() */
--
2.17.1


Regards,
Simon

Re: [PATCH v4 00/10] Add support for extension boards detection and DT overlays application

[Tom Rini]

On Tue, Apr 20, 2021 at 10:25:31AM +0200, Kory Maincent wrote:

> This series of patches aims at proposing a generic U-Boot mechanism to
> detect extension boards connected to the HW platform, and apply the
> appropriate Device Tree overlays depending on the detected extension
> boards.
> 
> Indeed, numerous popular platforms, such as the BeagleBone or the
> RaspberryPi, feature some kind of extension board mechanism. These
> extension boards are often discoverable through some kind of EEPROM
> (connected on I2C, 1-wire, etc.) and require Device Tree overlays to be
> applied at the U-Boot level to provide a complete HW description to the
> Linux kernel. However, currently this logic is usually implemented
> ad-hoc in downstream forks of U-Boot.
> 
> This series proposes to bring a HW-agnostic and generic solution to
> this problem to upstream U-Boot. The series shows that it is generic
> enough by implementing its usage for 2 different families of HW
> platforms and expansion boards:
> 
>  - The BeagleBone Black and BeagleBone AI, that use extension boards
>where the EEPROM describing the extension boards is connected over
>I2C.
> 
>  - The CHIP, that uses extension boards where the EEPROM describing the
>extension boards is connected over 1-wire.
> 
> The patch series implements a new command called "extension", with two
> sub-commands:
> 
>  - "extension scan" to detect available extension boards
> 
>  - "extension list" will simply list the detected extension boards
> 
>  - "extension apply" will allow to apply the Device Tree overlays
>corresponding to one extension board or to all expansion boards
> 
> Note that the name "extension" has been chosen to not refer to any
> particular board-specific terminology for extension boards ("cape" for
> BeagleBone, "DIP" for CHIP, "hat" for RaspberryPi, etc.). However, we
> welcome suggestions of other names and are definitely willing to use a
> different naming.
> 
> The "extension apply" command requires two environment variables to be
> defined so that it knows how to apply DT overlays. This is described
> in more details in PATCH 1.
> 
> This generic code requires board-specific code for the detection and
> enumeration of extension boards. This is simply implemented in the form
> of a board-specific extension_board_scan() function, which fills in a
> list of detected extension boards.
> 
> In detail:
> 
>  - PATCH 1 move fdt_valid function to fdt_support file
>  - PATCH 2 implements the generic command and logic
>  - PATCH 3 implements the python test for the "extension" command
>  - PATCH 4 implements the board-specific code for the BeagleBone platforms
>  - PATCH 5 enables the mechanism for the BeagleBone AI
>  - PATCH 6 review the detection mechanism of one-wire devices
>  - PATCH 7 and 8 enable the mechanism for the CHIP
>  - PATCH 9 and 10 enable the mechanism for the BeagleBone Black
> 
> Thanks in advance for your review and feedback

Can you please rebase this on current master?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: squashfs tests flaky?

[Tom Rini]

On Tue, May 04, 2021 at 04:31:57PM +0530, Pratyush Yadav wrote:

> Hi,
> 
> I am playing around with the U-Boot CI, mostly to make sure my patches 
> don't break things. To that end I created a fork of u-boot on GitLab and 
> started the CI pipeline on the current master (8ddaf94358).
> 
> I see on the official repo the job passes [0]. But on my fork, the job 
> fails due to squashfs failures [1]. Both jobs are using the same commit. 
> I looked at the failure logs and it seems to be because of some I/O 
> errors but I'm not sure what exactly is going on.
> 
> [0] https://source.denx.de/u-boot/u-boot/-/jobs/263093
> [1] https://gitlab.com/prati0100/uboot/-/jobs/1234264642

Flaky, no.  But needs a fix for some files not being cleaned up, which
the free runners on gitlab.com always trigger?  Yes.  Someone addressing
that would be most welcome.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC 4/7] pinctrl: mscc: Fix multiple definition error

[Horatiu Vultur]

The 05/03/2021 16:48, Tom Rini wrote:
> 
> With gcc-11 we get a multiple errors here as the declarations for
> mscc_pinctrl_ops and mscc_gpio_ops are missing an extern.

Reviewed-by: Horatiu Vultur 

> 
> CC: Gregory CLEMENT 
> Cc: Lars Povlsen 
> Cc: Horatiu Vultur 
> Signed-off-by: Tom Rini 
> ---
>  drivers/pinctrl/mscc/mscc-common.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/mscc/mscc-common.h 
> b/drivers/pinctrl/mscc/mscc-common.h
> index 3c5c1faf840f..49c84a9f410b 100644
> --- a/drivers/pinctrl/mscc/mscc-common.h
> +++ b/drivers/pinctrl/mscc/mscc-common.h
> @@ -61,6 +61,6 @@ int mscc_pinctrl_probe(struct udevice *dev, int num_func,
>const struct mscc_pin_data *mscc_pins, int num_pins,
>char * const *function_names,
>const unsigned long *mscc_gpios);
> -const struct pinctrl_ops mscc_pinctrl_ops;
> +extern const struct pinctrl_ops mscc_pinctrl_ops;
> 
> -const struct dm_gpio_ops mscc_gpio_ops;
> +extern const struct dm_gpio_ops mscc_gpio_ops;
> --
> 2.17.1
> 

-- 
/Horatiu

Re: [PATCH] cmd: pxe_utils: sysboot: fix crash if either board or soc are not set.

[Dimitri John Ledkov]

Hi qemu-board meaintainers,

The below patch affects any boards that do not have either board or
soc variables set.

Of which non-x86 qemu boards are exactly that, preventing to netboot
the same rootfs across multiple boards and qemu at the same time.

Another alternative would be for all non-x86 qemu boards to also define
config SYS_SOC
default "qemu"

However, I fear similar situation might still arise in the future
where some boards lack either SYS_BOARD or SYS_SOC definitions. Thus
even if non-qemu boards are fixed up, the below should still be
applied?

Do you want me to send a separate patch to add SYS_SOC to all qemu boards?

On Wed, Apr 21, 2021 at 3:32 PM Dimitri John Ledkov  wrote:
>
> If the environment does not have "soc" or "board" set, and fdtdir
> option is specified in extlinux.conf, the bootloader will crash whilst
> dereferencing a null pointer. Add a guard against null soc or
> board. Fixes a crash of qemu-riscv64_smode configuration, which does
> not have CONFIG_SYS_SOC defined.
>
> Signed-off-by: Dimitri John Ledkov 
> ---
>  cmd/pxe_utils.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index 71c5af4c25..9a30629e26 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -587,6 +587,14 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
> pxe_label *label)
> f2 = "-";
> f3 = env_get("board");
> f4 = ".dtb";
> +   if (!f1) {
> +   f1 = "";
> +   f2 = "";
> +   }
> +   if (!f3) {
> +   f2 = "";
> +   f3 = "";
> +   }
> }
>
> len = strlen(label->fdtdir);
> --
> 2.27.0
>


-- 
Regards,

Dimitri.

Re: [PATCH v7 2/8] drivers: clk: add fu740 support

[Dimitri John Ledkov]

(resending to the list after subscribing)

Hi,

On Thu, Apr 22, 2021 at 10:15 AM Green Wan  wrote:
>
> Add fu740 support. One abstract layer is added for supporting
> multiple chips such as fu540 and fu740.
>
> Signed-off-by: Green Wan 
> ---
>  drivers/clk/sifive/Kconfig   |   8 +-
>  drivers/clk/sifive/Makefile  |   4 +-
>  drivers/clk/sifive/fu540-prci.c  | 769 +--
>  drivers/clk/sifive/fu540-prci.h  |  22 +
>  drivers/clk/sifive/fu740-prci.c  | 158 +++
>  drivers/clk/sifive/fu740-prci.h  |  22 +
>  drivers/clk/sifive/sifive-prci.c | 733 +
>  drivers/clk/sifive/sifive-prci.h | 323 +
>  8 files changed, 1286 insertions(+), 753 deletions(-)
>  create mode 100644 drivers/clk/sifive/fu540-prci.h
>  create mode 100644 drivers/clk/sifive/fu740-prci.c
>  create mode 100644 drivers/clk/sifive/fu740-prci.h
>  create mode 100644 drivers/clk/sifive/sifive-prci.c
>  create mode 100644 drivers/clk/sifive/sifive-prci.h
>
> diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> index c4d0a1f9b1..20fc004b59 100644
> --- a/drivers/clk/sifive/Kconfig
> +++ b/drivers/clk/sifive/Kconfig
> @@ -6,11 +6,11 @@ config CLK_SIFIVE
> help
>   SoC drivers for SiFive Linux-capable SoCs.
>
> -config CLK_SIFIVE_FU540_PRCI
> -   bool "PRCI driver for SiFive FU540 SoCs"
> +config CLK_SIFIVE_PRCI
> +   bool "PRCI driver for SiFive SoCs"
> depends on CLK_SIFIVE

Since the above is done in this patch, I would expect to remove all
references to the CLK_SIFIVE_FU540_PRCI config option at the same
time. Specifically:

$ git grep CLK_SIFIVE_FU540_PRCI
arch/riscv/cpu/fu540/Kconfig:   imply CLK_SIFIVE_FU540_PRCI
drivers/reset/Kconfig:  depends on DM_RESET && CLK_SIFIVE_FU540_PRCI
&& TARGET_SIFIVE_UNLEASHED

If above references were fixed, it remove the need to manually add
"CONFIG_CLK_SIFIVE_PRCI=y" to unleashed config in the "board: sifive:
add HiFive Unmatched board support" patch.

Leaving left over references to the removed config options is
confusing, and makes the patch not self contained.


> select CLK_ANALOGBITS_WRPLL_CLN28HPC
> help
>   Supports the Power Reset Clock interface (PRCI) IP block found in
> - FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
> - enable this driver.
> + FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/
> + FU740 SoCs, enable this driver.
> diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
> index b224279afb..51348b1ddc 100644
> --- a/drivers/clk/sifive/Makefile
> +++ b/drivers/clk/sifive/Makefile
> @@ -1,3 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0+
>
> -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
> +obj-y += sifive-prci.o
> +
> +obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o fu740-prci.o
> diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
> index b3882d0b77..ceb2c6fab0 100644
> --- a/drivers/clk/sifive/fu540-prci.c
> +++ b/drivers/clk/sifive/fu540-prci.c
> @@ -5,6 +5,8 @@
>   * Copyright (C) 2018 SiFive, Inc.
>   * Wesley Terpstra
>   * Paul Walmsley
> + * Zong Li
> + * Pragnesh Patel
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -15,632 +17,48 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * The FU540 PRCI implements clock and reset control for the SiFive
> - * FU540-C000 chip.   This driver assumes that it has sole control
> - * over all PRCI resources.
> - *
> - * This driver is based on the PRCI driver written by Wesley Terpstra.
> - *
> - * Refer, commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
> - * https://github.com/riscv/riscv-linux
> - *
>   * References:
>   * - SiFive FU540-C000 manual v1p0, Chapter 7 "Clocking and Reset"
>   */
>
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/*
> - * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
> - * hfclk and rtcclk
> - */
> -#define EXPECTED_CLK_PARENT_COUNT  2
> -
> -/*
> - * Register offsets and bitmasks
> - */
> -
> -/* COREPLLCFG0 */
> -#define PRCI_COREPLLCFG0_OFFSET0x4
> -#define PRCI_COREPLLCFG0_DIVR_SHIFT0
> -#define PRCI_COREPLLCFG0_DIVR_MASK (0x3f << PRCI_COREPLLCFG0_DIVR_SHIFT)
> -#define PRCI_COREPLLCFG0_DIVF_SHIFT6
> -#define PRCI_COREPLLCFG0_DIVF_MASK (0x1ff << PRCI_COREPLLCFG0_DIVF_SHIFT)
> -#define PRCI_COREPLLCFG0_DIVQ_SHIFT15
> -#define PRCI_COREPLLCFG0_DIVQ_MASK (0x7 << PRCI_COREPLLCFG0_DIVQ_SHIFT)
> -#define PRCI_COREPLLCFG0_RANGE_SHIFT   18
> -#define PRCI_COREPLLCFG0_RANGE_MASK(0x7 << 

Re: [PATCH v7 1/8] riscv: cpu: fu740: Add support for cpu fu740

[Dimitri John Ledkov]

(resending to the list after subscribing)

Hi,

On Thu, Apr 22, 2021 at 10:14 AM Green Wan  wrote:
>
> Add SiFive fu740 cpu to support RISC-V arch
>
> Signed-off-by: Green Wan 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/Kconfig|  1 +
>  arch/riscv/cpu/fu740/Kconfig  | 37 +++
>  arch/riscv/cpu/fu740/Makefile | 12 +
>  arch/riscv/cpu/fu740/cache.c  | 55 +++
>  arch/riscv/cpu/fu740/cpu.c| 22 +
>  arch/riscv/cpu/fu740/dram.c   | 38 
>  arch/riscv/cpu/fu740/spl.c| 23 ++
>  arch/riscv/include/asm/arch-fu740/cache.h | 14 ++
>  arch/riscv/include/asm/arch-fu740/clk.h   | 14 ++
>  arch/riscv/include/asm/arch-fu740/gpio.h  | 38 
>  arch/riscv/include/asm/arch-fu740/reset.h | 13 ++
>  arch/riscv/include/asm/arch-fu740/spl.h   | 14 ++
>  arch/riscv/lib/sifive_clint.c |  1 -
>  13 files changed, 281 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/cpu/fu740/Kconfig
>  create mode 100644 arch/riscv/cpu/fu740/Makefile
>  create mode 100644 arch/riscv/cpu/fu740/cache.c
>  create mode 100644 arch/riscv/cpu/fu740/cpu.c
>  create mode 100644 arch/riscv/cpu/fu740/dram.c
>  create mode 100644 arch/riscv/cpu/fu740/spl.c
>  create mode 100644 arch/riscv/include/asm/arch-fu740/cache.h
>  create mode 100644 arch/riscv/include/asm/arch-fu740/clk.h
>  create mode 100644 arch/riscv/include/asm/arch-fu740/gpio.h
>  create mode 100644 arch/riscv/include/asm/arch-fu740/reset.h
>  create mode 100644 arch/riscv/include/asm/arch-fu740/spl.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 3f221dccdb..4177253e44 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -61,6 +61,7 @@ source "board/sipeed/maix/Kconfig"
>  # platform-specific options below
>  source "arch/riscv/cpu/ax25/Kconfig"
>  source "arch/riscv/cpu/fu540/Kconfig"
> +source "arch/riscv/cpu/fu740/Kconfig"
>  source "arch/riscv/cpu/generic/Kconfig"
>
>  # architecture-specific options below
> diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
> new file mode 100644
> index 00..24788beab1
> --- /dev/null
> +++ b/arch/riscv/cpu/fu740/Kconfig
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2020-2021 SiFive, Inc
> +# Pragnesh Patel 
> +
> +config SIFIVE_FU740
> +   bool
> +   select ARCH_EARLY_INIT_R
> +   select RAM
> +   select SPL_RAM if SPL
> +   imply CPU
> +   imply CPU_RISCV
> +   imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
> +   imply SIFIVE_CLINT if (RISCV_MMODE || SPL_RISCV_MMODE)
> +   imply CMD_CPU
> +   imply SPL_CPU
> +   imply SPL_OPENSBI
> +   imply SPL_LOAD_FIT
> +   imply SMP
> +   imply CLK_SIFIVE
> +   imply CLK_SIFIVE_PRCI
> +   imply SIFIVE_SERIAL
> +   imply MACB
> +   imply MII
> +   imply SPI
> +   imply SPI_SIFIVE
> +   imply MMC
> +   imply MMC_SPI
> +   imply MMC_BROKEN_CD
> +   imply CMD_MMC
> +   imply DM_GPIO
> +   imply SIFIVE_GPIO
> +   imply CMD_GPIO
> +   imply MISC
> +   imply SIFIVE_OTP
> +   imply DM_PWM
> +   imply PWM_SIFIVE
> diff --git a/arch/riscv/cpu/fu740/Makefile b/arch/riscv/cpu/fu740/Makefile
> new file mode 100644
> index 00..5ef8ac18a7
> --- /dev/null
> +++ b/arch/riscv/cpu/fu740/Makefile
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2020-2021 SiFive, Inc
> +# Pragnesh Patel 
> +
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-y += spl.o
> +else
> +obj-y += dram.o
> +obj-y += cpu.o
> +obj-y += cache.o
> +endif
> diff --git a/arch/riscv/cpu/fu740/cache.c b/arch/riscv/cpu/fu740/cache.c
> new file mode 100644
> index 00..680955c9e3
> --- /dev/null
> +++ b/arch/riscv/cpu/fu740/cache.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020-2021 SiFive, Inc
> + *
> + * Authors:
> + *   Pragnesh Patel 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define L2_CACHE_CONFIG0x000
> +#define L2_CACHE_ENABLE0x008
> +
> +#define MASK_NUM_WAYS  GENMASK(15, 8)
> +#define NUM_WAYS_SHIFT 8
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int cache_enable_ways(void)
> +{
> +   const void *blob = gd->fdt_blob;
> +   int node;
> +   fdt_addr_t base;
> +   u32 config;
> +   u32 ways;
> +
> +   volatile u32 *enable;
> +
> +   node = fdt_node_offset_by_compatible(blob, -1,
> +"sifive,fu740-c000-ccache");
> +
> +   if (node < 0)
> +   return node;
> +
> +   base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> +   NULL, false);
> +   if (base == FDT_ADDR_T_NONE)
> +   return FDT_ADDR_T_NONE;
> +
> +   config = 

Re: [PATCH v7 8/8] drivers: net: macb: add fu740 support

[Dimitri John Ledkov]

(resending to list after subscribing)

Hi,

On Thu, Apr 22, 2021 at 10:15 AM Green Wan  wrote:
>
> From: David Abdurachmanov 
>
> Add fu740 support to macb ethernet driver
>
> There is a PLL HW quirk in FU740. The VSC8541XMV-02 specification
> requires 125 +/-0.0125 Mhz. But the most close value can be output
> by PLL is 125.125 MHz and out of VSC8541XMV-02 spec.
>

In the Linux kernel driver for this
drivers/net/ethernet/cadence/macb_main.c it is not marked as
compatible with "sifive,fu740-c000-gem" and it does not have a similar
fix (and appears to use 125.0 MHz).
Should a similar fix be contributed to the Linux kernel?

As otherwise at the moment, one cannot pass the dtb from u-boot to
linux, as that leads to loss of network since the kernel doesn't know
about "sifive,fu740-c000-gem". If linux kernel contribution is not
forthcoming, would it be possible to have u-boot dtb to be compatible
with _both_  "sifive,fu540-c000-gem" and "sifive,fu740-c000-gem" on
unmatched boards, such that if one (mistakenly) uses u-boots dtb with
vanilla linux kernel networking still works? And then adjust the test
to check for "sifive,fu740-c000-gem" compatible string first.

> Signed-off-by: David Abdurachmanov 
> Signed-off-by: Green Wan 
> Reviewed-by: Ramon Fried 
> Reviewed-by: Bin Meng 
> ---
>  drivers/net/macb.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 57ea45e2dc..bf70525c54 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -591,8 +591,17 @@ static int macb_sifive_clk_init(struct udevice *dev, 
> ulong rate)
>  * 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
>  * and output clock on GMII output signal GTX_CLK
>  * 1 = MII mode. Use MII input signal TX_CLK in TX logic
> +*
> +* FU740 have a PLL HW quirk. The 125.125 Mhz is actually out of
> +* VSC8541XMV-02 specification. The tolerance level is +/-100ppm.
> +* Which means the range should be in between 125MHz +/-0.0125.
> +* But the most close value can be output by PLL is 125.125 MHz.
>  */
> -   writel(rate != 12500, gemgxl_regs);
> +   if (device_is_compatible(dev, "sifive,fu540-c000-gem"))
> +   writel(rate != 12500, gemgxl_regs);
> +   else if (device_is_compatible(dev, "sifive,fu740-c000-gem"))
> +   writel(rate != 125125000, gemgxl_regs);
> +
> return 0;
>  }
>
> @@ -1507,6 +1516,8 @@ static const struct udevice_id macb_eth_ids[] = {
> { .compatible = "cdns,zynq-gem" },
> { .compatible = "sifive,fu540-c000-gem",
>   .data = (ulong)_config },
> +   { .compatible = "sifive,fu740-c000-gem",
> + .data = (ulong)_config },
> { .compatible = "microchip,mpfs-mss-gem",
>   .data = (ulong)_config },
> { }
> --
> 2.31.0
>


--
Regards,

Dimitri.


-- 
Regards,

Dimitri.

[PATCH] cli: slighly more clear error messages

[Wang, Peng]

>From e8a2f8a7098f4b18bbbf859ca7c765ebfcd944b0 Mon Sep 17 00:00:00 2001
From: "peng.w...@smartm.com" 
Date: Tue, 4 May 2021 01:45:59 -0700
Subject: [PATCH] cli: slighly more clear error messages

This patch tries to distinguish two error messages.

Signed-off-by: peng.w...@smartm.com 
---
 common/cli_hush.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/cli_hush.c b/common/cli_hush.c
index 6cff3b1185..1467ff81b3 100644
--- a/common/cli_hush.c
+++ b/common/cli_hush.c
@@ -3325,7 +3325,7 @@ static void *xmalloc(size_t size)
void *p = NULL;
 
if (!(p = malloc(size))) {
-   printf("ERROR : memory not allocated\n");
+   printf("ERROR : xmalloc failed\n");
for(;;);
}
return p;
@@ -3336,7 +3336,7 @@ static void *xrealloc(void *ptr, size_t size)
void *p = NULL;
 
if (!(p = realloc(ptr, size))) {
-   printf("ERROR : memory not allocated\n");
+   printf("ERROR : xrealloc failed\n");
for(;;);
}
return p;
-- 
2.31.1.windows.1

[PATCH] cli: Fix non-printable character handling

[Wang, Peng]

>From 8919b7cf69575773ce7140a5412d0547a26bb8e6 Mon Sep 17 00:00:00 2001
From: "peng.w...@smartm.com" 
Date: Tue, 4 May 2021 01:13:31 -0700
Subject: [PATCH] cli: Fix non-printable character handling

This patch converts unhandled non-printable character to a
beep without putting it into the buffer.

Signed-off-by: peng.w...@smartm.com 
---
 common/cli_readline.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/common/cli_readline.c b/common/cli_readline.c
index c7614a4c90..c481917d5e 100644
--- a/common/cli_readline.c
+++ b/common/cli_readline.c
@@ -637,6 +637,12 @@ int cli_readline_into_buffer(const char *const prompt, 
char *buffer,
} else {
char __maybe_unused buf[2];
 
+   if (c <= 0x1f || c > 0x7f) {
+   /* all special characters shall 
be handled above;
+otherwise output an alarm here 
without changing col */
+   putc('\a');
+   continue;
+   }
/*
 * Echo input using puts() to force an
 * LCD flush if we are using an LCD
-- 
2.31.1.windows.1

[PATCH] cli: Fix command line underrun

[Wang, Peng]

>From 7a3110962cd1482793a9912fa14e5d9961e9f01a Mon Sep 17 00:00:00 2001
From: "peng.w...@smartm.com" 
Date: Mon, 3 May 2021 23:53:29 -0700
Subject: [PATCH] cli: Fix command line underrun

This patch adds a column position check to fix the cli issue that
backspace doesn't stop at the prompt.

Signed-off-by: peng.w...@smartm.com 
---
 common/cli_readline.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/cli_readline.c b/common/cli_readline.c
index c7614a4c90..bce670733f 100644
--- a/common/cli_readline.c
+++ b/common/cli_readline.c
@@ -45,8 +45,10 @@ static char *delete_char (char *buffer, char *p, int *colp, 
int *np, int plen)
}
}
} else {
-   puts(erase_seq);
-   (*colp)--;
+   if (*colp > plen) {
+   puts(erase_seq);
+   (*colp)--;
+   }
}
(*np)--;
 
-- 
2.31.1.windows.1

squashfs tests flaky?

[Pratyush Yadav]

Hi,

I am playing around with the U-Boot CI, mostly to make sure my patches 
don't break things. To that end I created a fork of u-boot on GitLab and 
started the CI pipeline on the current master (8ddaf94358).

I see on the official repo the job passes [0]. But on my fork, the job 
fails due to squashfs failures [1]. Both jobs are using the same commit. 
I looked at the failure logs and it seems to be because of some I/O 
errors but I'm not sure what exactly is going on.

[0] https://source.denx.de/u-boot/u-boot/-/jobs/263093
[1] https://gitlab.com/prati0100/uboot/-/jobs/1234264642

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

[PATCH v3 20/20] configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY

[Kishon Vijay Abraham I]

Update the default BOOTCOMMAND to provide an automatic and easier way
to configure ethernet PHY before loading the firmware.

Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j7200_evm_a72_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index bf78b36d22..5929bba82a 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -30,7 +30,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run 
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
 CONFIG_LOGLEVEL=7
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-- 
2.17.1

[PATCH v3 19/20] env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM

[Kishon Vijay Abraham I]

MAIN CPSW0 requires the PHY to be powered on and reset for QSGMII
operation. Add a env variable to configure driving "0" on ENET_EXP_PWRDN
controlled by GPIO EXPANDER2 (I2C Addr: 0x22), PIN: 17 and driving "1"
on ENET_EXP_RESETZ controlled by GPIO EXPANDER2 (I2C Addr: 0x22),
PIN: 18.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Suman Anna 
---
 include/configs/j721e_evm.h | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index b707fc4e89..00d0a18a68 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -139,11 +139,24 @@
 #endif /* CONFIG_TARGET_J721E_A72_EVM */
 
 #ifdef CONFIG_TARGET_J7200_A72_EVM
+#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY \
+   "do_main_cpsw0_qsgmii_phyinit=1\0"  \
+   "init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17;"   \
+"gpio clear gpio@22_16\0"  \
+   "main_cpsw0_qsgmii_phyinit="\
+   "if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1 && test ${dorprocboot} 
-eq 1 && " \
+   "test ${boot} = mmc; then " \
+   "run init_main_cpsw0_qsgmii_phy;"   \
+   "fi;\0"
 #define DEFAULT_RPROCS ""  \
"2 /lib/firmware/j7200-main-r5f0_0-fw " \
"3 /lib/firmware/j7200-main-r5f0_1-fw "
 #endif /* CONFIG_TARGET_J7200_A72_EVM */
 
+#ifndef EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
+#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
+#endif
+
 /* set default dfu_bufsiz to 128KB (sector size of OSPI) */
 #define EXTRA_ENV_DFUARGS \
"dfu_bufsiz=0x2\0" \
@@ -170,7 +183,8 @@
EXTRA_ENV_RPROC_SETTINGS\
EXTRA_ENV_DFUARGS   \
DEFAULT_UFS_TI_ARGS \
-   EXTRA_ENV_J721E_BOARD_SETTINGS_MTD
+   EXTRA_ENV_J721E_BOARD_SETTINGS_MTD  \
+   EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
 
 /* Now for the remaining common defines */
 #include 
-- 
2.17.1

[PATCH v3 18/20] configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add config for torrent serdes and common clock framework.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j7200_evm_a72_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 162bcc8753..bf78b36d22 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -96,6 +96,7 @@ CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_CLK_CCF=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
@@ -138,9 +139,15 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_SPI_FLASH_MTD=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_TORRENT=y
+CONFIG_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1

[PATCH v3 17/20] configs: j721e_evm_a72: Enable the drivers required for the USB3 support

[Kishon Vijay Abraham I]

From: Jean-Jacques Hiblot 

Enable the mmio mux driver, the J721E-wiz PHy driver and the cadence sierra
phy driver. All of them are required for USB3 support

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j721e_evm_a72_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index e14005c39d..5b46f2d53f 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -136,9 +136,15 @@ CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_TI_DP83867=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_SIERRA=y
+CONFIG_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1

[PATCH v3 16/20] arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add u-boot tags for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index bd037be350..bfe1ef5409 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -160,3 +160,15 @@
 _mux {
u-boot,dm-spl;
 };
+
+_ln_ctrl {
+   u-boot,mux-autoprobe;
+};
+
+_serdes_mux {
+   u-boot,mux-autoprobe;
+};
+
+ {
+   u-boot,dm-spl;
+};
-- 
2.17.1

[PATCH v3 15/20] arm: dts: k3-j7200-common-proc-board: Enable SERDES DT

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add default lane function for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-common-proc-board.dts | 23 +
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-common-proc-board.dts
index 5120711d4f..f0440cda1a 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
chosen {
@@ -281,3 +282,25 @@
ti,adc-channels = <0 1 2 3 4 5 6 7>;
};
 };
+
+_refclk {
+   clock-frequency = <1>;
+};
+
+ {
+   serdes0_pcie_link: link@0 {
+   reg = <0>;
+   cdns,num-lanes = <2>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   resets = <_wiz0 1>, <_wiz0 2>;
+   };
+
+   serdes0_qsgmii_link: link@1 {
+   reg = <2>;
+   cdns,num-lanes = <1>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   resets = <_wiz0 3>;
+   };
+};
-- 
2.17.1

[PATCH v3 14/20] arm: dts: k3-j7200-main: Add DT node for torrent serdes

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add DT node for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-main.dtsi | 63 +
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
index 1131464075..138702cf9d 100644
--- a/arch/arm/dts/k3-j7200-main.dtsi
+++ b/arch/arm/dts/k3-j7200-main.dtsi
@@ -5,6 +5,13 @@
  * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+/ {
+   serdes_refclk: serdes-refclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   };
+};
+
 _main {
msmc_ram: sram@7000 {
compatible = "mmio-sram";
@@ -554,6 +561,62 @@
clock-names = "gpio";
};
 
+   serdes_wiz0: wiz@506 {
+   compatible = "ti,j721e-wiz-10g";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   power-domains = <_pds 292 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 292 11>, <_clks 292 85>, <_refclk>;
+   clock-names = "fck", "core_ref_clk", "ext_ref_clk";
+   num-lanes = <4>;
+   #reset-cells = <1>;
+   ranges = <0x506 0x0 0x506 0x1>;
+
+   assigned-clocks = <_clks 292 85>;
+   assigned-clock-parents = <_clks 292 89>;
+
+   wiz0_pll0_refclk: pll0-refclk {
+   clocks = <_clks 292 85>, <_refclk>;
+   clock-output-names = "wiz0_pll0_refclk";
+   #clock-cells = <0>;
+   assigned-clocks = <_pll0_refclk>;
+   assigned-clock-parents = <_clks 292 85>;
+   };
+
+   wiz0_pll1_refclk: pll1-refclk {
+   clocks = <_clks 292 85>, <_refclk>;
+   clock-output-names = "wiz0_pll1_refclk";
+   #clock-cells = <0>;
+   assigned-clocks = <_pll1_refclk>;
+   assigned-clock-parents = <_clks 292 85>;
+   };
+
+   wiz0_refclk_dig: refclk-dig {
+   clocks = <_clks 292 85>, <_refclk>;
+   clock-output-names = "wiz0_refclk_dig";
+   #clock-cells = <0>;
+   assigned-clocks = <_refclk_dig>;
+   assigned-clock-parents = <_clks 292 85>;
+   };
+
+   wiz0_cmn_refclk_dig_div: cmn-refclk-dig-div {
+   clocks = <_refclk_dig>;
+   #clock-cells = <0>;
+   };
+
+   serdes0: serdes@506 {
+   compatible = "ti,j721e-serdes-10g";
+   reg = <0x0506 0x0001>;
+   reg-names = "torrent_phy";
+   resets = <_wiz0 0>;
+   reset-names = "torrent_reset";
+   clocks = <_pll0_refclk>;
+   clock-names = "refclk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
usbss0: cdns-usb@4104000 {
compatible = "ti,j721e-usb";
reg = <0x00 0x4104000 0x00 0x100>;
-- 
2.17.1

[PATCH v3 13/20] ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0

[Kishon Vijay Abraham I]

Partially sync with Linux's dts to add the entries required for USB3
support on USB0.
Note that the default mode is still "peripheral" not "host". USB3 is
supported only for the host mode.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../k3-j721e-common-proc-board-u-boot.dtsi| 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 3384ed9f3a..3b2e40c13d 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -115,13 +115,17 @@
u-boot,dm-spl;
 };
 
+_pll1_refclk {
+   assigned-clocks = <_pll1_refclk>, <_pll0_refclk>;
+   assigned-clock-parents = <_clks 295 0>, <_clks 295 9>;
+};
+
 _usbss0_pins_default {
u-boot,dm-spl;
 };
 
  {
u-boot,dm-spl;
-   ti,usb2-only;
 };
 
  {
@@ -193,3 +197,16 @@
 _fss0_ospi1_pins_default {
u-boot,dm-spl;
 };
+
+_pll1_refclk {
+   assigned-clocks = <_pll1_refclk>, <_pll0_refclk>;
+   assigned-clock-parents = <_clks 295 0>, <_clks 295 9>;
+};
+
+_ln_ctrl {
+   u-boot,mux-autoprobe;
+};
+
+_serdes_mux {
+   u-boot,mux-autoprobe;
+};
-- 
2.17.1

[PATCH v3 12/20] board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add support for probing and configuring Torrent serdes on J7200.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 board/ti/j721e/evm.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index b9a9f19552..580f13c3ab 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,7 +30,8 @@
 #define board_is_j721e_som()   (board_ti_k3_is("J721EX-PM1-SOM") || \
 board_ti_k3_is("J721EX-PM2-SOM"))
 
-#define board_is_j7200_som()   board_ti_k3_is("J7200X-PM1-SOM")
+#define board_is_j7200_som()   (board_ti_k3_is("J7200X-PM1-SOM") || \
+board_ti_k3_is("J7200X-PM2-SOM"))
 
 /* Max number of MAC addresses that are parsed/processed per daughter card */
 #define DAUGHTER_CARD_NO_OF_MAC_ADDR   8
@@ -384,6 +386,33 @@ static int probe_daughtercards(void)
 }
 #endif
 
+void configure_serdes_torrent(void)
+{
+   struct udevice *dev;
+   struct phy serdes;
+   int ret;
+
+   if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT))
+   return;
+
+   ret = uclass_get_device_by_driver(UCLASS_PHY,
+ DM_DRIVER_GET(torrent_phy_provider),
+ );
+   if (ret)
+   printf("Torrent init failed:%d\n", ret);
+
+   serdes.dev = dev;
+   serdes.id = 0;
+
+   ret = generic_phy_init();
+   if (ret)
+   printf("phy_init failed!!\n");
+
+   ret = generic_phy_power_on();
+   if (ret)
+   printf("phy_power_on failed !!\n");
+}
+
 int board_late_init(void)
 {
if (IS_ENABLED(CONFIG_TI_I2C_BOARD_DETECT)) {
@@ -394,6 +423,9 @@ int board_late_init(void)
probe_daughtercards();
}
 
+   if (board_is_j7200_som())
+   configure_serdes_torrent();
+
return 0;
 }
 
-- 
2.17.1

[PATCH v3 10/20] phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC

[Kishon Vijay Abraham I]

From: Jean-Jacques Hiblot 

Add support for WIZ module present in TI's J721E SoC. WIZ is a SERDES
wrapper used to configure some of the input signals to the SERDES. It is
used with both Sierra(16G) and Torrent(10G) SERDES. This driver configures
three clock selects (pll0, pll1, dig) and supports resets for each of the
lanes.

This is an adaptation of the linux driver.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig|1 +
 drivers/phy/Makefile   |1 +
 drivers/phy/ti/Kconfig |9 +
 drivers/phy/ti/Makefile|1 +
 drivers/phy/ti/phy-j721e-wiz.c | 1154 
 5 files changed, 1166 insertions(+)
 create mode 100644 drivers/phy/ti/Kconfig
 create mode 100644 drivers/phy/ti/Makefile
 create mode 100644 drivers/phy/ti/phy-j721e-wiz.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 9208e430a6..7821161e3c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -270,5 +270,6 @@ config PHY_MTK_TPHY
 
 source "drivers/phy/rockchip/Kconfig"
 source "drivers/phy/cadence/Kconfig"
+source "drivers/phy/ti/Kconfig"
 
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 4736c5eadb..2efaa8827b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
 obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
 obj-y += cadence/
+obj-y += ti/
diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig
new file mode 100644
index 00..111085f235
--- /dev/null
+++ b/drivers/phy/ti/Kconfig
@@ -0,0 +1,9 @@
+config PHY_J721E_WIZ
+   tristate "TI J721E WIZ (SERDES Wrapper) support"
+   depends on ARCH_K3
+   help
+ This option enables support for WIZ module present in TI's J721E
+ SoC. WIZ is a serdes wrapper used to configure some of the input
+ signals to the SERDES (Sierra/Torrent). This driver configures
+ three clock selects (pll0, pll1, dig) and resets for each of the
+ lanes.
diff --git a/drivers/phy/ti/Makefile b/drivers/phy/ti/Makefile
new file mode 100644
index 00..873ddbf036
--- /dev/null
+++ b/drivers/phy/ti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_$(SPL_)PHY_J721E_WIZ) += phy-j721e-wiz.o
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
new file mode 100644
index 00..cac55c9c80
--- /dev/null
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -0,0 +1,1154 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define WIZ_MAX_INPUT_CLOCKS   4
+/* To include mux clocks, divider clocks and gate clocks */
+#define WIZ_MAX_OUTPUT_CLOCKS  32
+
+#define WIZ_MAX_LANES  4
+#define WIZ_MUX_NUM_CLOCKS 3
+#define WIZ_DIV_NUM_CLOCKS_16G 2
+#define WIZ_DIV_NUM_CLOCKS_10G 1
+
+#define WIZ_SERDES_CTRL0x404
+#define WIZ_SERDES_TOP_CTRL0x408
+#define WIZ_SERDES_RST 0x40c
+#define WIZ_SERDES_TYPEC   0x410
+#define WIZ_LANECTL(n) (0x480 + (0x40 * (n)))
+#define WIZ_LANEDIV(n) (0x484 + (0x40 * (n)))
+
+#define WIZ_MAX_LANES  4
+#define WIZ_MUX_NUM_CLOCKS 3
+#define WIZ_DIV_NUM_CLOCKS_16G 2
+#define WIZ_DIV_NUM_CLOCKS_10G 1
+
+#define WIZ_SERDES_TYPEC_LN10_SWAP BIT(30)
+
+enum wiz_lane_standard_mode {
+   LANE_MODE_GEN1,
+   LANE_MODE_GEN2,
+   LANE_MODE_GEN3,
+   LANE_MODE_GEN4,
+};
+
+enum wiz_refclk_mux_sel {
+   PLL0_REFCLK,
+   PLL1_REFCLK,
+   REFCLK_DIG,
+};
+
+enum wiz_refclk_div_sel {
+   CMN_REFCLK,
+   CMN_REFCLK1,
+};
+
+enum wiz_clock_input {
+   WIZ_CORE_REFCLK,
+   WIZ_EXT_REFCLK,
+   WIZ_CORE_REFCLK1,
+   WIZ_EXT_REFCLK1,
+};
+
+static const struct reg_field por_en = REG_FIELD(WIZ_SERDES_CTRL, 31, 31);
+static const struct reg_field phy_reset_n = REG_FIELD(WIZ_SERDES_RST, 31, 31);
+static const struct reg_field pll1_refclk_mux_sel =
+   REG_FIELD(WIZ_SERDES_RST, 29, 29);
+static const struct reg_field pll0_refclk_mux_sel =
+   REG_FIELD(WIZ_SERDES_RST, 28, 28);
+static const struct reg_field refclk_dig_sel_16g =
+   REG_FIELD(WIZ_SERDES_RST, 24, 25);
+static const struct reg_field refclk_dig_sel_10g =
+   REG_FIELD(WIZ_SERDES_RST, 24, 24);
+static const struct reg_field pma_cmn_refclk_int_mode =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 28, 29);
+static const struct reg_field pma_cmn_refclk_mode =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 30, 31);
+static const struct reg_field 

[PATCH v3 11/20] usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name

[Kishon Vijay Abraham I]

Upstream device tree got updated to use clock name as "ref" instead of
"usb2_refclk". Fix cdns3-ti.c to use the correct name.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/cdns3/cdns3-ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 7b205c5656..43171678ee 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -101,7 +101,7 @@ static int cdns_ti_probe(struct udevice *dev)
if (!data->usbss)
return -EINVAL;
 
-   ret = clk_get_by_name(dev, "usb2_refclk", _refclk);
+   ret = clk_get_by_name(dev, "ref", _refclk);
if (ret) {
dev_err(dev, "Failed to get usb2_refclk\n");
return ret;
-- 
2.17.1

[PATCH v3 09/20] phy: cadence: Add driver for Torrent SERDES

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add driver for Torrent SERDES.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/cadence/Kconfig   |6 +
 drivers/phy/cadence/Makefile  |1 +
 drivers/phy/cadence/phy-cadence-torrent.c | 2468 +
 3 files changed, 2475 insertions(+)
 create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c

diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index 18a04819f5..549ddbf504 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -3,3 +3,9 @@ config PHY_CADENCE_SIERRA
depends on DM_RESET
help
  Enable this to support the Cadence Sierra PHY driver
+
+config PHY_CADENCE_TORRENT
+   tristate "Cadence Torrent PHY Driver"
+   depends on DM_RESET
+   help
+ Enable this to support the Cadence Torrent PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index d57856152a..af63b32d9f 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o
+obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c 
b/drivers/phy/cadence/phy-cadence-torrent.c
new file mode 100644
index 00..f959703e80
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -0,0 +1,2468 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence Torrent SD0801 PHY driver.
+ *
+ * Based on the linux driver provided by Cadence
+ *
+ * Copyright (c) 2018 Cadence Design Systems
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REF_CLK_19_2MHz1920
+#define REF_CLK_25MHz  2500
+
+#define MAX_NUM_LANES  4
+#define DEFAULT_MAX_BIT_RATE   8100 /* in Mbps*/
+
+#define NUM_SSC_MODE   3
+#define NUM_PHY_TYPE   6
+
+#define POLL_TIMEOUT_US5000
+#define PLL_LOCK_TIMEOUT   10
+
+#define TORRENT_COMMON_CDB_OFFSET  0x0
+
+#define TORRENT_TX_LANE_CDB_OFFSET(ln, block_offset, reg_offset)   \
+   ((0x4000 << (block_offset)) +   \
+   (((ln) << 9) << (reg_offset)))
+#define TORRENT_RX_LANE_CDB_OFFSET(ln, block_offset, reg_offset)   \
+   ((0x8000 << (block_offset)) +   \
+   (((ln) << 9) << (reg_offset)))
+
+#define TORRENT_PHY_PCS_COMMON_OFFSET(block_offset)\
+   (0xC000 << (block_offset))
+
+#define TORRENT_PHY_PMA_COMMON_OFFSET(block_offset)\
+   (0xE000 << (block_offset))
+
+/*
+ * register offsets from SD0801 PHY register block base (i.e MHDP
+ * register base + 0x50)
+ */
+#define CMN_SSM_BANDGAP_TMR0x0021U
+#define CMN_SSM_BIAS_TMR   0x0022U
+#define CMN_PLLSM0_PLLPRE_TMR  0x002AU
+#define CMN_PLLSM0_PLLLOCK_TMR 0x002CU
+#define CMN_PLLSM1_PLLPRE_TMR  0x0032U
+#define CMN_PLLSM1_PLLLOCK_TMR 0x0034U
+#define CMN_CDIAG_CDB_PWRI_OVRD0x0041U
+#define CMN_CDIAG_XCVRC_PWRI_OVRD  0x0047U
+#define CMN_BGCAL_INIT_TMR 0x0064U
+#define CMN_BGCAL_ITER_TMR 0x0065U
+#define CMN_IBCAL_INIT_TMR 0x0074U
+#define CMN_PLL0_VCOCAL_TCTRL  0x0082U
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084U
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085U
+#define CMN_PLL0_VCOCAL_REFTIM_START   0x0086U
+#define CMN_PLL0_VCOCAL_PLLCNT_START   0x0088U
+#define CMN_PLL0_INTDIV_M0 0x0090U
+#define CMN_PLL0_FRACDIVL_M0   0x0091U
+#define CMN_PLL0_FRACDIVH_M0   0x0092U
+#define CMN_PLL0_HIGH_THR_M0   0x0093U
+#define CMN_PLL0_DSM_DIAG_M0   0x0094U
+#define CMN_PLL0_SS_CTRL1_M0   0x0098U
+#define CMN_PLL0_SS_CTRL2_M0   0x0099U
+#define CMN_PLL0_SS_CTRL3_M0   0x009AU
+#define CMN_PLL0_SS_CTRL4_M0   0x009BU
+#define CMN_PLL0_LOCK_REFCNT_START 0x009CU
+#define CMN_PLL0_LOCK_PLLCNT_START 0x009EU
+#define CMN_PLL0_LOCK_PLLCNT_THR   0x009FU
+#define CMN_PLL0_INTDIV_M1 0x00A0U
+#define CMN_PLL0_FRACDIVH_M1   0x00A2U
+#define CMN_PLL0_HIGH_THR_M1   0x00A3U
+#define CMN_PLL0_DSM_DIAG_M1   0x00A4U
+#define CMN_PLL0_SS_CTRL1_M1   0x00A8U
+#define CMN_PLL0_SS_CTRL2_M1   0x00A9U
+#define CMN_PLL0_SS_CTRL3_M1   0x00AAU
+#define CMN_PLL0_SS_CTRL4_M1   0x00ABU
+#define CMN_PLL1_VCOCAL_TCTRL  0x00C2U
+#define CMN_PLL1_VCOCAL_INIT_TMR   0x00C4U
+#define CMN_PLL1_VCOCAL_ITER_TMR   0x00C5U
+#define CMN_PLL1_VCOCAL_REFTIM_START   0x00C6U

[PATCH v3 08/20] phy: cadence: Add driver for Sierra PHY

[Kishon Vijay Abraham I]

From: Alan Douglas 

Add a Sierra PHY driver with PCIe and USB support.
This driver is a port from the mainline linux driver.

The PHY has multiple lanes, which can be configured into
groups, and a generic PHY device is created for each group.

There are two resets controlling the overall PHY block, one
to enable the APB interface for programming registers, and
another to enable the PHY itself.  Additionally there are
resets for each PHY lane.

The PHY can be configured in hardware to read register
settings from ROM, or they can be written by the driver.

The sequence of operation on startup is to enable the APB
bus, write the PHY registers (if required)  for each lane
group, and then enable the PHY.  Each group of lanes
can then be individually controlled using the power_on()/
power_off() function for that generic PHY

One difference with the linux driver is that the PHY is
always reset after it is powered-on. This is because role
switching is not supported in u-boot and the cable
orientation is handled by the PHY reset.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Alan Douglas 
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Vignesh Raghavendra 
---
 drivers/phy/Kconfig  |   2 +
 drivers/phy/Makefile |   1 +
 drivers/phy/cadence/Kconfig  |   5 +
 drivers/phy/cadence/Makefile |   1 +
 drivers/phy/cadence/phy-cadence-sierra.c | 757 +++
 5 files changed, 766 insertions(+)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 008186a10d..9208e430a6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -269,4 +269,6 @@ config PHY_MTK_TPHY
  so you can easily distinguish them by banks layout.
 
 source "drivers/phy/rockchip/Kconfig"
+source "drivers/phy/cadence/Kconfig"
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 3c4a673a83..4736c5eadb 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MT7620_USB_PHY) += mt7620-usb-phy.o
 obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
 obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-y += cadence/
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
new file mode 100644
index 00..18a04819f5
--- /dev/null
+++ b/drivers/phy/cadence/Kconfig
@@ -0,0 +1,5 @@
+config PHY_CADENCE_SIERRA
+   tristate "Cadence Sierra PHY Driver"
+   depends on DM_RESET
+   help
+ Enable this to support the Cadence Sierra PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
new file mode 100644
index 00..d57856152a
--- /dev/null
+++ b/drivers/phy/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c 
b/drivers/phy/cadence/phy-cadence-sierra.c
new file mode 100644
index 00..66c671aded
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -0,0 +1,757 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence Sierra PHY Driver
+ *
+ * Based on the linux driver provided by Cadence
+ *
+ * Copyright (c) 2018 Cadence Design Systems
+ * Author: Alan Douglas 
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY register offsets */
+#define SIERRA_COMMON_CDB_OFFSET   0x0
+#define SIERRA_MACRO_ID_REG0x0
+#define SIERRA_CMN_PLLLC_MODE_PREG 0x48
+#define SIERRA_CMN_PLLLC_LF_COEFF_MODE1_PREG   0x49
+#define SIERRA_CMN_PLLLC_LF_COEFF_MODE0_PREG   0x4A
+#define SIERRA_CMN_PLLLC_LOCK_CNTSTART_PREG0x4B
+#define SIERRA_CMN_PLLLC_BWCAL_MODE1_PREG  0x4F
+#define SIERRA_CMN_PLLLC_BWCAL_MODE0_PREG  0x50
+#define SIERRA_CMN_PLLLC_SS_TIME_STEPSIZE_MODE_PREG0x62
+
+#define SIERRA_LANE_CDB_OFFSET(ln, offset) \
+   (0x4000 + ((ln) * (0x800 >> (2 - (offset)
+
+#define SIERRA_DET_STANDEC_A_PREG  0x000
+#define SIERRA_DET_STANDEC_B_PREG  0x001
+#define SIERRA_DET_STANDEC_C_PREG  0x002
+#define SIERRA_DET_STANDEC_D_PREG  0x003
+#define SIERRA_DET_STANDEC_E_PREG  0x004
+#define SIERRA_PSM_LANECAL_DLY_A1_RESETS_PREG  0x008
+#define SIERRA_PSM_A0IN_TMR_PREG   0x009
+#define SIERRA_PSM_DIAG_PREG   0x015
+#define SIERRA_PSC_TX_A0_PREG  0x028
+#define SIERRA_PSC_TX_A1_PREG  

[PATCH v3 07/20] dt-bindings: ti-serdes-mux: Add defines for AM64 SoC

[Kishon Vijay Abraham I]

AM64 has a single lane SERDES which can be configured to be used
with either PCIe or USB. Define the possilbe values for the SERDES
function in AM64 SoC here.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/dt-bindings/mux/ti-serdes.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/dt-bindings/mux/ti-serdes.h 
b/include/dt-bindings/mux/ti-serdes.h
index 9047ec6bd3..d417b9268b 100644
--- a/include/dt-bindings/mux/ti-serdes.h
+++ b/include/dt-bindings/mux/ti-serdes.h
@@ -90,4 +90,9 @@
 #define J7200_SERDES0_LANE3_USB0x2
 #define J7200_SERDES0_LANE3_IP4_UNUSED 0x3
 
+/* AM64 */
+
+#define AM64_SERDES0_LANE0_PCIE0   0x0
+#define AM64_SERDES0_LANE0_USB 0x1
+
 #endif /* _DT_BINDINGS_MUX_TI_SERDES */
-- 
2.17.1

[PATCH v3 06/20] dt-bindings: phy: cadence-torrent: Add defines for refclk driver

[Kishon Vijay Abraham I]

Add defines for refclk driver used to route the refclk out of torrent
SERDES.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/dt-bindings/phy/phy-cadence.h | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 include/dt-bindings/phy/phy-cadence.h

diff --git a/include/dt-bindings/phy/phy-cadence.h 
b/include/dt-bindings/phy/phy-cadence.h
new file mode 100644
index 00..4652bcb862
--- /dev/null
+++ b/include/dt-bindings/phy/phy-cadence.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides constants for Cadence SERDES.
+ */
+
+#ifndef _DT_BINDINGS_CADENCE_SERDES_H
+#define _DT_BINDINGS_CADENCE_SERDES_H
+
+/* Torrent */
+#define TORRENT_SERDES_NO_SSC  0
+#define TORRENT_SERDES_EXTERNAL_SSC1
+#define TORRENT_SERDES_INTERNAL_SSC2
+
+#define CDNS_TORRENT_REFCLK_DRIVER  0
+
+/* Sierra */
+#define CDNS_SIERRA_PLL_CMNLC  0
+#define CDNS_SIERRA_PLL_CMNLC1 1
+
+#endif /* _DT_BINDINGS_CADENCE_SERDES_H */
-- 
2.17.1

[PATCH v3 05/20] dt-bindings: phy: Add defines for AM64 SERDES Wrapper

[Kishon Vijay Abraham I]

Add defines for AM64 SERDES Wrapper.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/dt-bindings/phy/phy-ti.h | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 include/dt-bindings/phy/phy-ti.h

diff --git a/include/dt-bindings/phy/phy-ti.h b/include/dt-bindings/phy/phy-ti.h
new file mode 100644
index 00..ad955d3a56
--- /dev/null
+++ b/include/dt-bindings/phy/phy-ti.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides constants for TI SERDES.
+ */
+
+#ifndef _DT_BINDINGS_TI_SERDES
+#define _DT_BINDINGS_TI_SERDES
+
+/* Clock index for output clocks from WIZ */
+
+/* MUX Clocks */
+#define TI_WIZ_PLL0_REFCLK 0
+#define TI_WIZ_PLL1_REFCLK 1
+#define TI_WIZ_REFCLK_DIG  2
+
+/* Reserve index here for future additions */
+
+/* MISC Clocks */
+#define TI_WIZ_PHY_EN_REFCLK   16
+
+#endif /* _DT_BINDINGS_TI_SERDES */
-- 
2.17.1

[PATCH v3 04/20] dt-bindings: phy: Add definitions for additional phy types

[Kishon Vijay Abraham I]

From: Aswath Govindraju 

Add definitions for additional phy types that's used specifically for
Torrent SERDES.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 include/dt-bindings/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 7e657da454..d3714edd4b 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -19,5 +19,6 @@
 #define PHY_TYPE_DP6
 #define PHY_TYPE_XPCS  7
 #define PHY_TYPE_SGMII 8
+#define PHY_TYPE_QSGMII9
 
 #endif /* _DT_BINDINGS_PHY */
-- 
2.17.1

[PATCH v3 03/20] drivers: reset: Handle gracefully NULL pointers

[Kishon Vijay Abraham I]

The reset framework provides devm_reset_control_get_optional()
which can return NULL (not an error case). So all the other reset_ops
should handle NULL gracefully. Prepare the way for a managed reset
API by handling NULL pointers without crashing nor failing.

Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/reset/reset-uclass.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index ac89eaf098..18dfe06d1c 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -162,7 +162,12 @@ int reset_get_by_name(struct udevice *dev, const char 
*name,
 
 int reset_request(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops;
+
+   if (!reset_ctl)
+   return 0;
+
+   ops = reset_dev_ops(reset_ctl->dev);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
@@ -171,7 +176,12 @@ int reset_request(struct reset_ctl *reset_ctl)
 
 int reset_free(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops;
+
+   if (!reset_ctl)
+   return 0;
+
+   ops = reset_dev_ops(reset_ctl->dev);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
@@ -180,7 +190,12 @@ int reset_free(struct reset_ctl *reset_ctl)
 
 int reset_assert(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops;
+
+   if (!reset_ctl)
+   return 0;
+
+   ops = reset_dev_ops(reset_ctl->dev);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
@@ -202,7 +217,12 @@ int reset_assert_bulk(struct reset_ctl_bulk *bulk)
 
 int reset_deassert(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops;
+
+   if (!reset_ctl)
+   return 0;
+
+   ops = reset_dev_ops(reset_ctl->dev);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
@@ -224,7 +244,12 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 
 int reset_status(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops;
+
+   if (!reset_ctl)
+   return 0;
+
+   ops = reset_dev_ops(reset_ctl->dev);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-- 
2.17.1

[PATCH v3 00/20] TI/Cadence: Add Sierra/Torrent SERDES driver

[Kishon Vijay Abraham I]

Patch series adds Sierra and Torrent SERDES driver for the SERDES
used in TI's K3 platforms. This SERDES is used by USB3, PCIe and
Ethernet. This series is mostly an adaptation of drivers added in
upstream Linux kernel.

Changes from v2:
1) Re-worked "Handle gracefully NULL pointers" to fix Simons comments
2) Ported the part that allows creating clocks without explicit
sub-nodes in DT from the upstream linux kernel.

Changes from v1:
1) Fixed string comparison strncmp() to remove "=="
2) Added a test for node name comparison to ignore unit address
   in test/dm
3) Added better commit message in "drivers: reset: Handle gracefully
   NULL pointers"

Alan Douglas (1):
  phy: cadence: Add driver for Sierra PHY

Aswath Govindraju (7):
  dt-bindings: phy: Add definitions for additional phy types
  phy: cadence: Add driver for Torrent SERDES
  board: ti: j721e: Add support for probing and configuring Torrent
serdes on J7200
  arm: dts: k3-j7200-main: Add DT node for torrent serdes
  arm: dts: k3-j7200-common-proc-board: Enable SERDES DT
  arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for
torrent serdes
  configs: j7200_evm_a72_defconfig: Add config for torrent serdes and
common clock framework

Jean-Jacques Hiblot (2):
  phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC
  configs: j721e_evm_a72: Enable the drivers required for the USB3
support

Kishon Vijay Abraham I (10):
  dm: core: Add helper to compare node names
  dm: test: Add test case to check node name ignoring unit address
  drivers: reset: Handle gracefully NULL pointers
  dt-bindings: phy: Add defines for AM64 SERDES Wrapper
  dt-bindings: phy: cadence-torrent: Add defines for refclk driver
  dt-bindings: ti-serdes-mux: Add defines for AM64 SoC
  usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name
  ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0
  env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in
J7200 EVM
  configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY

 .../k3-j7200-common-proc-board-u-boot.dtsi|   12 +
 arch/arm/dts/k3-j7200-common-proc-board.dts   |   23 +
 arch/arm/dts/k3-j7200-main.dtsi   |   63 +
 .../k3-j721e-common-proc-board-u-boot.dtsi|   19 +-
 board/ti/j721e/evm.c  |   34 +-
 configs/j7200_evm_a72_defconfig   |9 +-
 configs/j721e_evm_a72_defconfig   |6 +
 drivers/core/ofnode.c |   13 +
 drivers/phy/Kconfig   |3 +
 drivers/phy/Makefile  |2 +
 drivers/phy/cadence/Kconfig   |   11 +
 drivers/phy/cadence/Makefile  |2 +
 drivers/phy/cadence/phy-cadence-sierra.c  |  757 +
 drivers/phy/cadence/phy-cadence-torrent.c | 2468 +
 drivers/phy/ti/Kconfig|9 +
 drivers/phy/ti/Makefile   |1 +
 drivers/phy/ti/phy-j721e-wiz.c| 1154 
 drivers/reset/reset-uclass.c  |   35 +-
 drivers/usb/cdns3/cdns3-ti.c  |2 +-
 include/configs/j721e_evm.h   |   16 +-
 include/dm/ofnode.h   |   10 +
 include/dt-bindings/mux/ti-serdes.h   |5 +
 include/dt-bindings/phy/phy-cadence.h |   20 +
 include/dt-bindings/phy/phy-ti.h  |   21 +
 include/dt-bindings/phy/phy.h |1 +
 test/dm/core.c|   14 +
 26 files changed, 4700 insertions(+), 10 deletions(-)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c
 create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c
 create mode 100644 drivers/phy/ti/Kconfig
 create mode 100644 drivers/phy/ti/Makefile
 create mode 100644 drivers/phy/ti/phy-j721e-wiz.c
 create mode 100644 include/dt-bindings/phy/phy-cadence.h
 create mode 100644 include/dt-bindings/phy/phy-ti.h

-- 
2.17.1

[PATCH v3 02/20] dm: test: Add test case to check node name ignoring unit address

[Kishon Vijay Abraham I]

Add test to check node name ignoring unit address.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Simon Glass 
---
 test/dm/core.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/test/dm/core.c b/test/dm/core.c
index 2210345dd1..e83f71f767 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -177,6 +177,20 @@ static int dm_test_autobind_uclass_pdata_alloc(struct 
unit_test_state *uts)
 }
 DM_TEST(dm_test_autobind_uclass_pdata_alloc, UT_TESTF_SCAN_PDATA);
 
+/* compare node names ignoring the unit address */
+static int dm_test_compare_node_name(struct unit_test_state *uts)
+{
+   ofnode node;
+
+   node = ofnode_path("/mmio-bus@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(ofnode_name_eq(node, "mmio-bus"));
+
+   return 0;
+}
+
+DM_TEST(dm_test_compare_node_name, UT_TESTF_SCAN_PDATA);
+
 /* Test that binding with uclass plat setting occurs correctly */
 static int dm_test_autobind_uclass_pdata_valid(struct unit_test_state *uts)
 {
-- 
2.17.1

[PATCH v3 01/20] dm: core: Add helper to compare node names

[Kishon Vijay Abraham I]

Add helper to compare node names.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/core/ofnode.c | 13 +
 include/dm/ofnode.h   | 10 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index d5058e..2a5b12040c 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -18,6 +18,19 @@
 #include 
 #include 
 
+bool ofnode_name_eq(ofnode node, const char *name)
+{
+   const char *node_name;
+   size_t len;
+
+   assert(ofnode_valid(node));
+
+   node_name = ofnode_get_name(node);
+   len = strchrnul(node_name, '@') - node_name;
+
+   return (strlen(name) == len) && !strncmp(node_name, name, len);
+}
+
 int ofnode_read_u32(ofnode node, const char *propname, u32 *outp)
 {
return ofnode_read_u32_index(node, propname, 0, outp);
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 8a69fd87da..ca98f7237c 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -231,6 +231,16 @@ static inline ofnode ofnode_root(void)
return node;
 }
 
+/**
+ * ofnode_name_eq() - Check if the node name is equivalent to a given name
+ *ignoring the unit address
+ *
+ * @node:  valid node reference that has to be compared
+ * @name:  name that has to be compared with the node name
+ * @return true if matches, false if it doesn't match
+ */
+bool ofnode_name_eq(ofnode node, const char *name);
+
 /**
  * ofnode_read_u32() - Read a 32-bit integer from a property
  *
-- 
2.17.1

[PATCH v3] dm: core: Add address translation in fdt_get_resource

[Patrick Delaunay]

Today of_address_to_resource() is called only in
ofnode_read_resource() for livetree support and
fdt_get_resource() is called when livetree is not supported.

The fdt_get_resource() doesn't do the address translation
so when it is required, but the address translation is done
by ofnode_read_resource() caller, for example in
drivers/firmware/scmi/smt.c::scmi_dt_get_smt_buffer() {
...
ret = ofnode_read_resource(args.node, 0, );
if (ret)
return ret;

faddr = cpu_to_fdt32(resource.start);
paddr = ofnode_translate_address(args.node, );
...

The both behavior should be aligned and the address translation
must be called in fdt_get_resource() and removed for each caller.

Fixes: a44810123f9e ("dm: core: Add dev_read_resource() to read device 
resources")
Signed-off-by: Patrick Delaunay 
---

This patch allows to remove the workaround in smci/smt.c
introduced by [1].

But it impact with all user of
- ofnode_read_resource
- ofnode_read_resource_byname
- dev_read_resource
- dev_read_resource_byname

After my first check, the only impacts are in drivers/net/mscc_eswitch
=> I remove the unnecessary translate after code review,
   this patch need to be verify on real hardware

I proposed to merge the workaround [1] as soon as possible to avoid issue
on stm32mp1 platform and this patch can be merged when it will be acked
by mscc_eswitch maintainers and other API users.

[1] "scmi: translate the resource only when livetree is not activated"
http://patchwork.ozlabs.org/project/uboot/list/?series=236526=*


Changes in v3:
- add test dm_test_read_resource

Changes in v2:
- remove translate in luton_switch.c:luton_probe()

 drivers/firmware/scmi/smt.c   | 12 +
 drivers/net/mscc_eswitch/jr2_switch.c |  4 +--
 drivers/net/mscc_eswitch/luton_switch.c   |  5 +---
 drivers/net/mscc_eswitch/ocelot_switch.c  |  4 +--
 drivers/net/mscc_eswitch/serval_switch.c  |  4 +--
 drivers/net/mscc_eswitch/servalt_switch.c |  4 +--
 lib/fdtdec.c  |  6 -
 test/dm/test-fdt.c| 33 +++
 8 files changed, 44 insertions(+), 28 deletions(-)

diff --git a/drivers/firmware/scmi/smt.c b/drivers/firmware/scmi/smt.c
index f1915c0074..e60c2aebc8 100644
--- a/drivers/firmware/scmi/smt.c
+++ b/drivers/firmware/scmi/smt.c
@@ -30,8 +30,6 @@ int scmi_dt_get_smt_buffer(struct udevice *dev, struct 
scmi_smt *smt)
int ret;
struct ofnode_phandle_args args;
struct resource resource;
-   fdt32_t faddr;
-   phys_addr_t paddr;
 
ret = dev_read_phandle_with_args(dev, "shmem", NULL, 0, 0, );
if (ret)
@@ -41,21 +39,13 @@ int scmi_dt_get_smt_buffer(struct udevice *dev, struct 
scmi_smt *smt)
if (ret)
return ret;
 
-   /* TEMP workaround for ofnode_read_resource translation issue */
-   if (of_live_active()) {
-   paddr = resource.start;
-   } else {
-   faddr = cpu_to_fdt32(resource.start);
-   paddr = ofnode_translate_address(args.node, );
-   }
-
smt->size = resource_size();
if (smt->size < sizeof(struct scmi_smt_header)) {
dev_err(dev, "Shared memory buffer too small\n");
return -EINVAL;
}
 
-   smt->buf = devm_ioremap(dev, paddr, smt->size);
+   smt->buf = devm_ioremap(dev, resource.start, smt->size);
if (!smt->buf)
return -ENOMEM;
 
diff --git a/drivers/net/mscc_eswitch/jr2_switch.c 
b/drivers/net/mscc_eswitch/jr2_switch.c
index 570d5a5109..d1e5b61ea5 100644
--- a/drivers/net/mscc_eswitch/jr2_switch.c
+++ b/drivers/net/mscc_eswitch/jr2_switch.c
@@ -863,7 +863,6 @@ static int jr2_probe(struct udevice *dev)
int i;
int ret;
struct resource res;
-   fdt32_t faddr;
phys_addr_t addr_base;
unsigned long addr_size;
ofnode eth_node, node, mdio_node;
@@ -926,9 +925,8 @@ static int jr2_probe(struct udevice *dev)
 
if (ofnode_read_resource(mdio_node, 0, ))
return -ENOMEM;
-   faddr = cpu_to_fdt32(res.start);
 
-   addr_base = ofnode_translate_address(mdio_node, );
+   addr_base = res.start;
addr_size = res.end - res.start;
 
/* If the bus is new then create a new bus */
diff --git a/drivers/net/mscc_eswitch/luton_switch.c 
b/drivers/net/mscc_eswitch/luton_switch.c
index 54afa14c9d..73c950d118 100644
--- a/drivers/net/mscc_eswitch/luton_switch.c
+++ b/drivers/net/mscc_eswitch/luton_switch.c
@@ -588,7 +588,6 @@ static int luton_probe(struct udevice *dev)
struct luton_private *priv = dev_get_priv(dev);
int i, ret;
struct resource res;
-   fdt32_t faddr;
phys_addr_t addr_base;
unsigned long addr_size;
ofnode eth_node, node, mdio_node;
@@ -658,9 +657,7 @@ static int luton_probe(struct udevice *dev)
 
if 

Re: [PATCH v2 03/17] drivers: reset: Handle gracefully NULL pointers

[Kishon Vijay Abraham I]

Hi Simon,

On 15/04/21 1:08 am, Simon Glass wrote:
> Hi Kishon,
> 
> On Mon, 5 Apr 2021 at 11:28, Kishon Vijay Abraham I  wrote:
>>
>> From: Jean-Jacques Hiblot 
>>
>> The reset framework provides devm_reset_control_get_optional()
>> which can return NULL (not an error case). So all the other reset_ops
>> should handle NULL gracefully. Prepare the way for a managed reset
>> API by handling NULL pointers without crashing nor failing.
>>
>> Signed-off-by: Jean-Jacques Hiblot 
>> Signed-off-by: Vignesh Raghavendra 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/reset/reset-uclass.c | 30 +-
>>  1 file changed, 17 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
>> index 071c389ca0..98304bc0ee 100644
>> --- a/drivers/reset/reset-uclass.c
>> +++ b/drivers/reset/reset-uclass.c
>> @@ -13,9 +13,12 @@
>>  #include 
>>  #include 
>>
>> -static inline struct reset_ops *reset_dev_ops(struct udevice *dev)
>> +struct reset_ops nop_reset_ops = {
>> +};
>> +
>> +static inline struct reset_ops *reset_dev_ops(struct reset_ctl *r)
>>  {
>> -   return (struct reset_ops *)dev->driver->ops;
>> +   return r ? (struct reset_ops *)r->dev->driver->ops : _reset_ops;
> 
> This behaviour still seems odd to me. Why do you have a reset driver
> with no ops? That is not allowed.

Okay. I'll re-work this patch and post a fresh series.

Thanks
Kishon

> 
>>  }
>>
>>  static int reset_of_xlate_default(struct reset_ctl *reset_ctl,
>> @@ -54,9 +57,10 @@ static int reset_get_by_index_tail(int ret, ofnode node,
>> debug("%s %d\n", ofnode_get_name(args->node), args->args[0]);
>> return ret;
>> }
>> -   ops = reset_dev_ops(dev_reset);
>>
>> reset_ctl->dev = dev_reset;
>> +   ops = reset_dev_ops(reset_ctl);
>> +
>> if (ops->of_xlate)
>> ret = ops->of_xlate(reset_ctl, args);
>> else
>> @@ -162,29 +166,29 @@ int reset_get_by_name(struct udevice *dev, const char 
>> *name,
>>
>>  int reset_request(struct reset_ctl *reset_ctl)
>>  {
>> -   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +   struct reset_ops *ops = reset_dev_ops(reset_ctl);
>>
>> debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
>>
>> -   return ops->request(reset_ctl);
>> +   return ops->request ? ops->request(reset_ctl) : 0;
> 
> Can you check this first and return -ENOSYS ? E.g.
> 
> if (!ops->request)
>return -ENOSYS;
> 
> return ops->request(reset_ctl);
> 
> Same below
> 
>>  }
>>
>>  int reset_free(struct reset_ctl *reset_ctl)
>>  {
>> -   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +   struct reset_ops *ops = reset_dev_ops(reset_ctl);
>>
>> debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
>>
>> -   return ops->rfree(reset_ctl);
>> +   return ops->rfree ? ops->rfree(reset_ctl) : 0;
>>  }
>>
>>  int reset_assert(struct reset_ctl *reset_ctl)
>>  {
>> -   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +   struct reset_ops *ops = reset_dev_ops(reset_ctl);
>>
>> debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
>>
>> -   return ops->rst_assert(reset_ctl);
>> +   return ops->rst_assert ? ops->rst_assert(reset_ctl) : 0;
>>  }
>>
>>  int reset_assert_bulk(struct reset_ctl_bulk *bulk)
>> @@ -202,11 +206,11 @@ int reset_assert_bulk(struct reset_ctl_bulk *bulk)
>>
>>  int reset_deassert(struct reset_ctl *reset_ctl)
>>  {
>> -   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +   struct reset_ops *ops = reset_dev_ops(reset_ctl);
>>
>> debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
>>
>> -   return ops->rst_deassert(reset_ctl);
>> +   return ops->rst_deassert ? ops->rst_deassert(reset_ctl) : 0;
>>  }
>>
>>  int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
>> @@ -224,11 +228,11 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
>>
>>  int reset_status(struct reset_ctl *reset_ctl)
>>  {
>> -   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +   struct reset_ops *ops = reset_dev_ops(reset_ctl);
>>
>> debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
>>
>> -   return ops->rst_status(reset_ctl);
>> +   return ops->rst_status ? ops->rst_status(reset_ctl) : 0;
>>  }
>>
>>  int reset_release_all(struct reset_ctl *reset_ctl, int count)
>> --
>> 2.17.1
>>
> 
> Regards,
> Simon
> 

Re: Weirdness of ofnode_get_addr_size()

[Jan Kiszka]

On 02.05.21 09:53, Jan Kiszka wrote:
> Hi,
> 
> I'm trying to make some sense of ofnode_get_addr_size() in order to fix
> [1] properly.
> 
> First, the documentation if this functions says "This does no address
> translation". But the node-pointer path happily calls
> of_translate_address(), as the result of a6a45cd32539. For not
> offset-bases path, it calls fdtdec_get_addr_size() which does no
> translation.
> 
> Related to [1]: The node-pointer path cleanly calls
> of_n_addr/size_cells() in order to retrieve the configured number of
> cells. But the offset-based path simply calls fdtdec_get_addr_size()
> which assumes that the number of cells is derived from the physical
> address width of that platform.
> 
> So, what is that functions actually supposed to do?
> 
> Jan
> 
> [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg405446.html
> 

Ping - any comments welcome so that the bug(s) can be fixed,
specifically [1].

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] fs/squashfs: Fix some hardlinks reading the wrong inode

[Miquel Raynal]

Hello,

Campbell Suter  wrote on Fri, 30 Apr 2021
16:45:46 +1200:

> In SquashFS, the contents of a directory is stored by
> squashfs_directory_entry structures which contain the file's name, inode
> and position within the filesystem.
> 
> The inode number is not stored directly; instead each directory has one
> or more headers which set a base inode number, and files store the
> offset from that to the file's inode number.
> 
> In mksquashfs, each inode is allocated a number in the same order as
> they are written to the directory table; thus the offset from the
> header's base inode number to the file's inode number is usually
> positive.
> 
> Hardlinks are simply stored with two directory entries referencing the
> same file. This means the second entry will thus have an inode number
> much lower than the surrounding files. Since the header's base inode
> number comes from the first entry that uses the header, this delta will
> usually be negative.

I am not sure hardlinks have been tested extensively (even tested at
all, actually?) so the logic here looks good to me.

> Previously, U-Boot's squashfs_directory_entry.inode_offset field was
> declared as an unsigned value. Thus when a negative value was found, it
> would either resolve to an invalid inode number or to that of an
> unrelated file.

That's also what the documentation used to write this code actually
states: https://dr-emann.github.io/squashfs/ # "Directory Entry" section:

NameTypeDescription
offset  u16 An offset into the uncompressed inode metadata block
inode offseti16 The difference of this inode's number to the reference 
stored in the header
typeu16 The inode type [...]
name_size   u16 One less than the size of the entry name
nameu8[name_size + 1]   The file name of the entry without a 
trailing null byte

And I believe i16 means int16_t which is a signed value indeed.

> A squashfs image to test this can be created like so:
> 
> echo hi > sqfs_test_files/001-root-file
> mkdir sqfs_test_files/002-subdir
> touch sqfs_test_files/002-subdir/003-file
> lnsqfs_test_files/{001-root-file,002-subdir/004-link}
> mksquashfs sqfs_test_files/ test.sqfs -noappend
> 
> Note that squashfs sorts the files ASCIIbetacally, so we can use the
> names to control the order they appear in. The ordering is important -
> the first reference to the file must have a lower inode number than the
> directory in which the second reference resides, and the second
> reference cannot be the first file in the directory.
> 
> Listing this sample image in U-Boot results in:
> 
> => sqfsls virtio 2 002-subdir  
>  0   003-file
> Inode not found.
>  0   004-link
> 
> Signed-off-by: Campbell Suter 
> ---
> 
>   fs/squashfs/sqfs_filesystem.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/squashfs/sqfs_filesystem.h b/fs/squashfs/sqfs_filesystem.h
> index 856cd15e349..5440b6c0e05 100644
> --- a/fs/squashfs/sqfs_filesystem.h
> +++ b/fs/squashfs/sqfs_filesystem.h
> @@ -231,7 +231,7 @@ union squashfs_inode {
> 
>   struct squashfs_directory_entry {
>   u16 offset;
> - u16 inode_offset;
> + s16 inode_offset;
>   u16 type;
>   u16 name_size;
>   char name[0];

Reviewed-by: Miquel Raynal 

Thanks,
Miquèl

Re: [PATCH 16/49] kconfig: Add host support to CONFIG_IS_ENABLED()

[Rasmus Villemoes]

On 04/05/2021 01.11, Simon Glass wrote:
> At present we must separately test for the host build for many options,
> since we force them to be enabled. For example, CONFIG_FIT is always
> enabled in the host tools, even if CONFIG_FIT is not enabled by the
> board itself.
> 
> It would be more convenient if we could use, for example,
> CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
> host. Add support for this.
> 

Suggested-by: Rasmus Villemoes  # b4f73886
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  include/linux/kconfig.h | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
> index d109ed3119e..6216b58625f 100644
> --- a/include/linux/kconfig.h
> +++ b/include/linux/kconfig.h
> @@ -31,11 +31,14 @@
>   (config_enabled(option))
>  
>  /*
> - * U-Boot add-on: Helper macros to reference to different macros
> - * (CONFIG_ or CONFIG_SPL_ prefixed), depending on the build context.
> + * U-Boot add-on: Helper macros to reference to different macros (prefixed by
> + * CONFIG_, CONFIG_SPL_, CONFIG_TPL or CONFIG_HOST), depending on the build
> + * context.

Please consistently have a trailing underscore on these prefixes.

>   */
>  
> -#if defined(CONFIG_TPL_BUILD)
> +#ifdef USE_HOSTCC
> +#define _CONFIG_PREFIX HOST_
> +#elif defined(CONFIG_TPL_BUILD)
>  #define _CONFIG_PREFIX TPL_
>  #elif defined(CONFIG_SPL_BUILD)
>  #define _CONFIG_PREFIX SPL_
> @@ -49,6 +52,7 @@
>  
>  /*
>   * CONFIG_VAL(FOO) evaluates to the value of
> + *  CONFIG_HOST_FOO if USE_HOSTCC is undefined,

s/undefined/defined/

Rasmus

Re: [PATCH 12/49] image: Create a function to do manual relocation

[Rasmus Villemoes]

On 04/05/2021 01.10, Simon Glass wrote:
> Rather than adding an #ifdef and open-coding this calculation, add a
> helper function to handle it. Use this in the image code.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  common/image.c | 33 +++--
>  include/relocate.h | 24 +++-
>  2 files changed, 30 insertions(+), 27 deletions(-)
> 
> diff --git a/common/image.c b/common/image.c
> index 0ef8f30fcfa..086ae609f29 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -63,6 +63,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -563,11 +564,7 @@ const char *genimg_get_cat_name(enum ih_category 
> category, uint id)
>   entry = get_table_entry(table_info[category].table, id);
>   if (!entry)
>   return unknown_msg(category);
> -#if defined(USE_HOSTCC) || !defined(CONFIG_NEEDS_MANUAL_RELOC)
> - return entry->lname;
> -#else
> - return entry->lname + gd->reloc_off;
> -#endif
> + return manual_reloc(entry->lname);
>  }
>  
>  /**
> @@ -587,11 +584,7 @@ const char *genimg_get_cat_short_name(enum ih_category 
> category, uint id)
>   entry = get_table_entry(table_info[category].table, id);
>   if (!entry)
>   return unknown_msg(category);
> -#if defined(USE_HOSTCC) || !defined(CONFIG_NEEDS_MANUAL_RELOC)
> - return entry->sname;
> -#else
> - return entry->sname + gd->reloc_off;
> -#endif
> + return manual_reloc(entry->sname);
>  }
>  
>  int genimg_get_cat_count(enum ih_category category)
> @@ -641,11 +634,7 @@ char *get_table_entry_name(const table_entry_t *table, 
> char *msg, int id)
>   table = get_table_entry(table, id);
>   if (!table)
>   return msg;
> -#if defined(USE_HOSTCC) || !defined(CONFIG_NEEDS_MANUAL_RELOC)
> - return table->lname;
> -#else
> - return table->lname + gd->reloc_off;
> -#endif
> + return manual_reloc(table->lname);
>  }
>  
>  const char *genimg_get_os_name(uint8_t os)
> @@ -675,11 +664,7 @@ static const char *genimg_get_short_name(const 
> table_entry_t *table, int val)
>   table = get_table_entry(table, val);
>   if (!table)
>   return "unknown";
> -#if defined(USE_HOSTCC) || !defined(CONFIG_NEEDS_MANUAL_RELOC)
> - return table->sname;
> -#else
> - return table->sname + gd->reloc_off;
> -#endif
> + return manual_reloc(table->sname);
>  }
>  
>  const char *genimg_get_type_short_name(uint8_t type)
> @@ -722,12 +707,8 @@ int get_table_entry_id(const table_entry_t *table,
>   const table_entry_t *t;
>  
>   for (t = table; t->id >= 0; ++t) {
> -#if !defined(USE_HOSTCC) && defined(CONFIG_NEEDS_MANUAL_RELOC)
> - if (t->sname && strcasecmp(t->sname + gd->reloc_off, name) == 0)
> -#else
> - if (t->sname && strcasecmp(t->sname, name) == 0)
> -#endif
> - return (t->id);
> + if (t->sname && !strcasecmp(manual_reloc(t->sname), name))
> + return t->id;
>   }
>   debug("Invalid %s Type: %s\n", table_name, name);
>  
> diff --git a/include/relocate.h b/include/relocate.h
> index 9ceeecdbe71..c4fad336128 100644
> --- a/include/relocate.h
> +++ b/include/relocate.h
> @@ -7,7 +7,11 @@
>  #ifndef _RELOCATE_H_
>  #define _RELOCATE_H_
>  
> -#include 
> +#ifndef USE_HOSTCC
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +#endif
>  
>  /**
>   * copy_uboot_to_ram() - Copy U-Boot to its new relocated position
> @@ -35,4 +39,22 @@ int clear_bss(void);
>   */
>  int do_elf_reloc_fixups(void);
>  
> +/**
> + * manual_reloc() - Manually relocate a pointer if needed
> + *
> + * This is a nop in almost all cases, except for the systems with a broken 
> gcc
> + * which need to manually relocate some things.
> + *
> + * @ptr: Pointer to relocate
> + * @return new pointer value
> + */
> +static inline void *manual_reloc(void *ptr)
> +{
> +#ifndef USE_HOSTCC
> + if (IS_ENABLED(CONFIG_NEEDS_MANUAL_RELOC))
> + return ptr + gd->reloc_off;
> +#endif
> + return ptr;
> +}

static inlines are preferred in most cases, but you could make this
const-correct if it was a macro. Dunno, maybe there are no
const-qualified pointers where this might be used.

The function also has the advantage of ensuring that the arithmetic is
done on a void* pointer (i.e. effectively sizeof==1), though if the
pointer is actually already a u32*, say, the current manual relocation
code wouldn't be doing a bare ptr+gd->reloc_off anyway.

Rasmus

Re: [PATCH 02/49] compiler: Add a comment to host_build()

[Rasmus Villemoes]

On 04/05/2021 01.10, Simon Glass wrote:
> This function should have a comment explaining what it does. Add one.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  include/compiler.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/compiler.h b/include/compiler.h
> index 27b9843497a..ec0d600e71a 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -151,6 +151,11 @@ typedef unsigned long int uintptr_t;
>  #define MEM_SUPPORT_64BIT_DATA   0
>  #endif
>  
> +/**
> + * host_build() - check if we are building for the host
> + *
> + * @return true if building for the hose, false if for a target

spello, hose->host

Re: [PATCH 01/49] Add support for an owned buffer

[Rasmus Villemoes]

On 04/05/2021 01.10, Simon Glass wrote:
> When passing a data buffer back from a function, it is not always clear
> who owns the buffer, i.e. who is responsible for freeing the memory used.
> An example of this is where multiple files are decompressed from the
> firmware image, using a temporary buffer for reading (since the
> compressed data has to live somewhere) and producing a temporary or
> permanent buffer with the resuilts.
> 
> Where the firmware image can be memory-mapped, as on x86, the compressed
> data does not need to be buffered, but the complexity of having a buffer
> which is either allocated or not, makes the code hard to understand.
> 
> Introduce a new 'abuf' which supports simple buffer operations:
> 
> - encapsulating a buffer and its size
> - either allocated with malloc() or not
> - able to be reliably freed if necessary
> - able to be converted to an allocated buffer if needed
> 
> This simple API makes it easier to deal with allocated and memory-mapped
> buffers.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2:
> - Add new abuf_init_set() function
> 
>  include/abuf.h| 148 ++
>  lib/Makefile  |   1 +
>  lib/abuf.c| 103 
>  test/lib/Makefile |   1 +
>  test/lib/abuf.c   | 303 ++
>  5 files changed, 556 insertions(+)
>  create mode 100644 include/abuf.h
>  create mode 100644 lib/abuf.c
>  create mode 100644 test/lib/abuf.c
> 
> diff --git a/include/abuf.h b/include/abuf.h
> new file mode 100644
> index 000..3b8f78348dd
> --- /dev/null
> +++ b/include/abuf.h
> @@ -0,0 +1,148 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Handles a buffer that can be allocated and freed
> + *
> + * Copyright 2021 Google LLC
> + * Written by Simon Glass 
> + */
> +
> +#ifndef __ABUF_H
> +#define __ABUF_H
> +
> +#include 
> +
> +/**
> + * struct abuf - buffer that can be allocated and freed
> + *
> + * This is useful for a block of data which may be allocated with malloc(), 
> or
> + * not, so that it needs to be freed correctly when finished with.
> + *
> + * For now it has a very simple purpose.
> + *
> + * Using memset() to zero all fields is guaranteed to be equivalent to
> + * abuf_init().
> + *
> + * @data: Pointer to data
> + * @size: Size of data in bytes
> + * @alloced: true if allocated with malloc(), so must be freed after use
> + */
> +struct abuf {
> + void *data;
> + size_t size;
> + bool alloced;
> +};
> +
> +static inline void *abuf_data(struct abuf *abuf)

const struct abuf *abuf?

> +{
> + return abuf->data;
> +}
> +
> +static inline size_t abuf_size(struct abuf *abuf)

ditto

> +{
> + return abuf->size;
> +}
> +
> +
> +bool abuf_realloc(struct abuf *abuf, size_t new_size)
> +{
> + void *ptr;
> +
> + if (!new_size) {
> + /* easy case, just need to uninit, freeing any allocation */
> + abuf_uninit(abuf);
> + } else if (abuf->alloced) {
> + /* currently allocated, so need to reallocate */
> + ptr = realloc(abuf->data, new_size);
> + if (!ptr)
> + return false;
> + abuf->data = ptr;
> + abuf->size = new_size;
> + } else if (new_size <= abuf->size) {
> + /*
> +  * not currently alloced and new size is no larger. Just update
> +  * it. Data is lost off the end if new_size < abuf->size
> +  */
> + abuf->size = new_size;
> + } else {
> + /* not currently allocated and new size is larger. Alloc and
> +  * copy in data. The new space is not inited.
> +  */
> + ptr = malloc(new_size);
> + if (!ptr)
> + return false;
> + memcpy(ptr, abuf->data, min(new_size, abuf->size));

You know new_size > abuf->size, no need for the min().

> + abuf->data = ptr;
> + abuf->size = new_size;
> + abuf->alloced = true;
> + }
> +
> + return true;
> +}

I think this would be easier to read if the branches did an early
"return true;" when the case has been handled.

> +
> +void *abuf_uninit_move(struct abuf *abuf, size_t *sizep)
> +{
> + void *ptr;
> +
> + if (sizep)
> + *sizep = abuf->size;
> + if (!abuf->size)
> + return NULL;
> + if (abuf->alloced) {
> + ptr = abuf->data;
> + } else {
> + ptr = malloc(abuf->size);
> + if (!ptr)
> + return NULL;
> + memcpy(ptr, abuf->data, abuf->size);

Don't we have a memdup() function? Hm, no, only a kmemdup(). Might be
worth introducing at some point, quick grepping shows quite a few places
that could use that.

> + }
> + /* Clear everything out so there is no record of the data */
> + abuf_init(abuf);
> +
> + return ptr;
> +}
> +
> +void abuf_init_set(struct abuf *abuf, void *data, size_t size)
>