Re: [PATCH] arm: mvebu: turris_omnia: Remove hardcoded spi-nor device tree path

[Stefan Roese]

On 01.08.22 23:58, Pali Rohár wrote:

Linux kernel DTS files renamed spi-nor@0 node to flash@0 which effectively
broke U-Boot to boot new Linux kernel versions correctly.

So remove hardcoded spi-nor device tree path from Turris Omnia board code
and replace it by searching for mtd node by compatible string.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 108d160f486d..9d7e63865f14 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -32,8 +32,6 @@
  
  DECLARE_GLOBAL_DATA_PTR;
  
-#define OMNIA_SPI_NOR_PATH		"/soc/spi@10600/spi-nor@0"

-
  #define OMNIA_I2C_BUS_NAME"i2c@11000->i2cmux@70->i2c@0"
  
  #define OMNIA_I2C_MCU_CHIP_ADDR		0x2a

@@ -1030,14 +1028,22 @@ static bool fixup_mtd_partitions(void *blob, int 
offset, struct mtd_info *mtd)
  
  static void fixup_spi_nor_partitions(void *blob)

  {
-   struct mtd_info *mtd;
+   struct mtd_info *mtd = NULL;
+   char mtd_path[64];
int node;
  
-	mtd = get_mtd_device_nm(OMNIA_SPI_NOR_PATH);

+   node = fdt_node_offset_by_compatible(gd->fdt_blob, -1, "jedec,spi-nor");
+   if (node < 0)
+   goto fail;
+
+   if (fdt_get_path(gd->fdt_blob, node, mtd_path, sizeof(mtd_path)) < 0)
+   goto fail;
+
+   mtd = get_mtd_device_nm(mtd_path);
if (IS_ERR_OR_NULL(mtd))
goto fail;
  
-	node = fdt_path_offset(blob, OMNIA_SPI_NOR_PATH);

+   node = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
if (node < 0)
goto fail;
  


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH] timer: bcmbca: Add Broadcom BCMBCA timer support

[Rafał Miłecki]

On 2.08.2022 00:03, William Zhang wrote:

This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
  
Signed-off-by: William Zhang 


(...)

+static const struct udevice_id bcmbca_timer_ids[] = {
+   { .compatible = "brcm,bcm-timers" },
+   { }
+};
+
+U_BOOT_DRIVER(bcmbca_timer) = {
+   .name = "bcmbca_timer",
+   .id = UCLASS_TIMER,
+   .of_match = bcmbca_timer_ids,
+   .priv_auto = sizeof(struct bcmbca_timer_priv),
+   .probe = bcmbca_timer_probe,
+   .ops = &bcmbca_timer_ops,
+   .flags = DM_FLAG_PRE_RELOC,
+};


That "brcm,bcm-timers" seems like a really wide bidding. Is that exact
timer block guaranteed to be present on all Broadcom devices? Does it
exist e.g. on Northstar SoCs? Or old MIPS SoCs like BCM4706?

It seems that even across BCMBCA devices this block may differ and may
need different bindings. Most SoCs have 4 CTL and 4 CNT registers but
some have only 3 + 3 (BCM6838 BCM60333 BCM63268).

Finally could we have that binding actually documented?

Re: [PATCH 0/6] introduce Arm FF-A support

[Simon Glass]

Hi Sudeep,

On Mon, 1 Aug 2022 at 13:28, Sudeep Holla  wrote:
>
> On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote:
> > On Wed, 13 Apr 2022 at 10:46, Tom Rini  wrote:
> > >
> > > How is it both discoverable and doesn't have a device tree node, in the
> > > kernel?
> >
> > Also, if it is discoverable, we can still use U-Boot to discover it
> > and then pass the info to Linux in the DT.
> >
>
> Why ? Linux can discover the presence of the feature with a simple SMCCC
> based query. We don't need any DT bindings for this particular feature.
> Not sure if you are talking in general or in the context of $subject
> feature in the kernel.

Oh well my understanding of Open Firmware was that the firmware did
the probing and passed the info to the OS.

>
> > I am seeing several series which don't have 'proper' DT bindings in
> > Linux. First I heard it was for legacy reasons, but now I am hearing
> > something different. For U-Boot, we really do need to have DT bindings
> > for devices. All this ad-hoc creation of stuff makes things hard to
> > discover, adds to code size and makes things like of-platdata
> > impossible.
> >
>
> I may not have the complete picture here. If you are saying that every
> feature in the u-boot needs DT for some reason, then that's U-boot's
> limitation or restriction. But just the presence of node means nothing

Yes it is something I am becoming more and more concerned about.

> until the corresponding feature is queried and confirmed to be present
> in the firmware. That is very important as we can't skip the query stage
> just because of presence of some DT node for this.
>
> > Furthermore, if the bindings affect U-Boot, then the U-Boot project
> > should have a say in what is being done there, not just be downstream
> > of all such changes.
> >
>
> I still think you talking about some issue in general and it doesn't
> apply in this case. The new firmware interfaces are designed to be
> discoverable which is the main advantage over any non discoverable
> hardware and/or firmware interface. One main advantage I see is that we
> don't need any DT bindings which makes the firmware upgrades must simpler
> as the users can query the interface and know exactly what they need
> instead of relying on DT node which may get stale if not updated with the
> firmware update. I am not sure if whatever I am writing here is relevant
> to what your concerns are as I think I haven't understood them fully.

I'm not sure either. In particular I'm not sure why it would be easier
to update whatever the FF-A software is than to update the DT, since
presumably they are both in the firmware.

I am talking about an issue in general and the same issue in
particular with this series.

Can I suggest resending this series with a change log for each patch.
Also please try to avoid #ifdefs and make sure to include
documentation in doc/ including how this relates to the UEFI
firmware-update effort that ARM/Linaro is undertaking. Also, what
happened to the tests / sandbox driver?

Regards,
Simon

Re: [PATCH v1 1/2] ARM: configs: npcm7xx: add full function for nuvoton npcm750

[Jim Liu]

Hi Tom

Thanks for your review.
My i2c driver status is  Awaiting Upstream.
Is this the reason for the failure?
What should I do to fix this build error?

Any comments are most welcome!


Best regards,
Jim

On Tue, Jul 26, 2022 at 12:59 AM Tom Rini  wrote:
>
> On Tue, Jul 12, 2022 at 05:24:06PM +0800, Jim Liu wrote:
>
> > Add add full function config for nuvoton npcm750
> >
> > Signed-off-by: Jim Liu 
>
> Does the i2c driver need to be reposted?  This patch causes the platform
> to fail to build as the i2c driver file is missing.
>
> --
> Tom

[PATCH] arm: disable FDPIC ABI

[Ben Wolsieffer]

When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is
enabled by default but should not be used to build U-Boot. Therefore,
pass -mno-fdpic if supported by the compiler.

Signed-off-by: Ben Wolsieffer 
---
 arch/arm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 85c23bcf77..cdc32ea790 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -32,6 +32,9 @@ else
 arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
 endif
 
+# Disable FDPIC ABI
+arch-y += $(call cc-option, -mno-fdpic)
+
 # Evaluate arch cc-option calls now
 arch-y := $(arch-y)
 
-- 
2.37.0

Re: [PATCH v2 5/5] test: add test for full FAT16 directory

[AKASHI Takahiro]

On Mon, Aug 01, 2022 at 08:14:15AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 8/1/22 03:50, AKASHI Takahiro wrote:
> > On Sun, Jul 31, 2022 at 01:58:37PM +0200, Heinrich Schuchardt wrote:
> > > Add a unit test checking that a full FAT16 directory leads to an error
> > > when trying to add an additional entry.
> > 
> > Thank you for adding this test case, but
> > why do you restrict this test to fat16 and the root directory?
> > The root directory on fat16 is a very much special case and differently
> > implemented from others. So the test scenario doesn't do what we expect
> > for fulfilling the whole disk.
> > 
> > I think we should use other sub directories (and other file systems as 
> > well).
> 
> No other filesystem but FAT supports mkdir in U-Boot currently.

Right, but it won't prevent us from creating a generic test scenario.
My pytest already has a mechanism to run a test for a specific set of
file systems. See supported_fs_xxx.

> Creating the maximum 512 directory entries for the root directory of FAT16
> can be done in a reasonable time.

As I said, the root directory on fat16 is very special and has a fixed size
of blocks and using it in your test will *never* make the file system full.

> Otherwise "The maximum valid directory size is 2**21 bytes." Creating 65536
> entries takes far too long to be done in a regular test. Even a bash script
> in Linux needs more than half an hour for this on my laptop.

Providing a test and running it is different things.
If necessary, we should exercise it.

> The 2 MiB limit is not implemented in U-Boot. So the test would fail after a
> few days or weeks.

If so, why not fix the problem?

-Takahiro Akashi

> 
> > 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > > v2:
> > >   new patch
> > > ---
> > >   test/py/tests/test_fs/test_mkdir.py | 17 +
> > >   1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/test/py/tests/test_fs/test_mkdir.py 
> > > b/test/py/tests/test_fs/test_mkdir.py
> > > index f5cc308362..e3a9e3ed27 100644
> > > --- a/test/py/tests/test_fs/test_mkdir.py
> > > +++ b/test/py/tests/test_fs/test_mkdir.py
> > > @@ -119,3 +119,20 @@ class TestMkdir(object):
> > >   assert('0123456789abcdef00/'  in output)
> > >   assert('0123456789abcdef13/'  in output)
> > >   assert_fs_integrity(fs_ubtype, fs_img)
> > > +
> > > +def test_mkdir7(self, u_boot_console, fs_obj_mkdir):
> > > +""" Test Case 7 - max out number of root directory entries
> > > +"""
> > > +_, _, fs_type = fs_obj_mkdir
> > 
> > Why not use fs_ubtype, _, fs_type = ..., then
> > 
> > > +if fs_type != 'fat16':
> > > +return
> > > +with u_boot_console.log.section('Test Case 7 - mkdir (max out)'):
> > > +for i in range(0, 512):
> > > +output = u_boot_console.run_command(
> > > +f'fatmkdir host 0:0 
> > > /U-Boot-mkdir-max-out-test-directory-{i:05d}')
> > 
> > '%smkdir ...'.format(fs_ubtype, i)
> 
> We know it is FAT.
> 
> Best regards
> 
> Heinrich
> > 
> > -Takahiro Akashi
> > 
> > > +if 'Can\'t create directory entry' in output:
> > > +break
> > > +# A directory was created
> > > +assert i > 0
> > > +# The FAT16 root directory has only 512 directory entries
> > > +assert i <= 512 / 5
> > > -- 
> > > 2.36.1
> > > 

Re: [PATCH v2 1/5] fs: fat: finding an empty FAT cluster

[AKASHI Takahiro]

On Mon, Aug 01, 2022 at 10:21:20AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 8/1/22 03:02, AKASHI Takahiro wrote:
> > On Sun, Jul 31, 2022 at 01:58:33PM +0200, Heinrich Schuchardt wrote:
> > > Currently we have two functions with redundant coding to find an empty
> > > cluster:
> > > 
> > > * find_empty_cluster() seeks from the beginning of the FAT table
> > > * determine_fatent() seeks after a given entry
> > > 
> > > Both do not detect the end of the FAT table correctly and return an 
> > > invalid
> > > cluster number if no empty entry if found.
> > > 
> > > find_empty_cluster() is replaced by an invocation of determine_fatent().
> > > 
> > > determine_fatent() is changed to seek in a second round from the beginning
> > > of the FAT table and to return an error code if no free entry is found.
> > > With this patch we will always find an empty cluster if it exists.
> > > 
> > > Further patches are needed to handle the disk full error gracefully.
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > > v2:
> > >   no change
> > 
> > I made this comment before:
> > https://lists.denx.de/pipermail/u-boot/2022-July/488827.html
> > 
> > -Takahiro Akashi
> 
> The speedup only exists in the rare case that the disk is full.
> Therefore reducing the code size and complexity has priority.

I don't believe that my approach is complexed at all.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > 
> > > ---
> > >   fs/fat/fat_write.c | 56 --
> > >   1 file changed, 29 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> > > index 8ff2f6def0..a137e14f41 100644
> > > --- a/fs/fat/fat_write.c
> > > +++ b/fs/fat/fat_write.c
> > > @@ -536,22 +536,41 @@ static int set_fatent_value(fsdata *mydata, __u32 
> > > entry, __u32 entry_value)
> > >   return 0;
> > >   }
> > > -/*
> > > - * Determine the next free cluster after 'entry' in a FAT (12/16/32) 
> > > table
> > > - * and link it to 'entry'. EOC marker is not set on returned entry.
> > > +/**
> > > + * determine_fatent() - get next free FAT cluster
> > > + *
> > > + * The parameter @entry indicates the current cluster. To reduce 
> > > fragementation
> > > + * the function first searches for a free cluster after the current 
> > > cluster.
> > > + * If none is found, the search is repeated from the beginning of the 
> > > FAT table.
> > > + *
> > > + * If @entry is set, the new FAT entry is appended to the given one.
> > > + * If @entry is zero, only the number of the first free cluster is 
> > > returned.
> > > + *
> > > + * @entry:   current entry
> > > + * Return:   next free cluster or negative error
> > >*/
> > > -static __u32 determine_fatent(fsdata *mydata, __u32 entry)
> > > +static int determine_fatent(fsdata *mydata, __u32 entry)
> > >   {
> > > - __u32 next_fat, next_entry = entry + 1;
> > > + __u32 next_fat, next_entry = entry;
> > > + int second_round = 0;
> > >   while (1) {
> > > + ++next_entry;
> > > + if (CHECK_CLUST(next_entry, mydata->fatsize)) {
> > > + if (!second_round) {
> > > + second_round = 1;
> > > + next_entry = 3;
> > > + } else {
> > > + return -ENOSPC;
> > > + }
> > > + }
> > >   next_fat = get_fatent(mydata, next_entry);
> > > - if (next_fat == 0) {
> > > + if (!next_fat) {
> > >   /* found free entry, link to entry */
> > > - set_fatent_value(mydata, entry, next_entry);
> > > + if (entry)
> > > + set_fatent_value(mydata, entry, next_entry);
> > >   break;
> > >   }
> > > - next_entry++;
> > >   }
> > >   debug("FAT%d: entry: %08x, entry_value: %04x\n",
> > >  mydata->fatsize, entry, next_entry);
> > > @@ -794,23 +813,6 @@ get_set_cluster(fsdata *mydata, __u32 clustnum, 
> > > loff_t pos, __u8 *buffer,
> > >   return 0;
> > >   }
> > > -/*
> > > - * Find the first empty cluster
> > > - */
> > > -static int find_empty_cluster(fsdata *mydata)
> > > -{
> > > - __u32 fat_val, entry = 3;
> > > -
> > > - while (1) {
> > > - fat_val = get_fatent(mydata, entry);
> > > - if (fat_val == 0)
> > > - break;
> > > - entry++;
> > > - }
> > > -
> > > - return entry;
> > > -}
> > > -
> > >   /**
> > >* new_dir_table() - allocate a cluster for additional directory entries
> > >*
> > > @@ -824,7 +826,7 @@ static int new_dir_table(fat_itr *itr)
> > >   int dir_oldclust = itr->clust;
> > >   unsigned int bytesperclust = mydata->clust_size * 
> > > mydata->sect_size;
> > > - dir_newclust = find_empty_cluster(mydata);
> > > + dir_newclust = determine_fatent(mydata, 0);
> > >   /*
> > >* Flush before updating FAT 

Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

[Tom Rini]

On Mon, Aug 01, 2022 at 09:39:00PM +0200, Pali Rohár wrote:
> On Monday 01 August 2022 13:13:22 Simon Glass wrote:
> > Hi Pali,
> > 
> > On Mon, 1 Aug 2022 at 09:43, Pali Rohár  wrote:
> > >
> > > Currently Makefile produces final mpc85xx image when SPL is not used in
> > > custom file u-boot-with-dtb.bin. It is quite confusing name as build
> > > process produce also intermediate file standard file u-boot-dtb.bin (which
> > > is just intermediate and not bootable). Other platforms use u-boot.bin
> > > (UBOOT_BIN) as standard name for final bootable raw image.
> > >
> > > So change Makefile rules and binman to produce final bootable file for
> > > mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
> > > define default rule for u-boot.bin then instruct binman (via DTS file) to
> > > store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
> > > finally rename target u-boot-with-dtb.bin to u-boot.bin.
> > >
> > > With this change are also removed custom Makefile hacks for mpc85xx that 
> > > it
> > > produced non-standard output file. And also updated documentation.
> > >
> > > Signed-off-by: Pali Rohár 
> > > ---
> > >  Makefile | 19 +--
> > >  arch/powerpc/dts/kmcent2-u-boot.dtsi |  2 +-
> > >  arch/powerpc/dts/u-boot.dtsi |  2 +-
> > >  board/freescale/p1_p2_rdb_pc/README  |  2 +-
> > >  board/freescale/p2041rdb/README  |  3 ---
> > >  board/freescale/t102xrdb/README  |  2 +-
> > >  board/freescale/t104xrdb/README  |  2 +-
> > >  board/freescale/t208xqds/README  |  2 +-
> > >  board/freescale/t208xrdb/README  |  2 +-
> > >  9 files changed, 12 insertions(+), 24 deletions(-)
> > 
> > At present u-boot.bin has a very standard meaning - it is U-Boot with the 
> > DT.
> > 
> > Boards which need something more than that can/should use binman to
> > create a separate file.
> > 
> > I certainly agree that u-boot-with-dtb.bin is a terrible name, though.
> > Something more descriptive would be better.
> > 
> > But is it possible to drop these SoC-specific rules in the Makefile
> > and just build everything needed in the standard binman rule in the
> > Makefile?
> > 
> > Regards,
> > Simon
> 
> I do not know what is binman doing and how to use it. I just do not see
> reason why it is needed to use such additional tool for building final
> binary for powerpc/mpc85xx as other arm boards do not use it at all.
> 
> Ad your comment "At present u-boot.bin has a very standard meaning - it
> is U-Boot with the DT." - This is exactly what binman for mpc85xx
> produces.
> 
> So I see there could be improvements, but as a first step this my patch
> should be enough?

So, one of the issues with PowerPC stuff is that much of it is so far
behind the rest of U-Boot in terms of frameworks.  So yes, let us start
by fixing the functional problem you're describing here and then see
what appetite exists for further work here.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] arm: bcmbca: add bcm63138 SoC support

[William Zhang]

BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, peripheral timer and
Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

This patch applies on top of the my previous patch [1] and depends 
on the timer support from patch [2].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/490597.html
[2] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html

Signed-off-by: William Zhang 

---

 MAINTAINERS|   1 +
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/bcm63138.dtsi | 102 +
 arch/arm/dts/bcm963138.dts |  30 
 arch/arm/mach-bcmbca/Kconfig   |   9 +++
 arch/arm/mach-bcmbca/Makefile  |   1 +
 arch/arm/mach-bcmbca/bcm63138/Kconfig  |  17 +
 arch/arm/mach-bcmbca/bcm63138/Makefile |   5 ++
 board/broadcom/bcmbca/Kconfig  |   7 ++
 configs/bcm963138_defconfig|  22 ++
 include/configs/bcm963138.h|  11 +++
 11 files changed, 207 insertions(+)
 create mode 100644 arch/arm/dts/bcm63138.dtsi
 create mode 100644 arch/arm/dts/bcm963138.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm63138/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm63138/Makefile
 create mode 100644 configs/bcm963138_defconfig
 create mode 100644 include/configs/bcm963138.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c3a7d77f17d..2a27d15705cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -219,6 +219,7 @@ F:  board/broadcom/bcmbca/
 F: drivers/timer/bcmbca-timer.c
 N: bcmbca
 N: bcm[9]?47622
+N: bcm[9]?63138
 N: bcm[9]?63148
 N: bcm[9]?63178
 N: bcm[9]?6756
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b8d136bd129b..f4fa6f517744 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1165,6 +1165,8 @@ dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
 
 dtb-$(CONFIG_BCM47622) += \
bcm947622.dtb
+dtb-$(CONFIG_BCM63138) += \
+   bcm963138.dtb
 dtb-$(CONFIG_BCM63148) += \
bcm963148.dtb
 dtb-$(CONFIG_BCM63178) += \
diff --git a/arch/arm/dts/bcm63138.dtsi b/arch/arm/dts/bcm63138.dtsi
new file mode 100644
index ..0665f24e8308
--- /dev/null
+++ b/arch/arm/dts/bcm63138.dtsi
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Broadcom BCM63138 DSL SoCs Device Tree
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm63138", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <0>;
+   enable-method = "brcm,bcm63138";
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <1>;
+   enable-method = "brcm,bcm63138";
+   };
+   };
+
+   clocks {
+   /* UBUS peripheral clock */
+   periph_clk: periph_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   clock-output-names = "periph";
+   };
+   };
+
+   /* ARM bus */
+   axi@8000 {
+   compatible = "simple-bus";
+   ranges = <0 0x8000 0x784000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   L2: cache-controller@1d000 {
+   compatible = "arm,pl310-cache";
+   reg = <0x1d000 0x1000>;
+   cache-unified;
+   cache-level = <2>;
+   cache-size = <524288>;
+   cache-sets = <1024>;
+   cache-line-size = <32>;
+   interrupts = ;
+   };
+
+   scu: scu@1e000 {
+   compatible = "arm,cortex-a9-scu";
+   reg = <0x1e000 0x100>;
+   };
+
+   gic: interrupt-controller@1f000 {
+   compatible = "arm,cortex-a9-gic";
+   reg = <0x1f000 0x1000
+   0x1e100 0x100>;
+   #interrupt-cells 

[PATCH] timer: bcmbca: Add Broadcom BCMBCA timer support

[William Zhang]

This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.

Signed-off-by: William Zhang 

---

 MAINTAINERS  |  1 +
 drivers/timer/Kconfig|  8 
 drivers/timer/Makefile   |  1 +
 drivers/timer/bcmbca_timer.c | 93 
 4 files changed, 103 insertions(+)
 create mode 100644 drivers/timer/bcmbca_timer.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d1d13c733db4..8c3a7d77f17d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -216,6 +216,7 @@ M:  Joel Peshkin 
 S: Maintained
 F: arch/arm/mach-bcmbca/
 F: board/broadcom/bcmbca/
+F: drivers/timer/bcmbca-timer.c
 N: bcmbca
 N: bcm[9]?47622
 N: bcm[9]?63148
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 20b5af7e260f..2e5af97b3ad5 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -125,6 +125,14 @@ config SPL_ATMEL_TCB_TIMER
  Select this to enable the use of the timer counter as a monotonic
  counter in SPL.
 
+
+config BCMBCA_TIMER
+   bool "Broadcom BCMBCA SoC timer support"
+   depends on TIMER
+   help
+ Select this to enable peripheral timer support for Broadcom
+ BCMBCA SoC devices
+
 config CADENCE_TTC_TIMER
bool "Cadence TTC (Triple Timer Counter)"
depends on TIMER
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index d9822a537009..d581db7563c5 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_$(SPL_)ATMEL_PIT_TIMER) += atmel_pit_timer.o
 obj-$(CONFIG_$(SPL_)ATMEL_TCB_TIMER) += atmel_tcb_timer.o
+obj-$(CONFIG_BCMBCA_TIMER) += bcmbca_timer.o
 obj-$(CONFIG_CADENCE_TTC_TIMER)+= cadence-ttc.o
 obj-$(CONFIG_DESIGNWARE_APB_TIMER) += dw-apb-timer.o
 obj-$(CONFIG_GXP_TIMER)+= gxp-timer.o
diff --git a/drivers/timer/bcmbca_timer.c b/drivers/timer/bcmbca_timer.c
new file mode 100644
index ..78a8a67f22a7
--- /dev/null
+++ b/drivers/timer/bcmbca_timer.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Broadcom BCMBCA Broadband SoC timer driver
+ *  Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TIMER_CTL 0
+#define TIMER_CNT 0x10
+
+#define BCMBCA_TIMER_ENABLEBIT(31)
+#define BCMBCA_TIMER_CNT_MASK  0x3fff
+#define BCMBCA_TIMER_CNT_HIGH_SHIFT30
+
+struct bcmbca_timer_priv {
+   void __iomem *reg_base;
+   u32 cnt_high;
+   u32 cnt_low;
+};
+
+static u64 bcmbca_timer_get_count(struct udevice *dev)
+{
+   u64 cnt_high_64;
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+   u32 val = readl(priv->reg_base + TIMER_CNT) & BCMBCA_TIMER_CNT_MASK;
+
+   /* handle hardware counter overflow case*/
+   if (val < priv->cnt_low)
+   priv->cnt_high++;
+   priv->cnt_low = val;
+   cnt_high_64 = (u64)priv->cnt_high;
+
+   return (cnt_high_64 << BCMBCA_TIMER_CNT_HIGH_SHIFT | priv->cnt_low);
+}
+
+static void bcmbca_timer_start(struct udevice *dev)
+{
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+
+   writel(BCMBCA_TIMER_ENABLE | BCMBCA_TIMER_CNT_MASK,
+  priv->reg_base + TIMER_CTL);
+}
+
+static int bcmbca_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   int ret;
+
+   priv->reg_base = dev_remap_addr(dev);
+
+   if (!priv->reg_base)
+   return -ENOENT;
+
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret)
+   return ret;
+
+   uc_priv->clock_rate = clk_get_rate(&clk);
+   if (!uc_priv->clock_rate)
+   return -EINVAL;
+
+   bcmbca_timer_start(dev);
+
+   return 0;
+}
+
+static const struct timer_ops bcmbca_timer_ops = {
+   .get_count = bcmbca_timer_get_count,
+};
+
+static const struct udevice_id bcmbca_timer_ids[] = {
+   { .compatible = "brcm,bcm-timers" },
+   { }
+};
+
+U_BOOT_DRIVER(bcmbca_timer) = {
+   .name = "bcmbca_timer",
+   .id = UCLASS_TIMER,
+   .of_match = bcmbca_timer_ids,
+   .priv_auto = sizeof(struct bcmbca_timer_priv),
+   .probe = bcmbca_timer_probe,
+   .ops = &bcmbca_timer_ops,
+   .flags = DM_FLAG_PRE_RELOC,
+};
-- 
2.37.1



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] timer: bcmbca: Add Broadcom BCMBCA timer support

[William Zhang]

This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
 
Signed-off-by: William Zhang 

---

 MAINTAINERS  |  1 +
 drivers/timer/Kconfig|  8 
 drivers/timer/Makefile   |  1 +
 drivers/timer/bcmbca_timer.c | 93 
 4 files changed, 103 insertions(+)
 create mode 100644 drivers/timer/bcmbca_timer.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d1d13c733db4..8c3a7d77f17d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -216,6 +216,7 @@ M:  Joel Peshkin 
 S: Maintained
 F: arch/arm/mach-bcmbca/
 F: board/broadcom/bcmbca/
+F: drivers/timer/bcmbca-timer.c
 N: bcmbca
 N: bcm[9]?47622
 N: bcm[9]?63148
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 20b5af7e260f..2e5af97b3ad5 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -125,6 +125,14 @@ config SPL_ATMEL_TCB_TIMER
  Select this to enable the use of the timer counter as a monotonic
  counter in SPL.
 
+
+config BCMBCA_TIMER
+   bool "Broadcom BCMBCA SoC timer support"
+   depends on TIMER
+   help
+ Select this to enable peripheral timer support for Broadcom
+ BCMBCA SoC devices
+
 config CADENCE_TTC_TIMER
bool "Cadence TTC (Triple Timer Counter)"
depends on TIMER
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index d9822a537009..d581db7563c5 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AST_TIMER)   += ast_timer.o
 obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
 obj-$(CONFIG_$(SPL_)ATMEL_PIT_TIMER) += atmel_pit_timer.o
 obj-$(CONFIG_$(SPL_)ATMEL_TCB_TIMER) += atmel_tcb_timer.o
+obj-$(CONFIG_BCMBCA_TIMER) += bcmbca_timer.o
 obj-$(CONFIG_CADENCE_TTC_TIMER)+= cadence-ttc.o
 obj-$(CONFIG_DESIGNWARE_APB_TIMER) += dw-apb-timer.o
 obj-$(CONFIG_GXP_TIMER)+= gxp-timer.o
diff --git a/drivers/timer/bcmbca_timer.c b/drivers/timer/bcmbca_timer.c
new file mode 100644
index ..78a8a67f22a7
--- /dev/null
+++ b/drivers/timer/bcmbca_timer.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Broadcom BCMBCA Broadband SoC timer driver
+ *  Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TIMER_CTL 0
+#define TIMER_CNT 0x10
+
+#define BCMBCA_TIMER_ENABLEBIT(31)
+#define BCMBCA_TIMER_CNT_MASK  0x3fff
+#define BCMBCA_TIMER_CNT_HIGH_SHIFT30
+
+struct bcmbca_timer_priv {
+   void __iomem *reg_base;
+   u32 cnt_high;
+   u32 cnt_low;
+};
+
+static u64 bcmbca_timer_get_count(struct udevice *dev)
+{
+   u64 cnt_high_64;
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+   u32 val = readl(priv->reg_base + TIMER_CNT) & BCMBCA_TIMER_CNT_MASK;
+
+   /* handle hardware counter overflow case*/
+   if (val < priv->cnt_low)
+   priv->cnt_high++;
+   priv->cnt_low = val;
+   cnt_high_64 = (u64)priv->cnt_high;
+
+   return (cnt_high_64 << BCMBCA_TIMER_CNT_HIGH_SHIFT | priv->cnt_low);
+}
+
+static void bcmbca_timer_start(struct udevice *dev)
+{
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+
+   writel(BCMBCA_TIMER_ENABLE | BCMBCA_TIMER_CNT_MASK,
+  priv->reg_base + TIMER_CTL);
+}
+
+static int bcmbca_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct bcmbca_timer_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   int ret;
+
+   priv->reg_base = dev_remap_addr(dev);
+
+   if (!priv->reg_base)
+   return -ENOENT;
+
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret)
+   return ret;
+
+   uc_priv->clock_rate = clk_get_rate(&clk);
+   if (!uc_priv->clock_rate)
+   return -EINVAL;
+
+   bcmbca_timer_start(dev);
+
+   return 0;
+}
+
+static const struct timer_ops bcmbca_timer_ops = {
+   .get_count = bcmbca_timer_get_count,
+};
+
+static const struct udevice_id bcmbca_timer_ids[] = {
+   { .compatible = "brcm,bcm-timers" },
+   { }
+};
+
+U_BOOT_DRIVER(bcmbca_timer) = {
+   .name = "bcmbca_timer",
+   .id = UCLASS_TIMER,
+   .of_match = bcmbca_timer_ids,
+   .priv_auto = sizeof(struct bcmbca_timer_priv),
+   .probe = bcmbca_timer_probe,
+   .ops = &bcmbca_timer_ops,
+   .flags = DM_FLAG_PRE_RELOC,
+};
-- 
2.37.1



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] arm: mvebu: turris_omnia: Remove hardcoded spi-nor device tree path

[Pali Rohár]

Linux kernel DTS files renamed spi-nor@0 node to flash@0 which effectively
broke U-Boot to boot new Linux kernel versions correctly.

So remove hardcoded spi-nor device tree path from Turris Omnia board code
and replace it by searching for mtd node by compatible string.

Signed-off-by: Pali Rohár 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 108d160f486d..9d7e63865f14 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -32,8 +32,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define OMNIA_SPI_NOR_PATH "/soc/spi@10600/spi-nor@0"
-
 #define OMNIA_I2C_BUS_NAME "i2c@11000->i2cmux@70->i2c@0"
 
 #define OMNIA_I2C_MCU_CHIP_ADDR0x2a
@@ -1030,14 +1028,22 @@ static bool fixup_mtd_partitions(void *blob, int 
offset, struct mtd_info *mtd)
 
 static void fixup_spi_nor_partitions(void *blob)
 {
-   struct mtd_info *mtd;
+   struct mtd_info *mtd = NULL;
+   char mtd_path[64];
int node;
 
-   mtd = get_mtd_device_nm(OMNIA_SPI_NOR_PATH);
+   node = fdt_node_offset_by_compatible(gd->fdt_blob, -1, "jedec,spi-nor");
+   if (node < 0)
+   goto fail;
+
+   if (fdt_get_path(gd->fdt_blob, node, mtd_path, sizeof(mtd_path)) < 0)
+   goto fail;
+
+   mtd = get_mtd_device_nm(mtd_path);
if (IS_ERR_OR_NULL(mtd))
goto fail;
 
-   node = fdt_path_offset(blob, OMNIA_SPI_NOR_PATH);
+   node = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
if (node < 0)
goto fail;
 
-- 
2.20.1

Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

[Pali Rohár]

On Monday 01 August 2022 13:13:22 Simon Glass wrote:
> Hi Pali,
> 
> On Mon, 1 Aug 2022 at 09:43, Pali Rohár  wrote:
> >
> > Currently Makefile produces final mpc85xx image when SPL is not used in
> > custom file u-boot-with-dtb.bin. It is quite confusing name as build
> > process produce also intermediate file standard file u-boot-dtb.bin (which
> > is just intermediate and not bootable). Other platforms use u-boot.bin
> > (UBOOT_BIN) as standard name for final bootable raw image.
> >
> > So change Makefile rules and binman to produce final bootable file for
> > mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
> > define default rule for u-boot.bin then instruct binman (via DTS file) to
> > store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
> > finally rename target u-boot-with-dtb.bin to u-boot.bin.
> >
> > With this change are also removed custom Makefile hacks for mpc85xx that it
> > produced non-standard output file. And also updated documentation.
> >
> > Signed-off-by: Pali Rohár 
> > ---
> >  Makefile | 19 +--
> >  arch/powerpc/dts/kmcent2-u-boot.dtsi |  2 +-
> >  arch/powerpc/dts/u-boot.dtsi |  2 +-
> >  board/freescale/p1_p2_rdb_pc/README  |  2 +-
> >  board/freescale/p2041rdb/README  |  3 ---
> >  board/freescale/t102xrdb/README  |  2 +-
> >  board/freescale/t104xrdb/README  |  2 +-
> >  board/freescale/t208xqds/README  |  2 +-
> >  board/freescale/t208xrdb/README  |  2 +-
> >  9 files changed, 12 insertions(+), 24 deletions(-)
> 
> At present u-boot.bin has a very standard meaning - it is U-Boot with the DT.
> 
> Boards which need something more than that can/should use binman to
> create a separate file.
> 
> I certainly agree that u-boot-with-dtb.bin is a terrible name, though.
> Something more descriptive would be better.
> 
> But is it possible to drop these SoC-specific rules in the Makefile
> and just build everything needed in the standard binman rule in the
> Makefile?
> 
> Regards,
> Simon

I do not know what is binman doing and how to use it. I just do not see
reason why it is needed to use such additional tool for building final
binary for powerpc/mpc85xx as other arm boards do not use it at all.

Ad your comment "At present u-boot.bin has a very standard meaning - it
is U-Boot with the DT." - This is exactly what binman for mpc85xx
produces.

So I see there could be improvements, but as a first step this my patch
should be enough?

Re: [PATCH 0/6] introduce Arm FF-A support

[Sudeep Holla]

On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote:
> On Wed, 13 Apr 2022 at 10:46, Tom Rini  wrote:
> >
> > How is it both discoverable and doesn't have a device tree node, in the
> > kernel?
>
> Also, if it is discoverable, we can still use U-Boot to discover it
> and then pass the info to Linux in the DT.
>

Why ? Linux can discover the presence of the feature with a simple SMCCC
based query. We don't need any DT bindings for this particular feature.
Not sure if you are talking in general or in the context of $subject
feature in the kernel.

> I am seeing several series which don't have 'proper' DT bindings in
> Linux. First I heard it was for legacy reasons, but now I am hearing
> something different. For U-Boot, we really do need to have DT bindings
> for devices. All this ad-hoc creation of stuff makes things hard to
> discover, adds to code size and makes things like of-platdata
> impossible.
>

I may not have the complete picture here. If you are saying that every
feature in the u-boot needs DT for some reason, then that's U-boot's
limitation or restriction. But just the presence of node means nothing
until the corresponding feature is queried and confirmed to be present
in the firmware. That is very important as we can't skip the query stage
just because of presence of some DT node for this.

> Furthermore, if the bindings affect U-Boot, then the U-Boot project
> should have a say in what is being done there, not just be downstream
> of all such changes.
>

I still think you talking about some issue in general and it doesn't
apply in this case. The new firmware interfaces are designed to be
discoverable which is the main advantage over any non discoverable
hardware and/or firmware interface. One main advantage I see is that we
don't need any DT bindings which makes the firmware upgrades must simpler
as the users can query the interface and know exactly what they need
instead of relying on DT node which may get stale if not updated with the
firmware update. I am not sure if whatever I am writing here is relevant
to what your concerns are as I think I haven't understood them fully.

--
Regards,
Sudeep

Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

[Simon Glass]

Hi Pali,

On Mon, 1 Aug 2022 at 09:43, Pali Rohár  wrote:
>
> Currently Makefile produces final mpc85xx image when SPL is not used in
> custom file u-boot-with-dtb.bin. It is quite confusing name as build
> process produce also intermediate file standard file u-boot-dtb.bin (which
> is just intermediate and not bootable). Other platforms use u-boot.bin
> (UBOOT_BIN) as standard name for final bootable raw image.
>
> So change Makefile rules and binman to produce final bootable file for
> mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
> define default rule for u-boot.bin then instruct binman (via DTS file) to
> store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
> finally rename target u-boot-with-dtb.bin to u-boot.bin.
>
> With this change are also removed custom Makefile hacks for mpc85xx that it
> produced non-standard output file. And also updated documentation.
>
> Signed-off-by: Pali Rohár 
> ---
>  Makefile | 19 +--
>  arch/powerpc/dts/kmcent2-u-boot.dtsi |  2 +-
>  arch/powerpc/dts/u-boot.dtsi |  2 +-
>  board/freescale/p1_p2_rdb_pc/README  |  2 +-
>  board/freescale/p2041rdb/README  |  3 ---
>  board/freescale/t102xrdb/README  |  2 +-
>  board/freescale/t104xrdb/README  |  2 +-
>  board/freescale/t208xqds/README  |  2 +-
>  board/freescale/t208xrdb/README  |  2 +-
>  9 files changed, 12 insertions(+), 24 deletions(-)

At present u-boot.bin has a very standard meaning - it is U-Boot with the DT.

Boards which need something more than that can/should use binman to
create a separate file.

I certainly agree that u-boot-with-dtb.bin is a terrible name, though.
Something more descriptive would be better.

But is it possible to drop these SoC-specific rules in the Makefile
and just build everything needed in the standard binman rule in the
Makefile?

Regards,
Simon

Re: [PATCH v3 2/8] binman: allow user-defined filenames for mkimage entry

[Simon Glass]

Hi Quentin,

On Mon, 1 Aug 2022 at 10:06, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> mkimage entry currently creates a file whose name is derived from the
> section name containing said entry.
>
> Let's allow the user to define a filename for the mkimage-generated
> binary by using the 'filename' DT property.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> added in v3
>
>  tools/binman/etype/mkimage.py | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

This does need a test (should be able to update the mkimage one).

>
> diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
> index 52297c23ea..902c254425 100644
> --- a/tools/binman/etype/mkimage.py
> +++ b/tools/binman/etype/mkimage.py
> @@ -20,11 +20,13 @@ class Entry_mkimage(Entry):
>datafiles to mkimage instead of creating a temporary file the 
> result
>of datafiles concatenation
>  - args: Other arguments to pass
> +- filename: filename of output binary generated by mkimage
>
>  The data passed to mkimage is collected from subnodes of the mkimage 
> node,
>  e.g.::
>
>  mkimage {
> +filename = "imximage.bin";
>  args = "-n test -T imximage";
>
>  u-boot-spl {
> @@ -33,7 +35,7 @@ class Entry_mkimage(Entry):
>
>  This calls mkimage to create an imximage with u-boot-spl.bin as the input
>  file. The output from mkimage then becomes part of the image produced by
> -binman.
> +binman but also is written into imximage.bin file.
>
> To pass all datafiles untouched to mkimage::
>
> @@ -70,6 +72,7 @@ class Entry_mkimage(Entry):
>  self._args = fdt_util.GetArgs(self._node, 'args')
>  self._multiple_data_files = fdt_util.GetBool(self._node, 
> 'multiple-data-files')
>  self._mkimage_entries = OrderedDict()
> +self._filename = fdt_util.GetString(self._node, 'filename')
>  self.align_default = None
>  self.ReadEntries()
>
> @@ -89,7 +92,7 @@ class Entry_mkimage(Entry):
>  self._mkimage_entries.values(), 'mkimage', fake_size)
>  if data is None:
>  return False
> -output_fname = tools.get_output_filename('mkimage-out.%s' % uniq)
> +output_fname = tools.get_output_filename(self._filename if 
> self._filename else 'mkimage-out.%s' % uniq)

Check <80cols?

>  if self.mkimage.run_cmd('-d', input_fname, *self._args,
>  output_fname) is not None:
>  self.SetContents(tools.read_file(output_fname))
> --
> 2.37.1
>

Regards,
SImon

Re: [PATCH 0/6] introduce Arm FF-A support

[Simon Glass]

Hi,

On Wed, 13 Apr 2022 at 10:46, Tom Rini  wrote:
>
> On Wed, Apr 13, 2022 at 03:20:23PM +0100, Abdellatif El Khlifi wrote:
> > On Tue, Apr 12, 2022 at 08:28:42AM -0500, Rob Herring wrote:
> > > On Tue, Apr 12, 2022 at 7:01 AM Tom Rini  wrote:
> > > >
> > > > On Tue, Apr 12, 2022 at 12:43:15PM +0100, Abdellatif El Khlifi wrote:
> > > > > On Thu, Apr 07, 2022 at 08:58:11AM -0400, Tom Rini wrote:
> > > > > > On Thu, Apr 07, 2022 at 01:54:24PM +0100, Abdellatif El Khlifi 
> > > > > > wrote:
> > > > > > > On Wed, Apr 06, 2022 at 03:47:11PM -0400, Tom Rini wrote:
> > > > > > > > On Tue, Mar 29, 2022 at 04:16:53PM +0100, 
> > > > > > > > abdellatif.elkhl...@arm.com wrote:
> > > > > > > > > From: Abdellatif El Khlifi 
> > > > > > > > >
> > > > > > > > > This patchset adds support for Arm FF-A (Arm Firmware 
> > > > > > > > > Framework for Armv8-A v1.0).
> > > > > > > > >
> > > > > > > > > FF-A support is generic by design and can be used by any Arm 
> > > > > > > > > platform.
> > > > > > > > >
> > > > > > > > > The features added are as follows:
> > > > > > > > >
> > > > > > > > > 1/ FF-A device driver
> > > > > > > > > 2/ armffa command
> > > > > > > > > 3/ FF-A Sandbox driver
> > > > > > > > > 4/ FF-A Sandbox test cases
> > > > > > > > > 5/ FF-A MM communication
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The suggested design sees FF-A as a data bus allowing data 
> > > > > > > > > exchange with the firmware
> > > > > > > > > running under TrustZone HW (such as Optee). The same approach 
> > > > > > > > > was followed in the
> > > > > > > > > FF-A driver in Linux kernel 
> > > > > > > > > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/arm_ffa/bus.c?h=v5.15#n211))
> > > > > > > > >
> > > > > > > > > u-boot boards using FF-A can provide a device tree node in a 
> > > > > > > > > -u-boot.dtsi file.
> > > > > > > > > Since the node can not be hosted in Linux device tree, we 
> > > > > > > > > suggest using u-boot device tree.
> > > > > > > >
> > > > > > > > Why can't the node be in the upstream tree?  It should be, so 
> > > > > > > > that it
> > > > > > > > can be shared between all users.  Especially since there's 
> > > > > > > > in-Linux
> > > > > > > > users?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tom
> > > > > > >
> > > > > > > Linux already has an FF-A bus driver and doesn't use a device 
> > > > > > > tree node for FF-A.
> > > > > > >
> > > > > > > The Linux driver registers FF-A as a bus:
> > > > > > >
> > > > > > > int arm_ffa_bus_init(void)
> > > > > > > {
> > > > > > >   return bus_register(&ffa_bus_type);
> > > > > > > }
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/arm_ffa/bus.c?h=v5.15#n211
> > > > > > >
> > > > > > > So, there is no user for the node in Linux. That's why we suggest 
> > > > > > > hosting the node in the u-boot device tree (a u-boot.dtsi file)
> > > > > >
> > > > > > OK, but you can still push it upstream as it's not required to have 
> > > > > > an
> > > > > > in tree user.
> > > > >
> > > > > During the review of Corstone-1000 patchset, Rui Silva had a 
> > > > > discussion with the Linux device tree maintainer
> > > > > (Rob Herring). Rob is not in favour of an FFA node in the kernel 
> > > > > device tree. This is why we are including the FFA node
> > > > > in u-boot device tree (u-boot.dtsi files).
> > >
> > > Sigh. There is not a 'kernel device tree' and a 'u-boot device tree'.
> > > There is only 1. For SystemReadyIR compliance, that is a hard
> > > requirement.
> > >
> > > > I'm a bit confused now, can you please link to the kernel thread?  Or
> > > > Rob, can you chime in here please?
> > >
> > > The FFA DT binding was rejected in favor of making FFA discoverable.
> > > The FFA spec was amended to address that. DT is only for what we
> > > failed to make discoverable. For hardware, we're stuck with it. We
> > > shouldn't repeat that for software interfaces.
> > >
> > > Rob
> >
> > Guys,
> >
> > Since we can not add an FFA node in the device tree, we will make FFA a 
> > discoverable bus.
> > So, we will manually create the udevice, binding it to the driver and 
> > probing it.
> > Manually means directly calling device_bind and device_probe APIs.
> >
> > Any thoughts about this approach ?
>
> How is it both discoverable and doesn't have a device tree node, in the
> kernel?

Also, if it is discoverable, we can still use U-Boot to discover it
and then pass the info to Linux in the DT.

I am seeing several series which don't have 'proper' DT bindings in
Linux. First I heard it was for legacy reasons, but now I am hearing
something different. For U-Boot, we really do need to have DT bindings
for devices. All this ad-hoc creation of stuff makes things hard to
discover, adds to code size and makes things like of-platdata
impossible.

Furthermore, if the bindings affect U-Boot, then the U-Boot project
should have a say in what is being done ther

Re: [PATCH v3 3/8] rockchip: remove binman temporary files when cleaning

[Simon Glass]

Hi Johan,

On Mon, 1 Aug 2022 at 12:59, Johan Jonker  wrote:
>
> Hi Quentin,
>
> Beside removing the "real" annoyance is that these files popup when adding 
> with "git add ." and are blocking branch changing with "git branch ...".
> Maybe add to ".gitignore" as well or delete immediately. What's the use to 
> keep them around?

At this point I have to remind people to consider moving to
out-of-tree builds (make O=...)

Regards,
Simon

Re: [PATCH v3 5/8] rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards

[Simon Glass]

On Mon, 1 Aug 2022 at 10:06, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> This allows to build u-boot-rockchip.bin binary with binman for Rockchip
> ARM64 boards instead of the legacy Makefile way.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  Makefile  | 26 +-
>  arch/arm/Kconfig  |  2 +-
>  arch/arm/dts/rockchip-u-boot.dtsi |  5 +
>  3 files changed, 7 insertions(+), 26 deletions(-)

Nice!

Reviewed-by: Simon Glass 

Re: Replace make-fit-atf.py with binman. Was: migrate u-boot-rockchip.bin to binman and generate an image for SPI

[Simon Glass]

Hi Quentin,

On Mon, 1 Aug 2022 at 11:05, Quentin Schulz
 wrote:
>
> Hi Simon,
>
> On 7/31/22 03:27, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Wed, 27 Jul 2022 at 04:34, Quentin Schulz
> >  wrote:
> >>
> >> Hi Simon,
> >>
> >> On 7/26/22 21:58, Simon Glass wrote:
> >>> Hi Quentin,
> >>>
> >>> On Tue, 26 Jul 2022 at 03:08, Quentin Schulz
> >>>  wrote:
> 
>  Hi Xavier,
> 
>  On 7/25/22 19:33, Xavier Drudis Ferran wrote:
> > El Mon, Jul 25, 2022 at 07:29:53PM +0200, Xavier Drudis Ferran deia:
> >>
> >> I copy here the rockchip-u-boot.dtsi file and then 2 patches on top of 
> >> yours.
> >>
> >
> > Sorry I copied a dirty version that din't work. The patches were 
> > correct, the dtsi wasn't.
> >
> >>>
> >>> [..]
> >>>
> 
> >> +};
> >> +};
> >> +};
> >> +};
> >>simple-bin {
> >>filename = "u-boot-rockchip.bin";
> >>pad-byte = <0xff>;
> >> @@ -62,6 +131,7 @@
> >> #ifdef CONFIG_ARM64
> >>blob {
> >>filename = "u-boot.itb";
> >> +
> 
>  This is unfortunately not possible since binman parallelizes the build
>  of images in the binman DT node. This means there is no guarantee the
>  u-boot.itb file is generated before this section is worked on by binman.
>  Or maybe I misunderstood the docs.
> >>>
> >>> You are correct, but this is something that has bothered me.
> >>>
> >>> At the moment we handle this by embedding the definition for one file
> >>> into the one that uses it. This is on the theory that there is no need
> >>> to actually write the embedded file, since it is a temporary file. In
> >>> fact binman does generate temporary files though.
> >>>
> >>> Is that good enough? If not I'd like to understand the need better,
> >>> before we make any changes.
> >>>
> >>
> >> For Rockchip, with the patch series from
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220722113505.3875669-2D1-2Dfoss-2Buboot-400leil.net_&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=OevHoqt3vOXsWmXfEPFnvZ2KSNns-ZKBiiZBUovrynOXVCUZtFfK9jsk3C1r4Y_J&s=nXnNRN3hfa_mkkt_suH6wLGbwj06I7HmQKcagZ6JPE0&e=
> >>  ,
> >> we now have two binaries:
> >> u-boot-rockchip.bin and u-boot-rockchip-spi.bin
> >>
> >> Both share the exact same u-boot.itb file (though at a different offset
> >> in the storage medium) embedded.
> >>
> >> This u-boot.itb is currently externally created via the Makefile +
> >> make_fit_atf.py prior to binman being called. This allows us to have a
> >> blob { filename = "u-boot.itb"; } in the binman DT node and that's
> >> enough for it to work fine.
> >>
> >> There's a desire to get rid of make_fit_atf.py in favor of binman. This
> >> means that we need to create this file in binman now.
> >>
> >> There's been some resistance to making binman not create idbloader.img
> >> image in the patch series mentioned above (it is *technically* created
> >> by binman but only in temporary files and then embedded in
> >> u-boot-rockchip*.bin). I assume the same resistance will be met for
> >> u-boot.itb.
> >>
> >> With how binman works currently and since we have u-boot.itb content
> >> embedded in at least two different images created by binman (might be
> >> even more once there's USB/NAND support?), we'd need to have the fit
> >> device tree node appear thrice (or more). One for u-boot.itb creation
> >> (because of people not wanting it disappear from binaries generated by
> >> U-Boot), one for embedding into u-boot-rockchip.bin and one for
> >> embedding into u-boot-rockchip-spi.bin.
> >> This increases the risk of not updating all fit device tree nodes at once.
> >> This is suboptimal in terms of build time because the image will
> >> effectively be created thrice (or more).
> >> This is also not the best for easy check of reproducibility since the
> >> content of the fit device tree node is technically not the same as
> >> u-boot.itb file (because it is the result of a different image built by
> >> binman).
> >>
> >> So I think the minimal implementation would be to allow to define an
> >> image/section (u-boot.itb) and to "#include" it inline in another
> >> section (where blob { filename = "u-boot.itb"; } currently is for
> >> u-boot-rockchip.bin and u-boot-rockchip-spi.bin). From reading the docs,
> >> I expected collection entry to be exactly this? But I couldn't make it 
> >> work.
> >>
> >> Ideally, allowing binman to define a dependency from one image on
> >> another would mean we could still use the blob image/section, but
> >> safely, because the dependency is explicit so binman will know which
> >> image to build first. Phandles is what we're after on the Device Tree
> >> side I would assume. We could have something like: blob { image =
> >> <&u-boot-itb>; } for ex

Re: [PATCH v3 4/8] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

[Simon Glass]

On Mon, 1 Aug 2022 at 10:06, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> idbloader.img content - currently created by way of Makefile - can be
> created by binman directly.
>
> So let's do that for Rockchip ARM platforms.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> v3:
>  - moved spl back into mkimage section,
>  - added filename property so that the idbloader.img binary is still
>  generated,
>
>  Makefile  |  2 +-
>  arch/arm/dts/rockchip-u-boot.dtsi | 11 ++-
>  2 files changed, 11 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v2 0/7] Add support for cyclic function execution infrastruture

[Simon Glass]

Hi Stefan,

On Mon, 1 Aug 2022 at 08:09, Stefan Roese  wrote:
>
> Hi Simon,
>
> On 01.08.22 15:00, Simon Glass wrote:
> > Hi Stefan,
> >
> > On Mon, 1 Aug 2022 at 06:40, Stefan Roese  wrote:
> >>
> >> Hi Simon,
> >>
> >> On 01.08.22 14:22, Simon Glass wrote:
> >>> Hi Stefan,
> >>>
> >>> On Mon, 1 Aug 2022 at 01:17, Stefan Roese  wrote:
> 
>  Hi Simon,
> 
>  On 31.07.22 03:27, Simon Glass wrote:
> > Hi Stefan,
> >
> > On Thu, 28 Jul 2022 at 01:09, Stefan Roese  wrote:
> >>
> >> This patchset adds the basic infrastructure to periodically execute
> >> code, e.g. all 100ms. Examples for such functions might be LED blinking
> >> etc. The functions that are hooked into this cyclic list should be
> >> small timewise as otherwise the execution of the other code that relies
> >> on a high frequent polling (e.g. UART rx char ready check) might be
> >> delayed too much. This patch also adds the Kconfig option
> >> CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
> >> for such a cyclic function. If it's execution time exceeds this time,
> >> this cyclic function will get removed from the cyclic list.
> >>
> >> How is this cyclic functionality executed?
> >> This patchset integrates the main function responsible for calling all
> >> registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
> >> macro. This guarantees that cyclic_run() is executed very often, which
> >> is necessary for the cyclic functions to get scheduled and executed at
> >> their configured periods.
> >>
> >> This cyclic infrastructure will be used by a board specific function on
> >> the NIC23 MIPS Octeon board, which needs to check periodically, if a
> >> PCIe FLR has occurred.
> >>
> >> Ideas how to continue:
> >> One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
> >> move the watchdog_reset call into this cyclic infrastructure as well.
> >> Or to perhaps move the shell UART RX ready polling to a cyclic
> >> function.
> >>
> >> It's also possible to extend the "cyclic" command, to support the
> >> creation of periodically executed shell commands (for testing etc).
> >>
> >> Here the Azure build, without any issues:
> >> https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results
> >>
> >> Thanks,
> >> Stefan
> >>
> >> Aaron Williams (1):
> >>  mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure
> >>
> >> Stefan Roese (6):
> >>  time: Import time_after64() and friends from Linux
> >>  cyclic: Add basic support for cyclic function execution 
> >> infrastruture
> >>  cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
> >>  cyclic: Integrate cyclic functionality at bootup in board_r/f
> >>  cyclic: Add 'cyclic list' command
> >>  sandbox: Add cyclic demo function
> >>
> >> MAINTAINERS|   7 +
> >> board/Marvell/octeon_nic23/board.c | 197 
> >> +
> >> board/sandbox/sandbox.c|  15 +++
> >> cmd/Kconfig|   7 +
> >> cmd/Makefile   |   1 +
> >> cmd/cyclic.c   |  40 ++
> >> common/Kconfig |  20 +++
> >> common/Makefile|   1 +
> >> common/board_f.c   |   2 +
> >> common/board_r.c   |   2 +
> >> common/cyclic.c| 112 
> >> configs/octeon_nic23_defconfig |   3 +
> >> configs/sandbox_defconfig  |   3 +
> >> fs/cramfs/uncompress.c |   2 +-
> >> include/cyclic.h   |  97 ++
> >> include/time.h |  19 +++
> >> include/watchdog.h |  23 +++-
> >> 17 files changed, 547 insertions(+), 4 deletions(-)
> >> create mode 100644 cmd/cyclic.c
> >> create mode 100644 common/cyclic.c
> >> create mode 100644 include/cyclic.h
> >>
> >> --
> >> 2.37.1
> >>
> >
> > This looks interesting. I like the idea of integrating the watchdog
> > stuff too, since you are making use of it.
> >
> > Would it make sense to make use of the new event system, since it has
> > static and dynamic handlers?
> 
>  IIRC, I tried to make use of this infrastructure but it did not work
>  out. Or do you see some way to integrate this cyclic IF into the
>  event system? FWICT, the only way to get this done is to make use of
>  the (ugly) WATCHDOG_RESET calls.
> >>>
> >>> Yes that makes sense. I don't see another way.
> >>>
> >>> But within that, one option would be to send an event every time
> >>> WATCHDOG_RESET is used, and 

Re: [PATCH 1/2] Makefile: Fix dependency for u-boot-with-dtb.bin

[Simon Glass]

On Mon, 1 Aug 2022 at 09:43, Pali Rohár  wrote:
>
> Makefile uses binman to produce u-boot-with-dtb.bin target. As its input it
> takes DTB file and u-boot binary without DTB, which is stored in file
> u-boot-nodtb.bin. So fix target dependency.
>
> Signed-off-by: Pali Rohár 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index ff25f9297486..dcfcd7ebd5d2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1628,7 +1628,7 @@ u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp 
> u-boot.img FORCE
>  endif
>
>  ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
> -u-boot-with-dtb.bin: u-boot.bin u-boot.dtb \
> +u-boot-with-dtb.bin: u-boot-nodtb.bin u-boot.dtb \
> $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
> $(call if_changed,binman)
>
> --
> 2.20.1
>

Reviewed-by: Simon Glass 

But I feel this should be dropped and be handled by the normal binman
rule in the Makefile.

Re: [PATCH 5/5] dm: rtc: Try to handle the localtime() race

[Simon Glass]

Hi Heinrich,

On Mon, 1 Aug 2022 at 09:00, Heinrich Schuchardt  wrote:
>
> On 8/1/22 15:58, Simon Glass wrote:
> > At present the sandbox timer uses localtime() which can jump around twice
> > a year when daylight-saving time changes.
> >
> > It would be tricky to make use of gmtime() since we still need to present
> > the time in local time, as seems to be required by U-Boot's RTC interface.
> >
> > The problem can only happen once, so use a loop to detect it and try
> > again. This should be sufficient to detect either a change in the 'second'
> > value, or a daylight-saving change. We can assume that the latter also
> > incorporates a 'second' change, so there is no need to loop more than
> > twice.
> >
> > Signed-off-by: Simon Glass 
>
> Linux systems tend to use UTC on the RTC. There is no reason for
> sandbox_defconfig to deviate. Please, avoid all this complication by
> reading the time with gmtime() instead of localtime().

That is an API change...how will we show the local time in that case?
I suppose we need to add this concept to rtc.h ?

Regards,
Simon

Re: [PATCH] dm: rtc: Avoid a race in the rtc_reset test

[Simon Glass]

Hi Heinrich,

On Mon, 1 Aug 2022 at 08:58, Heinrich Schuchardt  wrote:
>
> On 8/1/22 15:59, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 1 Aug 2022 at 02:11, Heinrich Schuchardt  wrote:
> >>
> >> On 7/31/22 20:27, Simon Glass wrote:
> >>> Since resetting the RTC on sandbox causes it to read the base time from
> >>> the system, we cannot rely on this being unchanged since it was last read.
> >>> Allow for a one-second delay.
> >>>
> >>> Fixes: https://source.denx.de/u-boot/u-boot/-/issues/4
> >>> Reported-by: Bin Meng 
> >>> Reported-by: Tom Rini 
> >>> Suggested-by: Rasmus Villemoes 
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>>test/dm/rtc.c | 11 ---
> >>>1 file changed, 8 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/test/dm/rtc.c b/test/dm/rtc.c
> >>> index c7f9f8f0ce7..403bf5c640a 100644
> >>> --- a/test/dm/rtc.c
> >>> +++ b/test/dm/rtc.c
> >>> @@ -245,16 +245,21 @@ static int dm_test_rtc_reset(struct unit_test_state 
> >>> *uts)
> >>>ut_assertok(dm_rtc_get(dev, &now));
> >>>
> >>>ut_assertok(i2c_emul_find(dev, &emul));
> >>> - ut_assert(emul != NULL);
> >>> + ut_assertnonnull(emul);
> >>
> >> This is an unrelated change. It would be preferable to describe it in
> >> the commit message.
> >>
> >>>
> >>>old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
> >>>
> >>>ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
> >>>
> >>> - /* Resetting the RTC should put he base time back to normal */
> >>> + /*
> >>> +  * Resetting the RTC should put the base time back to normal. Allow 
> >>> for
> >>> +  * a one-second adjustment in case the time flips over while this
> >>> +  * test process is pre-empted, since reset_time() in i2c_rtc_emul.c
> >>> +  * reads the time from the OS.
> >>> +  */
> >>>ut_assertok(dm_rtc_reset(dev));
> >>>base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
> >>> - ut_asserteq(old_base_time, base_time);
> >>> + ut_assert(base_time - old_base_time <= 1);
> >>
> >> If the operating system uses daylight saving time, this may still fail
> >> (very rarely).
> >>
> >> How about using gmtime() instead of localtime()? But that would be a
> >> separate patch.
> >
> > I'm not sure how to do this, as U-Boot expects local time. Of course
> > we could enhance the rtc API to support both (and use gmtime for the
>
> What makes you think that U-Boot expects local time? U-Boot has no
> notion of time zones. Linux systems tend to use UTC on the RTC. Why
> should sandbox_defconfig deviate?
>
> $ sudo hwclock --show -v
> hwclock from util-linux 2.38
> System Time: 1659365754.792540
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Assuming hardware clock is kept in UTC time.

Well the thing is, we want to show local times in U-Boot. As I
mentioned, we could expand the API to allow control over that, e.g. to
show local times but use UTC in tests?

>
> If you dual boot into Windows, you should better adjust Windows to use UTC.

I'm not the world's most dedicated Windows user.

Regards,
Simon


>
> Best regards
>
> Heinrich
>
> > test).
> >
> > I've got an idea how to deal with daylight savings, and an alternative
> > approach for this patch, so will send a series.
> >
> >>
> >> Reviewed-by: Heinrich Schuchardt 
> >>
> >>>
> >>>return 0;
> >>>}
> >>
> >
> > Regards,
> > Simon
>

Re: [PATCH 1/1] cmd: inconsistent return type of command_process()

[Simon Glass]

On Mon, 1 Aug 2022 at 07:18, Heinrich Schuchardt
 wrote:
>
> The declarations in the header and in the implementation must match.
>
> Reported-by: Sergei Antonov 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/command.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] doc: develop: Add a note about importing code from other projects

[Sudeep Holla]

On Mon, Aug 01, 2022 at 02:57:01PM -0400, Tom Rini wrote:
> We talk about importing code from other projects in two places. The
> first place is in the coding style section, where we explain when to or
> not to deviate in terms of white space, etc. In the process
> documentation we now add a note about saying where the code was imported
> from and to ensure that you do not copy Signed-off-by or other tags.
>
> Signed-off-by: Tom Rini 
> ---
> Given Sudeep's feedback just now on another series, it makes sense to
> note this in the documentation, for future reference.

Thanks for the quick response in the form of patch. That is super fast
and efficient 😄.

Acked-by: Sudeep Holla 

-- 
Regards,
Sudeep

Re: [PATCH v3 3/8] rockchip: remove binman temporary files when cleaning

[Johan Jonker]

Hi Quentin,

Beside removing the "real" annoyance is that these files popup when adding with 
"git add ." and are blocking branch changing with "git branch ...".
Maybe add to ".gitignore" as well or delete immediately. What's the use to keep 
them around?

Johan

On 8/1/22 18:06, Quentin Schulz wrote:
> From: Quentin Schulz 
> 
> Binman mkimage entry generates temporary files so let's remove them
> when calling `make clean`.
> 
> Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry")
> Cc: Quentin Schulz 
> Reported-by: Johan Jonker 
> Signed-off-by: Quentin Schulz 
> ---
> 
> added in v3
> 
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index ff25f92974..bbb2a4c088 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2220,7 +2220,8 @@ CLEAN_FILES += include/bmp_logo.h 
> include/bmp_logo_data.h \
>  lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
>  idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
>  mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
> -itb.fit.fit itb.fit.itb itb.map spl.map
> +itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
> +mkimage.rom.mkimage rom.map simple-bin.map
>  
>  # Directories & files removed with 'make mrproper'
>  MRPROPER_DIRS  += include/config include/generated spl tpl \

[PATCH] doc: develop: Add a note about importing code from other projects

[Tom Rini]

We talk about importing code from other projects in two places. The
first place is in the coding style section, where we explain when to or
not to deviate in terms of white space, etc. In the process
documentation we now add a note about saying where the code was imported
from and to ensure that you do not copy Signed-off-by or other tags.

Signed-off-by: Tom Rini 
---
Given Sudeep's feedback just now on another series, it makes sense to
note this in the documentation, for future reference.
---
 doc/develop/process.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0ef24e819982..388945cf9bb9 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -139,6 +139,10 @@ like this:
as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
that contains the developer's name and email address is required.
 
+   * Please note that when importing code from other projects you must say
+ where it comes from, and what revision you are importing. You must not
+ however copy ``Signed-off-by`` or other tags.
+
 #. Everybody who can is invited to review and test the changes.  Typically, we
follow the same guidelines as the Linux kernel for `Acked-by

`_
-- 
2.25.1

Re: [PATCH v3 1/4] arm64: smccc: add Xn registers support used by SMC calls

[Sudeep Holla]

On Mon, Aug 01, 2022 at 06:20:50PM +0100, Abdellatif El Khlifi wrote:
> use x0-x17 registers in the SMC32/SMC64 calls according to SMCCCv1.2
> 
> Signed-off-by: Sudeep Holla 

Please drop my signed-off as I didn't. I am seeing this patch on the list
for the first time and AFAIK I haven't posted any previous version of the
patch that you are picking up.

IIUC, you are importing this code from the Linux kernel tree which I assume
is fine. You can just mention the same and must not add anyone's sign-off
without consulting them.

OTH, if you cherry-pick the commit as is and use it in u-boot tree(e.g.
DTS patches), then you can retain them. That is my understanding. Happy
to be corrected if my assumptions are not correct here.

--
Regards,
Sudeep

[PATCH v2 5/5] arm: bcmbca: add bcm63148 SoC support

[William Zhang]

BCM63148 is an Broadcom B15 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang 

---

Changes in v2:
- Move COUNTER_FREQUENCY to bcm63148 defconfig

 MAINTAINERS|   1 +
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/bcm63148.dtsi | 103 +
 arch/arm/dts/bcm963148.dts |  30 +++
 arch/arm/mach-bcmbca/Kconfig   |   8 ++
 arch/arm/mach-bcmbca/Makefile  |   1 +
 arch/arm/mach-bcmbca/bcm63148/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm63148/Makefile |   5 ++
 board/broadcom/bcmbca/Kconfig  |   7 ++
 configs/bcm963148_defconfig|  23 ++
 include/configs/bcm963148.h|  11 +++
 11 files changed, 208 insertions(+)
 create mode 100644 arch/arm/dts/bcm63148.dtsi
 create mode 100644 arch/arm/dts/bcm963148.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm63148/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm63148/Makefile
 create mode 100644 configs/bcm963148_defconfig
 create mode 100644 include/configs/bcm963148.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d4b2f2ebb94..d1d13c733db4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -218,6 +218,7 @@ F:  arch/arm/mach-bcmbca/
 F: board/broadcom/bcmbca/
 N: bcmbca
 N: bcm[9]?47622
+N: bcm[9]?63148
 N: bcm[9]?63178
 N: bcm[9]?6756
 N: bcm[9]?6846
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f00bdb19675b..b8d136bd129b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1165,6 +1165,8 @@ dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
 
 dtb-$(CONFIG_BCM47622) += \
bcm947622.dtb
+dtb-$(CONFIG_BCM63148) += \
+   bcm963148.dtb
 dtb-$(CONFIG_BCM63178) += \
bcm963178.dtb
 dtb-$(CONFIG_BCM6756) += \
diff --git a/arch/arm/dts/bcm63148.dtsi b/arch/arm/dts/bcm63148.dtsi
new file mode 100644
index ..df5307b6b3af
--- /dev/null
+++ b/arch/arm/dts/bcm63148.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm63148", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   B15_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "brcm,brahma-b15";
+   reg = <0x0>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   B15_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "brcm,brahma-b15";
+   reg = <0x1>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   L2_0: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+   ,
+   ,
+   ;
+   };
+
+   pmu: pmu {
+   compatible = "arm,cortex-a15-pmu";
+   interrupts = ,
+   ;
+   interrupt-affinity = <&B15_0>, <&B15_1>;
+   };
+
+   clocks: clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   axi@8003 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x8003 0x8000>;
+
+   gic: interrupt-controller@1000 {
+   compatible = "arm,cortex-a15-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x1000 0x1000>,
+   <0x2000 0x2000>,
+   <0x4000 0x2000>,
+   <0x6000 0x2000>;
+   interrupts = ;
+   };
+   };
+
+   bus@ff80 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   

[PATCH v2 4/5] arm: bcmbca: add bcm6756 SoC support

[William Zhang]

BCM6756 is an ARM A7 based WLAN Gateway and Access Point Broadband SoC.
It is part of the BCA(Broadband Carrier Access origin) chipset family so
it's added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang 

---

Changes in v2:
- Move COUNTER_FREQUENCY to bcm6756 defconfig

 MAINTAINERS   |   1 +
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/bcm6756.dtsi | 130 ++
 arch/arm/dts/bcm96756.dts |  30 ++
 arch/arm/mach-bcmbca/Kconfig  |   8 ++
 arch/arm/mach-bcmbca/Makefile |   1 +
 arch/arm/mach-bcmbca/bcm6756/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm6756/Makefile |   5 +
 board/broadcom/bcmbca/Kconfig |  15 ++-
 configs/bcm96756_defconfig|  23 +
 include/configs/bcm96756.h|  11 +++
 11 files changed, 239 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/bcm6756.dtsi
 create mode 100644 arch/arm/dts/bcm96756.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm6756/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6756/Makefile
 create mode 100644 configs/bcm96756_defconfig
 create mode 100644 include/configs/bcm96756.h

diff --git a/MAINTAINERS b/MAINTAINERS
index db16d0211c52..4d4b2f2ebb94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -219,6 +219,7 @@ F:  board/broadcom/bcmbca/
 N: bcmbca
 N: bcm[9]?47622
 N: bcm[9]?63178
+N: bcm[9]?6756
 N: bcm[9]?6846
 N: bcm[9]?6878
 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 281f92c841c0..f00bdb19675b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1167,6 +1167,8 @@ dtb-$(CONFIG_BCM47622) += \
bcm947622.dtb
 dtb-$(CONFIG_BCM63178) += \
bcm963178.dtb
+dtb-$(CONFIG_BCM6756) += \
+   bcm96756.dtb
 dtb-$(CONFIG_BCM6846) += \
bcm96846.dtb
 dtb-$(CONFIG_BCM6878) += \
diff --git a/arch/arm/dts/bcm6756.dtsi b/arch/arm/dts/bcm6756.dtsi
new file mode 100644
index ..ce1b59faf800
--- /dev/null
+++ b/arch/arm/dts/bcm6756.dtsi
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm6756", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CA7_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   L2_0: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+   ,
+   ,
+   ;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   pmu: pmu {
+   compatible = "arm,cortex-a7-pmu";
+   interrupts = ,
+   ,
+   ,
+   ;
+   interrupt-affinity = <&CA7_0>, <&CA7_1>,
+   <&CA7_2>, <&CA7_3>;
+   };
+
+   clocks: clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   };
+
+   uart_clk: uart-clk {
+   compatible = "fixed-factor-clock";
+   #clock-cells = <0>;
+   clocks = <&periph_clk>;
+   

[PATCH v2 3/5] arm: bcmbca: add bcm6878 SoC support

[William Zhang]

BCM6878 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011
uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang 

---

Changes in v2:
- Move COUNTER_FREQUENCY to bcm6878 defconfig

 MAINTAINERS   |   1 +
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/bcm6878.dtsi | 111 ++
 arch/arm/dts/bcm96878.dts |  30 +++
 arch/arm/mach-bcmbca/Kconfig  |   8 ++
 arch/arm/mach-bcmbca/Makefile |   1 +
 arch/arm/mach-bcmbca/bcm6878/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm6878/Makefile |   5 ++
 board/broadcom/bcmbca/Kconfig |   7 ++
 configs/bcm96878_defconfig|  23 ++
 include/configs/bcm96878.h|  11 +++
 11 files changed, 216 insertions(+)
 create mode 100644 arch/arm/dts/bcm6878.dtsi
 create mode 100644 arch/arm/dts/bcm96878.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm6878/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6878/Makefile
 create mode 100644 configs/bcm96878_defconfig
 create mode 100644 include/configs/bcm96878.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b0fde1cb7285..db16d0211c52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -220,6 +220,7 @@ N:  bcmbca
 N: bcm[9]?47622
 N: bcm[9]?63178
 N: bcm[9]?6846
+N: bcm[9]?6878
 
 ARM BROADCOM BCMSTB
 M: Thomas Fitzsimmons 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5300ae8b2a1c..281f92c841c0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1169,6 +1169,8 @@ dtb-$(CONFIG_BCM63178) += \
bcm963178.dtb
 dtb-$(CONFIG_BCM6846) += \
bcm96846.dtb
+dtb-$(CONFIG_BCM6878) += \
+   bcm96878.dtb
 
 dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
 dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm6878.dtsi b/arch/arm/dts/bcm6878.dtsi
new file mode 100644
index ..1e8b5fa96c25
--- /dev/null
+++ b/arch/arm/dts/bcm6878.dtsi
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm6878", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CA7_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   L2_0: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+   ,
+   ,
+   ;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   pmu: pmu {
+   compatible = "arm,cortex-a7-pmu";
+   interrupts = ,
+   ;
+   interrupt-affinity = <&CA7_0>, <&CA7_1>;
+   };
+
+   clocks: clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   };
+   uart_clk: uart-clk {
+   compatible = "fixed-factor-clock";
+   #clock-cells = <0>;
+   clocks = <&periph_clk>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   axi@8100 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x8100 0x8000>;
+
+   gic: interrupt-controller@1000 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x1000 0x1

[PATCH v2 2/5] arm: bcmbca: add bcm6846 SoC support

[William Zhang]

BCM6846 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang 

---

Changes in v2:
- Move COUNTER_FREQUENCY to bcm6846 defconfig

 MAINTAINERS   |   1 +
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/bcm6846.dtsi | 103 ++
 arch/arm/dts/bcm96846.dts |  30 
 arch/arm/mach-bcmbca/Kconfig  |   8 ++
 arch/arm/mach-bcmbca/Makefile |   1 +
 arch/arm/mach-bcmbca/bcm6846/Kconfig  |  17 +
 arch/arm/mach-bcmbca/bcm6846/Makefile |   5 ++
 board/broadcom/bcmbca/Kconfig |   7 ++
 configs/bcm96846_defconfig|  23 ++
 include/configs/bcm96846.h|  11 +++
 11 files changed, 208 insertions(+)
 create mode 100644 arch/arm/dts/bcm6846.dtsi
 create mode 100644 arch/arm/dts/bcm96846.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm6846/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6846/Makefile
 create mode 100644 configs/bcm96846_defconfig
 create mode 100644 include/configs/bcm96846.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a01d2b69b260..b0fde1cb7285 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -219,6 +219,7 @@ F:  board/broadcom/bcmbca/
 N: bcmbca
 N: bcm[9]?47622
 N: bcm[9]?63178
+N: bcm[9]?6846
 
 ARM BROADCOM BCMSTB
 M: Thomas Fitzsimmons 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6628b1151fea..5300ae8b2a1c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1167,6 +1167,8 @@ dtb-$(CONFIG_BCM47622) += \
bcm947622.dtb
 dtb-$(CONFIG_BCM63178) += \
bcm963178.dtb
+dtb-$(CONFIG_BCM6846) += \
+   bcm96846.dtb
 
 dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
 dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm6846.dtsi b/arch/arm/dts/bcm6846.dtsi
new file mode 100644
index ..8aa47a2583b2
--- /dev/null
+++ b/arch/arm/dts/bcm6846.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm6846", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CA7_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   L2_0: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+   ,
+   ,
+   ;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   pmu: pmu {
+   compatible = "arm,cortex-a7-pmu";
+   interrupts = ,
+   ;
+   interrupt-affinity = <&CA7_0>, <&CA7_1>;
+   };
+
+   clocks: clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   axi@8100 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x8100 0x8000>;
+
+   gic: interrupt-controller@1000 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   interrupts = ;
+   reg = <0x1000 0x1000>,
+   <0x2000 0x2000>,
+   <0x4000 0x2000>,
+   <0x6000 0x2000>;
+   };
+   };
+
+   bus@ff80 {
+   compatible = 

[PATCH v2 1/5] arm: bcmbca: add bcm63178 SoC support

[William Zhang]

BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang 

---

Changes in v2:
- Move COUNTER_FREQUENCY to bcm63178 defconfig

 MAINTAINERS|   5 +-
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/bcm63178.dtsi | 120 +
 arch/arm/dts/bcm963178.dts |  30 +++
 arch/arm/mach-bcmbca/Kconfig   |  10 ++-
 arch/arm/mach-bcmbca/Makefile  |   1 +
 arch/arm/mach-bcmbca/bcm63178/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm63178/Makefile |   5 ++
 board/broadcom/bcmbca/Kconfig  |   7 ++
 configs/bcm963178_defconfig|  23 +
 include/configs/bcm963178.h|  11 +++
 11 files changed, 228 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/bcm63178.dtsi
 create mode 100644 arch/arm/dts/bcm963178.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm63178/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm63178/Makefile
 create mode 100644 configs/bcm963178_defconfig
 create mode 100644 include/configs/bcm963178.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 31291d34f353..a01d2b69b260 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -216,8 +216,9 @@ M:  Joel Peshkin 
 S: Maintained
 F: arch/arm/mach-bcmbca/
 F: board/broadcom/bcmbca/
-F: configs/bcm947622_defconfig
-F: include/configs/bcm947622.h
+N: bcmbca
+N: bcm[9]?47622
+N: bcm[9]?63178
 
 ARM BROADCOM BCMSTB
 M: Thomas Fitzsimmons 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7fa275ea7cca..6628b1151fea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1165,6 +1165,8 @@ dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
 
 dtb-$(CONFIG_BCM47622) += \
bcm947622.dtb
+dtb-$(CONFIG_BCM63178) += \
+   bcm963178.dtb
 
 dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
 dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm63178.dtsi b/arch/arm/dts/bcm63178.dtsi
new file mode 100644
index ..cbd094dde6d0
--- /dev/null
+++ b/arch/arm/dts/bcm63178.dtsi
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Broadcom Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "brcm,bcm63178", "brcm,bcmbca";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CA7_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   CA7_2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   next-level-cache = <&L2_0>;
+   enable-method = "psci";
+   };
+
+   L2_0: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+   ,
+   ,
+   ;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   pmu: pmu {
+   compatible = "arm,cortex-a7-pmu";
+   interrupts = ,
+   ,
+   ;
+   interrupt-affinity = <&CA7_0>, <&CA7_1>,
+   <&CA7_2>;
+   };
+
+   clocks: clocks {
+   periph_clk: periph-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2>;
+   };
+   uart_clk: uart-clk {
+   compatible = "fixed-factor-clock";
+   #clock-cells = <0>;
+   clocks = <&periph_clk>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+   };
+
+   psci {
+  

[PATCH v2 0/5] arm: bcmbca: add basic support for Broadcom BCA SoCs

[William Zhang]

Broadcom BCA (Broadband Carrier Access origin) chipset family includes
DSL, PON and WLAN access point and gateway SoC. Now that the ARCH_BCMBCA
architecture and its first SoC BCM47622 are supported in u-boot 2022.07,
this patch series add the basic support for following BCA chips under
ARCH_BCMBCA: BCM63178, BCM6846, BCM6878, BCM6756 and BCM63148.

We expect to send additional patches for more BCMBCA SoCs in the near
future.

Changes in v2:
- Move COUNTER_FREQUENCY to bcm63178 defconfig
- Move COUNTER_FREQUENCY to bcm6846 defconfig
- Move COUNTER_FREQUENCY to bcm6878 defconfig
- Move COUNTER_FREQUENCY to bcm6756 defconfig
- Move COUNTER_FREQUENCY to bcm63148 defconfig

William Zhang (5):
  arm: bcmbca: add bcm63178 SoC support
  arm: bcmbca: add bcm6846 SoC support
  arm: bcmbca: add bcm6878 SoC support
  arm: bcmbca: add bcm6756 SoC support
  arm: bcmbca: add bcm63148 SoC support

 MAINTAINERS|   9 +-
 arch/arm/dts/Makefile  |  10 ++
 arch/arm/dts/bcm63148.dtsi | 103 
 arch/arm/dts/bcm63178.dtsi | 120 +++
 arch/arm/dts/bcm6756.dtsi  | 130 +
 arch/arm/dts/bcm6846.dtsi  | 103 
 arch/arm/dts/bcm6878.dtsi  | 111 +
 arch/arm/dts/bcm963148.dts |  30 ++
 arch/arm/dts/bcm963178.dts |  30 ++
 arch/arm/dts/bcm96756.dts  |  30 ++
 arch/arm/dts/bcm96846.dts  |  30 ++
 arch/arm/dts/bcm96878.dts  |  30 ++
 arch/arm/mach-bcmbca/Kconfig   |  42 +++-
 arch/arm/mach-bcmbca/Makefile  |   5 +
 arch/arm/mach-bcmbca/bcm63148/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm63148/Makefile |   5 +
 arch/arm/mach-bcmbca/bcm63178/Kconfig  |  17 
 arch/arm/mach-bcmbca/bcm63178/Makefile |   5 +
 arch/arm/mach-bcmbca/bcm6756/Kconfig   |  17 
 arch/arm/mach-bcmbca/bcm6756/Makefile  |   5 +
 arch/arm/mach-bcmbca/bcm6846/Kconfig   |  17 
 arch/arm/mach-bcmbca/bcm6846/Makefile  |   5 +
 arch/arm/mach-bcmbca/bcm6878/Kconfig   |  17 
 arch/arm/mach-bcmbca/bcm6878/Makefile  |   5 +
 board/broadcom/bcmbca/Kconfig  |  35 +++
 configs/bcm963148_defconfig|  23 +
 configs/bcm963178_defconfig|  23 +
 configs/bcm96756_defconfig |  23 +
 configs/bcm96846_defconfig |  23 +
 configs/bcm96878_defconfig |  23 +
 include/configs/bcm963148.h|  11 +++
 include/configs/bcm963178.h|  11 +++
 include/configs/bcm96756.h |  11 +++
 include/configs/bcm96846.h |  11 +++
 include/configs/bcm96878.h |  11 +++
 35 files changed, 1095 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/bcm63148.dtsi
 create mode 100644 arch/arm/dts/bcm63178.dtsi
 create mode 100644 arch/arm/dts/bcm6756.dtsi
 create mode 100644 arch/arm/dts/bcm6846.dtsi
 create mode 100644 arch/arm/dts/bcm6878.dtsi
 create mode 100644 arch/arm/dts/bcm963148.dts
 create mode 100644 arch/arm/dts/bcm963178.dts
 create mode 100644 arch/arm/dts/bcm96756.dts
 create mode 100644 arch/arm/dts/bcm96846.dts
 create mode 100644 arch/arm/dts/bcm96878.dts
 create mode 100644 arch/arm/mach-bcmbca/bcm63148/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm63148/Makefile
 create mode 100644 arch/arm/mach-bcmbca/bcm63178/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm63178/Makefile
 create mode 100644 arch/arm/mach-bcmbca/bcm6756/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6756/Makefile
 create mode 100644 arch/arm/mach-bcmbca/bcm6846/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6846/Makefile
 create mode 100644 arch/arm/mach-bcmbca/bcm6878/Kconfig
 create mode 100644 arch/arm/mach-bcmbca/bcm6878/Makefile
 create mode 100644 configs/bcm963148_defconfig
 create mode 100644 configs/bcm963178_defconfig
 create mode 100644 configs/bcm96756_defconfig
 create mode 100644 configs/bcm96846_defconfig
 create mode 100644 configs/bcm96878_defconfig
 create mode 100644 include/configs/bcm963148.h
 create mode 100644 include/configs/bcm963178.h
 create mode 100644 include/configs/bcm96756.h
 create mode 100644 include/configs/bcm96846.h
 create mode 100644 include/configs/bcm96878.h

-- 
2.37.1



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

[Tom Rini]

On Mon, Aug 01, 2022 at 05:42:20PM +0200, Pali Rohár wrote:

> Currently Makefile produces final mpc85xx image when SPL is not used in
> custom file u-boot-with-dtb.bin. It is quite confusing name as build
> process produce also intermediate file standard file u-boot-dtb.bin (which
> is just intermediate and not bootable). Other platforms use u-boot.bin
> (UBOOT_BIN) as standard name for final bootable raw image.
> 
> So change Makefile rules and binman to produce final bootable file for
> mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
> define default rule for u-boot.bin then instruct binman (via DTS file) to
> store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
> finally rename target u-boot-with-dtb.bin to u-boot.bin.
> 
> With this change are also removed custom Makefile hacks for mpc85xx that it
> produced non-standard output file. And also updated documentation.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] Makefile: Fix dependency for u-boot-with-dtb.bin

[Tom Rini]

On Mon, Aug 01, 2022 at 05:42:19PM +0200, Pali Rohár wrote:

> Makefile uses binman to produce u-boot-with-dtb.bin target. As its input it
> takes DTB file and u-boot binary without DTB, which is stored in file
> u-boot-nodtb.bin. So fix target dependency.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/5] arm: bcmbca: add bcm63178 SoC support

[William Zhang]

Hi Tom,

On 08/01/2022 07:02 AM, Tom Rini wrote:

On Fri, Jul 29, 2022 at 12:48:43PM -0700, William Zhang wrote:


BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang 

[snip]

diff --git a/include/configs/bcm963178.h b/include/configs/bcm963178.h
new file mode 100644
index ..3ee2011b3a2d
--- /dev/null
+++ b/include/configs/bcm963178.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2022 Broadcom Ltd.
+ */
+
+#ifndef __BCM963178_H
+#define __BCM963178_H
+
+#define CONFIG_SYS_SDRAM_BASE  0x
+#define COUNTER_FREQUENCY  5000
+
+#endif


The one problem I have is that we need to put COUNTER_FREQUENCY
somewhere else, if it needs to be defined.  I see the top-level README
has outdated information about COUNTER_FREQUENCY, which is most often
CONFIG_COUNTER_FREQUENCY instead, as well.


Sure I will move it to CONFIG_COUNTER_FREQUENCY in soc defconfig.


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH v3 4/4] arm_ffa: introduce armffa command

[Abdellatif El Khlifi]

Provide armffa command showcasing the use of the FF-A driver

The armffa command allows to query secure partitions data from
the secure world and exchanging messages with the partitions.

Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Ilias Apalodimas 
Cc: Jens Wiklander 
---
 MAINTAINERS |   1 +
 cmd/Kconfig |  10 ++
 cmd/Makefile|   2 +
 cmd/armffa.c| 246 
 drivers/arm-ffa/Kconfig |   1 +
 5 files changed, 260 insertions(+)
 create mode 100644 cmd/armffa.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a57f4df2..b0fbc027c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -251,6 +251,7 @@ F:  configs/cortina_presidio-asic-pnand_defconfig
 ARM FF-A
 M: Abdellatif El Khlifi 
 S: Maintained
+F: cmd/armffa.c
 F: drivers/arm-ffa/
 F: include/arm_ffa.h
 
diff --git a/cmd/Kconfig b/cmd/Kconfig
index a8260aa170..22f85188ff 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -902,6 +902,16 @@ endmenu
 
 menu "Device access commands"
 
+config CMD_ARMFFA
+   bool "Arm FF-A test command"
+   depends on ARM_FFA_TRANSPORT
+   help
+ Provides a test command for the Arm FF-A driver
+ supported options:
+   - Listing the partition(s) info
+   - Sending a data pattern to the specified partition
+   - Displaying the arm_ffa device info
+
 config CMD_ARMFLASH
#depends on FLASH_CFI_DRIVER
bool "armflash"
diff --git a/cmd/Makefile b/cmd/Makefile
index 5e43a1e022..e40f52f1e4 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,8 @@ obj-y += panic.o
 obj-y += version.o
 
 # command
+
+obj-$(CONFIG_CMD_ARMFFA) += armffa.o
 obj-$(CONFIG_CMD_ACPI) += acpi.o
 obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
 obj-$(CONFIG_CMD_AES) += aes.o
diff --git a/cmd/armffa.c b/cmd/armffa.c
new file mode 100644
index 00..cb8a3d40aa
--- /dev/null
+++ b/cmd/armffa.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022 ARM Limited
+ * Abdellatif El Khlifi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * do_ffa_get_singular_partition_info - implementation of the getpart 
subcommand
+ * @cmdtp: Command Table
+ * @flag:  flags
+ * @argc:  number of arguments
+ * @argv:  arguments
+ *
+ * This function queries the secure partition information which the UUID is 
provided
+ * as an argument. The function uses the arm_ffa driver partition_info_get 
operation
+ * to retrieve the data.
+ * The input UUID string is expected to be in big endian format.
+ *
+ * Return:
+ *
+ * CMD_RET_SUCCESS: on success, otherwise failure
+ */
+static int do_ffa_get_singular_partition_info(struct cmd_tbl *cmdtp, int flag, 
int argc,
+ char *const argv[])
+{
+   u32 count = 0, size = 0;
+   int ret;
+   struct ffa_partition_info *parts_info;
+   u32 info_idx;
+
+   if (argc != 1)
+   return -EINVAL;
+
+   /* Mode 1: getting the number of secure partitions */
+   ret = ffa_bus_ops_get()->partition_info_get(argv[0], &count, NULL);
+   if (ret != FFA_ERR_STAT_SUCCESS) {
+   ffa_err("Failure in querying partitions count (error code: 
%d)", ret);
+   return ret;
+   }
+
+   if (!count) {
+   ffa_info("No secure partition found");
+   return ret;
+   }
+
+   /*
+* pre-allocate a buffer to be filled by the driver
+* with ffa_partition_info structs
+*/
+
+   ffa_info("Pre-allocating %d partition(s) info structures", count);
+
+   parts_info = calloc(count, sizeof(struct ffa_partition_info));
+   if (!parts_info)
+   return -EINVAL;
+
+   size = count * sizeof(struct ffa_partition_info);
+
+   /*
+* ask the driver to fill the buffer with the SPs info
+*/
+
+   ret = ffa_bus_ops_get()->partition_info_get(argv[0], &size, parts_info);
+   if (ret != FFA_ERR_STAT_SUCCESS) {
+   ffa_err("Failure in querying partition(s) info (error code: 
%d)", ret);
+   free(parts_info);
+   return ret;
+   }
+
+   /*
+* SPs found , show the partition information
+*/
+   for (info_idx = 0; info_idx < count ; info_idx++) {
+   ffa_info("Partition: id = 0x%x , exec_ctxt 0x%x , properties 
0x%x",
+parts_info[info_idx].id,
+parts_info[info_idx].exec_ctxt,
+parts_info[info_idx].properties);
+   }
+
+   free(parts_info);
+
+   return 0;
+}
+
+/**
+ * do_ffa_msg_send_direct_req - implementation of the ping subcommand
+ * @cmdtp: Command Table
+ * @flag:  flags
+ * @argc:  number of arguments
+ * @argv:  arguments
+ *
+ * This function sends data to the secure partition 

[PATCH v3 3/4] arm_ffa: introduce Arm FF-A low-level driver

[Abdellatif El Khlifi]

Add the driver implementing Arm Firmware Framework for Armv8-A v1.0

The Firmware Framework for Arm A-profile processors (FF-A)
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.

This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.

32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP
and FFA_MSG_SEND_DIRECT_{REQ, RESP}.

In u-boot FF-A design, FF-A is considered as a discoverable bus.
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.

The driver exports its operations to be used by upper layers.

Exported operations:

- partition_info_get
- sync_send_receive
- rxtx_unmap

This implementation provides an optional feature to copy the driver data
to EFI runtime area.

Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Ilias Apalodimas 
Cc: Jens Wiklander 
---
 MAINTAINERS|6 +
 common/board_r.c   |7 +
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/arm-ffa/Kconfig|   33 +
 drivers/arm-ffa/Makefile   |7 +
 drivers/arm-ffa/arm-ffa-uclass.c   |   16 +
 drivers/arm-ffa/arm_ffa_prv.h  |  219 
 drivers/arm-ffa/core.c | 1338 
 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c |   94 ++
 include/arm_ffa.h  |  132 ++
 include/dm/uclass-id.h |1 +
 include/uuid.h |8 +
 lib/efi_loader/efi_boottime.c  |   17 +
 lib/uuid.c |   65 +
 15 files changed, 1946 insertions(+)
 create mode 100644 drivers/arm-ffa/Kconfig
 create mode 100644 drivers/arm-ffa/Makefile
 create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c
 create mode 100644 drivers/arm-ffa/arm_ffa_prv.h
 create mode 100644 drivers/arm-ffa/core.c
 create mode 100644 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c
 create mode 100644 include/arm_ffa.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f371d864f2..93a57f4df2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -248,6 +248,12 @@ F: drivers/net/cortina_ni.h
 F: drivers/net/phy/ca_phy.c
 F: configs/cortina_presidio-asic-pnand_defconfig
 
+ARM FF-A
+M: Abdellatif El Khlifi 
+S: Maintained
+F: drivers/arm-ffa/
+F: include/arm_ffa.h
+
 ARM FREESCALE IMX
 M: Stefano Babic 
 M: Fabio Estevam 
diff --git a/common/board_r.c b/common/board_r.c
index ed29069d2d..2d3f359b96 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -63,6 +63,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARM_FFA_TRANSPORT
+#include 
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 ulong monitor_flash_len;
@@ -767,6 +771,9 @@ static init_fnc_t init_sequence_r[] = {
INIT_FUNC_WATCHDOG_RESET
initr_net,
 #endif
+#ifdef CONFIG_ARM_FFA_TRANSPORT
+   ffa_bus_discover,
+#endif
 #ifdef CONFIG_POST
initr_post,
 #endif
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 8b6fead351..60b5fd4d9d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -6,6 +6,8 @@ source "drivers/core/Kconfig"
 
 source "drivers/adc/Kconfig"
 
+source "drivers/arm-ffa/Kconfig"
+
 source "drivers/ata/Kconfig"
 
 source "drivers/axi/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index eba9940231..dfde371381 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -110,6 +110,7 @@ obj-y += iommu/
 obj-y += smem/
 obj-y += thermal/
 obj-$(CONFIG_TEE) += tee/
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += arm-ffa/
 obj-y += axi/
 obj-y += ufs/
 obj-$(CONFIG_W1) += w1/
diff --git a/drivers/arm-ffa/Kconfig b/drivers/arm-ffa/Kconfig
new file mode 100644
index 00..882ffde90f
--- /dev/null
+++ b/drivers/arm-ffa/Kconfig
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config ARM_FFA_TRANSPORT
+   bool "Enable Arm Firmware Framework for Armv8-A driver"
+   depends on DM && ARM64
+   select ARM_SMCCC
+   select LIB_UUID
+   select DEVRES
+   help
+ The Firmware Framework for Arm A-profile processors (FF-A)
+ describes interfaces (ABIs) that standardize communication
+ between the Secure World and Normal World leveraging TrustZone
+ technology.
+
+ This driver is based on FF-A specification v1.0 and uses SMC32
+ calling convention.
+
+ FF-A specification:
+
+ https://developer.arm.com/documentation/den0077/a/?lang=en
+
+ In u-boot FF-A design, FF-A is considered as a discoverable bus.
+ The Secure World is considered as one entity to communicate with
+ 

[PATCH v3 2/4] arm64: smccc: clear the Xn registers after SMC calls

[Abdellatif El Khlifi]

set to zero the x0-x17 registers

As per the SMCCC v1.2 spec, unused result and scratch registers can leak
information after an SMC call. We can mitigate against this risk by
returning zero in each register.

Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Ilias Apalodimas 
Cc: Jens Wiklander 
---
 arch/arm/cpu/armv8/smccc-call.S | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
index ec6f299bc9..8ac3e461e4 100644
--- a/arch/arm/cpu/armv8/smccc-call.S
+++ b/arch/arm/cpu/armv8/smccc-call.S
@@ -84,6 +84,26 @@ ENDPROC(__arm_smccc_hvc)
stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
 
+   /* x0-x17 registers can leak information after an SMC or HVC call. 
Let's clear them */
+   mov x0, xzr
+   mov x1, xzr
+   mov x2, xzr
+   mov x3, xzr
+   mov x4, xzr
+   mov x5, xzr
+   mov x6, xzr
+   mov x7, xzr
+   mov x8, xzr
+   mov x9, xzr
+   mov x10, xzr
+   mov x11, xzr
+   mov x12, xzr
+   mov x13, xzr
+   mov x14, xzr
+   mov x15, xzr
+   mov x16, xzr
+   mov x17, xzr
+
/* Restore original x19 */
ldp xzr, x19, [sp], #16
ret
-- 
2.17.1

[PATCH v3 1/4] arm64: smccc: add Xn registers support used by SMC calls

[Abdellatif El Khlifi]

use x0-x17 registers in the SMC32/SMC64 calls according to SMCCCv1.2

Signed-off-by: Sudeep Holla 
Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Ilias Apalodimas 
Cc: Jens Wiklander 
---
 arch/arm/cpu/armv8/smccc-call.S | 53 +
 arch/arm/lib/asm-offsets.c  | 13 
 include/linux/arm-smccc.h   | 43 ++
 3 files changed, 109 insertions(+)

diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
index dc92b28777..ec6f299bc9 100644
--- a/arch/arm/cpu/armv8/smccc-call.S
+++ b/arch/arm/cpu/armv8/smccc-call.S
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright (c) 2015, Linaro Limited
+ * (C) Copyright 2022 ARM Limited
+ * Abdellatif El Khlifi 
  */
 #include 
 #include 
@@ -45,3 +47,54 @@ ENDPROC(__arm_smccc_smc)
 ENTRY(__arm_smccc_hvc)
SMCCC   hvc
 ENDPROC(__arm_smccc_hvc)
+
+#ifdef CONFIG_ARM64
+
+   .macro SMCCC_1_2 instr
+   /* Save `res` and free a GPR that won't be clobbered */
+   stp x1, x19, [sp, #-16]!
+
+   /* Ensure `args` won't be clobbered while loading regs in next step */
+   mov x19, x0
+
+   /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */
+   ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
+   ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
+   ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
+   ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
+   ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
+   ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
+   ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
+   ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
+   ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
+
+   \instr #0
+
+   /* Load the `res` from the stack */
+   ldr x19, [sp]
+
+   /* Store the registers x0 - x17 into the result structure */
+   stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
+   stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
+   stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
+   stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
+   stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
+   stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
+   stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
+   stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
+   stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
+
+   /* Restore original x19 */
+   ldp xzr, x19, [sp], #16
+   ret
+   .endm
+
+/*
+ * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
+ *   struct arm_smccc_1_2_regs *res);
+ */
+ENTRY(arm_smccc_1_2_smc)
+   SMCCC_1_2 smc
+ENDPROC(arm_smccc_1_2_smc)
+
+#endif
diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c
index 22fd541f9a..b6bd1b32b0 100644
--- a/arch/arm/lib/asm-offsets.c
+++ b/arch/arm/lib/asm-offsets.c
@@ -9,6 +9,8 @@
  * generate asm statements containing #defines,
  * compile this file to assembler, and then extract the
  * #defines from the assembly-language output.
+ *
+ * (C) Copyright 2022 ARM Limited
  */
 
 #include 
@@ -117,6 +119,17 @@ int main(void)
DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id));
DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, 
state));
+   #ifdef CONFIG_ARM64
+   DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS,  offsetof(struct 
arm_smccc_1_2_regs, a0));
+   DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS,  offsetof(struct 
arm_smccc_1_2_regs, a2));
+   DEFINE(ARM_SMCCC_1_2_REGS_X4_OFFS,  offsetof(struct 
arm_smccc_1_2_regs, a4));
+   DEFINE(ARM_SMCCC_1_2_REGS_X6_OFFS,  offsetof(struct 
arm_smccc_1_2_regs, a6));
+   DEFINE(ARM_SMCCC_1_2_REGS_X8_OFFS,  offsetof(struct 
arm_smccc_1_2_regs, a8));
+   DEFINE(ARM_SMCCC_1_2_REGS_X10_OFFS, offsetof(struct 
arm_smccc_1_2_regs, a10));
+   DEFINE(ARM_SMCCC_1_2_REGS_X12_OFFS, offsetof(struct 
arm_smccc_1_2_regs, a12));
+   DEFINE(ARM_SMCCC_1_2_REGS_X14_OFFS, offsetof(struct 
arm_smccc_1_2_regs, a14));
+   DEFINE(ARM_SMCCC_1_2_REGS_X16_OFFS, offsetof(struct 
arm_smccc_1_2_regs, a16));
+   #endif
 #endif
 
return 0;
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index e1d09884a1..9105031d55 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright (c) 2015, Linaro Limited
+ * (C) Copyright 2022 ARM Limited
+ * Abdellatif El Khlifi 
  */
 #ifndef __LINUX_ARM_SMCCC_H
 #define __LINUX_ARM_SMCCC_H
@@ -70,6 +72,47 @@ struct arm_smccc_res {
unsigned long a3;
 };
 
+#ifdef CONFIG_ARM64
+/**
+ * struct arm_smccc_1_2_regs - Arguments for or 

[PATCH v3 0/4] introduce Arm FF-A support

[Abdellatif El Khlifi]

This new version of the patchset provides improvements to the FF-A driver 
design.

The FF-A driver is a discoverable bus and brings these new features:

* support for the 64-bit x0-x17 registers in SMC arguments passing 
* align with the FF-A kernel driver interfaces
* make the driver EFI independent

This patchset will be followed by further updates (work in progress):

* discover MM partitions at runtime
* align with the FF-A kernel driver error handling
* align Sandbox driver and tests with the new interfaces

Changelog:
===

v3:

* port x0-x17 registers support from linux kernel as defined by SMCCCv1.2
* align the interfaces of the u-boot FF-A driver with those in the linux FF-A 
driver
* remove the FF-A helper layer
* make the u-boot FF-A driver independent from EFI
* provide an optional config that enables copying the driver data to EFI 
runtime section at ExitBootServices service
* use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
* update armffa command with the new driver interfaces

v2  [2]:

* make FF-A bus discoverable using device_{bind, probe} APIs
* remove device tree support

v1  [1]:

* introduce FF-A bus driver with device tree support
* introduce armffa command
* introduce FF-A Sandbox driver
* add FF-A Sandbox test cases
* introduce FF-A MM communication

Cheers,
Abdellatif

[1]: 
https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhl...@arm.com/
[2]: 
https://lore.kernel.org/all/20220415122803.1-1-abdellatif.elkhl...@arm.com/


Cc: Tom Rini 
Cc: Ilias Apalodimas 
Cc: Jens Wiklander 
Cc: Achin Gupta 
Cc: Vishnu Banavath 
Cc: Xueliang Zhong 

Abdellatif El Khlifi (4):
  arm64: smccc: add Xn registers support used by SMC calls
  arm64: smccc: clear the Xn registers after SMC calls
  arm_ffa: introduce Arm FF-A low-level driver
  arm_ffa: introduce armffa command

 MAINTAINERS|7 +
 arch/arm/cpu/armv8/smccc-call.S|   73 ++
 arch/arm/lib/asm-offsets.c |   13 +
 cmd/Kconfig|   10 +
 cmd/Makefile   |2 +
 cmd/armffa.c   |  246 
 common/board_r.c   |7 +
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/arm-ffa/Kconfig|   34 +
 drivers/arm-ffa/Makefile   |7 +
 drivers/arm-ffa/arm-ffa-uclass.c   |   16 +
 drivers/arm-ffa/arm_ffa_prv.h  |  219 
 drivers/arm-ffa/core.c | 1338 
 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c |   94 ++
 include/arm_ffa.h  |  132 ++
 include/dm/uclass-id.h |1 +
 include/linux/arm-smccc.h  |   43 +
 include/uuid.h |8 +
 lib/efi_loader/efi_boottime.c  |   17 +
 lib/uuid.c |   65 +
 21 files changed, 2335 insertions(+)
 create mode 100644 cmd/armffa.c
 create mode 100644 drivers/arm-ffa/Kconfig
 create mode 100644 drivers/arm-ffa/Makefile
 create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c
 create mode 100644 drivers/arm-ffa/arm_ffa_prv.h
 create mode 100644 drivers/arm-ffa/core.c
 create mode 100644 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c
 create mode 100644 include/arm_ffa.h

-- 
2.17.1

Re: Replace make-fit-atf.py with binman. Was: migrate u-boot-rockchip.bin to binman and generate an image for SPI

[Quentin Schulz]

Hi Simon,

On 7/31/22 03:27, Simon Glass wrote:

Hi Quentin,

On Wed, 27 Jul 2022 at 04:34, Quentin Schulz
 wrote:


Hi Simon,

On 7/26/22 21:58, Simon Glass wrote:

Hi Quentin,

On Tue, 26 Jul 2022 at 03:08, Quentin Schulz
 wrote:


Hi Xavier,

On 7/25/22 19:33, Xavier Drudis Ferran wrote:

El Mon, Jul 25, 2022 at 07:29:53PM +0200, Xavier Drudis Ferran deia:


I copy here the rockchip-u-boot.dtsi file and then 2 patches on top of yours.



Sorry I copied a dirty version that din't work. The patches were correct, the 
dtsi wasn't.



[..]




+};
+};
+};
+};
   simple-bin {
   filename = "u-boot-rockchip.bin";
   pad-byte = <0xff>;
@@ -62,6 +131,7 @@
#ifdef CONFIG_ARM64
   blob {
   filename = "u-boot.itb";
+


This is unfortunately not possible since binman parallelizes the build
of images in the binman DT node. This means there is no guarantee the
u-boot.itb file is generated before this section is worked on by binman.
Or maybe I misunderstood the docs.


You are correct, but this is something that has bothered me.

At the moment we handle this by embedding the definition for one file
into the one that uses it. This is on the theory that there is no need
to actually write the embedded file, since it is a temporary file. In
fact binman does generate temporary files though.

Is that good enough? If not I'd like to understand the need better,
before we make any changes.



For Rockchip, with the patch series from
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220722113505.3875669-2D1-2Dfoss-2Buboot-400leil.net_&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=OevHoqt3vOXsWmXfEPFnvZ2KSNns-ZKBiiZBUovrynOXVCUZtFfK9jsk3C1r4Y_J&s=nXnNRN3hfa_mkkt_suH6wLGbwj06I7HmQKcagZ6JPE0&e=
 ,
we now have two binaries:
u-boot-rockchip.bin and u-boot-rockchip-spi.bin

Both share the exact same u-boot.itb file (though at a different offset
in the storage medium) embedded.

This u-boot.itb is currently externally created via the Makefile +
make_fit_atf.py prior to binman being called. This allows us to have a
blob { filename = "u-boot.itb"; } in the binman DT node and that's
enough for it to work fine.

There's a desire to get rid of make_fit_atf.py in favor of binman. This
means that we need to create this file in binman now.

There's been some resistance to making binman not create idbloader.img
image in the patch series mentioned above (it is *technically* created
by binman but only in temporary files and then embedded in
u-boot-rockchip*.bin). I assume the same resistance will be met for
u-boot.itb.

With how binman works currently and since we have u-boot.itb content
embedded in at least two different images created by binman (might be
even more once there's USB/NAND support?), we'd need to have the fit
device tree node appear thrice (or more). One for u-boot.itb creation
(because of people not wanting it disappear from binaries generated by
U-Boot), one for embedding into u-boot-rockchip.bin and one for
embedding into u-boot-rockchip-spi.bin.
This increases the risk of not updating all fit device tree nodes at once.
This is suboptimal in terms of build time because the image will
effectively be created thrice (or more).
This is also not the best for easy check of reproducibility since the
content of the fit device tree node is technically not the same as
u-boot.itb file (because it is the result of a different image built by
binman).

So I think the minimal implementation would be to allow to define an
image/section (u-boot.itb) and to "#include" it inline in another
section (where blob { filename = "u-boot.itb"; } currently is for
u-boot-rockchip.bin and u-boot-rockchip-spi.bin). From reading the docs,
I expected collection entry to be exactly this? But I couldn't make it work.

Ideally, allowing binman to define a dependency from one image on
another would mean we could still use the blob image/section, but
safely, because the dependency is explicit so binman will know which
image to build first. Phandles is what we're after on the Device Tree
side I would assume. We could have something like: blob { image =
<&u-boot-itb>; } for example. No idea how binman would create this
dependency tree though :)

Straight from my brain, lemme know if something needs to be clarified or
rephrased.


Collections should allow this. Can you try running with threading
disabled (-T0)?



Do they?

What (I think) I want is basically the following:

&binman {
multiple-images;
u_boot_itb: u-boot-itb {
fit {};
};
simple-bin {
[...]
collection {
 content = <&u_boot_itb>;
};
};
simple-bin-spi {
[...]
collection {
 content = <&u_boot_itb>;
};
};
};

or I guess something like:
&binman {
multiple-images;
u-boot-itb {
   

Re: [PATCH v3 6/8] rockchip: simplify binman image dependencies addition to INPUTS

[Quentin Schulz]

HI all,

On 8/1/22 18:06, Quentin Schulz wrote:

From: Quentin Schulz 

By factoring SPL check in the first condition, this makes the checks a
bit less convoluted and more readable.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  Makefile | 9 ++---
  1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index f8e919e136..640d4b8f65 100644
--- a/Makefile
+++ b/Makefile
@@ -995,19 +995,14 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
  INPUTS-y += u-boot-with-dtb.bin
  endif
  
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)

-# On ARM64 this target is produced by binman so we don't need this dep
+ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
+# Binman image dependencies
  ifeq ($(CONFIG_ARM64),y)
-ifeq ($(CONFIG_SPL),y)
  INPUTS-y += u-boot.itb
  endif


This one should be moved


  else
-ifeq ($(CONFIG_SPL),y)
-# Generate these inputs for binman which will create the output files
  INPUTS-y += u-boot.img
  endif


down here to keep the same behavior. Will update for v4.

Cheers,
Quentin

[PATCH v3 8/8] rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash

[Quentin Schulz]

From: Quentin Schulz 

This new image is similar to u-boot-rockchip.bin except that it's
destined to be flashed on SPI-NOR flashes.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

v3:
 - added filename property so that idblaoder-spi.img binary is generated
 by binman, as per community request,
 - added new temporary files to the list of files to clean up on `make
 clean`,

 Makefile  |  3 ++-
 arch/arm/dts/rockchip-u-boot.dtsi | 30 ++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 640d4b8f65..6979dfb28d 100644
--- a/Makefile
+++ b/Makefile
@@ -2192,7 +2192,8 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h 
\
   idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
   itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
-  mkimage.rom.mkimage rom.map simple-bin.map
+  mkimage.rom.mkimage rom.map simple-bin.map simple-bin-spi.map \
+  idbloader-spi.img
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index f90a8bf085..584f21eb5b 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -39,5 +39,35 @@
offset = ;
};
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+   simple-bin-spi {
+   filename = "u-boot-rockchip-spi.bin";
+   pad-byte = <0xff>;
+
+   mkimage {
+   filename = "idbloader-spi.img";
+   args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
+#ifdef CONFIG_TPL
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+#endif
+   u-boot-spl {
+   };
+   };
+
+#ifdef CONFIG_ARM64
+   blob {
+   filename = "u-boot.itb";
+#else
+   u-boot-img {
+#endif
+   /* Sync with u-boot,spl-payload-offset if present */
+   offset = ;
+   };
+   };
+#endif
 };
 #endif
-- 
2.37.1

[PATCH v3 7/8] rockchip: allow to build SPI images even without HAS_ROM option

[Quentin Schulz]

From: Quentin Schulz 

This prepares for the creation of a u-boot-rockchip-spi.bin image
similar to u-boot-rockchip.bin to the exception it's destined for
SPI-NOR flashes instead of MMC storage medium.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 arch/arm/dts/rk3288-u-boot.dtsi | 2 +-
 arch/arm/dts/rk3399-u-boot.dtsi | 2 +-
 arch/arm/mach-rockchip/Kconfig  | 6 ++
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 9eb696b141..e411445ed6 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -56,7 +56,7 @@
};
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
rom {
filename = "u-boot.rom";
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 716b9a433a..3c1a15fe51 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -60,7 +60,7 @@
 
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
rom {
filename = "u-boot.rom";
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index c561a77e6a..b46cea2f91 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -425,12 +425,10 @@ config SPL_MMC
 
 config ROCKCHIP_SPI_IMAGE
bool "Build a SPI image for rockchip"
-   depends on HAS_ROM
help
  Some Rockchip SoCs support booting from SPI flash. Enable this
- option to produce a 4MB SPI-flash image (called u-boot.rom)
- containing U-Boot. The image is built by binman. U-Boot sits near
- the start of the image.
+ option to produce a SPI-flash image containing U-Boot. The image
+ is built by binman. U-Boot sits near the start of the image.
 
 config LNX_KRNL_IMG_TEXT_OFFSET_BASE
default SYS_TEXT_BASE
-- 
2.37.1

[PATCH v3 6/8] rockchip: simplify binman image dependencies addition to INPUTS

[Quentin Schulz]

From: Quentin Schulz 

By factoring SPL check in the first condition, this makes the checks a
bit less convoluted and more readable.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 Makefile | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index f8e919e136..640d4b8f65 100644
--- a/Makefile
+++ b/Makefile
@@ -995,19 +995,14 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
 INPUTS-y += u-boot-with-dtb.bin
 endif
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-# On ARM64 this target is produced by binman so we don't need this dep
+ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
+# Binman image dependencies
 ifeq ($(CONFIG_ARM64),y)
-ifeq ($(CONFIG_SPL),y)
 INPUTS-y += u-boot.itb
 endif
 else
-ifeq ($(CONFIG_SPL),y)
-# Generate these inputs for binman which will create the output files
 INPUTS-y += u-boot.img
 endif
-endif
-endif
 
 INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
-- 
2.37.1

[PATCH v3 5/8] rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards

[Quentin Schulz]

From: Quentin Schulz 

This allows to build u-boot-rockchip.bin binary with binman for Rockchip
ARM64 boards instead of the legacy Makefile way.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 Makefile  | 26 +-
 arch/arm/Kconfig  |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi |  5 +
 3 files changed, 7 insertions(+), 26 deletions(-)

diff --git a/Makefile b/Makefile
index ceb5b5e0d9..f8e919e136 100644
--- a/Makefile
+++ b/Makefile
@@ -999,8 +999,7 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
 # On ARM64 this target is produced by binman so we don't need this dep
 ifeq ($(CONFIG_ARM64),y)
 ifeq ($(CONFIG_SPL),y)
-# TODO: Get binman to generate this too
-INPUTS-y += u-boot-rockchip.bin
+INPUTS-y += u-boot.itb
 endif
 else
 ifeq ($(CONFIG_SPL),y)
@@ -1493,29 +1492,6 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
 u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE
$(call if_changed,pad_cat)
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-
-# TPL + SPL
-ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy)
-MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd
-tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE
-   $(call if_changed,mkimage)
-idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE
-   $(call if_changed,cat)
-else
-MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd
-idbloader.img: spl/u-boot-spl.bin FORCE
-   $(call if_changed,mkimage)
-endif
-
-ifeq ($(CONFIG_ARM64),y)
-OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
-   --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
-u-boot-rockchip.bin: idbloader.img u-boot.itb FORCE
-   $(call if_changed,pad_cat)
-endif # CONFIG_ARM64
-
-endif # CONFIG_ARCH_ROCKCHIP
 
 ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
 MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 949ebb46ba..c973146f8d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1974,7 +1974,7 @@ config ARCH_STM32MP
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select BLK
-   select BINMAN if SPL_OPTEE || (SPL && !ARM64)
+   select BINMAN if SPL_OPTEE || SPL
select DM
select DM_GPIO
select DM_I2C
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index ad72ca9700..f90a8bf085 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -30,7 +30,12 @@
};
};
 
+#ifdef CONFIG_ARM64
+   blob {
+   filename = "u-boot.itb";
+#else
u-boot-img {
+#endif
offset = ;
};
};
-- 
2.37.1

[PATCH v3 4/8] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

[Quentin Schulz]

From: Quentin Schulz 

idbloader.img content - currently created by way of Makefile - can be
created by binman directly.

So let's do that for Rockchip ARM platforms.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

v3:
 - moved spl back into mkimage section,
 - added filename property so that the idbloader.img binary is still
 generated,

 Makefile  |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi | 11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index bbb2a4c088..ceb5b5e0d9 100644
--- a/Makefile
+++ b/Makefile
@@ -1005,7 +1005,7 @@ endif
 else
 ifeq ($(CONFIG_SPL),y)
 # Generate these inputs for binman which will create the output files
-INPUTS-y += idbloader.img u-boot.img
+INPUTS-y += u-boot.img
 endif
 endif
 endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index eae3ee715d..ad72ca9700 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -17,8 +17,17 @@
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
 
-   blob {
+   mkimage {
filename = "idbloader.img";
+   args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+#ifdef CONFIG_TPL
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+#endif
+   u-boot-spl {
+   };
};
 
u-boot-img {
-- 
2.37.1

[PATCH v3 3/8] rockchip: remove binman temporary files when cleaning

[Quentin Schulz]

From: Quentin Schulz 

Binman mkimage entry generates temporary files so let's remove them
when calling `make clean`.

Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry")
Cc: Quentin Schulz 
Reported-by: Johan Jonker 
Signed-off-by: Quentin Schulz 
---

added in v3

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index ff25f92974..bbb2a4c088 100644
--- a/Makefile
+++ b/Makefile
@@ -2220,7 +2220,8 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h 
\
   lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
   idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
-  itb.fit.fit itb.fit.itb itb.map spl.map
+  itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
+  mkimage.rom.mkimage rom.map simple-bin.map
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \
-- 
2.37.1

[PATCH v3 2/8] binman: allow user-defined filenames for mkimage entry

[Quentin Schulz]

From: Quentin Schulz 

mkimage entry currently creates a file whose name is derived from the
section name containing said entry.

Let's allow the user to define a filename for the mkimage-generated
binary by using the 'filename' DT property.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

added in v3

 tools/binman/etype/mkimage.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 52297c23ea..902c254425 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -20,11 +20,13 @@ class Entry_mkimage(Entry):
   datafiles to mkimage instead of creating a temporary file the result
   of datafiles concatenation
 - args: Other arguments to pass
+- filename: filename of output binary generated by mkimage
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
 e.g.::
 
 mkimage {
+filename = "imximage.bin";
 args = "-n test -T imximage";
 
 u-boot-spl {
@@ -33,7 +35,7 @@ class Entry_mkimage(Entry):
 
 This calls mkimage to create an imximage with u-boot-spl.bin as the input
 file. The output from mkimage then becomes part of the image produced by
-binman.
+binman but also is written into imximage.bin file.
 
To pass all datafiles untouched to mkimage::
 
@@ -70,6 +72,7 @@ class Entry_mkimage(Entry):
 self._args = fdt_util.GetArgs(self._node, 'args')
 self._multiple_data_files = fdt_util.GetBool(self._node, 
'multiple-data-files')
 self._mkimage_entries = OrderedDict()
+self._filename = fdt_util.GetString(self._node, 'filename')
 self.align_default = None
 self.ReadEntries()
 
@@ -89,7 +92,7 @@ class Entry_mkimage(Entry):
 self._mkimage_entries.values(), 'mkimage', fake_size)
 if data is None:
 return False
-output_fname = tools.get_output_filename('mkimage-out.%s' % uniq)
+output_fname = tools.get_output_filename(self._filename if 
self._filename else 'mkimage-out.%s' % uniq)
 if self.mkimage.run_cmd('-d', input_fname, *self._args,
 output_fname) is not None:
 self.SetContents(tools.read_file(output_fname))
-- 
2.37.1

[PATCH v3 1/8] binman: add support for skipping file concatenation for mkimage

[Quentin Schulz]

From: Quentin Schulz 

Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.

That is the case for rkspi for example which requires page alignment
and only writing 2KB every 4KB.

This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.

Cc: Quentin Schulz 
Reviewed-by: Simon Glass 
Signed-off-by: Quentin Schulz 
---
 tools/binman/entries.rst  | 22 +++
 tools/binman/etype/mkimage.py | 41 +++
 2 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index ae4305c99e..60c89aec59 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1101,6 +1101,9 @@ Entry: mkimage: Binary produced by mkimage
 
 Properties / Entry arguments:
 - datafile: Filename for -d argument
+- multiple-data-files: boolean to tell binman to pass all files as
+  datafiles to mkimage instead of creating a temporary file the result
+  of datafiles concatenation
 - args: Other arguments to pass
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -1117,6 +1120,25 @@ This calls mkimage to create an imximage with 
u-boot-spl.bin as the input
 file. The output from mkimage then becomes part of the image produced by
 binman.
 
+To pass all datafiles untouched to mkimage::
+
+mkimage {
+args = "-n rk3399 -T rkspi";
+multiple-data-files;
+
+u-boot-tpl {
+};
+
+u-boot-spl {
+};
+};
+
+This calls mkimage to create a Rockchip RK3399-specific first stage
+bootloader, made of TPL+SPL. Since this first stage bootloader requires to
+align the TPL and SPL but also some weird hacks that is handled by mkimage
+directly, binman is told to not perform the concatenation of datafiles prior
+to passing the data to mkimage.
+
 To use CONFIG options in the arguments, use a string list instead, as in
 this example which also produces four arguments::
 
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 5f6def2287..52297c23ea 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -16,6 +16,9 @@ class Entry_mkimage(Entry):
 
 Properties / Entry arguments:
 - datafile: Filename for -d argument
+- multiple-data-files: boolean to tell binman to pass all files as
+  datafiles to mkimage instead of creating a temporary file the result
+  of datafiles concatenation
 - args: Other arguments to pass
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -32,6 +35,25 @@ class Entry_mkimage(Entry):
 file. The output from mkimage then becomes part of the image produced by
 binman.
 
+   To pass all datafiles untouched to mkimage::
+
+   mkimage {
+   args = "-n rk3399 -T rkspi";
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+
+   u-boot-spl {
+   };
+   };
+
+   This calls mkimage to create a Rockchip RK3399-specific first stage
+   bootloader, made of TPL+SPL. Since this first stage bootloader requires 
to
+   align the TPL and SPL but also some weird hacks that is handled by 
mkimage
+   directly, binman is told to not perform the concatenation of datafiles 
prior
+   to passing the data to mkimage.
+
 To use CONFIG options in the arguments, use a string list instead, as in
 this example which also produces four arguments::
 
@@ -46,16 +68,27 @@ class Entry_mkimage(Entry):
 def __init__(self, section, etype, node):
 super().__init__(section, etype, node)
 self._args = fdt_util.GetArgs(self._node, 'args')
+self._multiple_data_files = fdt_util.GetBool(self._node, 
'multiple-data-files')
 self._mkimage_entries = OrderedDict()
 self.align_default = None
 self.ReadEntries()
 
 def ObtainContents(self):
 # Use a non-zero size for any fake files to keep mkimage happy
-data, input_fname, uniq = self.collect_contents_to_file(
-self._mkimage_entries.values(), 'mkimage', 1024)
-if data is None:
-return False
+fake_size = 1024
+if self._multiple_data_files:
+fnames = []
+uniq = self.GetUniqueName()
+for entry in self._mkimage_entries.values():
+if not entry.ObtainContents(fake_size=fake_size):
+return False
+fnames.append(entry.GetDefaultFilename())
+input_fname = ":".join(fnames)
+else:
+data, input_fname, uniq = self.collect_contents_to_file(

[PATCH v3 0/8] migrate u-boot-rockchip.bin to binman and generate an image for SPI

[Quentin Schulz]

From: Quentin Schulz 

This migrates the generation of u-boot-rockchip.bin from Makefile to binman
completely.

This also adds support for generating the same kind of image than
u-boot-rockchip.bin but for SPI flashes (specifically, a different image
type generated by mkimage is necessary, in addition to a different
offset in the storage medium).

This has been tested on Puma RK3399 with patch series from 
https://lore.kernel.org/u-boot/20220722160655.3904213-1-foss+ub...@0leil.net/#b 
(plus 
https://lore.kernel.org/u-boot/20220722113505.3875669-4-foss+ub...@0leil.net/).

Cheers,
Quentin

v3:
 - removed
 https://lore.kernel.org/u-boot/20220722113505.3875669-4-foss+ub...@0leil.net/,
 it'll be added later on in a separate patch series,
 - added "binman: allow user-defined filenames for mkimage entry,"
 - kept idbloader.img binary creation even with binman as requested by
 community,
 - generate idbloader-spi.img binary with binman,
 - added "rockchip: remove binman temporary files when cleaning"

v2:
 - removed patch 4/8 rockchip: pad u-boot-rockchip.bin correctly because
 it would break partitions table,
 - rebased on top of master, changes to patch 3/7 rockchip: remove
 unneeded CONFIG_SPL_PAD_TO compared to the RFC 3/8 rockchip: remove
 unneeded CONFIG_SPL_PAD_TO,

Quentin Schulz (8):
  binman: add support for skipping file concatenation for mkimage
  binman: allow user-defined filenames for mkimage entry
  rockchip: remove binman temporary files when cleaning
  rockchip: generate idbloader.img content for u-boot-rockchip.bin with
binman for ARM
  rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards
  rockchip: simplify binman image dependencies addition to INPUTS
  rockchip: allow to build SPI images even without HAS_ROM option
  rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR
flash

 Makefile  | 41 +-
 arch/arm/Kconfig  |  2 +-
 arch/arm/dts/rk3288-u-boot.dtsi   |  2 +-
 arch/arm/dts/rk3399-u-boot.dtsi   |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi | 46 -
 arch/arm/mach-rockchip/Kconfig|  6 ++--
 tools/binman/entries.rst  | 22 ++
 tools/binman/etype/mkimage.py | 48 +++
 8 files changed, 121 insertions(+), 48 deletions(-)

-- 
2.37.1

Re: [PATCH 2/2] arm: mvebu: turris_omnia: Increase fdt size in fixup_mtd_partitions

[Marek Behún]

On Mon,  1 Aug 2022 12:02:20 +0200
Pali Rohár  wrote:

> Sometimes fixup_mtd_partitions() prints during booting kernel error
> "Failed fixing SPI NOR partitions!" because it does not have enough space
> for creating all paritions nodes. So increase fdt size.
> 
> Fixes: 92f36c8e74c1 ("arm: mvebu: turris_omnia: fixup MTD partitions in 
> Linux' DTB")
> Signed-off-by: Pali Rohár 

Reviewed-by: Marek Behún 

Re: [PATCH 1/2] arm: mvebu: turris_omnia: Do not fail in fixup_mtd_partitions when partitions do not exist

[Marek Behún]

On Mon,  1 Aug 2022 12:02:19 +0200
Pali Rohár  wrote:

> All partitions are created by fixup_mtd_partitions() function, so they do
> not have to exist just for their removal need.
> 
> Fixes: 92f36c8e74c1 ("arm: mvebu: turris_omnia: fixup MTD partitions in 
> Linux' DTB")
> Signed-off-by: Pali Rohár 

Reviewed-by: Marek Behún 

Re: [PATCH 2/2] arm: mvebu: turris_omnia: Add support for design with SW reset signals

[Marek Behún]

On Fri, 29 Jul 2022 13:29:07 +0200
Pali Rohár  wrote:

> New Turris Omnia HW board revision requires that software controls
> peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
> phy reset and lan switch reset. Those pins are connected to MCU controlled
> by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
> after board reset and software has to release these peripherals from reset
> manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
> CMD_GET_FEATURES command.
> 
> On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
> those reset signals are automatically released after board finish reset.
> 
> Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
> functions and insert into device tree blob pcie "reset-gpios" and eth phy
> "phy-reset-gpios" properties with corresponding MCU gpio definitions.
> PCIe and eth PHY drivers then automatically release resets during device
> initialization. Both U-Boot and Linux kernel drivers support those device
> tree reset properties.
> 
> Initialization of lan switch on new HW board revision is more complicated.
> Switch strapping pins are shared with switch RGMII pins. And strapping pins
> must be in specific configuration after releasing switch reset. Due to pin
> sharing, it is first required to switch A385 side of switch pins into GPIO
> mode, set strapping configuration, release switch from reset and after that
> switch A385 pins back to RGMII mode.
> 
> Because this complicated setup is not supported by switch DSA drivers and
> cannot be expressed easily in device tree, implement it manually in SPL
> function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
> switch initialized and be in same configuration like it was on old HW board
> revisions (where reset sequence did those steps at hardware level).
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Marek Behún 

Re: [PATCH 1/2] arm: mvebu: turris_omnia: Show MCU type in show_board_info()

[Marek Behún]

On Fri, 29 Jul 2022 13:29:06 +0200
Pali Rohár  wrote:

> Different Turris Omnia HW board revisions contains different MCU.
> Show type in show_board_info() to easily identify which MCU is populated.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Marek Behún 

[PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

[Pali Rohár]

Currently Makefile produces final mpc85xx image when SPL is not used in
custom file u-boot-with-dtb.bin. It is quite confusing name as build
process produce also intermediate file standard file u-boot-dtb.bin (which
is just intermediate and not bootable). Other platforms use u-boot.bin
(UBOOT_BIN) as standard name for final bootable raw image.

So change Makefile rules and binman to produce final bootable file for
mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
define default rule for u-boot.bin then instruct binman (via DTS file) to
store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
finally rename target u-boot-with-dtb.bin to u-boot.bin.

With this change are also removed custom Makefile hacks for mpc85xx that it
produced non-standard output file. And also updated documentation.

Signed-off-by: Pali Rohár 
---
 Makefile | 19 +--
 arch/powerpc/dts/kmcent2-u-boot.dtsi |  2 +-
 arch/powerpc/dts/u-boot.dtsi |  2 +-
 board/freescale/p1_p2_rdb_pc/README  |  2 +-
 board/freescale/p2041rdb/README  |  3 ---
 board/freescale/t102xrdb/README  |  2 +-
 board/freescale/t104xrdb/README  |  2 +-
 board/freescale/t208xqds/README  |  2 +-
 board/freescale/t208xrdb/README  |  2 +-
 9 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/Makefile b/Makefile
index dcfcd7ebd5d2..b1b08695cc47 100644
--- a/Makefile
+++ b/Makefile
@@ -991,10 +991,6 @@ ifeq ($(CONFIG_INIT_SP_RELATIVE)$(CONFIG_OF_SEPARATE),yy)
 INPUTS-y += init_sp_bss_offset_check
 endif
 
-ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-INPUTS-y += u-boot-with-dtb.bin
-endif
-
 ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
 # On ARM64 this target is produced by binman so we don't need this dep
 ifeq ($(CONFIG_ARM64),y)
@@ -1218,9 +1214,12 @@ else ifeq 
($(CONFIG_OF_SEPARATE).$(CONFIG_OF_OMIT_DTB),y.)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
+ifneq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
 u-boot.bin: u-boot-dtb.bin FORCE
$(call if_changed,copy)
-else
+endif
+
+else ifneq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
 u-boot.bin: u-boot-nodtb.bin FORCE
$(call if_changed,copy)
 endif
@@ -1433,11 +1432,7 @@ MKIMAGEFLAGS_u-boot-spl.kwb = -n $(KWD_CONFIG_FILE) \
 MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
-R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -A $(ARCH) -T 
pblimage
 
-ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-UBOOT_BIN := u-boot-with-dtb.bin
-else
 UBOOT_BIN := u-boot.bin
-endif
 
 MKIMAGEFLAGS_u-boot-lzma.img = -A $(ARCH) -T standalone -C lzma -O u-boot \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
@@ -1628,7 +1623,7 @@ u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp u-boot.img 
FORCE
 endif
 
 ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-u-boot-with-dtb.bin: u-boot-nodtb.bin u-boot.dtb \
+u-boot.bin: u-boot-nodtb.bin u-boot.dtb \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
$(call if_changed,binman)
 
@@ -1694,12 +1689,8 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
 ifeq ($(ARCH),arm)
 UBOOT_BINLOAD := u-boot.img
 else
-ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-UBOOT_BINLOAD := u-boot-with-dtb.bin
-else
 UBOOT_BINLOAD := u-boot.bin
 endif
-endif
 
 OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary 
--pad-to=$(CONFIG_SPL_PAD_TO) \
  --gap-fill=0xff
diff --git a/arch/powerpc/dts/kmcent2-u-boot.dtsi 
b/arch/powerpc/dts/kmcent2-u-boot.dtsi
index ab76a9f1226c..eeaa688b6577 100644
--- a/arch/powerpc/dts/kmcent2-u-boot.dtsi
+++ b/arch/powerpc/dts/kmcent2-u-boot.dtsi
@@ -76,7 +76,7 @@
};
 
binman {
-   filename = "u-boot-with-dtb.bin";
+   filename = "u-boot.bin";
skip-at-start = ;
sort-by-offset;
pad-byte = <0xff>;
diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
index 67de476a45ed..0251afddca82 100644
--- a/arch/powerpc/dts/u-boot.dtsi
+++ b/arch/powerpc/dts/u-boot.dtsi
@@ -7,7 +7,7 @@
 
 / {
binman {
-   filename = "u-boot-with-dtb.bin";
+   filename = "u-boot.bin";
skip-at-start = ;
sort-by-offset;
pad-byte = <0xff>;
diff --git a/board/freescale/p1_p2_rdb_pc/README 
b/board/freescale/p1_p2_rdb_pc/README
index 86ff04e69d97..f542decec79b 100644
--- a/board/freescale/p1_p2_rdb_pc/README
+++ b/board/freescale/p1_p2_rdb_pc/README
@@ -60,5 +60,5 @@ enabled in relative defconfig file,
CONFIG_RESET_VECTOR_ADDRESS - 0xffc
 
 If device tree support is enabled in defconfig,
-1. use 'u-boot-with-dtb.bin' for NOR boot.
+1. use 'u-boot.bin' for NOR boot.
 2. use 'u-boot-with-spl.bin' for other boot.
diff --git a/board/freescale/p2041rdb/README b/board/freescale/p2041rdb/README
index 79f77e496125..96612daeeb11 100644
--- a/board/freescale/p2041rdb/README

[PATCH 1/2] Makefile: Fix dependency for u-boot-with-dtb.bin

[Pali Rohár]

Makefile uses binman to produce u-boot-with-dtb.bin target. As its input it
takes DTB file and u-boot binary without DTB, which is stored in file
u-boot-nodtb.bin. So fix target dependency.

Signed-off-by: Pali Rohár 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index ff25f9297486..dcfcd7ebd5d2 100644
--- a/Makefile
+++ b/Makefile
@@ -1628,7 +1628,7 @@ u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp u-boot.img 
FORCE
 endif
 
 ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-u-boot-with-dtb.bin: u-boot.bin u-boot.dtb \
+u-boot-with-dtb.bin: u-boot-nodtb.bin u-boot.dtb \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
$(call if_changed,binman)
 
-- 
2.20.1

Re: [PATCH v1 2/2] cmd: fru: add product info area parsing support

[Jae Hyun Yoo]

On 8/1/2022 5:37 AM, Heinrich Schuchardt wrote:

On 7/29/22 23:54, Jae Hyun Yoo wrote:

Add product info area parsing support. Custom product info field parsing
function 'fru_parse_product_custom' can be replaced with a board specific
implementation.

Signed-off-by: Jae Hyun Yoo 
---
Changes from RFC:
  * Added manufacturer custom product info fields parsing flow.


Please, provide a unit test for the new functions.


I'll add a unit test in the next spin.

Best Regards,
Jae

Re: [PATCH v1 1/2] cmd: fru: move FRU handling support to common region

[Jae Hyun Yoo]

On 8/1/2022 5:34 AM, Heinrich Schuchardt wrote:

On 7/29/22 23:54, Jae Hyun Yoo wrote:

From: Graeme Gregory 

The FRU handling was added as a Xilinx board dependent support but it
would be useful for other boards too, so this commit moves the FRU
handling support to the common region so that it can be enabled by
CONFIG_CMD_FRU.

To provide manufacturer specific custom board info field parsing,
it defines 'fru_parse_board_custom' as a weak function so that it can
be replaced with the board specific implementation. In the same way,
OEM Multirecord type (0xc0 - 0xff) parsing logic can be replaced with
a board specific 'fru_parse_multirec' implementation.

Signed-off-by: Graeme Gregory 
Signed-off-by: Jae Hyun Yoo 


Your patchset lacks documentation.

Please, add a man-page in doc/usage/cmd/fru.rst.


Okay. I'll add a man-page in v2.


---
Changes from RFC:
  * Made FRU typecode string table as a generic and sharable table. 
(Michal)
  * Made OEM multirecord parsing call happen only on customizable type 
IDs.

    (Michal)
  * Added manufacturer custom board info fields parsing flow. (Michal)

  board/xilinx/Kconfig  |   8 --
  board/xilinx/common/Makefile  |   3 -
  board/xilinx/common/board.c   | 108 +--
  cmd/Kconfig   |   8 ++
  cmd/Makefile  |   1 +
  {board/xilinx/common => cmd}/fru.c    |   5 +-
  common/Makefile   |   2 +
  {board/xilinx/common => common}/fru_ops.c | 126 ++


Why should this live in common/. lib/ would make more sense.


Right, lib/ would be a right place. Will fix it in v2.

[...]


diff --git a/cmd/Kconfig b/cmd/Kconfig
index a8260aa170d0..644c907bf83a 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1053,6 +1053,14 @@ config CMD_FPGAD
    fpga_get_reg() function. This functions similarly to the 'md'
    command.

+config CMD_FRU
+    bool "FRU information for product"
+    help
+  This option enables FRU commands to capture and display FRU
+  information present in the device. The FRU Information is used
+  to primarily to provide "inventory" information about the boards
+  that the FRU Information Device is located on.


Don't assume that a user knows what that FRU abbreviation stands for.
Should it relate to a Field Replaceable Unit, please, write once the
full text.


Right, it relates to a Field Replaceable Unit. I'll add the full text in
the next spin.


Which revision of the IPMI Storage FRU Layout does it support?


It supports v1.0.
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-platform-mgt-fru-info-storage-def-v1-0-rev-1-3-spec-update.pdf

Will add this link into commit message.


Where is the unit test for the command?


I'll add a unit test in v2.

Best Regards,
Jae

Re: [PATCH 5/5] dm: rtc: Try to handle the localtime() race

[Heinrich Schuchardt]

On 8/1/22 15:58, Simon Glass wrote:

At present the sandbox timer uses localtime() which can jump around twice
a year when daylight-saving time changes.

It would be tricky to make use of gmtime() since we still need to present
the time in local time, as seems to be required by U-Boot's RTC interface.

The problem can only happen once, so use a loop to detect it and try
again. This should be sufficient to detect either a change in the 'second'
value, or a daylight-saving change. We can assume that the latter also
incorporates a 'second' change, so there is no need to loop more than
twice.

Signed-off-by: Simon Glass 


Linux systems tend to use UTC on the RTC. There is no reason for
sandbox_defconfig to deviate. Please, avoid all this complication by
reading the time with gmtime() instead of localtime().

Best regards

Heinrich


---

  test/dm/rtc.c | 32 +++-
  1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index 50086ffcf36..bf97dbbd2f9 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -252,6 +252,7 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
struct rtc_time now;
struct udevice *dev, *emul;
long old_base_time, base_time;
+   int i;

ut_assertok(uclass_get_device(UCLASS_RTC, 0, &dev));
ut_assertok(dm_rtc_get(dev, &now));
@@ -259,19 +260,24 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
ut_assertok(i2c_emul_find(dev, &emul));
ut_assertnonnull(emul);

-   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
-
-   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
-
-   /*
-* Resetting the RTC should put the base time back to normal. Allow for
-* a one-second adjustment in case the time flips over while this
-* test process is pre-empted, since reset_time() in i2c_rtc_emul.c
-* reads the time from the OS.
-*/
-   ut_assertok(dm_rtc_reset(dev));
-   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
-   ut_assert(base_time - old_base_time <= 1);
+   i = 0;
+   do {
+   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
+
+   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
+
+   ut_assertok(dm_rtc_reset(dev));
+   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
+
+   /*
+* Resetting the RTC should put the base time back to normal.
+* Allow for a one-timeadjustment in case the time flips over
+* while this test process is pre-empted (either by a second
+* or a daylight-saving change), since reset_time() in
+* i2c_rtc_emul.c reads the time from the OS.
+*/
+   } while (++i < 2 && base_time != old_base_time);
+   ut_asserteq(old_base_time, base_time);

return 0;
  }

Re: [PATCH] dm: rtc: Avoid a race in the rtc_reset test

[Heinrich Schuchardt]

On 8/1/22 15:59, Simon Glass wrote:

Hi Heinrich,

On Mon, 1 Aug 2022 at 02:11, Heinrich Schuchardt  wrote:


On 7/31/22 20:27, Simon Glass wrote:

Since resetting the RTC on sandbox causes it to read the base time from
the system, we cannot rely on this being unchanged since it was last read.
Allow for a one-second delay.

Fixes: https://source.denx.de/u-boot/u-boot/-/issues/4
Reported-by: Bin Meng 
Reported-by: Tom Rini 
Suggested-by: Rasmus Villemoes 
Signed-off-by: Simon Glass 
---

   test/dm/rtc.c | 11 ---
   1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index c7f9f8f0ce7..403bf5c640a 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -245,16 +245,21 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
   ut_assertok(dm_rtc_get(dev, &now));

   ut_assertok(i2c_emul_find(dev, &emul));
- ut_assert(emul != NULL);
+ ut_assertnonnull(emul);


This is an unrelated change. It would be preferable to describe it in
the commit message.



   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);

   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));

- /* Resetting the RTC should put he base time back to normal */
+ /*
+  * Resetting the RTC should put the base time back to normal. Allow for
+  * a one-second adjustment in case the time flips over while this
+  * test process is pre-empted, since reset_time() in i2c_rtc_emul.c
+  * reads the time from the OS.
+  */
   ut_assertok(dm_rtc_reset(dev));
   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
- ut_asserteq(old_base_time, base_time);
+ ut_assert(base_time - old_base_time <= 1);


If the operating system uses daylight saving time, this may still fail
(very rarely).

How about using gmtime() instead of localtime()? But that would be a
separate patch.


I'm not sure how to do this, as U-Boot expects local time. Of course
we could enhance the rtc API to support both (and use gmtime for the


What makes you think that U-Boot expects local time? U-Boot has no
notion of time zones. Linux systems tend to use UTC on the RTC. Why
should sandbox_defconfig deviate?

$ sudo hwclock --show -v
hwclock from util-linux 2.38
System Time: 1659365754.792540
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.

If you dual boot into Windows, you should better adjust Windows to use UTC.

Best regards

Heinrich


test).

I've got an idea how to deal with daylight savings, and an alternative
approach for this patch, so will send a series.



Reviewed-by: Heinrich Schuchardt 



   return 0;
   }




Regards,
Simon

Re: [PATCH v1 0/2] cmd/fru: move FRU handling support to common region

[Jae Hyun Yoo]

Hi Michal,

On 8/1/2022 3:29 AM, Michal Simek wrote:



On 7/29/22 23:54, Jae Hyun Yoo wrote:

Hello,

The FRU handling was added as a Xilinx board dependent support but it
would be useful for other boards too, so this commit moves the FRU
handling support to the common region so that it can be enabled by
CONFIG_CMD_FRU.

To provide manufacturer specific custom board info field parsing,
it defines 'fru_parse_board_custom' as a weak function so that it can
be replaced with the board specific implementation. In the same way,
OEM Multirecord type (0xc0 - 0xff) parsing logic can be replaced with
a board specific 'fru_parse_multirec' implementation.

Also, this series adds 'Product Info' parsing support.

Please review!


In general I am fine with this but I want this to be done in steps to be 
able to better review it.
It means couple of preparation patches before this is moved to generic 
location.
Moving that part of xilinx private structure of board info as one step, 
multirecord OEM entries another one, etc.


Sure, I'll split them into individual patches in v2.

Thanks,
Jae

Re: [PATCH 1/1] fs/erofs: silence erofs_probe()

[Huang Jianan]

在 2022年8月1日星期一，Heinrich Schuchardt  写道：

> fs_set_blk_dev() probes all file-systems until it finds one that matches
> the volume. We do not expect any console output for non-matching
> file-systems.
>
> Convert error messages in erofs_read_superblock() to debug output.
>
> Fixes: 830613f8f5bb ("fs/erofs: add erofs filesystem support")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 
> ---
> v2:
> keep erofs_err() for block size mismatch
> ---
>  fs/erofs/super.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)


Looks good to me.
Reviewed-by: Huang Jianan 

Thanks,
Jianan

>
> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> index 4cca322b9e..8277d9b53f 100644
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@ -65,14 +65,14 @@ int erofs_read_superblock(void)
>
> ret = erofs_blk_read(data, 0, 1);
> if (ret < 0) {
> -   erofs_err("cannot read erofs superblock: %d", ret);
> +   erofs_dbg("cannot read erofs superblock: %d", ret);
> return -EIO;
> }
> dsb = (struct erofs_super_block *)(data + EROFS_SUPER_OFFSET);
>
> ret = -EINVAL;
> if (le32_to_cpu(dsb->magic) != EROFS_SUPER_MAGIC_V1) {
> -   erofs_err("cannot find valid erofs superblock");
> +   erofs_dbg("cannot find valid erofs superblock");
> return ret;
> }
>
> --
> 2.36.1
>
>

Re: [PATCH] MAINTAINERS: Change POWERPC MPC85XX maintainer to Marek Behún

[Tom Rini]

On Mon, Jul 25, 2022 at 05:06:15PM +0200, Marek Behún wrote:

> After a discussion with Tom Rini, we've agreed that I am going to take
> over custodianship of the MPC85XX platform, since it seems other people
> do not have necessary interest or time and getting things done over
> there takes too long.
> 
> Since I am only working on one MPC85XX board, Turris 1.x, and do not
> have time to do thorough reviews of patches for this entire platform
> (other than those concerning Turris 1.x board), for other boards I will
> only run patches through CI and checkpatch, and then send them via PR
> upwards to Tom.
> 
> Signed-off-by: Marek Behún 
> Acked-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 0/7] Add support for cyclic function execution infrastruture

[Stefan Roese]

Hi Simon,

On 01.08.22 15:00, Simon Glass wrote:

Hi Stefan,

On Mon, 1 Aug 2022 at 06:40, Stefan Roese  wrote:


Hi Simon,

On 01.08.22 14:22, Simon Glass wrote:

Hi Stefan,

On Mon, 1 Aug 2022 at 01:17, Stefan Roese  wrote:


Hi Simon,

On 31.07.22 03:27, Simon Glass wrote:

Hi Stefan,

On Thu, 28 Jul 2022 at 01:09, Stefan Roese  wrote:


This patchset adds the basic infrastructure to periodically execute
code, e.g. all 100ms. Examples for such functions might be LED blinking
etc. The functions that are hooked into this cyclic list should be
small timewise as otherwise the execution of the other code that relies
on a high frequent polling (e.g. UART rx char ready check) might be
delayed too much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.

How is this cyclic functionality executed?
This patchset integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.

This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.

Ideas how to continue:
One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
move the watchdog_reset call into this cyclic infrastructure as well.
Or to perhaps move the shell UART RX ready polling to a cyclic
function.

It's also possible to extend the "cyclic" command, to support the
creation of periodically executed shell commands (for testing etc).

Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results

Thanks,
Stefan

Aaron Williams (1):
 mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure

Stefan Roese (6):
 time: Import time_after64() and friends from Linux
 cyclic: Add basic support for cyclic function execution infrastruture
 cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
 cyclic: Integrate cyclic functionality at bootup in board_r/f
 cyclic: Add 'cyclic list' command
 sandbox: Add cyclic demo function

MAINTAINERS|   7 +
board/Marvell/octeon_nic23/board.c | 197 +
board/sandbox/sandbox.c|  15 +++
cmd/Kconfig|   7 +
cmd/Makefile   |   1 +
cmd/cyclic.c   |  40 ++
common/Kconfig |  20 +++
common/Makefile|   1 +
common/board_f.c   |   2 +
common/board_r.c   |   2 +
common/cyclic.c| 112 
configs/octeon_nic23_defconfig |   3 +
configs/sandbox_defconfig  |   3 +
fs/cramfs/uncompress.c |   2 +-
include/cyclic.h   |  97 ++
include/time.h |  19 +++
include/watchdog.h |  23 +++-
17 files changed, 547 insertions(+), 4 deletions(-)
create mode 100644 cmd/cyclic.c
create mode 100644 common/cyclic.c
create mode 100644 include/cyclic.h

--
2.37.1



This looks interesting. I like the idea of integrating the watchdog
stuff too, since you are making use of it.

Would it make sense to make use of the new event system, since it has
static and dynamic handlers?


IIRC, I tried to make use of this infrastructure but it did not work
out. Or do you see some way to integrate this cyclic IF into the
event system? FWICT, the only way to get this done is to make use of
the (ugly) WATCHDOG_RESET calls.


Yes that makes sense. I don't see another way.

But within that, one option would be to send an event every time
WATCHDOG_RESET is used, and have things register as an event spy, thus
making use of that existing system. The event feature is not enabled
by default, but it could be enabled when this functionality is needed.


I still need to double-check, sorry: You are thinking about this call-
trace:

WATCHDOG_RESET -> event IF -> cylic IF -> cylic user



More this, i.e. I am wondering if the cyclic functionality can be done
using events.

WATCHDOG_RESET -> sends watchdog event -> event spy receives event


This would mean in the end, that all U-Boot targets would need to
enable the event subsystem as well. This might lead to problems with
image sizes on some of those especially old/ancient targets. Hmmm...


?

If yes, what would be the advantage(s) against implementing this
separately?


It would need handling of max CPU time and perhaps some other tweaks,
but it would result in less code (?) and one less thing for people to
learn. The cyclic comman

Re: [PATCH 1/5] arm: bcmbca: add bcm63178 SoC support

[Tom Rini]

On Fri, Jul 29, 2022 at 12:48:43PM -0700, William Zhang wrote:

> BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
> (Broadband Carrier Access origin) chipset family so it's added under
> ARCH_BCMBCA platform. This initial support includes a bare-bone
> implementation and dts with CPU subsystem, memory and ARM PL011 uart.
> 
> This SoC is supported in the linux-next git repository so the dts and
> dtsi files are copied from linux with minor fix-up that needs to be
> upstreamed to linux as well.
> 
> The u-boot image can be loaded from flash or network to the entry
> point address in the memory and boot from there.
> 
> Signed-off-by: William Zhang 
[snip]
> diff --git a/include/configs/bcm963178.h b/include/configs/bcm963178.h
> new file mode 100644
> index ..3ee2011b3a2d
> --- /dev/null
> +++ b/include/configs/bcm963178.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2022 Broadcom Ltd.
> + */
> +
> +#ifndef __BCM963178_H
> +#define __BCM963178_H
> +
> +#define CONFIG_SYS_SDRAM_BASE0x
> +#define COUNTER_FREQUENCY5000
> +
> +#endif

The one problem I have is that we need to put COUNTER_FREQUENCY
somewhere else, if it needs to be defined.  I see the top-level README
has outdated information about COUNTER_FREQUENCY, which is most often
CONFIG_COUNTER_FREQUENCY instead, as well.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] dm: rtc: Avoid a race in the rtc_reset test

[Simon Glass]

Hi Heinrich,

On Mon, 1 Aug 2022 at 02:11, Heinrich Schuchardt  wrote:
>
> On 7/31/22 20:27, Simon Glass wrote:
> > Since resetting the RTC on sandbox causes it to read the base time from
> > the system, we cannot rely on this being unchanged since it was last read.
> > Allow for a one-second delay.
> >
> > Fixes: https://source.denx.de/u-boot/u-boot/-/issues/4
> > Reported-by: Bin Meng 
> > Reported-by: Tom Rini 
> > Suggested-by: Rasmus Villemoes 
> > Signed-off-by: Simon Glass 
> > ---
> >
> >   test/dm/rtc.c | 11 ---
> >   1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/test/dm/rtc.c b/test/dm/rtc.c
> > index c7f9f8f0ce7..403bf5c640a 100644
> > --- a/test/dm/rtc.c
> > +++ b/test/dm/rtc.c
> > @@ -245,16 +245,21 @@ static int dm_test_rtc_reset(struct unit_test_state 
> > *uts)
> >   ut_assertok(dm_rtc_get(dev, &now));
> >
> >   ut_assertok(i2c_emul_find(dev, &emul));
> > - ut_assert(emul != NULL);
> > + ut_assertnonnull(emul);
>
> This is an unrelated change. It would be preferable to describe it in
> the commit message.
>
> >
> >   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
> >
> >   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
> >
> > - /* Resetting the RTC should put he base time back to normal */
> > + /*
> > +  * Resetting the RTC should put the base time back to normal. Allow 
> > for
> > +  * a one-second adjustment in case the time flips over while this
> > +  * test process is pre-empted, since reset_time() in i2c_rtc_emul.c
> > +  * reads the time from the OS.
> > +  */
> >   ut_assertok(dm_rtc_reset(dev));
> >   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
> > - ut_asserteq(old_base_time, base_time);
> > + ut_assert(base_time - old_base_time <= 1);
>
> If the operating system uses daylight saving time, this may still fail
> (very rarely).
>
> How about using gmtime() instead of localtime()? But that would be a
> separate patch.

I'm not sure how to do this, as U-Boot expects local time. Of course
we could enhance the rtc API to support both (and use gmtime for the
test).

I've got an idea how to deal with daylight savings, and an alternative
approach for this patch, so will send a series.

>
> Reviewed-by: Heinrich Schuchardt 
>
> >
> >   return 0;
> >   }
>

Regards,
Simon

[PATCH 5/5] dm: rtc: Try to handle the localtime() race

[Simon Glass]

At present the sandbox timer uses localtime() which can jump around twice
a year when daylight-saving time changes.

It would be tricky to make use of gmtime() since we still need to present
the time in local time, as seems to be required by U-Boot's RTC interface.

The problem can only happen once, so use a loop to detect it and try
again. This should be sufficient to detect either a change in the 'second'
value, or a daylight-saving change. We can assume that the latter also
incorporates a 'second' change, so there is no need to loop more than
twice.

Signed-off-by: Simon Glass 
---

 test/dm/rtc.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index 50086ffcf36..bf97dbbd2f9 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -252,6 +252,7 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
struct rtc_time now;
struct udevice *dev, *emul;
long old_base_time, base_time;
+   int i;
 
ut_assertok(uclass_get_device(UCLASS_RTC, 0, &dev));
ut_assertok(dm_rtc_get(dev, &now));
@@ -259,19 +260,24 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
ut_assertok(i2c_emul_find(dev, &emul));
ut_assertnonnull(emul);
 
-   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
-
-   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
-
-   /*
-* Resetting the RTC should put the base time back to normal. Allow for
-* a one-second adjustment in case the time flips over while this
-* test process is pre-empted, since reset_time() in i2c_rtc_emul.c
-* reads the time from the OS.
-*/
-   ut_assertok(dm_rtc_reset(dev));
-   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
-   ut_assert(base_time - old_base_time <= 1);
+   i = 0;
+   do {
+   old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
+
+   ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
+
+   ut_assertok(dm_rtc_reset(dev));
+   base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
+
+   /*
+* Resetting the RTC should put the base time back to normal.
+* Allow for a one-timeadjustment in case the time flips over
+* while this test process is pre-empted (either by a second
+* or a daylight-saving change), since reset_time() in
+* i2c_rtc_emul.c reads the time from the OS.
+*/
+   } while (++i < 2 && base_time != old_base_time);
+   ut_asserteq(old_base_time, base_time);
 
return 0;
 }
-- 
2.37.1.455.g008518b4e5-goog

[PATCH 4/5] dm: rtc: Try to avoid a race in rtc_set_get test

[Simon Glass]

It seems that the time can change in between getting it and reading the
offset. Check for this and try again if this happens.

Signed-off-by: Simon Glass 
---

 test/dm/rtc.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index e23905b3e2e..50086ffcf36 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -60,16 +60,27 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
 {
struct rtc_time now, time, cmp;
struct udevice *dev, *emul;
-   long offset, old_offset, old_base_time;
+   long offset, check_offset, old_offset, old_base_time;
+   int i;
 
ut_assertok(uclass_get_device(UCLASS_RTC, 0, &dev));
-   ut_assertok(dm_rtc_get(dev, &now));
 
ut_assertok(i2c_emul_find(dev, &emul));
ut_assertnonnull(emul);
 
-   /* Tell the RTC to go into manual mode */
-   old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
+   /* Get the offset, putting the RTC into manual mode */
+   i = 0;
+   do {
+   check_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
+   ut_assertok(dm_rtc_get(dev, &now));
+
+   /* Tell the RTC to go into manual mode */
+   old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
+
+   /* If the times changed in that period, read it again */
+   } while (++i < 2 && check_offset != old_offset);
+   ut_asserteq(check_offset, old_offset);
+
old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
 
memset(&time, '\0', sizeof(time));
@@ -127,7 +138,8 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
ut_asserteq(now.tm_sec + 1, cmp.tm_sec);
}
 
-   old_offset = sandbox_i2c_rtc_set_offset(emul, true, 0);
+   /* return RTC to normal mode */
+   sandbox_i2c_rtc_set_offset(emul, true, 0);
 
return 0;
 }
-- 
2.37.1.455.g008518b4e5-goog

[PATCH 3/5] dm: rtc: Avoid a race in the rtc_reset test

[Simon Glass]

Since resetting the RTC on sandbox causes it to read the base time from
the system, we cannot rely on this being unchanged since it was last read.
Allow for a one-second delay.

Reviewed-by: Heinrich Schuchardt 
Fixes: https://source.denx.de/u-boot/u-boot/-/issues/4
Reported-by: Bin Meng 
Reported-by: Tom Rini 
Suggested-by: Rasmus Villemoes 
Signed-off-by: Simon Glass 
---

 test/dm/rtc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index a8349756c18..e23905b3e2e 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -251,10 +251,15 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
 
ut_asserteq(0, sandbox_i2c_rtc_get_set_base_time(emul, -1));
 
-   /* Resetting the RTC should put he base time back to normal */
+   /*
+* Resetting the RTC should put the base time back to normal. Allow for
+* a one-second adjustment in case the time flips over while this
+* test process is pre-empted, since reset_time() in i2c_rtc_emul.c
+* reads the time from the OS.
+*/
ut_assertok(dm_rtc_reset(dev));
base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
-   ut_asserteq(old_base_time, base_time);
+   ut_assert(base_time - old_base_time <= 1);
 
return 0;
 }
-- 
2.37.1.455.g008518b4e5-goog

[PATCH 2/5] test: Allow running tests multiple times

[Simon Glass]

Some tests can have race conditions which are hard to detect on a single
one. Add a way to run tests more than once, to help with this.

Each individual test is run the requested number of times before moving
to the next test. If any runs failed, a message is shown.

This is most useful when running a single test, since running all tests
multiple times can take a while.

Signed-off-by: Simon Glass 
---

 arch/sandbox/cpu/spl.c|  2 +-
 doc/develop/tests_sandbox.rst | 24 
 include/test/test.h   |  2 ++
 include/test/ut.h |  3 ++-
 test/cmd_ut.c | 12 ++--
 test/dm/test-dm.c | 13 ++---
 test/test-main.c  | 14 +++---
 7 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index fe5d44d36ed..1d49a9bd102 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -89,7 +89,7 @@ void spl_board_init(void)
int ret;
 
ret = ut_run_list("spl", NULL, tests, count,
- state->select_unittests);
+ state->select_unittests, 1);
/* continue execution into U-Boot */
}
 }
diff --git a/doc/develop/tests_sandbox.rst b/doc/develop/tests_sandbox.rst
index 40cf8ecdd7f..8e42a32afb9 100644
--- a/doc/develop/tests_sandbox.rst
+++ b/doc/develop/tests_sandbox.rst
@@ -119,6 +119,30 @@ You can easily use gdb on these tests, without needing 
--gdbserver::
 You can then single-step and look at variables as needed.
 
 
+Running tests multiple times
+
+
+Some tests can have race conditions which are hard to detect on a single
+one. It is possible to run each individual test multiple times, before moving
+to the next test, with the '-r' flag.
+
+This is most useful when running a single test, since running all tests
+multiple times can take a while.
+
+For example::
+
+   => ut dm -r1000 dm_test_rtc_set_get
+   ...
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   Test: dm_test_rtc_set_get: rtc.c
+   test/dm/rtc.c:257, dm_test_rtc_reset(): old_base_time == base_time: 
Expected 0x62e7453c (1659323708), got 0x62e7453d (1659323709)
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   Test: dm_test_rtc_set_get: rtc.c
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   ...
+   Test dm_test_rtc_reset failed 3 times
+
+
 Running sandbox_spl tests directly
 --
 
diff --git a/include/test/test.h b/include/test/test.h
index 0104e189f63..66fece48b2a 100644
--- a/include/test/test.h
+++ b/include/test/test.h
@@ -20,6 +20,7 @@
  * @testdev: Test device
  * @force_fail_alloc: Force all memory allocs to fail
  * @skip_post_probe: Skip uclass post-probe processing
+ * @runs_per_test: Number of times to run each test (typically 1)
  * @expect_str: Temporary string used to hold expected string value
  * @actual_str: Temporary string used to hold actual string value
  */
@@ -32,6 +33,7 @@ struct unit_test_state {
struct udevice *testdev;
int force_fail_alloc;
int skip_post_probe;
+   int runs_per_test;
char expect_str[512];
char actual_str[512];
 };
diff --git a/include/test/ut.h b/include/test/ut.h
index 18740f5807c..f7d1d18f7c1 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -403,9 +403,10 @@ void test_set_state(struct unit_test_state *uts);
  * @count: Number of tests to run
  * @select_name: Name of a single test to run (from the list provided). If NULL
  * then all tests are run
+ * @runs_per_test: Number of times to run each test (typically 1)
  * Return: 0 if all tests passed, -1 if any failed
  */
 int ut_run_list(const char *name, const char *prefix, struct unit_test *tests,
-   int count, const char *select_name);
+   int count, const char *select_name, int runs_per_test);
 
 #endif
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 3789c6b784c..11c219b48ac 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -18,10 +18,17 @@ int cmd_ut_category(const char *name, const char *prefix,
struct unit_test *tests, int n_ents,
int argc, char *const argv[])
 {
+   int runs_per_text = 1;
int ret;
 
+   if (argc > 1 && !strncmp("-r", argv[1], 2)) {
+   runs_per_text = dectoul(argv[1] + 2, NULL);
+   argv++;
+   argc++;
+   }
+
ret = ut_run_list(name, prefix, tests, n_ents,
- argc > 1 ? argv[1] : NULL);
+ argc > 1 ? argv[1] : NULL, runs_per_text);
 
return ret ? CMD_RET_FAILURE : 0;
 }
@@ -168,7 +175,8 @@ static char ut_help_text[] =
 #ifdef CONFIG_CMD_LOADM
"ut loadm [test-name]- test of parameters and load memory blob\n"
 #endif
-   ;
+   "All commands accept an optional [-r] flag before [test-name], 
to\n"
+   "run each test multiple times ( is in dec

[PATCH 1/5] dm: rtc: Make use of ut_assertnonnull()

[Simon Glass]

Use this (newish) macro since it is designed for the purpose of making
sure things are non-NULL.

Signed-off-by: Simon Glass 
---

 test/dm/rtc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index c7f9f8f0ce7..a8349756c18 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -66,7 +66,7 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
ut_assertok(dm_rtc_get(dev, &now));
 
ut_assertok(i2c_emul_find(dev, &emul));
-   ut_assert(emul != NULL);
+   ut_assertnonnull(emul);
 
/* Tell the RTC to go into manual mode */
old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
@@ -161,7 +161,7 @@ static int dm_test_rtc_read_write(struct unit_test_state 
*uts)
ut_asserteq(memcmp(buf, "at", 3), 0);
 
ut_assertok(i2c_emul_find(dev, &emul));
-   ut_assert(emul != NULL);
+   ut_assertnonnull(emul);
 
old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
ut_assertok(dm_rtc_get(dev, &time));
@@ -245,7 +245,7 @@ static int dm_test_rtc_reset(struct unit_test_state *uts)
ut_assertok(dm_rtc_get(dev, &now));
 
ut_assertok(i2c_emul_find(dev, &emul));
-   ut_assert(emul != NULL);
+   ut_assertnonnull(emul);
 
old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, 0);
 
@@ -274,9 +274,9 @@ static int dm_test_rtc_dual(struct unit_test_state *uts)
ut_assertok(dm_rtc_get(dev2, &now2));
 
ut_assertok(i2c_emul_find(dev1, &emul1));
-   ut_assert(emul1 != NULL);
+   ut_assertnonnull(emul1);
ut_assertok(i2c_emul_find(dev2, &emul2));
-   ut_assert(emul2 != NULL);
+   ut_assertnonnull(emul2);
 
offset = sandbox_i2c_rtc_set_offset(emul1, false, -1);
sandbox_i2c_rtc_set_offset(emul2, false, offset + 1);
-- 
2.37.1.455.g008518b4e5-goog

[PATCH 0/5] rtc: Work around race conditions

[Simon Glass]

This series includes some patches to work around race conditions in the
rtc tests, as well as a mechanism to run unit tests more than once.

With 1000 runs I normally see three failures in the tests addressed here.
With this series no failures are seen.

This also includes a work-around for the daylight-saving changeover.


Simon Glass (5):
  dm: rtc: Make use of ut_assertnonnull()
  test: Allow running tests multiple times
  dm: rtc: Avoid a race in the rtc_reset test
  dm: rtc: Try to avoid a race in rtc_set_get test
  dm: rtc: Try to handle the localtime() race

 arch/sandbox/cpu/spl.c|  2 +-
 doc/develop/tests_sandbox.rst | 24 
 include/test/test.h   |  2 ++
 include/test/ut.h |  3 +-
 test/cmd_ut.c | 12 ++--
 test/dm/rtc.c | 53 +--
 test/dm/test-dm.c | 13 +++--
 test/test-main.c  | 14 +++--
 8 files changed, 98 insertions(+), 25 deletions(-)

-- 
2.37.1.455.g008518b4e5-goog

[PATCH v5 1/1] test: Add some tests for kconfig.h

[Simon Glass]

The macros in this file are a little confusing and we currently have no
tests to check that they work as expected.

Add some tests which check the macros in C code. Add a few tests which
check that the build errors are generated correctly too, using buildman's
-a option.

Signed-off-by: Simon Glass 
---

Changes in v5:
- Correct a problem with azure not supporting buildman's parent directory
- Don't run the tests on sandbox_vpl

Changes in v4:
- Expand the series with tests and buildman changes

 test/Kconfig  |  3 +-
 test/Makefile |  4 ++-
 test/lib/Kconfig  | 23 ++
 test/lib/Makefile |  5 +++
 test/lib/kconfig.c| 58 +++
 test/lib/kconfig_spl.c| 44 ++
 test/py/tests/test_kconfig.py | 39 +++
 7 files changed, 174 insertions(+), 2 deletions(-)
 create mode 100644 test/lib/Kconfig
 create mode 100644 test/lib/kconfig.c
 create mode 100644 test/lib/kconfig_spl.c
 create mode 100644 test/py/tests/test_kconfig.py

diff --git a/test/Kconfig b/test/Kconfig
index 9b283a57ba9..a6b463e4d06 100644
--- a/test/Kconfig
+++ b/test/Kconfig
@@ -20,7 +20,7 @@ config SPL_UNIT_TEST
 config UT_LIB
bool "Unit tests for library functions"
depends on UNIT_TEST
-   default y
+   default y if !SANDBOX_VPL
help
  Enables the 'ut lib' command which tests library functions like
  memcat(), memcyp(), memmove() and ASN1 compiler/decoder.
@@ -99,5 +99,6 @@ config UT_UNICODE
 
 source "test/dm/Kconfig"
 source "test/env/Kconfig"
+source "test/lib/Kconfig"
 source "test/optee/Kconfig"
 source "test/overlay/Kconfig"
diff --git a/test/Makefile b/test/Makefile
index 1dfd5677440..178773647a8 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -17,6 +17,9 @@ obj-$(CONFIG_$(SPL_)CMDLINE) += command_ut.o
 obj-$(CONFIG_$(SPL_)UT_COMPRESSION) += compression.o
 obj-y += dm/
 obj-$(CONFIG_FUZZ) += fuzz/
+ifndef CONFIG_SANDBOX_VPL
+obj-$(CONFIG_UNIT_TEST) += lib/
+endif
 obj-$(CONFIG_$(SPL_)CMDLINE) += print_ut.o
 obj-$(CONFIG_$(SPL_)CMDLINE) += str_ut.o
 obj-$(CONFIG_UT_TIME) += time_ut.o
@@ -25,7 +28,6 @@ obj-y += ut.o
 ifeq ($(CONFIG_SPL_BUILD),)
 obj-$(CONFIG_UNIT_TEST) += boot/
 obj-$(CONFIG_UNIT_TEST) += common/
-obj-$(CONFIG_UNIT_TEST) += lib/
 obj-y += log/
 obj-$(CONFIG_$(SPL_)UT_UNICODE) += unicode_ut.o
 endif
diff --git a/test/lib/Kconfig b/test/lib/Kconfig
new file mode 100644
index 000..dbb03e4a36f
--- /dev/null
+++ b/test/lib/Kconfig
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2022 Google LLC
+
+if SANDBOX
+
+config TEST_KCONFIG
+   bool "Enable detection of Kconfig macro errors"
+   help
+ This is used to test that the IF_ENABLED_INT() macro causes a build 
error
+ if the value is used when the CONFIG Is not enabled.
+
+config TEST_KCONFIG_ENABLE
+   bool "Option to enable"
+   help
+ This is the option that controls whether the value is present.
+
+config TEST_KCONFIG_VALUE
+   int "Value associated with the option"
+   depends on TEST_KCONFIG_ENABLE
+   help
+ This is the value whgch is present if TEST_KCONFIG_ENABLE is enabled.
+
+endif # SANDBOX
diff --git a/test/lib/Makefile b/test/lib/Makefile
index d244bb431d4..7e7922fe3b4 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -2,11 +2,13 @@
 #
 # (C) Copyright 2018
 # Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ifeq ($(CONFIG_SPL_BUILD),)
 obj-y += cmd_ut_lib.o
 obj-y += abuf.o
 obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
 obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
 obj-y += hexdump.o
+obj-$(CONFIG_SANDBOX) += kconfig.o
 obj-y += lmb.o
 obj-y += longjmp.o
 obj-$(CONFIG_CONSOLE_RECORD) += test_print.o
@@ -19,3 +21,6 @@ obj-$(CONFIG_UT_LIB_RSA) += rsa.o
 obj-$(CONFIG_AES) += test_aes.o
 obj-$(CONFIG_GETOPT) += getopt.o
 obj-$(CONFIG_UT_LIB_CRYPT) += test_crypt.o
+else
+obj-$(CONFIG_SANDBOX) += kconfig_spl.o
+endif
diff --git a/test/lib/kconfig.c b/test/lib/kconfig.c
new file mode 100644
index 000..472d2c57280
--- /dev/null
+++ b/test/lib/kconfig.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test of linux/kconfig.h macros
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int lib_test_is_enabled(struct unit_test_state *uts)
+{
+   ulong val;
+
+   ut_asserteq(1, IS_ENABLED(CONFIG_CMDLINE))
+   ut_asserteq(0, IS_ENABLED(CONFIG__UNDEFINED))
+
+   ut_asserteq(1, CONFIG_IS_ENABLED(CMDLINE))
+   ut_asserteq(0, CONFIG_IS_ENABLED(OF_PLATDATA))
+   ut_asserteq(0, CONFIG_IS_ENABLED(_UNDEFINED))
+
+   ut_asserteq(0xc000,
+   IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED, 
CONFIG_BLOBLIST_ADDR));
+   ut_asserteq(0xc000,
+   CONFIG_IF_ENABLED_INT(BLOBLIST_FIXED, BLOBLIST_ADDR));
+
+   /*
+* This fails if CON

[PATCH] board: freescale: p1_p2_rdb_pc: Delete watchdog max6370 node in load_default mode

[Pali Rohár]

CPLD in load_default mode ignores watchdog reset signal. It does not reset
board when watchdog triggers reset signal.

Detect load_default mode by GPIO7 - LOAD_DEFAULT_N and delete watchdog
max6370 node from device to prevent registering driver for non-working
watchdog.

Signed-off-by: Pali Rohár 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 28 +
 1 file changed, 28 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index a71952dcf399..06cab729e4ab 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -368,6 +368,24 @@ int board_eth_init(struct bd_info *bis)
 }
 #endif
 
+#if defined(CONFIG_OF_BOARD_SETUP) || defined(CONFIG_OF_BOARD_FIXUP)
+static void fix_max6370_watchdog(void *blob)
+{
+   int off = fdt_node_offset_by_compatible(blob, -1, "maxim,max6370");
+   ccsr_gpio_t *pgpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
+   u32 gpioval = in_be32(&pgpio->gpdat);
+
+   /*
+* Delete watchdog max6370 node in load_default mode (detected by
+* GPIO7 - LOAD_DEFAULT_N) because CPLD in load_default mode ignores
+* watchdog reset signal. CPLD in load_default mode does not reset
+* board when watchdog triggers reset signal.
+*/
+   if (!(gpioval & BIT(31-7)) && off >= 0)
+   fdt_del_node(blob, off);
+}
+#endif
+
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
@@ -393,6 +411,8 @@ int ft_board_setup(void *blob, struct bd_info *bd)
sizeof("okay"), 0);
 #endif
 
+   fix_max6370_watchdog(blob);
+
 #if defined(CONFIG_HAS_FSL_DR_USB)
fsl_fdt_fixup_dr_usb(blob, bd);
 #endif
@@ -444,3 +464,11 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
 }
 #endif
+
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *blob)
+{
+   fix_max6370_watchdog(blob);
+   return 0;
+}
+#endif
-- 
2.20.1

[PATCH v2 1/4] board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop

[Pali Rohár]

CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.

This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.

But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.

To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.

With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Resend patch
* Update comment about watchdog
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 13 +
 board/freescale/p1_p2_rdb_pc/spl.c  |  6 ++
 board/freescale/p1_p2_rdb_pc/tlb.c  |  2 +-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 343059c09c36..84e1d65cdb1f 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -97,6 +97,19 @@ void board_cpld_init(void)
out_8(&cpld_data->status_led, CPLD_STATUS_LED);
out_8(&cpld_data->fxo_led, CPLD_FXO_LED);
out_8(&cpld_data->fxs_led, CPLD_FXS_LED);
+
+   /*
+* CPLD's system reset register on P1/P2 RDB boards is not autocleared
+* after flipping it. If this register is set to one then CPLD triggers
+* reset of CPU in few ms.
+*
+* CPLD does not trigger reset of CPU for 100ms after the last reset.
+*
+* This means that trying to reset board via CPLD system reset register
+* cause reboot loop. To prevent this reboot loop, the only workaround
+* is to try to clear CPLD's system reset register as early as possible
+* and it has to be done in 100ms since the last start of reset.
+*/
out_8(&cpld_data->system_rst, CPLD_SYS_RST);
 }
 
diff --git a/board/freescale/p1_p2_rdb_pc/spl.c 
b/board/freescale/p1_p2_rdb_pc/spl.c
index 22156f2824ec..def28665960d 100644
--- a/board/freescale/p1_p2_rdb_pc/spl.c
+++ b/board/freescale/p1_p2_rdb_pc/spl.c
@@ -31,6 +31,12 @@ void board_init_f(ulong bootflag)
u32 plat_ratio, bus_clk;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
 
+   /*
+* Call board_early_init_f() as early as possible as it workarounds
+* reboot loop due to broken CPLD state machine for reset line.
+*/
+   board_early_init_f();
+
console_init_f();
 
/* Set pmuxcr to allow both i2c1 and i2c2 */
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 13f3a1edf68d..2d431d6d0d90 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -61,11 +61,11 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 5, BOOKE_PAGESZ_1M, 1),
 #endif
+#endif /* not SPL */
 
SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
-#endif /* not SPL */
 
 #ifdef CONFIG_SYS_NAND_BASE
/* *I*G - NAND */
-- 
2.20.1

[PATCH v2 3/4] board: freescale: p1_p2_rdb_pc: Avoid usage of CPLD's system reset register

[Pali Rohár]

CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.

Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.

Fixes: 20fb58fc5a1c ("board: freescale: p1_p2_rdb_pc: Implement board_reset()")
Signed-off-by: Pali Rohár 
---
 arch/powerpc/cpu/mpc85xx/cpu.c  | 4 
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 226a26ba320a..c63c17286811 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -44,6 +44,7 @@ __board_reset(void)
/* Do nothing */
 }
 void board_reset(void) __attribute__((weak, alias("__board_reset")));
+void board_reset_last(void) __attribute__((weak, alias("__board_reset")));
 
 int checkcpu (void)
 {
@@ -328,6 +329,9 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
/* Next try asserting HRESET_REQ */
out_be32(&gur->rstcr, 0x2);
udelay(100);
+
+   /* Attempt last-stage board-specific reset */
+   board_reset_last();
 #endif
 
return 1;
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 16224752adb1..4bcb05bed9b8 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -83,7 +83,7 @@ struct cpld_data {
 #define CPLD_FXS_LED   0x0F
 #define CPLD_SYS_RST   0x00
 
-void board_reset(void)
+void board_reset_last(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
out_8(&cpld_data->system_rst, 1);
-- 
2.20.1

[PATCH v2 4/4] board: freescale: p1_p2_rdb_pc: Turn off watchdog before reset

[Pali Rohár]

P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.

Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.

Signed-off-by: Pali Rohár 
---
 arch/powerpc/cpu/mpc85xx/cpu.c  |  4 
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 12 
 2 files changed, 16 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index c63c17286811..015bd3661c59 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -43,6 +43,7 @@ __board_reset(void)
 {
/* Do nothing */
 }
+void board_reset_prepare(void) __attribute__((weak, alias("__board_reset")));
 void board_reset(void) __attribute__((weak, alias("__board_reset")));
 void board_reset_last(void) __attribute__((weak, alias("__board_reset")));
 
@@ -323,6 +324,9 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 #else
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 
+   /* Call board-specific preparation for reset */
+   board_reset_prepare();
+
/* Attempt board-specific reset */
board_reset();
 
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 4bcb05bed9b8..42409a864854 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -83,6 +83,18 @@ struct cpld_data {
 #define CPLD_FXS_LED   0x0F
 #define CPLD_SYS_RST   0x00
 
+void board_reset_prepare(void)
+{
+   /*
+* During reset preparation, turn off external watchdog.
+* This ensures that external watchdog does not trigger
+* another reset or possible infinite reset loop.
+*/
+   struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+   out_8(&cpld_data->wd_cfg, CPLD_WD_CFG);
+   in_8(&cpld_data->wd_cfg); /* Read back to sync write */
+}
+
 void board_reset_last(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
-- 
2.20.1

[PATCH v2 2/4] board: freescale: p1_p2_rdb_pc: Add workaround for non-working watchdog

[Pali Rohár]

If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Watchdog starts working again after CPU reset via
non-watchdog method.

Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.

Note that reset does not occur immediately after calling do_reset(), but
after few ms later as real reset is done by CPLD. So it is normal that
function do_reset() returns. Therefore hangs after calling do_reset() to
prevent CPU execution of the rest U-Boot code.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Call eieio() before do_reset() to ensure that all IO operations completes
* Hang after calling do_reset() as reset does not occur immediately.
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 84e1d65cdb1f..16224752adb1 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -92,6 +92,7 @@ void board_reset(void)
 void board_cpld_init(void)
 {
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+   u8 prev_wd_cfg = in_8(&cpld_data->wd_cfg);
 
out_8(&cpld_data->wd_cfg, CPLD_WD_CFG);
out_8(&cpld_data->status_led, CPLD_STATUS_LED);
@@ -111,6 +112,26 @@ void board_cpld_init(void)
 * and it has to be done in 100ms since the last start of reset.
 */
out_8(&cpld_data->system_rst, CPLD_SYS_RST);
+
+   /*
+* If watchdog timer was already set to non-disabled value then it means
+* that watchdog timer was already activated, has already expired and
+* caused CPU reset. If this happened then due to CPLD firmware bug,
+* writing to wd_cfg register has no effect and therefore it is not
+* possible to reactivate watchdog timer again. Also if CPU was reset
+* via watchdog then some peripherals like i2c do not work. Watchdog and
+* i2c start working again after CPU reset via non-watchdog method.
+*
+* So in case watchdog timer register in CPLD was already enabled then
+* disable it in CPLD and reset CPU which cause new boot. Watchdog timer
+* is disabled few lines above, after reading CPLD previous value.
+* This logic (disabling timer before reset) prevents reboot loop.
+*/
+   if (prev_wd_cfg != CPLD_WD_CFG) {
+   eieio();
+   do_reset(NULL, 0, 0, NULL);
+   while (1); /* do_reset() does not occur immediately */
+   }
 }
 
 void board_gpio_init(void)
-- 
2.20.1

[PATCH 1/1] fs/erofs: silence erofs_probe()

[Heinrich Schuchardt]

fs_set_blk_dev() probes all file-systems until it finds one that matches
the volume. We do not expect any console output for non-matching
file-systems.

Convert error messages in erofs_read_superblock() to debug output.

Fixes: 830613f8f5bb ("fs/erofs: add erofs filesystem support")
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass 
---
v2:
keep erofs_err() for block size mismatch
---
 fs/erofs/super.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 4cca322b9e..8277d9b53f 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -65,14 +65,14 @@ int erofs_read_superblock(void)
 
ret = erofs_blk_read(data, 0, 1);
if (ret < 0) {
-   erofs_err("cannot read erofs superblock: %d", ret);
+   erofs_dbg("cannot read erofs superblock: %d", ret);
return -EIO;
}
dsb = (struct erofs_super_block *)(data + EROFS_SUPER_OFFSET);
 
ret = -EINVAL;
if (le32_to_cpu(dsb->magic) != EROFS_SUPER_MAGIC_V1) {
-   erofs_err("cannot find valid erofs superblock");
+   erofs_dbg("cannot find valid erofs superblock");
return ret;
}
 
-- 
2.36.1

Re: cmd_process warning

[Heinrich Schuchardt]

On 8/1/22 13:58, Sergei Antonov wrote:

Hello!
There is an annoying warning about conflicting return types:

common/command.c:586:20: warning: conflicting types for 'cmd_process'
due to enum/integer mismatch; have 'enum command_ret_t(int,  int,
char * const*, int *, ulong *)' {aka 'enum command_ret_t(int,  int,
char * const*, int *, long unsigned int *)'} [-Wenum-int-mismatch]
In file included from common/command.c:13:
include/command.h:234:5: note: previous declaration of 'cmd_process'
with type 'int(int,  int,  char * const*, int *, long unsigned int *)'

It can be fixed by replacing 'int' with 'enum command_ret_t' in
include/command.h


Thanks for reporting. Patch created:

[PATCH 1/1] cmd: inconsistent return type of command_process()
https://lists.denx.de/pipermail/u-boot/2022-August/490520.html

Best regards

Heinrich

[PATCH 1/1] cmd: inconsistent return type of command_process()

[Heinrich Schuchardt]

The declarations in the header and in the implementation must match.

Reported-by: Sergei Antonov 
Signed-off-by: Heinrich Schuchardt 
---
 include/command.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/command.h b/include/command.h
index 44c91f655d..8917da8b21 100644
--- a/include/command.h
+++ b/include/command.h
@@ -229,10 +229,10 @@ enum command_ret_t {
  * is left unchanged.
  * @param ticksIf ticks is not null, this function set it to 
the
  * number of ticks the command took to complete.
- * Return: 0 if the command succeeded, 1 if it failed
+ * Return: 0 if command succeeded, else non-zero (CMD_RET_...)
  */
-int cmd_process(int flag, int argc, char *const argv[], int *repeatable,
-   unsigned long *ticks);
+enum command_ret_t cmd_process(int flag, int argc, char *const argv[],
+  int *repeatable, unsigned long *ticks);
 
 void fixup_cmdtable(struct cmd_tbl *cmdtp, int size);
 
-- 
2.36.1

Re: [PATCH] Revert "fdtdec: drop needlessly convoluted CONFIG_PHANDLE_CHECK_SEQ"

[Rasmus Villemoes]

On 31/07/2022 15.28, Tom Rini wrote:
> On Sat, Jul 30, 2022 at 07:27:26PM -0600, Simon Glass wrote:
>> Hi Tom,
>>

>> Shall I pick it up for the upcoming release?
> 
> I don't think we should pick up the revert as I don't think there's
> agreement that reverting this is the right step forward among all of the
> interested parties.
> 
> One thing I want to know at this point is, was the problematic device
> tree accepted upstream, or did they also say that 2 nodes with the same
> name but different paths is wrong, don't do that?

There's no problematic device tree, having two nodes with the same
(base)name is perfectly fine and in fact sometimes expected/required (in
the cases where a node name is standardized; e.g. having two identical
eeproms on different i2c buses both would/should be called eeprom@50).

What Simon is concerned about is that the translation from full path to
blob offset is now done unconditionally, and that might be costly. I'm
not sure it is (and didn't know that it could be), but as I've said
repeatedly, I prefer code that works out-of-the-box, and for the boards
that do need this extra check (because just looking at the basename is
not enough), the fact that the previous code worked seemed to be pure
luck - because those dtbs were compiled with -@ due to some other
CONFIG_ knob being set. And again, involving phandles at all is what
make the code fragile, so a revert that reinstates a CONFIG_ knob with
PHANDLE in the name is not a good way forward, assuming there is even
anything to fix.

So if the performance thing is real, sure, we can introduce a
CONFIG_something, but only if at the same time we have a sanity check at
build-time that detects if one should enable/disable that option
(depending on whether we make it "positive" or "negative"). Something
like this seems to do the trick, but I haven't looked at hooking it up
in the build system:

=== scripts/check-alias-homonyms.py ===
#!/usr/bin/python3

import sys

sys.path.insert(0, 'scripts/dtc/pylibfdt')
sys.path.insert(1, 'tools')

from dtoc import fdt

ret = 0

for name in sys.argv[1:]:
dtb = fdt.FdtScan(name)
aliasnode = dtb.GetNode("/aliases")
if not aliasnode:
continue
basenames = dict()
for prop in aliasnode.props.values():
alias = prop.name
path = prop.value
base = path[path.rfind('/')+1:]
if base in basenames:
basenames[base].append(alias)
else:
basenames[base] = [alias]
for base, aliases in basenames.items():
if len(aliases) == 1:
continue
print("Warning: In %s, the aliases %s all point at nodes with
the basename '%s' - consider (en/dis)abling CONFIG_..." % (name,
",".join(aliases), base))
ret = 1

sys.exit(ret)
===

I imagine this being run over CONFIG_OF_LIST when CONFIG_... has the
value that disables the fdt_path_offset() call. For concreteness,
something like

config ASSUME_ALIAS_HOMONYMS # or whatever better name one can come up with
  bool "Assume there may be nodes pointed to by aliases in DT that have
identical basenames"
  help
In most cases, the nodes pointed to by aliases in the device tree
all have different basenames. When this is satisfied, the
fdtdec_get_alias_seq() function can avoid a somewhat expensive full walk
of the dtb when looking for an alias for a given node. If the device
tree for your board does have aliases pointing at nodes with the same
basenames (but of course different full paths), that full walk is
necessary for correctness, and you can then enable this option.

plus

- if (offset != fdt_path_offset(blob, prop))
+ if (IS_ENABLED(CONFIG_ASSUME_ALIAS_HOMONYMS) && offset !=
fdt_path_offset(blob, prop))

I have no idea what running the above python script on the dtb(s) in the
common case of !CONFIG_ASSUME_ALIAS_HOMONYMS adds to buildtime, but I do
believe that before eliding some code that is necessary for correctness
in the general case, we need buildtime verification that it's ok.

Rasmus

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Add env commands norlowerboot, norupperboot, sd2boot and defboot

[Pali Rohár]

On Friday 22 July 2022 00:20:21 Pali Rohár wrote:
> On Friday 08 July 2022 19:12:10 Tom Rini wrote:
> > [resend to the list too this time]
> > 
> > On Sat, Jul 09, 2022 at 12:43:44AM +0200, Pali Rohár wrote:
> > > PING
> > > 
> > > I still have not received any response. What is the point?
> > > 
> > > On Sunday 03 July 2022 14:38:36 Pali Rohár wrote:
> > > > PING!
> > > > 
> > > > On Thursday 23 June 2022 15:43:45 Pali Rohár wrote:
> > > > > On Thursday 16 June 2022 17:01:50 Peng Fan (OSS) wrote:
> > > > > > 在 2022/4/25 22:50, Pali Rohár 写道:
> > > > > > > All *boot env commands overrides default boot source location via 
> > > > > > > i2c.
> > > > > > > After board reset without power off, BootROM then starts booting 
> > > > > > > U-Boot
> > > > > > > from this specified location instead of the default one.
> > > > > > > 
> > > > > > > Add new env command defboot which reverts boot location to the 
> > > > > > > default
> > > > > > > value, which in most cases is configurable by HW DIP switches.
> > > > > > > 
> > > > > > > And add new env commands norlowerboot, norupperboot, sd2boot to 
> > > > > > > boot from
> > > > > > > other locations. norlowerboot would instruct BootROM to boot from 
> > > > > > > lower NOR
> > > > > > > bank, norupperboot from upper NOR bank and sd2boot from SD card 
> > > > > > > with
> > > > > > > alternative configuration.
> > > > > > > 
> > > > > > > Signed-off-by: Pali Rohár 
> > > > > > 
> > > > > > Not able to apply this patch.
> > > > > 
> > > > > And what is the reason? It applies cleanly on top of next branch, 
> > > > > which
> > > > > is today at commit 9121478ee6f2aee381f8fe49d8997d43527d351a.
> > 
> > Peng, this patch doesn't apply currently but also looks fairly obvious
> > to adapt to top of tree.  Please just make it apply when you pick this
> > up, thanks.
> > 
> > -- 
> > Tom
> 
> Month ago it applied cleanly on next :-(

Now I tested this patch and it still applies cleanly on top of master
branch. I just downloaded MBOX version from patchwork:
https://patchwork.ozlabs.org/project/uboot/patch/20220425145043.9945-1-p...@kernel.org/

Could you please process it? It is there since April.

And if it has issue, could you please say something about it?

Re: [PATCH v2 0/7] Add support for cyclic function execution infrastruture

[Simon Glass]

Hi Stefan,

On Mon, 1 Aug 2022 at 06:40, Stefan Roese  wrote:
>
> Hi Simon,
>
> On 01.08.22 14:22, Simon Glass wrote:
> > Hi Stefan,
> >
> > On Mon, 1 Aug 2022 at 01:17, Stefan Roese  wrote:
> >>
> >> Hi Simon,
> >>
> >> On 31.07.22 03:27, Simon Glass wrote:
> >>> Hi Stefan,
> >>>
> >>> On Thu, 28 Jul 2022 at 01:09, Stefan Roese  wrote:
> 
>  This patchset adds the basic infrastructure to periodically execute
>  code, e.g. all 100ms. Examples for such functions might be LED blinking
>  etc. The functions that are hooked into this cyclic list should be
>  small timewise as otherwise the execution of the other code that relies
>  on a high frequent polling (e.g. UART rx char ready check) might be
>  delayed too much. This patch also adds the Kconfig option
>  CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
>  for such a cyclic function. If it's execution time exceeds this time,
>  this cyclic function will get removed from the cyclic list.
> 
>  How is this cyclic functionality executed?
>  This patchset integrates the main function responsible for calling all
>  registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
>  macro. This guarantees that cyclic_run() is executed very often, which
>  is necessary for the cyclic functions to get scheduled and executed at
>  their configured periods.
> 
>  This cyclic infrastructure will be used by a board specific function on
>  the NIC23 MIPS Octeon board, which needs to check periodically, if a
>  PCIe FLR has occurred.
> 
>  Ideas how to continue:
>  One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
>  move the watchdog_reset call into this cyclic infrastructure as well.
>  Or to perhaps move the shell UART RX ready polling to a cyclic
>  function.
> 
>  It's also possible to extend the "cyclic" command, to support the
>  creation of periodically executed shell commands (for testing etc).
> 
>  Here the Azure build, without any issues:
>  https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results
> 
>  Thanks,
>  Stefan
> 
>  Aaron Williams (1):
>  mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure
> 
>  Stefan Roese (6):
>  time: Import time_after64() and friends from Linux
>  cyclic: Add basic support for cyclic function execution infrastruture
>  cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
>  cyclic: Integrate cyclic functionality at bootup in board_r/f
>  cyclic: Add 'cyclic list' command
>  sandbox: Add cyclic demo function
> 
> MAINTAINERS|   7 +
> board/Marvell/octeon_nic23/board.c | 197 +
> board/sandbox/sandbox.c|  15 +++
> cmd/Kconfig|   7 +
> cmd/Makefile   |   1 +
> cmd/cyclic.c   |  40 ++
> common/Kconfig |  20 +++
> common/Makefile|   1 +
> common/board_f.c   |   2 +
> common/board_r.c   |   2 +
> common/cyclic.c| 112 
> configs/octeon_nic23_defconfig |   3 +
> configs/sandbox_defconfig  |   3 +
> fs/cramfs/uncompress.c |   2 +-
> include/cyclic.h   |  97 ++
> include/time.h |  19 +++
> include/watchdog.h |  23 +++-
> 17 files changed, 547 insertions(+), 4 deletions(-)
> create mode 100644 cmd/cyclic.c
> create mode 100644 common/cyclic.c
> create mode 100644 include/cyclic.h
> 
>  --
>  2.37.1
> 
> >>>
> >>> This looks interesting. I like the idea of integrating the watchdog
> >>> stuff too, since you are making use of it.
> >>>
> >>> Would it make sense to make use of the new event system, since it has
> >>> static and dynamic handlers?
> >>
> >> IIRC, I tried to make use of this infrastructure but it did not work
> >> out. Or do you see some way to integrate this cyclic IF into the
> >> event system? FWICT, the only way to get this done is to make use of
> >> the (ugly) WATCHDOG_RESET calls.
> >
> > Yes that makes sense. I don't see another way.
> >
> > But within that, one option would be to send an event every time
> > WATCHDOG_RESET is used, and have things register as an event spy, thus
> > making use of that existing system. The event feature is not enabled
> > by default, but it could be enabled when this functionality is needed.
>
> I still need to double-check, sorry: You are thinking about this call-
> trace:
>
> WATCHDOG_RESET -> event IF -> cylic IF -> cylic user
>

More this, i.e. I am wondering if the cyclic functio

[PATCH v2] board: freescale: p1_p2_rdb_pc: Calculate offsets for eSDHC boot sector

[Pali Rohár]

Correctly calculate offsets between SPL and proper U-Boot when new config
option CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR for generating eSDHC boot sector
is enabled. Otherwise SPL would not be able to boot proper U-Boot.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* rebase on top of master branch, commit 
85eb5ac6efee878f3c2ab3269286250e187ca10c
---
 include/configs/p1_p2_rdb_pc.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index ba04029df8d8..d2787136681b 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -80,7 +80,11 @@
 #define CONFIG_SYS_MMC_U_BOOT_SIZE (768 << 10)
 #define CONFIG_SYS_MMC_U_BOOT_DST  CONFIG_SYS_TEXT_BASE
 #define CONFIG_SYS_MMC_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
+#ifdef CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR
+#define CONFIG_SYS_MMC_U_BOOT_OFFS (CONFIG_SPL_PAD_TO - 
CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA*512)
+#else
 #define CONFIG_SYS_MMC_U_BOOT_OFFS CONFIG_SPL_PAD_TO
+#endif
 #elif defined(CONFIG_SPIFLASH)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DSTCONFIG_SYS_TEXT_BASE
-- 
2.20.1

Re: [PATCH v2 0/7] Add support for cyclic function execution infrastruture

[Stefan Roese]

Hi Simon,

On 01.08.22 14:22, Simon Glass wrote:

Hi Stefan,

On Mon, 1 Aug 2022 at 01:17, Stefan Roese  wrote:


Hi Simon,

On 31.07.22 03:27, Simon Glass wrote:

Hi Stefan,

On Thu, 28 Jul 2022 at 01:09, Stefan Roese  wrote:


This patchset adds the basic infrastructure to periodically execute
code, e.g. all 100ms. Examples for such functions might be LED blinking
etc. The functions that are hooked into this cyclic list should be
small timewise as otherwise the execution of the other code that relies
on a high frequent polling (e.g. UART rx char ready check) might be
delayed too much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.

How is this cyclic functionality executed?
This patchset integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.

This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.

Ideas how to continue:
One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
move the watchdog_reset call into this cyclic infrastructure as well.
Or to perhaps move the shell UART RX ready polling to a cyclic
function.

It's also possible to extend the "cyclic" command, to support the
creation of periodically executed shell commands (for testing etc).

Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results

Thanks,
Stefan

Aaron Williams (1):
mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure

Stefan Roese (6):
time: Import time_after64() and friends from Linux
cyclic: Add basic support for cyclic function execution infrastruture
cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
cyclic: Integrate cyclic functionality at bootup in board_r/f
cyclic: Add 'cyclic list' command
sandbox: Add cyclic demo function

   MAINTAINERS|   7 +
   board/Marvell/octeon_nic23/board.c | 197 +
   board/sandbox/sandbox.c|  15 +++
   cmd/Kconfig|   7 +
   cmd/Makefile   |   1 +
   cmd/cyclic.c   |  40 ++
   common/Kconfig |  20 +++
   common/Makefile|   1 +
   common/board_f.c   |   2 +
   common/board_r.c   |   2 +
   common/cyclic.c| 112 
   configs/octeon_nic23_defconfig |   3 +
   configs/sandbox_defconfig  |   3 +
   fs/cramfs/uncompress.c |   2 +-
   include/cyclic.h   |  97 ++
   include/time.h |  19 +++
   include/watchdog.h |  23 +++-
   17 files changed, 547 insertions(+), 4 deletions(-)
   create mode 100644 cmd/cyclic.c
   create mode 100644 common/cyclic.c
   create mode 100644 include/cyclic.h

--
2.37.1



This looks interesting. I like the idea of integrating the watchdog
stuff too, since you are making use of it.

Would it make sense to make use of the new event system, since it has
static and dynamic handlers?


IIRC, I tried to make use of this infrastructure but it did not work
out. Or do you see some way to integrate this cyclic IF into the
event system? FWICT, the only way to get this done is to make use of
the (ugly) WATCHDOG_RESET calls.


Yes that makes sense. I don't see another way.

But within that, one option would be to send an event every time
WATCHDOG_RESET is used, and have things register as an event spy, thus
making use of that existing system. The event feature is not enabled
by default, but it could be enabled when this functionality is needed.


I still need to double-check, sorry: You are thinking about this call-
trace:

WATCHDOG_RESET -> event IF -> cylic IF -> cylic user

?

If yes, what would be the advantage(s) against implementing this
separately?

Thanks,
Stefan

Re: [PATCH v1 2/2] cmd: fru: add product info area parsing support

[Heinrich Schuchardt]

On 7/29/22 23:54, Jae Hyun Yoo wrote:

Add product info area parsing support. Custom product info field parsing
function 'fru_parse_product_custom' can be replaced with a board specific
implementation.

Signed-off-by: Jae Hyun Yoo 
---
Changes from RFC:
  * Added manufacturer custom product info fields parsing flow.


Please, provide a unit test for the new functions.

Best regards

Heinrich



  common/fru_ops.c | 161 ++-
  include/fru.h|  22 +++
  2 files changed, 182 insertions(+), 1 deletion(-)

diff --git a/common/fru_ops.c b/common/fru_ops.c
index c03eeffbddc6..9f350f875035 100644
--- a/common/fru_ops.c
+++ b/common/fru_ops.c
@@ -264,6 +264,91 @@ static int fru_parse_board(unsigned long addr)
return ret;
  }

+__weak int fru_parse_product_custom(unsigned long addr)
+{
+   int len;
+   u8 type;
+
+   do {
+   len = fru_check_type_len(*(u8 *)addr, fru_data.prd.lang_code,
+&type);
+   if (len == -EINVAL)
+   break;
+
+   addr += 1;
+
+   /* Skip empty field */
+   if (!len)
+   continue;
+
+   if (DEBUG_PARSE_CUSTOM_FIELDS)
+   print_hex_dump_bytes("Product Custom Field: ",
+DUMP_PREFIX_NONE, (u8 *)addr, len);
+
+   addr += len;
+   } while (true);
+
+   return 0;
+}
+
+static int fru_parse_product(unsigned long addr)
+{
+   u8 i, type;
+   int len, ret = 0;
+   u8 *data, *term, *limit;
+
+   memcpy(&fru_data.prd.ver, (void *)addr, 6);
+   addr += 3;
+   data = (u8 *)&fru_data.prd.manufacturer_type_len;
+
+   /* Record max structure limit not to write data over allocated space */
+   limit = (u8 *)&fru_data.prd + sizeof(struct fru_product_data);
+
+   for (i = 0; i < FRU_PRODUCT_AREA_TOTAL_FIELDS;
+i++, data += FRU_BOARD_MAX_LEN) {
+   len = fru_check_type_len(*(u8 *)addr, fru_data.prd.lang_code,
+&type);
+   /*
+* Stop cature if it end of fields
+*/
+   if (len == -EINVAL)
+   break;
+
+   /* Stop when amount of chars is more then fields to record */
+   if (data + len > limit)
+   break;
+   /* This record type/len field */
+   *data++ = *(u8 *)addr;
+
+   /* Add offset to match data */
+   addr += 1;
+
+   /* If len is 0 it means empty field that's why skip writing */
+   if (!len)
+   continue;
+
+   /* Record data field */
+   memcpy(data, (u8 *)addr, len);
+   term = data + (u8)len;
+   *term = 0;
+   addr += len;
+   }
+
+   if (i < FRU_PRODUCT_AREA_TOTAL_FIELDS) {
+   printf("Product area require minimum %d fields\n",
+  FRU_PRODUCT_AREA_TOTAL_FIELDS);
+   return -EINVAL;
+   }
+
+   len = fru_check_type_len(*(u8 *)addr, fru_data.prd.lang_code, &type);
+
+   /* If it has custom fields, do custom parsing */
+   if (len != -EINVAL)
+   ret = fru_parse_product_custom(addr);
+
+   return ret;
+}
+
  __weak int fru_parse_multirec_oem(unsigned long addr)
  {
struct fru_multirec_hdr *mrc = (struct fru_multirec_hdr *)addr;
@@ -319,6 +404,9 @@ int fru_capture(unsigned long addr)
if (hdr->off_board)
fru_parse_board(addr + fru_cal_area_len(hdr->off_board));

+   if (hdr->off_product)
+   fru_parse_product(addr + fru_cal_area_len(hdr->off_product));
+
if (hdr->off_multirec)
fru_parse_multirec(addr + fru_cal_area_len(hdr->off_multirec));

@@ -397,6 +485,71 @@ static int fru_display_board(struct fru_board_data *brd, 
int verbose)
return 0;
  }

+static int fru_display_product(struct fru_product_data *prd, int verbose)
+{
+   u8 type;
+   int len;
+   u8 *data;
+   static const char * const productinfo[] = {
+   "Manufacturer Name",
+   "Product Name",
+   "Part Number",
+   "Version Number",
+   "Serial No",
+   "Asset Number",
+   "File ID",
+   };
+
+   if (verbose) {
+   printf("*PRODUCT INFO*\n");
+   printf("Version:%d\n", fru_version(prd->ver));
+   printf("Product Area Length:%d\n", fru_cal_area_len(prd->len));
+   }
+
+   if (fru_check_language(prd->lang_code))
+   return -EINVAL;
+
+   data = (u8 *)&prd->manufacturer_type_len;
+
+   for (u8 i = 0; i < (sizeof(productinfo) / sizeof(*productinfo)); i++) {
+   len = fru_check_type_len(*data++, prd->lang_code,
+  

Re: [PATCH v1 1/2] cmd: fru: move FRU handling support to common region

[Heinrich Schuchardt]

On 7/29/22 23:54, Jae Hyun Yoo wrote:

From: Graeme Gregory 

The FRU handling was added as a Xilinx board dependent support but it
would be useful for other boards too, so this commit moves the FRU
handling support to the common region so that it can be enabled by
CONFIG_CMD_FRU.

To provide manufacturer specific custom board info field parsing,
it defines 'fru_parse_board_custom' as a weak function so that it can
be replaced with the board specific implementation. In the same way,
OEM Multirecord type (0xc0 - 0xff) parsing logic can be replaced with
a board specific 'fru_parse_multirec' implementation.

Signed-off-by: Graeme Gregory 
Signed-off-by: Jae Hyun Yoo 


Your patchset lacks documentation.

Please, add a man-page in doc/usage/cmd/fru.rst.


---
Changes from RFC:
  * Made FRU typecode string table as a generic and sharable table. (Michal)
  * Made OEM multirecord parsing call happen only on customizable type IDs.
(Michal)
  * Added manufacturer custom board info fields parsing flow. (Michal)

  board/xilinx/Kconfig  |   8 --
  board/xilinx/common/Makefile  |   3 -
  board/xilinx/common/board.c   | 108 +--
  cmd/Kconfig   |   8 ++
  cmd/Makefile  |   1 +
  {board/xilinx/common => cmd}/fru.c|   5 +-
  common/Makefile   |   2 +
  {board/xilinx/common => common}/fru_ops.c | 126 ++


Why should this live in common/. lib/ would make more sense.


  {board/xilinx/common => include}/fru.h|  25 +
  9 files changed, 197 insertions(+), 89 deletions(-)
  rename {board/xilinx/common => cmd}/fru.c (95%)
  rename {board/xilinx/common => common}/fru_ops.c (80%)
  rename {board/xilinx/common => include}/fru.h (76%)

diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig
index 17880661736d..110706b20fa3 100644
--- a/board/xilinx/Kconfig
+++ b/board/xilinx/Kconfig
@@ -74,11 +74,3 @@ config ZYNQ_GEM_I2C_MAC_OFFSET
  Set the MAC offset for i2C.

  endif
-
-config CMD_FRU
-   bool "FRU information for product"
-   help
- This option enables FRU commands to capture and display FRU
- information present in the device. The FRU Information is used
- to primarily to provide "inventory" information about the boards
- that the FRU Information Device is located on.
diff --git a/board/xilinx/common/Makefile b/board/xilinx/common/Makefile
index cdc3c9677432..e33baaae1159 100644
--- a/board/xilinx/common/Makefile
+++ b/board/xilinx/common/Makefile
@@ -8,6 +8,3 @@ obj-y   += board.o
  ifndef CONFIG_ARCH_ZYNQ
  obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
  endif
-ifndef CONFIG_SPL_BUILD
-obj-$(CONFIG_CMD_FRU) += fru.o fru_ops.o
-endif
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 9b4aded466ab..484fb43c84e1 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -8,6 +8,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -25,8 +26,6 @@
  #include 
  #include 

-#include "fru.h"
-
  #if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
  struct efi_fw_image fw_images[] = {
  #if defined(XILINX_BOOT_IMAGE_GUID)
@@ -88,6 +87,9 @@ int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
  #define EEPROM_HDR_NO_OF_MAC_ADDR 4
  #define EEPROM_HDR_ETH_ALEN   ETH_ALEN
  #define EEPROM_HDR_UUID_LEN   16
+#define EEPROM_MULTIREC_TYPE_XILINX_OEM0xD2
+#define EEPROM_MULTIREC_MAC_OFFSET 4
+#define EEPROM_MULTIREC_DUT_MACID  0x31

  struct xilinx_board_description {
u32 header;
@@ -116,6 +118,26 @@ struct xilinx_legacy_format {
char unused3[29]; /* 0xe3 */
  };

+struct xilinx_multirec_mac {
+   u8 xlnx_iana_id[3];
+   u8 ver;
+   u8 macid[EEPROM_HDR_NO_OF_MAC_ADDR][ETH_ALEN];
+};
+
+static u8 parsed_macid[EEPROM_HDR_NO_OF_MAC_ADDR][ETH_ALEN];
+struct xilinx_board_custom_data {
+   u8 rev_type_len;
+   u8 rev[FRU_BOARD_MAX_LEN];
+   u8 pcie_type_len;
+   u8 pcie[FRU_BOARD_MAX_LEN];
+   u8 uuid_type_len;
+   u8 uuid[FRU_BOARD_MAX_LEN];
+} __packed;
+
+#define FRU_BOARD_CUSTOM_AREA_TOTAL_FIELDS 3
+
+struct xilinx_board_custom_data fru_brd_custom;
+
  static void xilinx_eeprom_legacy_cleanup(char *eeprom, int size)
  {
int i;
@@ -197,9 +219,75 @@ static bool xilinx_detect_legacy(u8 *buffer)
return true;
  }

+int fru_parse_board_custom(unsigned long addr)
+{
+   const struct fru_table *fru_data = fru_get_fru_data();
+   u8 *data, *term, *limit;
+   u8 i, type;
+   int len;
+
+   data = (u8 *)&fru_brd_custom;
+   memset(data, 0, sizeof(struct xilinx_board_custom_data));
+
+   /* Record max structure limit not to write data over allocated space */
+   limit = (u8 *)&fru_brd_custom + sizeof(struct xilinx_board_custom_data);
+
+   for (i = 0; i < FRU_BOARD_AREA_TOTAL_FIELDS;
+i++, data += 

Re: [PATCH v2 0/7] Add support for cyclic function execution infrastruture

[Simon Glass]

Hi Stefan,

On Mon, 1 Aug 2022 at 01:17, Stefan Roese  wrote:
>
> Hi Simon,
>
> On 31.07.22 03:27, Simon Glass wrote:
> > Hi Stefan,
> >
> > On Thu, 28 Jul 2022 at 01:09, Stefan Roese  wrote:
> >>
> >> This patchset adds the basic infrastructure to periodically execute
> >> code, e.g. all 100ms. Examples for such functions might be LED blinking
> >> etc. The functions that are hooked into this cyclic list should be
> >> small timewise as otherwise the execution of the other code that relies
> >> on a high frequent polling (e.g. UART rx char ready check) might be
> >> delayed too much. This patch also adds the Kconfig option
> >> CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
> >> for such a cyclic function. If it's execution time exceeds this time,
> >> this cyclic function will get removed from the cyclic list.
> >>
> >> How is this cyclic functionality executed?
> >> This patchset integrates the main function responsible for calling all
> >> registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
> >> macro. This guarantees that cyclic_run() is executed very often, which
> >> is necessary for the cyclic functions to get scheduled and executed at
> >> their configured periods.
> >>
> >> This cyclic infrastructure will be used by a board specific function on
> >> the NIC23 MIPS Octeon board, which needs to check periodically, if a
> >> PCIe FLR has occurred.
> >>
> >> Ideas how to continue:
> >> One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
> >> move the watchdog_reset call into this cyclic infrastructure as well.
> >> Or to perhaps move the shell UART RX ready polling to a cyclic
> >> function.
> >>
> >> It's also possible to extend the "cyclic" command, to support the
> >> creation of periodically executed shell commands (for testing etc).
> >>
> >> Here the Azure build, without any issues:
> >> https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results
> >>
> >> Thanks,
> >> Stefan
> >>
> >> Aaron Williams (1):
> >>mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure
> >>
> >> Stefan Roese (6):
> >>time: Import time_after64() and friends from Linux
> >>cyclic: Add basic support for cyclic function execution infrastruture
> >>cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
> >>cyclic: Integrate cyclic functionality at bootup in board_r/f
> >>cyclic: Add 'cyclic list' command
> >>sandbox: Add cyclic demo function
> >>
> >>   MAINTAINERS|   7 +
> >>   board/Marvell/octeon_nic23/board.c | 197 +
> >>   board/sandbox/sandbox.c|  15 +++
> >>   cmd/Kconfig|   7 +
> >>   cmd/Makefile   |   1 +
> >>   cmd/cyclic.c   |  40 ++
> >>   common/Kconfig |  20 +++
> >>   common/Makefile|   1 +
> >>   common/board_f.c   |   2 +
> >>   common/board_r.c   |   2 +
> >>   common/cyclic.c| 112 
> >>   configs/octeon_nic23_defconfig |   3 +
> >>   configs/sandbox_defconfig  |   3 +
> >>   fs/cramfs/uncompress.c |   2 +-
> >>   include/cyclic.h   |  97 ++
> >>   include/time.h |  19 +++
> >>   include/watchdog.h |  23 +++-
> >>   17 files changed, 547 insertions(+), 4 deletions(-)
> >>   create mode 100644 cmd/cyclic.c
> >>   create mode 100644 common/cyclic.c
> >>   create mode 100644 include/cyclic.h
> >>
> >> --
> >> 2.37.1
> >>
> >
> > This looks interesting. I like the idea of integrating the watchdog
> > stuff too, since you are making use of it.
> >
> > Would it make sense to make use of the new event system, since it has
> > static and dynamic handlers?
>
> IIRC, I tried to make use of this infrastructure but it did not work
> out. Or do you see some way to integrate this cyclic IF into the
> event system? FWICT, the only way to get this done is to make use of
> the (ugly) WATCHDOG_RESET calls.

Yes that makes sense. I don't see another way.

But within that, one option would be to send an event every time
WATCHDOG_RESET is used, and have things register as an event spy, thus
making use of that existing system. The event feature is not enabled
by default, but it could be enabled when this functionality is needed.

Regards,
Simon

[PATCH] power: regulator: Remove i2c header from gpio regulator

[Michal Simek]

i2c is not used that's why header is not needed.

Signed-off-by: Michal Simek 
---

 drivers/power/regulator/fan53555.c   | 1 -
 drivers/power/regulator/gpio-regulator.c | 1 -
 drivers/power/regulator/lp873x_regulator.c   | 1 -
 drivers/power/regulator/lp87565_regulator.c  | 1 -
 drivers/power/regulator/max77686.c   | 1 -
 drivers/power/regulator/palmas_regulator.c   | 1 -
 drivers/power/regulator/pfuze100.c   | 1 -
 drivers/power/regulator/s2mps11_regulator.c  | 1 -
 drivers/power/regulator/s5m8767.c| 1 -
 drivers/power/regulator/sandbox.c| 1 -
 drivers/power/regulator/tps65219_regulator.c | 1 -
 drivers/power/regulator/tps65941_regulator.c | 1 -
 12 files changed, 12 deletions(-)

diff --git a/drivers/power/regulator/fan53555.c 
b/drivers/power/regulator/fan53555.c
index 9d8a235b79b7..5681206bbafe 100644
--- a/drivers/power/regulator/fan53555.c
+++ b/drivers/power/regulator/fan53555.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/gpio-regulator.c 
b/drivers/power/regulator/gpio-regulator.c
index e5e08a33d3dc..9c0a68aa5af4 100644
--- a/drivers/power/regulator/gpio-regulator.c
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/lp873x_regulator.c 
b/drivers/power/regulator/lp873x_regulator.c
index ec1037d7a5fb..c326f8efa471 100644
--- a/drivers/power/regulator/lp873x_regulator.c
+++ b/drivers/power/regulator/lp873x_regulator.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/lp87565_regulator.c 
b/drivers/power/regulator/lp87565_regulator.c
index 7214dc1b8245..6bbc831d2c8a 100644
--- a/drivers/power/regulator/lp87565_regulator.c
+++ b/drivers/power/regulator/lp87565_regulator.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/max77686.c 
b/drivers/power/regulator/max77686.c
index f05d791b7cbc..cef20e11897c 100644
--- a/drivers/power/regulator/max77686.c
+++ b/drivers/power/regulator/max77686.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/palmas_regulator.c 
b/drivers/power/regulator/palmas_regulator.c
index aaa5f3cfc62e..3c4eb83be774 100644
--- a/drivers/power/regulator/palmas_regulator.c
+++ b/drivers/power/regulator/palmas_regulator.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/pfuze100.c 
b/drivers/power/regulator/pfuze100.c
index 698a6fa5923c..1d926689b3b0 100644
--- a/drivers/power/regulator/pfuze100.c
+++ b/drivers/power/regulator/pfuze100.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/s2mps11_regulator.c 
b/drivers/power/regulator/s2mps11_regulator.c
index 1c6d8358d5b1..93fb580407ab 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/s5m8767.c 
b/drivers/power/regulator/s5m8767.c
index ad0b98621cec..23575831f382 100644
--- a/drivers/power/regulator/s5m8767.c
+++ b/drivers/power/regulator/s5m8767.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/sandbox.c 
b/drivers/power/regulator/sandbox.c
index c52fe3d10832..e8b66bf2b142 100644
--- a/drivers/power/regulator/sandbox.c
+++ b/drivers/power/regulator/sandbox.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/tps65219_regulator.c 
b/drivers/power/regulator/tps65219_regulator.c
index 023cf211fc4c..f87d07e61fbf 100644
--- a/drivers/power/regulator/tps65219_regulator.c
+++ b/drivers/power/regulator/tps65219_regulator.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/power/regulator/tps65941_regulator.c 
b/drivers/power/regulator/tps65941_regulator.c
index 89918c38fa7a..b04112677505 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.36.1

Re: [PATCH 2/2] arm: mvebu: turris_omnia: Add support for design with SW reset signals

[Pali Rohár]

On Monday 01 August 2022 13:58:24 Stefan Roese wrote:
> On 29.07.22 13:29, Pali Rohár wrote:
> > New Turris Omnia HW board revision requires that software controls
> > peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
> > phy reset and lan switch reset. Those pins are connected to MCU controlled
> > by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
> > after board reset and software has to release these peripherals from reset
> > manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
> > CMD_GET_FEATURES command.
> > 
> > On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
> > those reset signals are automatically released after board finish reset.
> > 
> > Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
> > functions and insert into device tree blob pcie "reset-gpios" and eth phy
> > "phy-reset-gpios" properties with corresponding MCU gpio definitions.
> > PCIe and eth PHY drivers then automatically release resets during device
> > initialization. Both U-Boot and Linux kernel drivers support those device
> > tree reset properties.
> > 
> > Initialization of lan switch on new HW board revision is more complicated.
> > Switch strapping pins are shared with switch RGMII pins. And strapping pins
> > must be in specific configuration after releasing switch reset. Due to pin
> > sharing, it is first required to switch A385 side of switch pins into GPIO
> > mode, set strapping configuration, release switch from reset and after that
> > switch A385 pins back to RGMII mode.
> > 
> > Because this complicated setup is not supported by switch DSA drivers and
> > cannot be expressed easily in device tree, implement it manually in SPL
> > function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
> > switch initialized and be in same configuration like it was on old HW board
> > revisions (where reset sequence did those steps at hardware level).
> > 
> > Signed-off-by: Pali Rohár 
> 
> Wow, this looks pretty complex. But I assume that you already de-stilled
> the "best solution", so:

This SW setup is required as this is the only way how Marvell switch
88E6176 (Agate) can be configured. 88E6176 shares RGMII pins with
bootstrap pins. This is how Marvell designed this switch chip. In
previous board revisions 88E6176 setup was done in board reset procedure
by HW. In new board revision it is not by HW anymore.

Function initialize_switch() could be written differently, e.g. by using
U-Boot DM pinmux and GPIO APIs. But code would be larger (= slow UART
booting) and because this function is called from SPL, it would require
to adjust that DM code to fit into SPL memory and sizing limits... So
easier is to touch A385 GPIO registers directly as it require
relocations, DM usage and other stuff...

For other DT properties. Other option could be to include two DTS files
for Omnia and via some runtime u-boot hooks choose the correct DTS file.
And then there would be option question how to boot kernel correctly.
So DTS patching (which is already used in this board code) seems to be
easier and more robust solution and it allows to boot original
kernel/DTB binaries.

> Reviewed-by: Stefan Roese 
> 
> Thanks,
> Stefan
> 
> 
> > ---
> >   board/CZ.NIC/turris_omnia/turris_omnia.c | 226 +++
> >   1 file changed, 226 insertions(+)
> > 
> > diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
> > b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > index 6fc2018c1cfb..e262ea1aba51 100644
> > --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> > +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > @@ -19,9 +19,11 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include "../drivers/ddr/marvell/a38x/ddr3_init.h"
> > @@ -65,6 +67,9 @@ enum mcu_commands {
> > /* available if STS_FEATURES_SUPPORTED bit set in status word */
> > CMD_GET_FEATURES= 0x10,
> > +
> > +   /* available if EXT_CMD bit set in features */
> > +   CMD_EXT_CONTROL = 0x12,
> >   };
> >   enum status_word_bits {
> > @@ -81,6 +86,16 @@ enum status_word_bits {
> >   /* CMD_GET_FEATURES */
> >   enum features_e {
> > FEAT_PERIPH_MCU = BIT(0),
> > +   FEAT_EXT_CMDS   = BIT(1),
> > +};
> > +
> > +/* CMD_EXT_CONTROL */
> > +enum ext_ctl_e {
> > +   EXT_CTL_nRES_LAN= BIT(1),
> > +   EXT_CTL_nRES_PHY= BIT(2),
> > +   EXT_CTL_nPERST0 = BIT(3),
> > +   EXT_CTL_nPERST1 = BIT(4),
> > +   EXT_CTL_nPERST2 = BIT(5),
> >   };
> >   /*
> > @@ -543,6 +558,90 @@ static void handle_reset_button(void)
> > }
> >   }
> > +static void initialize_switch(void)
> > +{
> > +   u32 val, val04, val08, val10, val14;
> > +   u16 ctrl[2];
> > +   int err;
> > +
> > +   printf("Initializing LAN eth switch... ");
> > +
> > +   /* Change RGMII pins to GPIO mode */
> > +
> > +   val = val04 = readl(MVEBU_

Re: [GIT PULL] please pull fsl-qoirq-2022-7-29

[Tom Rini]

On Mon, Aug 01, 2022 at 01:00:34AM +, Peng Fan wrote:

> Hi Tom,
> 
> Please pull fsl-qoriq-2022-7-29
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

cmd_process warning

[Sergei Antonov]

Hello!
There is an annoying warning about conflicting return types:

common/command.c:586:20: warning: conflicting types for 'cmd_process'
due to enum/integer mismatch; have 'enum command_ret_t(int,  int,
char * const*, int *, ulong *)' {aka 'enum command_ret_t(int,  int,
char * const*, int *, long unsigned int *)'} [-Wenum-int-mismatch]
In file included from common/command.c:13:
include/command.h:234:5: note: previous declaration of 'cmd_process'
with type 'int(int,  int,  char * const*, int *, long unsigned int *)'

It can be fixed by replacing 'int' with 'enum command_ret_t' in
include/command.h

Re: [PATCH 2/2] arm: mvebu: turris_omnia: Add support for design with SW reset signals

[Stefan Roese]

On 29.07.22 13:29, Pali Rohár wrote:

New Turris Omnia HW board revision requires that software controls
peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
phy reset and lan switch reset. Those pins are connected to MCU controlled
by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
after board reset and software has to release these peripherals from reset
manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
CMD_GET_FEATURES command.

On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
those reset signals are automatically released after board finish reset.

Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
functions and insert into device tree blob pcie "reset-gpios" and eth phy
"phy-reset-gpios" properties with corresponding MCU gpio definitions.
PCIe and eth PHY drivers then automatically release resets during device
initialization. Both U-Boot and Linux kernel drivers support those device
tree reset properties.

Initialization of lan switch on new HW board revision is more complicated.
Switch strapping pins are shared with switch RGMII pins. And strapping pins
must be in specific configuration after releasing switch reset. Due to pin
sharing, it is first required to switch A385 side of switch pins into GPIO
mode, set strapping configuration, release switch from reset and after that
switch A385 pins back to RGMII mode.

Because this complicated setup is not supported by switch DSA drivers and
cannot be expressed easily in device tree, implement it manually in SPL
function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
switch initialized and be in same configuration like it was on old HW board
revisions (where reset sequence did those steps at hardware level).

Signed-off-by: Pali Rohár 


Wow, this looks pretty complex. But I assume that you already de-stilled
the "best solution", so:

Reviewed-by: Stefan Roese 

Thanks,
Stefan



---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 226 +++
  1 file changed, 226 insertions(+)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 6fc2018c1cfb..e262ea1aba51 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -19,9 +19,11 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "../drivers/ddr/marvell/a38x/ddr3_init.h"

@@ -65,6 +67,9 @@ enum mcu_commands {
  
  	/* available if STS_FEATURES_SUPPORTED bit set in status word */

CMD_GET_FEATURES= 0x10,
+
+   /* available if EXT_CMD bit set in features */
+   CMD_EXT_CONTROL = 0x12,
  };
  
  enum status_word_bits {

@@ -81,6 +86,16 @@ enum status_word_bits {
  /* CMD_GET_FEATURES */
  enum features_e {
FEAT_PERIPH_MCU = BIT(0),
+   FEAT_EXT_CMDS   = BIT(1),
+};
+
+/* CMD_EXT_CONTROL */
+enum ext_ctl_e {
+   EXT_CTL_nRES_LAN= BIT(1),
+   EXT_CTL_nRES_PHY= BIT(2),
+   EXT_CTL_nPERST0 = BIT(3),
+   EXT_CTL_nPERST1 = BIT(4),
+   EXT_CTL_nPERST2 = BIT(5),
  };
  
  /*

@@ -543,6 +558,90 @@ static void handle_reset_button(void)
}
  }
  
+static void initialize_switch(void)

+{
+   u32 val, val04, val08, val10, val14;
+   u16 ctrl[2];
+   int err;
+
+   printf("Initializing LAN eth switch... ");
+
+   /* Change RGMII pins to GPIO mode */
+
+   val = val04 = readl(MVEBU_MPP_BASE + 0x04);
+   val &= ~GENMASK(19, 16); /* MPP[12] := GPIO */
+   val &= ~GENMASK(23, 20); /* MPP[13] := GPIO */
+   val &= ~GENMASK(27, 24); /* MPP[14] := GPIO */
+   val &= ~GENMASK(31, 28); /* MPP[15] := GPIO */
+   writel(val, MVEBU_MPP_BASE + 0x04);
+
+   val = val08 = readl(MVEBU_MPP_BASE + 0x08);
+   val &= ~GENMASK(3, 0);   /* MPP[16] := GPIO */
+   val &= ~GENMASK(23, 20); /* MPP[21] := GPIO */
+   writel(val, MVEBU_MPP_BASE + 0x08);
+
+   val = val10 = readl(MVEBU_MPP_BASE + 0x10);
+   val &= ~GENMASK(27, 24); /* MPP[38] := GPIO */
+   val &= ~GENMASK(31, 28); /* MPP[39] := GPIO */
+   writel(val, MVEBU_MPP_BASE + 0x10);
+
+   val = val14 = readl(MVEBU_MPP_BASE + 0x14);
+   val &= ~GENMASK(3, 0);   /* MPP[40] := GPIO */
+   val &= ~GENMASK(7, 4);   /* MPP[41] := GPIO */
+   writel(val, MVEBU_MPP_BASE + 0x14);
+
+   /* Set initial values for switch reset strapping pins */
+
+   val = readl(MVEBU_GPIO0_BASE + 0x00);
+   val |= BIT(12); /* GPIO[12] := 1 */
+   val |= BIT(13); /* GPIO[13] := 1 */
+   val |= BIT(14); /* GPIO[14] := 1 */
+   val |= BIT(15); /* GPIO[15] := 1 */
+   val &= ~BIT(16);/* GPIO[16] := 0 */
+   val |= BIT(21); /* GPIO[21] := 1 */
+   writel(val, MVEBU_GPIO0_BASE + 0x00);
+
+   val = readl(MVEBU_GPIO1_BASE + 0x00);
+   v

Re: [PATCH 1/2] arm: mvebu: turris_omnia: Show MCU type in show_board_info()

[Stefan Roese]

On 29.07.22 13:29, Pali Rohár wrote:

Different Turris Omnia HW board revisions contains different MCU.
Show type in show_board_info() to easily identify which MCU is populated.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 45 
  1 file changed, 45 insertions(+)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index b169abca0956..6fc2018c1cfb 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -62,13 +62,27 @@ enum mcu_commands {
CMD_GET_STATUS_WORD = 0x01,
CMD_GET_RESET   = 0x09,
CMD_WATCHDOG_STATE  = 0x0b,
+
+   /* available if STS_FEATURES_SUPPORTED bit set in status word */
+   CMD_GET_FEATURES= 0x10,
  };
  
  enum status_word_bits {

+   STS_MCU_TYPE_MASK   = GENMASK(1, 0),
+   STS_MCU_TYPE_STM32  = 0,
+   STS_MCU_TYPE_GD32   = 1,
+   STS_MCU_TYPE_MKL= 2,
+   STS_MCU_TYPE_UNKN   = 3,
+   STS_FEATURES_SUPPORTED  = BIT(2),
CARD_DET_STSBIT = 0x0010,
MSATA_IND_STSBIT= 0x0020,
  };
  
+/* CMD_GET_FEATURES */

+enum features_e {
+   FEAT_PERIPH_MCU = BIT(0),
+};
+
  /*
   * Those values and defines are taken from the Marvell U-Boot version
   * "u-boot-2013.01-2014_T3.0"
@@ -371,6 +385,36 @@ static int omnia_get_ram_size_gb(void)
return ram_size;
  }
  
+static const char * const omnia_get_mcu_type(void)

+{
+   static const char * const mcu_types[] = {
+   [STS_MCU_TYPE_STM32] = "STM32",
+   [STS_MCU_TYPE_GD32]  = "GD32",
+   [STS_MCU_TYPE_MKL]   = "MKL",
+   [STS_MCU_TYPE_UNKN]  = "unknown",
+   };
+   static const char * const mcu_types_with_perip_resets[] = {
+   [STS_MCU_TYPE_STM32] = "STM32 (with peripheral resets)",
+   [STS_MCU_TYPE_GD32]  = "GD32 (with peripheral resets)",
+   [STS_MCU_TYPE_MKL]   = "MKL (with peripheral resets)",
+   [STS_MCU_TYPE_UNKN]  = "unknown (with peripheral resets)",
+   };
+   u16 stsword, features;
+   int ret;
+
+   ret = omnia_mcu_read(CMD_GET_STATUS_WORD, &stsword, sizeof(stsword));
+   if (ret)
+   return "unknown";
+
+   if (stsword & STS_FEATURES_SUPPORTED) {
+   ret = omnia_mcu_read(CMD_GET_FEATURES, &features, 
sizeof(features));
+   if (ret == 0 && (features & FEAT_PERIPH_MCU))
+   return mcu_types_with_perip_resets[stsword & 
STS_MCU_TYPE_MASK];
+   }
+
+   return mcu_types[stsword & STS_MCU_TYPE_MASK];
+}
+
  /*
   * Define the DDR layout / topology here in the board file. This will
   * be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -688,6 +732,7 @@ int show_board_info(void)
  
  	err = turris_atsha_otp_get_serial_number(&version_num, &serial_num);

printf("Model: Turris Omnia\n");
+   printf("  MCU type: %s\n", omnia_get_mcu_type());
printf("  RAM size: %i MiB\n", omnia_get_ram_size_gb() * 1024);
if (err)
printf("  Serial Number: unknown\n");


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de