Re: [PATCH v1] doc: board: imx8qm-rom7720-a1.rst: convert readme to reST

2020-12-06 Thread Stefano Babic

Hi Oliver,

On 20.11.20 15:05, Oliver Graute wrote:

Convert README to reStructuredText format.

Signed-off-by: Oliver Graute 
---
  board/advantech/imx8qm_rom7720_a1/README  | 61 --
  doc/board/advantech/imx8qm-rom7720-a1.rst | 75 +++
  doc/board/advantech/index.rst |  9 +++


The entry in doc/board/index.rst is missing, I add it myself while merging.

diff --git a/doc/board/index.rst b/doc/board/index.rst
index 4b6a996eb1..915f1be8a5 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -7,6 +7,7 @@ Board-specific doc
:maxdepth: 2

actions/index
+   advantech/index
AndesTech/index
amlogic/index
atmel/index

Best regards,
Stefano


  3 files changed, 84 insertions(+), 61 deletions(-)
  delete mode 100644 board/advantech/imx8qm_rom7720_a1/README
  create mode 100644 doc/board/advantech/imx8qm-rom7720-a1.rst
  create mode 100644 doc/board/advantech/index.rst

diff --git a/board/advantech/imx8qm_rom7720_a1/README 
b/board/advantech/imx8qm_rom7720_a1/README
deleted file mode 100644
index 585fde440d..00
--- a/board/advantech/imx8qm_rom7720_a1/README
+++ /dev/null
@@ -1,61 +0,0 @@
-U-Boot for the NXP i.MX8QM ROM 7720a1 board
-
-Quick Start
-===
-
-- Build the ARM Trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Get imx-mkimage
-- Build U-Boot
-- Build imx-mkimage
-- Flash the binary into the SD card
-- Boot
-
-Get and Build the ARM Trusted firmware
-==
-
-$ git clone https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ git checkout origin/imx_4.14.78_1.0.0_ga -b imx_4.14.78_1.0.0_ga
-$ make PLAT=imx8qm bl31
-
-Get scfw_tcm.bin and ahab-container.img
-==
-
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.1.bin
-$ chmod +x imx-sc-firmware-1.1.bin
-$ ./imx-sc-firmware-1.1.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Or use this to avoid running random scripts from the internet,
-but note that you must agree to the license the script displays:
-
-$ dd if=imx-sc-firmware-1.1.bin of=imx-sc-firmware-1.1.tar.bz2 bs=37185 skip=1
-$ tar -xf imx-sc-firmware-1.1.tar.bz2
-$ cp imx-sc-firmware-1.1/mx8qm-val-scfw-tcm.bin $(builddir)
-
-$ dd if=firmware-imx-8.0.bin of=firmware-imx-8.0.tar.bz2 bs=37180 skip=1
-$ tar -xf firmware-imx-8.0.tar.bz2
-$ cp firmware-imx-8.0/firmware/seco/mx8qm-ahab-container.img $(builddir)
-
-Build U-Boot
-
-
-$ export ATF_LOAD_ADDR=0x8000
-$ export BL33_LOAD_ADDR=0x8002
-$ make imx8qm_rom7720_a1_4G_defconfig
-$ make u-boot.bin
-$ make flash.bin
-
-Flash the binary into the SD card
-=
-
-Burn the flash.bin binary to SD card offset 32KB:
-
-$ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
-
-Boot
-
-Set Boot switch SW2: 1100.
diff --git a/doc/board/advantech/imx8qm-rom7720-a1.rst 
b/doc/board/advantech/imx8qm-rom7720-a1.rst
new file mode 100644
index 00..bd4be1dbeb
--- /dev/null
+++ b/doc/board/advantech/imx8qm-rom7720-a1.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the NXP i.MX8QM ROM 7720a1 board
+===
+
+Quick Start
+---
+
+- Build the ARM Trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Get imx-mkimage
+- Build U-Boot
+- Build imx-mkimage
+- Flash the binary into the SD card
+- Boot
+
+Get and Build the ARM Trusted firmware
+--
+
+.. code-block:: bash
+
+ $ git clone https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ git checkout origin/imx_4.14.78_1.0.0_ga -b imx_4.14.78_1.0.0_ga
+ $ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.1.bin
+ $ chmod +x imx-sc-firmware-1.1.bin
+ $ ./imx-sc-firmware-1.1.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+ $ chmod +x firmware-imx-8.0.bin
+ $ ./firmware-imx-8.0.bin
+
+Or use this to avoid running random scripts from the internet,
+but note that you must agree to the license the script displays:
+
+.. code-block:: bash
+
+ $ dd if=imx-sc-firmware-1.1.bin of=imx-sc-firmware-1.1.tar.bz2 bs=37185 
skip=1
+ $ tar -xf imx-sc-firmware-1.1.tar.bz2
+ $ cp imx-sc-firmware-1.1/mx8qm-val-scfw-tcm.bin $(builddir)
+
+ $ dd if=firmware-imx-8.0.bin of=firmware-imx-8.0.tar.bz2 bs=37180 skip=1
+ $ tar -xf firmware-imx-8.0.tar.bz2
+ $ cp firmware-imx-8.0/firmware/seco/mx8qm-ahab-container.img $(builddir)
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+ $ export ATF_LOAD_ADDR=0x8000
+ $ export BL33_LOAD_ADDR=0x8002
+ $ make imx8qm_rom7720_a1_4G_defconfig
+ $ make u-boot.bin
+

SocFPGA: Arria10: Boot from FPGA

2020-12-06 Thread Wolfgang Grandegger
Hello,

I want to boot U-Boot on the Arria10 from the FPGA using recent code. In
the past I used the U-Boot created by the "bsp-editor" as described at
[1], but starting with Quartus 21.3, the so called "old flow" is no
longer available.

I was able to build mainline U-Boot for our Arria10 board and it boots
fine from the eMMC. I wonder if it's also suitable for booting from the
FPGA. Is it available? Has this already been done? IIRC, some special
hacks are required to support boot from the FPGA.

[1] https://rocketboards.org/foswiki/Documentation/UBootA10FPGABoot

Wolfgang



Re: [PATCH 06/14] qemu: arm64: Set dfu_alt_info variable for the platform

2020-12-06 Thread Sughosh Ganu
On Mon, 7 Dec 2020 at 12:26, Heinrich Schuchardt  wrote:

> On 12/7/20 6:42 AM, Sughosh Ganu wrote:
> >
> > On Sat, 5 Dec 2020 at 16:01, Heinrich Schuchardt  > > wrote:
> >
> > On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> >  > The dfu framework uses the dfu_alt_info environment variable to
> get
> >  > information that is needed for performing the firmware update.
> > Set the
> >  > dfu_alt_info for the platform to reflect the two mtd partitions
> >  > created for the u-boot env and the firmware image.
> >  >
> >  > Signed-off-by: Sughosh Ganu  > >
> >
> > I can't see anything QEMU specific in this patch. Why is the code
> under
> > board/emulation/?
> >
> >
> > The device that the board wants to use to set the dfu_alt_info to would
> > be very much board specific. For example, the dfu_alt_info is being set
> > for the qemu platform for an mtd as the interface, with nor0 as the
> > device. Different platforms might have different requirements, like the
> > setting of the variable done for st
> > platforms(board/st/common/stm32mp_dfu.c). I think this information is
> > very much platform specific.
>
> In the function below you simply collect MTD partitions. Isn't this
> something that could be reused for other boards?
>

The function probes all mtd devices, but uses only the nor0 device for
setting up of the dfu_alt_info variable. The other nor1 device is not used,
since, on this platform configuration(non-secure boot), it has the u-boot
environment. So which of the mtd devices to use for setting of the
dfu_alt_info is very much platform specific.


> On other boards (e.g. board/samsung/common/misc.c)
> CONFIG_SET_DFU_ALT_INFO controls if set_dfu_alt_info() exists. Should
> the same be done for QEMU ARM?
>

Yes, I can add a check for this on the lines that you mention. Will do.


>
> Reading through patch 14/14 it is unclear to me how you control to which
> partition you write TF-A, SPL, U-Boot depending on which of these exists
> on the MTD device.
>

This gets added in patch 05/14. This sets the mtd partitions that are to be
set for the platform. On this particular configuration of the
platform(non-secure boot), the partition 1 is used for the u-boot image,
and the partition 2 is used for the u-boot environment.


> Wouldn't it make more sense to encode in the capsule to where it will be
> written?
>

We have discussed this earlier[1] that there is no way to encode the target
device and partition information as part of the capsule, the way the
capsule structure is defined by the uefi specification. That is the reason
that it was decided to use the dfu backend for the update using the
dfu_alt_info variable to indicate the partitions and device to be used for
the update.

-sughosh

[1] - https://lists.denx.de/pipermail/u-boot/2020-May/411236.html


> Best regards
>
> Heinrich
>
> >
> > -sughosh
> >
> >
> > Best regards
> >
> > Heinrich
> >
> >  > ---
> >  >   board/emulation/qemu-arm/qemu-arm.c | 55
> > +
> >  >   include/configs/qemu-arm.h  |  1 +
> >  >   2 files changed, 56 insertions(+)
> >  >
> >  > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> > b/board/emulation/qemu-arm/qemu-arm.c
> >  > index d5ed3eebaf..8cad54c76f 100644
> >  > --- a/board/emulation/qemu-arm/qemu-arm.c
> >  > +++ b/board/emulation/qemu-arm/qemu-arm.c
> >  > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
> >  >
> >  >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> >  >
> >  > +#include 
> >  >   #include 
> >  >
> >  > +#define MTDPARTS_LEN 256
> >  > +#define MTDIDS_LEN   128
> >  > +
> >  > +#define DFU_ALT_BUF_LEN  SZ_1K
> >  > +
> >  > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
> >  > +{
> >  > + struct mtd_info *part;
> >  > + bool first = true;
> >  > + const char *name;
> >  > + int len, partnum = 0;
> >  > +
> >  > + name = mtd->name;
> >  > + len = strlen(buf);
> >  > +
> >  > + if (buf[0] != '\0')
> >  > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> "&");
> >  > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> >  > + "mtd %s=", name);
> >  > +
> >  > + list_for_each_entry(part, >partitions, node) {
> >  > + partnum++;
> >  > + if (!first)
> >  > + len += snprintf(buf + len, DFU_ALT_BUF_LEN
> > - len, ";");
> >  > + first = false;
> >  > +
> >  > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> >  > + "%s part %d",
> >  > + part->name, partnum);
> >  > + }
> >  > +}
> >  > +
> >  > +void 

[PATC 1/2H] board: fsl: ls2088ardb: Program GIC LPI configuration table

2020-12-06 Thread Priyanka Jain
From: Nikhil Gupta 

Add programming of GIC LPI configuration table:
1. Program Redistributor PROCBASER configuration table
   which is common for all redistributors.
2. Program Redistributor pending table (PENDBASER), for
   all the available redistributors.
3. Reserve DDR memory region used for GIC LPI configuration table.

Signed-off-by: Nikhil Gupta 
Signed-off-by: Priyanka Jain 
---
 board/freescale/ls2080ardb/ls2080ardb.c | 27 -
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index c7e9c1dacf..1c54bac529 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2015 Freescale Semiconductor
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
  */
 #include 
 #include 
@@ -24,7 +24,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
+#define GIC_LPI_SIZE 0x20
 #ifdef CONFIG_FSL_QIXIS
 #include "../common/qixis.h"
 #include "ls2080ardb_qixis.h"
@@ -352,6 +355,21 @@ void board_quiesce_devices(void)
 }
 #endif
 
+#ifdef CONFIG_GIC_V3_ITS
+void fdt_fixup_gic_lpi_memory(void *blob, u64 gic_lpi_base)
+{
+   u32 phandle;
+   int err;
+   struct fdt_memory gic_lpi;
+
+   gic_lpi.start = gic_lpi_base;
+   gic_lpi.end = gic_lpi_base + GIC_LPI_SIZE - 1;
+   err = fdtdec_add_reserved_memory(blob, "gic-lpi", _lpi, );
+   if (err < 0)
+   debug("failed to add reserved memory: %d\n", err);
+}
+#endif
+
 #ifdef CONFIG_OF_BOARD_SETUP
 void fsl_fdt_fixup_flash(void *fdt)
 {
@@ -426,6 +444,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
u64 mc_memory_base = 0;
u64 mc_memory_size = 0;
u16 total_memory_banks;
+   u64 gic_lpi_base;
 
ft_cpu_setup(blob, bd);
 
@@ -445,6 +464,12 @@ int ft_board_setup(void *blob, struct bd_info *bd)
base[1] = gd->bd->bi_dram[1].start;
size[1] = gd->bd->bi_dram[1].size;
 
+#ifdef CONFIG_GIC_V3_ITS
+   gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
+   gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
+   fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
+#endif
+
 #ifdef CONFIG_RESV_RAM
/* reduce size if reserved memory is within this bank */
if (gd->arch.resv_ram >= base[0] &&
-- 
2.17.1



Re: [PATCH 06/14] qemu: arm64: Set dfu_alt_info variable for the platform

2020-12-06 Thread Heinrich Schuchardt

On 12/7/20 6:42 AM, Sughosh Ganu wrote:


On Sat, 5 Dec 2020 at 16:01, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 11/26/20 7:41 PM, Sughosh Ganu wrote:
 > The dfu framework uses the dfu_alt_info environment variable to get
 > information that is needed for performing the firmware update.
Set the
 > dfu_alt_info for the platform to reflect the two mtd partitions
 > created for the u-boot env and the firmware image.
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

I can't see anything QEMU specific in this patch. Why is the code under
board/emulation/?


The device that the board wants to use to set the dfu_alt_info to would
be very much board specific. For example, the dfu_alt_info is being set
for the qemu platform for an mtd as the interface, with nor0 as the
device. Different platforms might have different requirements, like the
setting of the variable done for st
platforms(board/st/common/stm32mp_dfu.c). I think this information is
very much platform specific.


In the function below you simply collect MTD partitions. Isn't this
something that could be reused for other boards?

On other boards (e.g. board/samsung/common/misc.c)
CONFIG_SET_DFU_ALT_INFO controls if set_dfu_alt_info() exists. Should
the same be done for QEMU ARM?

Reading through patch 14/14 it is unclear to me how you control to which
partition you write TF-A, SPL, U-Boot depending on which of these exists
on the MTD device.

Wouldn't it make more sense to encode in the capsule to where it will be
written?

Best regards

Heinrich



-sughosh


Best regards

Heinrich

 > ---
 >   board/emulation/qemu-arm/qemu-arm.c | 55
+
 >   include/configs/qemu-arm.h          |  1 +
 >   2 files changed, 56 insertions(+)
 >
 > diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
 > index d5ed3eebaf..8cad54c76f 100644
 > --- a/board/emulation/qemu-arm/qemu-arm.c
 > +++ b/board/emulation/qemu-arm/qemu-arm.c
 > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
 >
 >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
 >
 > +#include 
 >   #include 
 >
 > +#define MTDPARTS_LEN         256
 > +#define MTDIDS_LEN           128
 > +
 > +#define DFU_ALT_BUF_LEN              SZ_1K
 > +
 > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
 > +{
 > +     struct mtd_info *part;
 > +     bool first = true;
 > +     const char *name;
 > +     int len, partnum = 0;
 > +
 > +     name = mtd->name;
 > +     len = strlen(buf);
 > +
 > +     if (buf[0] != '\0')
 > +             len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
 > +     len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
 > +                     "mtd %s=", name);
 > +
 > +     list_for_each_entry(part, >partitions, node) {
 > +             partnum++;
 > +             if (!first)
 > +                     len += snprintf(buf + len, DFU_ALT_BUF_LEN
- len, ";");
 > +             first = false;
 > +
 > +             len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
 > +                             "%s part %d",
 > +                             part->name, partnum);
 > +     }
 > +}
 > +
 > +void set_dfu_alt_info(char *interface, char *devstr)
 > +{
 > +     struct mtd_info *mtd;
 > +
 > +     ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
 > +
 > +     if (env_get("dfu_alt_info"))
 > +             return;
 > +
 > +     memset(buf, 0, sizeof(buf));
 > +
 > +     /* probe all MTD devices */
 > +     mtd_probe_devices();
 > +
 > +     mtd = get_mtd_device_nm("nor0");
 > +     if (!IS_ERR_OR_NULL(mtd))
 > +             board_get_alt_info(mtd, buf);
 > +
 > +     env_set("dfu_alt_info", buf);
 > +     printf("dfu_alt_info set\n");
 > +}
 > +
 >   static void board_get_mtdparts(const char *dev, const char
*partition,
 >                              char *mtdids, char *mtdparts)
 >   {
 > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
 > index 69ff329434..726f985d35 100644
 > --- a/include/configs/qemu-arm.h
 > +++ b/include/configs/qemu-arm.h
 > @@ -33,6 +33,7 @@
 >   #include 
 >
 >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
 > +#define CONFIG_SET_DFU_ALT_INFO
 >   #define CONFIG_SYS_MTDPARTS_RUNTIME
 >   #endif
 >
 >





Re: [PATCH 07/14] efi_loader: Add config option to indicate fmp header presence

2020-12-06 Thread Sughosh Ganu
On Sat, 5 Dec 2020 at 16:04, Heinrich Schuchardt  wrote:

> On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > When building the capsule using scripts in edk2, an fmp header is
> > added on top of the binary payload. Add a config option to indicate
> > the presence of the header. When enabled, the pointer to the image
> > needs to be adjusted as per the size of the header to point to the
> > actual binary payload.
>
> Why do we need a config option? Can't we detect the header?
>

We do have a header signature that can be read, so yes this can be detected
at runtime.


>
> Can we harmonize the capsule format in EDK II and U-Boot?
>

I am not sure about this though. The FMP payload header that gets added by
the edk2 scripts is not defined by the uefi specification but is a edk2
specific structure. I am not sure if defining it in u-boot would make sense.

-sughosh


> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   lib/efi_loader/Kconfig|  7 +++
> >   lib/efi_loader/efi_firmware.c | 12 
> >   2 files changed, 19 insertions(+)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 0d1b1b5356..55e4787e32 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -138,6 +138,13 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT
> > Select this option if you want to enable capsule-based
> > firmware update using Firmware Management Protocol.
> >
> > +config EFI_CAPSULE_FMP_HEADER
> > + bool "Capsule uses FMP header"
> > + depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
> > + help
> > +   Select this option if the capsule is built using the
> > +   scripts in edk2.
> > +
> >   config EFI_CAPSULE_FIRMWARE_FIT
> >   bool "FMP driver for FIT image"
> >   depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
> > diff --git a/lib/efi_loader/efi_firmware.c
> b/lib/efi_loader/efi_firmware.c
> > index 7e56077383..6c97604d8b 100644
> > --- a/lib/efi_loader/efi_firmware.c
> > +++ b/lib/efi_loader/efi_firmware.c
> > @@ -385,10 +385,22 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
> >   if (!image)
> >   return EFI_EXIT(EFI_INVALID_PARAMETER);
> >
> > + if (CONFIG_IS_ENABLED(EFI_CAPSULE_FMP_HEADER)) {
> > + /*
> > +  * When building the capsule with the scripts in
> > +  * edk2, a FMP header is inserted above the capsule
> > +  * payload. Compensate for this header to get the
> > +  * actual payload that is to be updated.
> > +  */
> > + image += 0x10;
> > + image_size -= 0x10;
> > + }
> > +
> >   if (dfu_write_by_alt(image_index - 1, (void *)image, image_size,
> >NULL, NULL))
> >   return EFI_EXIT(EFI_DEVICE_ERROR);
> >
> > + printf("%s: Capsule update complete!\n", __func__);
> >   return EFI_EXIT(EFI_SUCCESS);
> >   }
> >
> >
>
>


Re: [PATCH 06/14] qemu: arm64: Set dfu_alt_info variable for the platform

2020-12-06 Thread Sughosh Ganu
On Sat, 5 Dec 2020 at 16:01, Heinrich Schuchardt  wrote:

> On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > The dfu framework uses the dfu_alt_info environment variable to get
> > information that is needed for performing the firmware update. Set the
> > dfu_alt_info for the platform to reflect the two mtd partitions
> > created for the u-boot env and the firmware image.
> >
> > Signed-off-by: Sughosh Ganu 
>
> I can't see anything QEMU specific in this patch. Why is the code under
> board/emulation/?
>

The device that the board wants to use to set the dfu_alt_info to would be
very much board specific. For example, the dfu_alt_info is being set for
the qemu platform for an mtd as the interface, with nor0 as the device.
Different platforms might have different requirements, like the setting of
the variable done for st platforms(board/st/common/stm32mp_dfu.c). I think
this information is very much platform specific.

-sughosh


>
> Best regards
>
> Heinrich
>
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 55 +
> >   include/configs/qemu-arm.h  |  1 +
> >   2 files changed, 56 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index d5ed3eebaf..8cad54c76f 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
> >
> >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> >
> > +#include 
> >   #include 
> >
> > +#define MTDPARTS_LEN 256
> > +#define MTDIDS_LEN   128
> > +
> > +#define DFU_ALT_BUF_LEN  SZ_1K
> > +
> > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
> > +{
> > + struct mtd_info *part;
> > + bool first = true;
> > + const char *name;
> > + int len, partnum = 0;
> > +
> > + name = mtd->name;
> > + len = strlen(buf);
> > +
> > + if (buf[0] != '\0')
> > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
> > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > + "mtd %s=", name);
> > +
> > + list_for_each_entry(part, >partitions, node) {
> > + partnum++;
> > + if (!first)
> > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> ";");
> > + first = false;
> > +
> > + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> > + "%s part %d",
> > + part->name, partnum);
> > + }
> > +}
> > +
> > +void set_dfu_alt_info(char *interface, char *devstr)
> > +{
> > + struct mtd_info *mtd;
> > +
> > + ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
> > +
> > + if (env_get("dfu_alt_info"))
> > + return;
> > +
> > + memset(buf, 0, sizeof(buf));
> > +
> > + /* probe all MTD devices */
> > + mtd_probe_devices();
> > +
> > + mtd = get_mtd_device_nm("nor0");
> > + if (!IS_ERR_OR_NULL(mtd))
> > + board_get_alt_info(mtd, buf);
> > +
> > + env_set("dfu_alt_info", buf);
> > + printf("dfu_alt_info set\n");
> > +}
> > +
> >   static void board_get_mtdparts(const char *dev, const char *partition,
> >  char *mtdids, char *mtdparts)
> >   {
> > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> > index 69ff329434..726f985d35 100644
> > --- a/include/configs/qemu-arm.h
> > +++ b/include/configs/qemu-arm.h
> > @@ -33,6 +33,7 @@
> >   #include 
> >
> >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > +#define CONFIG_SET_DFU_ALT_INFO
> >   #define CONFIG_SYS_MTDPARTS_RUNTIME
> >   #endif
> >
> >
>
>


Re: [PATCH 2/4] ARM: mvebu: helios4 dts changes to enable SPI

2020-12-06 Thread Baruch Siach
Hi Dennis,

On Mon, Dec 07 2020, dgilm...@redhat.com wrote:
> From: Dennis Gilmore 
>
> mirror seettings for the clearfog on the helios4 to get SPI working.
>
> Signed-off-by: Dennis Gilmore 
> ---
>  arch/arm/dts/armada-388-helios4-u-boot.dtsi | 22 ++
>  arch/arm/dts/armada-388-helios4.dts | 46 -
>  2 files changed, 58 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi 
> b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> index 0753889854..82513a1ce7 100644
> --- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> @@ -1,13 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  
> -/ {
> - aliases {
> - i2c0 = 
> - i2c1 = 
> - spi1 = 
> - };
> -};
> -
>   {
>   phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
>  };
> @@ -37,5 +29,17 @@
>  };
>  
>   {
> -   u-boot,dm-spl;
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +
> + eeprom@52 {
> + u-boot,dm-spl;
> + };
> +
> + eeprom@53 {
> + u-boot,dm-spl;
> + };
>  };
> diff --git a/arch/arm/dts/armada-388-helios4.dts 
> b/arch/arm/dts/armada-388-helios4.dts
> index fb49df2a3b..e948b94090 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -22,10 +22,14 @@
>   };
>  
>   aliases {
> - /* So that mvebu u-boot can update the MAC addresses */
> + /* So that mvebu u-boot can update the MAC address */
>   ethernet1 = 
> + spi1 = 
> + i2c0 = 
> + i2c1 = 
>   };
>  
> +
>   chosen {
>   stdout-path = "serial0:115200n8";
>   };
> @@ -306,3 +310,43 @@
>   };
>   };
>  };
> +
> + {
> + helios4_spi1_cs_pins: spi1-cs-pins {
> + marvell,pins = "mpp55";
> + marvell,function = "spi1";
> + };
> + mikro_pins: mikro-pins {
> + /* int: mpp22 rst: mpp29 */
> + marvell,pins = "mpp22", "mpp29";
> + marvell,function = "gpio";
> + };
> + mikro_spi_pins: mikro-spi-pins {
> + marvell,pins = "mpp43";
> + marvell,function = "spi1";
> + };
> + mikro_uart_pins: mikro-uart-pins {
> + marvell,pins = "mpp24", "mpp25";
> + marvell,function = "ua1";
> + };
> + rear_button_pins: rear-button-pins {
> + marvell,pins = "mpp34";
> + marvell,function = "gpio";
> + };

There is no MikroBUS header or rear button on the Helios4 carrier as far
as I can see.

> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + /*
> +  * Add SPI CS pins for helios4:
> +  * CS0: W25Q32
> +  * CS1:
> +  * CS2: mikrobus

Ditto.

> +  */
> + pinctrl-0 = <_pins _spi_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};

baruch

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


Re: [PATCH 05/14] qemu: arm64: Add support for dynamic mtdparts for the platform

2020-12-06 Thread Sughosh Ganu
On Sat, 5 Dec 2020 at 16:00, Heinrich Schuchardt  wrote:

> On 11/26/20 7:41 PM, Sughosh Ganu wrote:
> > Add support for setting the default values for mtd partitions on the
> > platform for the nor flash. This would be used for updating the
> > firmware image using uefi capsule update with the dfu mtd backend
> > driver.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 70 +
> >   include/configs/qemu-arm.h  |  7 +++
> >   2 files changed, 77 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index b3d5b3d5c2..d5ed3eebaf 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
>
> Is this development really QEMU specific or is it something we would
> could reuse for other systems too? If yes, we should put it into another
> directory (drivers/mtd/ or drivers/dfu/).
>

I think the functionality added in this patch is specific for a particular
board, given that the number and type of mtd devices would be specific to a
board. Even if the mtd device detection can be done dynamically, it would
be required to get the partition information from the board specific files.
Merging all the functionality under a common directory like drivers/mtd/,
if done, should be taken up as a separate effort. Thanks.

-sughosh


> Best regards
>
> Heinrich
>
> > @@ -197,3 +197,73 @@ void flash_write32(u32 value, void *addr)
> >   {
> >   asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value));
> >   }
> > +
> > +#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > +
> > +#include 
> > +
> > +static void board_get_mtdparts(const char *dev, const char *partition,
> > +char *mtdids, char *mtdparts)
> > +{
> > + /* mtdids: "=, " */
> > + if (mtdids[0] != '\0')
> > + strcat(mtdids, ",");
> > + strcat(mtdids, dev);
> > + strcat(mtdids, "=");
> > + strcat(mtdids, dev);
> > +
> > + /* mtdparts: "mtdparts=:>;..." */
> > + if (mtdparts[0] != '\0')
> > + strncat(mtdparts, ";", MTDPARTS_LEN);
> > + else
> > + strcat(mtdparts, "mtdparts=");
> > +
> > + strncat(mtdparts, dev, MTDPARTS_LEN);
> > + strncat(mtdparts, ":", MTDPARTS_LEN);
> > + strncat(mtdparts, partition, MTDPARTS_LEN);
> > +}
> > +
> > +void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> > +{
> > + struct mtd_info *mtd;
> > + struct udevice *dev;
> > + const char *mtd_partition;
> > + static char parts[3 * MTDPARTS_LEN + 1];
> > + static char ids[MTDIDS_LEN + 1];
> > + static bool mtd_initialized;
> > +
> > + if (mtd_initialized) {
> > + *mtdids = ids;
> > + *mtdparts = parts;
> > + return;
> > + }
> > +
> > + memset(parts, 0, sizeof(parts));
> > + memset(ids, 0, sizeof(ids));
> > +
> > + /* probe all MTD devices */
> > + for (uclass_first_device(UCLASS_MTD, ); dev;
> > +  uclass_next_device()) {
> > + debug("mtd device = %s\n", dev->name);
> > + }
> > +
> > + mtd = get_mtd_device_nm("nor0");
> > + if (!IS_ERR_OR_NULL(mtd)) {
> > + mtd_partition = MTDPARTS_NOR0;
> > + board_get_mtdparts("nor0", mtd_partition, ids, parts);
> > + put_mtd_device(mtd);
> > + }
> > +
> > + mtd = get_mtd_device_nm("nor1");
> > + if (!IS_ERR_OR_NULL(mtd)) {
> > + mtd_partition = MTDPARTS_NOR1;
> > + board_get_mtdparts("nor1", mtd_partition, ids, parts);
> > + put_mtd_device(mtd);
> > + }
> > +
> > + mtd_initialized = true;
> > + *mtdids = ids;
> > + *mtdparts = parts;
> > + debug("%s:mtdids=%s & mtdparts=%s\n", __func__, ids, parts);
> > +}
> > +#endif /* CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT */
> > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> > index 273fa1a7d7..69ff329434 100644
> > --- a/include/configs/qemu-arm.h
> > +++ b/include/configs/qemu-arm.h
> > @@ -32,6 +32,13 @@
> >
> >   #include 
> >
> > +#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
> > +#define CONFIG_SYS_MTDPARTS_RUNTIME
> > +#endif
> > +
> > +#define MTDPARTS_NOR0"64m(u-boot)\0"
> > +#define MTDPARTS_NOR1"64m(u-boot-env)\0"
> > +
> >   #define CONFIG_EXTRA_ENV_SETTINGS \
> >   "fdt_high=0x\0" \
> >   "initrd_high=0x\0" \
> >
>
>


RE: [PATCH v4 0/3] Add support for LX2162AQDS board

2020-12-06 Thread Meenakshi Aggarwal
HI,

Any review comment on this patch series?

Thanks,
Meenakshi

> -Original Message-
> From: Meenakshi Aggarwal 
> Sent: Thursday, October 29, 2020 7:17 PM
> To: u-boot@lists.denx.de; tr...@konsulko.com; Priyanka Jain
> 
> Cc: Varun Sethi ; Meenakshi Aggarwal
> 
> Subject: [PATCH v4 0/3] Add support for LX2162AQDS board
> 
> From: Meenakshi Aggarwal 
> 
> This patch set add support for LX2162AQDS board.
> LX2162A is a variant of LX2160A.
> 
> ---
> Changes:
>   v2:
>   - Add Separate ARCH for LX2162A SoC
>   - Updated ReadMe of SoC and board
> 
>   v3:
>   - Fix compilation bug for ls1088 introduced
> with lx2162 changes
> 
>   v4:
>   - Remove non-config options from config file
> 
> 
> *** BLURB HERE ***
> 
> Meenakshi Aggarwal (3):
>   drivers/net/phy: Add CORTINA_NO_FW_UPLOAD to Kconfig
>   armv8: lx2162a: Add Soc changes to support LX2162A
>   armv8: lx2162aqds: Add support for LX2162AQDS platform
> 
>  arch/arm/Kconfig   |  12 +
>  arch/arm/cpu/armv8/Kconfig |   2 +-
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  39 +-
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |   5 +
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   7 +-
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  58 ++
>  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|   8 +-
>  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |   4 +-
>  arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c |  19 +-
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  10 +-
>  arch/arm/dts/Makefile  |   6 +-
>  arch/arm/dts/fsl-lx2160a-qds.dts   |   3 -
>  arch/arm/dts/fsl-lx2160a-qds.dtsi  |  22 +-
>  arch/arm/dts/fsl-lx2162a-qds-17-x.dts  |  17 +
>  arch/arm/dts/fsl-lx2162a-qds-18-x.dts  |  17 +
>  arch/arm/dts/fsl-lx2162a-qds-20-x.dts  |  17 +
>  arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi   |  58 ++
>  arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi   |  61 ++
>  arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi   |  26 +
>  arch/arm/dts/fsl-lx2162a-qds.dts   |  34 +
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |   6 +-
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +-
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  12 +-
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   7 +-
>  .../asm/arch-fsl-layerscape/stream_id_lsch3.h  |  10 +-
>  board/freescale/common/qixis.h |  25 +
>  board/freescale/common/vid.c   |   3 +-
>  board/freescale/common/vid.h   |  31 +
>  board/freescale/lx2160a/Kconfig|  16 +
>  board/freescale/lx2160a/MAINTAINERS|  26 +
>  board/freescale/lx2160a/Makefile   |   1 +
>  board/freescale/lx2160a/README | 132 +++
>  board/freescale/lx2160a/eth_lx2160ardb.c   |   3 +-
>  board/freescale/lx2160a/eth_lx2162aqds.c   | 974
> +
>  board/freescale/lx2160a/lx2160a.c  |  43 +-
>  board/freescale/lx2160a/lx2160a.h  |  61 ++
>  configs/lx2160aqds_tfa_SECURE_BOOT_defconfig   |   1 +
>  configs/lx2160aqds_tfa_defconfig   |   1 +
>  configs/lx2160ardb_tfa_SECURE_BOOT_defconfig   |   1 +
>  configs/lx2160ardb_tfa_defconfig   |   1 +
>  configs/lx2160ardb_tfa_stmm_defconfig  |   1 +
>  configs/lx2162aqds_tfa_SECURE_BOOT_defconfig   |  98 +++
>  configs/lx2162aqds_tfa_defconfig   |  96 ++
>  configs/lx2162aqds_tfa_verified_boot_defconfig | 103 +++
>  drivers/ddr/fsl/Kconfig|   1 +
>  drivers/net/fsl-mc/Kconfig |   4 +-
>  drivers/net/ldpaa_eth/Makefile |   1 +
>  drivers/net/phy/Kconfig|   9 +
>  drivers/net/phy/cortina.c  |   8 +-
>  drivers/pci/Kconfig|   4 +-
>  drivers/pci/pcie_layerscape_ep.c   |   4 +-
>  drivers/pci/pcie_layerscape_fixup_common.c |   7 +-
>  include/configs/lx2160a_common.h   |   2 +
>  include/configs/lx2160aqds.h   |  76 --
>  include/configs/lx2160ardb.h   |  50 --
>  include/configs/lx2162aqds.h   |  78 ++
>  56 files changed, 2127 insertions(+), 198 deletions(-)  create mode 100644
> arch/arm/dts/fsl-lx2162a-qds-17-x.dts
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds-18-x.dts
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds-20-x.dts
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-17.dtsi
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-18.dtsi
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds-sd1-20.dtsi
>  create mode 100644 arch/arm/dts/fsl-lx2162a-qds.dts  create mode 100644
> 

Re: [PATCH 03/14] qemu: arm: Scan the pci bus in board_init

2020-12-06 Thread Sughosh Ganu
On Sat, 5 Dec 2020 at 15:15, Heinrich Schuchardt  wrote:

> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> > Scan the pci bus in board_init routine before scanning the virtio
> > devices. This enumerates all the virtio devices, including devices
> > found on the pci bus.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 8 
> >   1 file changed, 8 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index e146d1cc50..b3d5b3d5c2 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -65,6 +65,14 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
> >
> >   int board_init(void)
> >   {
> > +
> > + /*
> > +  * Scan the pci bus before calling virtio_init. This
> > +  * enumerates all virtio devices, including devices
> > +  * on the pci bus.
> > +  */
> > + pci_init();
>
> This does not compile if CONFIG_PCI=n.
>
> aarch64-linux-gnu-ld.bfd:
> board/emulation/qemu-arm/built-in.o:
> in function `board_init':
> board/emulation/qemu-arm/qemu-arm.c:74:
> undefined reference to `pci_init'
>
> Cf.
> arch/arm/mach-mvebu/arm64-common.c-106-#ifdef CONFIG_DM_PCI
> board/socrates/socrates.c-134-#if defined(CONFIG_DM_PCI)
>
> I found these lines in common/board_r.c:250
>
> #ifdef CONFIG_PCI
> static int initr_pci(void)
> {
>  if (IS_ENABLED(CONFIG_PCI_INIT_R))
>  pci_init();
>
>  return 0;
> }
> #endif
>
> Would selecting CONFIG_PCI_INIT_R be enough to solve your problem?
>

Will check this out. Thanks.

-sughosh


Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

2020-12-06 Thread Sughosh Ganu
hello Heinrich,

On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt  wrote:

> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> > The Qemu platform emulator generates a device tree blob and places it
> > at the start of the dram, which is then used by u-boot. Use this dtb
> > only if CONFIG_OF_BOARD is defined. This allows using a different
> > device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached
> > to the u-boot binary as a u-boot-fdt.bin file
>
> Dear Sughosh,
>
> thank your for this series which will allow us to better demonstrate and
> test capsule updates.
>
> I am not sure if the approach that you take at device-trees here is the
> right one.
>
> On QEMU the device-tree is generated on the fly by the QEMU binary
> depending on which devices the user has specified.
>
> Your idea is to replace this device-tree completely to be able to add
> extra elements (the EFI signature list, see patch 2/14). Thus a
> device-tree might be loaded that does not match the user selected devices.
>
> An alternative approach would be to apply all additions to the
> device-tree as an FDT overlay (or fixup). This would allow the dynamic
> parts of the QEMU device-tree still to be passed through.
>

I will take a look at storing the public key as part of the fdt overlay,
with a runtime fixup. Although, I think the issue that you are pointing to
would be specific to Qemu and not other platforms. But I do see the merit
in having the public-key certificate stored as part of an overlay. If I hit
any issues while implementing this, I will get back to you. Thanks.

-sughosh


> Could you, please, assess the pros and cons of the two approaches with
> respect to:
>
> * usability for capsule updates
> * applicability for non-QEMU systems
> * integration of DTB overlays with FIT images for other use cases
>
> Best regards
>
> Heinrich
>
>
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   board/emulation/qemu-arm/qemu-arm.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index f18f2ed7da..e146d1cc50 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -89,11 +89,13 @@ int dram_init_banksize(void)
> >   return 0;
> >   }
> >
> > +#if defined(CONFIG_OF_BOARD)
> >   void *board_fdt_blob_setup(void)
> >   {
> >   /* QEMU loads a generated DTB for us at the start of RAM. */
> >   return (void *)CONFIG_SYS_SDRAM_BASE;
> >   }
> > +#endif
> >
> >   void enable_caches(void)
> >   {
> >
>
>


[PATCH 1/3] rockchip: evb-rk3399: Provide init voltage

2020-12-06 Thread Kever Yang
Add missing regulator-init-microvolt property to vdd_center regulator.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3399-evb-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index 8056dc843e..523ae78657 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -38,6 +38,10 @@
status = "okay";
 };
 
+_center {
+   regulator-init-microvolt = <90>;
+};
+
  {
u-boot,dm-pre-reloc;
bus-width = <4>;
-- 
2.25.1





[PATCH 3/3] rockchip: leez-rk3399: Provide init voltage

2020-12-06 Thread Kever Yang
Add missing regulator-init-microvolt property to vdd_log regulator.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3399-leez-p710-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi 
b/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
index f8b2a1d56e..c638ce2597 100644
--- a/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-leez-p710-u-boot.dtsi
@@ -11,3 +11,7 @@
u-boot,spl-boot-order = "same-as-spl", , 
};
 };
+
+_log {
+   regulator-init-microvolt = <95>;
+};
-- 
2.25.1





[PATCH 2/3] rockchip: firefly-rk3399: Provide init voltage

2020-12-06 Thread Kever Yang
Add missing regulator-init-microvolt property to vdd_log regulator.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3399-firefly-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
index 38e0897db9..c58ad95d12 100644
--- a/arch/arm/dts/rk3399-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
@@ -11,3 +11,7 @@
u-boot,spl-boot-order = "same-as-spl", , 
};
 };
+
+_log {
+   regulator-init-microvolt = <95>;
+};
-- 
2.25.1





RE: [PATCH 3/3] arm64: dts: imx8mm-beacon: Re-sync dts file with Linux 5.10-rc6

2020-12-06 Thread Peng Fan
> Subject: [PATCH 3/3] arm64: dts: imx8mm-beacon: Re-sync dts file with Linux
> 5.10-rc6
> 
> There have been some updates to the device trees, so re-sync.
> 
> Signed-off-by: Adam Ford 


Acked-by: Peng Fan 

> 
> diff --git a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
> b/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
> index baa5f997d0..d6b9dedd16 100644
> --- a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
> +++ b/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
> @@ -10,19 +10,19 @@
>   led0 {
>   label = "gen_led0";
>   gpios = <_1 4 GPIO_ACTIVE_HIGH>;
> - default-state = "none";
> + default-state = "off";
>   };
> 
>   led1 {
>   label = "gen_led1";
>   gpios = <_1 5 GPIO_ACTIVE_HIGH>;
> - default-state = "none";
> + default-state = "off";
>   };
> 
>   led2 {
>   label = "gen_led2";
>   gpios = <_1 6 GPIO_ACTIVE_HIGH>;
> - default-state = "none";
> + default-state = "off";
>   };
> 
>   led3 {
> @@ -70,7 +70,7 @@
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_espi2>;
> - cs-gpios = < 9 0>;
> + cs-gpios = < 9 GPIO_ACTIVE_LOW>;
>   status = "okay";
> 
>   eeprom@0 {
> @@ -210,7 +210,7 @@
>   >;
>   };
> 
> - pinctrl_pcal6414: pcal6414-gpio {
> + pinctrl_pcal6414: pcal6414-gpiogrp {
>   fsl,pins = <
>   MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27   0x19
>   >;
> @@ -240,7 +240,7 @@
>   >;
>   };
> 
> - pinctrl_usdhc2_gpio: usdhc2grpgpio {
> + pinctrl_usdhc2_gpio: usdhc2gpiogrp {
>   fsl,pins = <
>   MX8MM_IOMUXC_SD2_CD_B_USDHC2_CD_B   0x41
>   MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
> @@ -259,7 +259,7 @@
>   >;
>   };
> 
> - pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
>   fsl,pins = <
>   MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
>   MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
> @@ -271,7 +271,7 @@
>   >;
>   };
> 
> - pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
>   fsl,pins = <
>   MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
>   MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
> diff --git a/arch/arm/dts/imx8mm-beacon-som.dtsi
> b/arch/arm/dts/imx8mm-beacon-som.dtsi
> index 801bd02eae..b88c3c99b0 100644
> --- a/arch/arm/dts/imx8mm-beacon-som.dtsi
> +++ b/arch/arm/dts/imx8mm-beacon-som.dtsi
> @@ -24,6 +24,26 @@
>   cpu-supply = <_reg>;
>  };
> 
> + {
> + operating-points-v2 = <_opp_table>;
> +
> + ddrc_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-25M {
> + opp-hz = /bits/ 64 <2500>;
> + };
> +
> + opp-100M {
> + opp-hz = /bits/ 64 <1>;
> + };
> +
> + opp-750M {
> + opp-hz = /bits/ 64 <75000>;
> + };
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_fec1>;
> @@ -52,9 +72,10 @@
>   pmic@4b {
>   compatible = "rohm,bd71847";
>   reg = <0x4b>;
> + pinctrl-names = "default";
>   pinctrl-0 = <_pmic>;
>   interrupt-parent = <>;
> - interrupts = <3 GPIO_ACTIVE_LOW>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>   rohm,reset-snvs-powered;
> 
>   regulators {
> @@ -116,7 +137,7 @@
> 
>   ldo1_reg: LDO1 {
>   regulator-name = "ldo1";
> - regulator-min-microvolt = <300>;
> + regulator-min-microvolt = <160>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
>   regulator-always-on;
> @@ -124,7 +145,7 @@
> 
>   ldo2_reg: LDO2 {
>   regulator-name = "ldo2";
> - regulator-min-microvolt = <90>;
> + regulator-min-microvolt = <80>;
>   regulator-max-microvolt = <90>;
>   regulator-boot-on;
>   regulator-always-on;
> @@ -164,7 +185,7 @@
>   status = "okay";
> 
>   eeprom@50 {
> - compatible = "microchip, at24c64d", "atmel,24c64";
> + compatible = "microchip,24c64", "atmel,24c64";
>   pagesize = <32>;
>   read-only;  /* 

RE: [PATCH 2/3] arm: dts: imx8mm: sync dts from Linux Kernel 5.10-rc6

2020-12-06 Thread Peng Fan
> Subject: [PATCH 2/3] arm: dts: imx8mm: sync dts from Linux Kernel 5.10-rc6
> 
> There have been some updates to the device tree since 5.6.
> This also includes some clocks, and makes it easier to keep board device tree
> files in sync with Linux
> 
> Signed-off-by: Adam Ford 


Acked-by: Peng Fan 

> 
> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi index
> 1e5e11592f..05ee062548 100644
> --- a/arch/arm/dts/imx8mm.dtsi
> +++ b/arch/arm/dts/imx8mm.dtsi
> @@ -18,10 +18,18 @@
> 
>   aliases {
>   ethernet0 = 
> + gpio0 = 
> + gpio1 = 
> + gpio2 = 
> + gpio3 = 
> + gpio4 = 
>   i2c0 = 
>   i2c1 = 
>   i2c2 = 
>   i2c3 = 
> + mmc0 = 
> + mmc1 = 
> + mmc2 = 
>   serial0 = 
>   serial1 = 
>   serial2 = 
> @@ -29,14 +37,6 @@
>   spi0 = 
>   spi1 = 
>   spi2 = 
> - mmc0 = 
> - mmc1 = 
> - mmc2 = 
> - gpio0 = 
> - gpio1 = 
> - gpio2 = 
> - gpio3 = 
> - gpio4 = 
>   };
> 
>   cpus {
> @@ -68,6 +68,7 @@
>   nvmem-cells = <_speed_grade>;
>   nvmem-cell-names = "speed_grade";
>   cpu-idle-states = <_pd_wait>;
> + #cooling-cells = <2>;
>   };
> 
>   A53_1: cpu@1 {
> @@ -80,6 +81,7 @@
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> + #cooling-cells = <2>;
>   };
> 
>   A53_2: cpu@2 {
> @@ -92,6 +94,7 @@
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> + #cooling-cells = <2>;
>   };
> 
>   A53_3: cpu@3 {
> @@ -104,6 +107,7 @@
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> + #cooling-cells = <2>;
>   };
> 
>   A53_L2: l2-cache0 {
> @@ -125,7 +129,7 @@
> 
>   opp-16 {
>   opp-hz = /bits/ 64 <16>;
> - opp-microvolt = <90>;
> + opp-microvolt = <95>;
>   opp-supported-hw = <0xc>, <0x7>;
>   clock-latency-ns = <15>;
>   opp-suspend;
> @@ -204,6 +208,38 @@
>   arm,no-tick-in-suspend;
>   };
> 
> + thermal-zones {
> + cpu-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = <>;
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit0: trip1 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <_alert0>;
> + cooling-device =
> + <_0 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + <_1 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + <_2 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> + <_3 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> + };
> +
>   usbphynop1: usbphynop1 {
>   compatible = "usb-nop-xceiv";
>   clocks = < IMX8MM_CLK_USB_PHY_REF>; @@ -227,12
> +263,14 @@
>   ranges = <0x0 0x0 0x0 0x3e00>;
> 
>   aips1: bus@3000 {
> - compatible = "simple-bus";
> + compatible = "fsl,aips-bus", "simple-bus";
> + reg = <0x3000 0x40>;
>   #address-cells = <1>;
>   #size-cells = <1>;
>   ranges = <0x3000 0x3000 0x40>;
> 
>   sai1: sai@3001 {
> + #sound-dai-cells = <0>;
>   compatible 

RE: [PATCH 1/3] imx: imx8mm: Update clock bindings header

2020-12-06 Thread Peng Fan
> Subject: [PATCH 1/3] imx: imx8mm: Update clock bindings header
> 
> Import clock bindings header file from Linux 5.10-rc6
> 
> Signed-off-by: Adam Ford 

Acked-by: Peng Fan 

> 
> diff --git a/include/dt-bindings/clock/imx8mm-clock.h
> b/include/dt-bindings/clock/imx8mm-clock.h
> index 07e6c686f3..e63a5530ae 100644
> --- a/include/dt-bindings/clock/imx8mm-clock.h
> +++ b/include/dt-bindings/clock/imx8mm-clock.h
> @@ -248,6 +248,32 @@
>  #define IMX8MM_CLK_SNVS_ROOT 228
>  #define IMX8MM_CLK_GIC   229
> 
> -#define IMX8MM_CLK_END   230
> +#define IMX8MM_SYS_PLL1_40M_CG   230
> +#define IMX8MM_SYS_PLL1_80M_CG   231
> +#define IMX8MM_SYS_PLL1_100M_CG  232
> +#define IMX8MM_SYS_PLL1_133M_CG  233
> +#define IMX8MM_SYS_PLL1_160M_CG  234
> +#define IMX8MM_SYS_PLL1_200M_CG  235
> +#define IMX8MM_SYS_PLL1_266M_CG  236
> +#define IMX8MM_SYS_PLL1_400M_CG  237
> +#define IMX8MM_SYS_PLL2_50M_CG   238
> +#define IMX8MM_SYS_PLL2_100M_CG  239
> +#define IMX8MM_SYS_PLL2_125M_CG  240
> +#define IMX8MM_SYS_PLL2_166M_CG  241
> +#define IMX8MM_SYS_PLL2_200M_CG  242
> +#define IMX8MM_SYS_PLL2_250M_CG  243
> +#define IMX8MM_SYS_PLL2_333M_CG  244
> +#define IMX8MM_SYS_PLL2_500M_CG  245
> +
> +#define IMX8MM_CLK_M4_CORE   246
> +#define IMX8MM_CLK_VPU_CORE  247
> +#define IMX8MM_CLK_GPU3D_CORE248
> +#define IMX8MM_CLK_GPU2D_CORE249
> +
> +#define IMX8MM_CLK_CLKO2 250
> +
> +#define IMX8MM_CLK_A53_CORE  251
> +
> +#define IMX8MM_CLK_END   252
> 
>  #endif
> --
> 2.25.1



[PATCH 2/4] ARM: mvebu: helios4 dts changes to enable SPI

2020-12-06 Thread dgilmore
From: Dennis Gilmore 

mirror seettings for the clearfog on the helios4 to get SPI working.

Signed-off-by: Dennis Gilmore 
---
 arch/arm/dts/armada-388-helios4-u-boot.dtsi | 22 ++
 arch/arm/dts/armada-388-helios4.dts | 46 -
 2 files changed, 58 insertions(+), 10 deletions(-)

diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi 
b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
index 0753889854..82513a1ce7 100644
--- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
@@ -1,13 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0+
 
-/ {
-   aliases {
-   i2c0 = 
-   i2c1 = 
-   spi1 = 
-   };
-};
-
  {
phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
 };
@@ -37,5 +29,17 @@
 };
 
  {
-   u-boot,dm-spl;
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+
+   eeprom@52 {
+   u-boot,dm-spl;
+   };
+
+   eeprom@53 {
+   u-boot,dm-spl;
+   };
 };
diff --git a/arch/arm/dts/armada-388-helios4.dts 
b/arch/arm/dts/armada-388-helios4.dts
index fb49df2a3b..e948b94090 100644
--- a/arch/arm/dts/armada-388-helios4.dts
+++ b/arch/arm/dts/armada-388-helios4.dts
@@ -22,10 +22,14 @@
};
 
aliases {
-   /* So that mvebu u-boot can update the MAC addresses */
+   /* So that mvebu u-boot can update the MAC address */
ethernet1 = 
+   spi1 = 
+   i2c0 = 
+   i2c1 = 
};
 
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -306,3 +310,43 @@
};
};
 };
+
+ {
+   helios4_spi1_cs_pins: spi1-cs-pins {
+   marvell,pins = "mpp55";
+   marvell,function = "spi1";
+   };
+   mikro_pins: mikro-pins {
+   /* int: mpp22 rst: mpp29 */
+   marvell,pins = "mpp22", "mpp29";
+   marvell,function = "gpio";
+   };
+   mikro_spi_pins: mikro-spi-pins {
+   marvell,pins = "mpp43";
+   marvell,function = "spi1";
+   };
+   mikro_uart_pins: mikro-uart-pins {
+   marvell,pins = "mpp24", "mpp25";
+   marvell,function = "ua1";
+   };
+   rear_button_pins: rear-button-pins {
+   marvell,pins = "mpp34";
+   marvell,function = "gpio";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   /*
+* Add SPI CS pins for helios4:
+* CS0: W25Q32
+* CS1:
+* CS2: mikrobus
+*/
+   pinctrl-0 = <_pins _spi_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
2.28.0



[PATCH 3/4] ARM: mvebu: ClearFog make sure that SATA and UART images are buildable

2020-12-06 Thread dgilmore
From: Dennis Gilmore 

SATA and UART ClearFog imaages are not buildable as ENV_SECT_SIZE is not defined
set values for both possible targets

Signed-off-by: Dennis Gilmore 
---
 board/solidrun/clearfog/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index e8c3f53d84..cf95258090 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -50,9 +50,9 @@ config ENV_OFFSET
 config ENV_SECT_SIZE
hex "Environment Sector-Size"
# Use SPI flash erase block size of 4 KiB
-   default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
+   default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI || 
MVEBU_SPL_BOOT_DEVICE_SATA
# Use optimistic 64 KiB erase block, will vary between actual media
-   default 0x1 if MVEBU_SPL_BOOT_DEVICE_MMC
+   default 0x1 if MVEBU_SPL_BOOT_DEVICE_MMC || 
MVEBU_SPL_BOOT_DEVICE_UART
 
 config SYS_SPI_U_BOOT_OFFS
hex "address of u-boot payload in SPI flash"
-- 
2.28.0



[PATCH 4/4] ARM: mvebu: fixup building a SPI image for db-mv784mp-gp

2020-12-06 Thread dgilmore
From: Dennis Gilmore 

sync config options from clearfog to db-mv784mp-gp to enable
building a SPI image

Signed-off-by: Dennis Gilmore 
---
 include/configs/db-mv784mp-gp.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/configs/db-mv784mp-gp.h b/include/configs/db-mv784mp-gp.h
index 3e20516e94..79ee5909d5 100644
--- a/include/configs/db-mv784mp-gp.h
+++ b/include/configs/db-mv784mp-gp.h
@@ -78,8 +78,17 @@
 #define CONFIG_SPL_STACK   (0x4000 + ((192 - 16) << 10))
 #define CONFIG_SPL_BOOTROM_SAVE(CONFIG_SPL_STACK + 4)
 
+#if defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI)
 /* SPL related SPI defines */
-#define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_SPI_U_BOOT_OFFS
+#define CONFIG_SYS_U_BOOT_OFFS  CONFIG_SYS_SPI_U_BOOT_OFFS
+#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC) || 
defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA)
+/* SPL related MMC defines */
+#define CONFIG_SYS_MMC_U_BOOT_OFFS  (160 << 10)
+#define CONFIG_SYS_U_BOOT_OFFS  CONFIG_SYS_MMC_U_BOOT_OFFS
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_FIXED_SDHCI_ALIGNED_BUFFER   0x0018  /* in SDRAM */
+#endif
+#endif
 
 /* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
 #define CONFIG_SPD_EEPROM  0x4e
-- 
2.28.0



[PATCH 1/4] ARM: mvebu: helios4 adjust env sizes to enable SPI to work

2020-12-06 Thread dgilmore
From: Dennis Gilmore 

mirror the clearfog setup to enable SPI to work

Signed-off-by: Dennis Gilmore 
---
 arch/arm/mach-mvebu/Kconfig |  1 +
 board/kobol/helios4/Kconfig | 24 
 configs/helios4_defconfig   |  2 --
 3 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 board/kobol/helios4/Kconfig

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 0d8e0922a2..66fd771dff 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -293,5 +293,6 @@ config SECURED_MODE_CSK_INDEX
depends on SECURED_MODE_IMAGE
 
 source "board/solidrun/clearfog/Kconfig"
+source "board/kobol/helios4/Kconfig"
 
 endif
diff --git a/board/kobol/helios4/Kconfig b/board/kobol/helios4/Kconfig
new file mode 100644
index 00..cad51c1cf0
--- /dev/null
+++ b/board/kobol/helios4/Kconfig
@@ -0,0 +1,24 @@
+menu "Helios4 configuration"
+   depends on TARGET_HELIOS4
+
+config ENV_SIZE
+   hex "Environment Size"
+   default 0x1
+
+config ENV_OFFSET
+   hex "Environment offset"
+   default 0xF
+
+config ENV_SECT_SIZE
+   hex "Environment Sector-Size"
+   # Use SPI or SATA flash erase block size of 4 KiB
+   default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI || 
MVEBU_SPL_BOOT_DEVICE_SATA
+   # Use optimistic 64 KiB erase block, will vary between actual media
+   default 0x1 if MVEBU_SPL_BOOT_DEVICE_MMC || 
MVEBU_SPL_BOOT_DEVICE_UART
+
+config SYS_SPI_U_BOOT_OFFS
+   hex "address of u-boot payload in SPI flash"
+   default 0x2
+   depends on MVEBU_SPL_BOOT_DEVICE_SPI
+
+endmenu
diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
index eceb85f082..bdc6f43554 100644
--- a/configs/helios4_defconfig
+++ b/configs/helios4_defconfig
@@ -9,8 +9,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_HELIOS4=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
-CONFIG_ENV_SIZE=0x2000
-CONFIG_ENV_OFFSET=0xFE000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_TEXT_BASE=0x4030
 CONFIG_SPL_SERIAL_SUPPORT=y
-- 
2.28.0



Re: [PATCH v3 1/2] arm: dts: add imx8mm-cl-iot-gate dts file

2020-12-06 Thread Peter Robinson
On Sun, Dec 6, 2020 at 7:43 PM Ying-Chun Liu  wrote:
>
> From: "Ying-Chun Liu (PaulLiu)" 
>
> Add board dts for imx8mm-cl-iot-gate
>
> Signed-off-by: Kirill Kapranov 
> Signed-off-by: Uri Mashiach 
> Signed-off-by: Valentin Raevsky 
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> Cc: Peter Robinson 
> ---

What's changed since the last version. You should put a change log at
this point.

>  arch/arm/dts/Makefile   |   2 +
>  arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 131 +
>  arch/arm/dts/imx8mm-cl-iot-gate.dts | 550 
>  3 files changed, 683 insertions(+)
>  create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e2e8a5fb7a..d00ecb88e0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1003,6 +1003,8 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
>
>  dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
>
> +dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
> +
>  targets += $(dtb-y)
>
>  # Add any required device tree compiler flags here
> diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> new file mode 100644
> index 00..a36147eb11
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/ {
> +   wdt-reboot {
> +   compatible = "wdt-reboot";
> +   wdt = <>;
> +   u-boot,dm-spl;
> +   };
> +};
> +
> +&{/soc@0} {
> +   u-boot,dm-pre-reloc;
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +   u-boot,dm-pre-reloc;
> +   /delete-property/ assigned-clocks;
> +   /delete-property/ assigned-clock-parents;
> +   /delete-property/ assigned-clock-rates;
> +};
> +
> +_24m {
> +   u-boot,dm-spl;
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> +_reg_usdhc2_vmmc {
> +   u-boot,dm-spl;
> +};
> +
> +_uart3 {
> +   u-boot,dm-spl;
> +};
> +
> +_usdhc2_gpio {
> +   u-boot,dm-spl;
> +};
> +
> +_usdhc2 {
> +   u-boot,dm-spl;
> +};
> +
> +_usdhc3 {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
> +   u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
> +   u-boot,dm-spl;
> +};
> +
> +_i2c2 {
> +   u-boot,dm-spl;
> +};
> +
> +_pmic {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx8mm-cl-iot-gate.dts 
> b/arch/arm/dts/imx8mm-cl-iot-gate.dts
> new file mode 100644
> index 00..82e9c0f40b
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate.dts
> @@ -0,0 +1,550 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "imx8mm.dtsi"
> +
> +/ {
> +   model = "CompuLab IOT-GATE-iMX8";
> +   compatible = "sb-iotgimx8", "cpl,ucm-imx8m-mini", "fsl,imx8mm-evk", 
> "fsl,imx8mm";
> +
> +   chosen {
> +   bootargs = "console=ttymxc2,115200 
> earlycon=ec_imx6q,0x3088,115200";
> +   stdout-path = 
> +   };
> +
> +   reg_vusb_5v: regulator-usdhc2 {
> +   compatible = "regulator-fixed";
> +   regulator-name = "VUSB_5V";
> +   regulator-min-microvolt = <500>;
> +   regulator-max-microvolt = <500>;
> +   gpio = < 28 GPIO_ACTIVE_HIGH>;
> +   regulator-boot-on;
> +   enable-active-high;
> +   };
> +
> +   reg_usdhc2_vqmmc: regulator-usdhc2_1v8 {
> +   compatible = "regulator-fixed";
> +   regulator-name = "usdhc2_1v8";
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   regulator-always-on;
> +   };
> +
> +   reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
> +   compatible = "regulator-fixed";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_reg_usdhc2_vmmc>;
> +   regulator-name = "VSD_3V3";
> +   regulator-min-microvolt = <330>;
> +  

Re: [PATCH 29/34] configs: sama7g5: add mmc config for sdmmc0

2020-12-06 Thread Jaehoon Chung
On 12/4/20 4:00 PM, eugen.hris...@microchip.com wrote:
> On 03.12.2020 23:45, Jaehoon Chung wrote:
>> Hi,
>>
>> On 12/3/20 8:20 PM, eugen.hris...@microchip.com wrote:
>>> On 03.12.2020 13:11, Jaehoon Chung wrote:
 EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
 content is safe

 On 12/3/20 7:47 PM, eugen.hris...@microchip.com wrote:
> On 03.12.2020 12:38, Jaehoon Chung wrote:
>> Hi,
>>
>> On 12/3/20 6:28 PM, Eugen Hristev wrote:
>>> Add new config for storing environment from sdmmc0.
>>> Also clean-up sama7g5ek_emmc1 to point to the proper mmc device.
>>
>> Just one question, Sorry, i didn't check entire patchset.
>>
>> What is different between sama7g5ek_mmc1 and sama7g5ek_mmc?
>
> Sama7g5ek_mmc is set to store the environment in the eMMC device
> soldered on the board which is connected on the SDMMC0 hardware block.
>
> sama7g5ek_mmc1 is set to store the environment on the SD-Card which can
> be inserted in the SD slot on the board which is connected on the SDMMC1
> hardware block.
>
> So basically we have two possible boot/env store configurations, one on
> eMMC and one on SD-Card .

 If device can know which device is used to boot, then i think that it 
 doesn't need to add one more config.
 It can know where env is stored at runtime.
 (with CONFIG_ENV_FAT_DEVICE_AND_PART ":" and implement 
 mmc_get_env_dev())

>>>
>>> Can you explain a little more ? I do not understand how.
>>> How will u-boot know if it should read the env from SD or eMMC ?
>>
>> I don't have any knowledge of your SoC. Maybe you know more exactly.
>> If its SoC has some registers to get boot device, it's possible to get which 
>> device is used to boot device.
> 
> It does, but U-boot is not the first stage bootloader. We have a second 
> stage that initializes the external RAM first.
> U-boot is in fact the third stage.

It doesn't matter which stage is used. It's dependent with your register.
If your bl0 is checking which device is used, it can be set to register.
- I don't know how to implement your bl0..so it's just guessing.

> 
>> Then you can implement mmc_get_env_dev() in its board specific file.
>> Then it can be got with below sequence.
>> In env/f
>> env_fat_devc_and_part()
>> -> part_str[0] += mmc_get_env_dev()
>> -> mmc_get_env_dev() will be returned to proper device after read register 
>> relevant to checking device.
>>
>> If there is no register to get boot device, it may be impossible.
> 
> Even if we know the boot device, we do not wish do enforce u-boot to 
> store the env on the same boot device. This would mean hard rules on 
> storing the env, which is something we wish to avoid.

I understood what you want. 
As i already mentioned, i didn't check this patchset fully. 
Just it seemed taht your configuration is duplicated, except env location.
I don't have any objection about your patch. :)
Just had a question whether it can be used one config or not.

Thanks for explanation kindly.

Best Regards,
Jaehoon Chung

> We would like to be able to select at compile time where to store the 
> env and the default boot device. This would allow for example to have a 
> very fast and small QSPI memory for storing the initial stages , but 
> have u-boot load linux and store the env from/on eMMCs or SD-Cards.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>
>>>

 commit 6731bef6966ea2b26cdcfe0109ff5a950003fd03
 Refs: v2020.07-1080-g6731bef696
 Author: David Woodhouse 
 AuthorDate: Fri Jun 19 23:07:17 2020 +0100
 Commit: Tom Rini 
 CommitDate: Sun Jul 26 14:35:12 2020 -0400

   env/fat.c: allow loading from a FAT partition on the MMC boot device

   I don't want to have to specify the device; only the partition.

   This allows me to use the same image on internal eMMC or SD card for
   Banana Pi R2, and it finds its own environment either way.

   Signed-off-by: David Woodhouse 
   [trini: Add #if/#else/#endif logic around CONFIG_SYS_MMC_ENV_DEV 
 usage,
   whitespace changes]
   Signed-off-by: Tom Rini 


 Best Regards,
 Jaehoon Chung

>
> Eugen
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Signed-off-by: Eugen Hristev 
>>> ---
>>> board/atmel/sama7g5ek/MAINTAINERS |  1 +
>>> configs/sama7g5ek_mmc1_defconfig  |  7 ++--
>>> configs/sama7g5ek_mmc_defconfig   | 67 
>>> +++
>>> 3 files changed, 72 insertions(+), 3 deletions(-)
>>> create mode 100644 configs/sama7g5ek_mmc_defconfig
>>>
>>> diff --git a/board/atmel/sama7g5ek/MAINTAINERS 
>>> b/board/atmel/sama7g5ek/MAINTAINERS
>>> index f66953ac4e..eac972968d 100644
>>> --- a/board/atmel/sama7g5ek/MAINTAINERS
>>> +++ b/board/atmel/sama7g5ek/MAINTAINERS

[PATCH 6/6] test: dm: spi: Add testcase for spi_claim_bus()

2020-12-06 Thread Ovidiu Panait
Add testcase for spi_claim_bus(), which checks that sandbox spi bus
speed/mode settings are updated correctly when multiple slaves use
the bus consecutively. The following configurations are used for the
two spi slaves involved:
  * different max_hz / different modes
  * different max_hz / same modes
  * different modes / same max_hz

asm/test.h header is added in order to be able to retrieve the current
speed/mode of the sandbox spi bus, via sandbox_spi_get_{speed, mode}.

Signed-off-by: Ovidiu Panait 

---

 test/dm/spi.c | 82 +++
 1 file changed, 82 insertions(+)

diff --git a/test/dm/spi.c b/test/dm/spi.c
index 6db680edd2..65093f6907 100644
--- a/test/dm/spi.c
+++ b/test/dm/spi.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,87 @@ static int dm_test_spi_find(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_spi_find, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
 
+/* dm_test_spi_switch_slaves - Helper function to check whether spi_claim_bus
+ * operates correctly with two spi slaves.
+ *
+ * Check that switching back and forth between two slaves claiming the bus
+ * will update dm_spi_bus->speed and sandbox_spi bus speed/mode correctly.
+ *
+ * @uts - unit test state
+ * @slave_a - first spi slave used for testing
+ * @slave_b - second spi slave used for testing
+ */
+static int dm_test_spi_switch_slaves(struct unit_test_state *uts,
+struct spi_slave *slave_a,
+struct spi_slave *slave_b)
+{
+   struct udevice *bus;
+   struct dm_spi_bus *bus_data;
+
+   /* Check that slaves are on the same bus */
+   ut_asserteq_ptr(dev_get_parent(slave_a->dev),
+   dev_get_parent(slave_b->dev));
+
+   bus = dev_get_parent(slave_a->dev);
+   bus_data = dev_get_uclass_priv(bus);
+
+   ut_assertok(spi_claim_bus(slave_a));
+   ut_asserteq(slave_a->max_hz, bus_data->speed);
+   ut_asserteq(slave_a->max_hz, sandbox_spi_get_speed(bus));
+   ut_asserteq(slave_a->mode, sandbox_spi_get_mode(bus));
+   spi_release_bus(slave_a);
+
+   ut_assertok(spi_claim_bus(slave_b));
+   ut_asserteq(slave_b->max_hz, bus_data->speed);
+   ut_asserteq(slave_b->max_hz, sandbox_spi_get_speed(bus));
+   ut_asserteq(slave_b->mode, sandbox_spi_get_mode(bus));
+   spi_release_bus(slave_b);
+
+   ut_assertok(spi_claim_bus(slave_a));
+   ut_asserteq(slave_a->max_hz, bus_data->speed);
+   ut_asserteq(slave_a->max_hz, sandbox_spi_get_speed(bus));
+   ut_asserteq(slave_a->mode, sandbox_spi_get_mode(bus));
+   spi_release_bus(slave_a);
+
+   return 0;
+}
+
+static int dm_test_spi_claim_bus(struct unit_test_state *uts)
+{
+   struct udevice *bus;
+   struct spi_slave *slave_a, *slave_b;
+   struct dm_spi_slave_platdata *slave_plat;
+   const int busnum = 0, cs_a = 0, cs_b = 1, mode = 0;
+
+   /* Get spi slave on CS0 */
+   ut_assertok(spi_get_bus_and_cs(busnum, cs_a, 100, mode, NULL, 0,
+  , _a));
+   /* Get spi slave on CS1 */
+   ut_assertok(spi_get_bus_and_cs(busnum, cs_b, 100, mode, NULL, 0,
+  , _b));
+
+   /* Different max_hz, different mode. */
+   ut_assert(slave_a->max_hz != slave_b->max_hz);
+   ut_assert(slave_a->mode != slave_b->mode);
+   dm_test_spi_switch_slaves(uts, slave_a, slave_b);
+
+   /* Different max_hz, same mode. */
+   slave_a->mode = slave_b->mode;
+   dm_test_spi_switch_slaves(uts, slave_a, slave_b);
+
+   /*
+* Same max_hz, different mode.
+* Restore original mode for slave_a, from platdata.
+*/
+   slave_plat = dev_get_parent_platdata(slave_a->dev);
+   slave_a->mode = slave_plat->max_hz;
+   slave_a->max_hz = slave_b->max_hz;
+   dm_test_spi_switch_slaves(uts, slave_a, slave_b);
+
+   return 0;
+}
+DM_TEST(dm_test_spi_claim_bus, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
 /* Test that sandbox SPI works correctly */
 static int dm_test_spi_xfer(struct unit_test_state *uts)
 {
-- 
2.17.1



[PATCH 5/6] spi: spi-uclass: Fix spi_claim_bus() speed/mode setup logic

2020-12-06 Thread Ovidiu Panait
Currently, when different spi slaves claim the bus consecutively using
spi_claim_bus(), spi_set_speed_mode() will only be executed on the first
two calls, leaving the bus in a bad state starting with the third call.

This patch drops spi_slave->speed member and adds caching of bus
speed/mode in dm_spi_bus struct. It also updates spi_claim_bus() to call
spi_set_speed_mode() if either speed or mode is different from what the
bus is currently configured for. Current behavior is to only take into
account the speed, but not the mode, which seems wrong.

Fixes: 60e2809a848 ("dm: spi: Avoid setting the speed with every transfer")
Reported-by: Rasmus Villemoes 
Reported-by: Moshe, Yaniv 
Signed-off-by: Ovidiu Panait 
---

 drivers/mmc/mmc_spi.c|  1 -
 drivers/spi/spi-uclass.c | 17 -
 include/spi.h| 18 ++
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 50fcd32674..793e3c8cfa 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -418,7 +418,6 @@ static int mmc_spi_probe(struct udevice *dev)
priv->spi = dev_get_parent_priv(dev);
if (!priv->spi->max_hz)
priv->spi->max_hz = MMC_SPI_MAX_CLOCK;
-   priv->spi->speed = 0;
priv->spi->mode = SPI_MODE_0;
priv->spi->wordlen = 8;
 
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 55a8eed890..4bd2adeb58 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -51,23 +51,28 @@ int dm_spi_claim_bus(struct udevice *dev)
struct dm_spi_ops *ops = spi_get_ops(bus);
struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
struct spi_slave *slave = dev_get_parent_priv(dev);
-   int speed;
+   uint speed, mode;
 
speed = slave->max_hz;
+   mode = slave->mode;
+
if (spi->max_hz) {
if (speed)
-   speed = min(speed, (int)spi->max_hz);
+   speed = min(speed, spi->max_hz);
else
speed = spi->max_hz;
}
if (!speed)
speed = SPI_DEFAULT_SPEED_HZ;
-   if (speed != slave->speed) {
+
+   if (speed != spi->speed || mode != spi->mode) {
int ret = spi_set_speed_mode(bus, speed, slave->mode);
 
if (ret)
return log_ret(ret);
-   slave->speed = speed;
+
+   spi->speed = speed;
+   spi->mode = mode;
}
 
return log_ret(ops->claim_bus ? ops->claim_bus(dev) : 0);
@@ -324,6 +329,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
 {
struct udevice *bus, *dev;
struct dm_spi_slave_platdata *plat;
+   struct dm_spi_bus *bus_data;
struct spi_slave *slave;
bool created = false;
int ret;
@@ -381,12 +387,13 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
}
 
slave = dev_get_parent_priv(dev);
+   bus_data = dev_get_uclass_priv(bus);
 
/*
 * In case the operation speed is not yet established by
 * dm_spi_claim_bus() ensure the bus is configured properly.
 */
-   if (!slave->speed) {
+   if (!bus_data->speed) {
ret = spi_claim_bus(slave);
if (ret)
goto err;
diff --git a/include/spi.h b/include/spi.h
index ef8c1f6692..7efced7057 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -39,9 +39,22 @@
 
 #define SPI_DEFAULT_WORDLEN8
 
-/* TODO(s...@chromium.org): Remove this and use max_hz from struct spi_slave */
+/**
+ * struct dm_spi_bus - SPI bus info
+ *
+ * This contains information about a SPI bus. To obtain this structure, use
+ * dev_get_uclass_priv(bus) where bus is the SPI bus udevice.
+ *
+ * @max_hz:Maximum speed that the bus can tolerate.
+ * @speed: Current bus speed. This is 0 until the bus is first claimed.
+ * @mode:  Current bus mode. This is 0 until the bus is first claimed.
+ *
+ * TODO(s...@chromium.org): Remove this and use max_hz from struct spi_slave.
+ */
 struct dm_spi_bus {
uint max_hz;
+   uint speed;
+   uint mode;
 };
 
 /**
@@ -112,8 +125,6 @@ enum spi_polarity {
  *
  * @dev:   SPI slave device
  * @max_hz:Maximum speed for this slave
- * @speed: Current bus speed. This is 0 until the bus is first
- * claimed.
  * @bus:   ID of the bus that the slave is attached to. For
  * driver model this is the sequence number of the SPI
  * bus (bus->seq) so does not need to be stored
@@ -131,7 +142,6 @@ struct spi_slave {
 #if CONFIG_IS_ENABLED(DM_SPI)
struct udevice *dev;/* struct spi_slave is dev->parentdata */
uint max_hz;
-   uint speed;
 #else
unsigned int bus;
unsigned int cs;
-- 
2.17.1



[PATCH 4/6] test: spi: Add sandbox_spi_get_{speed, mode} interface

2020-12-06 Thread Ovidiu Panait
Introduce sandbox_spi_get_{speed, mode} public interface to retrieve the
sandbox spi bus internal state. They are meant to be used in sandbox spi
testcases.

Signed-off-by: Ovidiu Panait 
---

 arch/sandbox/include/asm/test.h | 16 
 drivers/spi/sandbox_spi.c   | 14 ++
 2 files changed, 30 insertions(+)

diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
index 7f99d07c47..05f66f700c 100644
--- a/arch/sandbox/include/asm/test.h
+++ b/arch/sandbox/include/asm/test.h
@@ -202,6 +202,22 @@ void sandbox_set_allow_beep(struct udevice *dev, bool 
allow);
  */
 int sandbox_get_beep_frequency(struct udevice *dev);
 
+/**
+ * sandbox_spi_get_speed() - Get current speed setting of a sandbox spi bus
+ *
+ * @dev: Device to check
+ * @return current bus speed
+ */
+uint sandbox_spi_get_speed(struct udevice *dev);
+
+/**
+ * sandbox_spi_get_mode() - Get current mode setting of a sandbox spi bus
+ *
+ * @dev: Device to check
+ * @return current mode
+ */
+uint sandbox_spi_get_mode(struct udevice *dev);
+
 /**
  * sandbox_get_pch_spi_protect() - Get the PCI SPI protection status
  *
diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
index 72f22d066f..cbe8d62681 100644
--- a/drivers/spi/sandbox_spi.c
+++ b/drivers/spi/sandbox_spi.c
@@ -52,6 +52,20 @@ __weak int sandbox_spi_get_emul(struct sandbox_state *state,
return -ENOENT;
 }
 
+uint sandbox_spi_get_speed(struct udevice *dev)
+{
+   struct sandbox_spi_priv *priv = dev_get_priv(dev);
+
+   return priv->speed;
+}
+
+uint sandbox_spi_get_mode(struct udevice *dev)
+{
+   struct sandbox_spi_priv *priv = dev_get_priv(dev);
+
+   return priv->mode;
+}
+
 static int sandbox_spi_xfer(struct udevice *slave, unsigned int bitlen,
const void *dout, void *din, unsigned long flags)
 {
-- 
2.17.1



[PATCH 3/6] spi: sandbox_spi: Implement speed/mode setup

2020-12-06 Thread Ovidiu Panait
Implement sandbox_spi_set_{speed, mode} routines, to be able to keep track
of the current bus speed/mode. This will help determine whether the values
passed from dm_spi_claim_bus() are valid.

Signed-off-by: Ovidiu Panait 
---

 drivers/spi/sandbox_spi.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
index 412756aa4b..72f22d066f 100644
--- a/drivers/spi/sandbox_spi.c
+++ b/drivers/spi/sandbox_spi.c
@@ -28,6 +28,23 @@
 # define CONFIG_SPI_IDLE_VAL 0xFF
 #endif
 
+/**
+ * struct sandbox_spi_priv - Sandbox SPI private data
+ *
+ * Helper struct to keep track of the sandbox SPI bus internal state. It is
+ * used in unit tests to verify that dm spi functions update the bus
+ * speed/mode properly (for instance, when jumping back and forth between spi
+ * slaves claiming the bus, we need to make sure that the bus speed is updated
+ * accordingly for each slave).
+ *
+ * @speed: Current bus speed.
+ * @mode:  Current bus mode.
+ */
+struct sandbox_spi_priv {
+   uint speed;
+   uint mode;
+};
+
 __weak int sandbox_spi_get_emul(struct sandbox_state *state,
struct udevice *bus, struct udevice *slave,
struct udevice **emulp)
@@ -90,11 +107,19 @@ static int sandbox_spi_xfer(struct udevice *slave, 
unsigned int bitlen,
 
 static int sandbox_spi_set_speed(struct udevice *bus, uint speed)
 {
+   struct sandbox_spi_priv *priv = dev_get_priv(bus);
+
+   priv->speed = speed;
+
return 0;
 }
 
 static int sandbox_spi_set_mode(struct udevice *bus, uint mode)
 {
+   struct sandbox_spi_priv *priv = dev_get_priv(bus);
+
+   priv->mode = mode;
+
return 0;
 }
 
@@ -136,4 +161,5 @@ U_BOOT_DRIVER(sandbox_spi) = {
.id = UCLASS_SPI,
.of_match = sandbox_spi_ids,
.ops= _spi_ops,
+   .priv_auto_alloc_size = sizeof(struct sandbox_spi_priv),
 };
-- 
2.17.1



[PATCH 2/6] sandbox: test: Add a second SPI slave on sandbox_spi bus

2020-12-06 Thread Ovidiu Panait
Place a second spi slave on the sandbox_spi bus, to be used by the
spi_claim_bus() testcase we are about to introduce. We need to make sure
that jumping between slaves calling spi_claim_bus() sets the bus speed and
mode appropriately. Use different max-hz and mode properties for this new
slave.

Also, update sandbox_spi cs_info call to allow activity on CS0/CS1 and
adapt dm_test_spi_find() testcase for this new setup.

Signed-off-by: Ovidiu Panait 
---

 arch/sandbox/dts/test.dts | 10 +-
 drivers/spi/sandbox_spi.c |  4 ++--
 test/dm/spi.c |  2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f3b766271d..3eca1a73de 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -864,13 +864,21 @@
#size-cells = <0>;
reg = <0 1>;
compatible = "sandbox,spi";
-   cs-gpios = <0>, <_a 0>;
+   cs-gpios = <0>, <0>, <_a 0>;
spi.bin@0 {
reg = <0>;
compatible = "spansion,m25p16", "jedec,spi-nor";
spi-max-frequency = <4000>;
sandbox,filename = "spi.bin";
};
+   spi.bin@1 {
+   reg = <1>;
+   compatible = "spansion,m25p16", "jedec,spi-nor";
+   spi-max-frequency = <5000>;
+   sandbox,filename = "spi.bin";
+   spi-cpol;
+   spi-cpha;
+   };
};
 
syscon0: syscon@0 {
diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
index 3640ddeeb6..412756aa4b 100644
--- a/drivers/spi/sandbox_spi.c
+++ b/drivers/spi/sandbox_spi.c
@@ -101,8 +101,8 @@ static int sandbox_spi_set_mode(struct udevice *bus, uint 
mode)
 static int sandbox_cs_info(struct udevice *bus, uint cs,
   struct spi_cs_info *info)
 {
-   /* Always allow activity on CS 0 */
-   if (cs >= 1)
+   /* Always allow activity on CS 0, CS 1 */
+   if (cs >= 2)
return -EINVAL;
 
return 0;
diff --git a/test/dm/spi.c b/test/dm/spi.c
index fb180aed1f..6db680edd2 100644
--- a/test/dm/spi.c
+++ b/test/dm/spi.c
@@ -22,7 +22,7 @@ static int dm_test_spi_find(struct unit_test_state *uts)
struct sandbox_state *state = state_get_current();
struct spi_slave *slave;
struct udevice *bus, *dev;
-   const int busnum = 0, cs = 0, mode = 0, speed = 100, cs_b = 1;
+   const int busnum = 0, cs = 0, mode = 0, speed = 100, cs_b = 2;
struct spi_cs_info info;
ofnode node;
 
-- 
2.17.1



[PATCH 1/6] sandbox: spi: Drop unused sandbox_spi_parse_spec function

2020-12-06 Thread Ovidiu Panait
Commit 1289e96797bf ("sandbox: spi: Drop command-line SPI option") dropped
support for specifying SPI devices on the command line, removing the only
user of sandbox_spi_parse_spec(). Remove the function too.

Fixes: 1289e96797bf ("sandbox: spi: Drop command-line SPI option")
Signed-off-by: Ovidiu Panait 
---

 arch/sandbox/include/asm/spi.h | 10 --
 drivers/spi/sandbox_spi.c  | 16 
 2 files changed, 26 deletions(-)

diff --git a/arch/sandbox/include/asm/spi.h b/arch/sandbox/include/asm/spi.h
index 98e1826e2c..e8268bbe07 100644
--- a/arch/sandbox/include/asm/spi.h
+++ b/arch/sandbox/include/asm/spi.h
@@ -32,14 +32,4 @@ struct sandbox_spi_emu_ops {
int (*xfer)(void *priv, const u8 *rx, u8 *tx, uint bytes);
 };
 
-/*
- * Extract the bus/cs from the spi spec and return the start of the spi
- * client spec.  If the bus/cs are invalid for the current config, then
- * it returns NULL.
- *
- * Example: arg="0:1:foo" will set bus to 0, cs to 1, and return "foo"
- */
-const char *sandbox_spi_parse_spec(const char *arg, unsigned long *bus,
-  unsigned long *cs);
-
 #endif
diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
index 755f176861..3640ddeeb6 100644
--- a/drivers/spi/sandbox_spi.c
+++ b/drivers/spi/sandbox_spi.c
@@ -28,22 +28,6 @@
 # define CONFIG_SPI_IDLE_VAL 0xFF
 #endif
 
-const char *sandbox_spi_parse_spec(const char *arg, unsigned long *bus,
-  unsigned long *cs)
-{
-   char *endp;
-
-   *bus = simple_strtoul(arg, , 0);
-   if (*endp != ':' || *bus >= CONFIG_SANDBOX_SPI_MAX_BUS)
-   return NULL;
-
-   *cs = simple_strtoul(endp + 1, , 0);
-   if (*endp != ':' || *cs >= CONFIG_SANDBOX_SPI_MAX_CS)
-   return NULL;
-
-   return endp + 1;
-}
-
 __weak int sandbox_spi_get_emul(struct sandbox_state *state,
struct udevice *bus, struct udevice *slave,
struct udevice **emulp)
-- 
2.17.1



[PATCH 0/6] spi: spi-uclass: Fix spi_claim_bus() speed/mode setup logic

2020-12-06 Thread Ovidiu Panait
This patchset fixes spi_claim_bus() handling of the speed/mode settings
when multiple spi slaves claim the bus consecutively, as reported here:
https://lists.denx.de/pipermail/u-boot/2019-December/393854.html
https://lists.denx.de/pipermail/u-boot/2020-November/431554.html

It also does some minor cleanups and adds a sandbox testcase for
spi_claim_bus().


Ovidiu Panait (6):
  sandbox: spi: Drop unused sandbox_spi_parse_spec function
  sandbox: test: Add a second SPI slave on sandbox_spi bus
  spi: sandbox_spi: Implement speed/mode setup
  test: spi: Add sandbox_spi_get_{speed, mode} interface
  spi: spi-uclass: Fix spi_claim_bus() speed/mode setup logic
  test: dm: spi: Add testcase for spi_claim_bus()

 arch/sandbox/dts/test.dts   | 10 +++-
 arch/sandbox/include/asm/spi.h  | 10 
 arch/sandbox/include/asm/test.h | 16 +++
 drivers/mmc/mmc_spi.c   |  1 -
 drivers/spi/sandbox_spi.c   | 58 ---
 drivers/spi/spi-uclass.c| 17 +--
 include/spi.h   | 18 +--
 test/dm/spi.c   | 84 -
 8 files changed, 175 insertions(+), 39 deletions(-)

-- 
2.17.1



Re: [PATCH 1/6] tbs2910: configs: remove VIDCONSOLE_AS_LCD

2020-12-06 Thread Soeren Moch
On 03.12.20 10:15, Patrick Delaunay wrote:
> Remove the obsolete CONFIG_VIDCONSOLE_AS_LCD as vidconsole is used in
> ./include/configs/tbs2910.h since commit 513acd04452f ("tbs2910: migrate
> to DM_VIDEO").
I don't consider this workaround as obsolete, please see my response to
the cover letter of this series. [1]

So please do not remove this code.

Thanks,
Soeren

[1] https://lists.denx.de/pipermail/u-boot/2020-December/434239.html
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  configs/tbs2910_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
> index e43fab208d..b5580abbfd 100644
> --- a/configs/tbs2910_defconfig
> +++ b/configs/tbs2910_defconfig
> @@ -103,7 +103,6 @@ CONFIG_DM_VIDEO=y
>  # CONFIG_VIDEO_ANSI is not set
>  CONFIG_SYS_WHITE_ON_BLACK=y
>  # CONFIG_PANEL is not set
> -CONFIG_VIDCONSOLE_AS_LCD=y
>  CONFIG_I2C_EDID=y
>  CONFIG_VIDEO_IPUV3=y
>  CONFIG_VIDEO_BMP_RLE8=y



Re: [PATCH 0/6] video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME

2020-12-06 Thread Soeren Moch
On 03.12.20 10:15, Patrick Delaunay wrote:
> I propose this serie to remove the vidconsole work-around, activated with
> the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and cleanup
> the associated code in console.c (under #ifdef CONFIG_VIDCONSOLE_AS_LCD)
>
> This options are now obsolete and they was planned to be
> removed around the end of 2020.
>
> I propose this patchset for v2021.04 even if I don't
> test this serie on real boards.
I really would like to keep this code for now.

On the tbs2910 board this workaround was introduced in the last u-boot
release (v2020.10), so there was almost no time for end users to notice
the warning and to update there environment. Not every end user installs
every new u-boot release, so we really should give more time for this
change.

This workaround is self-contained, small, easy to maintain, and strictly
opt-in. So this workaround hurts nobody, but removing this will let
users alone without any HDMI output. So on this board (without included
serial console port), this will result in unhappy users, especially
since without any console output there is no chance to get any idea what
is going wrong.

Thanks,
Soeren
>
> Patrick.
>
>
>
> Patrick Delaunay (6):
>   tbs2910: configs: remove VIDCONSOLE_AS_LCD
>   peach-pit: configs: remove VIDCONSOLE_AS_LCD
>   snow: configs: remove VIDCONSOLE_AS_LCD
>   peach-pi: configs: remove VIDCONSOLE_AS_LCD
>   spring: configs: remove VIDCONSOLE_AS_LCD
>   video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME
>
>  common/console.c| 10 --
>  configs/peach-pi_defconfig  |  1 -
>  configs/peach-pit_defconfig |  1 -
>  configs/snow_defconfig  |  1 -
>  configs/spring_defconfig|  1 -
>  configs/tbs2910_defconfig   |  1 -
>  drivers/video/Kconfig   | 22 --
>  7 files changed, 37 deletions(-)
>



Re: [PATCH] ARM: mx6: add support for USB armory Mk II board

2020-12-06 Thread Stefano Babic
Hi Andrej,

On 21.10.20 11:57, andrej.ros...@f-secure.com wrote:
> From: Andrej Rosano 
> 
> Add support for F-Secure USB armory Mk II board, an open source
> flash-drive sized computer based on Freescale i.MX6UL SoC.
> 
> http://inversepath.com/usbarmory
> 
> Signed-off-by: Andrej Rosano 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/imx6ull-usbarmory.dts| 200 ++
>  arch/arm/mach-imx/mx6/Kconfig |   5 +
>  board/inversepath/usbarmory-mark-two/Kconfig  |  71 
>  .../usbarmory-mark-two/MAINTAINERS|   6 +
>  board/inversepath/usbarmory-mark-two/Makefile |  10 +
>  .../usbarmory-mark-two/imximage-1gb.cfg   |  87 +
>  .../usbarmory-mark-two/imximage-512mb.cfg |  89 +
>  .../usbarmory-mark-two/usbarmory-mark-two.c   | 347 ++
>  configs/usbarmory-mark-two_defconfig  |  72 
>  include/configs/usbarmory-mark-two.h  | 234 
>  11 files changed, 1122 insertions(+)
>  create mode 100644 arch/arm/dts/imx6ull-usbarmory.dts
>  create mode 100644 board/inversepath/usbarmory-mark-two/Kconfig
>  create mode 100644 board/inversepath/usbarmory-mark-two/MAINTAINERS
>  create mode 100644 board/inversepath/usbarmory-mark-two/Makefile
>  create mode 100644 board/inversepath/usbarmory-mark-two/imximage-1gb.cfg
>  create mode 100644 board/inversepath/usbarmory-mark-two/imximage-512mb.cfg

Just that you need two files to setup the RAM controller is a good
reason to switch to SPL.

>  create mode 100644 board/inversepath/usbarmory-mark-two/usbarmory-mark-two.c
>  create mode 100644 configs/usbarmory-mark-two_defconfig
>  create mode 100644 include/configs/usbarmory-mark-two.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b195723f16..d17c14c9bb 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -731,6 +731,7 @@ dtb-$(CONFIG_MX6ULL) += \
>   imx6ull-myir-mys-6ulx-eval.dtb \
>   imx6ull-phytec-segin-ff-rdk-emmc.dtb \
>   imx6ull-dart-6ul.dtb \
> + imx6ull-usbarmory.dtb \
>   imx6ull-somlabs-visionsom.dtb \
>   imx6ulz-14x14-evk.dtb
>  
> diff --git a/arch/arm/dts/imx6ull-usbarmory.dts 
> b/arch/arm/dts/imx6ull-usbarmory.dts
> new file mode 100644
> index 00..d5a616f703
> --- /dev/null
> +++ b/arch/arm/dts/imx6ull-usbarmory.dts
> @@ -0,0 +1,200 @@
> +/*
> + * USB armory Mk II device tree file
> + * https://github.com/inversepath/usbarmory
> + *
> + * Copyright (C) 2019, F-Secure Corporation
> + * Andrej Rosano 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6ull.dtsi"
> +
> +/ {
> + model = "F-Secure USB armory Mk II";
> + compatible = "inversepath,imx6ull-usbarmory-mkII", "fsl,imx6ull";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + memory {
> + reg = <0x8000 0x2000>;
> + };
> +
> + leds {
> + compatible = 

Re: [PATCH v1] imx: clk: added IPG Clock for I2C on imx8qm

2020-12-06 Thread Stefano Babic
On 12.11.20 11:51, Oliver Graute wrote:
> This patch fixes this clk issue on I2C on imx8qm
> 
>  => i2c bus
>  Bus 3:  i2c@5a83
>  => i2c dev 3
>  Setting bus to 3
>  Failed to enable ipg clk
>  Failure changing bus number (-524)
> 
> Signed-off-by: Oliver Graute 
> Cc: Stefano Babic 
> Cc: Peng Fan 
> Cc: uboot-imx 
> ---
>  drivers/clk/imx/clk-imx8qm.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c
> index 54fb09fda4..7e466d630a 100644
> --- a/drivers/clk/imx/clk-imx8qm.c
> +++ b/drivers/clk/imx/clk-imx8qm.c
> @@ -53,19 +53,27 @@ ulong imx8_clk_get_rate(struct clk *clk)
>   resource = SC_R_A53;
>   pm_clk = SC_PM_CLK_CPU;
>   break;
> + case IMX8QM_I2C0_IPG_CLK:
>   case IMX8QM_I2C0_CLK:
> + case IMX8QM_I2C0_DIV:
>   resource = SC_R_I2C_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C1_IPG_CLK:
>   case IMX8QM_I2C1_CLK:
> + case IMX8QM_I2C1_DIV:
>   resource = SC_R_I2C_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C2_IPG_CLK:
>   case IMX8QM_I2C2_CLK:
> + case IMX8QM_I2C2_DIV:
>   resource = SC_R_I2C_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C3_IPG_CLK:
>   case IMX8QM_I2C3_CLK:
> + case IMX8QM_I2C3_DIV:
>   resource = SC_R_I2C_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -148,19 +156,27 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long 
> rate)
>   debug("%s(#%lu), rate: %lu\n", __func__, clk->id, rate);
>  
>   switch (clk->id) {
> + case IMX8QM_I2C0_IPG_CLK:
>   case IMX8QM_I2C0_CLK:
> + case IMX8QM_I2C0_DIV:
>   resource = SC_R_I2C_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C1_IPG_CLK:
>   case IMX8QM_I2C1_CLK:
> + case IMX8QM_I2C1_DIV:
>   resource = SC_R_I2C_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C2_IPG_CLK:
>   case IMX8QM_I2C2_CLK:
> + case IMX8QM_I2C2_DIV:
>   resource = SC_R_I2C_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C3_IPG_CLK:
>   case IMX8QM_I2C3_CLK:
> + case IMX8QM_I2C3_DIV:
>   resource = SC_R_I2C_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -242,19 +258,27 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
>   debug("%s(#%lu)\n", __func__, clk->id);
>  
>   switch (clk->id) {
> + case IMX8QM_I2C0_IPG_CLK:
>   case IMX8QM_I2C0_CLK:
> + case IMX8QM_I2C0_DIV:
>   resource = SC_R_I2C_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C1_IPG_CLK:
>   case IMX8QM_I2C1_CLK:
> + case IMX8QM_I2C1_DIV:
>   resource = SC_R_I2C_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C2_IPG_CLK:
>   case IMX8QM_I2C2_CLK:
> + case IMX8QM_I2C2_DIV:
>   resource = SC_R_I2C_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_I2C3_IPG_CLK:
>   case IMX8QM_I2C3_CLK:
> + case IMX8QM_I2C3_DIV:
>   resource = SC_R_I2C_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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


Re: [PATCH v2] imx: Add support for Ronetix's i.MX7-CM board.

2020-12-06 Thread Stefano Babic
Hi Ilko,

your patch is since a long while in the list. I have merged it a couple
of times but I went back - sorry to not communicate this before.

Your patch create a DCD for the board - but we have full support for
i.MX6 and i.MX to set dinamically the DDR controller in SPL, see
mx7_dram_cfg(), and this makes board/ronetix/imx7-cm/imximage.cfg
superfluous. Do you have evaluated to switch to SPL instead of
hard-coding the DCD into u-boot.imx ?

Best regards,
Stefano Babic

On 13.07.20 16:00, Ilko Iliev wrote:
> Supported peripherals: ETH, SD, eMMC, USB, I2C EEPROM, PMIC, QSPI Nor
> Flash.
> 
> U-Boot 2020.07-00611-g1fc3bcb2ee-dirty (Jul 13 2020 - 15:25:49 +0200)
> 
> CPU:   Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 39C
> Reset cause: POR
> Model: Ronetix i.MX7-CM Board
> Board: i.MX7-CM in non-secure mode
> DRAM:  512 MiB
> PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@30be
> Hit any key to stop autoboot:  0
> 
> Signed-off-by: Ilko Iliev 
> 
> Changes for v2:
>   - support for i.MX7-CM v2.0
>   - applicable to the current master branch
> ---
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/imx7-cm.dts   | 674 +
>  arch/arm/mach-imx/mx7/Kconfig  |  10 +-
>  board/ronetix/imx7-cm/Kconfig  |  12 +
>  board/ronetix/imx7-cm/MAINTAINERS  |   6 +
>  board/ronetix/imx7-cm/Makefile |   4 +
>  board/ronetix/imx7-cm/imx7-cm.c| 210 +
>  board/ronetix/imx7-cm/imximage.cfg | 104 +
>  configs/imx7_cm_defconfig  |  97 +
>  include/configs/imx7-cm.h  | 157 +++
>  10 files changed, 1275 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/imx7-cm.dts
>  create mode 100644 board/ronetix/imx7-cm/Kconfig
>  create mode 100644 board/ronetix/imx7-cm/MAINTAINERS
>  create mode 100644 board/ronetix/imx7-cm/Makefile
>  create mode 100644 board/ronetix/imx7-cm/imx7-cm.c
>  create mode 100644 board/ronetix/imx7-cm/imximage.cfg
>  create mode 100644 configs/imx7_cm_defconfig
>  create mode 100644 include/configs/imx7-cm.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d839cb49b3..7a134190e5 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -730,7 +730,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
>   imx7s-warp.dtb \
>   imx7d-meerkat96.dtb \
>   imx7d-pico-pi.dtb \
> - imx7d-pico-hobbit.dtb
> + imx7d-pico-hobbit.dtb \
> + imx7-cm.dtb
>  
>  
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \
> diff --git a/arch/arm/dts/imx7-cm.dts b/arch/arm/dts/imx7-cm.dts
> new file mode 100644
> index 00..1938a1829d
> --- /dev/null
> +++ b/arch/arm/dts/imx7-cm.dts
> @@ -0,0 +1,674 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2017 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "imx7d.dtsi"
> +
> +/ {
> + model = "Ronetix i.MX7-CM Board";
> + compatible = "fsl,imx7d-sdb", "fsl,imx7d";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x8000>;
> + };
> +
> + reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg1_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < 5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg2_vbus";
> + pinctrl-names = "default";
> + pinctrl-0 = <_usb_otg2_vbus_reg>;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_vref_1v8: regulator-vref-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vref-1v8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + };
> +
> + reg_sd1_vmmc: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_SD1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 2 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <20>;
> + enable-active-high;
> + };
> +
> + reg_sd2_vmmc: regulator@4 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_SD2";
> + pinctrl-names = "default";
> + pinctrl-0 = <_sd2_vmmc_reg>;
> + 

Re: [PATCH v1 2/2] imx: imx8qm_rom7720_a1: fix broken fsl_esdhc_imx conversion

2020-12-06 Thread Stefano Babic
Hi Oliver,

sorry, lost your mail, and I see your question is still open:

On 20.11.20 14:13, Oliver Graute wrote:
> On 10/03/20, Stefano Babic wrote:
>> On 19.12.19 15:27, Oliver Graute wrote:
>>> Fix broken fsl_esdhc_imx conversion
>>>
>>> Signed-off-by: Oliver Graute 
>>> Cc: Stefano Babic 
>>> Cc: Fabio Estevam 
>>> Cc: Peng Fan 
>>> Cc: Simon Glass 
>>> Cc: Ye Li 
>>> Cc: uboot-imx 
>>> ---
>>>  board/advantech/imx8qm_rom7720_a1/spl.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/board/advantech/imx8qm_rom7720_a1/spl.c 
>>> b/board/advantech/imx8qm_rom7720_a1/spl.c
>>> index 3f31a8f9c3..24d216921d 100644
>>> --- a/board/advantech/imx8qm_rom7720_a1/spl.c
>>> +++ b/board/advantech/imx8qm_rom7720_a1/spl.c
>>> @@ -55,7 +55,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>> (SC_PAD_ISO_OFF << PADRING_LPCONFIG_SHIFT) | \
>>> (SC_PAD_28FDSOI_DSE_DV_HIGH << PADRING_DSE_SHIFT) | \
>>> (SC_PAD_28FDSOI_PS_PU << PADRING_PULL_SHIFT))
>>> -#ifdef CONFIG_FSL_ESDHC
>>> +#ifdef CONFIG_FSL_ESDHC_IMX
>>>  
>>>  #define USDHC1_CD_GPIO IMX_GPIO_NR(5, 22)
>>>  #define USDHC2_CD_GPIO IMX_GPIO_NR(4, 12)
>>> @@ -164,7 +164,7 @@ int board_mmc_getcd(struct mmc *mmc)
>>> return ret;
>>>  }
>>>  
>>> -#endif /* CONFIG_FSL_ESDHC */
>>> +#endif /* CONFIG_FSL_ESDHC_IMX */
>>>  
>>>  void spl_board_init(void)
>>>  {
>>>
>>
>> I agree to merge this, now it is enabled, code is compiled and I get a
>> warning:
>>
>>aarch64:  w+   imx8qm_rom7720_a1_4G
>> functional
>> +  115 |init_clk_usdhc(0);
>> +  |^~
>>
>> w+board/advantech/imx8qm_rom7720_a1/spl.c:115:4: warning: implicit
>> declaration of function 'init_clk_usdhc' [-Wimplicit-function-declaration]
> 
> is this the right place to fix this warning?
> 
> --- a/arch/arm/include/asm/arch-imx8/clock.h
> +++ b/arch/arm/include/asm/arch-imx8/clock.h
> @@ -23,5 +23,6 @@ enum mxc_clock {
>  };
> 
>  u32 mxc_get_clock(enum mxc_clock clk);
> +void init_clk_usdhc(u32 index);
> 

I think yes, we have the same for imx8m.

> 
>> w+board/advantech/imx8qm_rom7720_a1/spl.c:137:9: warning: implicit
>> declaration of function 'fsl_esdhc_initialize'; did you mean
>> 'eth_initialize'? [-Wimplicit-function-declaration]
> 
> I`ll replace this to fix this warning
> 
> +++ b/board/advantech/imx8qm_rom7720_a1/spl.c
> @@ -8,7 +8,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> 
> Best regards,
> 
> Oliver
> 

Regards,
Stefano

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


Re: About the commit imx: mx6ull: update the REFTOP_VBGADJ setting

2020-12-06 Thread Michael Nazzareno Trimarchi
Hi

On Fri, Dec 4, 2020 at 10:44 PM Michael Nazzareno Trimarchi
 wrote:
>
> Hi Peng
>
> I have a design with imx6ull that is running properly according to the
> manufacturer with the old REFTOP_VBGA set
> BM_ANADIG_ANA_MISC0_REFTOP_VBGADJ,. With this commit, the TJunction of
> the CPU is around 8 degree more than without. The commit message does
> not provide any info
>
> According to the design team, we need to set REFTOP_VBGADJ
> in PMU MISC0 according to the REFTOP_TRIM[2:0] fuse. the
> actually table is as below:
>
>   '000" - set REFTOP_VBGADJ[2:0] to 3'b000
>   '001" - set REFTOP_VBGADJ[2:0] to 3'b001
>   '010" - set REFTOP_VBGADJ[2:0] to 3'b010
>   '011" - set REFTOP_VBGADJ[2:0] to 3'b011
>   '100" - set REFTOP_VBGADJ[2:0] to 3'b100
>   '101" - set REFTOP_VBGADJ[2:0] to 3'b101
>   '110" - set REFTOP_VBGADJ[2:0] to 3'b110
>   '111" - set REFTOP_VBGADJ[2:0] to 3'b111
>
> Can someone describe to me better? The device needs to run in a very
> hot environment and  10 to 8 degrees on the junction
> are really important.

I think that is used as reference temperatur too, for measuring
temperature in the processor.
I think that i need to ask to us a thermal camera

Michael

>
> In the same environment:
> temp without this patch 34
> temp with is 43
>
> Register value is
> 0x240080E8
> and
> 0x24008088
>
> Michael
>
>
> --
> Michael Nazzareno Trimarchi
> Amarula Solutions BV
> COO Co-Founder
> Cruquiuskade 47 Amsterdam 1018 AM NL
> T. +31(0)851119172
> M. +39(0)3479132170
> [`as] https://www.amarulasolutions.com



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com