Re: [PATCH v3 1/6] binman: ti-secure: Add support for firewalling entities

2023-10-09 Thread Manorit Chawdhry
Hi Simon,

On 11:56-20231009, Simon Glass wrote:
> Hi Manorit,
> 
> On Mon, 9 Oct 2023 at 01:43, Manorit Chawdhry  wrote:
> >
> > Hi Simon,
> >
> > On 17:10-20231007, Simon Glass wrote:
> > > Hi Manorit,
> > >
> > > On Wed, 4 Oct 2023 at 06:32, Manorit Chawdhry  wrote:
> > > >
> > > > We can now firewall entities while loading them through our secure
> > > > entity TIFS, the required information should be present in the
> > > > certificate that is being parsed by TIFS.
> > > >
> > > > The following commit adds the support to enable the certificates to be
> > > > generated if the firewall configurations are present in the binman
> dtsi
> > > > nodes.
> > > >
> > > > Signed-off-by: Manorit Chawdhry 
> > > > ---
> > > >  tools/binman/btool/openssl.py   | 16 +++-
> > > >  tools/binman/etype/ti_secure.py | 85
> +
> > > >  tools/binman/etype/x509_cert.py |  3 +-
> > > >  3 files changed, 101 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/tools/binman/btool/openssl.py
> b/tools/binman/btool/openssl.py
> > > > index aad3b61ae27c..dff439df211f 100644
> > > > --- a/tools/binman/btool/openssl.py
> > > > +++ b/tools/binman/btool/openssl.py
> > > > @@ -82,7 +82,7 @@ imageSize  = INTEGER:{len(indata)}
> > > >  return self.run_cmd(*args)
> > > >
> > > >  def x509_cert_sysfw(self, cert_fname, input_fname, key_fname,
> sw_rev,
> > > > -  config_fname, req_dist_name_dict):
> > > > +  config_fname, req_dist_name_dict,
> firewall_cert_data):
> > > >  """Create a certificate to be booted by system firmware
> > > >
> > > >  Args:
> > > > @@ -94,6 +94,13 @@ imageSize  = INTEGER:{len(indata)}
> > > >  req_dist_name_dict (dict): Dictionary containing
> key-value pairs of
> > > >  req_distinguished_name section extensions, must contain
> extensions for
> > > >  C, ST, L, O, OU, CN and emailAddress
> > > > +firewall_cert_data (dict):
> > > > +  - auth_in_place (int): The Priv ID for copying as the
> > > > +specific host in firewall protected region
> > > > +  - num_firewalls (int): The number of firewalls in the
> > > > +extended certificate
> > > > +  - certificate (str): Extended firewall certificate with
> > > > +the information for the firewall configurations.
> > > >
> > > >  Returns:
> > > >  str: Tool output
> > > > @@ -121,6 +128,7 @@ basicConstraints   = CA:true
> > > >  1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
> > > >  1.3.6.1.4.1.294.1.34   = ASN1:SEQUENCE:sysfw_image_integrity
> > > >  1.3.6.1.4.1.294.1.35   = ASN1:SEQUENCE:sysfw_image_load
> > > > +1.3.6.1.4.1.294.1.37   = ASN1:SEQUENCE:firewall
> > > >
> > > >  [ swrv ]
> > > >  swrv = INTEGER:{sw_rev}
> > > > @@ -132,7 +140,11 @@ imageSize  = INTEGER:{len(indata)}
> > > >
> > > >  [ sysfw_image_load ]
> > > >  destAddr = FORMAT:HEX,OCT:
> > > > -authInPlace = INTEGER:2
> > > > +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> > > > +
> > > > +[ firewall ]
> > > > +numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
> > > > +{firewall_cert_data['certificate']}
> > >
> > > Do we want the text above if there is no firewall info?
> > >
> >
> > Yes, keeping numFirewallRegions = INTEGER:0 is valid. The other way would
> be
> > to remove OIDs and everything that we have kept in the certificate when
> > firewall nodes are not present but that seems a bit more difficult given
> > that we have an easy fix keeping the numFirewallRegions as 0.
> 
> OK
> 
> >
> > > >  ''', file=outf)
> > > >  args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
> > > >  '-outform', 'DER', '-out', cert_fname, '-config',
> config_fname,
> > > > diff --git a/tools/binman/etype/ti_secure.py
> b/tools/binman/etype/ti_secure.py
> > > > index d939dce57139.

Re: [PATCH v2 22/27] efi: Depend on CMDLINE for efi_loader

2023-10-09 Thread AKASHI Takahiro
Hi Simon,

On Sat, Oct 07, 2023 at 05:12:41PM -0600, Simon Glass wrote:
> This features currently requires the command line, so make this
> explicit. Future work could adjust this, but it needs effort within
> the booting support first, like the bootm command.

I a bit doubt this dependency.
EFI_LOADER as library functions doesn't rely on command line support.
What does is, as you mentioned, "bootefi bootmgr" command.
So a more appropriate dependency would be

CMD_BOOTEFI_BOOTMGR
depends on CMDLINE

CMD_BOOTEFI
depends on CMDLINE

CMD_EFICONFIG
depends on CMD_BOOTEFI_BOOTMGR

# CMD_EFIDEBUG can compile without CMD_BOOTEFI_BOOTMGR.

# In my opinion, CMD_BOOTEFI_BOOTMGR should be split into cmd part
  and library part.

-Takahiro Akashi

> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  lib/efi_loader/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 621ed5e5b0fb..2aef9336034e 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -12,6 +12,7 @@ config EFI_LOADER
>   depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
>   depends on BLK
>   depends on !EFI_APP
> + depends on CMDLINE
>   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
>   select CHARSET
>   # We need to send DM events, dynamically, in the EFI block driver
> -- 
> 2.42.0.609.gbb76f46606-goog
> 


[PATCH v2] net: phy: xilinx_phy: Get rid of using property xlnx, phy-type

2023-10-09 Thread Venkatesh Yadav Abbarapu
As the xlnx,phy-type device tree property is deprecated and phy-mode
is being used, so removing the code references of xlnx,phy-type.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
Changes in v2:
- Removed phytype variable.
---
 drivers/net/phy/xilinx_phy.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/phy/xilinx_phy.c b/drivers/net/phy/xilinx_phy.c
index 1df639d6f4..c07c780193 100644
--- a/drivers/net/phy/xilinx_phy.c
+++ b/drivers/net/phy/xilinx_phy.c
@@ -99,7 +99,6 @@ static int xilinxphy_startup(struct phy_device *phydev)
 
 static int xilinxphy_of_init(struct phy_device *phydev)
 {
-   u32 phytype;
ofnode node;
 
debug("%s\n", __func__);
@@ -107,10 +106,6 @@ static int xilinxphy_of_init(struct phy_device *phydev)
if (!ofnode_valid(node))
return -EINVAL;
 
-   phytype = ofnode_read_u32_default(node, "xlnx,phy-type", -1);
-   if (phytype == XAE_PHY_TYPE_1000BASE_X)
-   phydev->flags |= XAE_PHY_TYPE_1000BASE_X;
-
return 0;
 }
 
-- 
2.17.1



Re: [PATCH 07/25] tegra: Change #ifdef for nop

2023-10-09 Thread Sean Anderson

On 10/9/23 11:32, Simon Glass wrote:

Hi Sean,

On Sat, 7 Oct 2023 at 17:21, Sean Anderson  wrote:


On 10/7/23 19:10, Simon Glass wrote:

Hi Tom.

On Sun, 24 Sept 2023 at 18:43, Tom Rini  wrote:


On Sun, Sep 24, 2023 at 02:39:25PM -0600, Simon Glass wrote:


This code is normally compiled for Tegra, but sandbox can also compile
it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
possible to disable UNIT_TEST for sandbox.

Correct the condition.

Signed-off-by: Simon Glass 
---

   include/k210/pll.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/k210/pll.h b/include/k210/pll.h
index fd16a89cb203..6dd60b2eb4fc 100644
--- a/include/k210/pll.h
+++ b/include/k210/pll.h
@@ -13,7 +13,7 @@ struct k210_pll_config {
u8 od;
   };

-#ifdef CONFIG_UNIT_TEST
+#ifdef CONFIG_SANDBOX
   TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
 struct k210_pll_config *best);
   #ifndef nop


Tegra? Do you mean sifive?  That's where CLK_K210 stuff is... but it


Oh yes, I got confused.


also seems wrong, you can run unit test on real hardware, and this is a
test that could (should?) be run on that platform.


Only if it enables UNIT_TEST. You cannot run unit tests without that.
The current tests are designed for sandbox.


FWIW I have run this test on actual hardware. My intent here was to allow
unit tests to access functions which would otherwise be declared static.


Er, with or without UNIT_TEST enabled? How can it even build if this
declaration is only for sandbox?


With UNIT_TEST of course. Although since this is a forward-declaration, the
UNIT_TEST ifdef isn't really even necessary. If it's on actual hardware, nop
should already be defined. So maybe this should be something like

#if CONFIG_SANDBOX
#define nop()
#endif

--Sean



[PATCH] ARM: dts: stm32mp: Repair damage from alignment with v6.3

2023-10-09 Thread Marek Vasut
The patch fixed by this commit renders ST STM32MP15xx EV1 board and
all DHSOM SoM based boards unbootable from SPI NOR. Fix the damage
by updating -u-boot.dtsi to match the stm32mp15-pinctrl.dtsi update.

Fixes: 08002ffd083d ("ARM: dts: stm32mp: alignment with v6.3")
Signed-off-by: Marek Vasut 
---
NOTE: It is truly incomprehensible how 08002ffd083d was ever tested
  at ST, I can only speculate it never was tested at all, grumb.
---
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: u-b...@dh-electronics.com
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi   | 16 
 arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 12 +++-
 arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi |  8 ++--
 3 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
index 1f7fdbce530..eb283cacd27 100644
--- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
@@ -135,20 +135,28 @@
 
 _bk1_pins_a {
bootph-pre-ram;
-   pins1 {
+   pins {
bootph-pre-ram;
};
-   pins2 {
+};
+
+_cs1_pins_a {
+   bootph-pre-ram;
+   pins {
bootph-pre-ram;
};
 };
 
 _bk2_pins_a {
bootph-pre-ram;
-   pins1 {
+   pins {
bootph-pre-ram;
};
-   pins2 {
+};
+
+_cs2_pins_a {
+   bootph-pre-ram;
+   pins {
bootph-pre-ram;
};
 };
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index f12941b05f6..2f70b0690d2 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -134,20 +134,14 @@
 
 _bk1_pins_a {
bootph-pre-ram;
-   pins1 {
-   bootph-pre-ram;
-   };
-   pins2 {
+   pins {
bootph-pre-ram;
};
 };
 
-_bk2_pins_a {
+_cs1_pins_a {
bootph-pre-ram;
-   pins1 {
-   bootph-pre-ram;
-   };
-   pins2 {
+   pins {
bootph-pre-ram;
};
 };
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index eb905ad2820..552b35db3c7 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -98,10 +98,14 @@
 
 _bk1_pins_a {
bootph-pre-ram;
-   pins1 {
+   pins {
bootph-pre-ram;
};
-   pins2 {
+};
+
+_cs1_pins_a {
+   bootph-pre-ram;
+   pins {
bootph-pre-ram;
};
 };
-- 
2.40.1



[PATCH] cmd: mmc: Add mmc reg read command for reading card registers

2023-10-09 Thread Marek Vasut
Add extension to the 'mmc' command to read out the card registers.
Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are
supported. A register value can either be displayed or read into
an environment variable.

Signed-off-by: Marek Vasut 
---
Cc: Abdellatif El Khlifi 
Cc: Heinrich Schuchardt 
Cc: Ilias Apalodimas 
Cc: Jaehoon Chung 
Cc: Ramon Fried 
Cc: Roger Knecht 
Cc: Sean Edmond 
Cc: Simon Glass 
Cc: Tobias Waldekranz 
---
 cmd/Kconfig |  8 +
 cmd/mmc.c   | 96 +
 2 files changed, 104 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6470b138d2f..dcd99757a1e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1307,6 +1307,14 @@ config CMD_BKOPS_ENABLE
  on a eMMC device. The feature is optionally available on eMMC devices
  conforming to standard >= 4.41.
 
+config CMD_MMC_REG
+   bool "Enable support for reading card registers in the mmc command"
+   depends on CMD_MMC
+   default n
+   help
+ Enable the commands for reading card registers. This is useful
+ mostly for debugging or extracting details from the card.
+
 config CMD_MMC_RPMB
bool "Enable support for RPMB in the mmc command"
depends on SUPPORT_EMMC_RPMB
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c6bd81cebbc..c29f44b7a18 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -1110,6 +1110,93 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int 
flag,
return CMD_RET_SUCCESS;
 }
 
+#if CONFIG_IS_ENABLED(CMD_MMC_REG)
+static int do_mmc_reg(struct cmd_tbl *cmdtp, int flag,
+ int argc, char *const argv[])
+{
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+   struct mmc *mmc;
+   int i, ret;
+   u32 off;
+
+   if (argc < 3 || argc > 5)
+   return CMD_RET_USAGE;
+
+   mmc = find_mmc_device(curr_device);
+   if (!mmc) {
+   printf("no mmc device at slot %x\n", curr_device);
+   return CMD_RET_FAILURE;
+   }
+
+   if (IS_SD(mmc)) {
+   printf("SD registers are not supported\n");
+   return CMD_RET_FAILURE;
+   }
+
+   off = simple_strtoul(argv[3], NULL, 10);
+   if (!strcmp(argv[2], "cid")) {
+   if (off > 3)
+   return CMD_RET_USAGE;
+   printf("CID[%i]: 0x%08x\n", off, mmc->cid[off]);
+   if (argv[4])
+   env_set_hex(argv[4], mmc->cid[off]);
+   return CMD_RET_SUCCESS;
+   }
+   if (!strcmp(argv[2], "csd")) {
+   if (off > 3)
+   return CMD_RET_USAGE;
+   printf("CSD[%i]: 0x%08x\n", off, mmc->csd[off]);
+   if (argv[4])
+   env_set_hex(argv[4], mmc->csd[off]);
+   return CMD_RET_SUCCESS;
+   }
+   if (!strcmp(argv[2], "dsr")) {
+   printf("DSR: 0x%08x\n", mmc->dsr);
+   if (argv[4])
+   env_set_hex(argv[4], mmc->dsr);
+   return CMD_RET_SUCCESS;
+   }
+   if (!strcmp(argv[2], "ocr")) {
+   printf("OCR: 0x%08x\n", mmc->ocr);
+   if (argv[4])
+   env_set_hex(argv[4], mmc->ocr);
+   return CMD_RET_SUCCESS;
+   }
+   if (!strcmp(argv[2], "rca")) {
+   printf("RCA: 0x%08x\n", mmc->rca);
+   if (argv[4])
+   env_set_hex(argv[4], mmc->rca);
+   return CMD_RET_SUCCESS;
+   }
+   if (!strcmp(argv[2], "extcsd") &&
+   mmc->version >= MMC_VERSION_4_41) {
+   ret = mmc_send_ext_csd(mmc, ext_csd);
+   if (ret)
+   return ret;
+   if (!strcmp(argv[3], "all")) {
+   /* Dump the entire register */
+   printf("EXT_CSD:");
+   for (i = 0; i < MMC_MAX_BLOCK_LEN; i++) {
+   if (!(i % 10))
+   printf("\n%03i: ", i);
+   printf(" %02x", ext_csd[i]);
+   }
+   printf("\n");
+   return CMD_RET_SUCCESS;
+   }
+   off = simple_strtoul(argv[3], NULL, 10);
+   if (off > 512)
+   return CMD_RET_USAGE;
+   printf("EXT_CSD[%i]: 0x%02x\n", off, ext_csd[off]);
+   if (argv[4])
+   env_set_hex(argv[4], ext_csd[off]);
+   return CMD_RET_SUCCESS;
+   }
+
+   return CMD_RET_FAILURE;
+}
+#endif
+
 static struct cmd_tbl cmd_mmc[] = {
U_BOOT_CMD_MKENT(info, 1, 0, do_mmcinfo, "", ""),
U_BOOT_CMD_MKENT(read, 4, 1, do_mmc_read, "", ""),
@@ -1142,6 +1229,9 @@ static struct cmd_tbl cmd_mmc[] = {
U_BOOT_CMD_MKENT(bkops-enable, 2, 0, do_mmc_bkops_enable, "", ""),
U_BOOT_CMD_MKENT(bkops, 4, 0, do_mmc_bkops, "", ""),
 #endif
+#if 

[PATCH v4 3/3] dt-bindings: mtd: binman-partitions: Add alignment properties

2023-10-09 Thread Simon Glass
Add three properties for controlling alignment of partitions, aka
'entries' in binman.

For now there is no explicit mention of hierarchy, so a 'section' is
just the 'binman' node.

These new properties are inputs to the packaging process, but are also
needed if the firmware is repacked, to ensure that alignment
constraints are not violated. Therefore they are provided as part of
the schema.

Signed-off-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- Fix 'a' typo in commit message

 .../mtd/partitions/binman-partition.yaml  | 39 +++
 1 file changed, 39 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
index 35a320359ec1..8e8a3b6d4d14 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
@@ -28,6 +28,42 @@ properties:
   - const: u-boot   # u-boot.bin from U-Boot project
   - const: atf-bl31 # bl31.bin or bl31.elf from TF-A project
 
+  align:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the entry. The entry offset is adjusted
+  so that the entry starts on an aligned boundary within the containing
+  section or image. For example ‘align = <16>’ means that the entry will
+  start on a 16-byte boundary. This may mean that padding is added before
+  the entry. The padding is part of the containing section but is not
+  included in the entry, meaning that an empty space may be created before
+  the entry starts. Alignment should be a power of 2. If ‘align’ is not
+  provided, no alignment is performed.
+
+  align-size:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the entry size. For example, to ensure
+  that the size of an entry is a multiple of 64 bytes, set this to 64.
+  While this does not affect the contents of the entry within binman
+  itself (the padding is performed only when its parent section is
+  assembled), the end result is that the entry ends with the padding
+  bytes, so may grow. If ‘align-size’ is not provided, no alignment is
+  performed.
+
+  align-end:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the end of an entry with respect to the
+  containing section. Some entries require that they end on an alignment
+  boundary, regardless of where they start. This does not move the start
+  of the entry, so the contents of the entry will still start at the
+  beginning. But there may be padding at the end. While this does not
+  affect the contents of the entry within binman itself (the padding is
+  performed only when its parent section is assembled), the end result is
+  that the entry ends with the padding bytes, so may grow. If ‘align-end’
+  is not provided, no alignment is performed.
+
 additionalProperties: false
 
 examples:
@@ -40,10 +76,13 @@ examples:
 partition@10 {
 compatible = "u-boot";
 reg = <0x10 0xf0>;
+align-size = <0x1000>;
+align-end = <0x1>;
 };
 
 partition@20 {
 compatible = "atf-bl31";
 reg = <0x20 0x10>;
+align = <0x4000>;
 };
 };
-- 
2.42.0.609.gbb76f46606-goog



[PATCH v4 2/3] dt-bindings: mtd: binman-partition: Add binman compatibles

2023-10-09 Thread Simon Glass
Add two compatible for binman entries, as a starting point for the
schema.

Note that, after discussion on v2, we decided to keep the existing
meaning of label so as not to require changes to existing userspace
software when moving to use binman nodes to specify the firmware
layout.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Correct selection of multiple compatible strings

Changes in v3:
- Drop fixed-partitions from the example
- Use compatible instead of label

Changes in v2:
- Use plain partition@xxx for the node name

 .../mtd/partitions/binman-partition.yaml  | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml

diff --git 
a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
new file mode 100644
index ..35a320359ec1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman-partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman partition
+
+maintainers:
+  - Simon Glass 
+
+select: false
+
+description: |
+  This corresponds to a binman 'entry'. It is a single partition which holds
+  data of a defined type.
+
+allOf:
+  - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - const: binman,entry # generic binman entry
+  - items:
+  - const: u-boot   # u-boot.bin from U-Boot project
+  - const: atf-bl31 # bl31.bin or bl31.elf from TF-A project
+
+additionalProperties: false
+
+examples:
+  - |
+partitions {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+compatible = "u-boot";
+reg = <0x10 0xf0>;
+};
+
+partition@20 {
+compatible = "atf-bl31";
+reg = <0x20 0x10>;
+};
+};
-- 
2.42.0.609.gbb76f46606-goog



[PATCH v4 1/3] dt-bindings: mtd: partitions: Add binman compatible

2023-10-09 Thread Simon Glass
Add a compatible string for binman, so we can extend fixed-partitions
in various ways.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Change subject line

Changes in v3:
- Drop fixed-partition additional compatible string
- Drop fixed-partitions from the example
- Mention use of compatible instead of label

Changes in v2:
- Drop mention of 'enhanced features' in fixed-partitions.yaml
- Mention Binman input and output properties
- Use plain partition@xxx for the node name

 .../bindings/mtd/partitions/binman.yaml   | 63 +++
 .../bindings/mtd/partitions/partitions.yaml   |  1 +
 MAINTAINERS   |  5 ++
 3 files changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml

diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index ..7d6c8bd738f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman firmware layout
+
+maintainers:
+  - Simon Glass 
+
+select: false
+
+description: |
+  The binman node provides a layout for firmware, used when packaging firmware
+  from multiple projects. It is based on fixed-partitions, with some
+  extensions, but uses 'compatible' to indicate the contents of the node, to
+  avoid perturbing or confusing existing installations which use 'label' for a
+  particular purpose.
+
+  Binman supports properties used as inputs to the firmware-packaging process,
+  such as those which control alignment of partitions. This binding addresses
+  these 'input' properties. For example, it is common for the 'reg' property
+  (an 'output' property) to be set by Binman, based on the alignment requested
+  in the input.
+
+  Once processing is complete, input properties have mostly served their
+  purpose, at least until the firmware is repacked later, e.g. due to a
+  firmware update. The 'fixed-partitions' binding should provide enough
+  information to read the firmware at runtime, including decompression if
+  needed.
+
+  Documentation for Binman is available at:
+
+  https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
+
+  with the current image-description format at:
+
+  
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
+
+allOf:
+  - $ref: /schemas/mtd/partitions/fixed-partitions.yaml#
+
+properties:
+  compatible:
+const: binman
+
+additionalProperties: false
+
+examples:
+  - |
+partitions {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+label = "u-boot";
+reg = <0x10 0xf0>;
+};
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
index 1dda2c80747b..849fd15d085c 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -15,6 +15,7 @@ maintainers:
 
 oneOf:
   - $ref: arm,arm-firmware-suite.yaml
+  - $ref: binman.yaml
   - $ref: brcm,bcm4908-partitions.yaml
   - $ref: brcm,bcm947xx-cfe-partitions.yaml
   - $ref: fixed-partitions.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index c934244acc31..ebc8158fe67d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3536,6 +3536,11 @@ F:   Documentation/filesystems/bfs.rst
 F: fs/bfs/
 F: include/uapi/linux/bfs_fs.h
 
+BINMAN
+M: Simon Glass 
+S: Supported
+F: Documentation/devicetree/bindings/mtd/partitions/binman*
+
 BITMAP API
 M: Yury Norov 
 R: Andy Shevchenko 
-- 
2.42.0.609.gbb76f46606-goog



Re: [PATCH v3 2/3] dt-bindings: mtd: binman-partition: Add binman compatibles

2023-10-09 Thread Simon Glass
Hi Rob,

On Mon, 9 Oct 2023 at 15:18, Rob Herring  wrote:
>
>
> On Mon, 09 Oct 2023 14:10:00 -0600, Simon Glass wrote:
> > Add two compatible for binman entries, as a starting point for the
> > schema.
> >
> > Note that, after discussion on v2, we decided to keep the existing
> > meaning of label so as not to require changes to existing userspace
> > software when moving to use binman nodes to specify the firmware
> > layout.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v3:
> > - Drop fixed-partitions from the example
> > - Use compatible instead of label
> >
> > Changes in v2:
> > - Use plain partition@xxx for the node name
> >
> >  .../mtd/partitions/binman-partition.yaml  | 48 +++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml:
>  properties:compatible:items: {'enum': ['u-boot', 'atf-bl31']} is not of type 
> 'array'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
>
> doc reference errors (make refcheckdocs):
>
> See 
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231009201005.1964794-2-...@chromium.org
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>

Oh dear, I didn't notice that output but I see it now. Could the check
return a non-zero exit code if something goes wrong?

Anyway, I'll send v4

Regards,
Simon


Re: [PATCH v3 2/3] dt-bindings: mtd: binman-partition: Add binman compatibles

2023-10-09 Thread Rob Herring


On Mon, 09 Oct 2023 14:10:00 -0600, Simon Glass wrote:
> Add two compatible for binman entries, as a starting point for the
> schema.
> 
> Note that, after discussion on v2, we decided to keep the existing
> meaning of label so as not to require changes to existing userspace
> software when moving to use binman nodes to specify the firmware
> layout.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v3:
> - Drop fixed-partitions from the example
> - Use compatible instead of label
> 
> Changes in v2:
> - Use plain partition@xxx for the node name
> 
>  .../mtd/partitions/binman-partition.yaml  | 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml:
 properties:compatible:items: {'enum': ['u-boot', 'atf-bl31']} is not of type 
'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#

doc reference errors (make refcheckdocs):

See 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231009201005.1964794-2-...@chromium.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



[PATCH v3] rockchip: rk3568-radxa-e25: Enable pcie3x1 node

2023-10-09 Thread Jonas Karlman
Enable mini PCIe slot, pcie3x1 node, now that the PCIe PHY driver
support bifurcation.

A pinctrl is assigned for reset-gpios or the device may freeze running
pci enum and nothing is connected to the mini PCIe slot.

Also drop the AHCI_PCI Kconfig option as this option is not required for
a functional M.2 SATA drive slot.

Signed-off-by: Jonas Karlman 
Reviewed-by: Kever Yang 
---
v3:
- Collect r-b tag

v2:
- No change

 arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 11 +--
 configs/radxa-e25-rk3568_defconfig|  1 -
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi 
b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi
index 572bdc5665b1..1136f0bb3b81 100644
--- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi
@@ -8,9 +8,16 @@
};
 };
 
-/* PCIe PHY driver in U-Boot does not support bifurcation */
  {
-   status = "disabled";
+   pinctrl-0 = <_reset_h>;
+};
+
+ {
+   pcie {
+   pcie30x1_reset_h: pcie30x1-reset-h {
+   rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO _pull_none>;
+   };
+   };
 };
 
  {
diff --git a/configs/radxa-e25-rk3568_defconfig 
b/configs/radxa-e25-rk3568_defconfig
index a905100a794d..2dfff6af3bd1 100644
--- a/configs/radxa-e25-rk3568_defconfig
+++ b/configs/radxa-e25-rk3568_defconfig
@@ -54,7 +54,6 @@ CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent 
assigned-clocks assigne
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
-CONFIG_AHCI_PCI=y
 CONFIG_DWC_AHCI=y
 CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
-- 
2.42.0



[PATCH] RFC: x86: serial: ns16550: Allow the UART to be silently disabled

2023-10-09 Thread Simon Glass
U-Boot normally requires a UART. When booting from coreboot it is
sometimes just not available, e.g. when no sysinfo or DBG2 information
is provided.

In this case we need to continue running, since the display can be used.
Add a flag to disable serial for this case.

This allows U-Boot to start up and operation from the display, instead
of hanging on start-up.

This could perhaps be hidden behind a Kconfig option to reduce code
size.

Signed-off-by: Simon Glass 
---

 drivers/serial/ns16550.c | 17 +++--
 drivers/serial/serial_coreboot.c |  1 +
 include/ns16550.h|  1 +
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index eab9537fbae..6bb84f8c5bc 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -384,6 +384,8 @@ static int ns16550_serial_putc(struct udevice *dev, const 
char ch)
 {
struct ns16550 *const com_port = dev_get_priv(dev);
 
+   if (com_port->plat->flags & NS16550_FLAG_DISABLE)
+   return 0;
if (!(serial_in(_port->lsr) & UART_LSR_THRE))
return -EAGAIN;
serial_out(ch, _port->thr);
@@ -404,6 +406,9 @@ static int ns16550_serial_pending(struct udevice *dev, bool 
input)
 {
struct ns16550 *const com_port = dev_get_priv(dev);
 
+   if (com_port->plat->flags & NS16550_FLAG_DISABLE)
+   return 0;
+
if (input)
return (serial_in(_port->lsr) & UART_LSR_DR) ? 1 : 0;
else
@@ -414,6 +419,9 @@ static int ns16550_serial_getc(struct udevice *dev)
 {
struct ns16550 *const com_port = dev_get_priv(dev);
 
+   if (com_port->plat->flags & NS16550_FLAG_DISABLE)
+   return 0;
+
if (!(serial_in(_port->lsr) & UART_LSR_DR))
return -EAGAIN;
 
@@ -428,7 +436,8 @@ static int ns16550_serial_setbrg(struct udevice *dev, int 
baudrate)
 
clock_divisor = ns16550_calc_divisor(com_port, plat->clock, baudrate);
 
-   ns16550_setbrg(com_port, clock_divisor);
+   if (!(plat->flags & NS16550_FLAG_DISABLE))
+   ns16550_setbrg(com_port, clock_divisor);
 
return 0;
 }
@@ -441,6 +450,9 @@ static int ns16550_serial_setconfig(struct udevice *dev, 
uint serial_config)
uint bits = SERIAL_GET_BITS(serial_config);
uint stop = SERIAL_GET_STOP(serial_config);
 
+   if (com_port->plat->flags & NS16550_FLAG_DISABLE)
+   return 0;
+
/*
 * only parity config is implemented, check if other serial settings
 * are the default one.
@@ -525,7 +537,8 @@ int ns16550_serial_probe(struct udevice *dev)
reset_deassert_bulk(_bulk);
 
com_port->plat = dev_get_plat(dev);
-   ns16550_init(com_port, -1);
+   if (!(plat->flags & NS16550_FLAG_DISABLE))
+   ns16550_init(com_port, -1);
 
return 0;
 }
diff --git a/drivers/serial/serial_coreboot.c b/drivers/serial/serial_coreboot.c
index 23066e4d054..cdf9afc1739 100644
--- a/drivers/serial/serial_coreboot.c
+++ b/drivers/serial/serial_coreboot.c
@@ -120,6 +120,7 @@ static int coreboot_of_to_plat(struct udevice *dev)
 * there is no UART, which may panic. So stay silent and
 * pray that the video console will work.
 */
+   plat->flags |= NS16550_FLAG_DISABLE;
log_debug("Cannot detect UART\n");
}
 
diff --git a/include/ns16550.h b/include/ns16550.h
index e7e68663d03..618bb4026b3 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -52,6 +52,7 @@ enum ns16550_flags {
NS16550_FLAG_IO = 1 << 0, /* Use I/O access (else mem-mapped) */
NS16550_FLAG_ENDIAN = 1 << 1, /* Use out_le/be_32() */
NS16550_FLAG_BE = 1 << 2, /* Big-endian access (else little) */
+   NS16550_FLAG_DISABLE= BIT(3), /* No output or input */
 };
 
 /**
-- 
2.42.0.609.gbb76f46606-goog



Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

2023-10-09 Thread Simon Glass
Hi all,

On Fri, 6 Oct 2023 at 18:03, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > It is common to split firmware into 'Platform Init', which does the
> > > > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > > > booted.
> > > > > > Thus an handover interface is required between these two pieces.
> > > > > >
> > > > > > Where UEFI boot-time services are not available, but UEFI firmware 
> > > > > > is
> > > > > > present on either side of this interface, information about memory 
> > > > > > usage
> > > > > > and attributes must be presented to the "Payload" in some form.
> > > > > >
> > > > > > This aims to provide an small schema addition for the memory mapping
> > > > > > needed to keep these two pieces working together well.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > >
> > > > > > Changes in v7:
> > > > > > - Rename acpi-reclaim to acpi
> > > > > > - Drop individual mention of when memory can be reclaimed
> > > > > > - Rewrite the item descriptions
> > > > > > - Add back the UEFI text (with trepidation)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Drop mention of UEFI
> > > > > > - Use compatible strings instead of node names
> > > > > >
> > > > > > Changes in v5:
> > > > > > - Drop the memory-map node (should have done that in v4)
> > > > > > - Tidy up schema a bit
> > > > > >
> > > > > > Changes in v4:
> > > > > > - Make use of the reserved-memory node instead of creating a new one
> > > > > >
> > > > > > Changes in v3:
> > > > > > - Reword commit message again
> > > > > > - cc a lot more people, from the FFI patch
> > > > > > - Split out the attributes into the /memory nodes
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Reword commit message
> > > > > >
> > > > > >  .../reserved-memory/common-reserved.yaml  | 71 
> > > > > > +++
> > > > > >  1 file changed, 71 insertions(+)
> > > > > >  create mode 100644 
> > > > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > >
> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > new file mode 100644
> > > > > > index 000..f7fbdfd
> > > > > > --- /dev/null
> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > @@ -0,0 +1,71 @@
> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: 
> > > > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Common memory reservations
> > > > > > +
> > > > > > +description: |
> > > > > > +  Specifies that the reserved memory region can be used for the 
> > > > > > purpose
> > > > > > +  indicated by its compatible string.
> > > > > > +
> > > > > > +  Clients may reuse this reserved memory if they understand what 
> > > > > > it is for,
> > > > > > +  subject to the notes below.
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Simon Glass 
> > > > > > +
> > > > > > +allOf:
> > > > > > +  - $ref: reserved-memory.yaml
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +description: |
> > > > > > +  This describes some common memory reservations, with the 
> > > > > > compatible
> > > > > > +  string indicating what it is used for:
> > > > > > +
> > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) 
> > > > > > tables
> > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This 
> > > > > > is reserved by
> > > > > > +   the firmware for its use and is required to be saved 
> > > > > > and restored
> > > > > > +   across an NVS sleep
> > > > > > + boot-code: Contains code used for booting which is not 
> > > > > > needed by the OS
> > > > > > + boot-code: Contains data used for booting which is not 
> > > > > > needed by the OS
> > > > > > + runtime-code: Contains code used for interacting with the 
> > > > > > system when
> > > > > > +   running the OS
> > > > > > + runtime-data: Contains data used for interacting with the 
> > > > > > system when
> > > > > > +   running the OS
> > > > > > +
> > > > > > +

[PATCH v3 3/3] dt-bindings: mtd: binman-partitions: Add alignment properties

2023-10-09 Thread Simon Glass
Add three properties for controlling alignment of partitions, aka
'entries' in binman.

For now there is no explicit mention of hierarchy, so a 'section' is
just the 'binman' node.

These new properties are inputs to the packaging process, but are also
needed if the firmware is repacked, to ensure that alignment
constraints are not violated. Therefore they are provided as part of
the schema.

Signed-off-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- Fix 'a' typo in commit message

 .../mtd/partitions/binman-partition.yaml  | 39 +++
 1 file changed, 39 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
index 754f804524a5..350014a93da4 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
@@ -27,6 +27,42 @@ properties:
 - u-boot   # u-boot.bin from U-Boot projec6t
 - atf-bl31 # bl31.bin or bl31.elf from TF-A project
 
+  align:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the entry. The entry offset is adjusted
+  so that the entry starts on an aligned boundary within the containing
+  section or image. For example ‘align = <16>’ means that the entry will
+  start on a 16-byte boundary. This may mean that padding is added before
+  the entry. The padding is part of the containing section but is not
+  included in the entry, meaning that an empty space may be created before
+  the entry starts. Alignment should be a power of 2. If ‘align’ is not
+  provided, no alignment is performed.
+
+  align-size:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the entry size. For example, to ensure
+  that the size of an entry is a multiple of 64 bytes, set this to 64.
+  While this does not affect the contents of the entry within binman
+  itself (the padding is performed only when its parent section is
+  assembled), the end result is that the entry ends with the padding
+  bytes, so may grow. If ‘align-size’ is not provided, no alignment is
+  performed.
+
+  align-end:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  This sets the alignment of the end of an entry with respect to the
+  containing section. Some entries require that they end on an alignment
+  boundary, regardless of where they start. This does not move the start
+  of the entry, so the contents of the entry will still start at the
+  beginning. But there may be padding at the end. While this does not
+  affect the contents of the entry within binman itself (the padding is
+  performed only when its parent section is assembled), the end result is
+  that the entry ends with the padding bytes, so may grow. If ‘align-end’
+  is not provided, no alignment is performed.
+
 additionalProperties: false
 
 examples:
@@ -39,10 +75,13 @@ examples:
 partition@10 {
 compatible = "u-boot";
 reg = <0x10 0xf0>;
+align-size = <0x1000>;
+align-end = <0x1>;
 };
 
 partition@20 {
 compatible = "atf-bl31";
 reg = <0x20 0x10>;
+align = <0x4000>;
 };
 };
-- 
2.42.0.609.gbb76f46606-goog



[PATCH v3 2/3] dt-bindings: mtd: binman-partition: Add binman compatibles

2023-10-09 Thread Simon Glass
Add two compatible for binman entries, as a starting point for the
schema.

Note that, after discussion on v2, we decided to keep the existing
meaning of label so as not to require changes to existing userspace
software when moving to use binman nodes to specify the firmware
layout.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Drop fixed-partitions from the example
- Use compatible instead of label

Changes in v2:
- Use plain partition@xxx for the node name

 .../mtd/partitions/binman-partition.yaml  | 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml

diff --git 
a/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
new file mode 100644
index ..754f804524a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman-partition.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman partition
+
+maintainers:
+  - Simon Glass 
+
+select: false
+
+description: |
+  This corresponds to a binman 'entry'. It is a single partition which holds
+  data of a defined type.
+
+allOf:
+  - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+  compatible:
+items:
+  enum:
+- u-boot   # u-boot.bin from U-Boot projec6t
+- atf-bl31 # bl31.bin or bl31.elf from TF-A project
+
+additionalProperties: false
+
+examples:
+  - |
+partitions {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+compatible = "u-boot";
+reg = <0x10 0xf0>;
+};
+
+partition@20 {
+compatible = "atf-bl31";
+reg = <0x20 0x10>;
+};
+};
-- 
2.42.0.609.gbb76f46606-goog



[PATCH v3 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible

2023-10-09 Thread Simon Glass
Add a compatible string for binman, so we can extend fixed-partitions
in various ways.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Drop fixed-partition additional compatible string
- Drop fixed-partitions from the example
- Mention use of compatible instead of label

Changes in v2:
- Drop mention of 'enhanced features' in fixed-partitions.yaml
- Mention Binman input and output properties
- Use plain partition@xxx for the node name

 .../bindings/mtd/partitions/binman.yaml   | 63 +++
 .../bindings/mtd/partitions/partitions.yaml   |  1 +
 MAINTAINERS   |  5 ++
 3 files changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml

diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index ..7d6c8bd738f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman firmware layout
+
+maintainers:
+  - Simon Glass 
+
+select: false
+
+description: |
+  The binman node provides a layout for firmware, used when packaging firmware
+  from multiple projects. It is based on fixed-partitions, with some
+  extensions, but uses 'compatible' to indicate the contents of the node, to
+  avoid perturbing or confusing existing installations which use 'label' for a
+  particular purpose.
+
+  Binman supports properties used as inputs to the firmware-packaging process,
+  such as those which control alignment of partitions. This binding addresses
+  these 'input' properties. For example, it is common for the 'reg' property
+  (an 'output' property) to be set by Binman, based on the alignment requested
+  in the input.
+
+  Once processing is complete, input properties have mostly served their
+  purpose, at least until the firmware is repacked later, e.g. due to a
+  firmware update. The 'fixed-partitions' binding should provide enough
+  information to read the firmware at runtime, including decompression if
+  needed.
+
+  Documentation for Binman is available at:
+
+  https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
+
+  with the current image-description format at:
+
+  
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
+
+allOf:
+  - $ref: /schemas/mtd/partitions/fixed-partitions.yaml#
+
+properties:
+  compatible:
+const: binman
+
+additionalProperties: false
+
+examples:
+  - |
+partitions {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+label = "u-boot";
+reg = <0x10 0xf0>;
+};
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml 
b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
index 1dda2c80747b..849fd15d085c 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -15,6 +15,7 @@ maintainers:
 
 oneOf:
   - $ref: arm,arm-firmware-suite.yaml
+  - $ref: binman.yaml
   - $ref: brcm,bcm4908-partitions.yaml
   - $ref: brcm,bcm947xx-cfe-partitions.yaml
   - $ref: fixed-partitions.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index c934244acc31..ebc8158fe67d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3536,6 +3536,11 @@ F:   Documentation/filesystems/bfs.rst
 F: fs/bfs/
 F: include/uapi/linux/bfs_fs.h
 
+BINMAN
+M: Simon Glass 
+S: Supported
+F: Documentation/devicetree/bindings/mtd/partitions/binman*
+
 BITMAP API
 M: Yury Norov 
 R: Andy Shevchenko 
-- 
2.42.0.609.gbb76f46606-goog



Re: [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible

2023-10-09 Thread Simon Glass
Hi Rob,

On Fri, 6 Oct 2023 at 10:11, Rob Herring  wrote:
>
> On Fri, Oct 06, 2023 at 10:37:41AM +0200, Michael Walle wrote:
> > Hi,
> >
> > > > I'm still not sure why that compatible is needed. Also I'd need to
> > > > change
> > > > the label which might break user space apps looking for that specific
> > > > name.
> > > >
> > > > Also, our board might have u-boot/spl or u-boot/spl/bl31/bl32, right
> > > > now
> > > > that's something which depends on an u-boot configuration variable,
> > > > which
> > > > then enables or disables binman nodes in the -u-boot.dtsi. So in linux
> > > > we only have that "bootloader" partition, but there might be either
> > > > u-boot+spl or u-boot+spl+bl31+bl32.
> > > >
> > > > Honestly, I'm really not sure this should go into a device tree.
> > >
> > > I think we might be getting a bit ahead of ourselves here. I thought
> > > that the decision was that the label should indicate the contents.
> > > If you have multiple things in a partition then it would become a
> > > 'section' in Binman's terminology. Either the label programmatically
> > > describes what is inside or it doesn't. We can't have it both ways.
> > > What do you suggest?
> >
> > As Rob pointed out earlier, it's just a user-facing string. I'm a bit
> > reluctant to use it programatically.
>
> In general, yes, but the partition stuff has long (and still) uses
> label. As long as the values the tools understand are documented (which
> we don't normally do for label), I don't care so much. That's my
> opinion as long as this is shared with fixed-partitions. If it is not
> and there's little reason to use label, then absolutely, I think
> 'compatible' makes more sense.

OK I will try to drop the sharing with fixed-partitions

>
> > Taking my example again, the string "bootloader" is sufficient for a
> > user. He doesn't care if it's u-boot with spl or u-boot with tfa, or
> > even coreboot. It just says, "in this partition is the bootloader".
> > If you have an "bootloader" image you can flash it there.
>
> These days, there's generally not just 1 bootloader in the boot flow.
> Maybe there's 1 image, maybe not. Being more specific is hardly ever a
> bad thing. Only when the number of specific things becomes multiple 10s
> or 100s of them does it become a problem.
>
>
> > If it has a label "u-boot" and I want to switch to coreboot, will
> > it have to change to "coreboot"? I really don't think this is practical,
> > you are really putting software configuration into the device tree.
>
> On the input side (to binman), yes it is config, but on the output side
> (to the running system) we are saying what's there.
>
>
> > > At present it seems you have the image described in two places - one
> > > is the binman node and the other is the partitions node. I would like
> > > to unify these.
> >
> > And I'm not sure that will work for all the corner cases :/
> >
> > If you keep the binman section seperate from the flash partition
> > definition you don't have any of these problems, although there is
> > some redundancy:
> >  - you only have compatible = "binman", "fixed-partition", no further
> >compatibles are required
> >  - you don't have any conflicts with the current partition descriptions
> >  - you could even use the labels, because binman is the (only?) user
> >
> > But of course you need to find a place where to put your node.
>
> And remove it. We don't need 2 sources of truth in the DTB.

I would certainly prefer to have one...I think using 'label' for the
existing case and 'compatible' for the new one could be a reasonable
compromise, so I will send v3.

Regards,
Simon


Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification

2023-10-09 Thread Sughosh Ganu
hi Simon,

On Mon, 9 Oct 2023 at 23:27, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu  wrote:
> >
> > hi Simon,
> >
> > On Sun, 8 Oct 2023 at 04:41, Simon Glass  wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu  wrote:
> > > >
> > > > The various fields of a generated capsule are currently verified
> > > > through hard-coded offsets. Use the dump-capsule feature for dumping
> > > > the capsule header contents and use those for capsule verification.
> > > >
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > >  tools/binman/ftest.py | 95 ---
> > > >  1 file changed, 54 insertions(+), 41 deletions(-)
> > >
> > > This looks good apart from a few nits below. However, the tests fail for 
> > > me.
> >
> > Can you please specify which tests fail, and the way to reproduce the
> > failures? I ran the tests before sending the patches, and they ran
> > fine, including the coverage which is 100%. Ci too did not complain.
>
> Sure, for example:
>
> $ binman test testCapsuleGen
>  Running binman tests 
> /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) 
> isn't supported in binary mode, the default buffer size will be used
>   return io.open(fd, mode, buffering, encoding, *args, **kwargs)
> /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) 
> isn't supported in binary mode, the default buffer size will be used
>   return io.open(fd, mode, buffering, encoding, *args, **kwargs)
> F
> ==
> FAIL: binman.ftest.TestFunctional.testCapsuleGen (subunit.RemotedTestCase)
> binman.ftest.TestFunctional.testCapsuleGen
> --
> testtools.testresult.real._StringException: Traceback (most recent call last):
> AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != []
>
>
> --
> Ran 1 test in 0.147s
>
> FAILED (failures=1)

That is interesting. When I run the tests, they run just fine. I had
tested them before sending the patches. For e.g.

./tools/binman/binman test testCapsuleGen
 Running binman tests 
.
--
Ran 1 test in 0.375s

OK

-sughosh

>
>
> >
> > >
> > > >
> > > > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> > > > index 8e419645a6..2b8871ab7e 100644
> > > > --- a/tools/binman/ftest.py
> > > > +++ b/tools/binman/ftest.py
> > > > @@ -121,9 +121,11 @@ COMP_BINTOOLS = ['bzip2', 'gzip', 'lz4', 
> > > > 'lzma_alone', 'lzop', 'xz', 'zstd']
> > > >  TEE_ADDR = 0x5678
> > > >
> > > >  # Firmware Management Protocol(FMP) GUID
> > > > -FW_MGMT_GUID = 'edd5cb6d2de8444cbda17194199ad92a'
> > > > +FW_MGMT_GUID = '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A'
> > > >  # Image GUID specified in the DTS
> > > > -CAPSULE_IMAGE_GUID = '52cfd7092007104791d108469b7fe9c8'
> > > > +CAPSULE_IMAGE_GUID = '09D7CF52-0720-4710-91D1-08469B7FE9C8'
> > > > +# Windows cert GUID
> > > > +WIN_CERT_TYPE_EFI_GUID = '4AAFD29D-68DF-49EE-8AA9-347D375665A7'
> > >
> > > Please use lower-case hex
> >
> > Okay
> >
> > >
> > > >
> > > >  class TestFunctional(unittest.TestCase):
> > > >  """Functional tests for binman
> > > > @@ -7223,52 +7225,63 @@ fdt fdtmapExtract the 
> > > > devicetree blob from the fdtmap
> > > >  self.assertRegex(err,
> > > >   "Image 'image'.*missing bintools.*: bootgen")
> > > >
> > > > +def _GetCapsuleHeaders(self, data):
> > >
> > > This should have a function comment so it is clear what it is doing, 
> > > returning.
> >
> > Will add
> >
> > -sughosh
> >
> > >
> > > > +capsule_file = os.path.join(self._indir, 'test.capsule')
> > > > +tools.write_file(capsule_file, data)
> > > > +
> > > > +out = tools.run('mkeficapsule', '--dump-capsule', capsule_file)
> > > > +lines = out.splitlines()
> > > > +
> > > > +re_line = re.compile(r'^([^:\-\t]*)(?:\t*\s*:\s*(.*))?$')
> > > > +vals = collections.defaultdict(list)
> > > > +for line in lines:
> > > > +mat = re_line.match(line)
> > > > +if mat:
> > > > +vals[mat.group(1)] = mat.group(2)
> > > > +
> > > > +return vals
> > > > +
> > > [..]
> > >
> > > Regards,
> > > Simon
>
> Regards,
> SImon


Re: [PATCH v7 1/2] schemas: memory: Add ECC properties

2023-10-09 Thread Simon Glass
Hi Rob,

On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
>
> Some memories provide ECC detection and/or correction. For software which
> wants to check memory, it is helpful to see which regions provide this
> feature.
>
> Add this as a property of the /memory nodes, since it presumably follows
> the hardware-level memory system.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v7:
> - Drop unnecessary |
> - Add a blank line between properties
>
> Changes in v6:
> - Use a number of bits instead of a string property
> - Fix inidcates typo
>
> Changes in v5:
> - Redo to make this property specific to ECC
> - Provide properties both for detection and correction
>
> Changes in v3:
> - Add new patch to update the /memory nodes
>
>  dtschema/schemas/memory.yaml | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml
> index 1d74410..b3bf3c9 100644
> --- a/dtschema/schemas/memory.yaml
> +++ b/dtschema/schemas/memory.yaml
> @@ -35,6 +35,19 @@ patternProperties:
>For the purpose of identification, each NUMA node is associated 
> with
>a unique token known as a node id.
>
> +  ecc-detection-bits:
> +default: 0
> +description: |
> +  If present, this indicates the number of bits of memory error which
> +  can be detected and reported by the Error-Correction Code (ECC) 
> memory
> +  subsystem (typically 0, 1 or 2).
> +
> +  ecc-correction-bits:
> +default: 0
> +description: |
> +  If present, this indicates the number of bits of memory error which
> +  can be corrected by the Error-Correction Code (ECC) memory 
> subsystem
> +  (typically 0, 1 or 2).
>
>  required:
>- device_type
> --
> 2.42.0.515.g380fc7ccd1-goog
>

What is the status of this patch, please?

Regards,
Simon


Re: [PATCH] arm: rpi: explicitly enumerate mmc boot targets

2023-10-09 Thread Simon Glass
Hi Ben,

On Sun, 8 Oct 2023 at 15:55, Ben Wolsieffer  wrote:
>
> Hi Simon,
>
> On Sat, Oct 07, 2023 at 02:18:48PM -0600, Simon Glass wrote:
> > Hi Ben,
> >
> > On Sat, 7 Oct 2023 at 09:55, Ben Wolsieffer 
wrote:
> > >
> > > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > > fail to boot. c771e5b explains this approach as follows:
> > >
> > > > We don't need to specify the mmc devices individually, since they
are
> > > > used in order from 0 to 2, and standard boot uses that order anyway.
> > >
> > > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > > interface, and, when this fails, moves on to attempt the USB and
network
> > > boot targets rather than trying mmc0.
> > >
> > > This patch explicitly enumerates the mmc interfaces, causing each to
be
> > > attempted in turn. This matches what is done on other boards, and
allows
> > > the system to boot successfully.
> > >
> > > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > > Signed-off-by: Ben Wolsieffer 
> > > ---
> > >  board/raspberrypi/rpi/rpi.env | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> >
> > Does this patch help? [1]. Alternatively, if you just remove that
> > variable entirely, does it do the right thing?
>
> Yes, trying either of those suggestions makes it work correctly.

Thank you for testing this

In that case, I would rather that [1] since it should fix it for all
boards. If you want to send a patch to drop boot_targets, please do and
I'll leave that to Peter.

>
> >
> > Regards,
> > Simon
> >
> > [1]
https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/
>
>
> Thanks, Ben

Regards,
Simon


Re: [PATCH v4 1/4] common: add prototype & rename populate_serial_number()

2023-10-09 Thread Simon Glass
On Mon, 9 Oct 2023 at 08:42, Artur Rojek  wrote:
>
> Rename populate_serial_number() to a more descriptive
> serial_read_from_eeprom() and provide the missing function prototype.
>
> This is useful for boards that wish to read their serial number from
> EEPROM at init.
>
> Signed-off-by: Artur Rojek 
> ---
>
> v4: - revert to the approach found in v2
> - keep the new serial_read_from_eeprom() name
>
> v3: - restore original function name and make it static
> - provide a generic function for reading EEPROM serial number and
>   wrap it around the existing tlv logic
> - move the env var check out of populate_serial_number() and into
>   the new serial_read_from_eeprom() in order to stay consistent with
>   the documentation
>
> v2: - rename the function
> - move function documentation from .c file to the prototype location
>
>  cmd/tlv_eeprom.c | 14 +-
>  include/init.h   | 14 ++
>  2 files changed, 15 insertions(+), 13 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v4 2/4] event: add new EVT_SETTINGS_R event

2023-10-09 Thread Simon Glass
On Mon, 9 Oct 2023 at 08:42, Artur Rojek  wrote:
>
> Introduce EVT_SETTINGS_R, triggered post-relocation and before console
> init.
>
> This event gives an option to perform any platform-dependent setup,
> which needs to take place before show_board_info(). Usage examples
> include readout of EEPROM stored settings.
>
> Signed-off-by: Artur Rojek 
> ---
>
> v4: new patch
>
>  common/board_r.c | 1 +
>  common/event.c   | 1 +
>  include/event.h  | 9 +
>  3 files changed, 11 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH v3 1/6] binman: ti-secure: Add support for firewalling entities

2023-10-09 Thread Simon Glass
Hi Manorit,

On Mon, 9 Oct 2023 at 01:43, Manorit Chawdhry  wrote:
>
> Hi Simon,
>
> On 17:10-20231007, Simon Glass wrote:
> > Hi Manorit,
> >
> > On Wed, 4 Oct 2023 at 06:32, Manorit Chawdhry  wrote:
> > >
> > > We can now firewall entities while loading them through our secure
> > > entity TIFS, the required information should be present in the
> > > certificate that is being parsed by TIFS.
> > >
> > > The following commit adds the support to enable the certificates to be
> > > generated if the firewall configurations are present in the binman
dtsi
> > > nodes.
> > >
> > > Signed-off-by: Manorit Chawdhry 
> > > ---
> > >  tools/binman/btool/openssl.py   | 16 +++-
> > >  tools/binman/etype/ti_secure.py | 85
+
> > >  tools/binman/etype/x509_cert.py |  3 +-
> > >  3 files changed, 101 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/tools/binman/btool/openssl.py
b/tools/binman/btool/openssl.py
> > > index aad3b61ae27c..dff439df211f 100644
> > > --- a/tools/binman/btool/openssl.py
> > > +++ b/tools/binman/btool/openssl.py
> > > @@ -82,7 +82,7 @@ imageSize  = INTEGER:{len(indata)}
> > >  return self.run_cmd(*args)
> > >
> > >  def x509_cert_sysfw(self, cert_fname, input_fname, key_fname,
sw_rev,
> > > -  config_fname, req_dist_name_dict):
> > > +  config_fname, req_dist_name_dict,
firewall_cert_data):
> > >  """Create a certificate to be booted by system firmware
> > >
> > >  Args:
> > > @@ -94,6 +94,13 @@ imageSize  = INTEGER:{len(indata)}
> > >  req_dist_name_dict (dict): Dictionary containing
key-value pairs of
> > >  req_distinguished_name section extensions, must contain
extensions for
> > >  C, ST, L, O, OU, CN and emailAddress
> > > +firewall_cert_data (dict):
> > > +  - auth_in_place (int): The Priv ID for copying as the
> > > +specific host in firewall protected region
> > > +  - num_firewalls (int): The number of firewalls in the
> > > +extended certificate
> > > +  - certificate (str): Extended firewall certificate with
> > > +the information for the firewall configurations.
> > >
> > >  Returns:
> > >  str: Tool output
> > > @@ -121,6 +128,7 @@ basicConstraints   = CA:true
> > >  1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
> > >  1.3.6.1.4.1.294.1.34   = ASN1:SEQUENCE:sysfw_image_integrity
> > >  1.3.6.1.4.1.294.1.35   = ASN1:SEQUENCE:sysfw_image_load
> > > +1.3.6.1.4.1.294.1.37   = ASN1:SEQUENCE:firewall
> > >
> > >  [ swrv ]
> > >  swrv = INTEGER:{sw_rev}
> > > @@ -132,7 +140,11 @@ imageSize  = INTEGER:{len(indata)}
> > >
> > >  [ sysfw_image_load ]
> > >  destAddr = FORMAT:HEX,OCT:
> > > -authInPlace = INTEGER:2
> > > +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> > > +
> > > +[ firewall ]
> > > +numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
> > > +{firewall_cert_data['certificate']}
> >
> > Do we want the text above if there is no firewall info?
> >
>
> Yes, keeping numFirewallRegions = INTEGER:0 is valid. The other way would
be
> to remove OIDs and everything that we have kept in the certificate when
> firewall nodes are not present but that seems a bit more difficult given
> that we have an easy fix keeping the numFirewallRegions as 0.

OK

>
> > >  ''', file=outf)
> > >  args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
> > >  '-outform', 'DER', '-out', cert_fname, '-config',
config_fname,
> > > diff --git a/tools/binman/etype/ti_secure.py
b/tools/binman/etype/ti_secure.py
> > > index d939dce57139..a7409023fa55 100644
> > > --- a/tools/binman/etype/ti_secure.py
> > > +++ b/tools/binman/etype/ti_secure.py
> > > @@ -7,9 +7,35 @@
> > >
> > >  from binman.entry import EntryArg
> > >  from binman.etype.x509_cert import Entry_x509_cert
> > > +from dataclasses import dataclass
> > >
> > >  from dtoc import fdt_util
> > >
> > > +@dataclass
> > > +class Firewall():
> > > +id: int
> > > +region: int
> > > +control : int
> > > +permissions: list[hex]
> > > +start_address: str
> > > +end_address: str
> > > +
> > > +def get_certificate(self) -> str:
> > > +unique_identifier = f"{self.id}{self.region}"
> > > +cert = f"""
> > > +firewallID{unique_identifier} = INTEGER:{self.id}
> > > +region{unique_identifier} = INTEGER:{self.region}
> > > +control{unique_identifier} = INTEGER:{hex(self.control)}
> > > +nPermissionRegs{unique_identifier} = INTEGER:{len(self.permissions)}
> > > +"""
> > > +for index, permission in enumerate(self.permissions):
> > > +cert += f"""permissions{unique_identifier}{index} =
INTEGER:{hex(permission)}
> > > +"""
> > > +cert += f"""startAddress{unique_identifier} =
FORMAT:HEX,OCT:{self.start_address:02x}
> > > 

Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification

2023-10-09 Thread Simon Glass
Hi Sughosh,

On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Sun, 8 Oct 2023 at 04:41, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu 
wrote:
> > >
> > > The various fields of a generated capsule are currently verified
> > > through hard-coded offsets. Use the dump-capsule feature for dumping
> > > the capsule header contents and use those for capsule verification.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > >  tools/binman/ftest.py | 95
---
> > >  1 file changed, 54 insertions(+), 41 deletions(-)
> >
> > This looks good apart from a few nits below. However, the tests fail
for me.
>
> Can you please specify which tests fail, and the way to reproduce the
> failures? I ran the tests before sending the patches, and they ran
> fine, including the coverage which is 100%. Ci too did not complain.

Sure, for example:

$ binman test testCapsuleGen
 Running binman tests 
/usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary mode, the default buffer size will
be used
  return io.open(fd, mode, buffering, encoding, *args, **kwargs)
/usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary mode, the default buffer size will
be used
  return io.open(fd, mode, buffering, encoding, *args, **kwargs)
F
==
FAIL: binman.ftest.TestFunctional.testCapsuleGen (subunit.RemotedTestCase)
binman.ftest.TestFunctional.testCapsuleGen
--
testtools.testresult.real._StringException: Traceback (most recent call
last):
AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != []


--
Ran 1 test in 0.147s

FAILED (failures=1)


>
> >
> > >
> > > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> > > index 8e419645a6..2b8871ab7e 100644
> > > --- a/tools/binman/ftest.py
> > > +++ b/tools/binman/ftest.py
> > > @@ -121,9 +121,11 @@ COMP_BINTOOLS = ['bzip2', 'gzip', 'lz4',
'lzma_alone', 'lzop', 'xz', 'zstd']
> > >  TEE_ADDR = 0x5678
> > >
> > >  # Firmware Management Protocol(FMP) GUID
> > > -FW_MGMT_GUID = 'edd5cb6d2de8444cbda17194199ad92a'
> > > +FW_MGMT_GUID = '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A'
> > >  # Image GUID specified in the DTS
> > > -CAPSULE_IMAGE_GUID = '52cfd7092007104791d108469b7fe9c8'
> > > +CAPSULE_IMAGE_GUID = '09D7CF52-0720-4710-91D1-08469B7FE9C8'
> > > +# Windows cert GUID
> > > +WIN_CERT_TYPE_EFI_GUID = '4AAFD29D-68DF-49EE-8AA9-347D375665A7'
> >
> > Please use lower-case hex
>
> Okay
>
> >
> > >
> > >  class TestFunctional(unittest.TestCase):
> > >  """Functional tests for binman
> > > @@ -7223,52 +7225,63 @@ fdt fdtmapExtract the
devicetree blob from the fdtmap
> > >  self.assertRegex(err,
> > >   "Image 'image'.*missing bintools.*:
bootgen")
> > >
> > > +def _GetCapsuleHeaders(self, data):
> >
> > This should have a function comment so it is clear what it is doing,
returning.
>
> Will add
>
> -sughosh
>
> >
> > > +capsule_file = os.path.join(self._indir, 'test.capsule')
> > > +tools.write_file(capsule_file, data)
> > > +
> > > +out = tools.run('mkeficapsule', '--dump-capsule',
capsule_file)
> > > +lines = out.splitlines()
> > > +
> > > +re_line = re.compile(r'^([^:\-\t]*)(?:\t*\s*:\s*(.*))?$')
> > > +vals = collections.defaultdict(list)
> > > +for line in lines:
> > > +mat = re_line.match(line)
> > > +if mat:
> > > +vals[mat.group(1)] = mat.group(2)
> > > +
> > > +return vals
> > > +
> > [..]
> >
> > Regards,
> > Simon

Regards,
SImon


Re: [RFC PATCH v10 00/24] Modernize U-Boot shell

2023-10-09 Thread Simon Glass
Hi Francis,

On Wed, 4 Oct 2023 at 10:42, Francis Laniel <
francis.lan...@amarulasolutions.com> wrote:
>
> Hi.
>
>
> During 2021 summer, Sean Anderson wrote a contribution to add a new
shell, based
> on LIL, to U-Boot [1, 2].
> While one of the goals of this contribution was to address the fact actual
> U-Boot shell, which is based on Busybox hush, is old there was a
discussion
> about adding a new shell versus updating the actual one [3, 4].
>
> So, in this series, with Harald Seiler, we updated the actual U-Boot
shell to
> reflect what is currently in Busybox source code.
> Basically, this contribution is about taking a snapshot of Busybox
shell/hush.c
> file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
>
> This contribution was written to be as backward-compatible as possible to
avoid
> breaking the existing.
> So, the 2021 hush flavor offers the same as the actual, that is to say:
> 1. Variable expansion.
> 2. Instruction lists (;, && and ||).
> 3. If, then and else.
> 4. Loops (for, while and until).
> No new features offered by Busybox hush were implemented (e.g. functions).
>
> It is possible to change the parser at runtime using the "cli" command:
> => cli print
> old
> => cli set 2021
> => cli print
> 2021
> => cli set old
> The default parser is the old one.
> Note that to use both parser, you would need to set both
CONFIG_HUSH_2021_PARSER
> and CONFIG_HUSH_OLD_PARSER.
>
> In terms of testing, new unit tests were added to ut to ensure the new
behavior
> is the same as the old one and it does not add regression.
> Nonetheless, if old behavior was buggy and fixed upstream, the fix is
then added
> to U-Boot [5].
> In sandbox, all of these tests pass smoothly:
> => printenv board
> board=sandbox
> => ut hush
> Running 20 hush tests
> ...
> Failures: 0
> => parser set 2021
> => ut hush
> Running 20 hush tests
> ...
> Failures: 0
>
> Thanks to the effort of Harald Seiler, I was successful booting a board:
> => printenv fdtfile
> fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> => cli get
> old

This is a really nice integration.

I think it could benefit from a new Kconfig like CONFIG_HUSH_SELECTABLE
which enables the cli command and selection of parser...this could perhaps
be enabled automatically if two parsers are selected. Then the code growth
(about 1KB on Thumb 2) would mostly go away.

For checking parsers, the code you use:

   if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
  int hush_flags = FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP;

  if (flag & CMD_FLAG_ENV)
 hush_flags |= FLAG_CONT_ON_NEWLINE;
  return parse_string_outer(cmd, hush_flags);
   } else if (gd->flags & GD_FLG_HUSH_2021_PARSER) {
...
  return parse_string_outer_2021(cmd, FLAG_EXIT_FROM_LOOP);
   }

could be written to reduce code size...i.e. there is only a need to check
the gd flag if HUSH_SELECTABLE is enabled, so:

static inline bool use_hush_old(void)
{
 return IS_ENABLED(CONFIG_HUSH_SELECTABLE) ?
 gd->flags & GD_FLG_HUSH_OLD_PARSER :
 IS_ENABLD(CONFIG_HUSH_OLD_PARSER);
}

Then use that function in the code able.

Size growth when swtiching to the the new parser is only 3KB, from my test.
I thought it would be much more?

> => boot
> ...
> root@lepotato:~#
> root@lepotato:~# reboot
> ...
> => cli set 2021
> => cli get
> 2021
> => printenv fdtfile
> fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> => boot
> ...
> root@lepotato:~#
>
> I had to not use CONFIG_HUSH_2021_PARSER for the keymile board.
> Indeed, the keymile board family is the only set of boards to call
> get_local_var(), set_local_var() and unset_local_var().
> Sadly, these functions are static in this contribution.
> I could have change all of them to introduce code like this:
> *_local_var(/*...*/)
> {
> if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
> return *_local_var_old(/*...*/);
> if (gd->flags & GD_FLG_HUSH_2021_PARSER)
> return *_local_var_2021(/*...*/);
> }
> But this would have mean renaming all old hush functions calls and I did
not
> want to change the old hush particularly to avoid breaking things.
> Instead, I change the keymile board to use environment variable instead
of local
> ones.
> I think this particularities can be addressed in future works.

I agree.

>
> I also had to enable CONFIG_LTO for kirkwoord sheevaplug and phytec
bk4r1, so
> they do not hit their limits.
>
> For all these reasons, I marked this contribution as RFC to indeed
collect your
> opinions.
> My goal is not to change suddenly actual shell to this one, we clearly
need a
> transition period to think about it.
> I think it is better to see this contribution as a proof of concept which
shows
> it is possible to update the actual shell.
>
> If you want to review it - your review will really be appreciated - here
are
> some information regarding the commits:
> * commits marked as "test:" deal with unit tests.
> * commit "cli: Add Busybox upstream hush.c file." copies Busybox

[PATCH v2 19/19] board: rzg2l: Add RZ/G2L SMARC EVK board

2023-10-09 Thread Paul Barker
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.

The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car gen3/gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on and
this is used to select the appropriate device tree to load.

The configuration renesas_rzg2l_smarc_defconfig is added to support
building for this target. In the future this defconfig will be extended
to support other SoCs and evaluation boards from the RZ/G2L family.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
 * Move dram_init() & dram_init_banksize() to memmap-rzg2l.c
 * Add a TODO note for reset support.

 arch/arm/mach-rmobile/Kconfig.rzg2l   | 14 ++
 arch/arm/mach-rmobile/memmap-rzg2l.c  | 12 +
 board/renesas/rzg2l/Kconfig   | 18 +++
 board/renesas/rzg2l/MAINTAINERS   |  6 +++
 board/renesas/rzg2l/Makefile  |  4 ++
 board/renesas/rzg2l/rzg2l.c   | 67 +++
 configs/renesas_rzg2l_smarc_defconfig | 52 +
 include/configs/rzg2l-smarc.h | 14 ++
 8 files changed, 187 insertions(+)
 create mode 100644 board/renesas/rzg2l/Kconfig
 create mode 100644 board/renesas/rzg2l/MAINTAINERS
 create mode 100644 board/renesas/rzg2l/Makefile
 create mode 100644 board/renesas/rzg2l/rzg2l.c
 create mode 100644 configs/renesas_rzg2l_smarc_defconfig
 create mode 100644 include/configs/rzg2l-smarc.h

diff --git a/arch/arm/mach-rmobile/Kconfig.rzg2l 
b/arch/arm/mach-rmobile/Kconfig.rzg2l
index 039d6b0a45aa..dc30bdf3e5c2 100644
--- a/arch/arm/mach-rmobile/Kconfig.rzg2l
+++ b/arch/arm/mach-rmobile/Kconfig.rzg2l
@@ -9,6 +9,20 @@ config R9A07G044L
help
  Enable support for the Renesas R9A07G044L (RZ/G2L) SoC.
 
+choice
+   prompt "Renesas RZ/G2L Family Board selection"
+   default TARGET_RZG2L_SMARC_EVK
+
+config TARGET_RZG2L_SMARC_EVK
+   bool "Renesas RZ/G2L SMARC EVK"
+   imply R9A07G044L
+   help
+ Enable support for the RZ/G2L SMARC evaluation board.
+
+source "board/renesas/rzg2l/Kconfig"
+
+endchoice
+
 config MULTI_DTB_FIT_UNCOMPRESS_SZ
default 0x8 if TARGET_RZG2L_SMARC_EVK
 
diff --git a/arch/arm/mach-rmobile/memmap-rzg2l.c 
b/arch/arm/mach-rmobile/memmap-rzg2l.c
index d0509424fb73..a08d0ea08fc0 100644
--- a/arch/arm/mach-rmobile/memmap-rzg2l.c
+++ b/arch/arm/mach-rmobile/memmap-rzg2l.c
@@ -113,3 +113,15 @@ void enable_caches(void)
 
dcache_enable();
 }
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+   fdtdec_setup_memory_banksize();
+
+   return 0;
+}
diff --git a/board/renesas/rzg2l/Kconfig b/board/renesas/rzg2l/Kconfig
new file mode 100644
index ..1335fc7ae806
--- /dev/null
+++ b/board/renesas/rzg2l/Kconfig
@@ -0,0 +1,18 @@
+# Copyright (C) 2023 Renesas Electronics Corporation
+# SPDX-License-Identifier: GPL-2.0+
+
+if TARGET_RZG2L_SMARC_EVK
+
+config SYS_SOC
+   default "rmobile"
+
+config SYS_BOARD
+   default "rzg2l"
+
+config SYS_VENDOR
+   default "renesas"
+
+config SYS_CONFIG_NAME
+   default "rzg2l-smarc"
+
+endif
diff --git a/board/renesas/rzg2l/MAINTAINERS b/board/renesas/rzg2l/MAINTAINERS
new file mode 100644
index ..0a51391c1fc9
--- /dev/null
+++ b/board/renesas/rzg2l/MAINTAINERS
@@ -0,0 +1,6 @@
+RENESAS RZG2L BOARD FAMILY
+M: Paul Barker 
+S: Supported
+F: arch/arm/dts/rz-smarc-common.dtsi
+N: rzg2l
+N: r9a07g044
diff --git a/board/renesas/rzg2l/Makefile b/board/renesas/rzg2l/Makefile
new file mode 100644
index ..466935fc8158
--- /dev/null
+++ b/board/renesas/rzg2l/Makefile
@@ -0,0 +1,4 @@
+# Copyright (C) 2023 Renesas Electronics Corporation
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y  := rzg2l.o
diff --git a/board/renesas/rzg2l/rzg2l.c b/board/renesas/rzg2l/rzg2l.c
new file mode 100644
index ..5b919f0b495a
--- /dev/null
+++ b/board/renesas/rzg2l/rzg2l.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RZ/G2L board support.
+ * Copyright (C) 2023 Renesas Electronics Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
+/* If the firmware passed a device tree, use it for board identification. */
+extern u64 rcar_atf_boot_args[];
+
+static bool is_rzg2l_board(const char *board_name)
+{
+   void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
+
+   return fdt_node_check_compatible(atf_fdt_blob, 0, board_name) == 0;
+}
+
+int board_fit_config_name_match(const char *name)
+{
+   void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
+
+   if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
+   return -1;
+
+   if (is_rzg2l_board("renesas,r9a07g044l2"))

[PATCH v2 18/19] arm: dts: Import RZ/G2L SMARC EVK device tree

2023-10-09 Thread Paul Barker
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.

This patch is based on the corresponding Linux v6.5 device tree
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added the exact Linux commit we imported from.
  * Add Marek's Reivewed-by.

 arch/arm/dts/Makefile |3 +
 arch/arm/dts/r9a07g044.dtsi   | 1273 +
 arch/arm/dts/r9a07g044l2-smarc.dts|   18 +
 arch/arm/dts/r9a07g044l2.dtsi |   13 +
 arch/arm/dts/rz-smarc-common.dtsi |  183 +++
 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi |  137 +++
 arch/arm/dts/rzg2l-smarc-som.dtsi |  353 ++
 arch/arm/dts/rzg2l-smarc.dtsi |  144 +++
 8 files changed, 2124 insertions(+)
 create mode 100644 arch/arm/dts/r9a07g044.dtsi
 create mode 100644 arch/arm/dts/r9a07g044l2-smarc.dts
 create mode 100644 arch/arm/dts/r9a07g044l2.dtsi
 create mode 100644 arch/arm/dts/rz-smarc-common.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc-som.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7f6..8c1a6ccdb72e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1099,6 +1099,9 @@ dtb-$(CONFIG_RCAR_GEN4) += \
r8a779f0-spider-u-boot.dtb \
r8a779g0-white-hawk-u-boot.dtb
 
+dtb-$(CONFIG_TARGET_RZG2L) += \
+   r9a07g044l2-smarc.dts
+
 ifdef CONFIG_RCAR_64
 DTC_FLAGS += -R 4 -p 0x1000
 endif
diff --git a/arch/arm/dts/r9a07g044.dtsi b/arch/arm/dts/r9a07g044.dtsi
new file mode 100644
index ..232910e07444
--- /dev/null
+++ b/arch/arm/dts/r9a07g044.dtsi
@@ -0,0 +1,1273 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Device Tree Source for the RZ/G2L and RZ/G2LC common SoC parts
+ *
+ * Copyright (C) 2021 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "renesas,r9a07g044";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   audio_clk1: audio1-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by boards that provide it */
+   clock-frequency = <0>;
+   };
+
+   audio_clk2: audio2-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by boards that provide it */
+   clock-frequency = <0>;
+   };
+
+   /* External CAN clock - to be overridden by boards that provide it */
+   can_clk: can-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   /* clock can be either from exclk or crystal oscillator (XIN/XOUT) */
+   extal_clk: extal-clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board */
+   clock-frequency = <0>;
+   };
+
+   cluster0_opp: opp-table-0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-15000 {
+   opp-hz = /bits/ 64 <15000>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <30>;
+   };
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <30>;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <30>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <30>;
+   opp-suspend;
+   };
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   };
+   };
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a55";
+   reg = <0>;
+   device_type = "cpu";
+   #cooling-cells = <2>;
+   next-level-cache = 

[PATCH v2 17/19] arm: rmobile: Support RZ/G2L memory map

2023-10-09 Thread Paul Barker
The memory map for the RZ/G2L family differs from that of previous R-Car
Gen3/Gen4 SoCs.

A high level memory map can be seen in figure 5.2 (section 5.2.1) of the
RZ/G2L data sheet rev 1.30 published May 12, 2023. A summary is included
here (note that this is a 34-bit address space):
  * 0x0__ - 0x0_0002_ SRAM area
  * 0x0_0003_ - 0x0_0FFF_ Reserved area
  * 0x0_1000_ - 0x0_1FFF_ I/O register area
  * 0x0_2000_ - 0x0_2FFF_ SPI Multi area
  * 0x0_3000_ - 0x0_3FFF_ Reserved area
  * 0x0_4000_ - 0x1_3FFF_ DDR area (4 GiB)
  * 0x1_4000_ - 0x3__ Reserved area

Within the DDR area, the first 128 MiB are reserved by TrustedFirmware.
The region from 0x43F0 to 0x47DF inclusive is protected for use
in TrustedFirmware/OP-TEE, but all other memory is included in the
memory map. This reservation is the same as used in R-Car
Gen3/Gen4 and RZ/G2{H,M,N,E} SoCs.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Improve commit message.

 arch/arm/mach-rmobile/Makefile   |   8 +-
 arch/arm/mach-rmobile/memmap-rzg2l.c | 115 +++
 2 files changed, 119 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-rmobile/memmap-rzg2l.c

diff --git a/arch/arm/mach-rmobile/Makefile b/arch/arm/mach-rmobile/Makefile
index 45d6a0e2a28a..ff8b0c7bae25 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -10,11 +10,11 @@ obj-$(CONFIG_DISPLAY_BOARDINFO) += board.o
 obj-$(CONFIG_TMU_TIMER) += ../../sh/lib/time.o
 obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
 obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
-obj-$(CONFIG_RCAR_64) += lowlevel_init_gen3.o memmap-gen3.o
-obj-$(CONFIG_RCAR_GEN3) += cpu_info-rcar.o
-obj-$(CONFIG_RCAR_GEN4) += cpu_info-rcar.o
+obj-$(CONFIG_RCAR_64) += lowlevel_init_gen3.o
+obj-$(CONFIG_RCAR_GEN3) += cpu_info-rcar.o memmap-gen3.o
+obj-$(CONFIG_RCAR_GEN4) += cpu_info-rcar.o memmap-gen3.o
 obj-$(CONFIG_RZ_G2) += cpu_info-rzg.o
-obj-$(CONFIG_RZG2L) += cpu_info-rzg2l.o
+obj-$(CONFIG_RZG2L) += cpu_info-rzg2l.o memmap-rzg2l.o
 
 ifneq ($(CONFIG_R8A779A0),)
 obj-$(CONFIG_ARMV8_PSCI) += psci-r8a779a0.o
diff --git a/arch/arm/mach-rmobile/memmap-rzg2l.c 
b/arch/arm/mach-rmobile/memmap-rzg2l.c
new file mode 100644
index ..d0509424fb73
--- /dev/null
+++ b/arch/arm/mach-rmobile/memmap-rzg2l.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Renesas RZ/G2L family memory map tables
+ *
+ * Copyright (C) 2017 Marek Vasut 
+ * Copyright (C) 2023 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define RZG2L_NR_REGIONS 16
+
+/*
+ * RZ/G2L supports up to 4 GiB RAM starting at 0x4000, of
+ * which the first 128 MiB is reserved by TF-A.
+ */
+static struct mm_region rzg2l_mem_map[RZG2L_NR_REGIONS] = {
+   {
+   .virt = 0x0UL,
+   .phys = 0x0UL,
+   .size = 0x4000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   .virt = 0x4000UL,
+   .phys = 0x4000UL,
+   .size = 0x03F0UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0x47E0UL,
+   .phys = 0x47E0UL,
+   .size = 0xF820UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = rzg2l_mem_map;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define debug_memmap(i, map) \
+   debug("memmap %d: virt 0x%llx -> phys 0x%llx, size=0x%llx, 
attrs=0x%llx\n", \
+ i, map[i].virt, map[i].phys, map[i].size, map[i].attrs)
+
+void enable_caches(void)
+{
+   unsigned int bank, i = 0;
+   u64 start, size;
+
+   /* Create map for register access */
+   rzg2l_mem_map[i].virt = 0x0ULL;
+   rzg2l_mem_map[i].phys = 0x0ULL;
+   rzg2l_mem_map[i].size = 0x4000ULL;
+   rzg2l_mem_map[i].attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN;
+   debug_memmap(i, rzg2l_mem_map);
+   i++;
+
+   /* Generate entries for DRAM in 32bit address space */
+   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+   start = gd->bd->bi_dram[bank].start;
+   size = gd->bd->bi_dram[bank].size;
+
+   /* Skip empty DRAM banks */
+   if (!size)
+   continue;
+
+   /* Mark memory reserved by ATF as cacheable too. */
+   if (start == 0x4800) {
+   /* Unmark protection area 

[PATCH v2 16/19] arm: rmobile: Add CPU detection for RZ/G2L

2023-10-09 Thread Paul Barker
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car Gen3/Gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on.

We do this as reading the DEVID & PRR registers from u-boot is not
sufficient to differentiate between the R9A07G044L (RZ/G2L) and
R9A07G044C (RZ/G2LC) SoCs. An additional read from offset 0x11861178 is
needed but this address is in the OTP region which can only be read from
the secure world (i.e. TrustedFirmware). So we have to rely on
TrustedFirmware to determine the SoC and pass this information to u-boot
via an fdt blob.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Improved commit message.

 arch/arm/mach-rmobile/Makefile   |  5 +-
 arch/arm/mach-rmobile/cpu_info-rzg2l.c   | 63 
 arch/arm/mach-rmobile/include/mach/rmobile.h |  1 +
 3 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-rmobile/cpu_info-rzg2l.c

diff --git a/arch/arm/mach-rmobile/Makefile b/arch/arm/mach-rmobile/Makefile
index 4eddba53ed2a..45d6a0e2a28a 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -10,8 +10,11 @@ obj-$(CONFIG_DISPLAY_BOARDINFO) += board.o
 obj-$(CONFIG_TMU_TIMER) += ../../sh/lib/time.o
 obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
 obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
-obj-$(CONFIG_RCAR_64) += lowlevel_init_gen3.o cpu_info-rcar.o memmap-gen3.o
+obj-$(CONFIG_RCAR_64) += lowlevel_init_gen3.o memmap-gen3.o
+obj-$(CONFIG_RCAR_GEN3) += cpu_info-rcar.o
+obj-$(CONFIG_RCAR_GEN4) += cpu_info-rcar.o
 obj-$(CONFIG_RZ_G2) += cpu_info-rzg.o
+obj-$(CONFIG_RZG2L) += cpu_info-rzg2l.o
 
 ifneq ($(CONFIG_R8A779A0),)
 obj-$(CONFIG_ARMV8_PSCI) += psci-r8a779a0.o
diff --git a/arch/arm/mach-rmobile/cpu_info-rzg2l.c 
b/arch/arm/mach-rmobile/cpu_info-rzg2l.c
new file mode 100644
index ..de4892ee901e
--- /dev/null
+++ b/arch/arm/mach-rmobile/cpu_info-rzg2l.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021,2023 Renesas Electronics Corporation
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define SYSC_LSI_DEVID 0x11020A04
+
+/* If the firmware passed a device tree, use it for soc identification. */
+extern u64 rcar_atf_boot_args[];
+
+/* CPU information table */
+struct tfa_info {
+   const char *soc_name;
+   const char *cpu_name;
+   u32 cpu_type;
+};
+
+static const struct tfa_info tfa_info[] = {
+   { "renesas,r9a07g044l2", "R9A07G044L", RMOBILE_CPU_TYPE_R9A07G044L },
+};
+
+static const struct tfa_info invalid_tfa_info = { NULL, "(invalid)", 0 };
+
+static const struct tfa_info *get_tfa_info(void)
+{
+   void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
+
+   if (fdt_magic(atf_fdt_blob) == FDT_MAGIC) {
+   unsigned int i;
+   for (i = 0; i < ARRAY_SIZE(tfa_info); i++) {
+   if (!fdt_node_check_compatible(atf_fdt_blob, 0,
+  tfa_info[i].soc_name))
+   return _info[i];
+   }
+   }
+
+   return _tfa_info;
+}
+
+const u8 *rzg_get_cpu_name(void)
+{
+   return get_tfa_info()->cpu_name;
+}
+
+u32 rmobile_get_cpu_type(void)
+{
+   return get_tfa_info()->cpu_type;
+}
+
+u32 rmobile_get_cpu_rev_integer(void)
+{
+   return (readl(SYSC_LSI_DEVID) >> 28) + 1;
+}
+
+u32 rmobile_get_cpu_rev_fraction(void)
+{
+   return 0;
+}
diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h 
b/arch/arm/mach-rmobile/include/mach/rmobile.h
index 053ad08add00..88b8b78671b2 100644
--- a/arch/arm/mach-rmobile/include/mach/rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
@@ -43,6 +43,7 @@
 #define RMOBILE_CPU_TYPE_R8A779A0  0x59
 #define RMOBILE_CPU_TYPE_R8A779F0  0x5A
 #define RMOBILE_CPU_TYPE_R8A779G0  0x5C
+#define RMOBILE_CPU_TYPE_R9A07G044L0x9A070440
 
 #ifndef __ASSEMBLY__
 #include 
-- 
2.39.2



[PATCH v2 15/19] arm: rmobile: Include in header

2023-10-09 Thread Paul Barker
We don't want to rely on source files including  before
.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added Marek's Reviewed-by.

 arch/arm/mach-rmobile/include/mach/rmobile.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h 
b/arch/arm/mach-rmobile/include/mach/rmobile.h
index d326d5545a6f..053ad08add00 100644
--- a/arch/arm/mach-rmobile/include/mach/rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
@@ -45,6 +45,8 @@
 #define RMOBILE_CPU_TYPE_R8A779G0  0x5C
 
 #ifndef __ASSEMBLY__
+#include 
+
 const u8 *rzg_get_cpu_name(void);
 u32 rmobile_get_cpu_type(void);
 u32 rmobile_get_cpu_rev_integer(void);
-- 
2.39.2



[PATCH v2 14/19] mmc: renesas-sdhi: Initialize module on RZ/G2L

2023-10-09 Thread Paul Barker
On the Renesas RZ/G2L SoC family, we must ensure that the required clock
signals are enabled and the reset signal is de-asserted before we try to
communicate with the SDHI module.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Move RZ/G2L specific setup to its own function.

 drivers/mmc/renesas-sdhi.c | 82 --
 1 file changed, 79 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 1536c9782041..370dbce51ca0 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "tmio-common.h"
 
@@ -958,6 +959,74 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
priv->needs_clkh_fallback = false;
 }
 
+static int rzg2l_sdhi_setup(struct udevice *dev)
+{
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
+   struct clk imclk2, aclk;
+   struct reset_ctl rst;
+   int ret;
+
+   /*
+* On members of the RZ/G2L SoC family, we need to enable
+* additional chip detect and bus clocks, then release the SDHI
+* module from reset.
+*/
+   ret = clk_get_by_name(dev, "cd", );
+   if (ret < 0) {
+   dev_err(dev, "failed to get imclk2 (chip detect clk)\n");
+   goto err_get_imclk2;
+   }
+
+   ret = clk_get_by_name(dev, "aclk", );
+   if (ret < 0) {
+   dev_err(dev, "failed to get aclk\n");
+   goto err_get_aclk;
+   }
+
+   ret = clk_enable();
+   if (ret < 0) {
+   dev_err(dev, "failed to enable imclk2 (chip detect clk)\n");
+   goto err_imclk2;
+   }
+
+   ret = clk_enable();
+   if (ret < 0) {
+   dev_err(dev, "failed to enable aclk\n");
+   goto err_aclk;
+   }
+
+   ret = reset_get_by_index(dev, 0, );
+   if (ret < 0) {
+   dev_err(dev, "failed to get reset line\n");
+   goto err_reset;
+   }
+
+   ret = reset_deassert();
+   if (ret < 0) {
+   dev_err(dev, "failed to de-assert reset line\n");
+   goto err_reset;
+   }
+
+   ret = tmio_sd_probe(dev, priv->quirks);
+   if (ret)
+   goto err_tmio_probe;
+
+   return 0;
+
+err_tmio_probe:
+   reset_assert();
+err_reset:
+   clk_disable();
+err_aclk:
+   clk_disable();
+err_imclk2:
+   clk_free();
+err_get_aclk:
+   clk_free();
+err_get_imclk2:
+   return ret;
+}
+
 static int renesas_sdhi_probe(struct udevice *dev)
 {
struct tmio_sd_priv *priv = dev_get_priv(dev);
@@ -1012,9 +1081,15 @@ static int renesas_sdhi_probe(struct udevice *dev)
goto err_clkh;
}
 
-   ret = tmio_sd_probe(dev, priv->quirks);
-   if (ret)
-   goto err_tmio_probe;
+   if (IS_ENABLED(CONFIG_RZG2L)) {
+   ret = rzg2l_sdhi_setup(dev);
+   if (ret)
+   goto err_rzg2l_setup;
+   } else {
+   ret = tmio_sd_probe(dev, priv->quirks);
+   if (ret)
+   goto err_tmio_probe;
+   }
 
renesas_sdhi_filter_caps(dev);
 
@@ -1026,6 +1101,7 @@ static int renesas_sdhi_probe(struct udevice *dev)
 #endif
return 0;
 
+err_rzg2l_setup:
 err_tmio_probe:
clk_disable(>clk);
 err_clkh:
-- 
2.39.2



[PATCH v2 13/19] mmc: renesas-sdhi: Refactor probe function

2023-10-09 Thread Paul Barker
Move the assignment of priv->quirks earlier in the function. This allows
us to drop the quirks local variable and makes it easier to maintain
clean error handling when we add RZ/G2L support in the next patch.

Signed-off-by: Paul Barker 
---
v1->v2:
  * New patch to support breaking out RZ/G2L-specific initialization
into its own function.

 drivers/mmc/renesas-sdhi.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 8e716f74491f..1536c9782041 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -961,14 +961,14 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
 static int renesas_sdhi_probe(struct udevice *dev)
 {
struct tmio_sd_priv *priv = dev_get_priv(dev);
-   u32 quirks = dev_get_driver_data(dev);
struct fdt_resource reg_res;
DECLARE_GLOBAL_DATA_PTR;
int ret;
 
priv->clk_get_rate = renesas_sdhi_clk_get_rate;
 
-   if (quirks == RENESAS_GEN2_QUIRKS) {
+   priv->quirks = dev_get_driver_data(dev);
+   if (priv->quirks == RENESAS_GEN2_QUIRKS) {
ret = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev),
   "reg", 0, _res);
if (ret < 0) {
@@ -978,7 +978,7 @@ static int renesas_sdhi_probe(struct udevice *dev)
}
 
if (fdt_resource_size(_res) == 0x100)
-   quirks |= TMIO_SD_CAP_16BIT;
+   priv->quirks |= TMIO_SD_CAP_16BIT;
}
 
ret = clk_get_by_index(dev, 0, >clk);
@@ -1012,8 +1012,7 @@ static int renesas_sdhi_probe(struct udevice *dev)
goto err_clkh;
}
 
-   priv->quirks = quirks;
-   ret = tmio_sd_probe(dev, quirks);
+   ret = tmio_sd_probe(dev, priv->quirks);
if (ret)
goto err_tmio_probe;
 
-- 
2.39.2



[PATCH v2 12/19] serial: sh: Add RZ/G2L SCIF support

2023-10-09 Thread Paul Barker
Extend the existing driver to support the SCIF serial ports on the
Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that the
relevant reset signal is de-asserted before we try to talk to the SCIF
module.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Moved handle_error() changes out to a separate patch earlier in the
series.
  * Unconditionally de-assert the module reset during probe.

 arch/arm/mach-rmobile/Kconfig |  1 +
 drivers/serial/serial_sh.c| 17 +
 drivers/serial/serial_sh.h| 19 ++-
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig
index c30ff2caad17..c421181c89cf 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -77,6 +77,7 @@ config RZG2L
imply MULTI_DTB_FIT_USER_DEFINED_AREA
imply PINCTRL_RZG2L
imply RENESAS_SDHI
+   imply SCIF_CONSOLE
imply SYS_MALLOC_F
help
  Enable support for the Renesas RZ/G2L family of SoCs. Currently
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 2b650d458e71..6ea8da34d434 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "serial_sh.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -199,12 +201,26 @@ static int sh_serial_probe(struct udevice *dev)
 {
struct sh_serial_plat *plat = dev_get_plat(dev);
struct uart_port *priv = dev_get_priv(dev);
+   struct reset_ctl rst;
+   int ret;
 
priv->membase   = (unsigned char *)plat->base;
priv->mapbase   = plat->base;
priv->type  = plat->type;
priv->clk_mode  = plat->clk_mode;
 
+   ret = reset_get_by_index(dev, 0, );
+   if (ret < 0) {
+   dev_err(dev, "failed to get reset line\n");
+   return ret;
+   }
+
+   ret = reset_deassert();
+   if (ret < 0) {
+   dev_err(dev, "failed to de-assert reset line\n");
+   return ret;
+   }
+
sh_serial_init_generic(priv);
 
return 0;
@@ -223,6 +239,7 @@ static const struct udevice_id sh_serial_id[] ={
{.compatible = "renesas,scif", .data = PORT_SCIF},
{.compatible = "renesas,scifa", .data = PORT_SCIFA},
{.compatible = "renesas,hscif", .data = PORT_HSCIF},
+   {.compatible = "renesas,scif-r9a07g044", .data = PORT_SCIFA},
{}
 };
 
diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index 149ec1fe7397..58c2d22bc757 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -90,7 +90,7 @@ struct uart_port {
 # define SCSCR_INIT(port)  0x38 /* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
 # define SCIF_ORER 0x0001  /* overrun error bit */
 #elif defined(CONFIG_RCAR_GEN2) || defined(CONFIG_RCAR_64) || \
-  defined(CONFIG_R7S72100)
+  defined(CONFIG_R7S72100) || defined(CONFIG_RZG2L)
 # if defined(CFG_SCIF_A)
 #  define SCIF_ORER0x0200
 # else
@@ -312,6 +312,9 @@ static inline void sci_##name##_out(struct uart_port *port,\
sh4_scif_offset, sh4_scif_size)
#define SCIF_FNS(name, sh4_scif_offset, sh4_scif_size) \
CPU_SCIF_FNS(name, sh4_scif_offset, sh4_scif_size)
+#elif defined(CONFIG_RZG2L)
+#define SCIF_FNS(reg_name, reg_offset, reg_size) \
+   CPU_SCIF_FNS(reg_name, reg_offset, reg_size)
 #else
 #define SCIx_FNS(name, sh3_sci_offset, sh3_sci_size,\
sh4_sci_offset, sh4_sci_size, \
@@ -387,6 +390,20 @@ SCIF_FNS(SCLSR,  0,  0, 0x14, 16)
 #else
 SCIF_FNS(SCLSR,  0,  0, 0x24, 16)
 #endif
+#elif defined(CONFIG_RZG2L)
+SCIF_FNS(SCSMR,  0x00, 16)
+SCIF_FNS(SCBRR,  0x02,  8)
+SCIF_FNS(SCSCR,  0x04, 16)
+SCIF_FNS(SCxTDR, 0x06,  8)
+SCIF_FNS(SCxSR,  0x08, 16)
+SCIF_FNS(SCxRDR, 0x0A,  8)
+SCIF_FNS(SCFCR,  0x0C, 16)
+SCIF_FNS(SCFDR,  0x0E, 16)
+SCIF_FNS(SCSPTR, 0x10, 16)
+SCIF_FNS(SCLSR,  0x12, 16)
+SCIF_FNS(SCSEMR, 0x14,  8)
+SCIF_FNS(SCxTCR, 0x16, 16)
+SCIF_FNS(DL, 0x00,  0)
 #else
 /*  reg  SCI/SH3   SCI/SH4  SCIF/SH3   SCIF/SH4  SCI/H8*/
 /*  name off  sz   off  sz   off  sz   off  sz   off  sz*/
-- 
2.39.2



[PATCH v2 11/19] serial: sh: Fix error handling

2023-10-09 Thread Paul Barker
The current SCIF error handling is broken for the RZ/G2L. After a break
condition has been triggered, the current code is unable to clear the
error and serial port output never resumes.

The RZ/G2L datasheet says that most error conditions are cleared by
resetting the relevant error bits in the FSR & LSR registers to zero.
To clear framing errors, the invalid data also needs to be read out of
the receive FIFO.

After reviewing datasheets for RZ/G2{H,M,N,E}, R-Car Gen4, R-Car Gen3
and even SH7751 SoCs, it's clear that this is the way to clear errors
for all of these SoCs.

While we're here, annotate the handle_error() function with a couple of
comments as the reads and writes themselves don't immediately make it
clear what we're doing.

Signed-off-by: Paul Barker 
---
v1->v2:
  * New patch after discussion with Marek & further investigation.

I'm not going to put a `Fixes` tag on this, the error handling has been
writing ones to clear errors since at least 2007 so maybe it was
originally right for some board. It doesn't seem to apply to any of the
current users of the SCIF driver though.

 drivers/serial/serial_sh.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 5e543dbf3d58..2b650d458e71 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -79,10 +79,22 @@ sh_serial_setbrg_generic(struct uart_port *port, int clk, 
int baudrate)
 
 static void handle_error(struct uart_port *port)
 {
-   sci_in(port, SCxSR);
-   sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
+   /*
+* Most errors are cleared by resetting the relevant error bits to zero
+* in the FSR & LSR registers. For each register, a read followed by a
+* write is needed according to the relevant datasheets.
+*/
+   unsigned short status = sci_in(port, SCxSR);
+   sci_out(port, SCxSR, status & ~SCIF_ERRORS);
sci_in(port, SCLSR);
sci_out(port, SCLSR, 0x00);
+
+   /*
+* To clear framing errors, we also need to read and discard a
+* character.
+*/
+   if (status & SCIF_FER)
+   sci_in(port, SCxRDR);
 }
 
 static int serial_raw_putc(struct uart_port *port, const char c)
-- 
2.39.2



[PATCH v2 10/19] pinctrl: renesas: Add RZ/G2L PFC driver

2023-10-09 Thread Paul Barker
This driver provides pinctrl and gpio control for the Renesas RZ/G2L
(R9A07G044) SoC.

This patch is based on the corresponding Linux v6.5 driver.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Split GPIO into separate file.
  * Drop unnecessary parenthesis in defines.
  * Keep Kconfig list sorted.
  * Drop pfc_enabled flag.
  * Use const where possible.
  * Use clrbits/setbits/clrsetbits functions.
  * Return -ENOENT to skip invalid GPIO offsets.
  * Include ofnode_parse_phandle_with_args() return code in err print.
  * Use macro instal of port + 0x10.
  * Add TODO comment re Ethernet PIN_CFG.

 arch/arm/mach-rmobile/Kconfig   |   2 +
 drivers/gpio/Kconfig|   7 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/rzg2l-gpio.c   | 170 
 drivers/pinctrl/renesas/Kconfig |  10 +
 drivers/pinctrl/renesas/Makefile|   1 +
 drivers/pinctrl/renesas/rzg2l-pfc.c | 625 
 include/renesas/rzg2l-pfc.h | 110 +
 8 files changed, 926 insertions(+)
 create mode 100644 drivers/gpio/rzg2l-gpio.c
 create mode 100644 drivers/pinctrl/renesas/rzg2l-pfc.c
 create mode 100644 include/renesas/rzg2l-pfc.h

diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig
index af1f99197d9f..c30ff2caad17 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -72,8 +72,10 @@ config RZG2L
select GICV3
select RCAR_64
imply CLK_RZG2L
+   imply RZG2L_GPIO
imply MULTI_DTB_FIT
imply MULTI_DTB_FIT_USER_DEFINED_AREA
+   imply PINCTRL_RZG2L
imply RENESAS_SDHI
imply SYS_MALLOC_F
help
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9bf6e428ded2..12464257e0df 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -659,4 +659,11 @@ config ADP5585_GPIO
help
  Support ADP5585 GPIO expander.
 
+config RZG2L_GPIO
+   bool "Renesas RZ/G2L family GPIO driver"
+   depends on DM_GPIO
+   help
+ Support the gpio functionality of the pin function controller (PFC)
+ on the Renesas RZ/G2L SoC family.
+
 endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 64a36c472ebe..c8b3fd78141a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_SLG7XL45106_I2C_GPO) += gpio_slg7xl45106.o
 obj-$(CONFIG_$(SPL_TPL_)TURRIS_OMNIA_MCU)  += turris_omnia_mcu.o
 obj-$(CONFIG_FTGPIO010)+= ftgpio010.o
 obj-$(CONFIG_ADP5585_GPIO) += adp5585_gpio.o
+obj-$(CONFIG_RZG2L_GPIO)   += rzg2l-gpio.o
diff --git a/drivers/gpio/rzg2l-gpio.c b/drivers/gpio/rzg2l-gpio.c
new file mode 100644
index ..720162f3e4ef
--- /dev/null
+++ b/drivers/gpio/rzg2l-gpio.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/G2L Pin Function Controller
+ *
+ * Copyright (C) 2021-2023 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void rzg2l_gpio_set(const struct rzg2l_pfc_data *data, u32 port, u8 pin,
+   bool value)
+{
+   if (value)
+   setbits_8(data->base + P(port), BIT(pin));
+   else
+   clrbits_8(data->base + P(port), BIT(pin));
+}
+
+static int rzg2l_gpio_get_value(struct udevice *dev, unsigned int offset)
+{
+   const struct rzg2l_pfc_data *data =
+   (const struct rzg2l_pfc_data *)dev_get_driver_data(dev);
+   const u32 port = RZG2L_PINMUX_TO_PORT(offset);
+   const u8 pin = RZG2L_PINMUX_TO_PIN(offset);
+   u16 pm_state;
+
+   pm_state = (readw(data->base + PM(port)) >> (pin * 2)) & PM_MASK;
+   switch (pm_state) {
+   case PM_INPUT:
+   return !!(readb(data->base + PIN(port)) & BIT(pin));
+   case PM_OUTPUT:
+   case PM_OUTPUT_IEN:
+   return !!(readb(data->base + P(port)) & BIT(pin));
+   default:/* PM_HIGH_Z */
+   return 0;
+   }
+}
+
+static int rzg2l_gpio_set_value(struct udevice *dev, unsigned int offset,
+   int value)
+{
+   const struct rzg2l_pfc_data *data =
+   (const struct rzg2l_pfc_data *)dev_get_driver_data(dev);
+   const u32 port = RZG2L_PINMUX_TO_PORT(offset);
+   const u8 pin = RZG2L_PINMUX_TO_PIN(offset);
+
+   rzg2l_gpio_set(data, port, pin, (bool)value);
+   return 0;
+}
+
+static void rzg2l_gpio_set_direction(const struct rzg2l_pfc_data *data,
+u32 port, u8 pin, bool output)
+{
+   clrsetbits_le16(data->base + PM(port), PM_MASK << (pin * 2),
+   (output ? PM_OUTPUT : PM_INPUT) << (pin * 2));
+}
+
+static int rzg2l_gpio_direction_input(struct udevice *dev, unsigned int offset)
+{
+   const struct rzg2l_pfc_data *data =
+   (const struct rzg2l_pfc_data *)dev_get_driver_data(dev);
+   const u32 port = 

[PATCH v2 09/19] cmd: gpio: Skip output on -ENOENT

2023-10-09 Thread Paul Barker
On the Renesas RZ/G2L SoC family, valid GPIO numbers are not contiguous.
This is determined by the device tree, where a fixed number of bits are
used for the 'pin' number within a 'port', even though not all ports
have the same number of pins. The device tree can't be changed here
without breaking backwards compatibility in Linux, which we don't want
to do.

To avoid printing a status for each of these invalid GPIO numbers when
a user executes `gpio status -a`, we allow gpio_get_function() to return
-ENOENT when the given offset does not refer to a valid GPIO pin and we
skip printing anything if this occurs.

Signed-off-by: Paul Barker 
---
v1->v2:
  * New patch to simplify `gpio status -a` output.

 cmd/gpio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cmd/gpio.c b/cmd/gpio.c
index f4565982ecd9..a55d5970765b 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -17,6 +17,7 @@
 #endif
 #include 
 #include 
+#include 
 
 __weak int name_to_gpio(const char *name)
 {
@@ -69,6 +70,8 @@ static void gpio_get_description(struct udevice *dev, const 
char *bank_name,
printf("%s\n", buf);
return;
 err:
+   if (ret == -ENOENT)
+   return;
printf("Error %d\n", ret);
 }
 
-- 
2.39.2



[PATCH v2 08/19] arm: rmobile: Restrict PINCTRL_PFC selection to R-Car gen3/gen4

2023-10-09 Thread Paul Barker
The RZ/G2L family uses CONFIG_RCAR_64 but does not share a common PFC
driver with the R-Car gen3 & gen4 boards.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added Marek's Reviewed-by.

 arch/arm/mach-rmobile/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig
index c5419e8d69c0..af1f99197d9f 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -9,7 +9,6 @@ config RCAR_64
select PHY
select PINCONF
select PINCTRL
-   select PINCTRL_PFC
select POSITION_INDEPENDENT
imply CMD_FS_UUID
imply CMD_GPT
@@ -29,6 +28,7 @@ config RCAR_GEN3
bool "Renesas ARM SoCs R-Car Gen3 (64bit)"
select RCAR_64
select SUPPORT_SPL
+   select PINCTRL_PFC
imply SPL
imply SPL_BOARD_INIT
imply SPL_GZIP
@@ -43,6 +43,7 @@ config RCAR_GEN3
 config RCAR_GEN4
bool "Renesas ARM SoCs R-Car Gen4 (64bit)"
select RCAR_64
+   select PINCTRL_PFC
 
 config RZA1
prompt "Renesas ARM SoCs RZ/A1 (32bit)"
-- 
2.39.2



[PATCH v2 07/19] clk: renesas: Add RZ/G2L & RZ/G2LC CPG driver

2023-10-09 Thread Paul Barker
This driver provides clock and reset control for the Renesas R9A07G044L
(RZ/G2L) and R9A07G044C (RZ/G2LC) SoC. It consists of two parts:

* driver code which is applicable to all SoCs in the RZ/G2L family.

* static data describing the clocks and resets which are specific to the
  R9A07G044{L,C} SoCs. The identifier r9a07g044 (without a final letter)
  is used to indicate that both SoCs are supported.

clk_set_rate() and clk_get_rate() are implemented only for the clocks
that are actually used in u-boot.

The CPG driver is marked with DM_FLAG_PRE_RELOC to ensure that its bind
function is called before the SCIF (serial port) driver is probed. This
is required so that we can de-assert the relevant reset signal during
the serial driver probe function.

This patch is based on the corresponding Linux v6.5 driver
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Added the exact Linux commit we imported from.
  * Sorted imply statements under config RZG2L.
  * Note that this CPG driver will also be used for the RZ/G2LC.
  * Clarify the way we use `r9a07g044` in the code.
  * Fix use of brackets in definitions & expressions.
  * Fix comment block style.
  * Fix mixed tabs/spaces usage.
  * Use const where possible for variables.

 arch/arm/mach-rmobile/Kconfig   |   1 +
 arch/arm/mach-rmobile/Kconfig.rzg2l |   1 +
 drivers/clk/renesas/Kconfig |   9 +
 drivers/clk/renesas/Makefile|   2 +
 drivers/clk/renesas/r9a07g044-cpg.c | 384 +
 drivers/clk/renesas/rzg2l-cpg.c | 505 
 drivers/clk/renesas/rzg2l-cpg.h | 319 ++
 7 files changed, 1221 insertions(+)
 create mode 100644 drivers/clk/renesas/r9a07g044-cpg.c
 create mode 100644 drivers/clk/renesas/rzg2l-cpg.c
 create mode 100644 drivers/clk/renesas/rzg2l-cpg.h

diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig
index 1d8d26d8367f..c5419e8d69c0 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -70,6 +70,7 @@ config RZG2L
prompt "Renesas RZ/G2L Family ARM SoCs"
select GICV3
select RCAR_64
+   imply CLK_RZG2L
imply MULTI_DTB_FIT
imply MULTI_DTB_FIT_USER_DEFINED_AREA
imply RENESAS_SDHI
diff --git a/arch/arm/mach-rmobile/Kconfig.rzg2l 
b/arch/arm/mach-rmobile/Kconfig.rzg2l
index eda04df5c619..039d6b0a45aa 100644
--- a/arch/arm/mach-rmobile/Kconfig.rzg2l
+++ b/arch/arm/mach-rmobile/Kconfig.rzg2l
@@ -5,6 +5,7 @@ if RZG2L
 
 config R9A07G044L
bool "Renesas R9A07G044L SoC"
+   imply CLK_R9A07G044
help
  Enable support for the Renesas R9A07G044L (RZ/G2L) SoC.
 
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 437a82cd48be..927d62cf99a3 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -156,3 +156,12 @@ config CLK_R9A06G032
depends on CLK_RENESAS
help
  Enable this to support the clocks on Renesas R9A06G032 SoC.
+
+config CLK_RZG2L
+   bool "Renesas RZ/G2L family clock support"
+   depends on CLK_RENESAS
+   select DM_RESET
+
+config CLK_R9A07G044
+   bool "RZ/G2L (R9A07G044L) clock support"
+   depends on CLK_RZG2L
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 48373e61b901..df7e225e9ca4 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -23,3 +23,5 @@ obj-$(CONFIG_CLK_R8A779A0) += r8a779a0-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A779F0) += r8a779f0-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A779G0) += r8a779g0-cpg-mssr.o
 obj-$(CONFIG_CLK_R9A06G032) += r9a06g032-clocks.o
+obj-$(CONFIG_CLK_RZG2L) += rzg2l-cpg.o
+obj-$(CONFIG_CLK_R9A07G044) += r9a07g044-cpg.o
diff --git a/drivers/clk/renesas/r9a07g044-cpg.c 
b/drivers/clk/renesas/r9a07g044-cpg.c
new file mode 100644
index ..2336028a7367
--- /dev/null
+++ b/drivers/clk/renesas/r9a07g044-cpg.c
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/G2L CPG driver
+ *
+ * Copyright (C) 2021-2023 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rzg2l-cpg.h"
+
+/* Divider tables */
+static const struct clk_div_table dtable_1_8[] = {
+   {0, 1},
+   {1, 2},
+   {2, 4},
+   {3, 8},
+   {0, 0},
+};
+
+static const struct clk_div_table dtable_1_32[] = {
+   {0, 1},
+   {1, 2},
+   {2, 4},
+   {3, 8},
+   {4, 32},
+   {0, 0},
+};
+
+static const struct clk_div_table dtable_16_128[] = {
+   {0, 16},
+   {1, 32},
+   {2, 64},
+   {3, 128},
+   {0, 0},
+};
+
+/* Mux clock tables */
+static const char * const sel_pll3_3[] = { ".pll3_533", ".pll3_400" };
+static const char * const sel_pll5_4[] = { ".pll5_foutpostdiv", 
".pll5_fout1ph0" };
+static const char * const sel_pll6_2[] = { ".pll6_250", ".pll5_250" };
+static const char * const sel_shdi[] = { ".clk_533", 

[PATCH v2 06/19] arm: rmobile: Add basic R9A07G044L SoC support

2023-10-09 Thread Paul Barker
Add a config option for the R9A07G044L SoC used in the RZ/G2L so that we
can make use of this in the subsequent driver patches.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
v1->v2:
  * Reword config R9A07G044L description to improve clarity.

 arch/arm/mach-rmobile/Kconfig.rzg2l | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.rzg2l 
b/arch/arm/mach-rmobile/Kconfig.rzg2l
index 37ff6cd34160..eda04df5c619 100644
--- a/arch/arm/mach-rmobile/Kconfig.rzg2l
+++ b/arch/arm/mach-rmobile/Kconfig.rzg2l
@@ -3,6 +3,11 @@
 
 if RZG2L
 
+config R9A07G044L
+   bool "Renesas R9A07G044L SoC"
+   help
+ Enable support for the Renesas R9A07G044L (RZ/G2L) SoC.
+
 config MULTI_DTB_FIT_UNCOMPRESS_SZ
default 0x8 if TARGET_RZG2L_SMARC_EVK
 
-- 
2.39.2



[PATCH v2 05/19] arm: rmobile: Add basic RZ/G2L family support

2023-10-09 Thread Paul Barker
The Renesas RZ/G2L family includes the following ARM SoCs:

* RZ/G2L  (r9a07g044l)
* RZ/G2LC (r9a07g044c)
* RZ/G2UL (r9a07g043u)
* RZ/V2L  (r9a07g054l)

Support for individual SoCs and evaluation boards will be added in
separate patches.

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Sorted select/imply statements under config RZG2L.
  * Expanded help message for config RZG2L.
  * Added Marek's Reviewed-by.

 arch/arm/mach-rmobile/Kconfig| 15 +++
 arch/arm/mach-rmobile/Kconfig.rzg2l  | 12 
 arch/arm/mach-rmobile/include/mach/rmobile.h |  2 ++
 arch/arm/mach-rmobile/include/mach/rzg2l.h   | 13 +
 4 files changed, 42 insertions(+)
 create mode 100644 arch/arm/mach-rmobile/Kconfig.rzg2l
 create mode 100644 arch/arm/mach-rmobile/include/mach/rzg2l.h

diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig
index 3061ccd34c8b..1d8d26d8367f 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -66,6 +66,20 @@ config RZN1
select SYSRESET_SYSCON
imply CMD_DM
 
+config RZG2L
+   prompt "Renesas RZ/G2L Family ARM SoCs"
+   select GICV3
+   select RCAR_64
+   imply MULTI_DTB_FIT
+   imply MULTI_DTB_FIT_USER_DEFINED_AREA
+   imply RENESAS_SDHI
+   imply SYS_MALLOC_F
+   help
+ Enable support for the Renesas RZ/G2L family of SoCs. Currently
+ support is only included for the RZ/G2L itself (based on the R9A07G044
+ SoC). Support for additional SoCs in this family (RZ/G2LC, RZ/G2UL,
+ RZ/V2L & RZ/Five) is not yet available.
+
 endchoice
 
 config SYS_SOC
@@ -75,5 +89,6 @@ source "arch/arm/mach-rmobile/Kconfig.32"
 source "arch/arm/mach-rmobile/Kconfig.64"
 source "arch/arm/mach-rmobile/Kconfig.rza1"
 source "arch/arm/mach-rmobile/Kconfig.rzn1"
+source "arch/arm/mach-rmobile/Kconfig.rzg2l"
 
 endif
diff --git a/arch/arm/mach-rmobile/Kconfig.rzg2l 
b/arch/arm/mach-rmobile/Kconfig.rzg2l
new file mode 100644
index ..37ff6cd34160
--- /dev/null
+++ b/arch/arm/mach-rmobile/Kconfig.rzg2l
@@ -0,0 +1,12 @@
+# Copyright (C) 2023 Renesas Electronics Corporation
+# SPDX-License-Identifier: GPL-2.0+
+
+if RZG2L
+
+config MULTI_DTB_FIT_UNCOMPRESS_SZ
+   default 0x8 if TARGET_RZG2L_SMARC_EVK
+
+config MULTI_DTB_FIT_USER_DEF_ADDR
+   default 0x4900 if TARGET_RZG2L_SMARC_EVK
+
+endif
diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h 
b/arch/arm/mach-rmobile/include/mach/rmobile.h
index a14c2aad0a68..d326d5545a6f 100644
--- a/arch/arm/mach-rmobile/include/mach/rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
@@ -19,6 +19,8 @@
 #elif defined(CONFIG_RCAR_GEN4)
 #include 
 #elif defined(CONFIG_R7S72100)
+#elif defined(CONFIG_RZG2L)
+#include 
 #else
 #error "SOC Name not defined"
 #endif
diff --git a/arch/arm/mach-rmobile/include/mach/rzg2l.h 
b/arch/arm/mach-rmobile/include/mach/rzg2l.h
new file mode 100644
index ..057df5cb9d46
--- /dev/null
+++ b/arch/arm/mach-rmobile/include/mach/rzg2l.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * RZ/G2L SoC Family support.
+ * Copyright (C) 2023 Renesas Electronics Corporation
+ */
+
+#ifndef __ASM_ARCH_RZG2L_H
+#define __ASM_ARCH_RZG2L_H
+
+#define GICD_BASE  0x1190
+#define GICR_BASE  0x1196
+
+#endif /* __ASM_ARCH_RZG2L_H */
-- 
2.39.2



[PATCH v2 04/19] dt-bindings: Add RZ/G2L IRQC bindings

2023-10-09 Thread Paul Barker
Import bindings for the Interrupt Controller (IRQC) module in the
Renesas RZ/G2L SoC family.

This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added the exact Linux commit we imported from.
  * Add Marek's Reivewed-by.

 .../interrupt-controller/irqc-rzg2l.h | 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 include/dt-bindings/interrupt-controller/irqc-rzg2l.h

diff --git a/include/dt-bindings/interrupt-controller/irqc-rzg2l.h 
b/include/dt-bindings/interrupt-controller/irqc-rzg2l.h
new file mode 100644
index ..34ce778885a1
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/irqc-rzg2l.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * This header provides constants for Renesas RZ/G2L family IRQC bindings.
+ *
+ * Copyright (C) 2022 Renesas Electronics Corp.
+ *
+ */
+
+#ifndef __DT_BINDINGS_IRQC_RZG2L_H
+#define __DT_BINDINGS_IRQC_RZG2L_H
+
+/* NMI maps to SPI0 */
+#define RZG2L_NMI  0
+
+/* IRQ0-7 map to SPI1-8 */
+#define RZG2L_IRQ0 1
+#define RZG2L_IRQ1 2
+#define RZG2L_IRQ2 3
+#define RZG2L_IRQ3 4
+#define RZG2L_IRQ4 5
+#define RZG2L_IRQ5 6
+#define RZG2L_IRQ6 7
+#define RZG2L_IRQ7 8
+
+#endif /* __DT_BINDINGS_IRQC_RZG2L_H */
-- 
2.39.2



[PATCH v2 03/19] dt-bindings: Add RZ/G2L PFC bindings

2023-10-09 Thread Paul Barker
Import bindings for the Port Function Control (PFC) module in the
Renesas RZ/G2L SoC family.

This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added the exact Linux commit we imported from.
  * Add Marek's Reivewed-by.

 include/dt-bindings/pinctrl/rzg2l-pinctrl.h | 23 +
 1 file changed, 23 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/rzg2l-pinctrl.h

diff --git a/include/dt-bindings/pinctrl/rzg2l-pinctrl.h 
b/include/dt-bindings/pinctrl/rzg2l-pinctrl.h
new file mode 100644
index ..c78ed5e5efb7
--- /dev/null
+++ b/include/dt-bindings/pinctrl/rzg2l-pinctrl.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * This header provides constants for Renesas RZ/G2L family pinctrl bindings.
+ *
+ * Copyright (C) 2021 Renesas Electronics Corp.
+ *
+ */
+
+#ifndef __DT_BINDINGS_RZG2L_PINCTRL_H
+#define __DT_BINDINGS_RZG2L_PINCTRL_H
+
+#define RZG2L_PINS_PER_PORT8
+
+/*
+ * Create the pin index from its bank and position numbers and store in
+ * the upper 16 bits the alternate function identifier
+ */
+#define RZG2L_PORT_PINMUX(b, p, f) ((b) * RZG2L_PINS_PER_PORT + (p) | ((f) 
<< 16))
+
+/* Convert a port and pin label to its global pin index */
+#define RZG2L_GPIO(port, pin)  ((port) * RZG2L_PINS_PER_PORT + (pin))
+
+#endif /* __DT_BINDINGS_RZG2L_PINCTRL_H */
-- 
2.39.2



[PATCH v2 02/19] dt-bindings: Add RZ/G2L CPG bindings

2023-10-09 Thread Paul Barker
Import bindings for the Clock Pulse Generator (CPG) module in the
Renesas RZ/G2L SoC family.

This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).

Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Added the exact Linux commit we imported from.
  * Add Marek's Reivewed-by.

 include/dt-bindings/clock/r9a07g044-cpg.h | 220 ++
 1 file changed, 220 insertions(+)
 create mode 100644 include/dt-bindings/clock/r9a07g044-cpg.h

diff --git a/include/dt-bindings/clock/r9a07g044-cpg.h 
b/include/dt-bindings/clock/r9a07g044-cpg.h
new file mode 100644
index ..0bb17ff1a01a
--- /dev/null
+++ b/include/dt-bindings/clock/r9a07g044-cpg.h
@@ -0,0 +1,220 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+ *
+ * Copyright (C) 2021 Renesas Electronics Corp.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
+#define __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
+
+#include 
+
+/* R9A07G044 CPG Core Clocks */
+#define R9A07G044_CLK_I0
+#define R9A07G044_CLK_I2   1
+#define R9A07G044_CLK_G2
+#define R9A07G044_CLK_S0   3
+#define R9A07G044_CLK_S1   4
+#define R9A07G044_CLK_SPI0 5
+#define R9A07G044_CLK_SPI1 6
+#define R9A07G044_CLK_SD0  7
+#define R9A07G044_CLK_SD1  8
+#define R9A07G044_CLK_M0   9
+#define R9A07G044_CLK_M1   10
+#define R9A07G044_CLK_M2   11
+#define R9A07G044_CLK_M3   12
+#define R9A07G044_CLK_M4   13
+#define R9A07G044_CLK_HP   14
+#define R9A07G044_CLK_TSU  15
+#define R9A07G044_CLK_ZT   16
+#define R9A07G044_CLK_P0   17
+#define R9A07G044_CLK_P1   18
+#define R9A07G044_CLK_P2   19
+#define R9A07G044_CLK_AT   20
+#define R9A07G044_OSCCLK   21
+#define R9A07G044_CLK_P0_DIV2  22
+
+/* R9A07G044 Module Clocks */
+#define R9A07G044_CA55_SCLK0
+#define R9A07G044_CA55_PCLK1
+#define R9A07G044_CA55_ATCLK   2
+#define R9A07G044_CA55_GICCLK  3
+#define R9A07G044_CA55_PERICLK 4
+#define R9A07G044_CA55_ACLK5
+#define R9A07G044_CA55_TSCLK   6
+#define R9A07G044_GIC600_GICCLK7
+#define R9A07G044_IA55_CLK 8
+#define R9A07G044_IA55_PCLK9
+#define R9A07G044_MHU_PCLK 10
+#define R9A07G044_SYC_CNT_CLK  11
+#define R9A07G044_DMAC_ACLK12
+#define R9A07G044_DMAC_PCLK13
+#define R9A07G044_OSTM0_PCLK   14
+#define R9A07G044_OSTM1_PCLK   15
+#define R9A07G044_OSTM2_PCLK   16
+#define R9A07G044_MTU_X_MCK_MTU3   17
+#define R9A07G044_POE3_CLKM_POE18
+#define R9A07G044_GPT_PCLK 19
+#define R9A07G044_POEG_A_CLKP  20
+#define R9A07G044_POEG_B_CLKP  21
+#define R9A07G044_POEG_C_CLKP  22
+#define R9A07G044_POEG_D_CLKP  23
+#define R9A07G044_WDT0_PCLK24
+#define R9A07G044_WDT0_CLK 25
+#define R9A07G044_WDT1_PCLK26
+#define R9A07G044_WDT1_CLK 27
+#define R9A07G044_WDT2_PCLK28
+#define R9A07G044_WDT2_CLK 29
+#define R9A07G044_SPI_CLK2 30
+#define R9A07G044_SPI_CLK  31
+#define R9A07G044_SDHI0_IMCLK  32
+#define R9A07G044_SDHI0_IMCLK2 33
+#define R9A07G044_SDHI0_CLK_HS 34
+#define R9A07G044_SDHI0_ACLK   35
+#define R9A07G044_SDHI1_IMCLK  36
+#define R9A07G044_SDHI1_IMCLK2 37
+#define R9A07G044_SDHI1_CLK_HS 38
+#define R9A07G044_SDHI1_ACLK   39
+#define R9A07G044_GPU_CLK  40
+#define R9A07G044_GPU_AXI_CLK  41
+#define R9A07G044_GPU_ACE_CLK  42
+#define R9A07G044_ISU_ACLK 43
+#define R9A07G044_ISU_PCLK 44
+#define R9A07G044_H264_CLK_A   45
+#define R9A07G044_H264_CLK_P   46
+#define R9A07G044_CRU_SYSCLK   47
+#define R9A07G044_CRU_VCLK 48
+#define R9A07G044_CRU_PCLK 49
+#define R9A07G044_CRU_ACLK 50
+#define R9A07G044_MIPI_DSI_PLLCLK  51
+#define R9A07G044_MIPI_DSI_SYSCLK  52
+#define R9A07G044_MIPI_DSI_ACLK53
+#define R9A07G044_MIPI_DSI_PCLK54
+#define R9A07G044_MIPI_DSI_VCLK55
+#define R9A07G044_MIPI_DSI_LPCLK   56
+#define R9A07G044_LCDC_CLK_A   57
+#define R9A07G044_LCDC_CLK_P   58
+#define R9A07G044_LCDC_CLK_D   59
+#define R9A07G044_SSI0_PCLK2   60
+#define R9A07G044_SSI0_PCLK_SFR61
+#define R9A07G044_SSI1_PCLK2   62
+#define R9A07G044_SSI1_PCLK_SFR63
+#define R9A07G044_SSI2_PCLK2   64
+#define R9A07G044_SSI2_PCLK_SFR65
+#define 

[PATCH v2 01/19] serial: sh: Fix compile error when lacking HSCIF support

2023-10-09 Thread Paul Barker
If we attempt to compile serial_sh.c for a system which lacks HSCIF
support (e.g. R8A7740), we see the following compilation error:

In file included from drivers/serial/serial_sh.c:20:
drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’:
drivers/serial/serial_sh.h:429:35: warning: implicit declaration of 
function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? 
[-Wimplicit-function-declaration]
  429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value)
  |   ^~~~
drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’
   62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
  | ^~~

To fix this, only try to support access to the HSSRR register for SoCs
where it actually exists.

Support for the RZ/G2L will be introduced in following patches, which
selects CONFIG_RCAR_64 but does not have HSCIF interfaces, so check for
CONFIG_RCAR_GEN2 || CONFIG_RCAR_GEN3 || CONFIG_RCAR_GEN4 to determine if
HSCIF is present.

Fixes: bbe36e29ca2c ('serial: sh: Add HSCIF support for R-Car SoC')
Signed-off-by: Paul Barker 
Reviewed-by: Biju Das 
Cc: Hai Pham 
Cc: Simon Glass 
Reviewed-by: Marek Vasut 
---
v1->v2:
  * Improve commit message.
  * Add Marek's Reivewed-by.

 drivers/serial/serial_sh.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 20cda5dbe272..5e543dbf3d58 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -58,8 +58,10 @@ static void sh_serial_init_generic(struct uart_port *port)
sci_out(port, SCSPTR, 0x0003);
 #endif
 
+#if IS_ENABLED(CONFIG_RCAR_GEN2) || IS_ENABLED(CONFIG_RCAR_GEN3) || 
IS_ENABLED(CONFIG_RCAR_GEN4)
if (port->type == PORT_HSCIF)
sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
+#endif
 }
 
 static void
-- 
2.39.2



[PATCH v2 00/19] Add support for the Renesas RZ/G2L SMARC EVK

2023-10-09 Thread Paul Barker
These patches add initial support for the RZ/G2L SMARC Evaluation board
kit (EVK), consisting of the RZ/G2L System-on-Module (SOM) based on the
R9A07G044L2 SoC, and a common SMARC carrier board. Support is included
for the CPG (clock & reset control module), PFC (pinctrl & gpio module),
SDHI (eMMC & SD card interfaces) & SCIF (serial port) modules. Enough
functionality is included to boot a modern Linux kernel from the eMMC or
SD card interfaces.

Further work will follow in time to add support for other interfaces on
the RZ/G2L (such as Ethernet) and other SoCs in the RZ/G2L family
(including the RZ/G2UL, RZ/G2LC, RZ/V2L & RZ/Five).

See individual patches for details of the changes since v1 of this series.

Paul Barker (19):
  serial: sh: Fix compile error when lacking HSCIF support
  dt-bindings: Add RZ/G2L CPG bindings
  dt-bindings: Add RZ/G2L PFC bindings
  dt-bindings: Add RZ/G2L IRQC bindings
  arm: rmobile: Add basic RZ/G2L family support
  arm: rmobile: Add basic R9A07G044L SoC support
  clk: renesas: Add RZ/G2L & RZ/G2LC CPG driver
  arm: rmobile: Restrict PINCTRL_PFC selection to R-Car gen3/gen4
  cmd: gpio: Skip output on -ENOENT
  pinctrl: renesas: Add RZ/G2L PFC driver
  serial: sh: Fix error handling
  serial: sh: Add RZ/G2L SCIF support
  mmc: renesas-sdhi: Refactor probe function
  mmc: renesas-sdhi: Initialize module on RZ/G2L
  arm: rmobile: Include  in header
  arm: rmobile: Add CPU detection for RZ/G2L
  arm: rmobile: Support RZ/G2L memory map
  arm: dts: Import RZ/G2L SMARC EVK device tree
  board: rzg2l: Add RZ/G2L SMARC EVK board

 arch/arm/dts/Makefile |3 +
 arch/arm/dts/r9a07g044.dtsi   | 1273 +
 arch/arm/dts/r9a07g044l2-smarc.dts|   18 +
 arch/arm/dts/r9a07g044l2.dtsi |   13 +
 arch/arm/dts/rz-smarc-common.dtsi |  183 +++
 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi |  137 ++
 arch/arm/dts/rzg2l-smarc-som.dtsi |  353 +
 arch/arm/dts/rzg2l-smarc.dtsi |  144 ++
 arch/arm/mach-rmobile/Kconfig |   22 +-
 arch/arm/mach-rmobile/Kconfig.rzg2l   |   32 +
 arch/arm/mach-rmobile/Makefile|5 +-
 arch/arm/mach-rmobile/cpu_info-rzg2l.c|   63 +
 arch/arm/mach-rmobile/include/mach/rmobile.h  |5 +
 arch/arm/mach-rmobile/include/mach/rzg2l.h|   13 +
 arch/arm/mach-rmobile/memmap-rzg2l.c  |  127 ++
 board/renesas/rzg2l/Kconfig   |   18 +
 board/renesas/rzg2l/MAINTAINERS   |6 +
 board/renesas/rzg2l/Makefile  |4 +
 board/renesas/rzg2l/rzg2l.c   |   67 +
 cmd/gpio.c|3 +
 configs/renesas_rzg2l_smarc_defconfig |   52 +
 drivers/clk/renesas/Kconfig   |9 +
 drivers/clk/renesas/Makefile  |2 +
 drivers/clk/renesas/r9a07g044-cpg.c   |  384 +
 drivers/clk/renesas/rzg2l-cpg.c   |  505 +++
 drivers/clk/renesas/rzg2l-cpg.h   |  319 +
 drivers/gpio/Kconfig  |7 +
 drivers/gpio/Makefile |1 +
 drivers/gpio/rzg2l-gpio.c |  170 +++
 drivers/mmc/renesas-sdhi.c|   89 +-
 drivers/pinctrl/renesas/Kconfig   |   10 +
 drivers/pinctrl/renesas/Makefile  |1 +
 drivers/pinctrl/renesas/rzg2l-pfc.c   |  625 
 drivers/serial/serial_sh.c|   35 +-
 drivers/serial/serial_sh.h|   19 +-
 include/configs/rzg2l-smarc.h |   14 +
 include/dt-bindings/clock/r9a07g044-cpg.h |  220 +++
 .../interrupt-controller/irqc-rzg2l.h |   25 +
 include/dt-bindings/pinctrl/rzg2l-pinctrl.h   |   23 +
 include/renesas/rzg2l-pfc.h   |  110 ++
 40 files changed, 5097 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm/dts/r9a07g044.dtsi
 create mode 100644 arch/arm/dts/r9a07g044l2-smarc.dts
 create mode 100644 arch/arm/dts/r9a07g044l2.dtsi
 create mode 100644 arch/arm/dts/rz-smarc-common.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc-som.dtsi
 create mode 100644 arch/arm/dts/rzg2l-smarc.dtsi
 create mode 100644 arch/arm/mach-rmobile/Kconfig.rzg2l
 create mode 100644 arch/arm/mach-rmobile/cpu_info-rzg2l.c
 create mode 100644 arch/arm/mach-rmobile/include/mach/rzg2l.h
 create mode 100644 arch/arm/mach-rmobile/memmap-rzg2l.c
 create mode 100644 board/renesas/rzg2l/Kconfig
 create mode 100644 board/renesas/rzg2l/MAINTAINERS
 create mode 100644 board/renesas/rzg2l/Makefile
 create mode 100644 board/renesas/rzg2l/rzg2l.c
 create mode 100644 configs/renesas_rzg2l_smarc_defconfig
 create mode 100644 drivers/clk/renesas/r9a07g044-cpg.c
 create mode 100644 drivers/clk/renesas/rzg2l-cpg.c
 create mode 100644 drivers/clk/renesas/rzg2l-cpg.h
 create mode 100644 

Re: [PATCH v3 01/38] spl: Use CONFIG_SPL... instead of CONFIG_..._SPL_...

2023-10-09 Thread Felix Brack
On 24.09.23 21:24, Simon Glass wrote:
> We like to put the SPL first so it is clear that it relates to SPL. Rename
> various malloc-related options which have crept in, to stick to this
> convention.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Marcel Ziswiler 
> Reviewed-by: Martyn Welch 
> Reviewed-by: Svyatoslav Ryhel 
> ---
> 
> (no changes since v1)
> 
For the PDU001 board:

Tested-by: Felix Brack 


Re: [PATCH 07/25] tegra: Change #ifdef for nop

2023-10-09 Thread Simon Glass
Hi Sean,

On Sat, 7 Oct 2023 at 17:21, Sean Anderson  wrote:
>
> On 10/7/23 19:10, Simon Glass wrote:
> > Hi Tom.
> >
> > On Sun, 24 Sept 2023 at 18:43, Tom Rini  wrote:
> >>
> >> On Sun, Sep 24, 2023 at 02:39:25PM -0600, Simon Glass wrote:
> >>
> >>> This code is normally compiled for Tegra, but sandbox can also compile
> >>> it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
> >>> possible to disable UNIT_TEST for sandbox.
> >>>
> >>> Correct the condition.
> >>>
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>>   include/k210/pll.h | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/include/k210/pll.h b/include/k210/pll.h
> >>> index fd16a89cb203..6dd60b2eb4fc 100644
> >>> --- a/include/k210/pll.h
> >>> +++ b/include/k210/pll.h
> >>> @@ -13,7 +13,7 @@ struct k210_pll_config {
> >>>u8 od;
> >>>   };
> >>>
> >>> -#ifdef CONFIG_UNIT_TEST
> >>> +#ifdef CONFIG_SANDBOX
> >>>   TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
> >>> struct k210_pll_config *best);
> >>>   #ifndef nop
> >>
> >> Tegra? Do you mean sifive?  That's where CLK_K210 stuff is... but it
> >
> > Oh yes, I got confused.
> >
> >> also seems wrong, you can run unit test on real hardware, and this is a
> >> test that could (should?) be run on that platform.
> >
> > Only if it enables UNIT_TEST. You cannot run unit tests without that.
> > The current tests are designed for sandbox.
>
> FWIW I have run this test on actual hardware. My intent here was to allow
> unit tests to access functions which would otherwise be declared static.

Er, with or without UNIT_TEST enabled? How can it even build if this
declaration is only for sandbox?

Regards,
Simon


[PATCH v4 4/4] board: Add support for Conclusive KSTR-SAMA5D27

2023-10-09 Thread Artur Rojek
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.

Co-developed-by: Jakub Klama 
Signed-off-by: Jakub Klama 
Co-developed-by: Marcin Jabrzyk 
Signed-off-by: Marcin Jabrzyk 
Signed-off-by: Artur Rojek 
---

v4: - utilize EVT_SETTINGS_R in order to read MAC and serial number from
  EEPROM

v3: - use CONFIG_ID_EEPROM to read serial number 
- as side-effect of using CONFIG_ID_EEPROM, KSTR-SAMA5D27 now also
  correctly uses EEPROM embedded MAC addresses (overlooked in v1-v2)
- use CONFIG_DISPLAY_BOARDINFO_LATE for printing the board model and
  serial number, and provide the required checkboard() call 
- drop CONFIG_BOARD_LATE_INIT, as not needed anymore
- defconfig cleanup

v2: - remove redundant license text from at91-kstr-sama5d27.dts
- when defining properties in .dts, reference nodes by labels
- drop nodes for usb0 and pmic, as these aren't used by drivers 
- switch i2c to flexcom driver and make the necessary dts changes
- sort includes in at91-kstr-sama5d27.dts alphabetically

 arch/arm/dts/Makefile |   3 +
 arch/arm/dts/at91-kstr-sama5d27.dts   | 131 ++
 arch/arm/mach-at91/Kconfig|  12 +
 board/conclusive/kstr-sama5d27/Kconfig|  15 ++
 board/conclusive/kstr-sama5d27/MAINTAINERS|   8 +
 board/conclusive/kstr-sama5d27/Makefile   |   5 +
 .../conclusive/kstr-sama5d27/kstr-sama5d27.c  | 239 ++
 configs/kstr_sama5d27_defconfig   |  73 ++
 include/configs/kstr-sama5d27.h   |  15 ++
 9 files changed, 501 insertions(+)
 create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts
 create mode 100644 board/conclusive/kstr-sama5d27/Kconfig
 create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS
 create mode 100644 board/conclusive/kstr-sama5d27/Makefile
 create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c
 create mode 100644 configs/kstr_sama5d27_defconfig
 create mode 100644 include/configs/kstr-sama5d27.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7f6..c0f3525ed4d3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1198,6 +1198,9 @@ dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
 dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
at91-sama5d27_wlsom1_ek.dtb
 
+dtb-$(CONFIG_TARGET_KSTR_SAMA5D27) += \
+   at91-kstr-sama5d27.dtb
+
 dtb-$(CONFIG_TARGET_SAMA5D2_ICP) += \
at91-sama5d2_icp.dtb
 
diff --git a/arch/arm/dts/at91-kstr-sama5d27.dts 
b/arch/arm/dts/at91-kstr-sama5d27.dts
new file mode 100644
index ..fe9ec7e5bbc3
--- /dev/null
+++ b/arch/arm/dts/at91-kstr-sama5d27.dts
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * at91-kstr-sama5d27.dts - Device Tree file for Conclusive KSTR-SAMA5D27 board
+ *
+ *  Copyright (C) 2019-2023 Conclusive Engineering Sp. z o. o.
+ *
+ */
+/dts-v1/;
+
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Conclusive KSTR-SAMA5D27";
+   compatible = "conclusive,kstr-sama5d27", "atmel,sama5d2", "atmel,sama5";
+
+   chosen {
+   bootph-all;
+   stdout-path = 
+   };
+};
+
+_xtal {
+   clock-frequency = <1200>;
+};
+
+ {
+   bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_sdmmc0_cmd_dat_default 
_sdmmc0_ck_cd_default>;
+   status = "okay";
+   bootph-all;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart1_default>;
+   status = "okay";
+   bootph-all;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_macb0_rmii _macb0_phy_irq>;
+   phy-mode = "rmii";
+   status = "okay";
+
+   ethernet-phy@0 {
+   reg = <0x0>;
+   reset-gpios = < 44 GPIO_ACTIVE_LOW>;
+   };
+};
+
+ {
+   atmel,flexcom-mode = ;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_flx4_i2c>;
+   status = "okay";
+
+   eeprom: eeprom@50 {
+   compatible = "microchip,24c32", "atmel,24c32";
+   reg = <0x50>;
+   read-only;
+   pagesize = <32>;
+   status = "okay";
+   };
+};
+
+ {
+   pinctrl {
+   pinctrl_uart1_default: uart1_default {
+   pinmux = ,
+;
+   bias-disable;
+   bootph-all;
+   };
+
+   pinctrl_macb0_phy_irq: macb0_phy_irq {
+   pinmux = ;
+   bias-disable;
+   bootph-all;
+   };
+
+   pinctrl_macb0_rmii: macb0_rmii {
+   pinmux = ,
+,
+,
+,
+,
+,
+

[PATCH v4 3/4] arm: dts: at91: sama5: Add flexcom4 node

2023-10-09 Thread Artur Rojek
Set up flexcom4 for Microchip SAMA5D27 SoC and prepare it for usage in
I2C mode.

Signed-off-by: Artur Rojek 
---
v3-v4: no change

v2: new patch

 arch/arm/dts/sama5d2.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/dts/sama5d2.dtsi b/arch/arm/dts/sama5d2.dtsi
index dd6468ed96aa..819564fdd5bb 100644
--- a/arch/arm/dts/sama5d2.dtsi
+++ b/arch/arm/dts/sama5d2.dtsi
@@ -781,6 +781,26 @@
status = "disabled";
};
 
+   flx4: flexcom@fc018000 {
+   compatible = "atmel,sama5d2-flexcom";
+   reg = <0xfc018000 0x200>;
+   clocks = <_clk>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0xfc018000 0x800>;
+   status = "disabled";
+
+   i2c6: i2c@600 {
+   compatible = "atmel,sama5d2-i2c";
+   reg = <0x600 0x200>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clk>;
+   clock-names = "i2c6_clk";
+   status = "disabled";
+   };
+   };
+
aic: interrupt-controller@fc02 {
#interrupt-cells = <3>;
compatible = "atmel,sama5d2-aic";
-- 
2.42.0



[PATCH v4 2/4] event: add new EVT_SETTINGS_R event

2023-10-09 Thread Artur Rojek
Introduce EVT_SETTINGS_R, triggered post-relocation and before console
init.

This event gives an option to perform any platform-dependent setup,
which needs to take place before show_board_info(). Usage examples
include readout of EEPROM stored settings.

Signed-off-by: Artur Rojek 
---

v4: new patch

 common/board_r.c | 1 +
 common/event.c   | 1 +
 include/event.h  | 9 +
 3 files changed, 11 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index 52786901be55..a7967849dc0c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -693,6 +693,7 @@ static init_fnc_t init_sequence_r[] = {
 #if defined(CONFIG_ID_EEPROM)
mac_read_from_eeprom,
 #endif
+   INITCALL_EVENT(EVT_SETTINGS_R),
INIT_FUNC_WATCHDOG_RESET
 #if defined(CONFIG_PCI_INIT_R) && !defined(CONFIG_SYS_EARLY_PCI_INIT)
/*
diff --git a/common/event.c b/common/event.c
index 3080d9ed754d..dc61b9672f32 100644
--- a/common/event.c
+++ b/common/event.c
@@ -37,6 +37,7 @@ const char *const type_name[] = {
/* init hooks */
"misc_init_f",
"fsp_init_r",
+   "settings_r",
"last_stage_init",
 
/* Fpga load hook */
diff --git a/include/event.h b/include/event.h
index be4cefd6ae8a..a60a64718e01 100644
--- a/include/event.h
+++ b/include/event.h
@@ -104,6 +104,15 @@ enum event_t {
 */
EVT_FSP_INIT_F,
 
+   /**
+* @EVT_SETTINGS_R:
+* This event is triggered post-relocation and before console init.
+* This gives an option to perform any platform-dependent setup, which
+* needs to take place before show_board_info() (e.g. readout of EEPROM
+* stored settings).
+*/
+   EVT_SETTINGS_R,
+
/**
 * @EVT_LAST_STAGE_INIT:
 * This event is triggered just before jumping to the main loop.
-- 
2.42.0



[PATCH v4 1/4] common: add prototype & rename populate_serial_number()

2023-10-09 Thread Artur Rojek
Rename populate_serial_number() to a more descriptive
serial_read_from_eeprom() and provide the missing function prototype.

This is useful for boards that wish to read their serial number from
EEPROM at init.

Signed-off-by: Artur Rojek 
---

v4: - revert to the approach found in v2
- keep the new serial_read_from_eeprom() name

v3: - restore original function name and make it static
- provide a generic function for reading EEPROM serial number and
  wrap it around the existing tlv logic
- move the env var check out of populate_serial_number() and into
  the new serial_read_from_eeprom() in order to stay consistent with
  the documentation

v2: - rename the function
- move function documentation from .c file to the prototype location

 cmd/tlv_eeprom.c | 14 +-
 include/init.h   | 14 ++
 2 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c8..57cfd355df1b 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1088,19 +1088,7 @@ int mac_read_from_eeprom(void)
return 0;
 }
 
-/**
- *  populate_serial_number - read the serial number from EEPROM
- *
- *  This function reads the serial number from the EEPROM and sets the
- *  appropriate environment variable.
- *
- *  The environment variable is only set if it has not been set
- *  already.  This ensures that any user-saved variables are never
- *  overwritten.
- *
- *  This function must be called after relocation.
- */
-int populate_serial_number(int devnum)
+int serial_read_from_eeprom(int devnum)
 {
char serialstr[257];
int eeprom_index;
diff --git a/include/init.h b/include/init.h
index 4e7fe26c2004..d57a24fd00dd 100644
--- a/include/init.h
+++ b/include/init.h
@@ -271,6 +271,20 @@ void board_init_r(struct global_data *id, ulong dest_addr)
 
 int cpu_init_r(void);
 int mac_read_from_eeprom(void);
+
+/**
+ *  serial_read_from_eeprom - read the serial number from EEPROM
+ *
+ *  This function reads the serial number from the EEPROM and sets the
+ *  appropriate environment variable.
+ *
+ *  The environment variable is only set if it has not been set
+ *  already. This ensures that any user-saved variables are never
+ *  overwritten.
+ *
+ *  This function must be called after relocation.
+ */
+int serial_read_from_eeprom(int devnum);
 int set_cpu_clk_info(void);
 int update_flash_size(int flash_size);
 int arch_early_init_r(void);
-- 
2.42.0



[PATCH v4 0/4] Conclusive KSTR-SAMA5D27 support

2023-10-09 Thread Artur Rojek
Hi all,

this is v4 of the Conclusive KSTR-SAMA5D27 support series.

Patch [1/4] now reverts to the approach found in v2. 

Simon, while the behavior is now identical to the one from v2, I
retained the serial_read_from_eeprom() function name from v3 (it makes
it more consistent with the existing mac_read_from_eeprom()). Because of
that, I refrained from copying your v2 Reviewed-by tag.

Patch [2/4] is new. It introduces a new event, intended to be called
post-relocation and before console init.

As a result, [v3 2/4] patch gets dropped in favor of this much simpler
solution (see [4/4] below for use case).

Patch [3/4] remains unchanged.

Patch [4/4] makes use of the newly introduced EVT_SETTINGS_R, utilizing
it for EEPROM readout of MAC and board serial number settings.

Artur Rojek (4):
  common: add prototype & rename populate_serial_number()
  event: add new EVT_SETTINGS_R event
  arm: dts: at91: sama5: Add flexcom4 node
  board: Add support for Conclusive KSTR-SAMA5D27

 arch/arm/dts/Makefile |   3 +
 arch/arm/dts/at91-kstr-sama5d27.dts   | 131 ++
 arch/arm/dts/sama5d2.dtsi |  20 ++
 arch/arm/mach-at91/Kconfig|  12 +
 board/conclusive/kstr-sama5d27/Kconfig|  15 ++
 board/conclusive/kstr-sama5d27/MAINTAINERS|   8 +
 board/conclusive/kstr-sama5d27/Makefile   |   5 +
 .../conclusive/kstr-sama5d27/kstr-sama5d27.c  | 239 ++
 cmd/tlv_eeprom.c  |  14 +-
 common/board_r.c  |   1 +
 common/event.c|   1 +
 configs/kstr_sama5d27_defconfig   |  73 ++
 include/configs/kstr-sama5d27.h   |  15 ++
 include/event.h   |   9 +
 include/init.h|  14 +
 15 files changed, 547 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts
 create mode 100644 board/conclusive/kstr-sama5d27/Kconfig
 create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS
 create mode 100644 board/conclusive/kstr-sama5d27/Makefile
 create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c
 create mode 100644 configs/kstr_sama5d27_defconfig
 create mode 100644 include/configs/kstr-sama5d27.h

-- 
2.42.0



Re: [PATCH v2 04/27] bootstd: Correct dependencies on CMDLINE

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 05:45:17PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 7 Oct 2023 at 17:32, Tom Rini  wrote:
> >
> > On Sat, Oct 07, 2023 at 05:12:23PM -0600, Simon Glass wrote:
> >
> > > With recent changes in boot/Kconfig it is no-longer possible to disable
> > > CMDLINE. It results in various link errors because some options which
> > > require CMDLINE are enabled regardless of whether it is available.
> >
> > How "recent" is this problem?
> 
> Over the last few years, I think. It was definitely in better shape
> 3-4 years ago.

OK, that makes a little more sense.  But still, this is the wrong
approach I think.  I've got a little more specific feedback against v2,
but I want to see things get unwound from CMDLINE that aren't
specifically commands as they're things those other use cases you've
described will also need to enable.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 08/27] sifive: Change #ifdef for nop

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 05:12:27PM -0600, Simon Glass wrote:

> This code is normally compiled for sifive, but sandbox can also compile
> it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
> possible to disable UNIT_TEST for sandbox.
> 
> Correct the condition.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  include/k210/pll.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/k210/pll.h b/include/k210/pll.h
> index fd16a89cb203..6dd60b2eb4fc 100644
> --- a/include/k210/pll.h
> +++ b/include/k210/pll.h
> @@ -13,7 +13,7 @@ struct k210_pll_config {
>   u8 od;
>  };
>  
> -#ifdef CONFIG_UNIT_TEST
> +#ifdef CONFIG_SANDBOX
>  TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
>struct k210_pll_config *best);
>  #ifndef nop

Sean just explained that this is wrong.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 07/27] test: Make UNIT_TEST depend on CMDLINE

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 05:12:26PM -0600, Simon Glass wrote:

> Many tests make some use of the command line, so require it for all test
> code.
> 
> This could be teased apart, perhaps with a test flag indicating that ut
> uses the command line. Leave that for later.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 06/27] cmd: Add a few more dependencies on CMDLINE

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 05:12:25PM -0600, Simon Glass wrote:
> Add this to some more commands to avoid build errors with sandbox.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  cmd/Kconfig | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6470b138d2f8..f914da6fe1ac 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -224,6 +224,7 @@ menu "Boot commands"
>  
>  config CMD_BOOTD
>   bool "bootd"
> + depends on CMDLINE
>   default y
>   help
> Run the command stored in the environment "bootcmd", i.e.

This is the wrong direction.  cmd/Kconfig needs to be re-organized to
have a menu for the hush options, and then all of the commands should
bee under a main commands menu that depends on CMDLINE.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 05/27] autoboot: Correct dependencies on CMDLINE

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 05:12:24PM -0600, Simon Glass wrote:

> Make AUTOBOOT depend on CMDLINE since it is mostly meaningless without it.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request: u-boot-rockchip-20231007

2023-10-09 Thread Tom Rini
On Sat, Oct 07, 2023 at 06:26:58PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the updates for rockchip platform:
> - Add Board: rk3568 Bananapi R2Pro;
> - Update pcie bifurcation support;
> - dwc_eth_qos controller support for rk3568 and rk3588;
> - Compressed binary support for U-Boot on rockchip platform;
> - dts and config updates for different board and soc;
> 
> CI:
> https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/18047
> 
> Thanks,
> - Kever
> 
> The following changes since commit be2abe73df58a35da9e8d5afb13fccdf1b0faa8e:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-riscv (2023-10-05 
> 13:26:44 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20231007
> 
> for you to fetch changes up to dd8d52c934e8858264f91e8e8e2d8c7d8b059dd7:
> 
>   rockchip: rk356x-u-boot: Add bootph-all to i2c0_xfer pinctrl node 
> (2023-10-07 16:52:48 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] test/py: net: Add dhcp abort test

2023-10-09 Thread Michal Simek




On 10/3/23 14:46, Love Kumar wrote:

Abort the dhcp request in the middle by pressing ctrl + c on u-boot
prompt and validate the abort status.

Signed-off-by: Love Kumar 
---
  test/py/tests/test_net.py | 44 +++
  1 file changed, 44 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index cd4b4dc53cbc..1e8eb0357eef 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -6,6 +6,7 @@
  
  import pytest

  import u_boot_utils
+import re
  
  """

  Note: This test relies on boardenv_* containing configuration values to define
@@ -104,6 +105,49 @@ def test_net_dhcp(u_boot_console):
  global net_set_up
  net_set_up = True
  
+@pytest.mark.buildconfigspec("cmd_dhcp")


Similar issue is visible here too.
There should be CMD_MII dependency.


+def test_net_dhcp_abort(u_boot_console):
+"""Test the dhcp command by pressing ctrl+c in the middle of dhcp request
+
+The boardenv_* file may be used to enable/disable this test; see the
+comment at the beginning of this file.
+"""
+
+test_dhcp = u_boot_console.config.env.get("env__net_dhcp_server", False)
+if not test_dhcp:
+pytest.skip("No DHCP server available")
+
+u_boot_console.run_command("setenv autoload no")
+
+# Phy reset before running dhcp command
+output = u_boot_console.run_command("mii device")
+eth_num = re.search(r"Current device: '(.+?)'", output).groups()[0]
+u_boot_console.run_command(f"mii device {eth_num}")
+output = u_boot_console.run_command("mii info")
+eth_addr = hex(int(re.search(r"PHY (.+?):", output).groups()[0], 16))
+u_boot_console.run_command(f"mii modify {eth_addr} 0 0x8000 0x8000")
+
+u_boot_console.run_command("dhcp", wait_for_prompt=False)
+try:
+u_boot_console.wait_for("Waiting for PHY auto negotiation to complete")
+except:
+pytest.skip("Timeout waiting for PHY auto negotiation to complete")
+
+u_boot_console.wait_for("done")
+
+# Sending Ctrl-C
+output = u_boot_console.run_command(
+chr(3), wait_for_echo=False, send_nl=False
+)
+
+assert "TIMEOUT" not in output
+assert "DHCP client bound to address " not in output
+assert "Abort" in output
+
+# Provide a time to recover from Abort - if it is not performed
+# There is message like: ethernet@ff0e: No link.
+u_boot_console.run_command("sleep 1")
+
  @pytest.mark.buildconfigspec('cmd_dhcp6')
  def test_net_dhcp6(u_boot_console):
  """Test the dhcp6 command.


qemu_arm64 test.py is showing this issue.
 test_net_dhcp_abort __
test/py/tests/test_net.py:138: in test_net_dhcp_abort
eth_num = re.search(r"Current device: '(.+?)'", output).groups()[0]
E   AttributeError: 'NoneType' object has no attribute 'groups'

M


[PATCH] cli: Consume invalid escape sequences early

2023-10-09 Thread Yurii Monakov
Hi Simon,

On Sun, Oct 8, 2023 at 2:10=E2=80=AFAM Simon Glass  wrote:
>
> Hi Yurii,
>
> On Fri, 6 Oct 2023 at 15:32, Yurii Monakov  wrote:
> >
> > This commit fixes some issues with extra 'Esc' keys entered by user:
> >
> > 1. Sequence  right after autoboot stop gives:
> > =3D>
> > nknown command 'ry 'help'
> > =3D>
> > 2. Sequence  gives:
> > =3D> ri
> > Unknown command 'ri' - try 'help'
> > =3D>
> > 3. Extra 'Esc' key presses break backspace functionality.
> >
> > Signed-off-by: Yurii Monakov 
> > ---
> >  common/cli_getch.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/common/cli_getch.c b/common/cli_getch.c
> > index 61d4cb261b..0ee7908777 100644
> > --- a/common/cli_getch.c
> > +++ b/common/cli_getch.c
> > @@ -46,6 +46,8 @@ static int cli_ch_esc(struct cli_ch_state *cch, int i=
char,
> > case 1:
> > if (ichar =3D=3D '[' || ichar =3D=3D 'O')
> > act =3D ESC_SAVE;
> > +   else
> > +   act =3D ESC_CONVERTED;
> > break;
> > case 2:
> > switch (ichar) {
> > --
> > 2.34.1
> >
>
> This is a bit unfortunate. Basically the problem (as I understand it)
> is that characters are built up for processing so the expected ichar
> =3D=3D 0 is never passed in.
>
> I think the fix is reasonable. Does it work as well if use:
>
>else if (ichar =3D=3D '\e')
>act =3D ESC_CONVERTED;
>
> ?
>
> Also please can you add a test case o test/common/cread.c
>
> https://u-boot.readthedocs.io/en/latest/develop/tests_sandbox.html
>
> Regards,
> Simon

> This is a bit unfortunate. Basically the problem (as I understand it)
The main problem is that extra Esc key presses are accumulated internally,
even if it is already clear that the current escape sequence is invalid.
This results in weird behaviour. For example, the next character after 'Esc=
' key
simply disappears from input and 'Unknown command' printed after 'Enter'.
Googling "u-boot 'nknown' ry help" gives plenty of such examples. This ofte=
n
happens when user stops autoboot pressing 'Esc' key.

> expected ichar =3D=3D 0 is never passed in
IIUYC, this is already checked in the calling function (cli_ch_process).

> Does it work as well if use:
It was my first fix attempt. But unfortunately it does not work, because if
the next character is not valid for the escape sequence it gets swallowed.

> Also please can you add a test case o test/common/cread.c
It will be quite easy. I've tested this in the sandbox (and with qemu) and
was not able to break something with outstanding 'Esc' key presses.

Should I resend this patch?

Best Regards,
Yurii


Re: [PATCH v3 3/3] mx28evk: Add USB Mass Storage support

2023-10-09 Thread Marek Vasut

On 10/9/23 15:15, Fabio Estevam wrote:

From: Fabio Estevam 

Select the USB options to allow running "ums 0 mmc 0".

Signed-off-by: Fabio Estevam 


Reviewed-by: Marek Vasut 

Thanks !


[PATCH v3 3/3] mx28evk: Add USB Mass Storage support

2023-10-09 Thread Fabio Estevam
From: Fabio Estevam 

Select the USB options to allow running "ums 0 mmc 0".

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- Removed further unrelated options. (Marek)
Changes since v1:
- Remove unrelated config options. (Marek)

 configs/mx28evk_defconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index df0cceaea719..4058d08f961a 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_DM=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
 CONFIG_CMD_EXT4=y
@@ -65,3 +66,11 @@ CONFIG_RTC_MXS=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MAX_CONTROLLER_COUNT=2
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
-- 
2.34.1



[PATCH v3 2/3] usb: ehci: mxs: Use regulator_set_enable_if_allowed()

2023-10-09 Thread Fabio Estevam
From: Fabio Estevam 

Since commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable() may be EALREADY or
EBUSY for fixed/GPIO regulators.

Switch to using the more relaxed regulator_set_enable_if_allowed() to
continue if regulator already was enabled or disabled.

This fixes the following error when running the 'ums' command:

=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0xece000
Error enabling VBUS supply
g_dnl_register: failed!, error: -114
g_dnl_register failed

Signed-off-by: Fabio Estevam 
Reviewed-by: Marek Vasut 
---
Changes since v2:
- None
Changes since v1:
- Only collected Marek's Reviewed-by tag.

 drivers/usb/host/ehci-mxs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 092c79fd4bc5..ddf7cc2d00a7 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -236,9 +236,9 @@ static int ehci_usb_probe(struct udevice *dev)
debug("%s: No vbus supply\n", dev->name);
 
if (!ret && priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply,
-  (type == USB_INIT_DEVICE) ?
-  false : true);
+   ret = regulator_set_enable_if_allowed(priv->vbus_supply,
+ (type == USB_INIT_DEVICE) 
?
+ false : true);
if (ret) {
puts("Error enabling VBUS supply\n");
return ret;
@@ -265,7 +265,7 @@ static int ehci_usb_remove(struct udevice *dev)
 
 #if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
-   ret = regulator_set_enable(priv->vbus_supply, false);
+   ret = regulator_set_enable_if_allowed(priv->vbus_supply, false);
if (ret) {
puts("Error disabling VBUS supply\n");
return ret;
-- 
2.34.1



[PATCH v3 1/3] usb: ehci: mxs: Fix the USB node pointer retrieval

2023-10-09 Thread Fabio Estevam
From: Fabio Estevam 

Use dev_ofnode() to retrieve the USB node pointer from the udevice
structure.

This fixes the following build error:

drivers/usb/host/ehci-mxs.c:143:38: error: 'struct udevice' has no member named 
'node_'

Signed-off-by: Fabio Estevam 
Reviewed-by: Marek Vasut 
---
Changes since v2:
- None
Changes since v1:
- Only collected Marek's Reviewed-by tag.

 drivers/usb/host/ehci-mxs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 147b2fa145d6..092c79fd4bc5 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -136,11 +136,12 @@ static int ehci_usb_ofdata_to_platdata(struct udevice 
*dev)
struct usb_plat *plat = dev_get_plat(dev);
struct ehci_mxs_port *port = >port;
u32 phandle, phy_reg, clk_reg, clk_id;
+   ofnode np = dev_ofnode(dev);
ofnode phy_node, clk_node;
const char *mode;
int ret;
 
-   mode = ofnode_read_string(dev->node_, "dr_mode");
+   mode = ofnode_read_string(np, "dr_mode");
if (mode) {
if (strcmp(mode, "peripheral") == 0)
plat->init_type = USB_INIT_DEVICE;
@@ -151,12 +152,12 @@ static int ehci_usb_ofdata_to_platdata(struct udevice 
*dev)
}
 
/* Read base address of the USB IP block */
-   ret = ofnode_read_u32(dev->node_, "reg", >usb_regs);
+   ret = ofnode_read_u32(np, "reg", >usb_regs);
if (ret)
return ret;
 
/* Read base address of the USB PHY IP block */
-   ret = ofnode_read_u32(dev->node_, "fsl,usbphy", );
+   ret = ofnode_read_u32(np, "fsl,usbphy", );
if (ret)
return ret;
 
-- 
2.34.1



Re: [RFC PATCH] mxs: Don't enable 4P2 reg if mx28 is powered only from DCDC_BATT without 5V

2023-10-09 Thread Alan Kay
Hi Lukasz,

On Mon, Oct 9, 2023 at 8:49 AM Lukasz Majewski  wrote:
>
> Hi Fabio, Alan,
>
> > Hi Alan,
> >
> > [Adding Lukasz and Cody]
> >
> > On Tue, Aug 30, 2022 at 2:49 PM Alan Kay  wrote:
> > >
> > > mxs_power_enable_4p2() was added to mxs_batt_boot() in
> > > 'commit a0f97610757d ("ARM: mxs: Enable DCDC converter for battery
> > > boot")' to enable DCDC converter when board is powered from 5V and
> > > has detected sufficient battery voltage.
> > > This involves enabling 4P2 regulator and there is a code
> > > in mxs_power_enable_4p2() that disables VDDIO, VDDA, VDDD outputs of
> > > the DCDC converter and enables BO for each power rail e.g.
> > >
> > > setbits_le32(_regs->hw_power_vddioctrl,
> > > POWER_VDDIOCTRL_DISABLE_FET |
> > > POWER_VDDIOCTRL_PWDN_BRNOUT);
> > >
> > > In case the mx28 is powered by the 5V source and linear regulators
> > > are supplying power to the VDDIO, VDDA, VDDD rails there is no
> > > issue.
> > >
> > > However if the mx28 is powered by the DCDC_BATT source only without
> > > 5V, disabling the DCDC converter outputs causes brownout power down.
> > >
> > > The proposed solution is not to call mxs_power_enable_4p2() at all
> > > if the mx28 is powered by the DCDC_BATT source only. There is no
> > > reason to enable 4P2 regulator in this case and setup of all
> > > registers is done in mxs_batt_boot().
> > >
> > > Also there is no need to enable 5V brownout in
> > > mxs_power_init() in this case.
> > >
> > > Please consider if this is acceptable and I will submit a proper
> > > patch.
> > >
> > > Signed-off-by: Alan Kay 
> >
> > Cody also sent a fix for this issue:
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20230703163340.101490-2-c...@londelec.com/
>
> Isn't this already addressed with:
> https://source.denx.de/u-boot/u-boot/-/commit/79230640cb4fb780e2be9bb9a47b31976b18cac4
>
> Please also look into the recent patches for imx287 (xea board for
> reference):
>
> tig -- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
>
> At least SHA1: 65b9b3462bec2966911658836983819ab4e4823e
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,  Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de

The patch:
https://source.denx.de/u-boot/u-boot/-/commit/79230640cb4fb780e2be9bb9a47b31976b18cac4
does fix the issue, please feel free to discard my patch, thank you.

Best regards,
Alan Kay


[PATCH RESEND v3 1/1] arm: dts: icnova-a20-adb4006: Add board support

2023-10-09 Thread Ludwig Kormann
Add board support for ICnova A20 SomPi compute module on
ICnova ADB4006 development board.

Specification:
SoM
- Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
- 512MB DDR3 RAM
- Fast Ethernet (Phy: Realtek RTL8201CP)
ADB4006
- I2C
- 2x USB 2.0
- 1x Fast Ethernet port
- 1x SATA
- 2x buttons (PWRON, Boot)
- 2x LEDS
- serial console
- HDMI
- µSD-Card slot
- Audio Line-In / Line-Out
- GPIO pinheaders

https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM

devicetree upstreamed with linux 6.5

Signed-off-by: Ludwig Kormann 
---
changes in v3:
- rebase on v2023.10

changes in v2:
- rebase on v2023.07-rc2
- remove pin defines from defconfig
- get dts reviewed on the linux mailing list and
  scheduled for kernel 6.5 [1]

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
commit de2bdfb7f79d5c655eb056d459e02be2c7f13c8b

---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++
 arch/arm/dts/sun7i-a20-icnova-a20.dtsi|  62 
 board/sunxi/MAINTAINERS   |   5 +
 configs/icnova-a20-adb4006_defconfig  |  20 +++
 5 files changed, 225 insertions(+)
 create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts
 create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20.dtsi
 create mode 100644 configs/icnova-a20-adb4006_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157..16d5930b78 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -667,6 +667,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-haoyu-marsboard.dtb \
sun7i-a20-hummingbird.dtb \
sun7i-a20-i12-tvbox.dtb \
+   sun7i-a20-icnova-a20-adb4006.dtb \
sun7i-a20-icnova-swac.dtb \
sun7i-a20-itead-ibox.dtb \
sun7i-a20-lamobo-r1.dtb \
diff --git a/arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts 
b/arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts
new file mode 100644
index 00..577ead1d02
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit GmbH
+
+/dts-v1/;
+
+#include "sun7i-a20-icnova-a20.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "In-Circuit ICnova A20 ADB4006";
+   compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
+"allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
+   default-state = "on";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_HEARTBEAT;
+   color = ;
+   gpios = < 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
+   linux,default-trigger = "heartbeat";
+   };
+   };
+};
+
+ {
+   target-supply = <_ahci_5v>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_sram {
+   status = "okay";
+};
+
+_ahci_5v {
+   status = "okay";
+};
+
+_power_supply {
+   status = "okay";
+};
+
+_usb1_vbus {
+   status = "okay";
+};
+
+_usb2_vbus {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pb_pins>;
+   status = "okay";
+};
+
+_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
+ {
+   usb0_id_det-gpios = < 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+   usb0_vbus_det-gpios = < 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+   usb1_vbus-supply = <_usb1_vbus>;
+   usb2_vbus-supply = <_usb2_vbus>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/sun7i-a20-icnova-a20.dtsi 
b/arch/arm/dts/sun7i-a20-icnova-a20.dtsi
new file mode 100644
index 00..46616c6bc8
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-icnova-a20.dtsi
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit 

[PATCH v2] doc: Migrate Renesas board docs to rst

2023-10-09 Thread Paul Barker
Some of the information in README.rmobile is obsolete, references
defconfigs which no longer exist in u-boot or has broken links. The
information which is still relevant is moved into the reStructuredText
documentation under `doc/board/renesas`, and `doc/README.rmobile` is
dropped.

The list of boards in `doc/board/renesas` is converted into a table so
it's easier to see which defconfig to use. The list is expanded based on
reviewing the current u-boot code and the contents of the eLinux wiki
[1] [2].

[1]: https://elinux.org/R-Car
[2]: https://elinux.org/RZ-G

Signed-off-by: Paul Barker 
---
v1->v2:
  * Fixed minor issues pointed out by Marek.

 doc/README.rmobile|  99 -
 doc/board/renesas/renesas.rst | 255 +-
 doc/board/renesas/rzn1.rst|   2 +
 3 files changed, 226 insertions(+), 130 deletions(-)
 delete mode 100644 doc/README.rmobile

diff --git a/doc/README.rmobile b/doc/README.rmobile
deleted file mode 100644
index 524d839558bb..
--- a/doc/README.rmobile
+++ /dev/null
@@ -1,99 +0,0 @@
-Summary
-===
-
-This README is about U-Boot support for Renesas's ARM Cortex-A9 based 
RMOBILE[1]
-and Cortex-A9/A53/A57 based R-Car[2] family of SoCs. Renesas's RMOBILE/R-Car 
SoC
-family contains an ARM Cortex-A9/A53/A57.
-
-Currently the following boards are supported:
-
-| SoC   | Board  | defconfig
-|===++===
-| R8A73A0   | KMC KZM-A9-GT [3]  | kzm9g_config
-| R8A7734   | Atmark-Techno Armadillo-800-EVA [4]| 
armadillo-800eva_config
-|===++===
-| R8A7790  H2   | Renesas Electronics Lager  | lager_defconfig
-|   | Renesas Electronics Stout  | stout_defconfig
-|---++---
-| R8A7791  M2-W | Renesas Electronics Koelsch| koelsch_defconfig
-|   | Renesas Electronics Porter | porter_defconfig
-|---++---
-| R8A7792  V2H  | Renesas Electronics Blanche| blanche_defconfig
-|---++---
-| R8A7793  M2-N | Renesas Electronics Gose   | gose_defconfig
-|---++---
-| R8A7794  E2   | Renesas Electronics Alt| alt_defconfig
-|   | Renesas Electronics Silk   | silk_defconfig
-|===++===
-| R8A7795  H3   | Renesas Electronics Salvator-XS ES2.0+ | 
r8a7795_salvator-x_defconfig
-| R8A7795  H3   | Renesas Electronics ULCB ES2.0+| r8a7795_ulcb
-|---++---
-| R8A7796  M3-W | Renesas Electronics Salvator-X | 
r8a7796_salvator-x_defconfig
-| R8A7796  M3-W | Renesas Electronics ULCB   | r8a7796_ulcb
-|---++---
-| R8A77965 M3-N | Renesas Electronics Salvator-XS| 
r8a77965_salvator-x_defconfig
-| R8A77965 M3-N | Renesas Electronics ULCB   | r8a77965_ulcb
-|---++---
-| R8A77970 V3M  | Renesas Electronics Eagle  | 
r8a77970_eagle_defconfig
-| R8A77970 V3M  | Renesas Electronics V3MSK  | 
r8a77970_v3msk_defconfig
-|---++---
-| R8A77995 D3   | Renesas Electronics Draak  | 
r8a77995_draak_defconfig
-'===++===
-
-Toolchain
-=
-
-Either ARMv7 toolchain for 32bit Cortex-A9 systems or ARMv8 (aarch64)
-toolchain for 64bit Cortex-A53/A57 systems. Currently we compile the
-32bit systems with -march=armv5 to allow more compilers to work. (For
-U-Boot code this has no performance impact.)
-
-Currently, ELDK[5], Linaro[6], CodeSourcery[7] and Emdebian[8] supports
-ARMv7. Modern distributions also contain ARMv7 and ARMv8 crosstoolchains
-in their package feeds.
-
-Build
-=
-
-Locate defconfig in the table above. Then apply standard build procedure:
-
-  make _defconfig
-  make
-
-  Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only.
-Please see "B.2 Appendix B Boot Specifications" in hardware manual.
-
-Links
-=
-
-[1] Renesas RMOBILE:
-
-http://am.renesas.com/products/soc/assp/mobile/r_mobile/index.jsp
-
-[2] Renesas R-Car:
-
-http://am.renesas.com/products/soc/assp/automotive/index.jsp
-
-[3] KZM-A9-GT
-
-http://www.kmckk.co.jp/kzma9-gt/index.html
-
-[4] Armadillo-800-EVA
-
-http://armadillo.atmark-techno.com/armadillo-800-EVA
-
-[5] ELDK
-

Re: [PATCH] test/py: net: Add a TFTP put test

2023-10-09 Thread Michal Simek




On 10/3/23 11:02, Love Kumar wrote:

Execute tftpput command for uploading files to a server and validate its
size & CRC32.

Signed-off-by: Love Kumar 
---
  test/py/tests/test_net.py | 69 +++
  1 file changed, 69 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index cd4b4dc53cbc..f69e3ea2dbba 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -6,6 +6,7 @@
  
  import pytest

  import u_boot_utils
+import datetime
  
  """

  Note: This test relies on boardenv_* containing configuration values to define
@@ -50,6 +51,7 @@ env__net_tftp_readable_file = {
  'addr': 0x1000,
  'size': 5058624,
  'crc32': 'c2244b26',
+'timeout': 5,
  }
  
  # Details regarding a file that may be read from a NFS server. This variable

@@ -260,3 +262,70 @@ def test_net_nfs(u_boot_console):
  
  output = u_boot_console.run_command('crc32 %x $filesize' % addr)

  assert expected_crc in output
+
+@pytest.mark.buildconfigspec("cmd_crc32")
+@pytest.mark.buildconfigspec("cmd_net")


Here should be CMD_TFTPPUT marking.



+def test_net_tftpput(u_boot_console):
+"""Test the tftpput command.
+A file is downloaded from the TFTP server and then uploaded to the TFTP
+server, its size and its CRC32 are validated.
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip("Network not initialized")
+
+f = u_boot_console.config.env.get("env__net_tftp_readable_file", None)
+if not f:
+pytest.skip("No TFTP readable file to read")
+
+addr = f.get("addr", None)
+if not addr:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+sz = f.get("size", None)
+timeout = f.get("timeout", u_boot_console.p.timeout)
+fn = f["fn"]
+fnu = "_".join([datetime.datetime.now().strftime("%y%m%d%H%M%S"), fn])
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("tftpboot %x %s" % (addr, fn))
+
+assert "TIMEOUT" not in output
+assert expected_text in output
+
+expected_tftpb_crc = f.get("crc32", None)
+
+output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+assert expected_tftpb_crc in output
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command(
+"tftpput $fileaddr $filesize $serverip:%s" % (fnu)
+)
+
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+addr = addr + sz
+assert "TIMEOUT" not in output
+assert "Access violation" not in output
+assert expected_text in output
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("tftpboot %x %s" % (addr, fnu))
+
+expected_text = "Bytes transferred = "
+if sz:
+expected_text += "%d" % sz
+assert "TIMEOUT" not in output
+assert expected_text in output
+
+expected_tftpp_crc = expected_tftpb_crc
+
+output = u_boot_console.run_command("crc32 $fileaddr $filesize")
+assert expected_tftpp_crc in output


I pushed this to CI to see if that goes through and  I see couple of failures 
like this.


test/py/tests/test_net.py:409: in test_net_tftpput
assert expected_text in output
E   assert 'Bytes transferred = 5181868' in "smc911x: detected LAN9118 
controller\r\r\nsmc911x: phy initialized\r\r\nsmc911x: MAC 
52:54:00:12:34:56\r\r\n*** ERROR: `serverip' not set\r\r\nsmc911x: MAC 
52:54:00:12:34:56"


___ test_net_tftpput ___
test/py/tests/test_net.py:417: in test_net_tftpput
output = u_boot_console.run_command(
test/py/u_boot_console_base.py:269: in run_command
raise Exception('Bad pattern found on console: ' +
E   Exception: Bad pattern found on console: unknown_command

test/py/tests/test_net.py:409: in test_net_tftpput
assert expected_text in output
E   assert 'Bytes transferred = 6096080' in "*** ERROR: `serverip' not set"


M


Re: [PATCH] net: phy: xilinx_phy: Get rid of using property xlnx,phy-type

2023-10-09 Thread Michal Simek




On 10/9/23 12:15, Michal Simek wrote:



On 10/5/23 05:02, Venkatesh Yadav Abbarapu wrote:

As the xlnx,phy-type device tree property is deprecated and phy-mode
is being used, so removing the code references of xlnx,phy-type.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/net/phy/xilinx_phy.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/net/phy/xilinx_phy.c b/drivers/net/phy/xilinx_phy.c
index 1df639d6f4..50f1611ad5 100644
--- a/drivers/net/phy/xilinx_phy.c
+++ b/drivers/net/phy/xilinx_phy.c
@@ -107,10 +107,6 @@ static int xilinxphy_of_init(struct phy_device *phydev)
  if (!ofnode_valid(node))
  return -EINVAL;
-    phytype = ofnode_read_u32_default(node, "xlnx,phy-type", -1);
-    if (phytype == XAE_PHY_TYPE_1000BASE_X)
-    phydev->flags |= XAE_PHY_TYPE_1000BASE_X;
-
  return 0;
  }


Applied.
M


Actually no. I will remove this patch from my queue. You also need to remove 
phytype variable.

That's why please send v2 on this.

M


Re: [PATCH v4] arm64: versal: Add SelectMAP boot mode identification

2023-10-09 Thread Michal Simek




On 10/8/23 16:34, Polak, Leszek wrote:

The SelectMAP configuration interface provides an 8-bit,
16-bit or 32-bit bidirectional data bus interface to the Versal FPGA
configuration logic that can be used for both configuration and readback.

A connected microcontoller to the SelectMAP interface can load boot
image with bitstream, TF-A (ARM Trusted Firmware) and U-Boot.

This commit adds the missing identification of the SelectMAP mode.

Signed-off-by: Polak, Leszek 
Reviewed-by: Stefan Roese 
Cc: Michal Simek 
Cc: Stefan Roese 
---
v2:
- Drop assignment of 'mode' as selectmap is not be supported
   by distro boot
v3:
- Changed E-Mail/Name to be the same as git setup
v4:
- Fixed formatting
---
  arch/arm/mach-versal-net/include/mach/hardware.h | 1 +
  arch/arm/mach-versal/include/mach/hardware.h | 1 +
  board/xilinx/versal-net/board.c  | 3 +++
  board/xilinx/versal/board.c  | 4 
  4 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h 
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 9bddb8b007..767cdd3686 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -66,6 +66,7 @@ struct crp_regs {
  #define EMMC_MODE 0x0006
  #define USB_MODE  0x0007
  #define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
  #define SD1_LSHFT_MODE0x000E /* SD1 Level shifter */
  #define JTAG_MODE 0x
  #define BOOT_MODE_USE_ALT 0x100
diff --git a/arch/arm/mach-versal/include/mach/hardware.h 
b/arch/arm/mach-versal/include/mach/hardware.h
index 000af974e8..9d1c2f0dcf 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -82,6 +82,7 @@ struct crp_regs {
  #define EMMC_MODE 0x0006
  #define USB_MODE  0x0007
  #define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
  #define SD1_LSHFT_MODE0x000E /* SD1 Level shifter */
  #define JTAG_MODE 0x
  #define BOOT_MODE_USE_ALT 0x100
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index c18be0c26c..990ca1650a 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -252,6 +252,9 @@ static int boot_targets_setup(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+   case SELECTMAP_MODE:
+   puts("SELECTMAP_MODE\n");
+   break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index e4bdd5d7a3..8c2e614ad8 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -174,6 +174,9 @@ static int boot_targets_setup(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+   case SELECTMAP_MODE:
+   puts("SELECTMAP_MODE\n");
+   break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
@@ -312,6 +315,7 @@ enum env_location env_get_location(enum env_operation op, 
int prio)
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
case JTAG_MODE:
+   case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}


Applied.
M


Re: [PATCH] net: phy: xilinx_phy: Get rid of using property xlnx,phy-type

2023-10-09 Thread Michal Simek




On 10/5/23 05:02, Venkatesh Yadav Abbarapu wrote:

As the xlnx,phy-type device tree property is deprecated and phy-mode
is being used, so removing the code references of xlnx,phy-type.

Signed-off-by: Venkatesh Yadav Abbarapu 
---
  drivers/net/phy/xilinx_phy.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/net/phy/xilinx_phy.c b/drivers/net/phy/xilinx_phy.c
index 1df639d6f4..50f1611ad5 100644
--- a/drivers/net/phy/xilinx_phy.c
+++ b/drivers/net/phy/xilinx_phy.c
@@ -107,10 +107,6 @@ static int xilinxphy_of_init(struct phy_device *phydev)
if (!ofnode_valid(node))
return -EINVAL;
  
-	phytype = ofnode_read_u32_default(node, "xlnx,phy-type", -1);

-   if (phytype == XAE_PHY_TYPE_1000BASE_X)
-   phydev->flags |= XAE_PHY_TYPE_1000BASE_X;
-
return 0;
  }
  


Applied.
M


Re: [PATCH] arm64: xilinx: Do not use '_' in si5335 DT node names

2023-10-09 Thread Michal Simek




On 9/27/23 12:05, Michal Simek wrote:

Character '_' not recommended in node name. Use '-' instead.
Pretty much run sed below for node names.
s/si5335_/si5335-/

Signed-off-by: Michal Simek 
---

Till now I didn't heard back that different style should be used that's why
also sending this patch and separately from other similar change recently
sent.
---
  arch/arm/dts/zynqmp-zcu100-revC.dts | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts 
b/arch/arm/dts/zynqmp-zcu100-revC.dts
index a84cd86694e2..44d1b24677d1 100644
--- a/arch/arm/dts/zynqmp-zcu100-revC.dts
+++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
@@ -2,7 +2,8 @@
  /*
   * dts file for Xilinx ZynqMP ZCU100 revC
   *
- * (C) Copyright 2016 - 2021, Xilinx, Inc.
+ * (C) Copyright 2016 - 2022, Xilinx, Inc.
+ * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc.
   *
   * Michal Simek 
   * Nathalie Chan King Choy
@@ -131,13 +132,13 @@
io-channels = < 0>, < 1>, < 2>, < 3>;
};
  
-	si5335_0: si5335_0 { /* clk0_usb - u23 */

+   si5335_0: si5335-0 { /* clk0_usb - u23 */
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2600>;
};
  
-	si5335_1: si5335_1 { /* clk1_dp - u23 */

+   si5335_1: si5335-1 { /* clk1_dp - u23 */
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2700>;



Applied.
M


Re: [PATCH] Revert "clk: versal: Enable clock driver for Versal NET"

2023-10-09 Thread Michal Simek




On 9/27/23 12:02, Michal Simek wrote:

This partially reverts commit ff33227819f579ffb963e0dac6bc6a6566b89563.

Versal NET clock node should use "xlnx,versal-net-clk", "xlnx,versal-clk"
compatible string that's why it is not necessary to define Versal NET
specific compatible string if there is no any other change needed. It can
be get back if there is a need to differentiate clock support between
Versal and Versal NET.

Signed-off-by: Michal Simek 
---

  drivers/clk/clk_versal.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/clk/clk_versal.c b/drivers/clk/clk_versal.c
index 2e004beca2f9..c473643603a4 100644
--- a/drivers/clk/clk_versal.c
+++ b/drivers/clk/clk_versal.c
@@ -773,7 +773,6 @@ static struct clk_ops versal_clk_ops = {
  
  static const struct udevice_id versal_clk_ids[] = {

{ .compatible = "xlnx,versal-clk" },
-   { .compatible = "xlnx,versal-net-clk" },
{ }
  };
  


Applied.
M


Re: [PATCH] arm64: zynqmp: Do not use '_' in DT node names

2023-10-09 Thread Michal Simek




On 9/27/23 11:57, Michal Simek wrote:

Using '_' is not recommended for node names. Use '-' instead.
Pretty much run seds below for node names.
s/heartbeat_led/heartbeat-led/
s/gtr_sel/gtr-sel/
s/zynqmp_ipi/zynqmp-ipi/
s/nvmem_firmware/nvmem-firmware/
s/soc_revision/soc-revision/

Signed-off-by: Michal Simek 
---

  arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 8 
  arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 8 
  arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 8 
  arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 8 
  arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +-
  arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +-
  arch/arm/dts/zynqmp.dtsi| 6 +++---
  7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index cfd5ba1aac63..25ef646c8466 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -363,25 +363,25 @@
#gpio-cells = <2>;
gpio-line-names = "sw4_1", "sw4_2", "sw4_3", 
"sw4_4",
  "", "", "", "";
-   gtr_sel0 {
+   gtr-sel0 {
gpio-hog;
gpios = <0 0>;
input; /* FIXME add meaning */
line-name = "sw4_1";
};
-   gtr_sel1 {
+   gtr-sel1 {
gpio-hog;
gpios = <1 0>;
input; /* FIXME add meaning */
line-name = "sw4_2";
};
-   gtr_sel2 {
+   gtr-sel2 {
gpio-hog;
gpios = <2 0>;
input; /* FIXME add meaning */
line-name = "sw4_3";
};
-   gtr_sel3 {
+   gtr-sel3 {
gpio-hog;
gpios = <3 0>;
input; /* FIXME add meaning */
diff --git a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
index 18e14389f85f..ece9e6914541 100644
--- a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
@@ -365,25 +365,25 @@
#gpio-cells = <2>;
gpio-line-names = "sw4_1", "sw4_2", "sw4_3", 
"sw4_4",
  "", "", "", "";
-   gtr_sel0 {
+   gtr-sel0 {
gpio-hog;
gpios = <0 0>;
input; /* FIXME add meaning */
line-name = "sw4_1";
};
-   gtr_sel1 {
+   gtr-sel1 {
gpio-hog;
gpios = <1 0>;
input; /* FIXME add meaning */
line-name = "sw4_2";
};
-   gtr_sel2 {
+   gtr-sel2 {
gpio-hog;
gpios = <2 0>;
input; /* FIXME add meaning */
line-name = "sw4_3";
};
-   gtr_sel3 {
+   gtr-sel3 {
gpio-hog;
gpios = <3 0>;
input; /* FIXME add meaning */
diff --git a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
index cd7654a9f7ed..7372968e5734 100644
--- a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
@@ -359,25 +359,25 @@
#gpio-cells = <2>;
gpio-line-names = "sw4_1", "sw4_2", "sw4_3", 
"sw4_4",
  "", "", "", "";
-   gtr_sel0 {
+   gtr-sel0 {
gpio-hog;
gpios = <0 0>;
 

Re: [PATCH] arm: dts: xilinx: Remove undocumented is-dual property

2023-10-09 Thread Michal Simek




On 9/27/23 11:56, Michal Simek wrote:

Xilinx was using in past is-dual property for QSPIs to reflect their
configurations. But handling for them never reached upstream code that's
why better to remove them.

Signed-off-by: Michal Simek 
---

  arch/arm/dts/zynq-cc108.dts   | 1 -
  arch/arm/dts/zynq-dlc20-rev1.0.dts| 1 -
  arch/arm/dts/zynq-minized.dts | 1 -
  arch/arm/dts/zynq-topic-miami.dts | 1 -
  arch/arm/dts/zynq-topic-miamilite.dts | 1 -
  arch/arm/dts/zynq-topic-miamiplus.dts | 1 -
  arch/arm/dts/zynqmp-m-a2197-01-revA.dts   | 1 -
  arch/arm/dts/zynqmp-m-a2197-02-revA.dts   | 1 -
  arch/arm/dts/zynqmp-m-a2197-03-revA.dts   | 1 -
  arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts | 2 --
  arch/arm/dts/zynqmp-zcu102-revA.dts   | 1 -
  arch/arm/dts/zynqmp-zcu106-revA.dts   | 1 -
  arch/arm/dts/zynqmp-zcu111-revA.dts   | 1 -
  arch/arm/dts/zynqmp-zcu208-revA.dts   | 1 -
  arch/arm/dts/zynqmp-zcu216-revA.dts   | 1 -
  15 files changed, 16 deletions(-)

diff --git a/arch/arm/dts/zynq-cc108.dts b/arch/arm/dts/zynq-cc108.dts
index dc942b0f595e..593ca4a49cf5 100644
--- a/arch/arm/dts/zynq-cc108.dts
+++ b/arch/arm/dts/zynq-cc108.dts
@@ -55,7 +55,6 @@
  
   {

status = "okay";
-   is-dual = <0>;
num-cs = <1>;
flash@0 { /* 16 MB */
compatible = "n25q128a11", "jedec,spi-nor";
diff --git a/arch/arm/dts/zynq-dlc20-rev1.0.dts 
b/arch/arm/dts/zynq-dlc20-rev1.0.dts
index d06838c5eeb3..8d0073780336 100644
--- a/arch/arm/dts/zynq-dlc20-rev1.0.dts
+++ b/arch/arm/dts/zynq-dlc20-rev1.0.dts
@@ -66,7 +66,6 @@
   {
bootph-all;
status = "okay";
-   is-dual = <0>;
num-cs = <1>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
index 3214ee49e283..96d2937de8bf 100644
--- a/arch/arm/dts/zynq-minized.dts
+++ b/arch/arm/dts/zynq-minized.dts
@@ -39,7 +39,6 @@
  
   {

status = "okay";
-   is-dual = <0>;
num-cs = <1>;
flash@0 {
compatible = "micron,m25p128";
diff --git a/arch/arm/dts/zynq-topic-miami.dts 
b/arch/arm/dts/zynq-topic-miami.dts
index 57cb86aafd29..8307a2ef9dd3 100644
--- a/arch/arm/dts/zynq-topic-miami.dts
+++ b/arch/arm/dts/zynq-topic-miami.dts
@@ -33,7 +33,6 @@
   {
bootph-all;
status = "okay";
-   is-dual = <0>;
num-cs = <1>;
flash@0 {
compatible = "st,m25p80", "n25q256a", "jedec,spi-nor";
diff --git a/arch/arm/dts/zynq-topic-miamilite.dts 
b/arch/arm/dts/zynq-topic-miamilite.dts
index 366fd5bbb100..af0bc7ecf700 100644
--- a/arch/arm/dts/zynq-topic-miamilite.dts
+++ b/arch/arm/dts/zynq-topic-miamilite.dts
@@ -12,5 +12,4 @@
  };
  
   {

-   is-dual = <1>;
  };
diff --git a/arch/arm/dts/zynq-topic-miamiplus.dts 
b/arch/arm/dts/zynq-topic-miamiplus.dts
index df538865296d..36a7db355e5b 100644
--- a/arch/arm/dts/zynq-topic-miamiplus.dts
+++ b/arch/arm/dts/zynq-topic-miamiplus.dts
@@ -21,5 +21,4 @@
  };
  
   {

-   is-dual = <1>;
  };
diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index 2c3e30ba8916..cfd5ba1aac63 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -71,7 +71,6 @@
  
   {

status = "okay";
-   is-dual = <1>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
index ad724a135872..18e14389f85f 100644
--- a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
@@ -67,7 +67,6 @@
  
   {

status = "okay";
-   is-dual = <1>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
index 296af0426ee2..cd7654a9f7ed 100644
--- a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
@@ -67,7 +67,6 @@
  
   {

status = "okay";
-   is-dual = <1>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts 
b/arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts
index 3750bb38b585..0d96c6f9f041 100644
--- a/arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts
+++ b/arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts
@@ -56,7 +56,6 @@
  
   {

status = "okay";
-   is-dual = <1>;
flash@0 {
compatible = "st,m25p80", "n25q256a", 

Re: [PATCH 00/11] xilinx: add missing boards/SC descriptions

2023-10-09 Thread Michal Simek




On 9/27/23 11:53, Michal Simek wrote:

Hi,

I am sending series of zynqmp boards mostly related to system controller.
System controller is small ZynqMP board sitting on Versal/Versal NET board
doing board management. There is a internal spec about connection outside
but pretty much DT description describe all connected IPs.
The only thing what it is not covered in generic SC are i2c buses because
they contain different devices. That's why they are described by DT
overlays.
The first version was created for vpk120-revA, next was generic SC revB and
because of supply chain issue ethernet phy was replaced which ends up in
revC version.

The series also contain some cleanups and also adding new platforms like
KD240.

Thanks,
Michal


Michal Simek (11):
   arm64: zynqmp: Add support for KD240 Kria SOM CC
   arm64: zynqmp: Remove xlnx,fclk nodes
   arm64: zynqmp: Add support for vck190 revB system controller
   arm64: zynqmp: Add x-prc-01/02/03/04/05 revA support from SC
   arm64: zynqmp: Add support for vpk120-revA
   arm64: zynqmp: Create description for generic SC (vpk120-revB)
   arm64: zynqmp: Add support for SC revC
   arm64: zynqmp: Describe i2c structures for SCs
   arm64: zynqmp: Add support for VPXA2785
   arm64: zynqmp: Add support for zcu670-revA
   arm64: zynqmp: Add support for zcu670-revB

  arch/arm/dts/Makefile |  20 +
  arch/arm/dts/zynqmp-clk-ccf.dtsi  |  18 -
  arch/arm/dts/zynqmp-e-a2197-00-revB.dts   |  34 +
  .../zynqmp-p-a2197-00-revA-x-prc-01-revA.dtso |  76 ++
  .../zynqmp-p-a2197-00-revA-x-prc-02-revA.dtso |  76 ++
  .../zynqmp-p-a2197-00-revA-x-prc-03-revA.dtso |  80 +++
  .../zynqmp-p-a2197-00-revA-x-prc-04-revA.dtso |  86 +++
  .../zynqmp-p-a2197-00-revA-x-prc-05-revA.dtso |  86 +++
  arch/arm/dts/zynqmp-sc-revB.dts   | 430 +++
  arch/arm/dts/zynqmp-sc-revC.dts   |  37 +
  arch/arm/dts/zynqmp-sc-vek280-revA.dtso   | 230 ++
  arch/arm/dts/zynqmp-sc-vek280-revB.dtso   |  15 +
  arch/arm/dts/zynqmp-sc-vhk158-revA.dtso   | 321 +
  .../arm/dts/zynqmp-sc-vn-p-b2197-00-revA.dtso | 460 
  arch/arm/dts/zynqmp-sc-vpk120-revB.dtso   | 326 +
  arch/arm/dts/zynqmp-sc-vpk180-revA.dtso   | 371 ++
  arch/arm/dts/zynqmp-sc-vpk180-revB.dtso   | 337 +
  arch/arm/dts/zynqmp-sck-kd-g-revA.dtso| 353 +
  arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts| 438 
  arch/arm/dts/zynqmp-vpk120-revA.dts   | 574 +++
  arch/arm/dts/zynqmp-zcu670-revA.dts   | 669 +
  arch/arm/dts/zynqmp-zcu670-revB.dts   | 672 ++
  configs/xilinx_zynqmp_virt_defconfig  |   2 +-
  23 files changed, 5692 insertions(+), 19 deletions(-)
  create mode 100644 arch/arm/dts/zynqmp-e-a2197-00-revB.dts
  create mode 100644 arch/arm/dts/zynqmp-p-a2197-00-revA-x-prc-01-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-p-a2197-00-revA-x-prc-02-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-p-a2197-00-revA-x-prc-03-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-p-a2197-00-revA-x-prc-04-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-p-a2197-00-revA-x-prc-05-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-revB.dts
  create mode 100644 arch/arm/dts/zynqmp-sc-revC.dts
  create mode 100644 arch/arm/dts/zynqmp-sc-vek280-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vek280-revB.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vhk158-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vn-p-b2197-00-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vpk120-revB.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vpk180-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-sc-vpk180-revB.dtso
  create mode 100644 arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
  create mode 100644 arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts
  create mode 100644 arch/arm/dts/zynqmp-vpk120-revA.dts
  create mode 100644 arch/arm/dts/zynqmp-zcu670-revA.dts
  create mode 100644 arch/arm/dts/zynqmp-zcu670-revB.dts



Applied.
M


Re: [PATCH v2] riscv: enable multi-range memory layout

2023-10-09 Thread Wu, Fei
On 9/14/2023 2:05 PM, Heinrich Schuchardt wrote:
> 
> 
> Am 14. September 2023 07:30:55 MESZ schrieb Fei Wu :
>> In order to enable PCIe passthrough on qemu riscv, the physical memory
>> range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram,
>> two ranges are created as [2G, 3G) and [4G, 7G), currently u-boot sets
>> ram_top to 4G - 1 if the gd->ram_top is above 4G in
> 
> This should move to 7GiB - 1 in your example on riscv64.
> 
>> board_get_usable_ram_top(), but that address is not backed by ram. This
>> patch selects the lowest range instead.
>>
>> Signed-off-by: Fei Wu 
>> ---
>> arch/riscv/cpu/generic/dram.c| 2 +-
>> configs/qemu-riscv64_defconfig   | 2 +-
>> configs/qemu-riscv64_smode_defconfig | 2 +-
>> configs/qemu-riscv64_spl_defconfig   | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c
>> index 44e11bd56c..fb53a57b4e 100644
>> --- a/arch/riscv/cpu/generic/dram.c
>> +++ b/arch/riscv/cpu/generic/dram.c
>> @@ -13,7 +13,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> int dram_init(void)
>> {
>> -return fdtdec_setup_mem_size_base();
>> +return fdtdec_setup_mem_size_base_lowest();
> 
> Linaro is working on allowing to download a distro image via https and 
> installing from a RAM disk.
> 
It's okay if we don't do this installation and pcie passthrough together
on risc-v, nothing is changed if there is single-range memory, 1GB is
large enough for other cases.

> We should not artificially reduce the RAM size available for U-Boot by 
> restricting ourselfs to 1 GiB.
> 
> We must ensure that ram top is in the upper range.
> 
You mentioned a generic solution for all architectures in another
thread, it looks not trivial for me with little background on u-boot,
e.g. something is confusing to me, when a board should define
CFG_SYS_SDRAM_BASE, what happens if gd->ram_base != CFG_SYS_SDRAM_BASE,
I'm not sure if you or anyone can help drive this together. btw, the
good part of this patch is that it doesn't change the semantics of
ram_base, and the best choice is the largest range, the upper range
might not.

Thanks,
Fei.

> Best regards
> 
> Heinrich
> 
>> }
>>
>> int dram_init_banksize(void)
>> diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
>> index 9a8bbef192..aa55317d26 100644
>> --- a/configs/qemu-riscv64_defconfig
>> +++ b/configs/qemu-riscv64_defconfig
>> @@ -1,6 +1,6 @@
>> CONFIG_RISCV=y
>> CONFIG_SYS_MALLOC_LEN=0x80
>> -CONFIG_NR_DRAM_BANKS=1
>> +CONFIG_NR_DRAM_BANKS=2
>> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
>> CONFIG_ENV_SIZE=0x2
>> diff --git a/configs/qemu-riscv64_smode_defconfig 
>> b/configs/qemu-riscv64_smode_defconfig
>> index 1d0f021ade..de08a49dab 100644
>> --- a/configs/qemu-riscv64_smode_defconfig
>> +++ b/configs/qemu-riscv64_smode_defconfig
>> @@ -1,6 +1,6 @@
>> CONFIG_RISCV=y
>> CONFIG_SYS_MALLOC_LEN=0x80
>> -CONFIG_NR_DRAM_BANKS=1
>> +CONFIG_NR_DRAM_BANKS=2
>> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
>> CONFIG_ENV_SIZE=0x2
>> diff --git a/configs/qemu-riscv64_spl_defconfig 
>> b/configs/qemu-riscv64_spl_defconfig
>> index bb10145e6e..66dc2a1dd9 100644
>> --- a/configs/qemu-riscv64_spl_defconfig
>> +++ b/configs/qemu-riscv64_spl_defconfig
>> @@ -1,6 +1,6 @@
>> CONFIG_RISCV=y
>> CONFIG_SYS_MALLOC_LEN=0x80
>> -CONFIG_NR_DRAM_BANKS=1
>> +CONFIG_NR_DRAM_BANKS=2
>> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
>> CONFIG_ENV_SIZE=0x2



Re: [PATCH v1 1/2] mtd: spinand: rework detect procedure for different READ_ID operation

2023-10-09 Thread Frieder Schrempf
On 04.10.23 17:07, Igor Prusov wrote:
> Adaptation of Linux commit f1541773af49.
> 
> Currently there are 3 different variants of read_id implementation:
> 1. opcode only. Found in GD5FxGQ4xF.
> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> 3. opcode + 1 dummy byte. Found in other currently supported chips.
> 
> Original implementation was for variant 1 and let detect function
> of chips with variant 2 and 3 to ignore the first byte. This isn't
> robust:
> 
> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> during read, chip will get a random id offset, and the entire id
> buffer will shift by that offset, causing detect failure.
> 
> 2. For chips of variant 1, if it happens to get a devid that equals
> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> detected.
> 
> This patch reworks detect procedure to address problems above. New
> logic do detection for all variants separatedly, in 1-2-3 order.
> Since all current detect methods do exactly the same id matching
> procedure, unify them into core.c and remove detect method from
> manufacture_ops.
> 
> Signed-off-by: Chuanhong Guo 
> Signed-off-by: Igor Prusov 

An adaptation of this patch was already sent long ago [1] and Dario also
picked it up in nand-next [2]. Though it looks like this was never
merged upstream as there wasn't any pull request sent to Tom, right?

Dario, as you already seem to have rebased nand-next recently, can you
please sent the changes to Tom for picking them up? As the merge window
is open at the moment it would be good to get it done soon. Thanks!

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230110115843.391630-1-frie...@fris.de/
[2]
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/commits/nand-next/


Re: [PATCH 5/5] binman: capsule: Add support for generating EFI empty capsules

2023-10-09 Thread Sughosh Ganu
hi Simon,

On Sun, 8 Oct 2023 at 04:41, Simon Glass  wrote:
>
> Hi Sugosh,
>
> On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu  wrote:
> >
> > Add support in binman for generating EFI empty capsules. These
> > capsules are used in the FWU A/B update feature. Also add test cases
> > in binman for the corresponding code coverage.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  tools/binman/etype/efi_empty_capsule.py   | 91 +++
> >  tools/binman/ftest.py | 52 +++
> >  tools/binman/test/319_capsule_accept.dts  | 16 
> >  tools/binman/test/320_capsule_revert.dts  | 14 +++
> >  .../test/321_capsule_accept_missing_guid.dts  | 14 +++
> >  .../binman/test/322_capsule_accept_revert.dts | 17 
> >  6 files changed, 204 insertions(+)
> >  create mode 100644 tools/binman/etype/efi_empty_capsule.py
> >  create mode 100644 tools/binman/test/319_capsule_accept.dts
> >  create mode 100644 tools/binman/test/320_capsule_revert.dts
> >  create mode 100644 tools/binman/test/321_capsule_accept_missing_guid.dts
> >  create mode 100644 tools/binman/test/322_capsule_accept_revert.dts
> >
> > diff --git a/tools/binman/etype/efi_empty_capsule.py 
> > b/tools/binman/etype/efi_empty_capsule.py
> > new file mode 100644
> > index 00..d2c781627b
> > --- /dev/null
> > +++ b/tools/binman/etype/efi_empty_capsule.py
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +# Copyright (c) 2023 Linaro Limited
> > +#
> > +# Entry-type module for producing an empty  EFI capsule
> > +#
> > +
> > +import os
> > +
> > +from binman.entry import Entry
> > +from binman.etype.section import Entry_section
> > +from dtoc import fdt_util
> > +from u_boot_pylib import tools
> > +
> > +class Entry_efi_empty_capsule(Entry_section):
>
> Do you think this could subclass Entry_efi_capsule? They seem to do
> similar things. You could call generate_capsule() or
> generate_empty_capsule(). depending on whether any data is present
> (and perhaps require an operation if no data).
>
> I'm not sure about this, just an idea.

Okay, let me try this out. If it is getting too confusing or unclear,
I will keep the two entry types separate.

>
> > +"""Generate EFI empty capsules
> > +
> > +The parameters needed for generation of the empty capsules can
> > +be provided as properties in the entry.
> > +
> > +Properties / Entry arguments:
> > +- image-guid: Image GUID which will be used for identifying the
> > +  updatable image on the board. Mandatory for accept capsule.
> > +- accept-capsule - Boolean property to generate an accept capsule.
> > +  image-type-id
> > +- revert-capsule - Boolean property to generate a revert capsule
> > +
> > +For more details on the description of the capsule format, and the 
> > capsule
> > +update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
> > +specification`_. For more information on the empty capsule, refer the
> > +sections 2.3.2 and 2.3.3 in the `Dependable Boot specification`_.
> > +
> > +A typical accept empty capsule entry node would then look something 
> > like this
> > +
> > +empty-capsule {
> > +type = "efi-empty-capsule";
> > +/* Image GUID for testing capsule update */
> > +image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
> > +accept-capsule;
> > +};
> > +
> > +A typical revert empty capsule entry node would then look something 
> > like this
> > +
> > +empty-capsule {
> > +type = "efi-empty-capsule";
> > +revert-capsule;
> > +};
> > +
> > +The empty capsules do not have any input payload image.
> > +
> > +.. _`UEFI specification`: 
> > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf
> > +.. _`Dependable Boot specification`: 
> > https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
> > +"""
> > +def __init__(self, section, etype, node):
> > +super().__init__(section, etype, node)
> > +self.accept = 0
> > +self.revert = 0
> > +
> > +def ReadNode(self):
> > +super().ReadNode()
> > +
> > +self.image_guid = fdt_util.GetString(self._node, 'image-guid')
> > +self.accept = fdt_util.GetBool(self._node, 'accept-capsule')
> > +self.revert = fdt_util.GetBool(self._node, 'revert-capsule')
>
> Perhaps it should be
>
> operation = "accept" / "revert" ?
>
> Using two conflicting bools is not great.

Will change

>
> > +
> > +if self.accept and not self.image_guid:
> > +self.Raise('Image GUID needed for generating accept capsule')
> > +
> > +if self.accept and self.revert:
> > +self.Raise('Need to enable either Accept or Revert capsule')
> > +
> > +def BuildSectionData(self, required):
> > +def get_binman_test_guid(type_str):
> > +TYPE_TO_GUID = {
> > +'binman-test' : 

Re: [RFC PATCH] mxs: Don't enable 4P2 reg if mx28 is powered only from DCDC_BATT without 5V

2023-10-09 Thread Lukasz Majewski
Hi Fabio, Alan,

> Hi Alan,
> 
> [Adding Lukasz and Cody]
> 
> On Tue, Aug 30, 2022 at 2:49 PM Alan Kay  wrote:
> >
> > mxs_power_enable_4p2() was added to mxs_batt_boot() in
> > 'commit a0f97610757d ("ARM: mxs: Enable DCDC converter for battery
> > boot")' to enable DCDC converter when board is powered from 5V and
> > has detected sufficient battery voltage.
> > This involves enabling 4P2 regulator and there is a code
> > in mxs_power_enable_4p2() that disables VDDIO, VDDA, VDDD outputs of
> > the DCDC converter and enables BO for each power rail e.g.
> >
> > setbits_le32(_regs->hw_power_vddioctrl,
> > POWER_VDDIOCTRL_DISABLE_FET |
> > POWER_VDDIOCTRL_PWDN_BRNOUT);
> >
> > In case the mx28 is powered by the 5V source and linear regulators
> > are supplying power to the VDDIO, VDDA, VDDD rails there is no
> > issue.
> >
> > However if the mx28 is powered by the DCDC_BATT source only without
> > 5V, disabling the DCDC converter outputs causes brownout power down.
> >
> > The proposed solution is not to call mxs_power_enable_4p2() at all
> > if the mx28 is powered by the DCDC_BATT source only. There is no
> > reason to enable 4P2 regulator in this case and setup of all
> > registers is done in mxs_batt_boot().
> >
> > Also there is no need to enable 5V brownout in
> > mxs_power_init() in this case.
> >
> > Please consider if this is acceptable and I will submit a proper
> > patch.
> >
> > Signed-off-by: Alan Kay   
> 
> Cody also sent a fix for this issue:
> 
> https://patchwork.ozlabs.org/project/uboot/patch/20230703163340.101490-2-c...@londelec.com/

Isn't this already addressed with:
https://source.denx.de/u-boot/u-boot/-/commit/79230640cb4fb780e2be9bb9a47b31976b18cac4

Please also look into the recent patches for imx287 (xea board for
reference):

tig -- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c

At least SHA1: 65b9b3462bec2966911658836983819ab4e4823e


Best regards,

Lukasz Majewski

--

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


pgpQmSvw0ude8.pgp
Description: OpenPGP digital signature


Re: [PATCH 4/5] btool: mkeficapsule: Add support for EFI empty capsule generation

2023-10-09 Thread Sughosh Ganu
hi Simon,

On Sun, 8 Oct 2023 at 04:42, Simon Glass  wrote:
>
> Hi Sugosh,
>
> On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu  wrote:
> >
> > Add a method to the mkeficapsule bintool to generate empty
> > capsules. These are capsules needed for the FWU A/B update feature.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  tools/binman/btool/mkeficapsule.py | 29 +
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/tools/binman/btool/mkeficapsule.py 
> > b/tools/binman/btool/mkeficapsule.py
> > index 61179747ff..89c0adfc9f 100644
> > --- a/tools/binman/btool/mkeficapsule.py
> > +++ b/tools/binman/btool/mkeficapsule.py
> > @@ -80,6 +80,35 @@ class Bintoolmkeficapsule(bintool.Bintool):
> >
> >  return self.run_cmd(*args)
> >
> > +def generate_empty_capsule(self, accept, revert, image_guid,
>
> Instead of two separate bools, how about an 'operation' param, a
> string which is either accept or revert? Or perhaps just have 'accept'
>  and pass True or False?

Okay incorporate this and the other two review comments on this patch. Thanks.

-sughosh

>
> > +   output_fname):
> > +"""Generate empty capsules for FWU A/B updates
> > +
> > +Args:
> > +accept (int): Generate an accept capsule
> > +revert (int): Generate a revert capsule
> > +image_guid (str): GUID used for identifying the image
> > +output_fname (str): Path to the output capsule file
> > +
> > +Returns:
> > +str: Tool output
> > +"""
> > +if accept:
> > +args = [
> > +f'--guid={image_guid}',
> > +'--fw-accept'
> > +]
> > +elif revert:
> > +args = [
> > +'--fw-revert'
> > +]
>
> That can be on none line
>
> > +
> > +args += [
> > +output_fname
> > +]
>
> Same here
>
> > +
> > +return self.run_cmd(*args)
> > +
> >  def fetch(self, method):
> >  """Fetch handler for mkeficapsule
> >
> > --
> > 2.34.1
> >
>
> Regards,
> Simon


Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification

2023-10-09 Thread Sughosh Ganu
hi Simon,

On Sun, 8 Oct 2023 at 04:41, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu  wrote:
> >
> > The various fields of a generated capsule are currently verified
> > through hard-coded offsets. Use the dump-capsule feature for dumping
> > the capsule header contents and use those for capsule verification.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  tools/binman/ftest.py | 95 ---
> >  1 file changed, 54 insertions(+), 41 deletions(-)
>
> This looks good apart from a few nits below. However, the tests fail for me.

Can you please specify which tests fail, and the way to reproduce the
failures? I ran the tests before sending the patches, and they ran
fine, including the coverage which is 100%. Ci too did not complain.

>
> >
> > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> > index 8e419645a6..2b8871ab7e 100644
> > --- a/tools/binman/ftest.py
> > +++ b/tools/binman/ftest.py
> > @@ -121,9 +121,11 @@ COMP_BINTOOLS = ['bzip2', 'gzip', 'lz4', 'lzma_alone', 
> > 'lzop', 'xz', 'zstd']
> >  TEE_ADDR = 0x5678
> >
> >  # Firmware Management Protocol(FMP) GUID
> > -FW_MGMT_GUID = 'edd5cb6d2de8444cbda17194199ad92a'
> > +FW_MGMT_GUID = '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A'
> >  # Image GUID specified in the DTS
> > -CAPSULE_IMAGE_GUID = '52cfd7092007104791d108469b7fe9c8'
> > +CAPSULE_IMAGE_GUID = '09D7CF52-0720-4710-91D1-08469B7FE9C8'
> > +# Windows cert GUID
> > +WIN_CERT_TYPE_EFI_GUID = '4AAFD29D-68DF-49EE-8AA9-347D375665A7'
>
> Please use lower-case hex

Okay

>
> >
> >  class TestFunctional(unittest.TestCase):
> >  """Functional tests for binman
> > @@ -7223,52 +7225,63 @@ fdt fdtmapExtract the 
> > devicetree blob from the fdtmap
> >  self.assertRegex(err,
> >   "Image 'image'.*missing bintools.*: bootgen")
> >
> > +def _GetCapsuleHeaders(self, data):
>
> This should have a function comment so it is clear what it is doing, 
> returning.

Will add

-sughosh

>
> > +capsule_file = os.path.join(self._indir, 'test.capsule')
> > +tools.write_file(capsule_file, data)
> > +
> > +out = tools.run('mkeficapsule', '--dump-capsule', capsule_file)
> > +lines = out.splitlines()
> > +
> > +re_line = re.compile(r'^([^:\-\t]*)(?:\t*\s*:\s*(.*))?$')
> > +vals = collections.defaultdict(list)
> > +for line in lines:
> > +mat = re_line.match(line)
> > +if mat:
> > +vals[mat.group(1)] = mat.group(2)
> > +
> > +return vals
> > +
> [..]
>
> Regards,
> Simon


Re: [PATCH v3 1/6] binman: ti-secure: Add support for firewalling entities

2023-10-09 Thread Manorit Chawdhry
Hi Simon,

On 17:10-20231007, Simon Glass wrote:
> Hi Manorit,
> 
> On Wed, 4 Oct 2023 at 06:32, Manorit Chawdhry  wrote:
> >
> > We can now firewall entities while loading them through our secure
> > entity TIFS, the required information should be present in the
> > certificate that is being parsed by TIFS.
> >
> > The following commit adds the support to enable the certificates to be
> > generated if the firewall configurations are present in the binman dtsi
> > nodes.
> >
> > Signed-off-by: Manorit Chawdhry 
> > ---
> >  tools/binman/btool/openssl.py   | 16 +++-
> >  tools/binman/etype/ti_secure.py | 85 
> > +
> >  tools/binman/etype/x509_cert.py |  3 +-
> >  3 files changed, 101 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> > index aad3b61ae27c..dff439df211f 100644
> > --- a/tools/binman/btool/openssl.py
> > +++ b/tools/binman/btool/openssl.py
> > @@ -82,7 +82,7 @@ imageSize  = INTEGER:{len(indata)}
> >  return self.run_cmd(*args)
> >
> >  def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
> > -  config_fname, req_dist_name_dict):
> > +  config_fname, req_dist_name_dict, firewall_cert_data):
> >  """Create a certificate to be booted by system firmware
> >
> >  Args:
> > @@ -94,6 +94,13 @@ imageSize  = INTEGER:{len(indata)}
> >  req_dist_name_dict (dict): Dictionary containing key-value 
> > pairs of
> >  req_distinguished_name section extensions, must contain 
> > extensions for
> >  C, ST, L, O, OU, CN and emailAddress
> > +firewall_cert_data (dict):
> > +  - auth_in_place (int): The Priv ID for copying as the
> > +specific host in firewall protected region
> > +  - num_firewalls (int): The number of firewalls in the
> > +extended certificate
> > +  - certificate (str): Extended firewall certificate with
> > +the information for the firewall configurations.
> >
> >  Returns:
> >  str: Tool output
> > @@ -121,6 +128,7 @@ basicConstraints   = CA:true
> >  1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
> >  1.3.6.1.4.1.294.1.34   = ASN1:SEQUENCE:sysfw_image_integrity
> >  1.3.6.1.4.1.294.1.35   = ASN1:SEQUENCE:sysfw_image_load
> > +1.3.6.1.4.1.294.1.37   = ASN1:SEQUENCE:firewall
> >
> >  [ swrv ]
> >  swrv = INTEGER:{sw_rev}
> > @@ -132,7 +140,11 @@ imageSize  = INTEGER:{len(indata)}
> >
> >  [ sysfw_image_load ]
> >  destAddr = FORMAT:HEX,OCT:
> > -authInPlace = INTEGER:2
> > +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> > +
> > +[ firewall ]
> > +numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
> > +{firewall_cert_data['certificate']}
> 
> Do we want the text above if there is no firewall info?
> 

Yes, keeping numFirewallRegions = INTEGER:0 is valid. The other way would be
to remove OIDs and everything that we have kept in the certificate when
firewall nodes are not present but that seems a bit more difficult given
that we have an easy fix keeping the numFirewallRegions as 0.

> >  ''', file=outf)
> >  args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
> >  '-outform', 'DER', '-out', cert_fname, '-config', 
> > config_fname,
> > diff --git a/tools/binman/etype/ti_secure.py 
> > b/tools/binman/etype/ti_secure.py
> > index d939dce57139..a7409023fa55 100644
> > --- a/tools/binman/etype/ti_secure.py
> > +++ b/tools/binman/etype/ti_secure.py
> > @@ -7,9 +7,35 @@
> >
> >  from binman.entry import EntryArg
> >  from binman.etype.x509_cert import Entry_x509_cert
> > +from dataclasses import dataclass
> >
> >  from dtoc import fdt_util
> >
> > +@dataclass
> > +class Firewall():
> > +id: int
> > +region: int
> > +control : int
> > +permissions: list[hex]
> > +start_address: str
> > +end_address: str
> > +
> > +def get_certificate(self) -> str:
> > +unique_identifier = f"{self.id}{self.region}"
> > +cert = f"""
> > +firewallID{unique_identifier} = INTEGER:{self.id}
> > +region{unique_identifier} = INTEGER:{self.region}
> > +control{unique_identifier} = INTEGER:{hex(self.control)}
> > +nPermissionRegs{unique_identifier} = INTEGER:{len(self.permissions)}
> > +"""
> > +for index, permission in enumerate(self.permissions):
> > +cert += f"""permissions{unique_identifier}{index} = 
> > INTEGER:{hex(permission)}
> > +"""
> > +cert += f"""startAddress{unique_identifier} = 
> > FORMAT:HEX,OCT:{self.start_address:02x}
> > +endAddress{unique_identifier} = FORMAT:HEX,OCT:{self.end_address:02x}
> > +"""
> > +return cert
> > +
> >  class Entry_ti_secure(Entry_x509_cert):
> >  """Entry containing a TI x509 certificate binary
> >
> > @@ -17,6 +43,11 @@ class 

Re: [PATCH 10/16] serial: sh: Add RZ/G2L SCIF support

2023-10-09 Thread Paul Barker
On Sat, Oct 07, 2023 at 11:14:06PM +0200, Marek Vasut wrote:
> On 10/5/23 14:08, Paul Barker wrote:
> > The case we're interested in here is the Receive Error (ER) & Break
> > Detect (BRK) conditions. I've done some further datasheet digging...
> > 
> > RZ/G2L datasheet says these are cleared by writing zero to the
> > appropriate bits of the FSR register.
> > 
> > RZ/G2{H,M,N,E} datasheet says the same (pages 50-18 & 50-19 of
> > R01UH0808EJ0111 Rev.1.11).
> > 
> > The R-Car Gen3 Hardware Manual says the same (pages 55-18 & 55-19 of
> > R19UH0105EJ0230 Rev.2.30).
> > 
> > For R-Car S4, there is an Excel spreadsheet attached to page 105-5 of
> > the datasheet (R19UH0161EJ0100 Rev.1.00) which again says the same.
> > 
> > For R-Car V4H, the relevant info is on pages 105-16 & 105-18 of the
> > datasheet (R19UH0172EJ0081 Rev.0.81) and says the same.
> > 
> > On the RZ/G2L I was able to reproduce a break condition by changing
> > pinmux settings after the SCIF interface has been configured. You could
> > try this out on an R-Car system, but I don't think it's guaranteed to
> > cause a break condition, it may depend on how the port input is
> > implemented in those SoCs. From my reading, the only guaranteed way to
> > cause a break condition is to hold the Rx signal low, and you might need
> > to solder on some extra wires on to a board to be able to do that.
> 
> Can't you simply send a BREAK from terminal program ?
> In minicom, I think that's meta-F B .
> 
> > We should still fix the error handling here, even if the boards we have
> > don't easily cause Receive Errors or Break conditions, other folks may
> > have their own boards based on these SoCs.
> > 
> > If you're happy I'll go ahead and check IS_ENABLED(CONFIG_RCAR_64) here
> > instead of IS_ENABLED(CONFIG_RZG2L).
> 
> Based on the input I am getting from you here, it seems to me we should just
> use the G2L case as the common case for all systems, without any special
> casing, right ?

I assumed that the code that's in place here was correct for some older
SoC when it was added to u-boot. But I've just looked at the SH7751
datasheet this morning and guess what? It requires writing zeros to
clear the errors.

As long as SCIF_ERRORS is correctly defined for each SoC, then yes, it
looks like we can drop the conditional.

I'll include this in v2.

Thanks,
Paul


signature.asc
Description: PGP signature


Re: [PATCH] doc: Add a short intro video

2023-10-09 Thread Paul Barker
On Sun, Oct 08, 2023 at 03:35:56PM -0600, Simon Glass wrote:
> This video covers the basics in a short time, so add a link to it.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  doc/learn/talks.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/learn/talks.rst b/doc/learn/talks.rst
> index 0bb44aeabe55..d65e3b92be1a 100644
> --- a/doc/learn/talks.rst
> +++ b/doc/learn/talks.rst
> @@ -15,6 +15,9 @@ learn a bit about U-Boot:
>`__
>from Embedded Linux Conference 2023.
>  
> +* `Introduction to U-Boot for beginners
> +  `__
> +
>  See elinux_talks_ for a more comprehensive list.
>  
>  .. _elinux_talks: https://elinux.org/Boot_Loaders#U-Boot
> -- 
> 2.42.0.609.gbb76f46606-goog
> 

Reviewed-by: Paul Barker 


signature.asc
Description: PGP signature