[PATCH 1/2] i2c: ocores: add i2c driver for OpenCores I2C controller

2020-10-08 Thread Pragnesh Patel
Add support for the OpenCores I2C controller IP core
(See http://www.opencores.org/projects.cgi/web/i2c/overview).

This driver implementation is inspired from the Linux OpenCores
I2C driver available.

Thanks to Peter Korsgaard  for writing Linux
OpenCores I2C driver.

Signed-off-by: Pragnesh Patel 
---
 drivers/i2c/Kconfig  |   7 +
 drivers/i2c/Makefile |   1 +
 drivers/i2c/ocores_i2c.c | 638 +++
 3 files changed, 646 insertions(+)
 create mode 100644 drivers/i2c/ocores_i2c.c

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 8ae54e1e93..adf37177c4 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -342,6 +342,13 @@ config SYS_I2C_NEXELL
  have several I2C ports and all are provided, controlled by the
  device tree.
 
+config SYS_I2C_OCORES
+   bool "ocores I2C driver"
+   depends on DM_I2C
+   help
+ Add support for ocores I2C controller. For details see
+ http://www.opencores.org/projects.cgi/web/i2c/overview
+
 config SYS_I2C_OMAP24XX
bool "TI OMAP2+ I2C driver"
depends on ARCH_OMAP2PLUS || ARCH_K3
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index bd248cbf52..37dc8ada6d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o
 obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
 obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
 obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o
+obj-$(CONFIG_SYS_I2C_OCORES) += ocores_i2c.o
 obj-$(CONFIG_SYS_I2C_OCTEON) += octeon_i2c.o
 obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_I2C) += rcar_i2c.o
diff --git a/drivers/i2c/ocores_i2c.c b/drivers/i2c/ocores_i2c.c
new file mode 100644
index 00..b42b55625f
--- /dev/null
+++ b/drivers/i2c/ocores_i2c.c
@@ -0,0 +1,638 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ocores-i2c.c: I2C bus driver for OpenCores I2C controller
+ * (https://opencores.org/project/i2c/overview)
+ *
+ * (C) Copyright Peter Korsgaard 
+ *
+ * Copyright (C) 2020 SiFive, Inc.
+ * Pragnesh Patel 
+ *
+ * Support for the GRLIB port of the controller by
+ * Andreas Larsson 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* registers */
+#define OCI2C_PRELOW   0
+#define OCI2C_PREHIGH  1
+#define OCI2C_CONTROL  2
+#define OCI2C_DATA 3
+#define OCI2C_CMD  4 /* write only */
+#define OCI2C_STATUS   4 /* read only, same address as OCI2C_CMD */
+
+#define OCI2C_CTRL_IEN 0x40
+#define OCI2C_CTRL_EN  0x80
+
+#define OCI2C_CMD_START0x91
+#define OCI2C_CMD_STOP 0x41
+#define OCI2C_CMD_READ 0x21
+#define OCI2C_CMD_WRITE0x11
+#define OCI2C_CMD_READ_ACK 0x21
+#define OCI2C_CMD_READ_NACK0x29
+#define OCI2C_CMD_IACK 0x01
+
+#define OCI2C_STAT_IF  0x01
+#define OCI2C_STAT_TIP 0x02
+#define OCI2C_STAT_ARBLOST 0x20
+#define OCI2C_STAT_BUSY0x40
+#define OCI2C_STAT_NACK0x80
+
+#define STATE_DONE 0
+#define STATE_START1
+#define STATE_WRITE2
+#define STATE_READ 3
+#define STATE_ERROR4
+
+#define TYPE_OCORES0
+#define TYPE_GRLIB 1
+#define TYPE_SIFIVE_REV0   2
+
+#define OCORES_FLAG_BROKEN_IRQ BIT(1) /* Broken IRQ for FU540-C000 SoC */
+
+struct ocores_i2c_bus {
+   void __iomem *base;
+   u32 reg_shift;
+   u32 reg_io_width;
+   unsigned long flags;
+   struct i2c_msg *msg;
+   int pos;
+   int nmsgs;
+   int state; /* see STATE_ */
+   struct clk clk;
+   int ip_clk_khz;
+   int bus_clk_khz;
+   void (*setreg)(struct ocores_i2c_bus *i2c, int reg, u8 value);
+   u8 (*getreg)(struct ocores_i2c_bus *i2c, int reg);
+};
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Boolean attribute values */
+enum {
+   FALSE = 0,
+   TRUE,
+};
+
+static void oc_setreg_8(struct ocores_i2c_bus *i2c, int reg, u8 value)
+{
+   writeb(value, i2c->base + (reg << i2c->reg_shift));
+}
+
+static void oc_setreg_16(struct ocores_i2c_bus *i2c, int reg, u8 value)
+{
+   writew(value, i2c->base + (reg << i2c->reg_shift));
+}
+
+static void oc_setreg_32(struct ocores_i2c_bus *i2c, int reg, u8 value)
+{
+   writel(value, i2c->base + (reg << i2c->reg_shift));
+}
+
+static void oc_setreg_16be(struct ocores_i2c_bus *i2c, int reg, u8 value)
+{
+   out_be16(i2c->base + (reg << i2c->reg_shift), value);
+}
+
+static void oc_setreg_32be(struct ocores_i2c_bus *i2c, int reg, u8 value)
+{
+   out_be32(i2c->base + (reg << i2c->reg_shift), value);
+}
+
+static inline u8 oc_getreg_8(struct ocores_i2c_bus *i2c, int reg)
+{
+   return readb(i2c->base + (reg << i2c->reg_shift));
+}
+
+static inline u8 oc_getreg_16(struct ocores_i2c_bus *i2c, int reg)
+{
+   return readw(i2c->base + (reg << i2c->reg_shift));
+}

[PATCH 2/2] riscv: sifive/fu540: kconfig: Enable support for Opencores I2C controller

2020-10-08 Thread Pragnesh Patel
Enable support for SiFive FU540 Opencores I2C master controller.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/cpu/fu540/Kconfig | 2 ++
 board/sifive/fu540/Kconfig   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index ac3f183342..61bd5c426e 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -35,6 +35,8 @@ config SIFIVE_FU540
imply SIFIVE_OTP
imply DM_PWM
imply PWM_SIFIVE
+   imply DM_I2C
+   imply SYS_I2C_OCORES
 
 if ENV_IS_IN_SPI_FLASH
 
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index e70d1e53f9..64fdbd44b4 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -47,5 +47,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply SPI_FLASH_ISSI
imply SYSRESET
imply SYSRESET_GPIO
+   imply CMD_I2C
 
 endif
-- 
2.17.1



[PATCH 0/2] Add OpenCores I2C controller driver

2020-10-08 Thread Pragnesh Patel
This driver has been tested on HiFive Unleashed with a PMOD based
RTCC sensor connected to I2C pins J1 header of the board.

This series is available here [1] for testing
[1] https://github.com/pragnesh26992/u-boot/tree/i2c

Tested-by: Sagar Shrikant Kadam 

U-Boot Logs for reference:

Hit any key to stop autoboot:  0
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses: 57 6F
=> i2c md 0x57 0x0 1
: ff
=> i2c mw 0x57 0x0 0xa5 1
=> i2c md 0x57 0x0 1
: a5
=> i2c md 0x6f 0x0 1
: 00
=> i2c md 0x6f 0x1 1
0001: 00
=> i2c md 0x6f 0x2 1
0002: 00
=> i2c md 0x6f 0x20 1
0020: 98
=> i2c md 0x6f 0x5f 1
005f: 55
=> i2c mw 0x6f 0x0 0x12 1
=> i2c mw 0x6f 0x1 0x34 1
=> i2c mw 0x6f 0x2 0x56 1
=> i2c md 0x6f 0x0 1
: 12
=> i2c md 0x6f 0x1 1
0001: 34
=> i2c md 0x6f 0x2 1
0002: 56
=> i2c mw 0x6f 0x20 0x78 1
=> i2c md 0x6f 0x20 1
0020: 78
=> i2c mw 0x6f 0x5f 0x5a 1
=> i2c md 0x6f 0x5f 1
005f: 5a
=> i2c mw 0x6f 0x5f 0xa5 1
=> i2c md 0x6f 0x5f 1
005f: a5


Pragnesh Patel (2):
  i2c: ocores: add i2c driver for OpenCores I2C controller
  riscv: sifive/fu540: kconfig: Enable support for Opencores I2C
controller

 arch/riscv/cpu/fu540/Kconfig |   2 +
 board/sifive/fu540/Kconfig   |   1 +
 drivers/i2c/Kconfig  |   7 +
 drivers/i2c/Makefile |   1 +
 drivers/i2c/ocores_i2c.c | 638 +++
 5 files changed, 649 insertions(+)
 create mode 100644 drivers/i2c/ocores_i2c.c

-- 
2.17.1



[Patch v2] armv8: dts: fsl-lx2162a: add dspi node into qds dts

2020-10-08 Thread Qiang Zhao
From: Zhao Qiang 

Add dspi node into lx2162aqds device tree

Signed-off-by: Zhao Qiang 
---
depends on: 
https://patchwork.ozlabs.org/project/uboot/patch/1599473527-21511-3-git-send-email-meenakshi.aggar...@nxp.com/

changes for v2:
- add alias part

 arch/arm/dts/fsl-lx2162a-qds.dts | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm/dts/fsl-lx2162a-qds.dts b/arch/arm/dts/fsl-lx2162a-qds.dts
index 57e1913..6211757 100644
--- a/arch/arm/dts/fsl-lx2162a-qds.dts
+++ b/arch/arm/dts/fsl-lx2162a-qds.dts
@@ -16,6 +16,108 @@
 
aliases {
spi0 = 
+   spi1 = 
+   spi2 = 
+   spi3 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash0: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <0>;
+   };
+   dflash1: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <1>;
+   };
+   dflash2: en25s64 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <2>;
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash3: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <0>;
+   };
+   dflash4: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <1>;
+   };
+   dflash5: en25s64 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <2>;
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash6: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <0>;
+   };
+   dflash7: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <1>;
+   };
+   dflash8: en25s64 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <300>;
+   spi-cpol;
+   spi-cpha;
+   reg = <2>;
};
 };
 
-- 
2.7.4



Collecting U-Boot Testresults: was: [ANN] U-Boot v2020.10 released

2020-10-08 Thread Heiko Schocher

Hi all,

Am 05.10.2020 um 17:17 schrieb Tom Rini:

Hey all,

It is release day and here is the v2020.10 release.  With this release
we have a number of "please migrate to DM" warnings that are now 1 year
past their warning date, and well past 1 year of those warnings being
printed.  It's getting up there on my TODO list to see if removing
features or boards in these cases is easier.

In terms of a changelog,
git log --merges v2020.10-rc5..v2020.10
or
git log --merges v2020.07..v2020.10

The merge window is once again open and I plan to tag -rc1 on Monday,
October 26th, bi-weekly -rcs thereafter and final release on January
11th, 2021.

I am merging the next branch to master shortly and will send a separate
email when that is done.


I want to use the chance after a new release is out, to ask if
people have interests in sending U-Boot Testresults to

[1] http://xeidos.ddns.net/ubtestresults/home

Of course you can use tbot ([2],[7]) for doing all the stuff automated
([2], [3], [4]), but it is enough to create the data by hand and push
a testresult to this server (After you get access to it ...) for example
with my testscript [6]... but I recommend to use tbot, as you also
can use tbot for your daily work.

If enough data is collected for a board, you can get a graphic which
shows the progress of image size for your board, like:

http://xeidos.ddns.net/ubtestresults/stats/wandboard_defconfig/90

As the server code is on github [5], I am open for more ideas, what
sort of data we want to collect and what we may do with the data...

Thanks!

bye,
Heiko

[2] Example tbot implementation I use for the boards which are in [1]
https://github.com/EmbLux-Kft/tbot-tbot2go

Example config for socrates board:

tbot board config:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/socrates.py#L21

config for using U-Boots test.py:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/socrates.py#L27

add patches to U-Boot mainline:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/socrates.py#L39

UBoot builder config (for the "pollux" lab) with enabling some extra
Kconfig options for the U-Boot test:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/pollux.py#L129

[3] tbot generator for pushing to the database:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/push-testresult.py

[4] Minimal "CI" (something like a cron job, but in python):
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/minimal-ci.py

and the config for my currently 4 boards:
https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/minimal-ci.json

[5] server code:
https://github.com/EmbLux-Kft/uboot_results

[6] script for pushing results to it (by hand):
https://github.com/EmbLux-Kft/uboot_results/blob/master/src/client.py

This is just an test script from me, it needs cleanup, and of course
adaptions to work for others ...

[7] tbot documentation
http://tbot.tools/
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


Re: [PATCH 1/2] lib: print_freq() should output kHz not KHz

2020-10-08 Thread Stefan Roese

On 08.10.20 22:23, Heinrich Schuchardt wrote:

In the International System of Units (SI) the prefix kilo is abbreviated as
'k' not 'K'. 'K' is the symbol for Kelvin.

Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  include/display_options.h | 2 +-
  lib/display_options.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/display_options.h b/include/display_options.h
index a0dabca2b8..049688e39e 100644
--- a/include/display_options.h
+++ b/include/display_options.h
@@ -24,7 +24,7 @@ void print_size(uint64_t size, const char *suffix);
  /**
   * print_freq() - Print a frequency with a suffix
   *
- * Print frequencies as "x.xx GHz", "xxx KHz", etc as needed; allow for
+ * Print frequencies as "x.xx GHz", "xxx kHz", etc as needed; allow for
   * optional trailing string (like "\n")
   *
   * @freq: Frequency to print in Hz
diff --git a/lib/display_options.c b/lib/display_options.c
index ea9977cc18..b2025eeb5c 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -54,7 +54,7 @@ void print_freq(uint64_t freq, const char *s)
  {
unsigned long m = 0;
uint32_t f;
-   static const char names[] = {'G', 'M', 'K'};
+   static const char names[] = {'G', 'M', 'k'};
unsigned long d = 1e9;
char c = 0;
unsigned int i;
--
2.28.0




Viele Grüße,
Stefan

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


Re: [PATCH 2/2] test: unit tests for print_freq(), print_size()

2020-10-08 Thread Sean Anderson
On 10/8/20 4:23 PM, Heinrich Schuchardt wrote:
> Provide unit tests for functions print_freq() and print_size().
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/lib/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/test/lib/Makefile b/test/lib/Makefile
> index 22236f8587..15cd512506 100644
> --- a/test/lib/Makefile
> +++ b/test/lib/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
>  obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
>  obj-y += hexdump.o
>  obj-y += lmb.o
> +obj-y += test_print.o

Should test/lib/test_print.c be included in this patch?

--Sean

>  obj-$(CONFIG_SSCANF) += sscanf.o
>  obj-y += string.o
>  obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
> --
> 2.28.0
> 



[PATCH 1/2] lib: print_freq() should output kHz not KHz

2020-10-08 Thread Heinrich Schuchardt
In the International System of Units (SI) the prefix kilo is abbreviated as
'k' not 'K'. 'K' is the symbol for Kelvin.

Signed-off-by: Heinrich Schuchardt 
---
 include/display_options.h | 2 +-
 lib/display_options.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/display_options.h b/include/display_options.h
index a0dabca2b8..049688e39e 100644
--- a/include/display_options.h
+++ b/include/display_options.h
@@ -24,7 +24,7 @@ void print_size(uint64_t size, const char *suffix);
 /**
  * print_freq() - Print a frequency with a suffix
  *
- * Print frequencies as "x.xx GHz", "xxx KHz", etc as needed; allow for
+ * Print frequencies as "x.xx GHz", "xxx kHz", etc as needed; allow for
  * optional trailing string (like "\n")
  *
  * @freq:  Frequency to print in Hz
diff --git a/lib/display_options.c b/lib/display_options.c
index ea9977cc18..b2025eeb5c 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -54,7 +54,7 @@ void print_freq(uint64_t freq, const char *s)
 {
unsigned long m = 0;
uint32_t f;
-   static const char names[] = {'G', 'M', 'K'};
+   static const char names[] = {'G', 'M', 'k'};
unsigned long d = 1e9;
char c = 0;
unsigned int i;
--
2.28.0



[PATCH 2/2] test: unit tests for print_freq(), print_size()

2020-10-08 Thread Heinrich Schuchardt
Provide unit tests for functions print_freq() and print_size().

Signed-off-by: Heinrich Schuchardt 
---
 test/lib/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/lib/Makefile b/test/lib/Makefile
index 22236f8587..15cd512506 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
 obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
 obj-y += hexdump.o
 obj-y += lmb.o
+obj-y += test_print.o
 obj-$(CONFIG_SSCANF) += sscanf.o
 obj-y += string.o
 obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
--
2.28.0



[PATCH 0/2] lib: print_freq() should output kHz not KHz

2020-10-08 Thread Heinrich Schuchardt
Correct print_freq() for output of kHz.
Provide unit tests for print_freq() and print_size().

Heinrich Schuchardt (2):
  lib: print_freq() should output kHz not KHz
  test: unit tests for print_freq(), print_size()

 include/display_options.h | 2 +-
 lib/display_options.c | 2 +-
 test/lib/Makefile | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

--
2.28.0



[PATCH] env: sf: add support for env erase

2020-10-08 Thread Harry Waschkeit

Command "env erase" didn't work even though CONFIG_CMD_ERASEENV was
defined, because serial flash environment routines didn't implement
erase method.

Signed-off-by: Waschkeit, Harry 
---
 env/sf.c | 130 ++-
 1 file changed, 128 insertions(+), 2 deletions(-)

diff --git a/env/sf.c b/env/sf.c
index 937778aa37..9cda192a73 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -146,6 +146,78 @@ static int env_sf_save(void)
return ret;
 }
 
+#ifdef CONFIG_CMD_ERASEENV

+static int env_sf_erase(void)
+{
+   char*saved_buffer = NULL;
+   u32 saved_size, saved_offset, sector;
+   ulong   offset;
+   ulong   offsets[2] = { CONFIG_ENV_OFFSET, CONFIG_ENV_OFFSET_REDUND };
+   int i;
+   int ret;
+
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
+
+   /* get temporary storage if sector is larger than env (i.e. embedded) */
+   if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
+   saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
+   saved_buffer = memalign(ARCH_DMA_MINALIGN, saved_size);
+   if (!saved_buffer) {
+   ret = -ENOMEM;
+   goto done;
+   }
+   }
+
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
+
+   /* simply erase both environments, retaining non-env data (if any) */
+   for (i = 0; i < ARRAY_SIZE(offsets); i++) {
+   offset = offsets[i];
+
+   if (saved_buffer) {
+   saved_offset = offset + CONFIG_ENV_SIZE;
+   ret = spi_flash_read(env_flash, saved_offset,
+saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   if (i)
+   puts("Redund:");
+
+   puts("Erasing SPI flash...");
+   ret = spi_flash_erase(env_flash, offset,
+ sector * CONFIG_ENV_SECT_SIZE);
+   if (ret)
+   goto done;
+
+   if (saved_buffer) {
+   puts("Writing non-environment data to SPI flash...");
+   ret = spi_flash_write(env_flash, saved_offset,
+ saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   puts("done\n");
+   }
+
+   /* here we know that both env sections are cleared */
+   env_new_offset = CONFIG_ENV_OFFSET;
+   env_offset = CONFIG_ENV_OFFSET_REDUND;
+
+   gd->env_valid = ENV_INVALID;
+
+ done:
+   if (saved_buffer)
+   free(saved_buffer);
+
+   return ret;
+}
+#endif /* CONFIG_CMD_ERASEENV */
+
 static int env_sf_load(void)
 {
int ret;
@@ -182,7 +254,7 @@ out:
 
return ret;

 }
-#else
+#else  /* #if defined(CONFIG_ENV_OFFSET_REDUND) */
 static int env_sf_save(void)
 {
u32 saved_size, saved_offset, sector;
@@ -243,6 +315,57 @@ static int env_sf_save(void)
return ret;
 }
 
+#ifdef CONFIG_CMD_ERASEENV

+static int env_sf_erase(void)
+{
+   u32 saved_size, saved_offset, sector;
+   char*saved_buffer = NULL;
+   int ret = 1;
+
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
+
+   /* Is the sector larger than the env (i.e. embedded) */
+   if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
+   saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
+   saved_offset = CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE;
+   saved_buffer = malloc(saved_size);
+   if (!saved_buffer)
+   goto done;
+
+   ret = spi_flash_read(env_flash, saved_offset,
+   saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
+
+   puts("Erasing SPI flash...");
+   ret = spi_flash_erase(env_flash, CONFIG_ENV_OFFSET,
+   sector * CONFIG_ENV_SECT_SIZE);
+   if (ret)
+   goto done;
+
+   if (saved_buffer) {
+   puts("Writing non-environment data to SPI flash...");
+   ret = spi_flash_write(env_flash, saved_offset,
+   saved_size, saved_buffer);
+   if (ret)
+   goto done;
+   }
+
+   puts("done\n");
+
+ done:
+   if (saved_buffer)
+   free(saved_buffer);
+
+   return ret;
+}
+#endif /* CONFIG_CMD_ERASEENV */
+
 static int env_sf_load(void)
 {
int ret;
@@ -277,7 +400,7 @@ out:
 
return ret;

 }
-#endif
+#endif  /* #if defined(CONFIG_ENV_OFFSET_REDUND) #else */
 
 #if CONFIG_ENV_ADDR != 0x0

 __weak void *env_sf_get_env_addr(void)
@@ -311,4 +434,7 @@ 

[PATCH 5/6] rng: Add Qualcomm MSM PRNG driver

2020-10-08 Thread Robert Marko
Add support for the hardware pseudo random number generator found in Qualcomm 
SoC-s.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 
---
 MAINTAINERS   |   1 +
 drivers/rng/Kconfig   |   7 +++
 drivers/rng/Makefile  |   1 +
 drivers/rng/msm_rng.c | 143 ++
 4 files changed, 152 insertions(+)
 create mode 100644 drivers/rng/msm_rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f1a815c88..8a1bc97443 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -243,6 +243,7 @@ F:  drivers/reset/reset-ipq4019.c
 F: drivers/phy/phy-qcom-ipq4019-usb.c
 F: drivers/spi/spi-qup.c
 F: drivers/net/mdio-ipq4019.c
+F: drivers/rng/msm_rng.c
 
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index e4b22d79eb..11001c8ae7 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -24,6 +24,13 @@ config RNG_SANDBOX
  Enable random number generator for sandbox. This is an
  emulation of a rng device.
 
+config RNG_MSM
+   bool "Qualcomm SoCs Random Number Generator support"
+   depends on DM_RNG
+   help
+ This driver provides support for the Random Number
+ Generator hardware found on Qualcomm SoCs.
+
 config RNG_STM32MP1
bool "Enable random number generator for STM32MP1"
depends on ARCH_STM32MP
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 44a0003917..8953406882 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -6,5 +6,6 @@
 obj-$(CONFIG_DM_RNG) += rng-uclass.o
 obj-$(CONFIG_RNG_MESON) += meson-rng.o
 obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
+obj-$(CONFIG_RNG_MSM) += msm_rng.o
 obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
 obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
diff --git a/drivers/rng/msm_rng.c b/drivers/rng/msm_rng.c
new file mode 100644
index 00..d51119303a
--- /dev/null
+++ b/drivers/rng/msm_rng.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * PRNG driver for Qualcomm IPQ40xx
+ *
+ * Copyright (c) 2020 Sartura Ltd.
+ *
+ * Author: Robert Marko 
+ *
+ * Based on Linux driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Device specific register offsets */
+#define PRNG_DATA_OUT  0x
+#define PRNG_STATUS0x0004
+#define PRNG_LFSR_CFG  0x0100
+#define PRNG_CONFIG0x0104
+
+/* Device specific register masks and config values */
+#define PRNG_LFSR_CFG_MASK 0x
+#define PRNG_LFSR_CFG_CLOCKS   0x
+#define PRNG_CONFIG_HW_ENABLE  BIT(1)
+#define PRNG_STATUS_DATA_AVAIL BIT(0)
+
+#define MAX_HW_FIFO_DEPTH  16
+#define MAX_HW_FIFO_SIZE   (MAX_HW_FIFO_DEPTH * 4)
+#define WORD_SZ4
+
+struct msm_rng_priv {
+   phys_addr_t base;
+   struct clk clk;
+};
+
+static int msm_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   struct msm_rng_priv *priv = dev_get_priv(dev);
+   size_t currsize = 0;
+   u32 *retdata = data;
+   size_t maxsize;
+   u32 val;
+
+   /* calculate max size bytes to transfer back to caller */
+   maxsize = min_t(size_t, MAX_HW_FIFO_SIZE, len);
+
+   /* read random data from hardware */
+   do {
+   val = readl_relaxed(priv->base + PRNG_STATUS);
+   if (!(val & PRNG_STATUS_DATA_AVAIL))
+   break;
+
+   val = readl_relaxed(priv->base + PRNG_DATA_OUT);
+   if (!val)
+   break;
+
+   *retdata++ = val;
+   currsize += WORD_SZ;
+
+   /* make sure we stay on 32bit boundary */
+   if ((maxsize - currsize) < WORD_SZ)
+   break;
+   } while (currsize < maxsize);
+
+   return 0;
+}
+
+static int msm_rng_enable(struct msm_rng_priv *priv, int enable)
+{
+   u32 val;
+
+   if (enable) {
+   /* Enable PRNG only if it is not already enabled */
+   val = readl_relaxed(priv->base + PRNG_CONFIG);
+   if (val & PRNG_CONFIG_HW_ENABLE) {
+   val = readl_relaxed(priv->base + PRNG_LFSR_CFG);
+   val &= ~PRNG_LFSR_CFG_MASK;
+   val |= PRNG_LFSR_CFG_CLOCKS;
+   writel(val, priv->base + PRNG_LFSR_CFG);
+
+   val = readl_relaxed(priv->base + PRNG_CONFIG);
+   val |= PRNG_CONFIG_HW_ENABLE;
+   writel(val, priv->base + PRNG_CONFIG);
+   }
+   } else {
+   val = readl_relaxed(priv->base + PRNG_CONFIG);
+   val &= ~PRNG_CONFIG_HW_ENABLE;
+   writel(val, priv->base + PRNG_CONFIG);
+   }
+
+   return 0;
+}
+
+static int msm_rng_probe(struct udevice *dev)
+{
+   struct msm_rng_priv *priv = dev_get_priv(dev);
+
+   int ret;
+
+   priv->base 

[PATCH 6/6] IPQ40xx: Add PRNG support

2020-10-08 Thread Robert Marko
Since we now have the driver for Qualcomm PRNG HW, lets use it and add the 
necessary clocks and nodes.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 
---
 arch/arm/dts/qcom-ipq4019.dtsi| 7 +++
 arch/arm/mach-ipq40xx/clock-ipq4019.c | 4 
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/dts/qcom-ipq4019.dtsi b/arch/arm/dts/qcom-ipq4019.dtsi
index 031691e5d2..7a52ea2c4e 100644
--- a/arch/arm/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/dts/qcom-ipq4019.dtsi
@@ -60,6 +60,13 @@
u-boot,dm-pre-reloc;
};
 
+   rng: rng@22000 {
+   compatible = "qcom,prng";
+   reg = <0x22000 0x140>;
+   clocks = < GCC_PRNG_AHB_CLK>;
+   status = "disabled";
+   };
+
reset: gcc-reset@180 {
compatible = "qcom,gcc-reset-ipq4019";
reg = <0x180 0x6>;
diff --git a/arch/arm/mach-ipq40xx/clock-ipq4019.c 
b/arch/arm/mach-ipq40xx/clock-ipq4019.c
index d5b5f4cb79..31ae9719e8 100644
--- a/arch/arm/mach-ipq40xx/clock-ipq4019.c
+++ b/arch/arm/mach-ipq40xx/clock-ipq4019.c
@@ -54,6 +54,10 @@ static int msm_enable(struct clk *clk)
/* This clock is already initialized by SBL1 */
return 0;
break;
+   case GCC_PRNG_AHB_CLK: /*PRNG*/
+   /* This clock is already initialized by SBL1 */
+   return 0;
+   break;
default:
return 0;
}
-- 
2.28.0



[PATCH 2/6] IPQ40xx: Add SPI support

2020-10-08 Thread Robert Marko
Since we have SPI driver for IPQ40xx QUP SPI controller, lets add the necessary 
nodes, pinctrl and clocks.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 
---
 arch/arm/dts/qcom-ipq4019.dtsi  | 12 
 arch/arm/mach-ipq40xx/clock-ipq4019.c   | 17 +++--
 arch/arm/mach-ipq40xx/pinctrl-ipq4019.c |  3 +++
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/qcom-ipq4019.dtsi b/arch/arm/dts/qcom-ipq4019.dtsi
index e0e4188e5d..936ef74f94 100644
--- a/arch/arm/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/dts/qcom-ipq4019.dtsi
@@ -22,6 +22,7 @@
 
aliases {
serial0 = _uart1;
+   spi0 = _spi1;
};
 
reserved-memory {
@@ -89,6 +90,17 @@
gpio-count = <100>;
gpio-bank-name="soc";
#gpio-cells = <2>;
+   u-boot,dm-pre-reloc;
+   };
+
+   blsp1_spi1: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b5000 0x600>;
+   clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   u-boot,dm-pre-reloc;
};
 
usb3_ss_phy: ssphy@9a000 {
diff --git a/arch/arm/mach-ipq40xx/clock-ipq4019.c 
b/arch/arm/mach-ipq40xx/clock-ipq4019.c
index 83a688e625..d5b5f4cb79 100644
--- a/arch/arm/mach-ipq40xx/clock-ipq4019.c
+++ b/arch/arm/mach-ipq40xx/clock-ipq4019.c
@@ -2,7 +2,7 @@
 /*
  * Clock drivers for Qualcomm IPQ40xx
  *
- * Copyright (c) 2019 Sartura Ltd.
+ * Copyright (c) 2020 Sartura Ltd.
  *
  * Author: Robert Marko 
  *
@@ -24,7 +24,7 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
switch (clk->id) {
case GCC_BLSP1_UART1_APPS_CLK: /*UART1*/
/* This clock is already initialized by SBL1 */
-   return 0; 
+   return 0;
break;
default:
return 0;
@@ -47,8 +47,21 @@ static ulong msm_clk_set_rate(struct clk *clk, ulong rate)
return msm_set_rate(clk, rate);
 }
 
+static int msm_enable(struct clk *clk)
+{
+   switch (clk->id) {
+   case GCC_BLSP1_QUP1_SPI_APPS_CLK: /*SPI1*/
+   /* This clock is already initialized by SBL1 */
+   return 0;
+   break;
+   default:
+   return 0;
+   }
+}
+
 static struct clk_ops msm_clk_ops = {
.set_rate = msm_clk_set_rate,
+   .enable = msm_enable,
 };
 
 static const struct udevice_id msm_clk_ids[] = {
diff --git a/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c 
b/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
index 06a57f2e5e..1f283516cb 100644
--- a/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
+++ b/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
@@ -18,6 +18,9 @@ static const struct pinctrl_function msm_pinctrl_functions[] 
= {
{"blsp_uart0_0", 1}, /* Only for GPIO:16,17 */
{"blsp_uart0_1", 2}, /* Only for GPIO:60,61 */
{"blsp_uart1", 1},
+   {"blsp_spi0_0", 1}, /* Only for GPIO:12,13,14,15 */
+   {"blsp_spi0_1", 2}, /* Only for GPIO:54,55,56,57 */
+   {"blsp_spi1", 2},
 };
 
 static const char *ipq4019_get_function_name(struct udevice *dev,
-- 
2.28.0



[PATCH 1/6] spi: Add Qualcomm QUP SPI controller driver

2020-10-08 Thread Robert Marko
This patch adds support for the Qualcomm QUP SPI controller that is commonly 
found in most of Qualcomm SoC-s.

Driver currently supports v1.1.1, v2.1.1 and v2.2.1 HW.
FIFO and Block modes are supported, no support for DMA mode is planned.

Signed-off-by: Robert Marko 
Signed-off-by: Luka Kovacic 
Cc: Luka Perkov 
---
 MAINTAINERS  |   1 +
 doc/device-tree-bindings/spi/spi-qup.txt |  33 +
 drivers/spi/Kconfig  |  10 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-qup.c| 803 +++
 5 files changed, 848 insertions(+)
 create mode 100644 doc/device-tree-bindings/spi/spi-qup.txt
 create mode 100644 drivers/spi/spi-qup.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ed5e354873..aa6cbb965d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -241,6 +241,7 @@ F:  include/dt-bindings/clock/qcom,ipq4019-gcc.h
 F: include/dt-bindings/reset/qcom,ipq4019-reset.h
 F: drivers/reset/reset-ipq4019.c
 F: drivers/phy/phy-qcom-ipq4019-usb.c
+F: drivers/spi/spi-qup.c
 
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
diff --git a/doc/device-tree-bindings/spi/spi-qup.txt 
b/doc/device-tree-bindings/spi/spi-qup.txt
new file mode 100644
index 00..3697df2631
--- /dev/null
+++ b/doc/device-tree-bindings/spi/spi-qup.txt
@@ -0,0 +1,33 @@
+Qualcomm QUP SPI controller Device Tree Bindings
+---
+
+Required properties:
+- compatible : Should be "qcom,spi-qup-v1.1.1", "qcom,spi-qup-v2.1.1"
+   or "qcom,spi-qup-v2.2.1"
+- reg : Physical base address and size of SPI registers map.
+- clock: Clock phandle (see clock bindings for details).
+- #address-cells : Number of cells required to define a chip select
+   address on the SPI bus. Should be set to 1.
+- #size-cells : Should be zero.
+- pinctrl-names : Must be "default"
+- pinctrl-n : At least one pinctrl phandle
+- cs-gpios : Should specify GPIOs used for chipselects.
+   The gpios will be referred to as reg =  
in the
+   SPI child nodes.
+
+Optional properties:
+- num-cs : total number of chipselects
+
+Example:
+
+   blsp1_spi1: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b5000 0x600>;
+   clock = < 23>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "spi";
+   pinctrl-0 = <_spi0>;
+   num-cs = <2>;
+   cs-gpios = <_gpios 54 GPIO_ACTIVE_HIGH>, <_gpios 4 
GPIO_ACTIVE_HIGH>;
+   };
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5df97c80fa..f7a9852565 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -271,6 +271,16 @@ config PL022_SPI
  controller. If you have an embedded system with an AMBA(R)
  bus and a PL022 controller, say Y or M here.
 
+config SPI_QUP
+   bool "Qualcomm SPI controller with QUP interface"
+   depends on ARCH_IPQ40XX
+   help
+ Qualcomm Universal Peripheral (QUP) core is an AHB slave that
+ provides a common data path (an output FIFO and an input FIFO)
+ for serial peripheral interface (SPI) mini-core. SPI in master
+ mode supports up to 50MHz, up to four chip selects, programmable
+ data path from 4 bits to 32 bits and numerous protocol variants.
+
 config RENESAS_RPC_SPI
bool "Renesas RPC SPI driver"
depends on RCAR_GEN3 || RZA1
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index b5c9ff1af8..d9b5bd9b79 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_OCTEON_SPI) += octeon_spi.o
 obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
 obj-$(CONFIG_PL022_SPI) += pl022_spi.o
+obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
 obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
new file mode 100644
index 00..6f8df55fa5
--- /dev/null
+++ b/drivers/spi/spi-qup.c
@@ -0,0 +1,803 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Qualcomm QUP SPI controller
+ * FIFO and Block modes supported, no DMA
+ * mode support
+ *
+ * Copyright (c) 2020 Sartura Ltd.
+ *
+ * Author: Robert Marko 
+ * Author: Luka Kovacic 
+ *
+ * Based on stock U-boot and Linux drivers
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QUP_CONFIG 0x
+#define QUP_STATE  0x0004
+#define QUP_IO_M_MODES 0x0008
+#define QUP_SW_RESET   0x000c
+#define QUP_OPERATIONAL0x0018
+#define QUP_ERROR_FLAGS0x001c
+#define 

[PATCH 4/6] IPQ40xx: Add support for MDIO

2020-10-08 Thread Robert Marko
Lets add the necessary DTS node and pinctrl properties for newly added MDIO 
driver.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 
---
 arch/arm/dts/qcom-ipq4019.dtsi  | 28 +
 arch/arm/mach-ipq40xx/pinctrl-ipq4019.c |  4 
 2 files changed, 32 insertions(+)

diff --git a/arch/arm/dts/qcom-ipq4019.dtsi b/arch/arm/dts/qcom-ipq4019.dtsi
index 936ef74f94..031691e5d2 100644
--- a/arch/arm/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/dts/qcom-ipq4019.dtsi
@@ -103,6 +103,34 @@
u-boot,dm-pre-reloc;
};
 
+   mdio: mdio@9 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "qcom,ipq4019-mdio";
+   reg = <0x9 0x64>;
+   status = "disabled";
+
+   ethphy0: ethernet-phy@0 {
+   reg = <0>;
+   };
+
+   ethphy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+
+   ethphy2: ethernet-phy@2 {
+   reg = <2>;
+   };
+
+   ethphy3: ethernet-phy@3 {
+   reg = <3>;
+   };
+
+   ethphy4: ethernet-phy@4 {
+   reg = <4>;
+   };
+   };
+
usb3_ss_phy: ssphy@9a000 {
compatible = "qcom,usb-ss-ipq4019-phy";
#phy-cells = <0>;
diff --git a/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c 
b/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
index 1f283516cb..3e365f8cc8 100644
--- a/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
+++ b/arch/arm/mach-ipq40xx/pinctrl-ipq4019.c
@@ -21,6 +21,10 @@ static const struct pinctrl_function msm_pinctrl_functions[] 
= {
{"blsp_spi0_0", 1}, /* Only for GPIO:12,13,14,15 */
{"blsp_spi0_1", 2}, /* Only for GPIO:54,55,56,57 */
{"blsp_spi1", 2},
+   {"mdio_0", 1}, /* Only for GPIO6 */
+   {"mdio_1", 2}, /* Only for GPIO53 */
+   {"mdc_0", 1}, /* Only for GPIO7 */
+   {"mdc_1", 2}, /* Only for GPIO52 */
 };
 
 static const char *ipq4019_get_function_name(struct udevice *dev,
-- 
2.28.0



[PATCH 3/6] net: Add IPQ40xx MDIO driver

2020-10-08 Thread Robert Marko
This adds the driver for the IPQ40xx built-in MDIO.
This will be needed to support future PHY driver.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 
---
 MAINTAINERS|   1 +
 drivers/net/Kconfig|   7 ++
 drivers/net/Makefile   |   1 +
 drivers/net/mdio-ipq4019.c | 146 +
 4 files changed, 155 insertions(+)
 create mode 100644 drivers/net/mdio-ipq4019.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa6cbb965d..5f1a815c88 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -242,6 +242,7 @@ F:  include/dt-bindings/reset/qcom,ipq4019-reset.h
 F: drivers/reset/reset-ipq4019.c
 F: drivers/phy/phy-qcom-ipq4019-usb.c
 F: drivers/spi/spi-qup.c
+F: drivers/net/mdio-ipq4019.c
 
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a0d2d21a55..09a4688d69 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -701,6 +701,13 @@ config MDIO_MUX_I2CREG
  an I2C chip.  The board it was developed for uses a mux controlled by
  on-board FPGA which in turn is accessed as a chip over I2C.
 
+config MDIO_IPQ4019
+   bool "Qualcomm IPQ4019 MDIO interface support"
+   depends on DM_MDIO
+   help
+ This driver supports the MDIO interface found in Qualcomm
+ IPQ40xx series Soc-s.
+
 config MVMDIO
bool "Marvell MDIO interface support"
depends on DM_MDIO
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 03f01921ea..9cd4b36f57 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_LAN91C96) += lan91c96.o
 obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
 obj-$(CONFIG_MACB) += macb.o
 obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
+obj-$(CONFIG_MDIO_IPQ4019) += mdio-ipq4019.o
 obj-$(CONFIG_MDIO_MUX_I2CREG) += mdio_mux_i2creg.o
 obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o
 obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
diff --git a/drivers/net/mdio-ipq4019.c b/drivers/net/mdio-ipq4019.c
new file mode 100644
index 00..bc68e1d506
--- /dev/null
+++ b/drivers/net/mdio-ipq4019.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm IPQ4019 MDIO driver
+ *
+ * Copyright (c) 2020 Sartura Ltd.
+ *
+ * Author: Luka Kovacic 
+ * Author: Robert Marko 
+ *
+ * Based on Linux driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MDIO_MODE_REG   0x40
+#define MDIO_ADDR_REG   0x44
+#define MDIO_DATA_WRITE_REG 0x48
+#define MDIO_DATA_READ_REG  0x4c
+#define MDIO_CMD_REG0x50
+#define MDIO_CMD_ACCESS_BUSYBIT(16)
+#define MDIO_CMD_ACCESS_START   BIT(8)
+#define MDIO_CMD_ACCESS_CODE_READ   0
+#define MDIO_CMD_ACCESS_CODE_WRITE  1
+
+/* 0 = Clause 22, 1 = Clause 45 */
+#define MDIO_MODE_BIT   BIT(8)
+
+#define IPQ4019_MDIO_TIMEOUT1
+#define IPQ4019_MDIO_SLEEP  10
+
+struct ipq4019_mdio_priv {
+   phys_addr_t mdio_base;
+};
+
+static int ipq4019_mdio_wait_busy(struct ipq4019_mdio_priv *priv)
+{
+   unsigned int busy;
+
+   return readl_poll_sleep_timeout(priv->mdio_base + MDIO_CMD_REG, busy,
+ (busy & MDIO_CMD_ACCESS_BUSY) == 0, 
IPQ4019_MDIO_SLEEP,
+ IPQ4019_MDIO_TIMEOUT);
+}
+
+int ipq4019_mdio_read(struct udevice *dev, int addr, int devad, int reg)
+{
+   struct ipq4019_mdio_priv *priv = dev_get_priv(dev);
+   unsigned int cmd;
+
+   if (ipq4019_mdio_wait_busy(priv))
+   return -ETIMEDOUT;
+
+   /* Issue the phy address and reg */
+   writel((addr << 8) | reg, priv->mdio_base + MDIO_ADDR_REG);
+
+   cmd = MDIO_CMD_ACCESS_START | MDIO_CMD_ACCESS_CODE_READ;
+
+   /* Issue read command */
+   writel(cmd, priv->mdio_base + MDIO_CMD_REG);
+
+   /* Wait read complete */
+   if (ipq4019_mdio_wait_busy(priv))
+   return -ETIMEDOUT;
+
+   /* Read and return data */
+   return readl(priv->mdio_base + MDIO_DATA_READ_REG);
+}
+
+int ipq4019_mdio_write(struct udevice *dev, int addr, int devad,
+ int reg, u16 val)
+{
+   struct ipq4019_mdio_priv *priv = dev_get_priv(dev);
+   unsigned int cmd;
+
+   if (ipq4019_mdio_wait_busy(priv))
+   return -ETIMEDOUT;
+
+   /* Issue the phy addreass and reg */
+   writel((addr << 8) | reg, priv->mdio_base + MDIO_ADDR_REG);
+
+   /* Issue write data */
+   writel(val, priv->mdio_base + MDIO_DATA_WRITE_REG);
+
+   cmd = MDIO_CMD_ACCESS_START | MDIO_CMD_ACCESS_CODE_WRITE;
+
+   /* Issue write command */
+   writel(cmd, priv->mdio_base + MDIO_CMD_REG);
+
+   /* Wait for write complete */
+
+   if (ipq4019_mdio_wait_busy(priv))
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+static const struct mdio_ops ipq4019_mdio_ops = {
+   

[PATCH 0/6] IPQ40xx: Improve support

2020-10-08 Thread Robert Marko
This is a third patch series working towards providing
a usable U-boot support for Qualcomm IPQ40xx SoC-s.

This patch series adds SPI driver so booting is finally
possible, RNG driver for the built in pseudo RNG and
MDIO driver to prepare for future ethernet support.

Booting Linux is now possible.

Signed-off-by: Robert Marko 
Cc: Luka Perkov 

Robert Marko (6):
  spi: Add Qualcomm QUP SPI controller driver
  IPQ40xx: Add SPI support
  net: Add IPQ40xx MDIO driver
  IPQ40xx: Add support for MDIO
  rng: Add Qualcomm MSM PRNG driver
  IPQ40xx: Add PRNG support

 MAINTAINERS  |   3 +
 arch/arm/dts/qcom-ipq4019.dtsi   |  47 ++
 arch/arm/mach-ipq40xx/clock-ipq4019.c|  21 +-
 arch/arm/mach-ipq40xx/pinctrl-ipq4019.c  |   7 +
 doc/device-tree-bindings/spi/spi-qup.txt |  33 +
 drivers/net/Kconfig  |   7 +
 drivers/net/Makefile |   1 +
 drivers/net/mdio-ipq4019.c   | 146 +
 drivers/rng/Kconfig  |   7 +
 drivers/rng/Makefile |   1 +
 drivers/rng/msm_rng.c| 143 
 drivers/spi/Kconfig  |  10 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-qup.c| 803 +++
 14 files changed, 1228 insertions(+), 2 deletions(-)
 create mode 100644 doc/device-tree-bindings/spi/spi-qup.txt
 create mode 100644 drivers/net/mdio-ipq4019.c
 create mode 100644 drivers/rng/msm_rng.c
 create mode 100644 drivers/spi/spi-qup.c

-- 
2.28.0



[PATCH 1/1] lib: rsa: superfluous initialization in rsa_verify()

2020-10-08 Thread Heinrich Schuchardt
Remove initialization of ret with unused value.

Signed-off-by: Heinrich Schuchardt 
---
 lib/rsa/rsa-verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 2057f6819d..be55a4376f 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -540,7 +540,7 @@ int rsa_verify(struct image_sign_info *info,
 {
/* Reserve memory for maximum checksum-length */
uint8_t hash[info->crypto->key_len];
-   int ret = -EACCES;
+   int ret;

/*
 * Verify that the checksum-length does not exceed the
--
2.28.0



[PATCH] tools: image-host.c: use correct output format

2020-10-08 Thread Heinrich Schuchardt
When building on a 32bit host the following warning occurs:

tools/image-host.c: In function ‘fit_image_read_data’:
tools/image-host.c:296:56: warning: format ‘%ld’ expects argument of
type ‘long int’, but argument 3 has type ‘__off64_t’
{aka ‘long long int’} [-Wformat=]
   printf("File %s don't have the expected size (size=%ld, expected=%d)\n",
  ~~^
  %lld
  filename, sbuf.st_size, expected_size);

tools/image-host.c:311:62: warning: format ‘%ld’ expects argument of
type ‘long int’, but argument 4 has type ‘__off64_t’
{aka ‘long long int’} [-Wformat=]
   printf("Can't read all file %s (read %zd bytes, expexted %ld)\n",
~~^
%lld
  filename, n, sbuf.st_size);
   

Fix the format strings.

Signed-off-by: Heinrich Schuchardt 
---
 tools/image-host.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index 9a83b7f675..10e66cdaa2 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -293,8 +293,8 @@ static int fit_image_read_data(char *filename, unsigned 
char *data,

/* Check file size */
if (sbuf.st_size != expected_size) {
-   printf("File %s don't have the expected size (size=%ld, 
expected=%d)\n",
-  filename, sbuf.st_size, expected_size);
+   printf("File %s don't have the expected size (size=%lld, 
expected=%d)\n",
+  filename, (long long)sbuf.st_size, expected_size);
goto err;
}

@@ -308,8 +308,8 @@ static int fit_image_read_data(char *filename, unsigned 
char *data,

/* Check that we have read all the file */
if (n != sbuf.st_size) {
-   printf("Can't read all file %s (read %zd bytes, expexted 
%ld)\n",
-  filename, n, sbuf.st_size);
+   printf("Can't read all file %s (read %zd bytes, expexted 
%lld)\n",
+  filename, n, (long long)sbuf.st_size);
goto err;
}

--
2.26.2



[PATCH] ARM: at91: Add chip ID for SAM9X60 SiP

2020-10-08 Thread Eugen Hristev
From: Nicolas Ferre 

SAM9X60 SiP (System in Package) are added for SoC identification.

Signed-off-by: Nicolas Ferre 
---
 arch/arm/mach-at91/arm926ejs/sam9x60_devices.c | 6 ++
 arch/arm/mach-at91/include/mach/sam9x60.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-at91/arm926ejs/sam9x60_devices.c 
b/arch/arm/mach-at91/arm926ejs/sam9x60_devices.c
index d463bbc788..e3d3dd880c 100644
--- a/arch/arm/mach-at91/arm926ejs/sam9x60_devices.c
+++ b/arch/arm/mach-at91/arm926ejs/sam9x60_devices.c
@@ -44,6 +44,12 @@ char *get_cpu_name(void)
switch (extension_id) {
case ARCH_EXID_SAM9X60:
return "SAM9X60";
+   case ARCH_EXID_SAM9X60_D6K:
+   return "SAM9X60 8MiB SDRAM SiP";
+   case ARCH_EXID_SAM9X60_D5M:
+   return "SAM9X60 64MiB DDR2 SiP";
+   case ARCH_EXID_SAM9X60_D1G:
+   return "SAM9X60 128MiB DDR2 SiP";
default:
return "Unknown CPU type";
}
diff --git a/arch/arm/mach-at91/include/mach/sam9x60.h 
b/arch/arm/mach-at91/include/mach/sam9x60.h
index 0f00a9ae87..b7f43226b7 100644
--- a/arch/arm/mach-at91/include/mach/sam9x60.h
+++ b/arch/arm/mach-at91/include/mach/sam9x60.h
@@ -128,6 +128,9 @@
 #define ARCH_ID_SAM9X600x819b35a0
 #define ARCH_ID_VERSION_MASK   0x1f
 #define ARCH_EXID_SAM9X60  0x
+#define ARCH_EXID_SAM9X60_D6K  0x0011
+#define ARCH_EXID_SAM9X60_D5M  0x0001
+#define ARCH_EXID_SAM9X60_D1G  0x0010
 
 #define cpu_is_sam9x60()   (get_chip_id() == ARCH_ID_SAM9X60)
 
-- 
2.25.1



Something doesn't make sense with SPL_FIT and SPL_LOAD_FIT

2020-10-08 Thread Alex G.

Hi,

I think there's something wrong with the implementation distinction of 
SPL_FIT and SPL_LOAD_FIT.



CONFIG_SPL_FIT:
* Support Flattened Image Tree within SPL
CONFIG_SPL_LOAD_FIT:
* This option instead enables generation of a FIT (Flat Image
  Tree) which provides more flexibility.


I would expect that enabling SPL_FIT _alone_ will allow SPL to load FIT 
images. However, that's not what the code implements:



common/spl/spl_mmc.c:
int mmc_load_image_raw_sector(...)
{
if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
image_get_magic(header) == FDT_MAGIC) {


In order to "Support Flattened Image Tree within SPL" we actually need 
to enable SPL_LOAD_FIT. This has the side effect of making the u-boot 
image a FIT, which we may or may not want. I think the correct code 
should say:


if (IS_ENABLED(CONFIG_SPL_FIT))

Is this something that was overlooked (for so many years)? Is there 
something I'm missing?


Alex



Appendix A: Occurences of SPL_FIT vs SPL_LOAD_FIT

$ git grep '(IS_ENABLED(CONFIG_SPL_FIT)' -- common/spl


$ git grep '(IS_ENABLED(CONFIG_SPL_LOAD_FIT)' -- common/spl
common/spl/spl_fat.c:   } else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_mmc.c:   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_nand.c:  if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_net.c:   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_ram.c:   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_spi.c:   } else if 
(IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
common/spl/spl_ymodem.c:} else if 
(IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&

common/spl/spl_ymodem.c:if (!(IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&




Re: Please pull u-boot-cfi-flash/master

2020-10-08 Thread Tom Rini
On Thu, Oct 08, 2020 at 11:55:42AM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following cfi-flash related patches:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-mips

2020-10-08 Thread Tom Rini
On Wed, Oct 07, 2020 at 10:42:08PM +0200, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> please pull some more updates for Octeon MIPS64.
> 
> Gitlab CI:
> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/4947
> 
> 
> The following changes since commit 5dcf7cc590b348f1e730ec38242df64c179f10a8:
> 
>   Merge tag 'efi-2021-01-rc1' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-10-06 08:36:38 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-mips.git 
> tags/mips-pull-2020-10-07
> 
> for you to fetch changes up to 1471560b2c375c6e667acc896e99fa271100d299:
> 
>   mips: octeon: octeon_common.h: Increase CONFIG_SYS_BOOTM_LEN (2020-10-07 
> 20:25:58 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/2] Refactor AST2500 reset control

2020-10-08 Thread Tom Rini
On Thu, Oct 08, 2020 at 02:21:50AM +, ChiaWei Wang wrote:

> Hi Tom,
> 
> Could you help us on the review of the following patches for Aspeed platform 
> code?
> http://patchwork.ozlabs.org/project/uboot/cover/20200908072104.10067-1-chiawei_w...@aspeedtech.com/
> http://patchwork.ozlabs.org/project/uboot/cover/20200907082507.22290-1-dylan_h...@aspeedtech.com/
> 
> These patches are in fact refactoring to the existing Aspeed code structure 
> in U-Boot.
> When the refactoring is done, we would like to send a patch series for the 
> support of Aspeed next generation SoC (AST2600).

These patches seem to break qemu, or my merging of them on to the
current tree was incorrect (I had to fixup the dtsi part):
https://gitlab.denx.de/u-boot/u-boot/-/jobs/162152

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] km: fix license string and compatible strings

2020-10-08 Thread Tom Rini
On Thu, Oct 08, 2020 at 12:27:22PM +0200, Holger Brunck wrote:

> As the ownership is now Hitachi Power Grids, change the license string
> and adapt the compatible string in DTS files. For kmeter1.dts we
> change it to "keymile,KMETER1" for now, as this is then compliant with
> what is submitted to the linux kernel. All other boards don't have
> a upstreamed version in linux mainline.
> 
> Signed-off-by: Holger Brunck 
> CC: Valentin Longchamp 
> CC: Heiko Schocher 
> CC: Marek Vasut 
> CC: Tom Rini 

With the caveat that generally speaking these tags aren't supposed to
change, in order to keep compatibility, given that the changes are in
device trees not in the Linux kernel and thus also not apparently in use
in places where such compatibility is required (with the exception of
the one noted in the commit message):

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 1/2] clk: at91: clk-master: add 5th divisor for mck master

2020-10-08 Thread Eugen Hristev
clk-master can have 5 divisors with a field width of 3 bits
on some products.

Change the mask and number of divisors accordingly.

Reported-by: Mihai Sain 
Signed-off-by: Eugen Hristev 
Reviewed-by: Claudiu Beznea 
---
 drivers/clk/at91/clk-master.c | 2 +-
 drivers/clk/at91/pmc.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 759df93697..5d93e6a7e5 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -24,7 +24,7 @@
 #define MASTER_PRES_MASK   0x7
 #define MASTER_PRES_MAXMASTER_PRES_MASK
 #define MASTER_DIV_SHIFT   8
-#define MASTER_DIV_MASK0x3
+#define MASTER_DIV_MASK0x7
 
 #define PMC_MCR0x30
 #define PMC_MCR_ID_MSK GENMASK(3, 0)
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index a6a714fd22..f07f535e49 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -30,7 +30,7 @@ extern const struct clk_master_layout 
at91sam9x5_master_layout;
 
 struct clk_master_characteristics {
struct clk_range output;
-   u32 divisors[4];
+   u32 divisors[5];
u8 have_div3_pres;
 };
 
-- 
2.25.1



[PATCH 2/2] clk: at91: sama7g5: add 5th divisor for mck0 layout and characteristics

2020-10-08 Thread Eugen Hristev
This SoC has the 5th divisor for the mck0 master clock.
Adapt the characteristics accordingly.

Reported-by: Mihai Sain 
Signed-off-by: Eugen Hristev 
Reviewed-by: Claudiu Beznea 
---
 drivers/clk/at91/sama7g5.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index b96937673b..c0d9271966 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -189,13 +189,13 @@ static const struct clk_pll_layout pll_layout_divio = {
 /* MCK0 characteristics. */
 static const struct clk_master_characteristics mck0_characteristics = {
.output = { .min = 14000, .max = 2 },
-   .divisors = { 1, 2, 4, 3 },
+   .divisors = { 1, 2, 4, 3, 5 },
.have_div3_pres = 1,
 };
 
 /* MCK0 layout. */
 static const struct clk_master_layout mck0_layout = {
-   .mask = 0x373,
+   .mask = 0x773,
.pres_shift = 4,
.offset = 0x28,
 };
-- 
2.25.1



Re: [PATCH] configs: stm32mp: force empty PREBOOT

2020-10-08 Thread Tom Rini
On Wed, Oct 07, 2020 at 10:10:20AM +0200, Patrick Delaunay wrote:

> This patch remove the default preboot command 'usb start' for
> STMicroelectronics board. These command is added by the
> commit 324d77998ed6 ("Define default CONFIG_PREBOOT with right config
> option")' and commit 44758771eefb ("arm: move CONFIG_PREBOOT="usb start"
> to KConfig").
> 
> The USB storage boot (not activated in stm32mp1.h) is correctly
> managed by distro boot command 'usb_boot' (defined in
> include/config_distro_bootcmd.h, it include 'usb start')
> and USB keyboard is not supported in stm32mp15 defconfig.
> 
> So this patch avoids unnecessary USB initialization which slows
> down the start-up:
>   starting USB...
>   Bus usbh-ehci@5800d000: USB EHCI 1.00
>   scanning bus usbh-ehci@5800d000 for devices... 3 USB Device(s) found
>  scanning usb for storage devices... 1 Storage Device(s) found
> 
> Cc: Peter Robinson 
> Cc: Jonas Smedegaard 
> Cc: Neil Armstrong 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/stm32mp15_basic_defconfig   | 1 +
>  configs/stm32mp15_trusted_defconfig | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index a8c4112dbe..f937a0278d 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -19,6 +19,7 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
> +CONFIG_PREBOOT=""
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 0792884a9d..b0be064cc3 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
> +CONFIG_PREBOOT=""
>  CONFIG_SYS_PROMPT="STM32MP> "
>  CONFIG_CMD_ADTIMG=y
>  # CONFIG_CMD_ELF is not set

In this case you should disable CONFIG_USE_PREBOOT.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] phy: omap-usb2-phy: Drop usage of "ti, dis-chg-det-quirk" DT property

2020-10-08 Thread Vignesh Raghavendra
"ti,dis-chg-det-quirk" property is not part of Linux kernel DT binding
documentation.  Therefore drop this and instead use soc_device_match()
to distinguish b/w AM654 SR1.0 and SR2.0 devices similar to Linux kernel
driver.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/phy/omap-usb2-phy.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/omap-usb2-phy.c b/drivers/phy/omap-usb2-phy.c
index adc454ddd4..a981cb2f8d 100644
--- a/drivers/phy/omap-usb2-phy.c
+++ b/drivers/phy/omap-usb2-phy.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -196,6 +197,11 @@ struct phy_ops omap_usb2_phy_ops = {
.exit = omap_usb2_phy_exit,
 };
 
+static const struct soc_attr am65x_sr10_soc_devices[] = {
+   { .family = "AM65X", .revision = "SR1.0" },
+   { /* sentinel */ }
+};
+
 int omap_usb2_phy_probe(struct udevice *dev)
 {
int rc;
@@ -222,10 +228,9 @@ int omap_usb2_phy_probe(struct udevice *dev)
 * Disabling the USB2_PHY Charger Detect function will put D+
 * into the normal state.
 *
-* Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node
-* to enable this workaround for AM654x PG1.0.
+* Enable this workaround for AM654x PG1.0.
 */
-   if (dev_read_bool(dev, "ti,dis-chg-det-quirk"))
+   if (soc_device_match(am65x_sr10_soc_devices))
priv->flags |= OMAP_USB2_DISABLE_CHG_DET;
 
regmap = syscon_regmap_lookup_by_phandle(dev, "syscon-phy-power");
-- 
2.28.0



Re: [PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties

2020-10-08 Thread André Przywara
On 08/10/2020 14:10, Heinrich Schuchardt wrote:

Hi,

> On 14.06.20 17:48, Heinrich Schuchardt wrote:
>> On 6/1/20 6:20 PM, Heinrich Schuchardt wrote:
>>> On 6/1/20 4:43 PM, André Przywara wrote:
 On 01/06/2020 14:56, Heinrich Schuchardt wrote:
> Provide accurate values of the manufacturer and the product name.
>
> PINE Microsystems Inc. is referred to on
> https://www.pine64.org/contact/.

 While this patch looks alright, I wonder if we can just use the "model"
 property in the DT's root node, at least for the product name? This
 would not only avoid every defconfig to be touched, but would also cover
 all other platforms (at least ARM based ones, probably PPC and MIPS as
 well).
>>>
>>> The relevant code is in lib/smbios.c. For boards that follow the driver
>>> model you could read the model node here. But that would unnecessarily
>>> increase the code size of the resulting binary. I doubt this would find
>>> Tom's sympathy. So you would have to generate the value at compile time.
>>> I have no clue how to do that.
>>>
>>> The model property for the PINE A64 LTS is "Pine64 LTS" while the board
>>> is called "PINE A64-LTS" by the manufacturer
>>> (https://www.pine64.org/devices/single-board-computers/pine-a64-lts/).
>>> So this approach does not lead to the correct result.
>>>

 The manufacturer is less straight-forward to handle generically, but the
 string before the comma in the DT root's compatible property should give
 a hint. The Linux kernel contains a machine readable list of those
 prefixes: Documentation/devicetree/bindings/vendor-prefixes.yaml
 So we could pick the vendor at compile time based on that.
 Of course any config could still overwrite this.
>>>
>>> SMBIOS_MANUFACTURER defaults to SYS_VENDOR which is defined as "sunxi".
>>>
>>> The Linux vendor-prefix exists for ARM64 and is missing for the ARM
>>> architecture. So this cannot be a general solution.
>>>
>>> For the Pine64 A64-LTS the vendor-prefix is "allwinner". Neither "sunxi"
>>> nor "Allwinner" is the manufacturer of the PINE A64-LTS board.
>>>
>>> You have to set SMBIOS_MANUFACTURER on the board level.
>>>

 Does that make sense?
 If people agree, I could try to make a patch for that.
>>>
>>> Please, reconsider the patch as is.
>>
>> Hello Andr+e
>>
>> any comments?
>>
>> Best regards
>>
>> Heinrich
> 
> 
> Hello Andre,
> 
> did you work on your idea of using the model property? Or can Jagan take
> the patch as is?

No, I didn't have time to tackle this yet.

So yes, please Jagan, take this patch as it.

Cheers,
Andre

>>
>>>
>>> Best regards
>>>
>>> Heinrich
>>>

 Cheers,
 Andre.

>
> Signed-off-by: Heinrich Schuchardt 
> ---
>   configs/pine64-lts_defconfig | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/configs/pine64-lts_defconfig
> b/configs/pine64-lts_defconfig
> index ef108a1a31..a8ff34a376 100644
> --- a/configs/pine64-lts_defconfig
> +++ b/configs/pine64-lts_defconfig
> @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949
>   CONFIG_MMC0_CD_PIN=""
>   CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>   CONFIG_SPL_SPI_SUNXI=y
> +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS"
>   # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>   CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts"
>   CONFIG_SUN8I_EMAC=y
>   CONFIG_USB_EHCI_HCD=y
>   CONFIG_USB_OHCI_HCD=y
> +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc."
> --
> 2.26.2
>

>>>
>>
> 



[PATCH] ARM: dts: stm32: Do not set eth1addr if KS8851 has EEPROM

2020-10-08 Thread Marek Vasut
In case the KS8851 has external EEPROM attached to it, do not set
eth1addr at all. The network stack will read the MAC out of the
KS8851 and set eth1addr accordingly.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 board/dhelectronics/dh_stm32mp1/board.c | 40 ++---
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index c9abe3cc6d..f42d395098 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -81,6 +81,11 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
+#define KS_CCR 0x08
+#define KS_CCR_EEPROM  BIT(9)
+#define KS_BE0 BIT(12)
+#define KS_BE1 BIT(13)
+
 int setup_mac_address(void)
 {
unsigned char enetaddr[6];
@@ -97,12 +102,39 @@ int setup_mac_address(void)
if (off < 0) {
/* ethernet1 is not present in the system */
skip_eth1 = true;
-   } else {
-   ret = eth_env_get_enetaddr("eth1addr", enetaddr);
-   if (ret)/* eth1addr is already set */
-   skip_eth1 = true;
+   goto out_set_ethaddr;
+   }
+
+   ret = eth_env_get_enetaddr("eth1addr", enetaddr);
+   if (ret) {
+   /* eth1addr is already set */
+   skip_eth1 = true;
+   goto out_set_ethaddr;
+   }
+
+   ret = fdt_node_check_compatible(gd->fdt_blob, off, "micrel,ks8851-mll");
+   if (ret)
+   goto out_set_ethaddr;
+
+   /*
+* KS8851 with EEPROM may use custom MAC from EEPROM, read
+* out the KS8851 CCR register to determine whether EEPROM
+* is present. If EEPROM is present, it must contain valid
+* MAC address.
+*/
+   u32 reg, ccr;
+   reg = fdt_get_base_address(gd->fdt_blob, off);
+   if (!reg)
+   goto out_set_ethaddr;
+
+   writew(KS_BE0 | KS_BE1 | KS_CCR, reg + 2);
+   ccr = readw(reg);
+   if (ccr & KS_CCR_EEPROM) {
+   skip_eth1 = true;
+   goto out_set_ethaddr;
}
 
+out_set_ethaddr:
if (skip_eth0 && skip_eth1)
return 0;
 
-- 
2.28.0



[PATCH] net: ks8851: Implement EEPROM MAC address readout

2020-10-08 Thread Marek Vasut
In case there is an EEPROM attached to the KS8851 MAC and the EEPROM
contains a valid MAC address, the MAC address is loaded into the NIC
registers on power on. Read the MAC address out of the NIC registers
and provide it to U-Boot.

Signed-off-by: Marek Vasut 
Cc: Eugen Hristev 
Cc: Joe Hershberger 
---
 drivers/net/ks8851_mll.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/net/ks8851_mll.c b/drivers/net/ks8851_mll.c
index d22668446d..58e065cdcc 100644
--- a/drivers/net/ks8851_mll.c
+++ b/drivers/net/ks8851_mll.c
@@ -622,6 +622,34 @@ static int ks8851_write_hwaddr(struct udevice *dev)
return 0;
 }
 
+static int ks8851_read_rom_hwaddr(struct udevice *dev)
+{
+   struct ks_net *ks = dev_get_priv(dev);
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+   u16 addrl, addrm, addrh;
+
+   /* No EEPROM means no valid MAC address. */
+   if (!(ks_rdreg16(ks, KS_CCR) & CCR_EEPROM))
+   return -EINVAL;
+
+   /*
+* If the EEPROM contains valid MAC address, it is loaded into
+* the NIC on power on. Read the MAC out of the NIC registers.
+*/
+   addrl = ks_rdreg16(ks, KS_MARL);
+   addrm = ks_rdreg16(ks, KS_MARM);
+   addrh = ks_rdreg16(ks, KS_MARH);
+
+   pdata->enetaddr[0] = (addrh >> 8) & 0xff;
+   pdata->enetaddr[1] = addrh & 0xff;
+   pdata->enetaddr[2] = (addrm >> 8) & 0xff;
+   pdata->enetaddr[3] = addrm & 0xff;
+   pdata->enetaddr[4] = (addrl >> 8) & 0xff;
+   pdata->enetaddr[5] = addrl & 0xff;
+
+   return !is_valid_ethaddr(pdata->enetaddr);
+}
+
 static int ks8851_bind(struct udevice *dev)
 {
return device_set_name(dev, dev->name);
@@ -654,6 +682,7 @@ static const struct eth_ops ks8851_ops = {
.send   = ks8851_send,
.recv   = ks8851_recv,
.write_hwaddr   = ks8851_write_hwaddr,
+   .read_rom_hwaddr = ks8851_read_rom_hwaddr,
 };
 
 static const struct udevice_id ks8851_ids[] = {
-- 
2.28.0



Re: [PATCH 1/1] sunxi: Pine64-LTS: SMBIOS properties

2020-10-08 Thread Heinrich Schuchardt
On 14.06.20 17:48, Heinrich Schuchardt wrote:
> On 6/1/20 6:20 PM, Heinrich Schuchardt wrote:
>> On 6/1/20 4:43 PM, André Przywara wrote:
>>> On 01/06/2020 14:56, Heinrich Schuchardt wrote:
 Provide accurate values of the manufacturer and the product name.

 PINE Microsystems Inc. is referred to on
 https://www.pine64.org/contact/.
>>>
>>> While this patch looks alright, I wonder if we can just use the "model"
>>> property in the DT's root node, at least for the product name? This
>>> would not only avoid every defconfig to be touched, but would also cover
>>> all other platforms (at least ARM based ones, probably PPC and MIPS as
>>> well).
>>
>> The relevant code is in lib/smbios.c. For boards that follow the driver
>> model you could read the model node here. But that would unnecessarily
>> increase the code size of the resulting binary. I doubt this would find
>> Tom's sympathy. So you would have to generate the value at compile time.
>> I have no clue how to do that.
>>
>> The model property for the PINE A64 LTS is "Pine64 LTS" while the board
>> is called "PINE A64-LTS" by the manufacturer
>> (https://www.pine64.org/devices/single-board-computers/pine-a64-lts/).
>> So this approach does not lead to the correct result.
>>
>>>
>>> The manufacturer is less straight-forward to handle generically, but the
>>> string before the comma in the DT root's compatible property should give
>>> a hint. The Linux kernel contains a machine readable list of those
>>> prefixes: Documentation/devicetree/bindings/vendor-prefixes.yaml
>>> So we could pick the vendor at compile time based on that.
>>> Of course any config could still overwrite this.
>>
>> SMBIOS_MANUFACTURER defaults to SYS_VENDOR which is defined as "sunxi".
>>
>> The Linux vendor-prefix exists for ARM64 and is missing for the ARM
>> architecture. So this cannot be a general solution.
>>
>> For the Pine64 A64-LTS the vendor-prefix is "allwinner". Neither "sunxi"
>> nor "Allwinner" is the manufacturer of the PINE A64-LTS board.
>>
>> You have to set SMBIOS_MANUFACTURER on the board level.
>>
>>>
>>> Does that make sense?
>>> If people agree, I could try to make a patch for that.
>>
>> Please, reconsider the patch as is.
>
> Hello Andr+e
>
> any comments?
>
> Best regards
>
> Heinrich


Hello Andre,

did you work on your idea of using the model property? Or can Jagan take
the patch as is?

Best regards

Heinrich

>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Cheers,
>>> Andre.
>>>

 Signed-off-by: Heinrich Schuchardt 
 ---
   configs/pine64-lts_defconfig | 2 ++
   1 file changed, 2 insertions(+)

 diff --git a/configs/pine64-lts_defconfig
 b/configs/pine64-lts_defconfig
 index ef108a1a31..a8ff34a376 100644
 --- a/configs/pine64-lts_defconfig
 +++ b/configs/pine64-lts_defconfig
 @@ -8,8 +8,10 @@ CONFIG_DRAM_ZQ=3881949
   CONFIG_MMC0_CD_PIN=""
   CONFIG_MMC_SUNXI_SLOT_EXTRA=2
   CONFIG_SPL_SPI_SUNXI=y
 +CONFIG_SMBIOS_PRODUCT_NAME="PINE A64-LTS"
   # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
   CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts"
   CONFIG_SUN8I_EMAC=y
   CONFIG_USB_EHCI_HCD=y
   CONFIG_USB_OHCI_HCD=y
 +CONFIG_SMBIOS_MANUFACTURER="PINE Microsystems Inc."
 --
 2.26.2

>>>
>>
>



Re: [PATCH v3 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-10-08 Thread Heinrich Schuchardt
On 25.08.20 18:57, Simon Glass wrote:
> On Mon, 24 Aug 2020 at 22:15, Heinrich Schuchardt  wrote:
>>
>> On 7/25/20 8:18 PM, Heinrich Schuchardt wrote:
>>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
>>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
>>> relocation.
>>>
>>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
>>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>>>
>>> CONFIG_LOG=Y is another setting requiring additional early malloc
>>> area, cf. log_init().
>>>
>>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
>>> we see as output in main U-Boot
>>>
>>> alloc_simple() alloc space exhausted
>>>
>>> With this patch the default values of SYS_MALLOC_F_LEN and
>>> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> Reviewed-by: Jagan Teki 
>>
>> With current pine64-lts_defconfig we get a warning:
>>
>> "alloc space exhausted"
>>
>> So, please, merge the patch.
>
> Reviewed-by: Simon Glass 
>
>>
>> Best regards
>>
>> Heinrich

Hello Jagan, hello Maxime,

it is merge window but I could not find this patch in

https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi

Please, take care of the patch.

Best regards

Heinrich


Re: [PATCH v2 2/2] timer: Return count from timer_ops.get_count

2020-10-08 Thread Claudiu.Beznea


On 07.10.2020 21:37, Sean Anderson wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> No timer drivers return an error from get_count. Instead of possibly
> returning an error, just return the count directly.
> 
> Signed-off-by: Sean Anderson 

For mchp-pit64b-timer:
Reviewed-by: Claudiu Beznea 

> ---
> 
> Changes in v2:
> - mchp-pit64b was added since v1, so convert it
> - Document when get_count may be called, and what assumptions the timer
>   subsystem makes about drivers
> 
>  arch/riscv/lib/andes_plmt.c   |  6 ++
>  arch/riscv/lib/sifive_clint.c |  6 ++
>  drivers/timer/ag101p_timer.c  |  5 ++---
>  drivers/timer/altera_timer.c  |  6 ++
>  drivers/timer/arc_timer.c |  6 ++
>  drivers/timer/ast_timer.c |  6 ++
>  drivers/timer/atcpit100_timer.c   |  5 ++---
>  drivers/timer/atmel_pit_timer.c   |  6 ++
>  drivers/timer/cadence-ttc.c   |  6 ++
>  drivers/timer/dw-apb-timer.c  |  6 ++
>  drivers/timer/mchp-pit64b-timer.c |  6 ++
>  drivers/timer/mpc83xx_timer.c |  6 ++
>  drivers/timer/mtk_timer.c |  6 ++
>  drivers/timer/nomadik-mtu-timer.c |  6 ++
>  drivers/timer/omap-timer.c|  6 ++
>  drivers/timer/ostm_timer.c|  6 ++
>  drivers/timer/riscv_timer.c   | 21 +
>  drivers/timer/rockchip_timer.c|  5 ++---
>  drivers/timer/sandbox_timer.c |  6 ++
>  drivers/timer/sti-timer.c |  6 ++
>  drivers/timer/stm32_timer.c   |  6 ++
>  drivers/timer/timer-uclass.c  |  3 ++-
>  drivers/timer/tsc_timer.c |  6 ++
>  include/timer.h   |  9 ++---
>  24 files changed, 59 insertions(+), 97 deletions(-)
> 
> diff --git a/arch/riscv/lib/andes_plmt.c b/arch/riscv/lib/andes_plmt.c
> index a28c14c1eb..cec86718c7 100644
> --- a/arch/riscv/lib/andes_plmt.c
> +++ b/arch/riscv/lib/andes_plmt.c
> @@ -17,11 +17,9 @@
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base))
> 
> -static int andes_plmt_get_count(struct udevice *dev, u64 *count)
> +static u64 andes_plmt_get_count(struct udevice *dev)
>  {
> -   *count = readq((void __iomem *)MTIME_REG(dev->priv));
> -
> -   return 0;
> +   return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
> 
>  static const struct timer_ops andes_plmt_ops = {
> diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
> index c9704c596f..a5572cb825 100644
> --- a/arch/riscv/lib/sifive_clint.c
> +++ b/arch/riscv/lib/sifive_clint.c
> @@ -62,11 +62,9 @@ int riscv_get_ipi(int hart, int *pending)
> return 0;
>  }
> 
> -static int sifive_clint_get_count(struct udevice *dev, u64 *count)
> +static u64 sifive_clint_get_count(struct udevice *dev)
>  {
> -   *count = readq((void __iomem *)MTIME_REG(dev->priv));
> -
> -   return 0;
> +   return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
> 
>  static const struct timer_ops sifive_clint_ops = {
> diff --git a/drivers/timer/ag101p_timer.c b/drivers/timer/ag101p_timer.c
> index c011906b93..23ad5b2b67 100644
> --- a/drivers/timer/ag101p_timer.c
> +++ b/drivers/timer/ag101p_timer.c
> @@ -62,14 +62,13 @@ struct atftmr_timer_platdata {
> struct atftmr_timer_regs *regs;
>  };
> 
> -static int atftmr_timer_get_count(struct udevice *dev, u64 *count)
> +static u64 atftmr_timer_get_count(struct udevice *dev)
>  {
> struct atftmr_timer_platdata *plat = dev->platdata;
> struct atftmr_timer_regs *const regs = plat->regs;
> u32 val;
> val = readl(>t3_counter);
> -   *count = timer_conv_64(val);
> -   return 0;
> +   return timer_conv_64(val);
>  }
> 
>  static int atftmr_timer_probe(struct udevice *dev)
> diff --git a/drivers/timer/altera_timer.c b/drivers/timer/altera_timer.c
> index 6cb2923e0b..ccc164ee17 100644
> --- a/drivers/timer/altera_timer.c
> +++ b/drivers/timer/altera_timer.c
> @@ -32,7 +32,7 @@ struct altera_timer_platdata {
> struct altera_timer_regs *regs;
>  };
> 
> -static int altera_timer_get_count(struct udevice *dev, u64 *count)
> +static u64 altera_timer_get_count(struct udevice *dev)
>  {
> struct altera_timer_platdata *plat = dev->platdata;
> struct altera_timer_regs *const regs = plat->regs;
> @@ -44,9 +44,7 @@ static int altera_timer_get_count(struct udevice *dev, u64 
> *count)
> /* Read timer value */
> val = readl(>snapl) & 0x;
> val |= (readl(>snaph) & 0x) << 16;
> -   *count = timer_conv_64(~val);
> -
> -   return 0;
> +   return timer_conv_64(~val);
>  }
> 
>  static int altera_timer_probe(struct udevice *dev)
> diff --git a/drivers/timer/arc_timer.c b/drivers/timer/arc_timer.c
> index 8c574ec5af..2dea9f40cb 100644
> --- a/drivers/timer/arc_timer.c
> +++ b/drivers/timer/arc_timer.c
> @@ -26,7 +26,7 @@ struct arc_timer_priv {
> uint timer_id;
>  };
> 
> 

Re: [PATCH] timer: mchp-pit64b: add support for pit64b

2020-10-08 Thread Claudiu.Beznea


On 07.10.2020 20:49, Sean Anderson wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> On 9/7/20 11:36 AM, Claudiu Beznea wrote:
>> Add support for Microchip PIT64B timer. The timer is 64 bit length and
>> is used as a free running counter (in continuous mode with highest values
>> for period registers). The clock feeding the timer would be no more
>> than 12.5MHz.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  drivers/timer/Kconfig |   7 +++
>>  drivers/timer/Makefile|   1 +
>>  drivers/timer/mchp-pit64b-timer.c | 109 
>> ++
>>  3 files changed, 117 insertions(+)
>>  create mode 100644 drivers/timer/mchp-pit64b-timer.c
>>
>> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
>> index 5f4bc6edb67b..13a98be4ab92 100644
>> --- a/drivers/timer/Kconfig
>> +++ b/drivers/timer/Kconfig
>> @@ -181,4 +181,11 @@ config MTK_TIMER
>> Select this to enable support for the timer found on
>> MediaTek devices.
>>
>> +config MCHP_PIT64B_TIMER
>> + bool "Microchip 64-bit periodic interval timer support"
>> + depends on TIMER
>> + help
>> +   Select this to enable support for Microchip 64-bit periodic
>> +   interval timer.
>> +
>>  endmenu
>> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
>> index fa35bea6c5b2..4744a8d9c93c 100644
>> --- a/drivers/timer/Makefile
>> +++ b/drivers/timer/Makefile
>> @@ -21,3 +21,4 @@ obj-$(CONFIG_STI_TIMER) += sti-timer.o
>>  obj-$(CONFIG_STM32_TIMER)+= stm32_timer.o
>>  obj-$(CONFIG_X86_TSC_TIMER)  += tsc_timer.o
>>  obj-$(CONFIG_MTK_TIMER)  += mtk_timer.o
>> +obj-$(CONFIG_MCHP_PIT64B_TIMER)  += mchp-pit64b-timer.o
>> diff --git a/drivers/timer/mchp-pit64b-timer.c 
>> b/drivers/timer/mchp-pit64b-timer.c
>> new file mode 100644
>> index ..ead8c9b84ad5
>> --- /dev/null
>> +++ b/drivers/timer/mchp-pit64b-timer.c
>> @@ -0,0 +1,109 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * 64-bit Periodic Interval Timer driver
>> + *
>> + * Copyright (C) 2020 Microchip Technology Inc. and its subsidiaries
>> + *
>> + * Author: Claudiu Beznea 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MCHP_PIT64B_CR   0x00/* Control Register */
>> +#define  MCHP_PIT64B_CR_STARTBIT(0)
>> +#define  MCHP_PIT64B_CR_SWRSTBIT(8)
>> +#define MCHP_PIT64B_MR   0x04/* Mode Register */
>> +#define  MCHP_PIT64B_MR_CONT BIT(0)
>> +#define MCHP_PIT64B_LSB_PR   0x08/* LSB Period Register */
>> +#define MCHP_PIT64B_MSB_PR   0x0C/* MSB Period Register */
>> +#define MCHP_PIT64B_TLSBR0x20/* Timer LSB Register */
>> +#define MCHP_PIT64B_TMSBR0x24/* Timer MSB Register */
>> +
>> +struct mchp_pit64b_priv {
>> + void __iomem *base;
>> +};
>> +
>> +static int mchp_pit64b_get_count(struct udevice *dev, u64 *count)
>> +{
>> + struct mchp_pit64b_priv *priv = dev_get_priv(dev);
>> +
>> + u32 lsb = readl(priv->base + MCHP_PIT64B_TLSBR);
>> + u32 msb = readl(priv->base + MCHP_PIT64B_TMSBR);
> 
> Is there a chance of rollover here? E.g. lets say the 64-bit counter is
> 0x___ when we read lsb, but it increments to
> 0x_0001__ when we read msb. Then the next time we read the
> timer, it will look like we jumped backward in time.

This should not happen as the hardware takes care of it as follows:
when using a 64 bit period TLSB must be read first, followed by the
read of TMSB. This sequence generates an atomic read of the 64 bit
timer value whatever the lapse of time between the accesses.

Thank you,
Claudiu Beznea

> 
> One way to get around this is by doing something like
> 
> do {
> msb = readl(priv->base + MCHP_PIT64B_TMSBR);
> lsb = readl(priv->base + MCHP_PIT64B_TLSBR);
> } while (msb != readl(priv->base + MCHP_PIT64B_TMSBR));
> 
> That way, if we ever roll-over between the two reads, we just redo the
> lsb read. This is the method used by drivers/timer/riscv_timer.c on
> 32-bit systems.
> 
> --Sean
> 
>> +
>> + *count = ((u64)msb << 32) | lsb;
>> +
>> + return 0;
>> +}
>> +
>> +static int mchp_pit64b_probe(struct udevice *dev)
>> +{
>> + struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
>> + struct mchp_pit64b_priv *priv = dev_get_priv(dev);
>> + struct clk clk;
>> + ulong rate;
>> + int ret;
>> +
>> + priv->base = dev_read_addr_ptr(dev);
>> + if (IS_ERR(priv->base))
>> + return PTR_ERR(priv->base);
>> +
>> + ret = clk_get_by_index(dev, 0, );
>> + if (ret)
>> + return ret;
>> +
>> + ret = clk_enable();
>> + if (ret)
>> + return ret;
>> +
>> + rate = clk_get_rate();
>> + if (!rate) {
>> + clk_disable();
>> +  

cache: Misaligned operation at range

2020-10-08 Thread Shlomi Vaknin
Hi!

I am using stm32mp157c-dk2 board. I added support for usb ethernet gadget
(the short patch is attached). Then, when I booted the board I see the
following output when running ping:

###
STM32MP> ping 10.0.0.1
using dwc2-udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
MAC f8:dc:7a:00:00:02
HOST MAC f8:dc:7a:00:00:01
RNDIS ready
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
USB RNDIS network up!
CACHE: Misaligned operation at range [ddcfbcc4, ddcfbd04]
Using usb_ether device
CACHE: Misaligned operation at range [dbc3c678, dbc3c6f8]
CACHE: Misaligned operation at range [dbc3c678, dbc3c6f8]
host 10.0.0.1 is alive
##

Is there a way to get rid of the warning? Is the warning hides a real
problem?
I saw some discussions and patches regarding this issue so I am not sure if
the is some problem here.

Thanks!
Shlomi
From 1c2e523b753ca491e3b6cbbb90547969e404494d Mon Sep 17 00:00:00 2001
From: Shlomi Vaknin 
Date: Thu, 8 Oct 2020 12:03:39 +0300
Subject: [PATCH] stm32mp1: add support for usb ether gadget.

Add the dwc2-udc to available controllers and call
init function of ether gadget in stm32 board late init.

Signed-off-by: Shlomi Vaknin 
---
 board/st/stm32mp1/stm32mp1.c  | 4 
 drivers/usb/gadget/gadget_chips.h | 8 
 2 files changed, 12 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 3b677d339b..b46eec2e1c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -699,6 +699,10 @@ int board_late_init(void)
 	/* for DK1/DK2 boards */
 	board_check_usb_power();
 
+#if defined(CONFIG_USB_ETHER)
+usb_ether_init();
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/usb/gadget/gadget_chips.h b/drivers/usb/gadget/gadget_chips.h
index 587204cfb7..270d3f0058 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -161,6 +161,12 @@
 #define gadget_is_max3420(g)0
 #endif
 
+#ifdef CONFIG_USB_GADGET_DWC2_OTG
+#define gadget_is_dwc2(g)(!strcmp("dwc2-udc", (g)->name))
+#else
+#define gadget_is_dwc2(g)0
+#endif
+
 /**
  * usb_gadget_controller_number - support bcdDevice id convention
  * @gadget: the controller being driven
@@ -224,5 +230,7 @@ static inline int usb_gadget_controller_number(struct usb_gadget *gadget)
 		return 0x24;
 	else if (gadget_is_max3420(gadget))
 		return 0x25;
+	else if (gadget_is_dwc2(gadget))
+return 0x26;
 	return -ENOENT;
 }
-- 
2.25.1



RE: [PATCH 1/2] km: adapt defines and variables for new memory layout

2020-10-08 Thread Holger Brunck
Hi Heiko,

> > Due to increasing kernel image sizes we get problems when
> > decompressing the kernel image. To fix this we need to change the
> > addresses where we load and where we extract the kernel. Also we need
> > to adapt the address where to load the CRAMFS image and where to load
> the DTB file.
> > While a it also harmonize all boards for PPC and ARM to have the same
> > values.
> >
> > Signed-off-by: Holger Brunck 
> > CC: Valentin Longchamp 
> > CC: Heiko Schocher 
> > CC: Tom Rini 
> > ---
> >   board/keymile/Kconfig   | 12 +++-
> >   include/configs/km/keymile-common.h |  1 +
> >   include/configs/km/km-powerpc.h |  4 
> >   include/configs/km/km_arm.h |  3 +++
> >   4 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/board/keymile/Kconfig b/board/keymile/Kconfig index
> > e20c017436..e5906906f3 100644
> > --- a/board/keymile/Kconfig
> > +++ b/board/keymile/Kconfig
> > @@ -37,26 +37,20 @@ config KM_RESERVED_PRAM
> >
> >   config KM_CRAMFS_ADDR
> >   hex "CRAMFS Address"
> > - default 0x240 if ARCH_KIRKWOOD
> > - default 0xC0 if MPC83xx
> > - default 0x200 if MPC85xx
> > + default 0x300
> >   depends on !ARCH_SOCFPGA
> >   help
> > Start address of the CRAMFS containing the Linux kernel.
> >
> >   config KM_KERNEL_ADDR
> >   hex "Kernel Load Address"
> > - default 0x200 if ARCH_KIRKWOOD
> > - default 0x40 if MPC83xx
> > - default 0x100 if MPC85xx || ARCH_SOCFPGA
> > + default 0x200
> >   help
> > Address where to load Linux kernel in RAM.
> >
> >   config KM_FDT_ADDR
> >   hex "FDT Load Address"
> > - default 0x23E if ARCH_KIRKWOOD || ARCH_SOCFPGA
> > - default 0xB8 if MPC83xx
> > - default 0x1F8 if MPC85xx
> > + default 0x2FC
> >   help
> > Address where to load flattened device tree in RAM.
> >
> > diff --git a/include/configs/km/keymile-common.h
> > b/include/configs/km/keymile-common.h
> > index e9e3981060..6a8c41529f 100644
> > --- a/include/configs/km/keymile-common.h
> > +++ b/include/configs/km/keymile-common.h
> > @@ -160,6 +160,7 @@
> >   "pnvramsize=" __stringify(CONFIG_KM_PNVRAM) "\0"\
> >   "testbootcmd=setenv boot_bank ${test_bank}; "   \
> >   "run ${subbootcmds}; reset\0"   \
> > + "env_version=1\0"   \
> >   ""
> 
> What is this? This change is not related with commit text ... or?
>

We need a variable so that the userspace knows that we have the new
values or not. We need to be compatible to older u-boot and in this case
we change in linux the u-boot variables. I will add a comment to the
commit message.
 
> >   #ifndef CONFIG_KM_DEF_ENV
> > diff --git a/include/configs/km/km-powerpc.h
> > b/include/configs/km/km-powerpc.h index fde8487178..267b124165
> 100644
> > --- a/include/configs/km/km-powerpc.h
> > +++ b/include/configs/km/km-powerpc.h
> > @@ -21,6 +21,9 @@
> >   /* Reserve 4 MB for malloc */
> >   #define CONFIG_SYS_MALLOC_LEN   (4 * 1024 * 1024)
> >
> > +/* Increase max size of compressed kernel */
> > +#define CONFIG_SYS_BOOTM_LEN (32 << 20)
> > +
> >
> /**
> 
> >* (PRAM usage)
> >* ... ---
> > @@ -53,6 +56,7 @@
> >   "protect on " __stringify(BOOTFLASH_START) "  +${filesize}\0"\
> >   "set_fdthigh=true\0"\
> >   "checkfdt=true\0"   \
> > + "bootm_mapsize=0x200\0" \
> >   ""
> 
> Couldn;t you use __stringify(CONFIG_SYS_BOOTM_LEN) ?
> 

good point, I'll change that.

Best regards
Holger



[PATCH v2] km: fix license string and compatible strings

2020-10-08 Thread Holger Brunck
As the ownership is now Hitachi Power Grids, change the license string
and adapt the compatible string in DTS files. For kmeter1.dts we
change it to "keymile,KMETER1" for now, as this is then compliant with
what is submitted to the linux kernel. All other boards don't have
a upstreamed version in linux mainline.

Signed-off-by: Holger Brunck 
CC: Valentin Longchamp 
CC: Heiko Schocher 
CC: Marek Vasut 
CC: Tom Rini 
---
 arch/arm/dts/socfpga_arria5_secu1.dts  | 4 ++--
 arch/powerpc/dts/km8309-uboot.dtsi | 2 +-
 arch/powerpc/dts/km8321-uboot.dtsi | 2 +-
 arch/powerpc/dts/km8321.dtsi   | 2 +-
 arch/powerpc/dts/km836x-uboot.dtsi | 2 +-
 arch/powerpc/dts/km836x.dtsi   | 2 +-
 arch/powerpc/dts/kmcoge5ne-uboot.dtsi  | 2 +-
 arch/powerpc/dts/kmcoge5ne.dts | 4 ++--
 arch/powerpc/dts/kmeter1-uboot.dtsi| 2 +-
 arch/powerpc/dts/kmeter1.dts   | 4 ++--
 arch/powerpc/dts/kmopti2.dts   | 4 ++--
 arch/powerpc/dts/kmsupc5.dts   | 4 ++--
 arch/powerpc/dts/kmsupm5.dts   | 4 ++--
 arch/powerpc/dts/kmtegr1.dts   | 4 ++--
 arch/powerpc/dts/kmtepr2.dts   | 4 ++--
 arch/powerpc/dts/kmtuge1.dts   | 4 ++--
 arch/powerpc/dts/kmtuxa1.dts   | 4 ++--
 board/keymile/km83xx/km83xx.c  | 2 +-
 board/keymile/secu1/MAINTAINERS| 2 +-
 board/keymile/secu1/Makefile   | 2 +-
 board/keymile/secu1/socfpga.c  | 2 +-
 include/configs/socfpga_arria5_secu1.h | 2 +-
 22 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm/dts/socfpga_arria5_secu1.dts 
b/arch/arm/dts/socfpga_arria5_secu1.dts
index 820e29a..cfe3e67 100644
--- a/arch/arm/dts/socfpga_arria5_secu1.dts
+++ b/arch/arm/dts/socfpga_arria5_secu1.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2016-2020 ABB
+ * Copyright (C) 2016-2020 Hitachi Power Grids
  */
 
 #include "socfpga_arria5.dtsi"
@@ -8,7 +8,7 @@
 #include 
 
 / {
-   model = "ABB SoC SECU1 Board";
+   model = "Hitachi PG SoC SECU1 Board";
compatible = "altr,socfpga-secu1", "altr,socfpga";
 
chosen {
diff --git a/arch/powerpc/dts/km8309-uboot.dtsi 
b/arch/powerpc/dts/km8309-uboot.dtsi
index c44ce7d..a93bdb2 100644
--- a/arch/powerpc/dts/km8309-uboot.dtsi
+++ b/arch/powerpc/dts/km8309-uboot.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA 8309 U-Boot specific Device Tree Source parts
+ * Hitachi Power Grids 8309 U-Boot specific Device Tree Source parts
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/km8321-uboot.dtsi 
b/arch/powerpc/dts/km8321-uboot.dtsi
index 3488260..fd11fe6 100644
--- a/arch/powerpc/dts/km8321-uboot.dtsi
+++ b/arch/powerpc/dts/km8321-uboot.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA 8321 U-Boot specific Device Tree Source parts
+ * Hitachi Power Grids 8321 U-Boot specific Device Tree Source parts
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/km8321.dtsi b/arch/powerpc/dts/km8321.dtsi
index e493613..6c36017 100644
--- a/arch/powerpc/dts/km8321.dtsi
+++ b/arch/powerpc/dts/km8321.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA km8321 common ports Device Tree Source
+ * Hitachi Power Grids km8321 common ports Device Tree Source
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/km836x-uboot.dtsi 
b/arch/powerpc/dts/km836x-uboot.dtsi
index ac5339e..5c78529 100644
--- a/arch/powerpc/dts/km836x-uboot.dtsi
+++ b/arch/powerpc/dts/km836x-uboot.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA km836x U-Boot specific Device Tree Source parts
+ * Hitachi Power Grids km836x U-Boot specific Device Tree Source parts
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/km836x.dtsi b/arch/powerpc/dts/km836x.dtsi
index a8c83fc..94b71cd 100644
--- a/arch/powerpc/dts/km836x.dtsi
+++ b/arch/powerpc/dts/km836x.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA km836x common ports Device Tree Source
+ * Hitachi Power Grids km836x common ports Device Tree Source
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/kmcoge5ne-uboot.dtsi 
b/arch/powerpc/dts/kmcoge5ne-uboot.dtsi
index 6a5e74f..69392bb 100644
--- a/arch/powerpc/dts/kmcoge5ne-uboot.dtsi
+++ b/arch/powerpc/dts/kmcoge5ne-uboot.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA kmcoge5ne U-Boot specific Device Tree Source parts
+ * Hitachi Power Grids kmcoge5ne U-Boot specific Device Tree Source parts
  *
  * Copyright (C) 2020 Heiko Schocher 
  *
diff --git a/arch/powerpc/dts/kmcoge5ne.dts b/arch/powerpc/dts/kmcoge5ne.dts
index 467e5bd..0dad793 100644
--- a/arch/powerpc/dts/kmcoge5ne.dts
+++ b/arch/powerpc/dts/kmcoge5ne.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * ABB PGGA KMCOGE5ne Device Tree Source
+ * Hitachi Power Grids KMCOGE5ne Device Tree Source
  *
  * 

RE: [PATCH] km: fix license string and compatible strings

2020-10-08 Thread Holger Brunck
> Am 07.10.2020 um 17:46 schrieb Tom Rini:
> > On Wed, Oct 07, 2020 at 03:53:35PM +0200, Holger Brunck wrote:
> >
> >> As the ownership is now Hitachi Power Grids, change the license
> >> string and adapt the compatible string in DTS files.
> >>
> >> Signed-off-by: Holger Brunck 
> >> CC: Valentin Longchamp 
> >> CC: Heiko Schocher 
> >> CC: Marek Vasut 
> >> CC: Tom Rini 
> >
> > Please get this done in upstream Linux dts files first please (or link
> > where it's accepted in next or whatever), thanks!
> 
> Hmm... Ok, for the boards, which are in linux, this are (If I searched
> correct):
> 
> kmeter1.dts
> kmcent2.dts
> kmcoge4.dts
> 
> All the other (also the arm based board) are not in linux mainline...
>

Only board we need to change is kmeter1 then as this is the only one I change
in my patch. I will re-use the string from Linux mainline.

Best regards
Holger



Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread Stefan Roese

On 08.10.20 12:15, Heinrich Schuchardt wrote:

On 08.10.20 11:49, Stefan Roese wrote:

On 08.10.20 10:39, Heinrich Schuchardt wrote:

On 08.10.20 09:08, Stefan Roese wrote:

On 24.09.20 01:22, Andre Przywara wrote:

The cfi-flash driver uses an open-coded version of the generic
algorithm to decode and translate multiple frames of a "reg" property.

This starts off the wrong foot by using the address-cells and
size-cells
properties of *this* very node, and not of the parent. This somewhat
happened to work back when we were using a wrong default size of 2,
but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
correct value if #size-cells property is not present").

Instead of fixing the reinvented wheel, just use the generic function
that does all of this properly.

This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
a wrong flash base address:
DRAM:  1 GiB
Flash: "Synchronous Abort" handler, esr 0x9644
elr: 000211dc lr : 000211b0 (reloc)
elr: 7ff5e1dc lr : 7ff5e1b0
x0 : 00f0 x1 : 7ff5e1d8
x2 : 7edfbc48 x3 : 
x4 :  x5 : 00f0
x6 : 7edfbc2c x7 : 
x8 : 7ffd8d70 x9 : 000c
x10: 0403 x11: 0055
    

Signed-off-by: Andre Przywara 


Applied to u-boot-cfi-flash/master

Thanks,
Stefan


---
Changes v1 .. v2:
- Use live tree compatible function
- Drop unneeded size variable

    drivers/mtd/cfi_flash.c | 24 ++--
    1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b7289ba5394..9e3a652f445 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
    #ifdef CONFIG_CFI_FLASH /* for driver model */
    static int cfi_flash_probe(struct udevice *dev)
    {
-    const fdt32_t *cell;
-    int addrc, sizec;
-    int len, idx;
+    fdt_addr_t addr;
+    int idx;
    -    addrc = dev_read_addr_cells(dev);
-    sizec = dev_read_size_cells(dev);
-
-    /* decode regs; there may be multiple reg tuples. */
-    cell = dev_read_prop(dev, "reg", );
-    if (!cell)
-    return -ENOENT;
-    idx = 0;
-    len /= sizeof(fdt32_t);
-    while (idx < len) {
-    phys_addr_t addr;
-
-    addr = dev_translate_address(dev, cell + idx);
+    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
+    addr = dev_read_addr_index(dev, idx);


Why don't you additionally read the size here to populate
flash_info[].size?

fdt_size_t size;
addr = dev_read_addr_size_index(dev, idx, );


It was not done before this either. IIRC, then the size is auto detected
by querying the flash chip.

Do you see any issue without this? Feel free to send a follow up patch
is something needs to get fixed / tuned.


Yes, there is a function flash_get_size().

I am not worried about this special patch but about the logic of the
driver as a whole.

Why does function flash_get_size() consider CONFIG_SYS_FLASH_BANKS_SIZES
but not the size information from the DTB?


All this CFI code is pretty ancient. Many years before devicetree was
introduced to U-Boot. IIRC, there were many boards that could be
equipped with different CFI flash chips (different sizes). That's were
this flash_get_size() etc comes from.


Do we need
CONFIG_SYS_FLASH_BANKS_SIZES and weak function cfi_flash_bank_size() at all?


I agree that this code could benefit from some "cleanup", removing
some of the old legacy stuff. Perhaps I will find some time to tackle
this in the near future. But if someone beats me here, I would not
be too disappointed. ;)

Thanks,
Stefan


Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread André Przywara
On 08/10/2020 11:15, Heinrich Schuchardt wrote:

Hi,

> On 08.10.20 11:49, Stefan Roese wrote:
>> On 08.10.20 10:39, Heinrich Schuchardt wrote:
>>> On 08.10.20 09:08, Stefan Roese wrote:
 On 24.09.20 01:22, Andre Przywara wrote:
> The cfi-flash driver uses an open-coded version of the generic
> algorithm to decode and translate multiple frames of a "reg" property.
>
> This starts off the wrong foot by using the address-cells and
> size-cells
> properties of *this* very node, and not of the parent. This somewhat
> happened to work back when we were using a wrong default size of 2,
> but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
> correct value if #size-cells property is not present").
>
> Instead of fixing the reinvented wheel, just use the generic function
> that does all of this properly.
>
> This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
> a wrong flash base address:
> DRAM:  1 GiB
> Flash: "Synchronous Abort" handler, esr 0x9644
> elr: 000211dc lr : 000211b0 (reloc)
> elr: 7ff5e1dc lr : 7ff5e1b0
> x0 : 00f0 x1 : 7ff5e1d8
> x2 : 7edfbc48 x3 : 
> x4 :  x5 : 00f0
> x6 : 7edfbc2c x7 : 
> x8 : 7ffd8d70 x9 : 000c
> x10: 0403 x11: 0055
>    
>
> Signed-off-by: Andre Przywara 

 Applied to u-boot-cfi-flash/master

 Thanks,
 Stefan

> ---
> Changes v1 .. v2:
> - Use live tree compatible function
> - Drop unneeded size variable
>
>    drivers/mtd/cfi_flash.c | 24 ++--
>    1 file changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index b7289ba5394..9e3a652f445 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
>    #ifdef CONFIG_CFI_FLASH /* for driver model */
>    static int cfi_flash_probe(struct udevice *dev)
>    {
> -    const fdt32_t *cell;
> -    int addrc, sizec;
> -    int len, idx;
> +    fdt_addr_t addr;
> +    int idx;
>    -    addrc = dev_read_addr_cells(dev);
> -    sizec = dev_read_size_cells(dev);
> -
> -    /* decode regs; there may be multiple reg tuples. */
> -    cell = dev_read_prop(dev, "reg", );
> -    if (!cell)
> -    return -ENOENT;
> -    idx = 0;
> -    len /= sizeof(fdt32_t);
> -    while (idx < len) {
> -    phys_addr_t addr;
> -
> -    addr = dev_translate_address(dev, cell + idx);
> +    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
> +    addr = dev_read_addr_index(dev, idx);
>>>
>>> Why don't you additionally read the size here to populate
>>> flash_info[].size?
>>>
>>> fdt_size_t size;
>>> addr = dev_read_addr_size_index(dev, idx, );
>>
>> It was not done before this either. IIRC, then the size is auto detected
>> by querying the flash chip.
>>
>> Do you see any issue without this? Feel free to send a follow up patch
>> is something needs to get fixed / tuned.
> 
> Yes, there is a function flash_get_size().
> 
> I am not worried about this special patch but about the logic of the
> driver as a whole.
> 
> Why does function flash_get_size() consider CONFIG_SYS_FLASH_BANKS_SIZES
> but not the size information from the DTB? Do we need
> CONFIG_SYS_FLASH_BANKS_SIZES and weak function cfi_flash_bank_size() at all?

That's a good point: given that this symbol is in config_whitelist.txt,
it's probably some legacy from the dawn of time.

Maybe for some hacks, as those lines in cfi_flash.c suggest:

max_size = cfi_flash_bank_size(banknum);
if (max_size && info->size > max_size) {
debug("[truncated from %ldMiB]", info->size >> 20);
info->size = max_size;
}


Maybe someone mounted a bigger flash chip than there was space in the
MMIO frame?

But I totally agree that this is very confusing and should either be
removed entirely (preferred, but would need to be tested on those boards
using it) or extended to cover DTBs as well.

Cheers,
Andre


Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread Heinrich Schuchardt
On 08.10.20 11:49, Stefan Roese wrote:
> On 08.10.20 10:39, Heinrich Schuchardt wrote:
>> On 08.10.20 09:08, Stefan Roese wrote:
>>> On 24.09.20 01:22, Andre Przywara wrote:
 The cfi-flash driver uses an open-coded version of the generic
 algorithm to decode and translate multiple frames of a "reg" property.

 This starts off the wrong foot by using the address-cells and
 size-cells
 properties of *this* very node, and not of the parent. This somewhat
 happened to work back when we were using a wrong default size of 2,
 but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
 correct value if #size-cells property is not present").

 Instead of fixing the reinvented wheel, just use the generic function
 that does all of this properly.

 This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
 a wrong flash base address:
 DRAM:  1 GiB
 Flash: "Synchronous Abort" handler, esr 0x9644
 elr: 000211dc lr : 000211b0 (reloc)
 elr: 7ff5e1dc lr : 7ff5e1b0
 x0 : 00f0 x1 : 7ff5e1d8
 x2 : 7edfbc48 x3 : 
 x4 :  x5 : 00f0
 x6 : 7edfbc2c x7 : 
 x8 : 7ffd8d70 x9 : 000c
 x10: 0403 x11: 0055
    

 Signed-off-by: Andre Przywara 
>>>
>>> Applied to u-boot-cfi-flash/master
>>>
>>> Thanks,
>>> Stefan
>>>
 ---
 Changes v1 .. v2:
 - Use live tree compatible function
 - Drop unneeded size variable

    drivers/mtd/cfi_flash.c | 24 ++--
    1 file changed, 6 insertions(+), 18 deletions(-)

 diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
 index b7289ba5394..9e3a652f445 100644
 --- a/drivers/mtd/cfi_flash.c
 +++ b/drivers/mtd/cfi_flash.c
 @@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
    #ifdef CONFIG_CFI_FLASH /* for driver model */
    static int cfi_flash_probe(struct udevice *dev)
    {
 -    const fdt32_t *cell;
 -    int addrc, sizec;
 -    int len, idx;
 +    fdt_addr_t addr;
 +    int idx;
    -    addrc = dev_read_addr_cells(dev);
 -    sizec = dev_read_size_cells(dev);
 -
 -    /* decode regs; there may be multiple reg tuples. */
 -    cell = dev_read_prop(dev, "reg", );
 -    if (!cell)
 -    return -ENOENT;
 -    idx = 0;
 -    len /= sizeof(fdt32_t);
 -    while (idx < len) {
 -    phys_addr_t addr;
 -
 -    addr = dev_translate_address(dev, cell + idx);
 +    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
 +    addr = dev_read_addr_index(dev, idx);
>>
>> Why don't you additionally read the size here to populate
>> flash_info[].size?
>>
>> fdt_size_t size;
>> addr = dev_read_addr_size_index(dev, idx, );
>
> It was not done before this either. IIRC, then the size is auto detected
> by querying the flash chip.
>
> Do you see any issue without this? Feel free to send a follow up patch
> is something needs to get fixed / tuned.

Yes, there is a function flash_get_size().

I am not worried about this special patch but about the logic of the
driver as a whole.

Why does function flash_get_size() consider CONFIG_SYS_FLASH_BANKS_SIZES
but not the size information from the DTB? Do we need
CONFIG_SYS_FLASH_BANKS_SIZES and weak function cfi_flash_bank_size() at all?

Best regards

Heinrich

>
> Thanks,
> Stefan



Please pull u-boot-cfi-flash/master

2020-10-08 Thread Stefan Roese

Hi Tom,

please pull the following cfi-flash related patches:


- Fix devicetree address determination seen on QEMU ARM64
- Use DMA for reads is available


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=55=results

Thanks,
Stefan

The following changes since commit 42378e3cd2432e0353cdcc1789039293e4b46252:

  Merge tag 'dm-pull-6oct20' of git://git.denx.de/u-boot-dm (2020-10-06 
13:59:01 -0400)


are available in the Git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git

for you to fetch changes up to 492b9917c684bbfd42479e049c00b1e502f8b53f:

  cfi_flash: Fix devicetree address determination (2020-10-08 09:04:41 
+0200)



Andre Przywara (1):
  cfi_flash: Fix devicetree address determination

Vignesh Raghavendra (2):
  dma: Reduce error level when DMA channel type does not exist
  mtd: cfi_mtd: Use DMA for reads

 drivers/dma/dma-uclass.c |  4 ++--
 drivers/mtd/cfi_flash.c  | 24 ++--
 drivers/mtd/cfi_mtd.c|  4 +++-
 3 files changed, 11 insertions(+), 21 deletions(-)


Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread Stefan Roese

On 08.10.20 10:39, Heinrich Schuchardt wrote:

On 08.10.20 09:08, Stefan Roese wrote:

On 24.09.20 01:22, Andre Przywara wrote:

The cfi-flash driver uses an open-coded version of the generic
algorithm to decode and translate multiple frames of a "reg" property.

This starts off the wrong foot by using the address-cells and size-cells
properties of *this* very node, and not of the parent. This somewhat
happened to work back when we were using a wrong default size of 2,
but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
correct value if #size-cells property is not present").

Instead of fixing the reinvented wheel, just use the generic function
that does all of this properly.

This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
a wrong flash base address:
DRAM:  1 GiB
Flash: "Synchronous Abort" handler, esr 0x9644
elr: 000211dc lr : 000211b0 (reloc)
elr: 7ff5e1dc lr : 7ff5e1b0
x0 : 00f0 x1 : 7ff5e1d8
x2 : 7edfbc48 x3 : 
x4 :  x5 : 00f0
x6 : 7edfbc2c x7 : 
x8 : 7ffd8d70 x9 : 000c
x10: 0403 x11: 0055
   

Signed-off-by: Andre Przywara 


Applied to u-boot-cfi-flash/master

Thanks,
Stefan


---
Changes v1 .. v2:
- Use live tree compatible function
- Drop unneeded size variable

   drivers/mtd/cfi_flash.c | 24 ++--
   1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b7289ba5394..9e3a652f445 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
   #ifdef CONFIG_CFI_FLASH /* for driver model */
   static int cfi_flash_probe(struct udevice *dev)
   {
-    const fdt32_t *cell;
-    int addrc, sizec;
-    int len, idx;
+    fdt_addr_t addr;
+    int idx;
   -    addrc = dev_read_addr_cells(dev);
-    sizec = dev_read_size_cells(dev);
-
-    /* decode regs; there may be multiple reg tuples. */
-    cell = dev_read_prop(dev, "reg", );
-    if (!cell)
-    return -ENOENT;
-    idx = 0;
-    len /= sizeof(fdt32_t);
-    while (idx < len) {
-    phys_addr_t addr;
-
-    addr = dev_translate_address(dev, cell + idx);
+    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
+    addr = dev_read_addr_index(dev, idx);


Why don't you additionally read the size here to populate flash_info[].size?

fdt_size_t size;
addr = dev_read_addr_size_index(dev, idx, );


It was not done before this either. IIRC, then the size is auto detected
by querying the flash chip.

Do you see any issue without this? Feel free to send a follow up patch
is something needs to get fixed / tuned.

Thanks,
Stefan


Re: [PATCH 1/1] sandbox: make SDL window resizable

2020-10-08 Thread Heinrich Schuchardt
On 05.10.20 03:41, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 28 Sep 2020 at 19:11, Heinrich Schuchardt  wrote:
>>
>> Without resizing the SDL window showed by
>>
>> ./u-boot -D -l
>>
>> is not legible on a high resolution screen.
>>
>> Start with a maximized window and allow resizing.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  arch/sandbox/cpu/sdl.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>
> Have you troubled the --double_lcd option?

That looks better.

This option is not documented in doc/arch/sandbox.rst.

>
> Does this have any effect on performance?

With --double_lcd you are already doing a resize operation. I could not
observe any performance loss for a maximized window. The BitBlt
operations in X11 are well accelerated by current GPUs.

>
> I actually don't like this as it makes the text hard to read, and full
> screen is annoying. I wonder if this should be a flag?

I understand that you do not want the window maximized. But is anything
wrong about making the window resizable (SDL_WINDOW_RESIZABLE)?

Shall I update the patch accordingly?

Best regards

Heinrich

>
>> diff --git a/arch/sandbox/cpu/sdl.c b/arch/sandbox/cpu/sdl.c
>> index 7dc3dab32e..911247123f 100644
>> --- a/arch/sandbox/cpu/sdl.c
>> +++ b/arch/sandbox/cpu/sdl.c
>> @@ -127,7 +127,9 @@ int sandbox_sdl_init_display(int width, int height, int 
>> log2_bpp,
>> sdl.pitch = sdl.width * sdl.depth / 8;
>> SDL_Window *screen = SDL_CreateWindow("U-Boot", 
>> SDL_WINDOWPOS_UNDEFINED,
>>   SDL_WINDOWPOS_UNDEFINED,
>> - sdl.vis_width, sdl.vis_height, 
>> 0);
>> + sdl.vis_width, sdl.vis_height,
>> + SDL_WINDOW_MAXIMIZED |
>> + SDL_WINDOW_RESIZABLE);
>> if (!screen) {
>> printf("Unable to initialise SDL screen: %s\n",
>>SDL_GetError());
>> --
>> 2.28.0
>>
>
> Regards,
> Simon
>



[PATCH v5 2/2] mmc: renesas-sdhi: Add R8A774A1 SDHI quirks

2020-10-08 Thread Biju Das
Add various SDHI quirks for R8A774A1 SoC.

Signed-off-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
 v5 : New Patch
---
 drivers/mmc/renesas-sdhi.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index d80b3fc28f..40e01ed890 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -870,7 +870,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
/* HS400 is not supported on H3 ES1.x and M3W ES1.0, ES1.1 */
if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
(rmobile_get_cpu_rev_integer() <= 1)) ||
-   ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+   (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() < 2)))
plat->cfg.host_caps &= ~MMC_MODE_HS400;
@@ -878,7 +879,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
/* H3 ES2.0, ES3.0 and M3W ES1.2 and M3N bad taps */
if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
(rmobile_get_cpu_rev_integer() >= 2)) ||
-   ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+   (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() == 2)) ||
(rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77965))
@@ -894,7 +896,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
}
 
/* M3W ES1.2 can use HS400 with manual adjustment */
-   if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+(rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() == 2)) {
priv->adjust_hs400_enable = true;
@@ -904,7 +907,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
}
 
/* M3W ES1.x for x>2 can use HS400 with manual adjustment and taps */
-   if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+(rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() > 2)) {
priv->adjust_hs400_enable = true;
@@ -933,7 +937,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
/* H3 ES1.x, ES2.0 and M3W ES1.0, ES1.1, ES1.2 uses 4 tuning taps */
if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
(rmobile_get_cpu_rev_integer() <= 2)) ||
-   ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+   (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() <= 2)))
priv->nrtaps = 4;
@@ -943,7 +948,8 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
/* H3 ES1.x and M3W ES1.0 uses bit 17 for DTRAEND */
if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
(rmobile_get_cpu_rev_integer() <= 1)) ||
-   ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) ||
+   (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A774A1)) &&
(rmobile_get_cpu_rev_integer() == 1) &&
(rmobile_get_cpu_rev_fraction() == 0)))
priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD;
-- 
2.17.1



[PATCH v5 1/2] arm: rmobile: Add RZ/G2[HMNE] SoC support

2020-10-08 Thread Biju Das
RZ/G2 SoC's are identical to R-Car Gen3 SoC's apart from some
automotive peripherals.

RZ/G2H (R8A774E1) = R-Car H3-N (R8A77951).
RZ/G2M (R8A774A1) = R-Car M3-W (R8A77960).
RZ/G2N (R8A774B1) = R-Car M3-N (R8A77965).
RZ/G2E (R8A774C0) = R-Car E3 (R8A77990).

As the devices are the same they also have the same SoC PRR
register values. This means we cannot rely upon the PRODUCT
field to tell us whether an R-Car or RZ/G device is being used.

For RZ/G2 SoC identification the compatible string from TFA is
matched against the list of compatible strings in struct
tfa_cpuinfo.

Signed-off-by: Biju Das 
Reviewed-by: Lad Prabhakar 
---
 v4->v5
   * Add support for unique identification of RZ/G2 CPU types

 v3->v4
   * Dropped CPU info reporting logic for RZ/G2. Will address this later.
   * Added PRRID's for RZG2[HMNE]
   (Ref: 
https://patchwork.ozlabs.org/project/uboot/patch/20201001103658.4835-1-biju.das...@bp.renesas.com/)

 v2->v3  
   * Reworked as per Marek's suggestion
   * Added rzg2_get_cpu_type function to get cpu_type by matching TFA 
compatible string
   * Removed SoC family type Enum
   (Ref: 
https://patchwork.ozlabs.org/project/uboot/patch/20200922160317.16296-2-biju.das...@bp.renesas.com/)

 v1->v2:
  * Add comment's related to loop logic
   (ref: 
https://patchwork.ozlabs.org/project/uboot/patch/20200918160307.14323-1-biju.das...@bp.renesas.com/)

 v1:
  * New patch
  
(ref:https://patchwork.ozlabs.org/project/uboot/patch/20200915143630.7678-4-biju.das...@bp.renesas.com/)
---
 arch/arm/mach-rmobile/cpu_info-rcar.c| 29 +-
 arch/arm/mach-rmobile/cpu_info.c | 10 ++--
 arch/arm/mach-rmobile/include/mach/rmobile.h | 57 ++--
 3 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-rmobile/cpu_info-rcar.c 
b/arch/arm/mach-rmobile/cpu_info-rcar.c
index 5bde24ae0e..ee56864b61 100644
--- a/arch/arm/mach-rmobile/cpu_info-rcar.c
+++ b/arch/arm/mach-rmobile/cpu_info-rcar.c
@@ -6,12 +6,37 @@
  */
 #include 
 #include 
+#include 
 
+#define PRODUCT_MASK   0xff
 #define PRR_MASK   0x7fff
 #define R8A7796_REV_1_00x5200
 #define R8A7796_REV_1_10x5210
 #define R8A7796_REV_1_30x5211
 
+static const struct udevice_id tfa_cpu_info[] = {
+   { .compatible = "renesas,r8a774a1", .data = RMOBILE_CPU_TYPE_R8A774A1 },
+   { .compatible = "renesas,r8a774b1", .data = RMOBILE_CPU_TYPE_R8A774B1 },
+   { .compatible = "renesas,r8a774c0", .data = RMOBILE_CPU_TYPE_R8A774C0 },
+   { .compatible = "renesas,r8a774e1", .data = RMOBILE_CPU_TYPE_R8A774E1 },
+   { },
+};
+
+static const u32 get_cpu_type(u32 soc_id)
+{
+   const struct udevice_id *of_match = tfa_cpu_info;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(tfa_cpu_info); i++) {
+   if (soc_id == (of_match->data & PRODUCT_MASK) &&
+   of_machine_is_compatible(of_match->compatible))
+   return of_match->data;
+   of_match++;
+   }
+
+   return soc_id;
+}
+
 static u32 rmobile_get_prr(void)
 {
 #ifdef CONFIG_RCAR_GEN3
@@ -23,7 +48,9 @@ static u32 rmobile_get_prr(void)
 
 u32 rmobile_get_cpu_type(void)
 {
-   return (rmobile_get_prr() & 0x7F00) >> 8;
+   const u32 soc_id = (rmobile_get_prr() & 0x7F00) >> 8;
+
+   return get_cpu_type(soc_id);
 }
 
 u32 rmobile_get_cpu_rev_integer(void)
diff --git a/arch/arm/mach-rmobile/cpu_info.c b/arch/arm/mach-rmobile/cpu_info.c
index fdbbd72e28..b19b7e3044 100644
--- a/arch/arm/mach-rmobile/cpu_info.c
+++ b/arch/arm/mach-rmobile/cpu_info.c
@@ -3,12 +3,12 @@
  * (C) Copyright 2012 Nobuhiro Iwamatsu 
  * (C) Copyright 2012 Renesas Solutions Corp.
  */
-#include 
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_ARCH_CPU_INIT
@@ -59,6 +59,10 @@ static const struct {
 } rmobile_cpuinfo[] = {
{ RMOBILE_CPU_TYPE_SH73A0, "SH73A0" },
{ RMOBILE_CPU_TYPE_R8A7740, "R8A7740" },
+   { RMOBILE_CPU_TYPE_R8A774A1, "R8A774A1" },
+   { RMOBILE_CPU_TYPE_R8A774B1, "R8A774B1" },
+   { RMOBILE_CPU_TYPE_R8A774C0, "R8A774C0" },
+   { RMOBILE_CPU_TYPE_R8A774E1, "R8A774E1" },
{ RMOBILE_CPU_TYPE_R8A7790, "R8A7790" },
{ RMOBILE_CPU_TYPE_R8A7791, "R8A7791" },
{ RMOBILE_CPU_TYPE_R8A7792, "R8A7792" },
diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h 
b/arch/arm/mach-rmobile/include/mach/rmobile.h
index a50249dc96..6d638466e9 100644
--- a/arch/arm/mach-rmobile/include/mach/rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
@@ -24,21 +24,48 @@
 #endif
 #endif /* CONFIG_ARCH_RMOBILE */
 
-/* PRR CPU IDs */
-#define RMOBILE_CPU_TYPE_SH73A00x37
-#define RMOBILE_CPU_TYPE_R8A7740   0x40
-#define RMOBILE_CPU_TYPE_R8A7790   0x45
-#define RMOBILE_CPU_TYPE_R8A7791   0x47
-#define RMOBILE_CPU_TYPE_R8A7792   0x4A
-#define RMOBILE_CPU_TYPE_R8A7793   0x4B
-#define 

Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread Heinrich Schuchardt
On 08.10.20 09:08, Stefan Roese wrote:
> On 24.09.20 01:22, Andre Przywara wrote:
>> The cfi-flash driver uses an open-coded version of the generic
>> algorithm to decode and translate multiple frames of a "reg" property.
>>
>> This starts off the wrong foot by using the address-cells and size-cells
>> properties of *this* very node, and not of the parent. This somewhat
>> happened to work back when we were using a wrong default size of 2,
>> but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
>> correct value if #size-cells property is not present").
>>
>> Instead of fixing the reinvented wheel, just use the generic function
>> that does all of this properly.
>>
>> This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
>> a wrong flash base address:
>> DRAM:  1 GiB
>> Flash: "Synchronous Abort" handler, esr 0x9644
>> elr: 000211dc lr : 000211b0 (reloc)
>> elr: 7ff5e1dc lr : 7ff5e1b0
>> x0 : 00f0 x1 : 7ff5e1d8
>> x2 : 7edfbc48 x3 : 
>> x4 :  x5 : 00f0
>> x6 : 7edfbc2c x7 : 
>> x8 : 7ffd8d70 x9 : 000c
>> x10: 0403 x11: 0055
>>   
>>
>> Signed-off-by: Andre Przywara 
>
> Applied to u-boot-cfi-flash/master
>
> Thanks,
> Stefan
>
>> ---
>> Changes v1 .. v2:
>> - Use live tree compatible function
>> - Drop unneeded size variable
>>
>>   drivers/mtd/cfi_flash.c | 24 ++--
>>   1 file changed, 6 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
>> index b7289ba5394..9e3a652f445 100644
>> --- a/drivers/mtd/cfi_flash.c
>> +++ b/drivers/mtd/cfi_flash.c
>> @@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
>>   #ifdef CONFIG_CFI_FLASH /* for driver model */
>>   static int cfi_flash_probe(struct udevice *dev)
>>   {
>> -    const fdt32_t *cell;
>> -    int addrc, sizec;
>> -    int len, idx;
>> +    fdt_addr_t addr;
>> +    int idx;
>>   -    addrc = dev_read_addr_cells(dev);
>> -    sizec = dev_read_size_cells(dev);
>> -
>> -    /* decode regs; there may be multiple reg tuples. */
>> -    cell = dev_read_prop(dev, "reg", );
>> -    if (!cell)
>> -    return -ENOENT;
>> -    idx = 0;
>> -    len /= sizeof(fdt32_t);
>> -    while (idx < len) {
>> -    phys_addr_t addr;
>> -
>> -    addr = dev_translate_address(dev, cell + idx);
>> +    for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
>> +    addr = dev_read_addr_index(dev, idx);

Why don't you additionally read the size here to populate flash_info[].size?

fdt_size_t size;
addr = dev_read_addr_size_index(dev, idx, );

Best regards

Heinrich

>> +    if (addr == FDT_ADDR_T_NONE)
>> +    break;
>>     flash_info[cfi_flash_num_flash_banks].dev = dev;
>>   flash_info[cfi_flash_num_flash_banks].base = addr;
>>   cfi_flash_num_flash_banks++;
>> -
>> -    idx += addrc + sizec;
>>   }
>>   gd->bd->bi_flashstart = flash_info[0].base;
>>  
>
>
> Viele Grüße,
> Stefan
>



Re: [fs/squashfs PATCH v3 2/2] avoid 64-bit divisions on 32-bit

2020-10-08 Thread Mauro Condarelli



On 10/8/20 9:34 AM, Miquel Raynal wrote:
> Hi Mauro,
>
> Mauro Condarelli  wrote on Thu,  8 Oct 2020 00:30:21
> +0200:
>
>> Use macros in linux/kernel.h to avoid 64-bit divisions.
> s/in/from/?
My command of English language is far from perfect.
I meant those macros are used in Linux kernel.
Feel free to rewrite as needed.

>> These divisions are needed to convert from file length (potentially
>> over 32-bit range) to block number, so result and remainder are
>> guaranteed to fit in 32-bit integers.
>>
>> Some 32bit architectures (notably mipsel) lack an implementation of
>> __udivdi3() compiler helper function in reduced libgcc.
>>
>> Standard strategy is to use macros and do_div() inline.
> You don't use do_div(), here, is it a leftover or do you mean that this
> is a generic solution?
I meant I use the macros in SquashFS code, but macros use
do_div() inline function to do their job.
Should I rephrase to be more explicit?


>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v3:
>> - converted to use DIV_ROUND_(UP|DOWN)_ULL() macros (Miquel Raynal).
>> - split commits to handle unrelated Kconfig warning (Thomas Petazzoni).
>>
>> Changes in v2:
>> - replace division with right shift (Daniel Schwierzeck).
>> - remove vocore2-specific change (Daniel Schwierzeck).
>> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
>>
>>  fs/squashfs/sqfs.c   | 32 
>>  fs/squashfs/sqfs_inode.c |  7 ---
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
>> index 15208b4dab..ef9f5e3449 100644
>> --- a/fs/squashfs/sqfs.c
>> +++ b/fs/squashfs/sqfs.c
>> @@ -10,14 +10,14 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  
>>  #include "sqfs_decompressor.h"
>>  #include "sqfs_filesystem.h"
>> @@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, 
>> u64 *offset)
>>  u64 start_, table_size;
>>  
>>  table_size = le64_to_cpu(end) - le64_to_cpu(start);
>> -start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
>> +start_ = DIV_ROUND_DOWN_ULL(le64_to_cpu(start), ctxt.cur_dev->blksz);
>>  *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>>  
>> -return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
>> +return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
>> ctxt.cur_dev->log2blksz;
This is definitely a leftover.
It should be:

  return DIV_ROUND_UP_ULL(table_size + *offset, ctxt.cur_dev->blksz);

> I don't recall Joao using this kind of structure but I might be wrong.
> Can you just verify that this is not a leftover from a previous change?
I will correct, retest and resend.

> Also, as you state in the commit message, all these divisions serve the
> same purpose: translating a file length to a block number. I think a
> helper would be very nice here, something like
>
>   sqfs_length_to_block_id(ctxt, length);
I will consider it.

>
> Thanks,
> Miquèl
>



Re: [fs/squashfs PATCH v3 2/2] avoid 64-bit divisions on 32-bit

2020-10-08 Thread Thomas Petazzoni
Hello,

The commit title lacks a proper prefix, it should start with
"fs/squashfs". You confused the prefix of the commit title with the
"subject prefix" of format-patch.

On Thu,  8 Oct 2020 00:30:21 +0200
Mauro Condarelli  wrote:

> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> index 15208b4dab..ef9f5e3449 100644
> --- a/fs/squashfs/sqfs.c
> +++ b/fs/squashfs/sqfs.c
> @@ -10,14 +10,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 

Do we need both ?

>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 

Is this change related ?

>  #include "sqfs_decompressor.h"
>  #include "sqfs_filesystem.h"
> @@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
> *offset)
>   u64 start_, table_size;
>  
>   table_size = le64_to_cpu(end) - le64_to_cpu(start);
> - start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
> + start_ = DIV_ROUND_DOWN_ULL(le64_to_cpu(start), ctxt.cur_dev->blksz);
>   *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>  
> - return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
> + return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
> ctxt.cur_dev->log2blksz;

Why are you not using DIV_ROUND_UP_ULL() here ?

Thanks,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [fs/squashfs PATCH v3 2/2] avoid 64-bit divisions on 32-bit

2020-10-08 Thread Miquel Raynal
Hi Mauro,

Mauro Condarelli  wrote on Thu,  8 Oct 2020 00:30:21
+0200:

> Use macros in linux/kernel.h to avoid 64-bit divisions.

s/in/from/?

> 
> These divisions are needed to convert from file length (potentially
> over 32-bit range) to block number, so result and remainder are
> guaranteed to fit in 32-bit integers.
> 
> Some 32bit architectures (notably mipsel) lack an implementation of
> __udivdi3() compiler helper function in reduced libgcc.
> 
> Standard strategy is to use macros and do_div() inline.

You don't use do_div(), here, is it a leftover or do you mean that this
is a generic solution?

> 
> Signed-off-by: Mauro Condarelli 
> ---
> 
> Changes in v3:
> - converted to use DIV_ROUND_(UP|DOWN)_ULL() macros (Miquel Raynal).
> - split commits to handle unrelated Kconfig warning (Thomas Petazzoni).
> 
> Changes in v2:
> - replace division with right shift (Daniel Schwierzeck).
> - remove vocore2-specific change (Daniel Schwierzeck).
> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
> 
>  fs/squashfs/sqfs.c   | 32 
>  fs/squashfs/sqfs_inode.c |  7 ---
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> index 15208b4dab..ef9f5e3449 100644
> --- a/fs/squashfs/sqfs.c
> +++ b/fs/squashfs/sqfs.c
> @@ -10,14 +10,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "sqfs_decompressor.h"
>  #include "sqfs_filesystem.h"
> @@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
> *offset)
>   u64 start_, table_size;
>  
>   table_size = le64_to_cpu(end) - le64_to_cpu(start);
> - start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
> + start_ = DIV_ROUND_DOWN_ULL(le64_to_cpu(start), ctxt.cur_dev->blksz);
>   *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>  
> - return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
> + return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
> ctxt.cur_dev->log2blksz;

I don't recall Joao using this kind of structure but I might be wrong.
Can you just verify that this is not a leftover from a previous change?

Also, as you state in the commit message, all these divisions serve the
same purpose: translating a file length to a block number. I think a
helper would be very nice here, something like

sqfs_length_to_block_id(ctxt, length);

Thanks,
Miquèl


Re: [fs/squashfs PATCH v3 1/2] Add warning for dynamic memory usage.

2020-10-08 Thread Miquel Raynal
Hi Mauro,

Mauro Condarelli  wrote on Thu,  8 Oct 2020 00:30:20
+0200:

> SquashFS may need a large amount of dynamic memory fot its buffers,
> especially if and when compression is enabled I got failures with
> CONFIG_SYS_MALLOC_LEN < 0x4000.
> 
> I found no way to enforce this in Kconfig itself, so I resorted
> to ada a warning in help string.

Nit: s/ada/add/ s/in help/in the help/?

Besides that,

Reviewed-by: Miquel Raynal 

> 
> Signed-off-by: Mauro Condarelli 
> ---
> 
> (no changes since v1)
> 
>  fs/squashfs/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
> index 54ab1618f1..7c3f83d007 100644
> --- a/fs/squashfs/Kconfig
> +++ b/fs/squashfs/Kconfig
> @@ -9,3 +9,5 @@ config FS_SQUASHFS
> filesystem use, for archival use (i.e. in cases where a .tar.gz file
> may be used), and in constrained block device/memory systems (e.g.
> embedded systems) where low overhead is needed.
> +   WARNING: if compression is enabled SquashFS needs a large amount
> +   of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000.

Thanks,
Miquèl


Re: [PATCH 2/2] mtd: cfi_mtd: Use DMA for reads

2020-10-08 Thread Stefan Roese

On 17.09.20 13:23, Vignesh Raghavendra wrote:

When possible use DMA for reading from CFI flash, this provides upto 5x
improvement in read performance with high speed CFI compliant flashes
like HyperFlash.

Code will gracefully fallback to CPU copy when DMA is unavailable.

Signed-off-by: Vignesh Raghavendra 


Applied to u-boot-cfi-flash/master

Thanks,
Stefan


---
  drivers/mtd/cfi_mtd.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/cfi_mtd.c b/drivers/mtd/cfi_mtd.c
index a5bb0962e5..78293caa2f 100644
--- a/drivers/mtd/cfi_mtd.c
+++ b/drivers/mtd/cfi_mtd.c
@@ -6,6 +6,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -70,7 +71,8 @@ static int cfi_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,

flash_info_t *fi = mtd->priv;
u_char *f = (u_char*)(fi->start[0]) + from;
  
-	memcpy(buf, f, len);

+   if (dma_memcpy(buf, f, len) < 0)
+   memcpy(buf, f, len);
*retlen = len;
  
  	return 0;





Viele Grüße,
Stefan

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


Re: [PATCH 1/2] dma: Reduce error level when DMA channel type does not exist

2020-10-08 Thread Stefan Roese

On 17.09.20 13:23, Vignesh Raghavendra wrote:

Caller would need gracefully handle failures of dma_get_device(),
therefore reduce pr_err() to pr_debug() when DMA device is not found.

Signed-off-by: Vignesh Raghavendra 


Applied to u-boot-cfi-flash/master

Thanks,
Stefan


---
  drivers/dma/dma-uclass.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 8cbb364042..50403148d6 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -219,8 +219,8 @@ int dma_get_device(u32 transfer_type, struct udevice **devp)
}
  
  	if (!dev) {

-   pr_err("No DMA device found that supports %x type\n",
- transfer_type);
+   pr_debug("No DMA device found that supports %x type\n",
+transfer_type);
return -EPROTONOSUPPORT;
}
  




Viele Grüße,
Stefan

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


Re: [PATCH v2] cfi_flash: Fix devicetree address determination

2020-10-08 Thread Stefan Roese

On 24.09.20 01:22, Andre Przywara wrote:

The cfi-flash driver uses an open-coded version of the generic
algorithm to decode and translate multiple frames of a "reg" property.

This starts off the wrong foot by using the address-cells and size-cells
properties of *this* very node, and not of the parent. This somewhat
happened to work back when we were using a wrong default size of 2,
but broke about a year ago with commit 0ba41ce1b781 ("libfdt: return
correct value if #size-cells property is not present").

Instead of fixing the reinvented wheel, just use the generic function
that does all of this properly.

This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding
a wrong flash base address:
DRAM:  1 GiB
Flash: "Synchronous Abort" handler, esr 0x9644
elr: 000211dc lr : 000211b0 (reloc)
elr: 7ff5e1dc lr : 7ff5e1b0
x0 : 00f0 x1 : 7ff5e1d8
x2 : 7edfbc48 x3 : 
x4 :  x5 : 00f0
x6 : 7edfbc2c x7 : 
x8 : 7ffd8d70 x9 : 000c
x10: 0403 x11: 0055
  

Signed-off-by: Andre Przywara 


Applied to u-boot-cfi-flash/master

Thanks,
Stefan


---
Changes v1 .. v2:
- Use live tree compatible function
- Drop unneeded size variable

  drivers/mtd/cfi_flash.c | 24 ++--
  1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b7289ba5394..9e3a652f445 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2468,29 +2468,17 @@ unsigned long flash_init(void)
  #ifdef CONFIG_CFI_FLASH /* for driver model */
  static int cfi_flash_probe(struct udevice *dev)
  {
-   const fdt32_t *cell;
-   int addrc, sizec;
-   int len, idx;
+   fdt_addr_t addr;
+   int idx;
  
-	addrc = dev_read_addr_cells(dev);

-   sizec = dev_read_size_cells(dev);
-
-   /* decode regs; there may be multiple reg tuples. */
-   cell = dev_read_prop(dev, "reg", );
-   if (!cell)
-   return -ENOENT;
-   idx = 0;
-   len /= sizeof(fdt32_t);
-   while (idx < len) {
-   phys_addr_t addr;
-
-   addr = dev_translate_address(dev, cell + idx);
+   for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
+   addr = dev_read_addr_index(dev, idx);
+   if (addr == FDT_ADDR_T_NONE)
+   break;
  
  		flash_info[cfi_flash_num_flash_banks].dev = dev;

flash_info[cfi_flash_num_flash_banks].base = addr;
cfi_flash_num_flash_banks++;
-
-   idx += addrc + sizec;
}
gd->bd->bi_flashstart = flash_info[0].base;
  




Viele Grüße,
Stefan

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


RE: [PATCH v4 1/2] arm: rmobile: Add PRR CPU ID macros for RZ/G2[HMNE]

2020-10-08 Thread Biju Das
Hi Marek,

> [...]
>
> >  /* PRR CPU IDs */
> >  #define RMOBILE_CPU_TYPE_SH73A00x37  #define
> > RMOBILE_CPU_TYPE_R8A77400x40
> > +#define RMOBILE_CPU_TYPE_R8A774A10x52
> 
>  The problem here is that this is the same as
>  #define RMOBILE_CPU_TYPE_R8A7796   0x52
> 
>  So if you use that ^ in the code, you cannot discern it from
>  RMOBILE_CPU_TYPE_R8A774A1 .
> >>>
> >>> But this value is same as per the hardware manual, see the
> >>> definitions in linux[1]
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t
> >>> re
> >>> e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
> >>> Please correct me, if this macros are not as per hardware manual.
> >>
> >> This is not what I am complaining about. See for example the output
> >> of $ git grep RMOBILE_CPU_TYPE_ ...
> >> drivers/mmc/renesas-sdhi.c: if (((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A7795) &&
> >> drivers/mmc/renesas-sdhi.c: ((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A7796) &&
> >> drivers/net/ravb.c: if ((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A77990) ||
> >> drivers/net/ravb.c: (rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A77995))
> >>
> >> These tests will no longer work on RZG as they should (the test to
> >> match on
> >> RMOBILE_CPU_TYPE_R8A7796 will also match on
> >> RMOBILE_CPU_TYPE_R8A774A1 and that might not be what is expected).
> So
> >> there needs to be some way to implement match on RZG-only.
> >
> > I have tested all the interfaces on RZ/H2[HMN] and they work as they
> > expected Moreover SOC's  with same PRR ID's use identical IP's.
>
> If (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) is true on
> RZG2, then it does not work as expected, I think we can agree on that ?
>
> > For eg:-
> > R8A7796 SDHI IP is identical to RZ/G2M SDHI IP
>
> If there ever is some RZG2 specific quirk further down the line, which does
> not apply to R-Car, then how do you propose that quirk is applied without
> having a way to tell RZG and RCar apart ?

OK, Will Make RMOBILE_CPU_TYPE_R8A774A1 as unique.

> > SDHI case, it has generic compatible string "renesas,rcar-gen3-sdhi " [1] .
> > Generic compatible string tells that the driver is compatible with RCar Gen3
> and RZ/G2 family.
> > SoC PRR ID's used to adapt the changes related to SoC family. So it will 
> > work
> as expected.
> > https://elixir.bootlin.com/u-boot/v2020.10-rc5/source/drivers/mmc/rene
> > sas-sdhi.c#L845
> >
> >> So we will need some
> rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
> >> function, which will match on 7796 only and if it is called with
> >> RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on
> >> which it is running is 7796).
> >
> > OK, If we really needed to separate this, then
> >
> > We can define CPU_MASK for  both RCar and RZG2.  We can define SoC
> PRRID's as per hardware Manual and We can redefine the above CPU
> macro's like this.
> >
> > #define SOC_R8A7796_PRR_ID 0x52
> > #define SOC_R8A774A1_PRR_ID 0x52
> >
> > #define RCAR_GEN3_CPU_MASK  0x0
> > #define RZG2_CPU_MASK 0x1000
> >
> > #define RMOBILE_CPU_TYPE_R8A7796   (SOC_R8A7796_PRR_ID +
> RCAR_GEN3_CPU_MASK)
> > #define RMOBILE_CPU_TYPE_R8A774A1 (SOC_R8A774A1_PRR_ID +
> > RZG2_CPU_MASK)
> >
> > So rmobile_cpu_match will return RMOBILE_CPU_TYPE_R8A7796 or
> > RMOBILE_CPU_TYPE_R8A774A1 instead of PRRID's.
> >
> > What do you think?
>
> I think this is just an implementation detail. What needs to be figured out
> first is how to tell RCar3 and RZG2 apart. Lets continue this discussion in 
> the
> bootrom thread, that really needs to be figured out first and only then can U-
> Boot and TFA patches be implemented on top of that solution.

OK.

>  We really need to find a way to tell these two apart first, e.g. by
>  checking the bootrom, and then use it in U-Boot all over the place.
> >>>
> >>> Yes, I agree we need to differentiate them. Different ways I can
> >>> think of is
> >>>
> >>> 1) Bootrom level
> >>> 2) Checking some IP register which is present in RCar and not in
> >>> RZ/G2
> >>
> >> Did you make any progress on these two ?
> >
> > Still investigating [1] and [2],
> >
> > For 1) this to done at TFA  right, not at u-boot level?
>
> Yes
>
> > TFA runs at EL3, So all secure stuffs to be handled at TFA and TFA needs to
> identify the SoC/Family type pass this info to u-boot.
> > Basically identify the SoC using BootRom code at TFA  and pass that info to
> u-boot   (for eg:-  in the form of  "SoC Compatible string"  , which has the 
> info
> "r8a7796" for RCar and "r8a774a1" for RZ/G2 )
> > which is same as the Solution 3 ("Compatible SoC string from TFA")
> >
> > For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on
> some register access, we may be able to differentiate it at u-boot level.
>
> Note that it doesn't really matter whether you do the identification in TFA
> and just pass that information to U-Boot (via DT fragment) or