Re: [U-Boot] [PATCH 03/26] dts: mtmips: move uart property clock-frequency into mt7628an.dtsi

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

The UART of MT7628 has fixed 40MHz input clock so there is no need to put
clock-frequency in every dts files. Just put it into the common dtsi file.

Signed-off-by: Weijie Gao 


Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 04/26] dts: mtmips: enable high-speed UART support for mt7628

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

All three UARTs of mt7628 are actually MediaTek's high-speed UARTs which
support baudrate up to 921600.
The high-speed UART is compatible with ns16550 when baudrate <= 115200.

Add compatible string to dtsi file so u-boot can use it when serial_mtk
driver is built in.

Signed-off-by: Weijie Gao 


Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] clk: meson-g12b: add compatible

2019-08-28 Thread Neil Armstrong
Hi Mark,

On 27/08/2019 23:06, Mark Kettenis wrote:
> The G12B clock controller is almost identical to the G12A and
> so far the differences don't matter.  Adding the G12B compatible
> makes USB work on the Odroid-N2.

Indeed I forgot this when syncing with linux DTB,
Applying and sending right now, thanks !

Neil

> 
> Signed-off-by: Mark Kettenis 
> ---
>  drivers/clk/meson/g12a.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
> index 112326e553..43dac1aa37 100644
> --- a/drivers/clk/meson/g12a.c
> +++ b/drivers/clk/meson/g12a.c
> @@ -405,6 +405,7 @@ static struct clk_ops meson_clk_ops = {
>  
>  static const struct udevice_id meson_clk_ids[] = {
>   { .compatible = "amlogic,g12a-clkc" },
> + { .compatible = "amlogic,g12b-clkc" },
>   { }
>  };
>  
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 05/26] spi: mt7621-spi: remove data cache and rewrite its xfer function

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

The mt7621 spi controller supports continuous generic half-duplex spi
transaction. There is no need to cache xfer data at all.

To achieve this goal, the OPADDR register must be used as the first data
to be sent. And follows the eight generic DIDO registers. But one thing
different between OPADDR and DIDO registers is OPADDR has a reversed byte
order.

With this patch, any amount of data can be read/written in a single xfer
function call.

Signed-off-by: Weijie Gao 


Very nice, thanks for all your work here.

Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 06/26] spi: mt7621-spi: restore default register value after each xfer

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

Currently this driver uses a different way to implement the spi xfer,
by modifying some fields of two registers, which is incompatible with the
MTK's original SDK linux driver. This will cause the flash data being
damaged by the SDK driver.

This patch lets the mt7621_spi_set_cs() restore the original register
fields after cs deactivated.


What is this "MTK's original SDK Linux driver"? It's not the mainline
Linux SPI driver, correct? Which platforms / boards are using it?

Please note that in general, drivers in Linux should not make any
assumptions about prior register setup. So the driver you are referring
to should configure all registers correctly for its setup.

But I don't object to this patch, so if this is really needed for
some of your customers, please go ahead:

Reviewed-by: Stefan Roese 

Thanks,
Stefan
 

Signed-off-by: Weijie Gao 
---
  drivers/spi/mt7621_spi.c | 30 +-
  1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/mt7621_spi.c b/drivers/spi/mt7621_spi.c
index 20fe93d416..06484e7abe 100644
--- a/drivers/spi/mt7621_spi.c
+++ b/drivers/spi/mt7621_spi.c
@@ -20,6 +20,10 @@
  #define MT7621_SPI_TRANS  0x00
  #define MT7621_SPI_TRANS_STARTBIT(8)
  #define MT7621_SPI_TRANS_BUSY BIT(16)
+#define TRANS_ADDR_SZ  GENMASK(20, 19)
+#define TRANS_ADDR_SZ_SHIFT19
+#define TRANS_MOSI_BCNTGENMASK(3, 0)
+#define TRANS_MOSI_BCNT_SHIFT  0
  
  #define MT7621_SPI_OPCODE	0x04

  #define MT7621_SPI_DATA0  0x08
@@ -49,20 +53,22 @@ struct mt7621_spi {
unsigned int sys_freq;
  };
  
-static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)

-{
-   setbits_le32(rs->base + MT7621_SPI_MASTER,
-MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE);
-}
-
  static void mt7621_spi_set_cs(struct mt7621_spi *rs, int cs, int enable)
  {
-   u32 val = 0;
-
debug("%s: cs#%d -> %s\n", __func__, cs, enable ? "enable" : "disable");
-   if (enable)
-   val = BIT(cs);
-   iowrite32(val, rs->base + MT7621_SPI_POLAR);
+
+   if (enable) {
+   setbits_le32(rs->base + MT7621_SPI_MASTER,
+MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE);
+   iowrite32(BIT(cs), rs->base + MT7621_SPI_POLAR);
+   } else {
+   iowrite32(0, rs->base + MT7621_SPI_POLAR);
+   iowrite32((2 << TRANS_ADDR_SZ_SHIFT) |
+ (1 << TRANS_MOSI_BCNT_SHIFT),
+ rs->base + MT7621_SPI_TRANS);
+   clrbits_le32(rs->base + MT7621_SPI_MASTER,
+MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE);
+   }
  }
  
  static int mt7621_spi_set_mode(struct udevice *bus, uint mode)

@@ -267,8 +273,6 @@ static int mt7621_spi_probe(struct udevice *dev)
return -EINVAL;
}
  
-	mt7621_spi_reset(rs, 0);

-
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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

2019-08-28 Thread Sherry Sun
Hi Jean,

> 
> Hi Sherry,
> 
> On 21/08/2019 16:36, Sherry Sun wrote:
> > The cdns3-usb-phy driver supports both host and peripheral mode of usb
> > driver which use cadence usb3 IP.
> >
> > Signed-off-by: Sherry Sun 
> > ---
> >   drivers/phy/Kconfig |   8 ++
> >   drivers/phy/Makefile|   1 +
> >   drivers/phy/cdns3-usb-phy.c | 241
> 
> >   3 files changed, 250 insertions(+)
> >   create mode 100644 drivers/phy/cdns3-usb-phy.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > 3942f035eb..1837b32c31 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -205,4 +205,12 @@ config MT76X8_USB_PHY
> >
> >   This PHY is found on MT76x8 devices supporting USB.
> >
> > +config CDNS3_USB_PHY
> > +   bool "Support CDNS3 USB PHY"
> > +   depends on PHY
> > +   help
> > + Support for the USB PHY in CDNS3 IP.
> > +
> > + This PHY is found on CDNS3 IP devices supporting USB.
> > +
> >   endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> > 3157f1b7ee..0e062214d3 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -22,4 +22,5 @@ obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-
> usbh-phy.o
> >   obj-$(CONFIG_OMAP_USB2_PHY) += omap-usb2-phy.o
> >   obj-$(CONFIG_KEYSTONE_USB_PHY) += keystone-usb-phy.o
> >   obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
> > +obj-$(CONFIG_CDNS3_USB_PHY) += cdns3-usb-phy.o
> >   obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o diff --git
> > a/drivers/phy/cdns3-usb-phy.c b/drivers/phy/cdns3-usb-phy.c new file
> > mode 100644 index 00..c0d308075b
> > --- /dev/null
> > +++ b/drivers/phy/cdns3-usb-phy.c
> > @@ -0,0 +1,241 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2019 NXP
> > + *
> > + * Cadence3 USB PHY driver
> > + *
> > + * Author: Sherry Sun   */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* PHY registers */
> > +#define PHY_PMA_CMN_CTRL1  (0xC800 * 4)
> > +#define TB_ADDR_CMN_DIAG_HSCLK_SEL (0x01e0 * 4)
> > +#define TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR   (0x0084 * 4)
> > +#define TB_ADDR_CMN_PLL0_VCOCAL_ITER_TMR   (0x0085 * 4)
> > +#define TB_ADDR_CMN_PLL0_INTDIV(0x0094 * 4)
> > +#define TB_ADDR_CMN_PLL0_FRACDIV   (0x0095 * 4)
> > +#define TB_ADDR_CMN_PLL0_HIGH_THR  (0x0096 * 4)
> > +#define TB_ADDR_CMN_PLL0_SS_CTRL1  (0x0098 * 4)
> > +#define TB_ADDR_CMN_PLL0_SS_CTRL2  (0x0099 * 4)
> > +#define TB_ADDR_CMN_PLL0_DSM_DIAG  (0x0097 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_OVRD (0x01c2 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_FBH_OVRD (0x01c0 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_FBL_OVRD (0x01c1 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_V2I_TUNE  (0x01C5 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_CP_TUNE   (0x01C6 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_LF_PROG   (0x01C7 * 4)
> > +#define TB_ADDR_CMN_DIAG_PLL0_TEST_MODE(0x01c4 * 4)
> > +#define TB_ADDR_CMN_PSM_CLK_CTRL   (0x0061 * 4)
> > +#define TB_ADDR_XCVR_DIAG_RX_LANE_CAL_RST_TMR  (0x40ea * 4)
> > +#define TB_ADDR_XCVR_PSM_RCTRL (0x4001 * 4)
> > +#define TB_ADDR_TX_PSC_A0  (0x4100 * 4)
> > +#define TB_ADDR_TX_PSC_A1  (0x4101 * 4)
> > +#define TB_ADDR_TX_PSC_A2  (0x4102 * 4)
> > +#define TB_ADDR_TX_PSC_A3  (0x4103 * 4)
> > +#define TB_ADDR_TX_DIAG_ECTRL_OVRD (0x41f5 * 4)
> > +#define TB_ADDR_TX_PSC_CAL (0x4106 * 4)
> > +#define TB_ADDR_TX_PSC_RDY (0x4107 * 4)
> > +#define TB_ADDR_RX_PSC_A0  (0x8000 * 4)
> > +#define TB_ADDR_RX_PSC_A1  (0x8001 * 4)
> > +#define TB_ADDR_RX_PSC_A2  (0x8002 * 4)
> > +#define TB_ADDR_RX_PSC_A3  (0x8003 * 4)
> > +#define TB_ADDR_RX_PSC_CAL (0x8006 * 4)
> > +#define TB_ADDR_RX_PSC_RDY (0x8007 * 4)
> > +#define TB_ADDR_TX_TXCC_MGNLS_MULT_000 (0x4058 * 4)
> > +#define TB_ADDR_TX_DIAG_BGREF_PREDRV_DELAY (0x41e7 * 4)
> > +#define TB_ADDR_RX_SLC_CU_ITER_TMR (0x80e3 * 4)
> > +#define TB_ADDR_RX_SIGDET_HL_FILT_TMR  (0x8090 * 4)
> > +#define TB_ADDR_RX_SAMP_DAC_CTRL   (0x8058 * 4)
> > +#define TB_ADDR_RX_DIAG_SIGDET_TUNE(0x81dc * 4)
> > +#define TB_ADDR_RX_DIAG_LFPSDET_TUNE2  (0x81df * 4)
> > +#define TB_ADDR_RX_DIAG_BS_TM  (0x81f5 * 4)
> > +#define TB_ADDR_RX_DIAG_DFE_CTRL1  (0x81d3 * 4)
> > +#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM4  (0x81c7 * 4)
> > +#define TB_ADDR_RX_DIAG_ILL_E_TRIM0(0x81c2 * 4)
> > +#define TB_ADDR_RX_DIAG_ILL_IQ_TRIM0   (0x81c1 * 4)
> > +#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM6  (0x81c9 * 4)
> > +#define TB_ADDR_RX_DIAG_RXFE_TM3   (0x81f8 * 4)
> > +#def

Re: [U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-28 Thread Ley Foon Tan
On Fri, Aug 23, 2019 at 5:56 PM Marek Vasut  wrote:
>
> On 8/23/19 11:52 AM, Ley Foon Tan wrote:
> > On Fri, Aug 23, 2019 at 5:23 PM Marek Vasut  wrote:
> >>
> >> On 8/23/19 10:57 AM, Ley Foon Tan wrote:
> >>> On Wed, Aug 21, 2019 at 9:50 AM Ley Foon Tan  
> >>> wrote:
> 
>  On Tue, Aug 20, 2019 at 5:50 PM Marek Vasut  wrote:
> >
> > On 8/20/19 4:35 AM, Ley Foon Tan wrote:
> >> Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
> >> to defines.
> >> No functional change.
> >>
> >> Signed-off-by: Ley Foon Tan 
> >> ---
> >>  .../mach-socfpga/include/mach/reset_manager.h | 12 +
> >>  .../include/mach/reset_manager_arria10.h  | 41 +++-
> >>  .../include/mach/reset_manager_gen5.h | 20 +++-
> >>  .../include/mach/reset_manager_s10.h  | 33 ++---
> >>  arch/arm/mach-socfpga/misc_gen5.c |  6 +--
> >>  arch/arm/mach-socfpga/reset_manager_arria10.c | 49 +--
> >>  arch/arm/mach-socfpga/reset_manager_gen5.c| 26 +-
> >>  arch/arm/mach-socfpga/reset_manager_s10.c | 35 ++---
> >>  drivers/sysreset/sysreset_socfpga.c   |  6 +--
> >>  9 files changed, 86 insertions(+), 142 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
> >> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >> index 6ad037e325..c460e89d22 100644
> >> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> >> @@ -6,6 +6,18 @@
> >>  #ifndef _RESET_MANAGER_H_
> >>  #define _RESET_MANAGER_H_
> >>
> >> +#define RSTMGR_READL(reg)\
> >> + readl(SOCFPGA_RSTMGR_ADDRESS + (reg))
> >> +
> >> +#define RSTMGR_WRITEL(data, reg) \
> >> + writel(data, SOCFPGA_RSTMGR_ADDRESS + (reg))
> >> +
> >> +#define RSTMGR_CLRBITS(reg, mask)\
> >> + clrbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
> >> +
> >> +#define RSTMGR_SETBITS(reg, mask)\
> >> + setbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
> >>
> >> btw. mask is missing parenthesis, but see below.
> >>
> >> +
> >
> > No, don't introduce such macros. Use readl()/writel()/... in the driver.
> > The address should come from DT. Besides, there is no type checking in
> > such macros.
>  These macros call to writel() and readl() underlying, it just add base
>  address to it.
> >>
> >> Right, it just makes the code hardware to read and understand.
> > Okay, will change it.
>
> It should be easy to do:
> $ sed "s@RSTMGR_SETBITS(\([^,]\+\),
> \([^)]\+\))@setbits_le32(SOCFPGA_RSTMGR_ADDRESS + \1, \1)@"
> $ git add -u ; git commit -sm part1
> $ checkpatch -f --fix --fix-inplace 
> $ git diff # review the fixes
> $ git add -u ; git commit --amend #
>
>  So, it should have type checking as call writel()/readl() directly?
> >>
> >> The functions in the macro get typechecked. But unlike function
> >> arguments, macro arguments are not checked.
> > Noted.
> >>
>  If want to use address from DT, we need get address every time need to
>  use the address.
>  For non-DM, it is easier to use constant address. Let me know if you
>  still prefer to use address from DT.
> >>
> >> Surely you can cache the address or even better, convert to DM/DT ?
> > Will try to cache the address for now.  But, we need get address from
> > DT twice, one in SPL, one in Uboot. They not sharing global data.
>
> I don't think there's much we can do about that, unless we can somehow
> share parsed live DT from SPL to U-Boot, but that's for another
> discussion/patchset/etc.
I am working on this now and found there are 2 challenges if we get
base address from DT.
1. We can only get the address from DT after gd->fdt_blob is
initialized in spl_early_init(). So, spl_early_init() need move to
beginning of board_init_f().
   Tested this on Agilex, look okay. But, pending test on other device
families, like Gen5 or A10. Not sure any side effect with this change.
2. Secure (for PSCI) and non-secure functions share same functions,
these functions can't use global data (for base address). Secure
functions have its own secure data region.
#2 is more difficult to overcome. Do you have strong opinion to get
base address from DT? Otherwise, can we use constant define for these
base addresses?

Thanks.

Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Enable USB host controller on Odroid-C2

2019-08-28 Thread Neil Armstrong
On 18/08/2019 15:42, Beniamino Galvani wrote:
> Hi,
> 
> these two patches enable the USB host controller on Odroid-C2. The
> first patch adds a PHY driver; the second one enables the necessary
> configuration options and updates the device tree.
> 
> Note that the DWC2 driver currently does not support enabling PHYs
> from the device tree and so the following series (still on review) is
> needed as runtime requirement for the second patch:
> 
>  [PATCH 0/5] usb: host: dwc2: use driver model for PHY and CLOCK


Pushed to my u-boot-amlogic-next test tree until this dependency is applied.

Thanks,
Neil

> 
> Thanks,
> Beniamino
> 
> Beniamino Galvani (2):
>   phy: meson: add GXBB PHY driver
>   odroid-c2: enable USB host controller
> 
>  arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi |   8 +
>  configs/odroid-c2_defconfig  |   7 +
>  drivers/phy/Kconfig  |   8 +
>  drivers/phy/Makefile |   1 +
>  drivers/phy/meson-gxbb-usb2.c| 235 +++
>  include/configs/meson64.h|   5 +
>  6 files changed, 264 insertions(+)
>  create mode 100644 drivers/phy/meson-gxbb-usb2.c
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] board: amlogic: document alternative libretech-cc installation methods

2019-08-28 Thread Neil Armstrong
Hi,

On 06/08/2019 10:10, Daniel Drake wrote:
> As already documented in this README, several binaries must be
> glued together in order to boot the device.
> 
> Extend the documentation to cover the prebuilt binaries
> (saving you the hassle of installing ancient cross-compilers),
> and also mention the open source replacements for the encryption
> tool (which is especially useful if you want to avoid requiring
> 32-bit x86 binaries in your build system).

Applied to u-boot-amlogic-next for next u-boot release, feel free
to add the same text to other boards..

Neil

> 
> Signed-off-by: Daniel Drake 
> Cc: Neil Armstrong 
> ---
>  board/amlogic/p212/README.libretech-cc | 41 +++---
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/board/amlogic/p212/README.libretech-cc 
> b/board/amlogic/p212/README.libretech-cc
> index d007f58764..6af7de3cfa 100644
> --- a/board/amlogic/p212/README.libretech-cc
> +++ b/board/amlogic/p212/README.libretech-cc
> @@ -38,9 +38,28 @@ U-Boot compilation
>  Image creation
>  ==
>  
> -Amlogic doesn't provide sources for the firmware and for tools needed
> -to create the bootloader image, so it is necessary to obtain them from
> -the git tree published by the board vendor:
> +To boot the system, u-boot must be combined with several earlier stage
> +bootloaders:
> +
> +* bl2.bin: vendor-provided binary blob
> +* bl21.bin: built from vendor u-boot source
> +* bl30.bin: vendor-provided binary blob
> +* bl301.bin: built from vendor u-boot source
> +* bl31.bin: vendor-provided binary blob
> +* acs.bin: built from vendor u-boot source
> +
> +These binaries and the tools required below have been collected and prebuilt
> +for convenience at 
> +
> +Download and extract the libretech-cc release from there, and set FIPDIR to
> +point to the `fip` subdirectory.
> +
> + > export FIPDIR=/path/to/extracted/fip
> +
> +Alternatively, you can obtain the original vendor u-boot tree which
> +contains the required blobs and sources, and build yourself.
> +Note that old compilers are required for this to build. The compilers here
> +are suggested by Amlogic, and they are 32-bit x86 binaries.
>  
>   > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
>   > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> @@ -53,7 +72,10 @@ the git tree published by the board vendor:
>   > make
>   > export FIPDIR=$PWD/fip
>  
> -Go back to mainline U-Boot source tree then :
> +Once you have the binaries available (either through the prebuilt download,
> +or having built the vendor u-boot yourself), you can then proceed to glue
> +everything together. Go back to mainline U-Boot source tree then :
> +
>   > mkdir fip
>  
>   > cp $FIPDIR/gxl/bl2.bin fip/
> @@ -100,3 +122,14 @@ and then write the image to SD with:
>   > DEV=/dev/your_sd_device
>   > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 
> seek=1
>   > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
> +
> +Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
> +source code. Should you prefer to avoid that, there are open source reverse
> +engineered versions available:
> +
> +1. gxlimg , which comes with a handy
> +   Makefile that automates the whole process.
> +2. meson-tools 
> +
> +However, these community-developed alternatives are not endorsed by or
> +supported by Amlogic.
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/6] usb: ehci-generic: don't probe fail if there is no clk_enable() ops

2019-08-28 Thread Kever Yang
Some clock driver do not have a clk_enable() call back, and we should not
treat this as fail in ehci probe like other modules, eg. clk_enabl_bulk()
do not return fail if ret value is '-ENOSYS'

Signed-off-by: Kever Yang 
---

 drivers/usb/host/ehci-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 0270f3bc95..682a070306 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -96,7 +96,7 @@ static int ehci_usb_probe(struct udevice *dev)
if (err < 0)
break;
err = clk_enable(&priv->clocks[i]);
-   if (err) {
+   if (err && err != -ENOSYS) {
dev_err(dev, "failed to enable clock %d\n", i);
clk_free(&priv->clocks[i]);
goto clk_err;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/6] Remove no use clk_enable() for rockchip platform

2019-08-28 Thread Kever Yang

There are some clk_enable() callback add to rockchip clock drivers but
with out any real operation driver code, it's waste of CPU cycles at
runtime and waste of code size. The callback are add because some
peripheral REQUIRE it, eg. ehci/ohci generic driver, and other driver
also need it if the ops exist, eg. dwc3 driver and designware net driver.

After update ehci&ohci driver to not always need clk_enable ops in
vendor driver, we can remove all relate no use code in rockchip clock
drivers.



Kever Yang (6):
  usb: ehci-generic: don't probe fail if there is no clk_enable() ops
  usb: ohci-generic: don't probe fail if there is no clk_enable() ops
  rockchip: clk: rk3288: remove clk_enable()
  rockchip: clk: rk3328: remove clk_enable()
  rockchip: clk: rk3368: remove clk_enable()
  rockchip: clk: rk3399: remove clk_enable()

 drivers/clk/rockchip/clk_rk3288.c | 23 ---
 drivers/clk/rockchip/clk_rk3328.c | 12 --
 drivers/clk/rockchip/clk_rk3368.c | 19 
 drivers/clk/rockchip/clk_rk3399.c | 37 ---
 drivers/usb/host/ehci-generic.c   |  2 +-
 drivers/usb/host/ohci-generic.c   |  2 +-
 6 files changed, 2 insertions(+), 93 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/6] rockchip: clk: rk3328: remove clk_enable()

2019-08-28 Thread Kever Yang
There is no real driver for clk enable/disable now, and we actually
don't need it now, remove it so that not waste CPU cycles and code size.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3328.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3328.c 
b/drivers/clk/rockchip/clk_rk3328.c
index 5957a00402..a89e2ecc4a 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -745,22 +745,10 @@ static int rk3328_clk_set_parent(struct clk *clk, struct 
clk *parent)
return -ENOENT;
 }
 
-static int rk3328_clk_enable(struct clk *clk)
-{
-   switch (clk->id) {
-   case HCLK_HOST0:
-   /* Required to successfully probe the ehci generic driver */
-   return 0;
-   }
-
-   return -ENOENT;
-}
-
 static struct clk_ops rk3328_clk_ops = {
.get_rate = rk3328_clk_get_rate,
.set_rate = rk3328_clk_set_rate,
.set_parent = rk3328_clk_set_parent,
-   .enable = rk3328_clk_enable,
 };
 
 static int rk3328_clk_probe(struct udevice *dev)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/6] rockchip: clk: rk3288: remove clk_enable()

2019-08-28 Thread Kever Yang
There is no real driver for clk enable/disable now, and we actually
don't need it now, remove it so that not waste CPU cycles and code size.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3288.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index 375d7f8acb..0122381633 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -940,35 +940,12 @@ static int __maybe_unused rk3288_clk_set_parent(struct 
clk *clk, struct clk *par
return -ENOENT;
 }
 
-static int rk3288_clk_enable(struct clk *clk)
-{
-   switch (clk->id) {
-   case HCLK_USBHOST0:
-   case HCLK_HSIC:
-   return 0;
-
-   case SCLK_MAC:
-   case SCLK_MAC_RX:
-   case SCLK_MAC_TX:
-   case SCLK_MACREF:
-   case SCLK_MACREF_OUT:
-   case ACLK_GMAC:
-   case PCLK_GMAC:
-   /* Required to successfully probe the Designware GMAC driver */
-   return 0;
-   }
-
-   debug("%s: unsupported clk %ld\n", __func__, clk->id);
-   return -ENOENT;
-}
-
 static struct clk_ops rk3288_clk_ops = {
.get_rate   = rk3288_clk_get_rate,
.set_rate   = rk3288_clk_set_rate,
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.set_parent = rk3288_clk_set_parent,
 #endif
-   .enable = rk3288_clk_enable,
 };
 
 static int rk3288_clk_ofdata_to_platdata(struct udevice *dev)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/6] usb: ohci-generic: don't probe fail if there is no clk_enable() ops

2019-08-28 Thread Kever Yang
Some clock driver do not have a clk_enable() call back, and we should not
treat this as fail in ehci probe like other modules, eg. clk_enabl_bulk()
do not return fail if ret value is '-ENOSYS'

Signed-off-by: Kever Yang 
---

 drivers/usb/host/ohci-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-generic.c b/drivers/usb/host/ohci-generic.c
index 24b5c3156f..916ea0b955 100644
--- a/drivers/usb/host/ohci-generic.c
+++ b/drivers/usb/host/ohci-generic.c
@@ -95,7 +95,7 @@ static int ohci_usb_probe(struct udevice *dev)
break;
 
err = clk_enable(&priv->clocks[i]);
-   if (err) {
+   if (err && err != -ENOSYS) {
dev_err(dev, "failed to enable clock %d\n", i);
clk_free(&priv->clocks[i]);
goto clk_err;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 5/6] rockchip: clk: rk3368: remove clk_enable()

2019-08-28 Thread Kever Yang
There is no real driver for clk enable/disable now, and we actually
don't need it now, remove it so that not waste CPU cycles and code size.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3368.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 89cbae59c5..c1a867b2ed 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -566,31 +566,12 @@ static int __maybe_unused rk3368_clk_set_parent(struct 
clk *clk, struct clk *par
return -ENOENT;
 }
 
-static int rk3368_clk_enable(struct clk *clk)
-{
-   switch (clk->id) {
-   case SCLK_MAC:
-   case SCLK_MAC_RX:
-   case SCLK_MAC_TX:
-   case SCLK_MACREF:
-   case SCLK_MACREF_OUT:
-   case ACLK_GMAC:
-   case PCLK_GMAC:
-   /* Required to successfully probe the Designware GMAC driver */
-   return 0;
-   }
-
-   debug("%s: unsupported clk %ld\n", __func__, clk->id);
-   return -ENOENT;
-}
-
 static struct clk_ops rk3368_clk_ops = {
.get_rate = rk3368_clk_get_rate,
.set_rate = rk3368_clk_set_rate,
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.set_parent = rk3368_clk_set_parent,
 #endif
-   .enable = rk3368_clk_enable,
 };
 
 static int rk3368_clk_probe(struct udevice *dev)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 6/6] rockchip: clk: rk3399: remove clk_enable()

2019-08-28 Thread Kever Yang
There is no real driver for clk enable/disable now, and we actually
don't need it now, remove it so that not waste CPU cycles and code size.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3399.c | 37 ---
 1 file changed, 37 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index d9950c159b..a273bd1beb 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -1062,49 +1062,12 @@ static int __maybe_unused rk3399_clk_set_parent(struct 
clk *clk,
return -ENOENT;
 }
 
-static int rk3399_clk_enable(struct clk *clk)
-{
-   switch (clk->id) {
-   case HCLK_HOST0:
-   case HCLK_HOST0_ARB:
-   case HCLK_HOST1:
-   case HCLK_HOST1_ARB:
-   return 0;
-
-   case SCLK_MAC:
-   case SCLK_MAC_RX:
-   case SCLK_MAC_TX:
-   case SCLK_MACREF:
-   case SCLK_MACREF_OUT:
-   case ACLK_GMAC:
-   case PCLK_GMAC:
-   /* Required to successfully probe the Designware GMAC driver */
-   return 0;
-
-   case SCLK_USB3OTG0_REF:
-   case SCLK_USB3OTG1_REF:
-   case SCLK_USB3OTG0_SUSPEND:
-   case SCLK_USB3OTG1_SUSPEND:
-   case ACLK_USB3OTG0:
-   case ACLK_USB3OTG1:
-   case ACLK_USB3_RKSOC_AXI_PERF:
-   case ACLK_USB3:
-   case ACLK_USB3_GRF:
-   /* Required to successfully probe the Designware USB3 driver */
-   return 0;
-   }
-
-   debug("%s: unsupported clk %ld\n", __func__, clk->id);
-   return -ENOENT;
-}
-
 static struct clk_ops rk3399_clk_ops = {
.get_rate = rk3399_clk_get_rate,
.set_rate = rk3399_clk_set_rate,
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.set_parent = rk3399_clk_set_parent,
 #endif
-   .enable = rk3399_clk_enable,
 };
 
 #ifdef CONFIG_SPL_BUILD
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] board: atmel: common: remove year from print message

2019-08-28 Thread Eugen.Hristev
From: Eugen Hristev 

Remove 2017 from being printed at boot video console.
This is outdated.
To avoid this situation, remove the year completely.

Signed-off-by: Eugen Hristev 
---
 board/atmel/common/video_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/atmel/common/video_display.c 
b/board/atmel/common/video_display.c
index c7d3f8a..cc051d2 100644
--- a/board/atmel/common/video_display.c
+++ b/board/atmel/common/video_display.c
@@ -23,7 +23,7 @@ int at91_video_show_board_info(void)
int i;
u32 len = 0;
char buf[255];
-   char *corp = "2017 Microchip Technology Inc.\n";
+   char *corp = "Microchip Technology Inc.\n";
char temp[32];
struct udevice *dev, *con;
const char *s;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/6] usb: ehci-generic: don't probe fail if there is no clk_enable() ops

2019-08-28 Thread Patrice CHOTARD
Hi Kever

On 8/28/19 10:23 AM, Kever Yang wrote:
> Some clock driver do not have a clk_enable() call back, and we should not
> treat this as fail in ehci probe like other modules, eg. clk_enabl_bulk()
> do not return fail if ret value is '-ENOSYS'
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/usb/host/ehci-generic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
> index 0270f3bc95..682a070306 100644
> --- a/drivers/usb/host/ehci-generic.c
> +++ b/drivers/usb/host/ehci-generic.c
> @@ -96,7 +96,7 @@ static int ehci_usb_probe(struct udevice *dev)
>   if (err < 0)
>   break;
>   err = clk_enable(&priv->clocks[i]);
> - if (err) {
> + if (err && err != -ENOSYS) {
>   dev_err(dev, "failed to enable clock %d\n", i);
>   clk_free(&priv->clocks[i]);
>   goto clk_err;

Reviewed-by: Patrice Chotard 

Thanks

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/6] usb: ohci-generic: don't probe fail if there is no clk_enable() ops

2019-08-28 Thread Patrice CHOTARD
Hi Kever

On 8/28/19 10:23 AM, Kever Yang wrote:
> Some clock driver do not have a clk_enable() call back, and we should not
> treat this as fail in ehci probe like other modules, eg. clk_enabl_bulk()
> do not return fail if ret value is '-ENOSYS'
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/usb/host/ohci-generic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-generic.c b/drivers/usb/host/ohci-generic.c
> index 24b5c3156f..916ea0b955 100644
> --- a/drivers/usb/host/ohci-generic.c
> +++ b/drivers/usb/host/ohci-generic.c
> @@ -95,7 +95,7 @@ static int ohci_usb_probe(struct udevice *dev)
>   break;
>  
>   err = clk_enable(&priv->clocks[i]);
> - if (err) {
> + if (err && err != -ENOSYS) {
>   dev_err(dev, "failed to enable clock %d\n", i);
>   clk_free(&priv->clocks[i]);
>   goto clk_err;

Reviewed-by: Patrice Chotard 

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] ata: ahci allow 64-bit DMA for SATA

2019-08-28 Thread Roman Kapl
Allow 64-bit DMA on AHCI. If not supported by the host controller, at
least print a message and fail.

Signed-off-by: Roman Kapl 
---
 drivers/ata/ahci.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9a08575053..02007ad4bd 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -503,9 +503,15 @@ static int ahci_fill_sg(struct ahci_uc_priv *uc_priv, u8 
port,
}
 
for (i = 0; i < sg_count; i++) {
-   ahci_sg->addr =
-   cpu_to_le32((unsigned long) buf + i * MAX_DATA_BYTE_COUNT);
-   ahci_sg->addr_hi = 0;
+   /* We assume virt=phys */
+   phys_addr_t pa = (unsigned long)buf + i * MAX_DATA_BYTE_COUNT;
+
+   ahci_sg->addr = cpu_to_le32(pa & U32_MAX);
+   ahci_sg->addr_hi = cpu_to_le32((pa >> 32) & U32_MAX);
+   if (ahci_sg->addr_hi && !(uc_priv->cap & AHCI_CAP_S64A)) {
+   printf("Error: DMA address too high\n");
+   return -1;
+   }
ahci_sg->flags_size = cpu_to_le32(0x3f &
  (buf_len < MAX_DATA_BYTE_COUNT
   ? (buf_len - 1)
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/8] add PCIe, its PHY and AHCI support for mt7623

2019-08-28 Thread Frank Wunderlich
Any comments on this series?

just a friendly reminder :)

regards Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

2019-08-28 Thread Jean-Jacques Hiblot

+Kishon who worked on this PHY under linux


Hi Sherry,


On 28/08/2019 10:05, Sherry Sun wrote:

Hi Jean,


Hi Sherry,

On 21/08/2019 16:36, Sherry Sun wrote:

The cdns3-usb-phy driver supports both host and peripheral mode of usb
driver which use cadence usb3 IP.

Signed-off-by: Sherry Sun 
---
   drivers/phy/Kconfig |   8 ++
   drivers/phy/Makefile|   1 +
   drivers/phy/cdns3-usb-phy.c | 241



   3 files changed, 250 insertions(+)
   create mode 100644 drivers/phy/cdns3-usb-phy.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
3942f035eb..1837b32c31 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -205,4 +205,12 @@ config MT76X8_USB_PHY

  This PHY is found on MT76x8 devices supporting USB.

+config CDNS3_USB_PHY
+   bool "Support CDNS3 USB PHY"
+   depends on PHY
+   help
+ Support for the USB PHY in CDNS3 IP.
+
+ This PHY is found on CDNS3 IP devices supporting USB.
+
   endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
3157f1b7ee..0e062214d3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-

usbh-phy.o

   obj-$(CONFIG_OMAP_USB2_PHY) += omap-usb2-phy.o
   obj-$(CONFIG_KEYSTONE_USB_PHY) += keystone-usb-phy.o
   obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
+obj-$(CONFIG_CDNS3_USB_PHY) += cdns3-usb-phy.o
   obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o diff --git
a/drivers/phy/cdns3-usb-phy.c b/drivers/phy/cdns3-usb-phy.c new file
mode 100644 index 00..c0d308075b
--- /dev/null
+++ b/drivers/phy/cdns3-usb-phy.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *
+ * Cadence3 USB PHY driver
+ *
+ * Author: Sherry Sun   */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY registers */
+#define PHY_PMA_CMN_CTRL1  (0xC800 * 4)
+#define TB_ADDR_CMN_DIAG_HSCLK_SEL (0x01e0 * 4)
+#define TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR   (0x0084 * 4)
+#define TB_ADDR_CMN_PLL0_VCOCAL_ITER_TMR   (0x0085 * 4)
+#define TB_ADDR_CMN_PLL0_INTDIV(0x0094 * 4)
+#define TB_ADDR_CMN_PLL0_FRACDIV   (0x0095 * 4)
+#define TB_ADDR_CMN_PLL0_HIGH_THR  (0x0096 * 4)
+#define TB_ADDR_CMN_PLL0_SS_CTRL1  (0x0098 * 4)
+#define TB_ADDR_CMN_PLL0_SS_CTRL2  (0x0099 * 4)
+#define TB_ADDR_CMN_PLL0_DSM_DIAG  (0x0097 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_OVRD (0x01c2 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_FBH_OVRD (0x01c0 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_FBL_OVRD (0x01c1 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_V2I_TUNE  (0x01C5 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_CP_TUNE   (0x01C6 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_LF_PROG   (0x01C7 * 4)
+#define TB_ADDR_CMN_DIAG_PLL0_TEST_MODE(0x01c4 * 4)
+#define TB_ADDR_CMN_PSM_CLK_CTRL   (0x0061 * 4)
+#define TB_ADDR_XCVR_DIAG_RX_LANE_CAL_RST_TMR  (0x40ea * 4)
+#define TB_ADDR_XCVR_PSM_RCTRL (0x4001 * 4)
+#define TB_ADDR_TX_PSC_A0  (0x4100 * 4)
+#define TB_ADDR_TX_PSC_A1  (0x4101 * 4)
+#define TB_ADDR_TX_PSC_A2  (0x4102 * 4)
+#define TB_ADDR_TX_PSC_A3  (0x4103 * 4)
+#define TB_ADDR_TX_DIAG_ECTRL_OVRD (0x41f5 * 4)
+#define TB_ADDR_TX_PSC_CAL (0x4106 * 4)
+#define TB_ADDR_TX_PSC_RDY (0x4107 * 4)
+#define TB_ADDR_RX_PSC_A0  (0x8000 * 4)
+#define TB_ADDR_RX_PSC_A1  (0x8001 * 4)
+#define TB_ADDR_RX_PSC_A2  (0x8002 * 4)
+#define TB_ADDR_RX_PSC_A3  (0x8003 * 4)
+#define TB_ADDR_RX_PSC_CAL (0x8006 * 4)
+#define TB_ADDR_RX_PSC_RDY (0x8007 * 4)
+#define TB_ADDR_TX_TXCC_MGNLS_MULT_000 (0x4058 * 4)
+#define TB_ADDR_TX_DIAG_BGREF_PREDRV_DELAY (0x41e7 * 4)
+#define TB_ADDR_RX_SLC_CU_ITER_TMR (0x80e3 * 4)
+#define TB_ADDR_RX_SIGDET_HL_FILT_TMR  (0x8090 * 4)
+#define TB_ADDR_RX_SAMP_DAC_CTRL   (0x8058 * 4)
+#define TB_ADDR_RX_DIAG_SIGDET_TUNE(0x81dc * 4)
+#define TB_ADDR_RX_DIAG_LFPSDET_TUNE2  (0x81df * 4)
+#define TB_ADDR_RX_DIAG_BS_TM  (0x81f5 * 4)
+#define TB_ADDR_RX_DIAG_DFE_CTRL1  (0x81d3 * 4)
+#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM4  (0x81c7 * 4)
+#define TB_ADDR_RX_DIAG_ILL_E_TRIM0(0x81c2 * 4)
+#define TB_ADDR_RX_DIAG_ILL_IQ_TRIM0   (0x81c1 * 4)
+#define TB_ADDR_RX_DIAG_ILL_IQE_TRIM6  (0x81c9 * 4)
+#define TB_ADDR_RX_DIAG_RXFE_TM3   (0x81f8 * 4)
+#define TB_ADDR_RX_DIAG_RXFE_TM4   (0x81f9 * 4)
+#define TB_ADDR_RX_DIAG_LFPSDET_TUNE   (0x81dd * 4)
+#define TB_ADDR_RX_DIAG_DFE_CTRL3  (0x81d5 * 4)
+#define TB_ADDR_RX_DIAG_SC2C_DELAY 

[U-Boot] [PATCH v2] ata: ahci allow 64-bit DMA for SATA

2019-08-28 Thread Roman Kapl
Allow 64-bit DMA on AHCI. If not supported by the host controller, at
least print a message and fail.

Signed-off-by: Roman Kapl 
---

Please disregard the previous patch, I've send a wrong version that does not
even compile.

 drivers/ata/ahci.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9a08575053..fd4df60a17 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -50,6 +50,8 @@ struct ahci_uc_priv *probe_ent = NULL;
 #define WAIT_MS_FLUSH  5000
 #define WAIT_MS_LINKUP 200
 
+#define AHCI_CAP_S64A (1u << 31)
+
 __weak void __iomem *ahci_port_base(void __iomem *base, u32 port)
 {
return base + 0x100 + (port * 0x80);
@@ -503,9 +505,15 @@ static int ahci_fill_sg(struct ahci_uc_priv *uc_priv, u8 
port,
}
 
for (i = 0; i < sg_count; i++) {
-   ahci_sg->addr =
-   cpu_to_le32((unsigned long) buf + i * MAX_DATA_BYTE_COUNT);
-   ahci_sg->addr_hi = 0;
+   /* We assume virt=phys */
+   phys_addr_t pa = (unsigned long)buf + i * MAX_DATA_BYTE_COUNT;
+
+   ahci_sg->addr = cpu_to_le32(pa & U32_MAX);
+   ahci_sg->addr_hi = cpu_to_le32((pa >> 32) & U32_MAX);
+   if (ahci_sg->addr_hi && !(uc_priv->cap & AHCI_CAP_S64A)) {
+   printf("Error: DMA address too high\n");
+   return -1;
+   }
ahci_sg->flags_size = cpu_to_le32(0x3f &
  (buf_len < MAX_DATA_BYTE_COUNT
   ? (buf_len - 1)
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] booting multi-image with several embedded dtbs

2019-08-28 Thread Rasmus Villemoes
Hi,

I have a (legacy) multi-image uImage with several embedded dtbs, but no
initrd. I.e. one created by something like "mkimage -T multi -d
zImage:dtb1:dtb2:dtb3". I thought I could boot that using the bootm
command like this

  bootm $loadaddr:0 - $loadaddr:3 # choose dtb3

but that fails with

ERROR: uImage is not a fdt

Just doing "bootm $loadaddr" kind of works (in the sense that the kernel
starts, and I can see that dtb2 got passed as dtb) fails quite miserably
once dtb1 gets interpreted as an initrd - and of course what I want is
to be able to choose between the dtbs at runtime.

Yes, we will switch to proper FIT image at some point, but is there any
way to use the existing multi-image uImage as described?

Thanks,
Rasmus
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/1] board: arm: Add support for Broadcom BCM7445

2019-08-28 Thread Bin Meng
Hi Thomas,

On Wed, Aug 28, 2019 at 6:31 AM Thomas Fitzsimmons  wrote:
>
> Hi Bin,
>
> Bin Meng  writes:
>
> > Hi Thomas,
> >
> > On Sat, Jun 9, 2018 at 6:06 AM Thomas Fitzsimmons  
> > wrote:
> >>
> >> Add support for loading U-Boot on the Broadcom 7445 SoC.  This port
> >> assumes Broadcom's BOLT bootloader is acting as the second stage
> >> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> >> as an ELF program by BOLT.
> >>
> >> Signed-off-by: Thomas Fitzsimmons 
> >> Cc: Stefan Roese 
> >> Cc: Tom Rini 
> >> Cc: Florian Fainelli 
> >> ---
> >> Changes for v4:
> >>- Use high timer register for get_ticks
> >>- Move hard-coded register addresses from Kconfig to header
> >>- Document I-cache/D-cache expectation
> >>
> >>  MAINTAINERS |  10 +
> >>  arch/arm/Kconfig|  12 +
> >>  arch/arm/Makefile   |   1 +
> >>  arch/arm/mach-bcmstb/Kconfig|  36 ++
> >>  arch/arm/mach-bcmstb/Makefile   |   8 +
> >>  arch/arm/mach-bcmstb/include/mach/gpio.h|  11 +
> >>  arch/arm/mach-bcmstb/include/mach/hardware.h|  11 +
> >>  arch/arm/mach-bcmstb/include/mach/prior_stage.h |  30 ++
> >>  arch/arm/mach-bcmstb/include/mach/sdhci.h   |  15 +
> >>  arch/arm/mach-bcmstb/include/mach/timer.h   |  13 +
> >>  arch/arm/mach-bcmstb/lowlevel_init.S|  21 ++
> >>  board/broadcom/bcmstb/MAINTAINERS   |   7 +
> >>  board/broadcom/bcmstb/Makefile  |   8 +
> >>  board/broadcom/bcmstb/bcmstb.c  | 194 +++
> >>  configs/bcm7445_defconfig   |  27 ++
> >>  doc/README.bcm7xxx  | 150 
> >>  drivers/mmc/Kconfig |  11 +
> >>  drivers/mmc/Makefile|   1 +
> >>  drivers/mmc/bcmstb_sdhci.c  |  67 
> >>  drivers/spi/Kconfig |   7 +
> >>  drivers/spi/Makefile|   1 +
> >>  drivers/spi/bcmstb_spi.c| 439 
> >> 
> >>  drivers/spi/spi-uclass.c|   2 +-
> >>  dts/Kconfig |   7 +
> >>  include/configs/bcm7445.h   |  26 ++
> >>  include/configs/bcmstb.h| 183 ++
> >>  include/fdtdec.h|   4 +
> >>  lib/fdtdec.c|   4 +
> >>  28 files changed, 1305 insertions(+), 1 deletion(-)
> >>  create mode 100644 arch/arm/mach-bcmstb/Kconfig
> >>  create mode 100644 arch/arm/mach-bcmstb/Makefile
> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h
> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h
> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h
> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h
> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h
> >>  create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S
> >>  create mode 100644 board/broadcom/bcmstb/MAINTAINERS
> >>  create mode 100644 board/broadcom/bcmstb/Makefile
> >>  create mode 100644 board/broadcom/bcmstb/bcmstb.c
> >>  create mode 100644 configs/bcm7445_defconfig
> >>  create mode 100644 doc/README.bcm7xxx
> >>  create mode 100644 drivers/mmc/bcmstb_sdhci.c
> >>  create mode 100644 drivers/spi/bcmstb_spi.c
> >>  create mode 100644 include/configs/bcm7445.h
> >>  create mode 100644 include/configs/bcmstb.h
> >>
> >
> > [snip]
> >
> >> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> >> index d2d091f..c517d06 100644
> >> --- a/drivers/spi/spi-uclass.c
> >> +++ b/drivers/spi/spi-uclass.c
> >> @@ -273,7 +273,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, 
> >> int mode,
> >> bool created = false;
> >> int ret;
> >>
> >> -#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> +#if CONFIG_IS_ENABLED(OF_PLATDATA) || CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
> >
> > Could you please explain this change a little bit? Why should we call
> > uclass_first_device_err() for OF_PRIOR_STAGE?
> >
> >> ret = uclass_first_device_err(UCLASS_SPI, &bus);
> >>  #else
> >> ret = uclass_get_device_by_seq(UCLASS_SPI, busnum, &bus);
>
> On the BCM7445 eval board, the prior-stage-provided device tree does not
> have an alias for spi0, though it has aliases for other device types; I
> don't know why this is the case, but I don't have control over what the
> prior stage bootloader (Broadcom's BOLT) provides.  Without that alias,
> uclass_get_device_by_seq fails to find the SPI bus (and so U-Boot can't
> find the SPI flash device that stores its environment).
>

I checked uclass_get_device_by_seq() and did not find any codes that
are trying to read aliases. Am I missing anything?

> At the time, I checked other ARM device trees in the Linux kernel and
> not many set a

[U-Boot] [PATCH v4 1/8] dm: cache: Add enable and disable ops for cache uclass

2019-08-28 Thread Andes
From: Rick Chen 

Add cache enable/disable ops to the DM cache uclass driver

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 drivers/cache/cache-uclass.c | 20 
 include/cache.h  | 31 +++
 2 files changed, 51 insertions(+)

diff --git a/drivers/cache/cache-uclass.c b/drivers/cache/cache-uclass.c
index 97ce024..3b20a10 100644
--- a/drivers/cache/cache-uclass.c
+++ b/drivers/cache/cache-uclass.c
@@ -17,6 +17,26 @@ int cache_get_info(struct udevice *dev, struct cache_info 
*info)
return ops->get_info(dev, info);
 }
 
+int cache_enable(struct udevice *dev)
+{
+   struct cache_ops *ops = cache_get_ops(dev);
+
+   if (!ops->enable)
+   return -ENOSYS;
+
+   return ops->enable(dev);
+}
+
+int cache_disable(struct udevice *dev)
+{
+   struct cache_ops *ops = cache_get_ops(dev);
+
+   if (!ops->disable)
+   return -ENOSYS;
+
+   return ops->disable(dev);
+}
+
 UCLASS_DRIVER(cache) = {
.id = UCLASS_CACHE,
.name   = "cache",
diff --git a/include/cache.h b/include/cache.h
index c6334ca..32f59fd 100644
--- a/include/cache.h
+++ b/include/cache.h
@@ -22,6 +22,22 @@ struct cache_ops {
 * @return 0 if OK, -ve on error
 */
int (*get_info)(struct udevice *dev, struct cache_info *info);
+
+   /**
+* enable() - Enable cache
+*
+* @dev:Device to check (UCLASS_CACHE)
+* @return 0 if OK, -ve on error
+*/
+   int (*enable)(struct udevice *dev);
+
+   /**
+* disable() - Flush and disable cache
+*
+* @dev:Device to check (UCLASS_CACHE)
+* @return 0 if OK, -ve on error
+*/
+   int (*disable)(struct udevice *dev);
 };
 
 #define cache_get_ops(dev) ((struct cache_ops *)(dev)->driver->ops)
@@ -35,4 +51,19 @@ struct cache_ops {
  */
 int cache_get_info(struct udevice *dev, struct cache_info *info);
 
+/**
+ * cache_enable() - Enable cache
+ *
+ * @dev:   Device to check (UCLASS_CACHE)
+ * @return 0 if OK, -ve on error
+ */
+int cache_enable(struct udevice *dev);
+
+/**
+ * cache_disable() - Flush and disable cache
+ *
+ * @dev:   Device to check (UCLASS_CACHE)
+ * @return 0 if OK, -ve on error
+ */
+int cache_disable(struct udevice *dev);
 #endif
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 0/8] Support Andes RISC-V l2cache on AE350 platform

2019-08-28 Thread Andes
From: Rick Chen 

Add a v5l2 cache controller driver that is usually found on
Andes RISC-V ae350 platform. It will parse and configure the
cache settings (data & instruction prefetch, data & tag latency)
from the device tree blob.

Also implement L2 cache flush and disable before jump to linux.
The sequence will be preferred as below:
L1 flush -> L1 disable -> L2 flush -> L2 disable

Changes in v4:
- Remove definitions of v5l2cache.h to cache-v5l2.c

Changes in v3:
- Add the enable/disable in sandbox_cache.c.
- Parse dtb data in v5l2_ofdata_to_platdata() and configure HW in v5l2_probe().
- Move cache_disable() into dcache_disable() of cache.c

Changes in v2:
- Add new patch [1/7] to support dm cache uclass enable and disable ops.
- Use ofdata_to_platdata() to parse and save register base instead of global 
data.
- Rename compatible string of "cache" as "v5l2cache".
- make v512_init() return void.
- Use dm cache uclass api to disable L2 cache.

Rick Chen (8):
  dm: cache: Add enable and disable ops for cache uclass
  dm: cache: Add enable and disable ops for sandbox and test
  dm: cache: add v5l2 cache controller driver
  riscv: ae350: use the v5l2 driver to configure the cache
  riscv: ax25: add imply v5l2 cache controller
  riscv: cache: Flush L2 cache before jump to linux
  riscv: dts: move out AE350 L2 node from cpus node
  riscv: cache: use CCTL to flush d-cache

 arch/riscv/cpu/ax25/Kconfig |   1 +
 arch/riscv/cpu/ax25/cache.c |  39 +--
 arch/riscv/dts/ae350_32.dts |  17 +--
 arch/riscv/dts/ae350_64.dts |  17 +--
 board/AndesTech/ax25-ae350/ax25-ae350.c |   9 ++
 drivers/cache/Kconfig   |   9 ++
 drivers/cache/Makefile  |   1 +
 drivers/cache/cache-uclass.c|  20 
 drivers/cache/cache-v5l2.c  | 186 
 drivers/cache/sandbox_cache.c   |  13 +++
 include/cache.h |  31 ++
 test/dm/cache.c |   2 +
 12 files changed, 324 insertions(+), 21 deletions(-)
 create mode 100644 drivers/cache/cache-v5l2.c

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 3/8] dm: cache: add v5l2 cache controller driver

2019-08-28 Thread Andes
From: Rick Chen 

Add a v5l2 cache controller driver that is usually found on
Andes RISC-V ae350 platform. It will parse the cache settings
from the dtb.

In this version tag and data ram control timing can be adjusted
by the requirement from the dtb.

Signed-off-by: Rick Chen 
Cc: KC Lin 
---
 drivers/cache/Kconfig  |   9 +++
 drivers/cache/Makefile |   1 +
 drivers/cache/cache-v5l2.c | 186 +
 3 files changed, 196 insertions(+)
 create mode 100644 drivers/cache/cache-v5l2.c

diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
index 24def7a..629039e 100644
--- a/drivers/cache/Kconfig
+++ b/drivers/cache/Kconfig
@@ -22,4 +22,13 @@ config L2X0_CACHE
  ARMv7(32-bit) devices. The driver configures the cache settings
  found in the device tree.
 
+config V5L2_CACHE
+   bool "Andes V5L2 cache driver"
+   select CACHE
+   depends on RISCV_NDS_CACHE
+   help
+ Support Andes V5L2 cache controller in AE350 platform.
+ It will configure tag and data ram timing control from the
+ device tree and enable L2 cache.
+
 endmenu
diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
index 9deb961..4a6458c 100644
--- a/drivers/cache/Makefile
+++ b/drivers/cache/Makefile
@@ -2,3 +2,4 @@
 obj-$(CONFIG_CACHE) += cache-uclass.o
 obj-$(CONFIG_SANDBOX) += sandbox_cache.o
 obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
+obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o
diff --git a/drivers/cache/cache-v5l2.c b/drivers/cache/cache-v5l2.c
new file mode 100644
index 000..d367171
--- /dev/null
+++ b/drivers/cache/cache-v5l2.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct l2cache {
+   volatile u64configure;
+   volatile u64control;
+   volatile u64hpm0;
+   volatile u64hpm1;
+   volatile u64hpm2;
+   volatile u64hpm3;
+   volatile u64error_status;
+   volatile u64ecc_error;
+   volatile u64cctl_command0;
+   volatile u64cctl_access_line0;
+   volatile u64cctl_command1;
+   volatile u64cctl_access_line1;
+   volatile u64cctl_command2;
+   volatile u64cctl_access_line2;
+   volatile u64cctl_command3;
+   volatile u64cctl_access_line4;
+   volatile u64cctl_status;
+};
+
+/* Control Register */
+#define L2_ENABLE  0x1
+/* prefetch */
+#define IPREPETCH_OFF  3
+#define DPREPETCH_OFF  5
+#define IPREPETCH_MSK  (3 << IPREPETCH_OFF)
+#define DPREPETCH_MSK  (3 << DPREPETCH_OFF)
+/* tag ram */
+#define TRAMOCTL_OFF   8
+#define TRAMICTL_OFF   10
+#define TRAMOCTL_MSK   (3 << TRAMOCTL_OFF)
+#define TRAMICTL_MSK   BIT(TRAMICTL_OFF)
+/* data ram */
+#define DRAMOCTL_OFF   11
+#define DRAMICTL_OFF   13
+#define DRAMOCTL_MSK   (3 << DRAMOCTL_OFF)
+#define DRAMICTL_MSK   BIT(DRAMICTL_OFF)
+
+/* CCTL Command Register */
+#define CCTL_CMD_REG(base, hart)   ((ulong)(base) + 0x40 + (hart) * 0x10)
+#define L2_WBINVAL_ALL 0x12
+
+/* CCTL Status Register */
+#define CCTL_STATUS_MSK(hart)  (0xf << ((hart) * 4))
+#define CCTL_STATUS_IDLE(hart) (0 << ((hart) * 4))
+#define CCTL_STATUS_PROCESS(hart)  (1 << ((hart) * 4))
+#define CCTL_STATUS_ILLEGAL(hart)  (2 << ((hart) * 4))
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct v5l2_plat {
+   struct l2cache  *regs;
+   u32 iprefetch;
+   u32 dprefetch;
+   u32 tram_ctl[2];
+   u32 dram_ctl[2];
+};
+
+static int v5l2_enable(struct udevice *dev)
+{
+   struct v5l2_plat *plat = dev_get_platdata(dev);
+   volatile struct l2cache *regs = plat->regs;
+
+   if (regs)
+   setbits_le32(®s->control, L2_ENABLE);
+
+   return 0;
+}
+
+static int v5l2_disable(struct udevice *dev)
+{
+   struct v5l2_plat *plat = dev_get_platdata(dev);
+   volatile struct l2cache *regs = plat->regs;
+   u8 hart = gd->arch.boot_hart;
+   void __iomem *cctlcmd = (void __iomem *)CCTL_CMD_REG(regs, hart);
+
+   if ((regs) && (readl(®s->control) & L2_ENABLE)) {
+   writel(L2_WBINVAL_ALL, cctlcmd);
+
+   while ((readl(®s->cctl_status) & CCTL_STATUS_MSK(hart))) {
+   if ((readl(®s->cctl_status) & 
CCTL_STATUS_ILLEGAL(hart))) {
+   printf("L2 flush illegal! hanging...");
+   hang();
+   }
+   }
+   clrbits_le32(®s->control, L2_ENABLE);
+   }
+
+   return 0;
+}
+
+static int v5l2_ofdata_to_platdata(struct udevice *dev)
+{
+   struct v5l2_plat *plat = dev_get_platdata(dev);
+   struct l2cache *regs;
+
+   regs = (struct l2cache *)dev_read_addr(dev);
+   plat->regs = regs;
+
+   plat->iprefetch = -EINVAL;
+   plat->dpref

[U-Boot] [PATCH v4 2/8] dm: cache: Add enable and disable ops for sandbox and test

2019-08-28 Thread Andes
From: Rick Chen 

Add cache enable and disable ops for test coverage.

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 drivers/cache/sandbox_cache.c | 13 +
 test/dm/cache.c   |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/cache/sandbox_cache.c b/drivers/cache/sandbox_cache.c
index 14cc6b0..9050c4c 100644
--- a/drivers/cache/sandbox_cache.c
+++ b/drivers/cache/sandbox_cache.c
@@ -17,8 +17,21 @@ static int sandbox_get_info(struct udevice *dev, struct 
cache_info *info)
return 0;
 }
 
+static int sandbox_enable(struct udevice *dev)
+{
+   return 0;
+}
+
+static int snadbox_disable(struct udevice *dev)
+{
+   return 0;
+}
+
+
 static const struct cache_ops sandbox_cache_ops = {
.get_info   = sandbox_get_info,
+   .enable = sandbox_enable,
+   .disable= snadbox_disable,
 };
 
 static const struct udevice_id sandbox_cache_ids[] = {
diff --git a/test/dm/cache.c b/test/dm/cache.c
index d4144aa..2e244b1 100644
--- a/test/dm/cache.c
+++ b/test/dm/cache.c
@@ -14,6 +14,8 @@ static int dm_test_reset(struct unit_test_state *uts)
 
ut_assertok(uclass_get_device(UCLASS_CACHE, 0, &dev_cache));
ut_assertok(cache_get_info(dev, &info));
+   ut_assertok(cache_enable(dev));
+   ut_assertok(cache_disable(dev));
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 6/8] riscv: cache: Flush L2 cache before jump to linux

2019-08-28 Thread Andes
From: Rick Chen 

Flush and disable L2 cache in dcache_disable()
which will be called in cleanup_before_linux()
before jump to linux.

The sequence will be preferred as below:
L1 flush -> L1 disable -> L2 flush -> L2 disable

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 arch/riscv/cpu/ax25/cache.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
index cd95058..8f5455e 100644
--- a/arch/riscv/cpu/ax25/cache.c
+++ b/arch/riscv/cpu/ax25/cache.c
@@ -5,6 +5,9 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 
 void flush_dcache_all(void)
 {
@@ -59,11 +62,18 @@ void dcache_enable(void)
 {
 #if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
 #ifdef CONFIG_RISCV_NDS_CACHE
+   struct udevice *dev = NULL;
+
asm volatile (
"csrr t1, mcache_ctl\n\t"
"ori t0, t1, 0x2\n\t"
"csrw mcache_ctl, t0\n\t"
);
+
+   uclass_find_first_device(UCLASS_CACHE, &dev);
+
+   if (dev)
+   cache_enable(dev);
 #endif
 #endif
 }
@@ -72,12 +82,19 @@ void dcache_disable(void)
 {
 #if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
 #ifdef CONFIG_RISCV_NDS_CACHE
+   struct udevice *dev = NULL;
+
asm volatile (
"fence\n\t"
"csrr t1, mcache_ctl\n\t"
"andi t0, t1, ~0x2\n\t"
"csrw mcache_ctl, t0\n\t"
);
+
+   uclass_find_first_device(UCLASS_CACHE, &dev);
+
+   if (dev)
+   cache_disable(dev);
 #endif
 #endif
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 7/8] riscv: dts: move out AE350 L2 node from cpus node

2019-08-28 Thread Andes
From: Rick Chen 

When L2 node exists inside cpus node, uclass_get_device
can not parse L2 node successfully. So move it outside
from cpus node.

Also add tag-ram-ctl and data-ram-ctl attributes for
v5l2 cache controller driver. This can adjust timing
by requirement from dtb to improve performance.

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 arch/riscv/dts/ae350_32.dts | 17 +++--
 arch/riscv/dts/ae350_64.dts | 17 +++--
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index cb6ee13..97b7cee 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -62,13 +62,18 @@
compatible = "riscv,cpu-intc";
};
};
+   };
 
-   L2: l2-cache@e050 {
-   compatible = "cache";
-   cache-level = <2>;
-   cache-size = <0x4>;
-   reg = <0x0 0xe050 0x0 0x4>;
-   };
+   L2: l2-cache@e050 {
+   compatible = "v5l2cache";
+   cache-level = <2>;
+   cache-size = <0x4>;
+   reg = <0xe050 0x4>;
+   andes,inst-prefetch = <3>;
+   andes,data-prefetch = <3>;
+   /* The value format is  */
+   andes,tag-ram-ctl = <0 0>;
+   andes,data-ram-ctl = <0 0>;
};
 
memory@0 {
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 705491a..d8f00f8 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -62,13 +62,18 @@
compatible = "riscv,cpu-intc";
};
};
+   };
 
-   L2: l2-cache@e050 {
-   compatible = "cache";
-   cache-level = <2>;
-   cache-size = <0x4>;
-   reg = <0x0 0xe050 0x0 0x4>;
-   };
+   L2: l2-cache@e050 {
+   compatible = "v5l2cache";
+   cache-level = <2>;
+   cache-size = <0x4>;
+   reg = <0x0 0xe050 0x0 0x4>;
+   andes,inst-prefetch = <3>;
+   andes,data-prefetch = <3>;
+   /* The value format is  */
+   andes,tag-ram-ctl = <0 0>;
+   andes,data-ram-ctl = <0 0>;
};
 
memory@0 {
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 5/8] riscv: ax25: add imply v5l2 cache controller

2019-08-28 Thread Andes
From: Rick Chen 

Select the v5l2 UCLASS_CACHE driver for ax25.

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 arch/riscv/cpu/ax25/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig
index 6b4b92e..49be775 100644
--- a/arch/riscv/cpu/ax25/Kconfig
+++ b/arch/riscv/cpu/ax25/Kconfig
@@ -4,6 +4,7 @@ config RISCV_NDS
imply CPU
imply CPU_RISCV
imply RISCV_TIMER
+   imply V5L2_CACHE
imply ANDES_PLIC if RISCV_MMODE
imply ANDES_PLMT if RISCV_MMODE
help
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 4/8] riscv: ae350: use the v5l2 driver to configure the cache

2019-08-28 Thread Andes
From: Rick Chen 

Find the UCLASS_CACHE driver to configure the cache controller's
settings.

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 board/AndesTech/ax25-ae350/ax25-ae350.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 3d65ce7..b43eebb 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -93,10 +94,18 @@ int smc_init(void)
return 0;
 }
 
+static void v5l2_init(void)
+{
+   struct udevice *dev;
+
+   uclass_get_device(UCLASS_CACHE, 0, &dev);
+}
+
 #ifdef CONFIG_BOARD_EARLY_INIT_F
 int board_early_init_f(void)
 {
smc_init();
+   v5l2_init();
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v4 8/8] riscv: cache: use CCTL to flush d-cache

2019-08-28 Thread Andes
From: Rick Chen 

Use CCTL command to do d-cache write back
and invalidate instead of fence.

Signed-off-by: Rick Chen 
Cc: KC Lin 
Reviewed-by: Bin Meng 
---
 arch/riscv/cpu/ax25/cache.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
index 8f5455e..41de30c 100644
--- a/arch/riscv/cpu/ax25/cache.c
+++ b/arch/riscv/cpu/ax25/cache.c
@@ -8,17 +8,21 @@
 #include 
 #include 
 #include 
+#include 
+
+#ifdef CONFIG_RISCV_NDS_CACHE
+/* mcctlcommand */
+#define CCTL_REG_MCCTLCOMMAND_NUM  0x7cc
+
+/* D-cache operation */
+#define CCTL_L1D_WBINVAL_ALL   6
+#endif
 
 void flush_dcache_all(void)
 {
-   /*
-* Andes' AX25 does not have a coherence agent. U-Boot must use data
-* cache flush and invalidate functions to keep data in the system
-* coherent.
-* The implementation of the fence instruction in the AX25 flushes the
-* data cache and is used for this purpose.
-*/
-   asm volatile ("fence" ::: "memory");
+#ifdef CONFIG_RISCV_NDS_CACHE
+   csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
+#endif
 }
 
 void flush_dcache_range(unsigned long start, unsigned long end)
@@ -84,8 +88,8 @@ void dcache_disable(void)
 #ifdef CONFIG_RISCV_NDS_CACHE
struct udevice *dev = NULL;
 
+   csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
asm volatile (
-   "fence\n\t"
"csrr t1, mcache_ctl\n\t"
"andi t0, t1, ~0x2\n\t"
"csrw mcache_ctl, t0\n\t"
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] Makefile: fix newline escaping for CONFIG_DEFAULT_ENV_FILE

2019-08-28 Thread Rasmus Villemoes
I wanted this to be compatible with mkenvimage, including the ability
to embed newlines in variables by escaping them. But I failed to check
that it works more than once.

Fixes: f3d8f7dd73a (Allow providing default environment from file)
Signed-off-by: Rasmus Villemoes 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index aedc2ea4d9..8ae59ef3f0 100644
--- a/Makefile
+++ b/Makefile
@@ -1633,7 +1633,7 @@ define filechk_defaultenv.h
(grep -v '^#' | \
 grep -v '^$$' | \
 tr '\n' '\0' | \
-sed -e 's/\\\x0/\n/' | \
+sed -e 's/\\\x0/\n/g' | \
 xxd -i ; echo ", 0x00" ; )
 endef
 
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2 0/6] bmips: add brcmnand support

2019-08-28 Thread Álvaro Fernández Rojas
These patches add support for brcmnand on bmips.
The current brcmnand driver only supports controller >= 4.0,
which means that only BCM63268 works right now.

v2: Drop CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

Álvaro Fernández Rojas (6):
  nand: brcm: add BCM6368 support
  bmips: bcm6368: add support for brcmnand
  bmips: bcm6328: add support for brcmnand
  bmips: bcm6362: add support for brcmnand
  bmips: bcm63268: add support for brcmnand
  bmips: enable vr-3032u nand support

 arch/mips/dts/brcm,bcm63268.dtsi |  18 +++
 arch/mips/dts/brcm,bcm6328.dtsi  |  16 +++
 arch/mips/dts/brcm,bcm6362.dtsi  |  18 +++
 arch/mips/dts/brcm,bcm6368.dtsi  |  18 +++
 arch/mips/dts/comtrend,vr-3032u.dts  |  13 ++
 configs/comtrend_vr3032u_ram_defconfig   |   5 +
 drivers/mtd/nand/raw/Kconfig |   6 +
 drivers/mtd/nand/raw/brcmnand/Makefile   |   1 +
 drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c | 122 +++
 include/configs/comtrend_vr3032u.h   |   5 +
 10 files changed, 222 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c

-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2 1/6] nand: brcm: add BCM6368 support

2019-08-28 Thread Álvaro Fernández Rojas
This adds support for BCM6368, BCM6328, BCM6362 and BCM63268 SoCs.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: no changes

 drivers/mtd/nand/raw/Kconfig |   6 +
 drivers/mtd/nand/raw/brcmnand/Makefile   |   1 +
 drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c | 122 +++
 3 files changed, 129 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index a129f44869..2000826c79 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -72,6 +72,12 @@ config NAND_BRCMNAND
  Enable the driver for NAND flash on platforms using a Broadcom NAND
  controller.
 
+config NAND_BRCMNAND_6368
+   bool "Support Broadcom NAND controller on bcm6368"
+   depends on NAND_BRCMNAND && ARCH_BMIPS
+   help
+ Enable support for broadcom nand driver on bcm6368.
+
 config NAND_BRCMNAND_6838
bool "Support Broadcom NAND controller on bcm6838"
depends on NAND_BRCMNAND && ARCH_BMIPS && SOC_BMIPS_BCM6838
diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile 
b/drivers/mtd/nand/raw/brcmnand/Makefile
index a2363cc80e..7e70b859dc 100644
--- a/drivers/mtd/nand/raw/brcmnand/Makefile
+++ b/drivers/mtd/nand/raw/brcmnand/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+obj-$(CONFIG_NAND_BRCMNAND_6368) += bcm6368_nand.o
 obj-$(CONFIG_NAND_BRCMNAND_63158) += bcm63158_nand.o
 obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
 obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
diff --git a/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c 
b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c
new file mode 100644
index 00..1768d3945f
--- /dev/null
+++ b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "brcmnand.h"
+
+struct bcm6368_nand_soc {
+   struct brcmnand_soc soc;
+   void __iomem *base;
+};
+
+#define BCM6368_NAND_INT   0x00
+#define  BCM6368_NAND_STATUS_SHIFT 0
+#define  BCM6368_NAND_STATUS_MASK  (0xfff << BCM6368_NAND_STATUS_SHIFT)
+#define  BCM6368_NAND_ENABLE_SHIFT 16
+#define  BCM6368_NAND_ENABLE_MASK  (0x << BCM6368_NAND_ENABLE_SHIFT)
+
+enum {
+   BCM6368_NP_READ = BIT(0),
+   BCM6368_BLOCK_ERASE = BIT(1),
+   BCM6368_COPY_BACK   = BIT(2),
+   BCM6368_PAGE_PGM= BIT(3),
+   BCM6368_CTRL_READY  = BIT(4),
+   BCM6368_DEV_RBPIN   = BIT(5),
+   BCM6368_ECC_ERR_UNC = BIT(6),
+   BCM6368_ECC_ERR_CORR= BIT(7),
+};
+
+static bool bcm6368_nand_intc_ack(struct brcmnand_soc *soc)
+{
+   struct bcm6368_nand_soc *priv =
+   container_of(soc, struct bcm6368_nand_soc, soc);
+   void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+   u32 val = brcmnand_readl(mmio);
+
+   if (val & (BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT)) {
+   /* Ack interrupt */
+   val &= ~BCM6368_NAND_STATUS_MASK;
+   val |= BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT;
+   brcmnand_writel(val, mmio);
+   return true;
+   }
+
+   return false;
+}
+
+static void bcm6368_nand_intc_set(struct brcmnand_soc *soc, bool en)
+{
+   struct bcm6368_nand_soc *priv =
+   container_of(soc, struct bcm6368_nand_soc, soc);
+   void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+   u32 val = brcmnand_readl(mmio);
+
+   /* Don't ack any interrupts */
+   val &= ~BCM6368_NAND_STATUS_MASK;
+
+   if (en)
+   val |= BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT;
+   else
+   val &= ~(BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT);
+
+   brcmnand_writel(val, mmio);
+}
+
+static int bcm6368_nand_probe(struct udevice *dev)
+{
+   struct udevice *pdev = dev;
+   struct bcm6368_nand_soc *priv = dev_get_priv(dev);
+   struct brcmnand_soc *soc;
+   struct resource res;
+
+   soc = &priv->soc;
+
+   dev_read_resource_byname(pdev, "nand-int-base", &res);
+   priv->base = ioremap(res.start, resource_size(&res));
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   soc->ctlrdy_ack = bcm6368_nand_intc_ack;
+   soc->ctlrdy_set_enabled = bcm6368_nand_intc_set;
+
+   /* Disable and ack all interrupts  */
+   brcmnand_writel(0, priv->base + BCM6368_NAND_INT);
+   brcmnand_writel(BCM6368_NAND_STATUS_MASK,
+   priv->base + BCM6368_NAND_INT);
+
+   return brcmnand_probe(pdev, soc);
+}
+
+static const struct udevice_id bcm6368_nand_dt_ids[] = {
+   {
+   .compatible = "brcm,nand-bcm6368",
+   },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(bcm6368_nand) = {
+   .name = "bcm6368-nand",
+   .id = UCLASS_MTD,
+   .of_matc

[U-Boot] [PATCH V2 2/6] bmips: bcm6368: add support for brcmnand

2019-08-28 Thread Álvaro Fernández Rojas
BCM6368 uses old 2.1 HW nand controller, which isn't currently supported by
brcmnand driver.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: no changes

 arch/mips/dts/brcm,bcm6368.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6368.dtsi b/arch/mips/dts/brcm,bcm6368.dtsi
index 89590d6ff9..69be65056e 100644
--- a/arch/mips/dts/brcm,bcm6368.dtsi
+++ b/arch/mips/dts/brcm,bcm6368.dtsi
@@ -146,6 +146,24 @@
status = "disabled";
};
 
+   nand: nand-controller@1200 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "brcm,nand-bcm6368",
+"brcm,brcmnand-v2.1",
+"brcm,brcmnand";
+   reg-names = "nand",
+   "nand-cache",
+   "nand-int-base";
+   reg = <0x1200 0x180>,
+ <0x1600 0x200>,
+ <0x10b0 0x10>;
+   clocks = <&periph_clk BCM6368_CLK_NAND>;
+   clock-names = "nand";
+
+   status = "disabled";
+   };
+
spi: spi@1800 {
compatible = "brcm,bcm6358-spi";
reg = <0x1800 0x70c>;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 6/6] bmips: enable vr-3032u nand support

2019-08-28 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 v2: Drop CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

 arch/mips/dts/comtrend,vr-3032u.dts| 13 +
 configs/comtrend_vr3032u_ram_defconfig |  5 +
 include/configs/comtrend_vr3032u.h |  5 +
 3 files changed, 23 insertions(+)

diff --git a/arch/mips/dts/comtrend,vr-3032u.dts 
b/arch/mips/dts/comtrend,vr-3032u.dts
index 512cb52de3..110119b507 100644
--- a/arch/mips/dts/comtrend,vr-3032u.dts
+++ b/arch/mips/dts/comtrend,vr-3032u.dts
@@ -99,6 +99,19 @@
};
 };
 
+&nand {
+   status = "okay";
+
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-strength = <15>;
+   nand-ecc-step-size = <512>;
+   nand-on-flash-bbt;
+   brcm,nand-oob-sector-size = <64>;
+   };
+};
+
 &ohci {
status = "okay";
 };
diff --git a/configs/comtrend_vr3032u_ram_defconfig 
b/configs/comtrend_vr3032u_ram_defconfig
index 013c9ee1f6..33be24c45b 100644
--- a/configs/comtrend_vr3032u_ram_defconfig
+++ b/configs/comtrend_vr3032u_ram_defconfig
@@ -25,6 +25,7 @@ CONFIG_CMD_LICENSE=y
 CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_LOADS is not set
+CONFIG_CMD_NAND=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
@@ -37,6 +38,10 @@ CONFIG_DM_GPIO=y
 CONFIG_LED=y
 CONFIG_LED_BCM6328=y
 CONFIG_LED_BLINK=y
+CONFIG_MTD=y
+CONFIG_NAND=y
+CONFIG_NAND_BRCMNAND=y
+CONFIG_NAND_BRCMNAND_6368=y
 CONFIG_DM_ETH=y
 CONFIG_BCM6368_ETH=y
 CONFIG_PHY=y
diff --git a/include/configs/comtrend_vr3032u.h 
b/include/configs/comtrend_vr3032u.h
index e183288c5d..d625101ecb 100644
--- a/include/configs/comtrend_vr3032u.h
+++ b/include/configs/comtrend_vr3032u.h
@@ -10,3 +10,8 @@
 
 #define CONFIG_ENV_SIZE(8 * 1024)
 
+#ifdef CONFIG_NAND
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_SELF_INIT
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+#endif /* CONFIG_NAND */
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2 3/6] bmips: bcm6328: add support for brcmnand

2019-08-28 Thread Álvaro Fernández Rojas
BCM6328 uses old 2.2 HW nand controller, which isn't currently supported by
brcmnand driver.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: no changes

 arch/mips/dts/brcm,bcm6328.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6328.dtsi b/arch/mips/dts/brcm,bcm6328.dtsi
index 50beed4171..350c0e903b 100644
--- a/arch/mips/dts/brcm,bcm6328.dtsi
+++ b/arch/mips/dts/brcm,bcm6328.dtsi
@@ -124,6 +124,22 @@
status = "disabled";
};
 
+   nand: nand-controller@1200 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "brcm,nand-bcm6368",
+"brcm,brcmnand-v2.2",
+"brcm,brcmnand";
+   reg-names = "nand",
+   "nand-cache",
+   "nand-int-base";
+   reg = <0x1200 0x180>,
+ <0x1400 0x200>,
+ <0x10b0 0x10>;
+
+   status = "disabled";
+   };
+
leds: led-controller@1800 {
compatible = "brcm,bcm6328-leds";
reg = <0x1800 0x24>;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2 5/6] bmips: bcm63268: add support for brcmnand

2019-08-28 Thread Álvaro Fernández Rojas
BCM63268 uses 4.0 HW nand controller, which is currently supported by
brcmnand driver.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: no changes

 arch/mips/dts/brcm,bcm63268.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm63268.dtsi b/arch/mips/dts/brcm,bcm63268.dtsi
index f8a72ef535..5294242529 100644
--- a/arch/mips/dts/brcm,bcm63268.dtsi
+++ b/arch/mips/dts/brcm,bcm63268.dtsi
@@ -141,6 +141,24 @@
status = "disabled";
};
 
+   nand: nand-controller@1200 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "brcm,nand-bcm6368",
+"brcm,brcmnand-v4.0",
+"brcm,brcmnand";
+   reg-names = "nand",
+   "nand-cache",
+   "nand-int-base";
+   reg = <0x1200 0x180>,
+ <0x1600 0x200>,
+ <0x10b0 0x10>;
+   clocks = <&periph_clk BCM63268_CLK_NAND>;
+   clock-names = "nand";
+
+   status = "disabled";
+   };
+
periph_pwr: power-controller@1000184c {
compatible = "brcm,bcm6328-power-domain";
reg = <0x1000184c 0x4>;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2 4/6] bmips: bcm6362: add support for brcmnand

2019-08-28 Thread Álvaro Fernández Rojas
BCM6362 uses old 2.2 HW nand controller, which isn't currently supported by
brcmnand driver.

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: no changes

 arch/mips/dts/brcm,bcm6362.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6362.dtsi b/arch/mips/dts/brcm,bcm6362.dtsi
index c77b80a4cc..23c47963c3 100644
--- a/arch/mips/dts/brcm,bcm6362.dtsi
+++ b/arch/mips/dts/brcm,bcm6362.dtsi
@@ -135,6 +135,24 @@
status = "disabled";
};
 
+   nand: nand-controller@1200 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "brcm,nand-bcm6368",
+"brcm,brcmnand-v2.2",
+"brcm,brcmnand";
+   reg-names = "nand",
+   "nand-cache",
+   "nand-int-base";
+   reg = <0x1200 0x180>,
+ <0x1600 0x200>,
+ <0x10b0 0x10>;
+   clocks = <&periph_clk BCM6362_CLK_NAND>;
+   clock-names = "nand";
+
+   status = "disabled";
+   };
+
lsspi: spi@1800 {
compatible = "brcm,bcm6358-spi";
reg = <0x1800 0x70c>;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] python3 support for pylibfdt

2019-08-28 Thread Peter Robinson
Hi Simon,

> > > > > > With the EOL of python2 soon I've been looking at the Fedora U-Boot
> > > > > > builds to see what it would take to move over to python3. There's a
> > > > > > couple of issues building the bundled pylibfdt, the first is the
> > > > > > Makefile hard codes python2, the second is that the generated
> > > > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h
> > > > > > (errors below).
> > > > > >
> > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 but 
> > > > > > I
> > > > > > couldn't quite work out how this fits into the U-Boot bundled 
> > > > > > version.
> > > > > > Is there plans to be able to support pylibfdt with python3?
> > > > >
> > > > > Sounds like we need to run the normal kernel script to re-sync with
> > > > > upstream?  Thanks!
> > > >
> > > > Seems reasonable, I'll keep an eye out for a patch series to test,
> > > > it's quite straight forward to test from my PoV.
> > >
> > > It won't be any time soon, sadly.  Updating to the same dtc in the
> > > kernel (so just v1.4.7+) causes both massive amount of new device tree
> > > warnings as well as several fail to link due to size growth problems.
> >
> > For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3
> > merge window.
>
> Also I sent a series for libfdt to reduce the size, as a first step to
> syncing up U-Boot again. It needs work, but I expect to get back to it
> next week.

What's the latest on this?

Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver

2019-08-28 Thread Sherry Sun
Hi Jean,

> 
> Hi Jean,
> 
> >
> > Hi Marek, Sherry,
> >
> >
> >  we keep the cdns3 node for usb gadget driver, then add a usb host
> >  node for
> >  xhci-imx8 driver in *-uboot.dtsi. so here is no need to change
> >  the host driver
> > >>> compatible.
> >  But the compatible in gadget driver should be changed later.
> > >>> We should try avoiding ABI breaks in DT.
> > >> But the cdns3 usb gaget driver and host driver in different uclass
> > >> need two
> > dt nodes to bind with.
> > >> And the compatible of the two node cannot be same.
> > >> So for gadget driver, the compatible may use "cdns,usb3-1.0.0", for
> > >> host
> > driver, the compatible will use "cdns,usb3-1.0.0-host".
> > >> What do you think about it?
> > > CCing Jean, since I think he did solve similar topic for his platform.
> >
> > I've been OOO for a few weeks and didn't look at the whole series.
> >
> > For this particular issue, the solution I used is to let the wrapper
> > do the binding job. The name of the driver to use is hard-coded in the
> wrapper diver.
> >
> > This is done in dwc3_glue_bind().
> 
> Thanks for your suggestions.
> 
> So if I want to use the cdns3 usb node as both usb gadget device and usb
> host device, do you mean that I should make the cdns3 usb node as a usb
> wrapper device, and create two subnodes in it.
> Then when binding the wrapper node, it will hard-coded the two subnodes
> to different driver(gadge/host driver) according to the dr_mode property in
> nodes.
> 

Do you think I understand it right?

Best regards
Sherry sun

> Best regards
> Sherry sun
> 
> >
> > JJ
> >
> >
> >
> > >
> > >> +{ }
> > >> +};
> > >
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d
> enx.de%2Flistinfo%2Fu-
> boot&data=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
> 670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C637025710721487079&sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
> GrNOxDH6HC0%3D&reserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

2019-08-28 Thread Sherry Sun
Hi Jean,

> 
> +Kishon who worked on this PHY under linux
> 
> 
> Hi Sherry,
> 
> 
> On 28/08/2019 10:05, Sherry Sun wrote:
> > Hi Jean,
> >
> >> Hi Sherry,
> >>
> >> On 21/08/2019 16:36, Sherry Sun wrote:
> >>> The cdns3-usb-phy driver supports both host and peripheral mode of
> >>> usb driver which use cadence usb3 IP.
> >>>
> >>> Signed-off-by: Sherry Sun 
> >>> ---
> >>>drivers/phy/Kconfig |   8 ++
> >>>drivers/phy/Makefile|   1 +
> >>>drivers/phy/cdns3-usb-phy.c | 241
> >> 
> >>>3 files changed, 250 insertions(+)
> >>>create mode 100644 drivers/phy/cdns3-usb-phy.c
> >>>
> >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> >>> 3942f035eb..1837b32c31 100644
> >>> --- a/drivers/phy/Kconfig
> >>> +++ b/drivers/phy/Kconfig
> >>> @@ -205,4 +205,12 @@ config MT76X8_USB_PHY
> >>>
> >>> This PHY is found on MT76x8 devices supporting USB.
> >>>
> >>> +config CDNS3_USB_PHY
> >>> + bool "Support CDNS3 USB PHY"
> >>> + depends on PHY
> >>> + help
> >>> +   Support for the USB PHY in CDNS3 IP.
> >>> +
> >>> +   This PHY is found on CDNS3 IP devices supporting USB.
> >>> +
> >>>endmenu
> >>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> >>> 3157f1b7ee..0e062214d3 100644
> >>> --- a/drivers/phy/Makefile
> >>> +++ b/drivers/phy/Makefile
> >>> @@ -22,4 +22,5 @@ obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-
> >> usbh-phy.o
> >>>obj-$(CONFIG_OMAP_USB2_PHY) += omap-usb2-phy.o
> >>>obj-$(CONFIG_KEYSTONE_USB_PHY) += keystone-usb-phy.o
> >>>obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
> >>> +obj-$(CONFIG_CDNS3_USB_PHY) += cdns3-usb-phy.o
> >>>obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o diff --git
> >>> a/drivers/phy/cdns3-usb-phy.c b/drivers/phy/cdns3-usb-phy.c new file
> >>> mode 100644 index 00..c0d308075b
> >>> --- /dev/null
> >>> +++ b/drivers/phy/cdns3-usb-phy.c
> >>> @@ -0,0 +1,241 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright 2019 NXP
> >>> + *
> >>> + * Cadence3 USB PHY driver
> >>> + *
> >>> + * Author: Sherry Sun   */
> >>> +
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +/* PHY registers */
> >>> +#define PHY_PMA_CMN_CTRL1(0xC800 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_HSCLK_SEL   (0x01e0 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_VCOCAL_INIT_TMR (0x0084 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_VCOCAL_ITER_TMR (0x0085 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_INTDIV  (0x0094 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_FRACDIV (0x0095 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_HIGH_THR(0x0096 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_SS_CTRL1(0x0098 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_SS_CTRL2(0x0099 * 4)
> >>> +#define TB_ADDR_CMN_PLL0_DSM_DIAG(0x0097 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_OVRD   (0x01c2 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_FBH_OVRD   (0x01c0 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_FBL_OVRD   (0x01c1 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_V2I_TUNE  (0x01C5 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_CP_TUNE   (0x01C6 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_LF_PROG   (0x01C7 * 4)
> >>> +#define TB_ADDR_CMN_DIAG_PLL0_TEST_MODE  (0x01c4 * 4)
> >>> +#define TB_ADDR_CMN_PSM_CLK_CTRL (0x0061 * 4)
> >>> +#define TB_ADDR_XCVR_DIAG_RX_LANE_CAL_RST_TMR(0x40ea * 4)
> >>> +#define TB_ADDR_XCVR_PSM_RCTRL   (0x4001 * 4)
> >>> +#define TB_ADDR_TX_PSC_A0(0x4100 * 4)
> >>> +#define TB_ADDR_TX_PSC_A1(0x4101 * 4)
> >>> +#define TB_ADDR_TX_PSC_A2(0x4102 * 4)
> >>> +#define TB_ADDR_TX_PSC_A3(0x4103 * 4)
> >>> +#define TB_ADDR_TX_DIAG_ECTRL_OVRD   (0x41f5 * 4)
> >>> +#define TB_ADDR_TX_PSC_CAL   (0x4106 * 4)
> >>> +#define TB_ADDR_TX_PSC_RDY   (0x4107 * 4)
> >>> +#define TB_ADDR_RX_PSC_A0(0x8000 * 4)
> >>> +#define TB_ADDR_RX_PSC_A1(0x8001 * 4)
> >>> +#define TB_ADDR_RX_PSC_A2(0x8002 * 4)
> >>> +#define TB_ADDR_RX_PSC_A3(0x8003 * 4)
> >>> +#define TB_ADDR_RX_PSC_CAL   (0x8006 * 4)
> >>> +#define TB_ADDR_RX_PSC_RDY   (0x8007 * 4)
> >>> +#define TB_ADDR_TX_TXCC_MGNLS_MULT_000   (0x4058 * 4)
> >>> +#define TB_ADDR_TX_DIAG_BGREF_PREDRV_DELAY   (0x41e7 * 4)
> >>> +#define TB_ADDR_RX_SLC_CU_ITER_TMR   (0x80e3 * 4)
> >>> +#define TB_ADDR_RX_SIGDET_HL_FILT_TMR(0x8090 * 4)
> >>> +#define TB_ADDR_RX_SAMP_DAC_CTRL (0x8058 * 4)
> >>> +#define TB_ADDR_RX_DIAG_SIGDET_TUNE  (0x81dc * 4)
> >>> +#define TB_ADDR_RX_DIAG_LFPSDET_TUNE2(0x81df * 4)
> >>> +#define TB_ADDR_RX_DIAG

Re: [U-Boot] [PATCH 07/26] pinctrl: add support for MediaTek MT7628

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

This patch adds pinctrl support for mt7628, with a file for common pinmux
functions and a file for mt7628 which has additional support for pinconf.

Signed-off-by: Weijie Gao 
---
  drivers/pinctrl/Kconfig   |   1 +
  drivers/pinctrl/Makefile  |   1 +
  drivers/pinctrl/mtmips/Kconfig|  13 +
  drivers/pinctrl/mtmips/Makefile   |   7 +
  drivers/pinctrl/mtmips/pinctrl-mt7628.c   | 585 ++
  .../pinctrl/mtmips/pinctrl-mtmips-common.c|  87 +++
  .../pinctrl/mtmips/pinctrl-mtmips-common.h|  53 ++
  7 files changed, 747 insertions(+)
  create mode 100644 drivers/pinctrl/mtmips/Kconfig
  create mode 100644 drivers/pinctrl/mtmips/Makefile
  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mt7628.c
  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.c
  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.h


Nice patch. I do have 2 questions though:

a) Why are you introducing a new "mtmips" directory and don't re-use
the already available "mediatek" directory? Is there nothing in
common with these "mediatek" drivers?

b) Somewhat related: You introduce a mtmips-common file. For which
platforms is this targeted (non-mt7628)? Is there nothing in common
with the "mediatek" files already available?

Other than that I've tested this on my MT7688 board and it works
just fine. Thanks a lot!

Thanks,
Stefan
 

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index a0ac167d14..1634dffb35 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -244,6 +244,7 @@ source "drivers/pinctrl/exynos/Kconfig"
  source "drivers/pinctrl/mediatek/Kconfig"
  source "drivers/pinctrl/meson/Kconfig"
  source "drivers/pinctrl/mscc/Kconfig"
+source "drivers/pinctrl/mtmips/Kconfig"
  source "drivers/pinctrl/mvebu/Kconfig"
  source "drivers/pinctrl/nxp/Kconfig"
  source "drivers/pinctrl/renesas/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 4b080b74dc..ce0879a2b7 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -9,6 +9,7 @@ obj-y   += nxp/
  obj-$(CONFIG_$(SPL_)PINCTRL_ROCKCHIP) += rockchip/
  obj-$(CONFIG_ARCH_ASPEED) += aspeed/
  obj-$(CONFIG_ARCH_ATH79) += ath79/
+obj-$(CONFIG_ARCH_MTMIPS) += mtmips/
  obj-$(CONFIG_ARCH_RMOBILE) += renesas/
  obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
  
diff --git a/drivers/pinctrl/mtmips/Kconfig b/drivers/pinctrl/mtmips/Kconfig

new file mode 100644
index 00..8482a38ebc
--- /dev/null
+++ b/drivers/pinctrl/mtmips/Kconfig
@@ -0,0 +1,13 @@
+
+config PINCTRL_MTMIPS
+   depends on ARCH_MTMIPS
+   bool
+
+config PINCTRL_MT7628
+   bool "MediaTek MT7628 pin control driver"
+   select PINCTRL_MTMIPS
+   depends on SOC_MT7628 && PINCTRL_GENERIC
+   help
+ Support pin multiplexing control on MediaTek MT7628.
+ The driver is controlled by a device tree node which contains
+ the pin mux functions for each available pin groups.
diff --git a/drivers/pinctrl/mtmips/Makefile b/drivers/pinctrl/mtmips/Makefile
new file mode 100644
index 00..3ba5c0c66d
--- /dev/null
+++ b/drivers/pinctrl/mtmips/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+
+# Core
+obj-$(CONFIG_PINCTRL_MTMIPS) += pinctrl-mtmips-common.o
+
+# SoC Drivers
+obj-$(CONFIG_PINCTRL_MT7628) += pinctrl-mt7628.o
diff --git a/drivers/pinctrl/mtmips/pinctrl-mt7628.c 
b/drivers/pinctrl/mtmips/pinctrl-mt7628.c
new file mode 100644
index 00..6883450a09
--- /dev/null
+++ b/drivers/pinctrl/mtmips/pinctrl-mt7628.c
@@ -0,0 +1,585 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc. All Rights Reserved.
+ *
+ * Author: Weijie Gao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtmips-common.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define AGPIO_OFS  0
+#define GPIOMODE1_OFS  0x24
+#define GPIOMODE2_OFS  0x28
+
+#define EPHY4_1_PAD_SHIFT  17
+#define EPHY4_1_PAD_MASK   0x0f
+#define EPHY0_SHIFT16
+#define RF_OLT_MODE_SHIFT  12
+#define N9_EINT_SRC_SHIFT  9
+#define WLED_OD_SHIFT  8
+#define REF_CLKO_PAD_SHIFT 4
+#define I2S_CLK_PAD_SHIFT  3
+#define I2S_WS_PAD_SHIFT   2
+#define I2S_SDO_PAD_SHIFT  1
+#define I2S_SDI_PAD_SHIFT  0
+
+#define GM4_MASK   3
+
+#define P4LED_K_SHIFT  26
+#define P3LED_K_SHIFT  24
+#define P2LED_K_SHIFT  22
+#define P1LED_K_SHIFT  20
+#define P0LED_K_SHIFT  18
+#define WLED_K_SHIFT   16
+#define P4LED_A_SHIFT  10
+#define P3LED_A_SHIFT  8
+#define P2LED_A_SHIFT  6
+#define P1L

Re: [U-Boot] [PATCH 07/26] pinctrl: add support for MediaTek MT7628

2019-08-28 Thread Stefan Roese

On 28.08.19 14:26, Stefan Roese wrote:

On 28.08.19 08:37, Weijie Gao wrote:

This patch adds pinctrl support for mt7628, with a file for common pinmux
functions and a file for mt7628 which has additional support for pinconf.

Signed-off-by: Weijie Gao 
---
   drivers/pinctrl/Kconfig   |   1 +
   drivers/pinctrl/Makefile  |   1 +
   drivers/pinctrl/mtmips/Kconfig|  13 +
   drivers/pinctrl/mtmips/Makefile   |   7 +
   drivers/pinctrl/mtmips/pinctrl-mt7628.c   | 585 ++
   .../pinctrl/mtmips/pinctrl-mtmips-common.c|  87 +++
   .../pinctrl/mtmips/pinctrl-mtmips-common.h|  53 ++
   7 files changed, 747 insertions(+)
   create mode 100644 drivers/pinctrl/mtmips/Kconfig
   create mode 100644 drivers/pinctrl/mtmips/Makefile
   create mode 100644 drivers/pinctrl/mtmips/pinctrl-mt7628.c
   create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.c
   create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.h


Nice patch. I do have 2 questions though:

a) Why are you introducing a new "mtmips" directory and don't re-use
the already available "mediatek" directory? Is there nothing in
common with these "mediatek" drivers?

b) Somewhat related: You introduce a mtmips-common file. For which
platforms is this targeted (non-mt7628)? Is there nothing in common
with the "mediatek" files already available?

Other than that I've tested this on my MT7688 board and it works
just fine. Thanks a lot!


I do have another comment though:

I've used the common "pinctrl-single" driver in Linux a few weeks ago as
there is no need for a separate MT7628 specific pin-mux driver [1][2] etc.
Frankly, I don't know that status of the "pinctrl-single" U-Boot driver
in depth. If its compatible with the Linux one (which I really hope), then
we don't need a MT7628 specific pinctrl driver but can use the "pinctrl-single"
driver as I've done in the Linux [1][2].

It would be great if you could check this and change this pinctrl support
to the common "single" driver is possible.

Thanks,
Stefan

[1] 
https://github.com/torvalds/linux/commit/380f072c57a590d7593050b8533d88e18b6a7daa
[2] 
https://github.com/torvalds/linux/commit/6394de396ed36f3e8043734676eaa9c26f84bb1b
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-28 Thread Marek Vasut
On 8/28/19 10:13 AM, Ley Foon Tan wrote:
[...]

>> If want to use address from DT, we need get address every time need to
>> use the address.
>> For non-DM, it is easier to use constant address. Let me know if you
>> still prefer to use address from DT.

 Surely you can cache the address or even better, convert to DM/DT ?
>>> Will try to cache the address for now.  But, we need get address from
>>> DT twice, one in SPL, one in Uboot. They not sharing global data.
>>
>> I don't think there's much we can do about that, unless we can somehow
>> share parsed live DT from SPL to U-Boot, but that's for another
>> discussion/patchset/etc.
> I am working on this now and found there are 2 challenges if we get
> base address from DT.
> 1. We can only get the address from DT after gd->fdt_blob is
> initialized in spl_early_init(). So, spl_early_init() need move to
> beginning of board_init_f().

This should be reasonably easy to solve I guess ?

>Tested this on Agilex, look okay. But, pending test on other device
> families, like Gen5 or A10. Not sure any side effect with this change.
> 2. Secure (for PSCI) and non-secure functions share same functions,
> these functions can't use global data (for base address). Secure
> functions have its own secure data region.

There was a discussion about this before, instead of hacking up this
part constantly, maybe we should create a separate build of U-Boot (like
SPL/TPL) and use that for the "secure" mode. But that's for another
patchset and another discussion.

> #2 is more difficult to overcome. Do you have strong opinion to get
> base address from DT? Otherwise, can we use constant define for these
> base addresses?

See above, the secure part might need further work.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v5 0/7] usb: Add cadence USB3 gadget/host/phy driver

2019-08-28 Thread Vignesh Raghavendra
Hi Sherry,

On 21/08/19 8:05 PM, Sherry Sun wrote:
> These patches introduce new Cadence driver to U-Boot.
> The first patch is to add the Cadence USB3 IP(CDNS3) core and driver for 
> the usb gadget.
> The second patch introduce the xhci-imx8 usb host driver separately.
> The third patch introduce the cdns3 phy driver which can be used for both 
> cdns3 host driver and gadget driver.
> The cdns3 usb gadget/host/phy driver are all used DM mode.
> 
> The current driver has been validated on i.MX8 platform.
> If someone want to test it, please note that the additional dts nodes/
> config macros/clock driver are also essential. You can also get
> my test patches at https://github.com/sherrysun1/u-boot-imx.git to 
> start your test quickly.
> 

I see that Cadence USB driver for Linux kernel is still under
development and DT compatible binding is supposed to be "cdns,usb3" not
"cdns,usb3-1.0.0". See v11:
https://patchwork.kernel.org/patch/4415/
Deviating from kernel binding will break sync'ing of DTs b/w kernel and
U-Boot.

Also, why not sync the latest host/gadget driver patches from kernel as
is? That should help in borrowing bug fixes/features whenever Cadence
updates kernel driver in future.

BTW, have you tested gadget driver with functions that use bulk
endpoints such as f_mass_storage or f_fastboot?

Regards
Vignesh

> Changes in v5:
>  - Delete some unnecessary code.
>  - Fix some issues about lack of parentheses.
>  - Add separate patch for core framework changes. 
>  - Add "reg-names" for usb nodes in DT and use it to get reg
>  values.
>  - Use "cdns,usb3-1.0.0" compatible instead "cdns,usb3".
>  - Add DM_FLAG_OS_PREPARE flag to xhci-imx8 driver.
> 
> Sherry Sun (7):
>   dt-bindings: add dt-binding doc for CDNS3 controller
>   usb: gadget: Add the cadence USB3 gadget driver
>   usb: gadget: Add match_ep call back to usb_gadget_ops
>   usb: gadget: Add gadget_is_cdns3 checking to provide bcdUSB value
>   usb: host: Add the USB3 host driver
>   phy: Add USB PHY driver for the cadence USB3
>   usb: gadget: core: introduce ->udc_set_speed() method
> 
>  Makefile   |1 +
>  doc/device-tree-bindings/usb/cdns-usb3.txt |   53 +
>  drivers/phy/Kconfig|8 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/cdns3-usb-phy.c|  241 +++
>  drivers/usb/Kconfig|2 +
>  drivers/usb/cdns3/Kconfig  |   20 +
>  drivers/usb/cdns3/Makefile |5 +
>  drivers/usb/cdns3/cdns3-generic.c  |  114 +
>  drivers/usb/cdns3/cdns3-nxp-reg-def.h  |   93 +
>  drivers/usb/cdns3/core.c   |  203 ++
>  drivers/usb/cdns3/core.h   |  118 ++
>  drivers/usb/cdns3/dev-regs-macro.h |  116 ++
>  drivers/usb/cdns3/dev-regs-map.h   |  117 ++
>  drivers/usb/cdns3/gadget-export.h  |   26 +
>  drivers/usb/cdns3/gadget.c | 2183 
>  drivers/usb/cdns3/gadget.h |  225 ++
>  drivers/usb/cdns3/io.h |   27 +
>  drivers/usb/gadget/epautoconf.c|4 +
>  drivers/usb/gadget/gadget_chips.h  |7 +
>  drivers/usb/gadget/udc/Makefile|1 +
>  drivers/usb/gadget/udc/udc-core.c  |   23 +
>  drivers/usb/host/Kconfig   |9 +
>  drivers/usb/host/Makefile  |1 +
>  drivers/usb/host/xhci-imx8.c   |  210 ++
>  include/linux/usb/gadget.h |5 +
>  scripts/Makefile.spl   |1 +
>  27 files changed, 3814 insertions(+)
>  create mode 100644 doc/device-tree-bindings/usb/cdns-usb3.txt
>  create mode 100644 drivers/phy/cdns3-usb-phy.c
>  create mode 100644 drivers/usb/cdns3/Kconfig
>  create mode 100644 drivers/usb/cdns3/Makefile
>  create mode 100644 drivers/usb/cdns3/cdns3-generic.c
>  create mode 100644 drivers/usb/cdns3/cdns3-nxp-reg-def.h
>  create mode 100644 drivers/usb/cdns3/core.c
>  create mode 100644 drivers/usb/cdns3/core.h
>  create mode 100644 drivers/usb/cdns3/dev-regs-macro.h
>  create mode 100644 drivers/usb/cdns3/dev-regs-map.h
>  create mode 100644 drivers/usb/cdns3/gadget-export.h
>  create mode 100644 drivers/usb/cdns3/gadget.c
>  create mode 100644 drivers/usb/cdns3/gadget.h
>  create mode 100644 drivers/usb/cdns3/io.h
>  create mode 100644 drivers/usb/host/xhci-imx8.c
> 

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Wandboard boot failure when HAB support is enabled

2019-08-28 Thread Jon Szymaniak
Hello all,

I'd like to get U-Boot >= 2019.07 booting on a Wandboard Quad with HAB
support enabled, but appear to be running into either some regressions
(or matters of PEBKAC).  For the scope of this discussion, I'm only
concerned with booting an "insecure" HAB-enabled U-Boot image (ideally
FIT), on a device that has not yet been fused (i.e., with the U-Boot
commands need to fuse and verify successful image authentication prior
to enforcing ROM-based authentication of the SPL).

As of commit df516569, I am able to use the default Wandboard
configuration, enable HAB support (CONFIG_SECURE_BOOT=y) via
menufconfig, build and then successfully boot the resulting SPL +
u-boot-ivt.img combination on a Wandboard Quad (B1).

However, as of commit 5b85858 (and onwards), I am no longer able to
boot the second stage U-Boot image when HAB support is enabled (the
SPL still works, however).  Disabling HAB support (the default
configuration state) still works, of course.

Issue #1: u-boot-ivt.img load address changed from 0x1780 to 0x

It appears that the generation of u-boot-ivt.img "breaks" in df516569
because the associated MKIMAGEFLAGS_u-boot-ivt.img definition, present
in an else clause of the top-level Makefile, is no longer used, now
that the default configuration enables SPL FIT support. As a result,
the generated image contains a load address of 0x0, which results in a
boot loop.

I've tried to work around this with the following change, which leads
me to Issue #2.  I'm unclear on whether a multi-DTB IVT image should
be instead be produced to address this, or whether "legacy" boot
images should continue to work.

diff --git a/Makefile b/Makefile
index f3857ab6a9..07fa36b4c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1243,12 +1243,13 @@ else
 MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
 -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
 -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
+endif
+
 MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \
 -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
 -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
 u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
 CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log
-endif

 MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)


Issue #2: u-boot-ivt.img stuck in lib/hang.c's hang()

Once executing u-boot-ivt.img from 0x1780, I'm seeing the
following call path occurring:

board_init_f() -> initcall_run_list @ fdtdec_setup() errors out -->
hang() -> bootstage_error(BOOTSTAGE_ID_NEED_RESET)

I'm still trying to determine specifically where in fdtdec_setup() the
failure is, but before I dig too much deeper, I was hoping to get some
feedback on whether this is simply a matter of needing to produce a
modified image that isn't currently being built.

Again, I'm not entirely clear what the expectation is here -- should I
simply not be attempting to boot the u-boot-ivt.img? Should this still
work despite not being a FIT image?  Do we need to generate a
FIT-based IVT image for this configuration?


Thank you in advance for your time and help!

Best regards,
Jon Szymaniak
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board

2019-08-28 Thread Oliver Graute
Hello list,

this is the first version of this patch that boots properly the linux kernel
on my i.MX8QM Board. It's still based on v2019.07. Please skip v1 because its
not working.

Best Regards,

Oliver

Oliver Graute (1):
  imx: support i.MX8QM ROM 7720 a1 board

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++
 arch/arm/mach-imx/imx8/Kconfig|   7 +
 arch/arm/mach-imx/mkimage_fit_atf.sh  |   3 +
 board/freescale/imx8qm_rom7720_a1/Kconfig |  14 +
 board/freescale/imx8qm_rom7720_a1/MAINTAINERS |   6 +
 board/freescale/imx8qm_rom7720_a1/Makefile|  11 +
 board/freescale/imx8qm_rom7720_a1/README  |  70 
 .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 +
 .../freescale/imx8qm_rom7720_a1/imximage.cfg  |  21 +
 board/freescale/imx8qm_rom7720_a1/spl.c   | 228 +++
 configs/imx8qm_rom7720_a1_4G_defconfig|  82 
 include/configs/imx8qm_rom7720.h  | 189 +
 13 files changed, 1186 insertions(+)
 create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
 create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig
 create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS
 create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile
 create mode 100644 board/freescale/imx8qm_rom7720_a1/README
 create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
 create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg
 create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c
 create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
 create mode 100644 include/configs/imx8qm_rom7720.h

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Error reading cluster" from fs/fat/fat.c

2019-08-28 Thread Oliver Graute
On 26/08/19, Oliver Graute wrote:
> On 22/08/19, Oliver Graute wrote:
> > Hello list,
> > 
> > I have a annoying problem with u-boot 2019.07. I try to boot a Linux
> > Image from a fat16 partition on a SD-Card. But I got the "Error reading
> > cluster" Message from fs/fat/fat.c
> > 
> > => boot
> > switch to partitions #0, OK
> > mmc2 is current device
> > Error reading cluster
> > ** Unable to read file Image **

this error occurs especially on this Swissbit SD-Card (industrial card)

=> mmcinfo
Device: FSL_SDHC
Manufacturer ID: 5d
OEM: 5342
Name: L1BM1
Bus Speed: 5000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes

another San-Disk SD-Card (consumer) I tried is working fine with same
u-boot image. So it looks for me for a wired hw/timing issue.

=> mmcinfo
Device: FSL_SDHC
Manufacturer ID: 13
OEM: 14e
Name: Q2J55 
Bus Speed: 5200
Mode: MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 7.1 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 7.1 GiB WRREL
Boot Capacity: 16 MiB ENH
RPMB Capacity: 4 MiB ENH

Best Regards,

Oliver
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board

2019-08-28 Thread Oliver Graute
Add i.MX8QM ROM 7720a1 board support

Boot log as below:
U-Boot 2019.07-1-g6c912ea4d4 (Aug 28 2019 - 13:01:45 +0200)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

Model: Advantech iMX8QM Qseven series
Board: ROM-7720-A1 4GB
Build: SCFW 65afe5f6
Boot:  SD2
DRAM:  3.9 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:   eth0: ethernet@5b04Could not get PHY for FEC1: addr 1
, eth-1: ethernet@5b05
Hit any key to stop autoboot:  0

Signed-off-by: Oliver Graute 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Simon Glass 
Cc: Ye Li 
Cc: uboot-imx 
---

These changes are based on this vendor tree:
https://github.com/ADVANTECH-Corp/uboot-imx6.git

I adapted the files and compared them with code from similar imx8qm-mek board

Changes for v2:
 - cleanup of u-boot environment
 - set power mode SC_R_DC_0 for full boot of linux kernel
 - enabled usdhc2
 - enabled FEC defines
 - updated README.md
 - enabled readwrite for nfs rootfs
 - removed include of environment header

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++
 arch/arm/mach-imx/imx8/Kconfig|   7 +
 arch/arm/mach-imx/mkimage_fit_atf.sh  |   3 +
 board/freescale/imx8qm_rom7720_a1/Kconfig |  14 +
 board/freescale/imx8qm_rom7720_a1/MAINTAINERS |   6 +
 board/freescale/imx8qm_rom7720_a1/Makefile|  11 +
 board/freescale/imx8qm_rom7720_a1/README  |  70 
 .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 +
 .../freescale/imx8qm_rom7720_a1/imximage.cfg  |  21 +
 board/freescale/imx8qm_rom7720_a1/spl.c   | 228 +++
 configs/imx8qm_rom7720_a1_4G_defconfig|  82 
 include/configs/imx8qm_rom7720.h  | 189 +
 13 files changed, 1186 insertions(+)
 create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
 create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig
 create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS
 create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile
 create mode 100644 board/freescale/imx8qm_rom7720_a1/README
 create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
 create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg
 create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c
 create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
 create mode 100644 include/configs/imx8qm_rom7720.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20dbc2ff84..54c1f40085 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -613,6 +613,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
 dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+   imx8qm-rom7720-a1.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
 
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts 
b/arch/arm/dts/imx8qm-rom7720-a1.dts
new file mode 100644
index 00..5f9ac955ed
--- /dev/null
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+
+/ {
+   model = "Advantech iMX8QM Qseven series";
+   compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
+
+   chosen {
+   bootargs = "console=ttyLP0,115200 
earlycon=lpuart32,0x5a06,115200";
+   stdout-path = &lpuart0;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_gpio_leds>;
+   user {
+   label = "heartbeat";
+   gpios = <&gpio2 15 0>;
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_usb_otg1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "usb_otg1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_usdhc2_vmmc: usdhc2_vmmc {
+   compatible = "regulator-fixed";
+   regulator-name = "sw-3p3-sd1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio4 7 GPIO_ACTIVE_HIGH>;
+   

[U-Boot] [PATCH 02/25] remoteproc: ops: Add elf section size as input parameter to device_to_virt api

2019-08-28 Thread Lokesh Vutla
Introduce a new parameter size that accepts elf section size to remoteproc
ops callback device_to_virt(). This can enforce more checks on the
elf section that is being loaded.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-elf-loader.c | 3 ++-
 drivers/remoteproc/sandbox_testproc.c | 4 +++-
 drivers/remoteproc/stm32_copro.c  | 4 +++-
 include/remoteproc.h  | 3 ++-
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/rproc-elf-loader.c 
b/drivers/remoteproc/rproc-elf-loader.c
index 67937a7595..7574ba3fb3 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -86,7 +86,8 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned long 
addr)
continue;
 
if (ops->device_to_virt)
-   dst = ops->device_to_virt(dev, (ulong)dst);
+   dst = ops->device_to_virt(dev, (ulong)dst,
+ phdr->p_memsz);
 
dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
i, dst, phdr->p_filesz);
diff --git a/drivers/remoteproc/sandbox_testproc.c 
b/drivers/remoteproc/sandbox_testproc.c
index 5f35119ab7..0a8f7871e1 100644
--- a/drivers/remoteproc/sandbox_testproc.c
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -306,9 +306,11 @@ static int sandbox_testproc_ping(struct udevice *dev)
  * sandbox_testproc_device_to_virt() - Convert device address to virtual 
address
  * @dev:   device to operate upon
  * @da:device address
+ * @size:  Size of the section
  * @return converted virtual address
  */
-static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da)
+static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da,
+ulong size)
 {
u64 paddr;
 
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index de3b9729f3..ff82313bca 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -107,9 +107,11 @@ static int stm32_copro_set_hold_boot(struct udevice *dev, 
bool hold)
  * stm32_copro_device_to_virt() - Convert device address to virtual address
  * @dev:   corresponding STM32 remote processor device
  * @da:device address
+ * @size:  Size of the section
  * @return converted virtual address
  */
-static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
+static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da,
+   ulong size)
 {
fdt32_t in_addr = cpu_to_be32(da);
u64 paddr;
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 4987194905..81f616a1f9 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -122,9 +122,10 @@ struct dm_rproc_ops {
 *
 * @dev:Remote proc device
 * @da: Device address
+* @size:   Size of the section
 * @return virtual address.
 */
-   void * (*device_to_virt)(struct udevice *dev, ulong da);
+   void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
 };
 
 /* Accessor */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 00/25] remoteproc: Add support for R5F and DSP processors

2019-08-28 Thread Lokesh Vutla
This series addds support loading and starting for the following remote
processors:
- ARM Cortex-R5F in lockstep and split mode
- C66x DSP
- C7x DSP

Enable these remoteprocessor in AM654-evm and J721E evm.

Kedar Chitnis (1):
  armv8: K3: j721e: Updated ddr address regions in MMU table

Lokesh Vutla (14):
  dm: core: Add a function to count the children of a device
  remoteproc: ops: Add elf section size as input parameter to
device_to_virt api
  remoteproc: elf_loader: Always check the validity of the image before
loading
  remoteproc: elf-loader: Add 64 bit elf loading support
  remoteproc: elf_loader: Introduce a common elf loader function
  remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api
  remoteproc: tisci_proc: Add helper api for controlling core power
domain
  remoteproc: Introduce K3 remoteproc driver for R5F subsystem
  remoteproc: Introduce K3 C66 and C71 remoteproc driver
  arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node
  arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes
  arm: dts: k3-j721e-main: Add C66x DSP nodes
  arm: dts: k3-j721e-main: Add C71x DSP node
  configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver

Suman Anna (10):
  dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
  dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3
SoCs
  arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes
  env: ti: k3_rproc: Add common rproc environment variables
  env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs
  env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs
  configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs
  configs: am65x_evm_a53: Enable R5F remoteproc driver
  configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs
  armv8: K3: am65x: Update DDR address regions in MMU table

 arch/arm/dts/k3-am65-mcu.dtsi |  40 +-
 arch/arm/dts/k3-am654-base-board.dts  |   5 +
 arch/arm/dts/k3-j721e-common-proc-board.dts   |  12 +
 arch/arm/dts/k3-j721e-main.dtsi   | 111 +++
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  38 +
 arch/arm/mach-k3/arm64-mmu.c  |  24 +-
 configs/am65x_evm_a53_defconfig   |   4 +-
 configs/j721e_evm_a72_defconfig   |   5 +-
 .../remoteproc/ti,k3-dsp-rproc.txt| 101 +++
 .../remoteproc/ti,k3-r5f-rproc.txt| 164 
 drivers/core/device.c |  11 +
 drivers/remoteproc/Kconfig|  20 +
 drivers/remoteproc/Makefile   |   2 +
 drivers/remoteproc/rproc-elf-loader.c | 164 +++-
 drivers/remoteproc/sandbox_testproc.c |   4 +-
 drivers/remoteproc/stm32_copro.c  |  13 +-
 drivers/remoteproc/ti_k3_dsp_rproc.c  | 354 
 drivers/remoteproc/ti_k3_r5f_rproc.c  | 816 ++
 drivers/remoteproc/ti_sci_proc.h  |  27 +
 include/configs/am65x_evm.h   |  11 +-
 include/configs/j721e_evm.h   |  14 +-
 include/dm/device.h   |   9 +
 include/environment/ti/k3_rproc.h |  52 ++
 include/remoteproc.h  |  59 +-
 test/dm/bus.c |  41 +-
 test/dm/remoteproc.c  |   9 +-
 26 files changed, 2037 insertions(+), 73 deletions(-)
 create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
 create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
 create mode 100644 drivers/remoteproc/ti_k3_dsp_rproc.c
 create mode 100644 drivers/remoteproc/ti_k3_r5f_rproc.c
 create mode 100644 include/environment/ti/k3_rproc.h

-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 01/25] dm: core: Add a function to count the children of a device

2019-08-28 Thread Lokesh Vutla
Add a function to count the available children of a device.
Update the corresponding dm tests.

Signed-off-by: Lokesh Vutla 
---
 drivers/core/device.c | 11 +++
 include/dm/device.h   |  9 +
 test/dm/bus.c | 41 +++--
 3 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 474c1642ee..beff52009d 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -565,6 +565,17 @@ int device_get_child(struct udevice *parent, int index, 
struct udevice **devp)
return -ENODEV;
 }
 
+int device_get_child_count(struct udevice *parent)
+{
+   struct udevice *dev;
+   int count = 0;
+
+   list_for_each_entry(dev, &parent->child_head, sibling_node)
+   count++;
+
+   return count;
+}
+
 int device_find_child_by_seq(struct udevice *parent, int seq_or_req_seq,
 bool find_req_seq, struct udevice **devp)
 {
diff --git a/include/dm/device.h b/include/dm/device.h
index 27a6d7b9fd..7e2a097de2 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -404,6 +404,15 @@ const char *dev_get_uclass_name(const struct udevice *dev);
  */
 int device_get_child(struct udevice *parent, int index, struct udevice **devp);
 
+/**
+ * device_get_child_count() - Get the available child count of a device
+ *
+ * Returns the number of children to a device.
+ *
+ * @parent:Parent device to check
+ */
+int device_get_child_count(struct udevice *parent);
+
 /**
  * device_find_child_by_seq() - Find a child device based on a sequence
  *
diff --git a/test/dm/bus.c b/test/dm/bus.c
index 93f3acd430..1ad45adb60 100644
--- a/test/dm/bus.c
+++ b/test/dm/bus.c
@@ -8,6 +8,7 @@
 #include 
 #endif
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -371,7 +372,6 @@ static int test_bus_parent_platdata(struct unit_test_state 
*uts)
 {
struct dm_test_parent_platdata *plat;
struct udevice *bus, *dev;
-   int child_count;
 
/* Check that the bus has no children */
ut_assertok(uclass_find_device(UCLASS_TEST_BUS, 0, &bus));
@@ -380,7 +380,7 @@ static int test_bus_parent_platdata(struct unit_test_state 
*uts)
 
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
 
-   for (device_find_first_child(bus, &dev), child_count = 0;
+   for (device_find_first_child(bus, &dev);
 dev;
 device_find_next_child(&dev)) {
/* Check that platform data is allocated */
@@ -399,22 +399,20 @@ static int test_bus_parent_platdata(struct 
unit_test_state *uts)
ut_asserteq_ptr(plat, dev_get_parent_platdata(dev));
ut_asserteq(1, plat->count);
ut_assertok(device_probe(dev));
-   child_count++;
}
-   ut_asserteq(3, child_count);
+   ut_asserteq(3, device_get_child_count(bus));
 
/* Removing the bus should also have no effect (it is still bound) */
device_remove(bus, DM_REMOVE_NORMAL);
-   for (device_find_first_child(bus, &dev), child_count = 0;
+   for (device_find_first_child(bus, &dev);
 dev;
 device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(1, plat->count);
-   child_count++;
}
-   ut_asserteq(3, child_count);
+   ut_asserteq(3, device_get_child_count(bus));
 
/* Unbind all the children */
do {
@@ -425,16 +423,15 @@ static int test_bus_parent_platdata(struct 
unit_test_state *uts)
 
/* Now the child platdata should be removed and re-added */
device_probe(bus);
-   for (device_find_first_child(bus, &dev), child_count = 0;
+   for (device_find_first_child(bus, &dev);
 dev;
 device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(0, plat->count);
-   child_count++;
}
-   ut_asserteq(3, child_count);
+   ut_asserteq(3, device_get_child_count(bus));
 
return 0;
 }
@@ -480,19 +477,17 @@ static int dm_test_bus_child_post_bind(struct 
unit_test_state *uts)
 {
struct dm_test_parent_platdata *plat;
struct udevice *bus, *dev;
-   int child_count;
 
ut_assertok(uclass_get_device(UCLASS_TEST_BUS, 0, &bus));
-   for (device_find_first_child(bus, &dev), child_count = 0;
+   for (device_find_first_child(bus, &dev);
 dev;
 device_find_next_child(&dev)) {
/* Check that platform data is allocated */
plat = dev_get_parent_platdata(dev);
ut_assert(plat != NULL);
ut_asserteq(1, plat->bind_flag);
-   child_count++;
  

[U-Boot] [PATCH 04/25] remoteproc: elf-loader: Add 64 bit elf loading support

2019-08-28 Thread Lokesh Vutla
The current rproc-elf-loader supports loading of only 32 bit elf files.
Introduce support for loading of 64 bit elf files in rproc-elf-loader.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-elf-loader.c | 109 ++
 include/remoteproc.h  |  12 +++
 2 files changed, 121 insertions(+)

diff --git a/drivers/remoteproc/rproc-elf-loader.c 
b/drivers/remoteproc/rproc-elf-loader.c
index 149aeafb85..dff1873a51 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -64,6 +64,61 @@ static int rproc_elf32_sanity_check(ulong addr, ulong size)
return 0;
 }
 
+static int rproc_elf64_sanity_check(ulong addr, ulong size)
+{
+   Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
+   char class;
+
+   if (!addr) {
+   pr_debug("Invalid fw address?\n");
+   return -EFAULT;
+   }
+
+   if (size < sizeof(Elf64_Ehdr)) {
+   pr_debug("Image is too small\n");
+   return -ENOSPC;
+   }
+
+   class = ehdr->e_ident[EI_CLASS];
+
+   if (!IS_ELF(*ehdr) || ehdr->e_type != ET_EXEC || class != ELFCLASS64) {
+   pr_debug("Not an executable ELF64 image\n");
+   return -EPROTONOSUPPORT;
+   }
+
+   /* We assume the firmware has the same endianness as the host */
+# ifdef __LITTLE_ENDIAN
+   if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
+# else /* BIG ENDIAN */
+   if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
+# endif
+   pr_debug("Unsupported firmware endianness\n");
+   return -EILSEQ;
+   }
+
+   if (size < ehdr->e_shoff + sizeof(Elf64_Shdr)) {
+   pr_debug("Image is too small\n");
+   return -ENOSPC;
+   }
+
+   if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+   pr_debug("Image is corrupted (bad magic)\n");
+   return -EBADF;
+   }
+
+   if (ehdr->e_phnum == 0) {
+   pr_debug("No loadable segments\n");
+   return -ENOEXEC;
+   }
+
+   if (ehdr->e_phoff > size) {
+   pr_debug("Firmware size is too small\n");
+   return -ENOSPC;
+   }
+
+   return 0;
+}
+
 int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
 {
Elf32_Ehdr *ehdr; /* Elf header structure pointer */
@@ -110,3 +165,57 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned 
long addr, ulong size)
 
return 0;
 }
+
+int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
+{
+   const struct dm_rproc_ops *ops = rproc_get_ops(dev);
+   u64 da, memsz, filesz, offset;
+   Elf64_Ehdr *ehdr;
+   Elf64_Phdr *phdr;
+   int i, ret = 0;
+   void *ptr;
+
+   dev_dbg(dev, "%s: addr = 0x%lx size = 0x%lx\n", __func__, addr, size);
+
+   if (rproc_elf64_sanity_check(addr, size))
+   return -EINVAL;
+
+   ehdr = (Elf64_Ehdr *)addr;
+   phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
+
+   /* go through the available ELF segments */
+   for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
+   da = phdr->p_paddr;
+   memsz = phdr->p_memsz;
+   filesz = phdr->p_filesz;
+   offset = phdr->p_offset;
+
+   if (phdr->p_type != PT_LOAD)
+   continue;
+
+   dev_dbg(dev, "%s:phdr: type %d da 0x%llx memsz 0x%llx filesz 
0x%llx\n",
+   __func__, phdr->p_type, da, memsz, filesz);
+
+   ptr = (void *)(uintptr_t)da;
+   if (ops->device_to_virt) {
+   ptr = ops->device_to_virt(dev, da, phdr->p_memsz);
+   if (!ptr) {
+   dev_err(dev, "bad da 0x%llx mem 0x%llx\n", da,
+   memsz);
+   ret = -EINVAL;
+   break;
+   }
+   }
+
+   if (filesz)
+   memcpy(ptr, (void *)addr + offset, filesz);
+   if (filesz != memsz)
+   memset(ptr + filesz, 0x00, memsz - filesz);
+
+   flush_cache(rounddown((ulong)ptr, ARCH_DMA_MINALIGN),
+   roundup((ulong)ptr + filesz, ARCH_DMA_MINALIGN) -
+   rounddown((ulong)ptr, ARCH_DMA_MINALIGN));
+   }
+
+   return ret;
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 6657b39723..f5d77c8c81 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -210,6 +210,15 @@ int rproc_is_running(int id);
  * @return 0 if the image is successfully loaded, else appropriate error value.
  */
 int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong 
size);
+
+/**
+ * rproc_elf64_load_image() - load an ELF64 image
+ * @dev:   device loading the ELF64 image
+ * @addr:  valid ELF64 image address
+ * @size:  size of the image
+ *

[U-Boot] [PATCH 05/25] remoteproc: elf_loader: Introduce a common elf loader function

2019-08-28 Thread Lokesh Vutla
Introduce a common remoteproc elf loader function that automatically
detects the 64 bit elf file or 32 bit elf file and loads the sections
accordingly.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-elf-loader.c | 15 +++
 include/remoteproc.h  | 14 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/remoteproc/rproc-elf-loader.c 
b/drivers/remoteproc/rproc-elf-loader.c
index dff1873a51..276164bae7 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -219,3 +219,18 @@ int rproc_elf64_load_image(struct udevice *dev, ulong 
addr, ulong size)
 
return ret;
 }
+
+int rproc_elf_load_image(struct udevice *dev, ulong addr, ulong size)
+{
+   Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+   if (!addr) {
+   dev_err(dev, "Invalid firmware address\n");
+   return -EFAULT;
+   }
+
+   if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
+   return rproc_elf64_load_image(dev, addr, size);
+   else
+   return rproc_elf32_load_image(dev, addr, size);
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index f5d77c8c81..e0493aae2c 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -219,6 +219,17 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned 
long addr, ulong size);
  * @return 0 if the image is successfully loaded, else appropriate error value.
  */
 int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
+
+/**
+ * rproc_elf_load_image() - load an ELF image
+ * @dev:   device loading the ELF image
+ * @addr:  valid ELF image address
+ * @size:  size of the image
+ *
+ * Auto detects if the image is ELF32 or ELF64 image and load accordingly.
+ * @return 0 if the image is successfully loaded, else appropriate error value.
+ */
+int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
 #else
 static inline int rproc_init(void) { return -ENOSYS; }
 static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -235,6 +246,9 @@ static inline int rproc_elf32_load_image(struct udevice 
*dev,
 static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
 ulong size)
 { return -ENOSYS; }
+static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
+  ulong size)
+{ return -ENOSYS; }
 #endif
 
 #endif /* _RPROC_H_ */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 17/25] env: ti: k3_rproc: Add common rproc environment variables

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

Add a new file include/environment/ti/k3_rproc.h that defines
common environment variables useful for booting various remote
processors from U-Boot. This file is expected to be included in
the board config files with the EXTRA_ENV_RPROC_SETTINGS added
to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten
to include the actual list of processors to be booted.

The 'boot_rprocs' variable just needs to be added to the board's
bootcmd to automatically boot the processors, and runtime control
can be achieved through the 'dorprocboot' variable.

The variables are currently defined to use MMC as the boot media,
and can be expanded in the future to include other boot media.
The immediate usage is intended for K3 J721E SoCs.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Suman Anna 
---
 include/environment/ti/k3_rproc.h | 52 +++
 1 file changed, 52 insertions(+)
 create mode 100644 include/environment/ti/k3_rproc.h

diff --git a/include/environment/ti/k3_rproc.h 
b/include/environment/ti/k3_rproc.h
new file mode 100644
index 00..3418cb42be
--- /dev/null
+++ b/include/environment/ti/k3_rproc.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * rproc environment variable definitions for various TI K3 SoCs.
+ */
+
+#ifndef __TI_RPROC_H
+#define __TI_RPROC_H
+
+/*
+ * should contain a list of  tuplies,
+ * override in board config files with the actual list
+ */
+#define DEFAULT_RPROCS ""
+
+#ifdef CONFIG_CMD_REMOTEPROC
+#define EXTRA_ENV_RPROC_SETTINGS   \
+   "dorprocboot=0\0"   \
+   "boot_rprocs="  \
+   "if test ${dorprocboot} -eq 1 && test ${boot} = mmc; then "\
+   "rproc init;"   \
+   "run boot_rprocs_mmc;"  \
+   "fi;\0" \
+   "rproc_load_and_boot_one="  \
+   "if load mmc ${bootpart} $loadaddr ${rproc_fw}; then "  \
+   "if rproc load ${rproc_id} ${loadaddr} ${filesize}; 
then "\
+   "rproc start ${rproc_id};"  \
+   "fi;"   \
+   "fi\0"  \
+   "boot_rprocs_mmc="  \
+   "env set rproc_id;" \
+   "env set rproc_fw;" \
+   "for i in ${rproc_fw_binaries} ; do "   \
+   "if test -z \"${rproc_id}\" ; then "\
+   "env set rproc_id $i;"  \
+   "else " \
+   "env set rproc_fw $i;"  \
+   "run rproc_load_and_boot_one;"  \
+   "env set rproc_id;" \
+   "env set rproc_fw;" \
+   "fi;"   \
+   "done\0"\
+   "rproc_fw_binaries="\
+   DEFAULT_RPROCS  \
+   "\0"
+#else
+#define EXTRA_ENV_RPROC_SETTINGS   \
+   "boot_rprocs= \0"
+#endif /* CONFIG_CMD_REMOTEPROC */
+
+#endif /* __TI_RPROC_H */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 03/25] remoteproc: elf_loader: Always check the validity of the image before loading

2019-08-28 Thread Lokesh Vutla
rproc_elf32_load_image() rely on user to send a valid address for elf loading.
Instead do a sanity check on the address passed by user. This will help
all rproc elf users to not call sanity_check explicitly before calling
elf_loading.

Now that rproc_elf32_sanity_check() is used only in rproc-elf-loader.c
make it static.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-elf-loader.c | 13 +
 drivers/remoteproc/stm32_copro.c  |  9 +
 include/remoteproc.h  | 20 
 test/dm/remoteproc.c  |  7 ++-
 4 files changed, 16 insertions(+), 33 deletions(-)

diff --git a/drivers/remoteproc/rproc-elf-loader.c 
b/drivers/remoteproc/rproc-elf-loader.c
index 7574ba3fb3..149aeafb85 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -8,7 +8,7 @@
 #include 
 
 /* Basic function to verify ELF32 image format */
-int rproc_elf32_sanity_check(ulong addr, ulong size)
+static int rproc_elf32_sanity_check(ulong addr, ulong size)
 {
Elf32_Ehdr *ehdr;
char class;
@@ -64,13 +64,18 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
return 0;
 }
 
-/* A very simple elf loader, assumes the image is valid */
-int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
+int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong size)
 {
Elf32_Ehdr *ehdr; /* Elf header structure pointer */
Elf32_Phdr *phdr; /* Program header structure pointer */
const struct dm_rproc_ops *ops;
-   unsigned int i;
+   unsigned int i, ret;
+
+   ret =  rproc_elf32_sanity_check(addr, size);
+   if (ret) {
+   dev_err(dev, "Invalid ELF32 Image %d\n", ret);
+   return ret;
+   }
 
ehdr = (Elf32_Ehdr *)addr;
phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index ff82313bca..1760dc5aba 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -149,14 +149,7 @@ static int stm32_copro_load(struct udevice *dev, ulong 
addr, ulong size)
return ret;
}
 
-   /* Support only ELF32 image */
-   ret = rproc_elf32_sanity_check(addr, size);
-   if (ret) {
-   dev_err(dev, "Invalid ELF32 image (%d)\n", ret);
-   return ret;
-   }
-
-   return rproc_elf32_load_image(dev, addr);
+   return rproc_elf32_load_image(dev, addr, size);
 }
 
 /**
diff --git a/include/remoteproc.h b/include/remoteproc.h
index 81f616a1f9..6657b39723 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -202,25 +202,14 @@ int rproc_ping(int id);
  */
 int rproc_is_running(int id);
 
-/**
- * rproc_elf32_sanity_check() - Verify if an image is a valid ELF32 one
- *
- * Check if a valid ELF32 image exists at the given memory location. Verify
- * basic ELF32 format requirements like magic number and sections size.
- *
- * @addr:  address of the image to verify
- * @size:  size of the image
- * @return 0 if the image looks good, else appropriate error value.
- */
-int rproc_elf32_sanity_check(ulong addr, ulong size);
-
 /**
  * rproc_elf32_load_image() - load an ELF32 image
  * @dev:   device loading the ELF32 image
  * @addr:  valid ELF32 image address
+ * @size:  size of the image
  * @return 0 if the image is successfully loaded, else appropriate error value.
  */
-int rproc_elf32_load_image(struct udevice *dev, unsigned long addr);
+int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong 
size);
 #else
 static inline int rproc_init(void) { return -ENOSYS; }
 static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -231,10 +220,9 @@ static inline int rproc_stop(int id) { return -ENOSYS; }
 static inline int rproc_reset(int id) { return -ENOSYS; }
 static inline int rproc_ping(int id) { return -ENOSYS; }
 static inline int rproc_is_running(int id) { return -ENOSYS; }
-static inline int rproc_elf32_sanity_check(ulong addr,
-  ulong size) { return -ENOSYS; }
 static inline int rproc_elf32_load_image(struct udevice *dev,
-unsigned long addr) { return -ENOSYS; }
+unsigned long addr, ulong size)
+{ return -ENOSYS; }
 #endif
 
 #endif /* _RPROC_H_ */
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
index a2c4be7c27..fb3b615fc3 100644
--- a/test/dm/remoteproc.c
+++ b/test/dm/remoteproc.c
@@ -171,18 +171,15 @@ static int dm_test_remoteproc_elf(struct unit_test_state 
*uts)
ut_assertnonnull(loaded_firmware);
memset(loaded_firmware, 0, loaded_firmware_size);
 
-   /* Verify valid ELF format */
-   ut_assertok(rproc_elf32_sanity_check((ulong)valid_elf32, size));
-
/* Load firmware in loaded_firmware, and verify it */
-   ut_assertok(rproc_elf32_load_image(dev, (un

[U-Boot] [PATCH 14/25] arm: dts: k3-j721e-main: Add C66x DSP nodes

2019-08-28 Thread Lokesh Vutla
The J721E SoCs have two TMS320C66x DSP Core Subsystems (C66x CorePacs)
in the MAIN voltage domain, each with a C66x Fixed/Floating-Point DSP
Core, and 32 KB of L1P & L1D configurable SRAMs/Cache and an additional
288 KB of L2 configurable SRAM/Cache. These subsystems do not have
an MMU but contain a Region Address Translator (RAT) sub-module for
translating 32-bit processor addresses into larger bus addresses.
The inter-processor communication between the main A72 cores and
these processors is achieved through shared memory and Mailboxes.
Add the DT nodes for these DSP processor sub-systems in the common
k3-j721e-main.dtsi file.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-j721e-common-proc-board.dts |  2 ++
 arch/arm/dts/k3-j721e-main.dtsi | 24 +
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-common-proc-board.dts
index 21afdc8ce0..a548277718 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -20,6 +20,8 @@
remoteproc3 = &main_r5fss0_core1;
remoteproc4 = &main_r5fss1_core0;
remoteproc5 = &main_r5fss1_core1;
+   remoteproc6 = &c66_0;
+   remoteproc7 = &c66_1;
};
 };
 
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index 59ca4e5686..c3aa0cdcf1 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -304,4 +304,28 @@
loczrama = <1>;
};
};
+
+   c66_0: dsp@4d8080 {
+   compatible = "ti,j721e-c66-dsp";
+   reg = <0x4d 0x8080 0x00 0x00048000>,
+ <0x4d 0x80e0 0x00 0x8000>,
+ <0x4d 0x80f0 0x00 0x8000>;
+   reg-names = "l2sram", "l1pram", "l1dram";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <142>;
+   ti,sci-proc-ids = <0x03 0xFF>;
+   resets = <&k3_reset 142 1>;
+   };
+
+   c66_1: dsp@4d8180 {
+   compatible = "ti,j721e-c66-dsp";
+   reg = <0x4d 0x8180 0x00 0x00048000>,
+ <0x4d 0x81e0 0x00 0x8000>,
+ <0x4d 0x81f0 0x00 0x8000>;
+   reg-names = "l2sram", "l1pram", "l1dram";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <143>;
+   ti,sci-proc-ids = <0x04 0xFF>;
+   resets = <&k3_reset 143 1>;
+   };
 };
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 07/25] remoteproc: tisci_proc: Add helper api for controlling core power domain

2019-08-28 Thread Lokesh Vutla
Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/ti_sci_proc.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
index ccfc39ec88..f8299d1aff 100644
--- a/drivers/remoteproc/ti_sci_proc.h
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -19,12 +19,14 @@
  * @proc_id: processor id for the consumer remoteproc device
  * @host_id: host id to pass the control over for this consumer remoteproc
  *  device
+ * @dev_id: Device ID as identified by system controller.
  */
 struct ti_sci_proc {
const struct ti_sci_handle *sci;
const struct ti_sci_proc_ops *ops;
u8 proc_id;
u8 host_id;
+   u16 dev_id;
 };
 
 static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
@@ -118,4 +120,29 @@ static inline int ti_sci_proc_set_control(struct 
ti_sci_proc *tsp,
return ret;
 }
 
+static inline int ti_sci_proc_power_domain_on(struct ti_sci_proc *tsp)
+{
+   int ret;
+
+   debug("%s: dev_id = %d\n", __func__, tsp->dev_id);
+
+   ret = tsp->sci->ops.dev_ops.get_device_exclusive(tsp->sci, tsp->dev_id);
+   if (ret)
+   pr_err("Power-domain on failed for dev = %d\n", tsp->dev_id);
+
+   return ret;
+}
+
+static inline int ti_sci_proc_power_domain_off(struct ti_sci_proc *tsp)
+{
+   int ret;
+
+   debug("%s: dev_id = %d\n", __func__, tsp->dev_id);
+
+   ret = tsp->sci->ops.dev_ops.put_device(tsp->sci, tsp->dev_id);
+   if (ret)
+   pr_err("Power-domain off failed for dev = %d\n", tsp->dev_id);
+
+   return ret;
+}
 #endif /* REMOTEPROC_TI_SCI_PROC_H */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 12/25] arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node

2019-08-28 Thread Lokesh Vutla
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-j721e-common-proc-board.dts |  5 +++
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi   | 38 +
 2 files changed, 43 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-common-proc-board.dts
index b5b8c3c5cc..070d21cd05 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -12,6 +12,11 @@
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 
earlycon=ns16550a,mmio32,0x0280";
};
+
+   aliases {
+   remoteproc0 = &mcu_r5fss0_core0;
+   remoteproc1 = &mcu_r5fss0_core1;
+   };
 };
 
 &wkup_uart0 {
diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi 
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 1175fa9a50..b958b5b3c1 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -69,4 +69,42 @@
clocks = <&k3_clks 149 0>;
clock-names = "fclk";
};
+
+   mcu_r5fss0: r5fss@4100 {
+   compatible = "ti,j721e-r5fss";
+   lockstep-mode = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x4100 0x00 0x4100 0x2>,
+<0x4140 0x00 0x4140 0x2>;
+   power-domains = <&k3_pds 249 TI_SCI_PD_EXCLUSIVE>;
+
+   mcu_r5fss0_core0: r5f@4100 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x4100 0x8000>,
+ <0x4101 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <250>;
+   ti,sci-proc-ids = <0x01 0xFF>;
+   resets = <&k3_reset 250 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+
+   mcu_r5fss0_core1: r5f@4140 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x4140 0x8000>,
+ <0x4141 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <251>;
+   ti,sci-proc-ids = <0x02 0xFF>;
+   resets = <&k3_reset 251 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+   };
 };
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 08/25] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

The Texas Instruments K3 family of SoCs have one of more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.

The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 .../remoteproc/ti,k3-r5f-rproc.txt| 164 ++
 1 file changed, 164 insertions(+)
 create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt

diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt 
b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
new file mode 100644
index 00..c2fa6e8344
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
@@ -0,0 +1,164 @@
+TI K3 R5F processor subsystems
+==
+
+The TI K3 family of SoCs usually have one or more dual-core Arm Cortex
+R5F processor subsystems/clusters (R5FSS). The dual core cluster can be
+used either in a LockStep mode providing safety/fault tolerance features
+or in a Split mode providing two individual compute cores for doubling
+the compute capacity. These are used together with other processors
+present on the SoC to achieve various system level goals.
+
+R5F Sub-System Device Node:
+===
+Each Dual-Core R5F sub-system is represented as a single DTS node representing
+the cluster, with a pair of child DT nodes representing the individual R5F
+cores. Each node has a number of required or optional properties that enable
+the OS running on the host processor to perform the device management of the
+remote processor and to communicate with the remote processor.
+
+Required properties:
+
+The following are the mandatory properties:
+
+- compatible:  Should be one of the following,
+   "ti,am654-r5fss" for R5F clusters/subsystems on
+  K3 AM65x SoCs
+   "ti,j721e-r5fss" for R5F clusters/subsystems on
+  K3 J721E SoCs
+- power-domains:   Should contain a phandle to a PM domain provider node
+   and an args specifier containing the R5FSS device id
+   value. This property is as per the binding,
+   
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- #address-cells:  Should be 1
+- #size-cells: Should be 1
+- ranges:  Standard ranges definition providing translations for
+   R5F TCM address spaces
+
+Optional properties:
+
+- lockstep-mode:   Configuration Mode for the Dual R5F cores within the R5F
+   cluster. Should be either a value of 1 (LockStep mode) 
or
+   0 (Split mode), default is LockStep mode if omitted.
+
+
+R5F Processor Child Nodes:
+==
+The R5F Sub-System device node should define two R5F child nodes, each node
+representing a TI instantiation of the Arm Cortex R5F core. There are some
+specific integration differences for the IP like the usage of a Region Address
+Translator (RAT) for translating the larger SoC bus addresses into a 32-bit
+address space for the processor.
+
+Required properties:
+
+The following are the mandatory properties:
+
+- compatible:  Should be one of the following,
+   "ti,am654-r5f" for the R5F cores in K3 AM65x SoCs
+   "ti,j721e-r5f" for the R5F cores in K3 J721E SOCs
+- reg: Should contain an entry for each value in 'reg-names'.
+   Each entry should have the memory region's start address
+   and the size of the region, the representation matching
+   the parent node's '#address-cells' and '#size-cells' 
values.
+- reg-names:   Should contain strings with the following names, each
+   representing a specific internal memory region, and
+   should be defined in this order,
+"atcm", "btcm"
+- ti,sci:  Should be a phandle to the TI-SCI System Controller node
+- ti,sci-dev-id:   Should contain the TI-SCI device id corresponding to the
+   R5F Core. Please refer to the corresponding System
+   Controller documentation for valid values for the R5F
+   cores.
+- ti,sci-proc-ids: Should contain 2 

[U-Boot] [PATCH 13/25] arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes

2019-08-28 Thread Lokesh Vutla
The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5 cores are each added as child nodes to the corresponding
main cluster node. Configure SS0 in split mode an SS1 in lockstep mode,
with the ATCMs enabled to allow the R5 cores to execute code from DDR
with boot-strapping code from ATCM.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-j721e-common-proc-board.dts |  4 ++
 arch/arm/dts/k3-j721e-main.dtsi | 76 +
 2 files changed, 80 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-common-proc-board.dts
index 070d21cd05..21afdc8ce0 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -16,6 +16,10 @@
aliases {
remoteproc0 = &mcu_r5fss0_core0;
remoteproc1 = &mcu_r5fss0_core1;
+   remoteproc2 = &main_r5fss0_core0;
+   remoteproc3 = &main_r5fss0_core1;
+   remoteproc4 = &main_r5fss1_core0;
+   remoteproc5 = &main_r5fss1_core1;
};
 };
 
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index 3445784293..59ca4e5686 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -228,4 +228,80 @@
ti,trm-icp = <0x8>;
dma-coherent;
};
+
+   main_r5fss0: r5fss@5c0 {
+   compatible = "ti,j721e-r5fss";
+   lockstep-mode = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x5c0 0x00 0x5c0 0x2>,
+<0x5d0 0x00 0x5d0 0x2>;
+   power-domains = <&k3_pds 243 TI_SCI_PD_EXCLUSIVE>;
+
+   main_r5fss0_core0: r5f@5c0 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x5c0 0x8000>,
+ <0x5c1 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <245>;
+   ti,sci-proc-ids = <0x06 0xFF>;
+   resets = <&k3_reset 245 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+
+   main_r5fss0_core1: r5f@5d0 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x5d0 0x8000>,
+ <0x5d1 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <246>;
+   ti,sci-proc-ids = <0x07 0xFF>;
+   resets = <&k3_reset 246 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+   };
+
+   main_r5fss1: r5fss@5e0 {
+   compatible = "ti,j721e-r5fss";
+   lockstep-mode = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x5e0 0x00 0x5e0 0x2>,
+<0x5f0 0x00 0x5f0 0x2>;
+   power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>;
+
+   main_r5fss1_core0: r5f@5e0 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x5e0 0x8000>,
+ <0x5e1 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <247>;
+   ti,sci-proc-ids = <0x08 0xFF>;
+   resets = <&k3_reset 247 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+
+   main_r5fss1_core1: r5f@5f0 {
+   compatible = "ti,j721e-r5f";
+   reg = <0x5f0 0x8000>,
+

[U-Boot] [PATCH 20/25] configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver

2019-08-28 Thread Lokesh Vutla
Enable R5F and DSP remoteproc drivers for j721e running on a72.

Signed-off-by: Lokesh Vutla 
---
 configs/j721e_evm_a72_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6e355f5247..6e0c3f05fb 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_CMD_ASKENV=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
@@ -72,6 +73,8 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
 CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_REMOTEPROC_TI_K3_DSP=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 16/25] arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

The AM65x SoCs has a single dual-core Arm Cortex-R5F processor
subsystem/cluster (MCU_R5FSS0) within the MCU domain. This cluster
can be configured at boot time to be either run in a LockStep mode
or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in Split-mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am65-mcu.dtsi| 40 +++-
 arch/arm/dts/k3-am654-base-board.dts |  5 
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index c9bfd9b80f..c42e7553c7 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for AM6 SoC Family MCU Domain peripherals
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
  */
 
 &cbass_mcu {
@@ -26,4 +26,42 @@
clocks = <&k3_clks 114 1>;
power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
};
+
+   mcu_r5fss0: r5fss@4100 {
+   compatible = "ti,am654-r5fss";
+   lockstep-mode = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x4100 0x00 0x4100 0x2>,
+<0x4140 0x00 0x4140 0x2>;
+   power-domains = <&k3_pds 129 TI_SCI_PD_EXCLUSIVE>;
+
+   mcu_r5fss0_core0: r5f@4100 {
+   compatible = "ti,am654-r5f";
+   reg = <0x4100 0x8000>,
+ <0x4101 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <159>;
+   ti,sci-proc-ids = <0x01 0xFF>;
+   resets = <&k3_reset 159 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+
+   mcu_r5fss0_core1: r5f@4140 {
+   compatible = "ti,am654-r5f";
+   reg = <0x4140 0x8000>,
+ <0x4141 0x8000>;
+   reg-names = "atcm", "btcm";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <245>;
+   ti,sci-proc-ids = <0x02 0xFF>;
+   resets = <&k3_reset 245 1>;
+   atcm-enable = <1>;
+   btcm-enable = <1>;
+   loczrama = <1>;
+   };
+   };
 };
diff --git a/arch/arm/dts/k3-am654-base-board.dts 
b/arch/arm/dts/k3-am654-base-board.dts
index e73b9aa6b1..573ead0b4d 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -17,6 +17,11 @@
bootargs = "earlycon=ns16550a,mmio32,0x0280";
};
 
+   aliases {
+   remoteproc0 = &mcu_r5fss0_core0;
+   remoteproc1 = &mcu_r5fss0_core1;
+   };
+
memory@8000 {
device_type = "memory";
/* 4G RAM */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 06/25] remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api

2019-08-28 Thread Lokesh Vutla
Introduce rproc_elf_get_boot_addr() that returns the entry point of
the elf file. This api auto detects the 64/32 bit elf file and returns
the boot addr accordingly.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-elf-loader.c | 24 
 include/remoteproc.h  | 12 
 test/dm/remoteproc.c  |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/remoteproc/rproc-elf-loader.c 
b/drivers/remoteproc/rproc-elf-loader.c
index 276164bae7..6a9cec94ad 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -234,3 +234,27 @@ int rproc_elf_load_image(struct udevice *dev, ulong addr, 
ulong size)
else
return rproc_elf32_load_image(dev, addr, size);
 }
+
+static ulong rproc_elf32_get_boot_addr(ulong addr)
+{
+   Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+   return ehdr->e_entry;
+}
+
+static ulong rproc_elf64_get_boot_addr(ulong addr)
+{
+   Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
+
+   return ehdr->e_entry;
+}
+
+ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr)
+{
+   Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
+
+   if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
+   return rproc_elf64_get_boot_addr(addr);
+   else
+   return rproc_elf32_get_boot_addr(addr);
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index e0493aae2c..4f67dab80c 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -230,6 +230,16 @@ int rproc_elf64_load_image(struct udevice *dev, ulong 
addr, ulong size);
  * @return 0 if the image is successfully loaded, else appropriate error value.
  */
 int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong size);
+
+/**
+ * rproc_elf_get_boot_addr() - Get rproc's boot address.
+ * @dev:   device loading the ELF image
+ * @addr:  valid ELF image address
+ *
+ * This function returns the entry point address of the ELF
+ * image.
+ */
+ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr);
 #else
 static inline int rproc_init(void) { return -ENOSYS; }
 static inline int rproc_dev_init(int id) { return -ENOSYS; }
@@ -249,6 +259,8 @@ static inline int rproc_elf64_load_image(struct udevice 
*dev, ulong addr,
 static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
   ulong size)
 { return -ENOSYS; }
+static inline ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong addr)
+{ return 0; }
 #endif
 
 #endif /* _RPROC_H_ */
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
index fb3b615fc3..f1097cd703 100644
--- a/test/dm/remoteproc.c
+++ b/test/dm/remoteproc.c
@@ -174,6 +174,8 @@ static int dm_test_remoteproc_elf(struct unit_test_state 
*uts)
/* Load firmware in loaded_firmware, and verify it */
ut_assertok(rproc_elf32_load_image(dev, (ulong)valid_elf32, size));
ut_assertok(memcmp(loaded_firmware, valid_elf32, loaded_firmware_size));
+   ut_asserteq(rproc_elf_get_boot_addr(dev, (unsigned long)valid_elf32),
+   0x0800);
unmap_physmem(loaded_firmware, MAP_NOCACHE);
 
/* Invalid ELF Magic */
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 09/25] remoteproc: Introduce K3 remoteproc driver for R5F subsystem

2019-08-28 Thread Lokesh Vutla
SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
subsytem can be configured at boot time to be either run in a LockStep
mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has each Tightly-Coupled Memory (TCM) internal memories
for each core split between two banks - TCMA and TCMB.

Add a remoteproc driver to support this subsystem to be able to load
and boot the R5 cores primarily in LockStep mode or split mode.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Suman Anna 
---
 drivers/remoteproc/Kconfig   |  10 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/ti_k3_r5f_rproc.c | 816 +++
 3 files changed, 827 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_r5f_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f54a245424..c2d59ba000 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -52,6 +52,16 @@ config REMOTEPROC_TI_K3_ARM64
  on various TI K3 family of SoCs through the remote processor
  framework.
 
+config REMOTEPROC_TI_K3_R5F
+   bool "TI K3 R5F remoteproc support"
+   select REMOTEPROC
+   depends on ARCH_K3
+   depends on TI_SCI_PROTOCOL
+   help
+ Say y here to support TI's R5F remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
 config REMOTEPROC_TI_POWER
bool "Support for TI Power processor"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 271ba55b09..9d247ba5e7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
 obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c 
b/drivers/remoteproc/ti_k3_r5f_rproc.c
new file mode 100644
index 00..ae1e4b9e04
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -0,0 +1,816 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 R5 Remoteproc driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ti_sci_proc.h"
+
+/*
+ * R5F's view of this address can either be for ATCM or BTCM with the other
+ * at address 0x0 based on loczrama signal.
+ */
+#define K3_R5_TCM_DEV_ADDR 0x4101
+
+/* R5 TI-SCI Processor Configuration Flags */
+#define PROC_BOOT_CFG_FLAG_R5_DBG_EN   0x0001
+#define PROC_BOOT_CFG_FLAG_R5_DBG_NIDEN0x0002
+#define PROC_BOOT_CFG_FLAG_R5_LOCKSTEP 0x0100
+#define PROC_BOOT_CFG_FLAG_R5_TEINIT   0x0200
+#define PROC_BOOT_CFG_FLAG_R5_NMFI_EN  0x0400
+#define PROC_BOOT_CFG_FLAG_R5_TCM_RSTBASE  0x0800
+#define PROC_BOOT_CFG_FLAG_R5_BTCM_EN  0x1000
+#define PROC_BOOT_CFG_FLAG_R5_ATCM_EN  0x2000
+#define PROC_BOOT_CFG_FLAG_GEN_IGN_BOOTVECTOR  0x1000
+
+/* R5 TI-SCI Processor Control Flags */
+#define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT   0x0001
+
+/* R5 TI-SCI Processor Status Flags */
+#define PROC_BOOT_STATUS_FLAG_R5_WFE   0x0001
+#define PROC_BOOT_STATUS_FLAG_R5_WFI   0x0002
+#define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
+#define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED0x0100
+
+#define NR_CORES   2
+
+enum cluster_mode {
+   CLUSTER_MODE_SPLIT = 0,
+   CLUSTER_MODE_LOCKSTEP,
+};
+
+/**
+ * struct k3_r5_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_r5f_mem {
+   void __iomem *cpu_addr;
+   phys_addr_t bus_addr;
+   u32 dev_addr;
+   size_t size;
+};
+
+/**
+ * struct k3_r5f_core - K3 R5 core structure
+ * @dev: cached device pointer
+ * @cluster: pointer to the parent cluster.
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @mem: Array of available internal memories
+ * @num_mem: Number of available memories
+ * @atcm_enable: flag to control ATCM enablement
+ * @btcm_enable: flag to control BTCM enablement
+ * @loczrama: flag to dictate which TCM is at device address 0x0
+ * @in_use: flag to tell if the core is already in use.
+ */
+struct k3_r5f_

[U-Boot] [PATCH 23/25] configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

The A53 U-boot can support early booting of the MCU R5F remote processor(s)
from U-boot prompt to achieve various system usecases before booting the
Linux kernel. Update the default BOOTCOMMAND to provide an automatic and
easier way to start the MCU R5F cores through added environment variables.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 configs/am65x_evm_a53_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index d6a0d8583c..2d91d25b6a 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -16,7 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_TEXT_BASE=0x8008
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 21/25] configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

The A72 U-boot can support early booting of any of the R5F or C66x
or C71x remote processors from U-boot prompt to achieve various system
usecases before booting the Linux kernel. Update the default BOOTCOMMAND
to provide an automatic and easier way to start various remote processors
through added environment variables.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Suman Anna 
---
 configs/j721e_evm_a72_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6e0c3f05fb..56df452fb6 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -17,7 +17,7 @@ CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DISTRO_DEFAULTS=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_TEXT_BASE=0x8008
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 11/25] remoteproc: Introduce K3 C66 and C71 remoteproc driver

2019-08-28 Thread Lokesh Vutla
Certain SoCs with K3 architecture have integrated a C66 Corepac DSP
subsystem and an advanced C71 DSPs. Introduce a remoteproc driver
that that does take care of loading an elf to any of the specified
DSPs and start it.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Suman Anna 
---
 drivers/remoteproc/Kconfig   |  10 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/ti_k3_dsp_rproc.c | 354 +++
 3 files changed, 365 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_dsp_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c2d59ba000..7c2e4804b5 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -52,6 +52,16 @@ config REMOTEPROC_TI_K3_ARM64
  on various TI K3 family of SoCs through the remote processor
  framework.
 
+config REMOTEPROC_TI_K3_DSP
+   bool "TI K3 C66 and C71 remoteproc support"
+   select REMOTEPROC
+   depends on ARCH_K3
+   depends on TI_SCI_PROTOCOL
+   help
+ Say y here to support TI's C66/C71 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
 config REMOTEPROC_TI_K3_R5F
bool "TI K3 R5F remoteproc support"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 9d247ba5e7..69ae7bd1e8 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
 obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_STM32_COPRO) += stm32_copro.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
+obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/ti_k3_dsp_rproc.c 
b/drivers/remoteproc/ti_k3_dsp_rproc.c
new file mode 100644
index 00..c5dc6b25da
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_dsp_rproc.c
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' K3 DSP Remoteproc driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ti_sci_proc.h"
+
+#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK  (SZ_16M - 1)
+
+/**
+ * struct k3_dsp_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from remoteproc view
+ * @size: Size of the memory region
+ */
+struct k3_dsp_mem {
+   void __iomem *cpu_addr;
+   phys_addr_t bus_addr;
+   phys_addr_t dev_addr;
+   size_t size;
+};
+
+/**
+ * struct k3_dsp_privdata - Structure representing Remote processor data.
+ * @rproc_rst: rproc reset control data
+ * @tsp:   Pointer to TISCI proc contrl handle
+ * @mem:   Array of available memories
+ * @num_mem:   Number of available memories
+ */
+struct k3_dsp_privdata {
+   struct reset_ctl dsp_rst;
+   struct ti_sci_proc tsp;
+   struct k3_dsp_mem *mem;
+   int num_mems;
+};
+
+/**
+ * k3_dsp_load() - Load up the Remote processor image
+ * @dev:   rproc device pointer
+ * @addr:  Address at which image is available
+ * @size:  size of the image
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int k3_dsp_load(struct udevice *dev, ulong addr, ulong size)
+{
+   struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+   u32 boot_vector;
+   int ret;
+
+   dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
+   ret = ti_sci_proc_request(&dsp->tsp);
+   if (ret)
+   return ret;
+
+   ret = rproc_elf_load_image(dev, addr, size);
+   if (ret < 0) {
+   dev_err(dev, "Loading elf failed %d\n", ret);
+   goto proc_release;
+   }
+
+   boot_vector = rproc_elf_get_boot_addr(dev, addr);
+
+   dev_dbg(dev, "%s: Boot vector = 0x%x\n", __func__, boot_vector);
+
+   ret = ti_sci_proc_set_config(&dsp->tsp, boot_vector, 0, 0);
+proc_release:
+   ti_sci_proc_release(&dsp->tsp);
+   return ret;
+}
+
+/**
+ * k3_dsp_start() - Start the remote processor
+ * @dev:   rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int k3_dsp_start(struct udevice *dev)
+{
+   struct k3_dsp_privdata *dsp = dev_get_priv(dev);
+   int ret;
+
+   dev_dbg(dev, "%s\n", __func__);
+
+   ret = ti_sci_proc_request(&dsp->tsp);
+   if (ret)
+   return ret;
+   /*
+* Setting the right clock frequency would have taken care by
+* assigned-clock-rates during the device probe. So no need to

[U-Boot] [PATCH 10/25] dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3 SoCs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 .../remoteproc/ti,k3-dsp-rproc.txt| 101 ++
 1 file changed, 101 insertions(+)
 create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt

diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt 
b/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
new file mode 100644
index 00..80ab7a4090
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
@@ -0,0 +1,101 @@
+TI K3 DSP devices
+=
+
+The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems that
+are used to offload some of the processor-intensive tasks or algorithms, for
+achieving various system level goals.
+
+These processor sub-systems usually contain additional sub-modules like L1
+and/or L2 caches/SRAMs, an Interrupt Controller, an external memory controller,
+a dedicated local power/sleep controller etc. The DSP processor cores in the
+K3 SoCs is usually either a TMS320C66x CorePac processor or a TMS320C71x 
CorePac
+processor.
+
+DSP Device Node:
+
+Each DSP Core sub-system is represented as a single DT node. Each node has a
+number of required or optional properties that enable the OS running on the
+host processor (Arm CorePac) to perform the device management of the remote
+processor and to communicate with the remote processor.
+
+Required properties:
+
+The following are the mandatory properties:
+
+- compatible:  Should be one of the following,
+   "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+   "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
+
+- reg: Should contain an entry for each value in 'reg-names'.
+   Each entry should have the memory region's start address
+   and the size of the region, the representation matching
+   the parent node's '#address-cells' and '#size-cells' 
values.
+
+- reg-names:   Should contain strings with the following names, each
+   representing a specific internal memory region (if
+   present), and should be defined in this order,
+"l2sram", "l1pram", "l1dram"
+   NOTE: C71x DSPs do not have a "l1pram" memory.
+
+- ti,sci:  Should be a phandle to the TI-SCI System Controller node
+
+- ti,sci-dev-id:   Should contain the TI-SCI device id corresponding to the
+   DSP Core. Please refer to the corresponding System
+   Controller documentation for valid values for the DSP
+   cores.
+
+- ti,sci-proc-ids: Should contain 2 integer values. The first cell should
+   contain the TI-SCI processor id for the DSP core device
+   and the second cell should contain the TI-SCI host id to
+   which the processor control ownership should be
+   transferred to.
+
+- resets:  Should contain the phandle to the reset controller node
+   managing the resets for this device, and a reset
+   specifier. Please refer to the following reset bindings
+   for the reset argument specifier,
+   Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+
+Example:
+-
+
+1. J721E SoC
+   /* J721E remoteproc alias */
+   aliases {
+   rproc6 = &c66_0;
+   rproc8 = &c71_0;
+   };
+
+   cbass_main: interconnect@10 {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0x00 0x6480 0x00 0x6480 0x00 0x0080>, /* 
C71_0 */
+<0x4d 0x8080 0x4d 0x8080 0x00 0x0080>, /* 
C66_0 */
+<0x4d 0x8180 0x4d 0x8180 0x00 0x0080>; /* 
C66_1 */
+
+   /* J721E C66_0 DSP node */
+   c66_0: dsp@4d8080 {
+   compatible = "ti,j721e-c66-dsp";
+   reg = <0x4d 0x8080 0x00 0x00048000>,
+ <0x4d 0x80e0 0x00 0x8000>,
+ <0x4d 0x80f0 0x00 0x8000>;
+   reg-names = "l2sram", "l1pram", "l1dram";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <142>;
+

[U-Boot] [PATCH 15/25] arm: dts: k3-j721e-main: Add C71x DSP node

2019-08-28 Thread Lokesh Vutla
The J721E SoCs have a single TMS320C71x DSP Subsystem in the MAIN
voltage domain containing the next-generation C711 CPU core. The
subsystem has 32 KB of L1D configurable SRAM/Cache and 512 KB of
L2 configurable SRAM/Cache. This subsystem has a CMMU but is not
used currently. The inter-processor communication between the main
A72 cores and the C711 processor is achieved through shared memory
and a Mailbox. Add the DT node for this DSP processor sub-system
in the common k3-j721e-main.dtsi file.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-j721e-common-proc-board.dts |  1 +
 arch/arm/dts/k3-j721e-main.dtsi | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-common-proc-board.dts
index a548277718..b21f597a80 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -22,6 +22,7 @@
remoteproc5 = &main_r5fss1_core1;
remoteproc6 = &c66_0;
remoteproc7 = &c66_1;
+   remoteproc8 = &c71_0;
};
 };
 
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index c3aa0cdcf1..6bd59bac52 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -328,4 +328,15 @@
ti,sci-proc-ids = <0x04 0xFF>;
resets = <&k3_reset 143 1>;
};
+
+   c71_0: dsp@6480 {
+   compatible = "ti,j721e-c71-dsp";
+   reg = <0x00 0x6480 0x00 0x0008>,
+ <0x00 0x64e0 0x00 0xc000>;
+   reg-names = "l2sram", "l1dram";
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <15>;
+   ti,sci-proc-ids = <0x30 0xFF>;
+   resets = <&k3_reset 15 1>;
+   };
 };
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 22/25] configs: am65x_evm_a53: Enable R5F remoteproc driver

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

Enable the R5F remoteproc driver for the AM65x GP EVM so that the
MCU domain R5F cores can be booted from A53 U-boot.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 configs/am65x_evm_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 9d02dbc01a..d6a0d8583c 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
+CONFIG_CMD_REMOTEPROC=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
 # CONFIG_ISO_PARTITION is not set
@@ -83,6 +84,7 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
 CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_SERIAL=y
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 25/25] armv8: K3: j721e: Updated ddr address regions in MMU table

2019-08-28 Thread Lokesh Vutla
From: Kedar Chitnis 

The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
Main R5FSS Cores. In order to view the code loaded by the U-Boot by
remote cores, U-Boot should configure the memory region with right
memory attributes. Right now U-Boot carves out a memory region which
is not sufficient for all the images to be loaded. So, increase this
carve out region by 256MB.

Signed-off-by: Kedar Chitnis 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/arm64-mmu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 98c5a777e5..7f908eee80 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -80,13 +80,13 @@ struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x0bc0UL,
+   .size = 0x1bc0UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
 PTE_BLOCK_NON_SHARE
}, {
-   .virt = 0xabc0UL,
-   .phys = 0xabc0UL,
-   .size = 0x5440UL,
+   .virt = 0xbbc0UL,
+   .phys = 0xbbc0UL,
+   .size = 0x4440UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 19/25] env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

Add support to boot the MCU domain R5F Core0 remoteproc at U-boot prompt
on the AM65x EVM boards by using the 'boot_rprocs' and other env variables
defined in the common environment file k3_rproc.h, and updating the
'DEFAULT_RPROCS' macro.

The default configuration is to use the MCU R5F in Split mode, so both
the R5F Core0 and Core1 are started before loading and booting the Linux
kernel using the following firmware:
   MCU R5FSS0 Core0 (Split) : 0 /lib/firmware/am65x-mcu-r5f0_0-fw
   MCU R5FSS0 Core1 (Split) : 1 /lib/firmware/am65x-mcu-r5f0_1-fw

The MCU R5FSS was initially running the R5 SPL in LockStep mode with ATCM
disabled, and is actually shutdown to enable it to be reconfigured and
booted by either A53 U-Boot or Linux kernel in remoteproc mode and using
ATCM.

The MCU R5FSS would need to be reconfigured for Lockstep mode through
DT if a fault-tolerant/safety application were to be run on the cluster
with the DEFAULT_RPROCS macro updated to remove the Core1 firmware.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 include/configs/am65x_evm.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 6072e4a48c..5c44b22ead 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CONFIG_ENV_SIZE(128 << 10)
 
@@ -96,11 +97,19 @@
"${bootdir}/${name_kern}\0" \
"partitions=" PARTS_DEFAULT
 
+#ifdef DEFAULT_RPROCS
+#undef DEFAULT_RPROCS
+#endif
+#define DEFAULT_RPROCS ""  \
+   "0 /lib/firmware/am65x-mcu-r5f0_0-fw "  \
+   "1 /lib/firmware/am65x-mcu-r5f0_1-fw "
+
 /* Incorporate settings into the U-Boot environment */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
DEFAULT_MMC_TI_ARGS \
EXTRA_ENV_AM65X_BOARD_SETTINGS  \
-   EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC
+   EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC  \
+   EXTRA_ENV_RPROC_SETTINGS
 
 /* MMC ENV related defines */
 #ifdef CONFIG_ENV_IS_IN_MMC
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 18/25] env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
boards by using the 'boot_rprocs' and other env variables defined in the
common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
macro.

The list of R5F cores to be started before loading and booting the Linux
kernel are as follows, and in this order:
   Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw
   Main R5FSS1 (LockStep): 4 /lib/firmware/j7-main-r5f1_0-fw

The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the
equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main
R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included
in the list either.

The DSP cores are started in the following order before loading and
booting the Linux kernel:
   C66_0: 6 /lib/firmware/j7-c66_0-fw
   C66_1: 7 /lib/firmware/j7-c66_1-fw
   C71_0: 8 /lib/firmware/j7-c71_0-fw

The order of the rprocs to boot can be changed at runtime if desired by
overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 include/configs/j721e_evm.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 5fe77ef16d..dbe226b46d 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CONFIG_ENV_SIZE(128 << 10)
 
@@ -87,11 +88,22 @@
"get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
"${bootdir}/${name_kern}\0"
 
+#ifdef DEFAULT_RPROCS
+#undef DEFAULT_RPROCS
+#endif
+#define DEFAULT_RPROCS ""  \
+   "3 /lib/firmware/j7-main-r5f0_1-fw "\
+   "4 /lib/firmware/j7-main-r5f1_0-fw "\
+   "6 /lib/firmware/j7-c66_0-fw "  \
+   "7 /lib/firmware/j7-c66_1-fw "  \
+   "8 /lib/firmware/j7-c71_0-fw "
+
 /* Incorporate settings into the U-Boot environment */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
DEFAULT_MMC_TI_ARGS \
EXTRA_ENV_J721E_BOARD_SETTINGS  \
-   EXTRA_ENV_J721E_BOARD_SETTINGS_MMC
+   EXTRA_ENV_J721E_BOARD_SETTINGS_MMC  \
+   EXTRA_ENV_RPROC_SETTINGS
 
 /* Now for the remaining common defines */
 #include 
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 24/25] armv8: K3: am65x: Update DDR address regions in MMU table

2019-08-28 Thread Lokesh Vutla
From: Suman Anna 

The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
single core in LockStep mode or 2 cores in Split mode) to achieve various
early system functionalities. Change the memory attributes for the DDR
regions used by the remote processors so that the cores can see and
execute the proper code loaded by U-Boot.

These regions are currently limited to 0xa000 to 0xa210 as per
the DDR carveouts assigned for these R5F cores in the overall DDR memory
map.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/arm64-mmu.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 82778d2197..98c5a777e5 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -14,7 +14,7 @@
 
 #ifdef CONFIG_SOC_K3_AM6
 /* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
 
 /* ToDo: Add 64bit IO */
 struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
@@ -28,7 +28,19 @@ struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
-   .size = 0x8000UL,
+   .size = 0x2000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xa000UL,
+   .phys = 0xa000UL,
+   .size = 0x0210UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xa210UL,
+   .phys = 0xa210UL,
+   .size = 0x5df0UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.22.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-28 Thread Simon Goldschmidt
Marek Vasut  schrieb am Mi., 28. Aug. 2019, 14:44:

> On 8/28/19 10:13 AM, Ley Foon Tan wrote:
> [...]
>
> >> If want to use address from DT, we need get address every time need
> to
> >> use the address.
> >> For non-DM, it is easier to use constant address. Let me know if you
> >> still prefer to use address from DT.
> 
>  Surely you can cache the address or even better, convert to DM/DT ?
> >>> Will try to cache the address for now.  But, we need get address from
> >>> DT twice, one in SPL, one in Uboot. They not sharing global data.
> >>
> >> I don't think there's much we can do about that, unless we can somehow
> >> share parsed live DT from SPL to U-Boot, but that's for another
> >> discussion/patchset/etc.
> > I am working on this now and found there are 2 challenges if we get
> > base address from DT.
> > 1. We can only get the address from DT after gd->fdt_blob is
> > initialized in spl_early_init(). So, spl_early_init() need move to
> > beginning of board_init_f().
>
> This should be reasonably easy to solve I guess ?
>

I did that for gen5 already in my pending patchset. It was kind of easy,
although problems like coding bugs or lack of heap are hard to debug as the
debug Hart doesn't work that early (no ponmux setup etc.)


> >Tested this on Agilex, look okay. But, pending test on other device
> > families, like Gen5 or A10. Not sure any side effect with this change.
> > 2. Secure (for PSCI) and non-secure functions share same functions,
> > these functions can't use global data (for base address). Secure
> > functions have its own secure data region.
>
> There was a discussion about this before, instead of hacking up this
> part constantly, maybe we should create a separate build of U-Boot (like
> SPL/TPL) and use that for the "secure" mode. But that's for another
> patchset and another discussion.
>
> > #2 is more difficult to overcome. Do you have strong opinion to get
> > base address from DT? Otherwise, can we use constant define for these
> > base addresses?
>
> See above, the secure part might need further work.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Wandboard boot failure when HAB support is enabled

2019-08-28 Thread Fabio Estevam
Hi Jon,

[Adding Breno on Cc, who is familiar with HAB support].

On Tue, Aug 27, 2019 at 3:03 PM Jon Szymaniak
 wrote:
>
> Hello all,
>
> I'd like to get U-Boot >= 2019.07 booting on a Wandboard Quad with HAB
> support enabled, but appear to be running into either some regressions
> (or matters of PEBKAC).  For the scope of this discussion, I'm only
> concerned with booting an "insecure" HAB-enabled U-Boot image (ideally
> FIT), on a device that has not yet been fused (i.e., with the U-Boot
> commands need to fuse and verify successful image authentication prior
> to enforcing ROM-based authentication of the SPL).
>
> As of commit df516569, I am able to use the default Wandboard
> configuration, enable HAB support (CONFIG_SECURE_BOOT=y) via
> menufconfig, build and then successfully boot the resulting SPL +
> u-boot-ivt.img combination on a Wandboard Quad (B1).
>
> However, as of commit 5b85858 (and onwards), I am no longer able to
> boot the second stage U-Boot image when HAB support is enabled (the
> SPL still works, however).  Disabling HAB support (the default
> configuration state) still works, of course.
>
> Issue #1: u-boot-ivt.img load address changed from 0x1780 to 0x
>
> It appears that the generation of u-boot-ivt.img "breaks" in df516569
> because the associated MKIMAGEFLAGS_u-boot-ivt.img definition, present
> in an else clause of the top-level Makefile, is no longer used, now
> that the default configuration enables SPL FIT support. As a result,
> the generated image contains a load address of 0x0, which results in a
> boot loop.
>
> I've tried to work around this with the following change, which leads
> me to Issue #2.  I'm unclear on whether a multi-DTB IVT image should
> be instead be produced to address this, or whether "legacy" boot
> images should continue to work.
>
> diff --git a/Makefile b/Makefile
> index f3857ab6a9..07fa36b4c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1243,12 +1243,13 @@ else
>  MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
>  -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>  -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> +endif
> +
>  MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \
>  -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>  -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
>  u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
>  CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log
> -endif
>
>  MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
>
>
> Issue #2: u-boot-ivt.img stuck in lib/hang.c's hang()
>
> Once executing u-boot-ivt.img from 0x1780, I'm seeing the
> following call path occurring:
>
> board_init_f() -> initcall_run_list @ fdtdec_setup() errors out -->
> hang() -> bootstage_error(BOOTSTAGE_ID_NEED_RESET)
>
> I'm still trying to determine specifically where in fdtdec_setup() the
> failure is, but before I dig too much deeper, I was hoping to get some
> feedback on whether this is simply a matter of needing to produce a
> modified image that isn't currently being built.
>
> Again, I'm not entirely clear what the expectation is here -- should I
> simply not be attempting to boot the u-boot-ivt.img? Should this still
> work despite not being a FIT image?  Do we need to generate a
> FIT-based IVT image for this configuration?
>
>
> Thank you in advance for your time and help!
>
> Best regards,
> Jon Szymaniak
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2 1/6] nand: brcm: add BCM6368 support

2019-08-28 Thread Daniel Schwierzeck


Am 28.08.19 um 13:44 schrieb Álvaro Fernández Rojas:
> This adds support for BCM6368, BCM6328, BCM6362 and BCM63268 SoCs.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  v2: no changes
> 
>  drivers/mtd/nand/raw/Kconfig |   6 +
>  drivers/mtd/nand/raw/brcmnand/Makefile   |   1 +
>  drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c | 122 +++
>  3 files changed, 129 insertions(+)
>  create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c

Reviewed-by: Daniel Schwierzeck 

nits below

> 
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index a129f44869..2000826c79 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -72,6 +72,12 @@ config NAND_BRCMNAND
> Enable the driver for NAND flash on platforms using a Broadcom NAND
> controller.
>  
> +config NAND_BRCMNAND_6368
> + bool "Support Broadcom NAND controller on bcm6368"
> + depends on NAND_BRCMNAND && ARCH_BMIPS
> + help
> +   Enable support for broadcom nand driver on bcm6368.
> +
>  config NAND_BRCMNAND_6838
> bool "Support Broadcom NAND controller on bcm6838"
> depends on NAND_BRCMNAND && ARCH_BMIPS && SOC_BMIPS_BCM6838
> diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile 
> b/drivers/mtd/nand/raw/brcmnand/Makefile
> index a2363cc80e..7e70b859dc 100644
> --- a/drivers/mtd/nand/raw/brcmnand/Makefile
> +++ b/drivers/mtd/nand/raw/brcmnand/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  
> +obj-$(CONFIG_NAND_BRCMNAND_6368) += bcm6368_nand.o
>  obj-$(CONFIG_NAND_BRCMNAND_63158) += bcm63158_nand.o
>  obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
>  obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
> diff --git a/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c 
> b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c
> new file mode 100644
> index 00..1768d3945f
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/brcmnand/bcm6368_nand.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "brcmnand.h"
> +
> +struct bcm6368_nand_soc {
> + struct brcmnand_soc soc;
> + void __iomem *base;
> +};
> +
> +#define BCM6368_NAND_INT 0x00
> +#define  BCM6368_NAND_STATUS_SHIFT   0
> +#define  BCM6368_NAND_STATUS_MASK(0xfff << BCM6368_NAND_STATUS_SHIFT)
> +#define  BCM6368_NAND_ENABLE_SHIFT   16
> +#define  BCM6368_NAND_ENABLE_MASK(0x << BCM6368_NAND_ENABLE_SHIFT)
> +
> +enum {
> + BCM6368_NP_READ = BIT(0),
> + BCM6368_BLOCK_ERASE = BIT(1),
> + BCM6368_COPY_BACK   = BIT(2),
> + BCM6368_PAGE_PGM= BIT(3),
> + BCM6368_CTRL_READY  = BIT(4),
> + BCM6368_DEV_RBPIN   = BIT(5),
> + BCM6368_ECC_ERR_UNC = BIT(6),
> + BCM6368_ECC_ERR_CORR= BIT(7),
> +};
> +
> +static bool bcm6368_nand_intc_ack(struct brcmnand_soc *soc)
> +{
> + struct bcm6368_nand_soc *priv =
> + container_of(soc, struct bcm6368_nand_soc, soc);

because you have this multiple times, maybe it makes sense to add something 
like:

#define soc_to_priv(_soc) container_of(_soc, struct bcm6368_nand_soc, soc)

> + void __iomem *mmio = priv->base + BCM6368_NAND_INT;
> + u32 val = brcmnand_readl(mmio);
> +
> + if (val & (BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT)) {
> + /* Ack interrupt */
> + val &= ~BCM6368_NAND_STATUS_MASK;
> + val |= BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT;
> + brcmnand_writel(val, mmio);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void bcm6368_nand_intc_set(struct brcmnand_soc *soc, bool en)
> +{
> + struct bcm6368_nand_soc *priv =
> + container_of(soc, struct bcm6368_nand_soc, soc);
> + void __iomem *mmio = priv->base + BCM6368_NAND_INT;
> + u32 val = brcmnand_readl(mmio);
> +
> + /* Don't ack any interrupts */
> + val &= ~BCM6368_NAND_STATUS_MASK;
> +
> + if (en)
> + val |= BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT;
> + else
> + val &= ~(BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT);
> +
> + brcmnand_writel(val, mmio);
> +}
> +
> +static int bcm6368_nand_probe(struct udevice *dev)
> +{
> + struct udevice *pdev = dev;
> + struct bcm6368_nand_soc *priv = dev_get_priv(dev);
> + struct brcmnand_soc *soc;
> + struct resource res;
> +
> + soc = &priv->soc;
> +
> + dev_read_resource_byname(pdev, "nand-int-base", &res);
> + priv->base = ioremap(res.start, resource_size(&res));

we recently got support for dev_remap_addr_name(). Maybe this is useful here.

> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + soc->ctlrdy_ack = bcm6368_nand_intc_ack;
> + soc->ctlrdy_set_enabled = bcm6368_nand_intc_set;
> +
> + /* Disable and ac

Re: [U-Boot] [PATCH v4 3/8] dm: cache: add v5l2 cache controller driver

2019-08-28 Thread Bin Meng
On Wed, Aug 28, 2019 at 6:52 PM Andes  wrote:
>
> From: Rick Chen 
>
> Add a v5l2 cache controller driver that is usually found on
> Andes RISC-V ae350 platform. It will parse the cache settings
> from the dtb.
>
> In this version tag and data ram control timing can be adjusted
> by the requirement from the dtb.
>
> Signed-off-by: Rick Chen 
> Cc: KC Lin 
> ---
>  drivers/cache/Kconfig  |   9 +++
>  drivers/cache/Makefile |   1 +
>  drivers/cache/cache-v5l2.c | 186 
> +
>  3 files changed, 196 insertions(+)
>  create mode 100644 drivers/cache/cache-v5l2.c
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628

2019-08-28 Thread Stefan Roese

On 28.08.19 08:37, Weijie Gao wrote:

This patch updates reset controller node for mt7628

Signed-off-by: Weijie Gao 
---
  arch/mips/dts/mt7628a.dtsi | 36 
  1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index f07de1b611..0e2b6598ea 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -1,4 +1,5 @@
  // SPDX-License-Identifier: GPL-2.0
+#include 
  
  / {

#address-cells = <1>;
@@ -16,11 +17,6 @@
};
};
  
-	resetc: reset-controller {

-   compatible = "ralink,rt2880-reset";
-   #reset-cells = <1>;
-   };
-
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
@@ -48,6 +44,12 @@
mask = <0x1>;
};
  
+		rstctrl: rstctrl@0x34 {

+   reg = <0x34 0x4>;
+   compatible = "mediatek,mtmips-reset";
+   #reset-cells = <1>;
+   };
+
pinctrl: pinctrl@60 {
compatible = "mediatek,mt7628-pinctrl";
reg = <0x3c 0x2c>, <0x1300 0x100>;
@@ -202,7 +204,7 @@
compatible = "ralink,mt7628a-wdt", 
"mediatek,mt7621-wdt";
reg = <0x100 0x30>;
  
-			resets = <&resetc 8>;

+   resets = <&rstctrl MT7628_TIMER_RST>;


I like this patch. But we should always keep in mind to stay in sync (or sync
in the future) with the Linux DT sources. And in Linux currently, its the "old"
syntax that you are removing with this patch.

Do you plan to update the Linux DT as well, so that the bindings match again?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190828

2019-08-28 Thread Neil Armstrong
Hi Tom,

This PR simply adds a missing compatible enabling the G12B clock controller.

The CI jobs passed at 
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/568

Thanks,
Neil

The following changes since commit e4b8dd9b34021241cd05d5cc9d24b4ae34657830:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx (2019-08-27 
07:11:37 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
tags/u-boot-amlogic-20190828

for you to fetch changes up to d0e8c4ad513c0df492cc90bdc59f272687e90b32:

  clk: meson-g12b: add compatible (2019-08-28 10:14:31 +0200)


- add missing g12b clock driver compatible, fixing odroid-n2 usb support


Mark Kettenis (1):
  clk: meson-g12b: add compatible

 drivers/clk/meson/g12a.c | 1 +
 1 file changed, 1 insertion(+)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 12/26] clk: add clock gating driver for MediaTek MIPS platform

2019-08-28 Thread Daniel Schwierzeck


Am 28.08.19 um 08:37 schrieb Weijie Gao:
> This patch adds clock gating driver for MediaTek MIPS platform
> 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/clk/Kconfig  |  8 
>  drivers/clk/Makefile |  1 +
>  drivers/clk/clk-mtmips-cg.c  | 63 
>  include/dt-bindings/clk/mt7628-clk.h | 31 ++
>  4 files changed, 103 insertions(+)
>  create mode 100644 drivers/clk/clk-mtmips-cg.c
>  create mode 100644 include/dt-bindings/clk/mt7628-clk.h
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 95fe0aea2c..0762a42476 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -160,4 +160,12 @@ config SANDBOX_CLK_CCF
> Enable this option if you want to test the Linux kernel's Common
> Clock Framework [CCF] code in U-Boot's Sandbox clock driver.
>  
> +config CLK_MTMIPS_GATE
> + bool "Enable clock gating driver for MediaTek MIPS platform"
> + depends on CLK && ARCH_MTMIPS
> + default y
> + help
> +   Enable clock gating driver for MediaTek MIPS platform.
> +   This driver supports only clock enable and disable.
> +
>  endmenu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 68aabe1ca9..353974d784 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
>  obj-$(CONFIG_CLK_EXYNOS) += exynos/
>  obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
>  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
> +obj-$(CONFIG_CLK_MTMIPS_GATE) += clk-mtmips-cg.o
>  obj-$(CONFIG_CLK_OWL) += owl/
>  obj-$(CONFIG_CLK_RENESAS) += renesas/
>  obj-$(CONFIG_CLK_SIFIVE) += sifive/
> diff --git a/drivers/clk/clk-mtmips-cg.c b/drivers/clk/clk-mtmips-cg.c
> new file mode 100644
> index 00..0221d95aed
> --- /dev/null
> +++ b/drivers/clk/clk-mtmips-cg.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc. All Rights Reserved.
> + *
> + * Author: Weijie Gao 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct mtmips_clk_gate_priv {
> + void __iomem *base;
> +};
> +
> +static int mtmips_clk_gate_enable(struct clk *clk)
> +{
> + struct mtmips_clk_gate_priv *priv = dev_get_priv(clk->dev);
> +
> + setbits_32(priv->base, BIT(clk->id));
> +
> + return 0;
> +}
> +
> +static int mtmips_clk_gate_disable(struct clk *clk)
> +{
> + struct mtmips_clk_gate_priv *priv = dev_get_priv(clk->dev);
> +
> + clrbits_32(priv->base, BIT(clk->id));
> +
> + return 0;
> +}
> +
> +const struct clk_ops mtmips_clk_gate_ops = {
> + .enable = mtmips_clk_gate_enable,
> + .disable = mtmips_clk_gate_disable,
> +};

the generic clk-gate.c driver already supports this simple register bit
toggling. Why don't you use that one?

> +
> +static int mtmips_clk_gate_probe(struct udevice *dev)
> +{
> + struct mtmips_clk_gate_priv *priv = dev_get_priv(dev);
> +
> + priv->base = (void __iomem *)dev_remap_addr_index(dev, 0);
> + if (!priv->base)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static const struct udevice_id mtmips_clk_gate_ids[] = {
> + { .compatible = "mediatek,mtmips-clk-gate" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(mtmips_clk_gate) = {
> + .name = "mtmips-clk-gate",
> + .id = UCLASS_CLK,
> + .of_match = mtmips_clk_gate_ids,
> + .probe = mtmips_clk_gate_probe,
> + .priv_auto_alloc_size = sizeof(struct mtmips_clk_gate_priv),
> + .ops = &mtmips_clk_gate_ops,
> +};
> diff --git a/include/dt-bindings/clk/mt7628-clk.h 
> b/include/dt-bindings/clk/mt7628-clk.h
> new file mode 100644
> index 00..6784d6e50b
> --- /dev/null
> +++ b/include/dt-bindings/clk/mt7628-clk.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + *
> + * Author:  Weijie Gao 
> + */
> +
> +#ifndef _DT_BINDINGS_MT7628_CLK_H_
> +#define _DT_BINDINGS_MT7628_CLK_H_
> +
> +#define MT7628_PWM_CLK   31
> +#define MT7628_SDXC_CLK  30
> +#define MT7628_CRYPTO_CLK29
> +#define MT7628_MIPS_CNT_CLK  28
> +#define MT7628_PCIE_CLK  26
> +#define MT7628_UPHY_CLK  25
> +#define MT7628_ETH_CLK   23
> +#define MT7628_UART2_CLK 20
> +#define MT7628_UART1_CLK 19
> +#define MT7628_SPI_CLK   18
> +#define MT7628_I2S_CLK   17
> +#define MT7628_I2C_CLK   16
> +#define MT7628_GDMA_CLK  14
> +#define MT7628_PIO_CLK   13
> +#define MT7628_UART0_CLK 12
> +#define MT7628_PCM_CLK   11
> +#define MT7628_MC_CLK10
> +#define MT7628_INT_CLK   9
> +#define MT7628_TIMER_CLK 8
> +
> +#endif /* _DT_BINDINGS_MT7628_CLK_H_ */
> 

-- 
- Daniel
_

Re: [U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-28 Thread Ley Foon Tan
On Wed, Aug 28, 2019 at 8:44 PM Marek Vasut  wrote:
>
> On 8/28/19 10:13 AM, Ley Foon Tan wrote:
> [...]
>
> >> If want to use address from DT, we need get address every time need to
> >> use the address.
> >> For non-DM, it is easier to use constant address. Let me know if you
> >> still prefer to use address from DT.
> 
>  Surely you can cache the address or even better, convert to DM/DT ?
> >>> Will try to cache the address for now.  But, we need get address from
> >>> DT twice, one in SPL, one in Uboot. They not sharing global data.
> >>
> >> I don't think there's much we can do about that, unless we can somehow
> >> share parsed live DT from SPL to U-Boot, but that's for another
> >> discussion/patchset/etc.
> > I am working on this now and found there are 2 challenges if we get
> > base address from DT.
> > 1. We can only get the address from DT after gd->fdt_blob is
> > initialized in spl_early_init(). So, spl_early_init() need move to
> > beginning of board_init_f().
>
> This should be reasonably easy to solve I guess ?
Yes, this shouldn't be tough, just need testing. Make sure it doesn't
break anything.
>
> >Tested this on Agilex, look okay. But, pending test on other device
> > families, like Gen5 or A10. Not sure any side effect with this change.
> > 2. Secure (for PSCI) and non-secure functions share same functions,
> > these functions can't use global data (for base address). Secure
> > functions have its own secure data region.
>
> There was a discussion about this before, instead of hacking up this
> part constantly, maybe we should create a separate build of U-Boot (like
> SPL/TPL) and use that for the "secure" mode. But that's for another
> patchset and another discussion.
Yes, we have discussion here internally regarding this secure firmware.
We plan change the boot flow to include ATF. But, our downstream git
still need to maintain this "secure" region for some period (so
customer can migrate to new boot flow).
If change to DT address, we need patch our downstream git for these
secure functions. :)
Anyway, I will try change for upstream. I'm trying to find where is
the proper place to get DT address in Uboot. SPL is more straight
forward, get the DT address in board_init_f.

Thanks.

Regards
Ley Foon

>
> > #2 is more difficult to overcome. Do you have strong opinion to get
> > base address from DT? Otherwise, can we use constant define for these
> > base addresses?
>
> See above, the secure part might need further work.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 15/26] net: mt7628-eth: remove hardcoded gpio settings and regmap-based phy reset

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

This patch removes hardcoded gpio settings as they have been replaced by
pinctrl in dts, and also replaces regmap-based phy reset with a more
generic reset controller.

Signed-off-by: Weijie Gao 
---
  drivers/net/mt7628-eth.c | 45 +++-
  1 file changed, 8 insertions(+), 37 deletions(-)


Very nice diffstat with this patch. :)

Reviewed-by: Stefan Roese 

Thanks,
Stefan
 

diff --git a/drivers/net/mt7628-eth.c b/drivers/net/mt7628-eth.c
index 7833b2f47a..4675b0f003 100644
--- a/drivers/net/mt7628-eth.c
+++ b/drivers/net/mt7628-eth.c
@@ -18,23 +18,12 @@
  #include 
  #include 
  #include 
-#include 
-#include 
+#include 
  #include 
  #include 
  #include 
  #include 
  
-/* System controller register */

-#define MT7628_RSTCTRL_REG 0x34
-#define RSTCTRL_EPHY_RST   BIT(24)
-
-#define MT7628_AGPIO_CFG_REG   0x3c
-#define MT7628_EPHY_GPIO_AIO_ENGENMASK(20, 17)
-#define MT7628_EPHY_P0_DIS BIT(16)
-
-#define MT7628_GPIO2_MODE_REG  0x64
-
  /* Ethernet frame engine register */
  #define PDMA_RELATED  0x0800
  
@@ -137,7 +126,6 @@ struct fe_tx_dma {

  struct mt7628_eth_dev {
void __iomem *base; /* frame engine base address */
void __iomem *eth_sw_base;  /* switch base address */
-   struct regmap *sysctrl_regmap;  /* system-controller reg-map */
  
  	struct mii_dev *bus;
  
@@ -150,6 +138,8 @@ struct mt7628_eth_dev {

int rx_dma_idx;
/* Point to the next TXD in TXD Ring0 CPU wants to use */
int tx_dma_idx;
+
+   struct reset_ctlrst_ephy;
  };
  
  static int mdio_wait_read(struct mt7628_eth_dev *priv, u32 mask, bool mask_set)

@@ -301,20 +291,9 @@ static void rt305x_esw_init(struct mt7628_eth_dev *priv)
/* 1us cycle number=125 (FE's clock=125Mhz) */
writel(0x7d00, base + MT7628_SWITCH_BMU_CTRL);
  
-	/* Configure analog GPIO setup */

-   regmap_update_bits(priv->sysctrl_regmap, MT7628_AGPIO_CFG_REG,
-  MT7628_EPHY_P0_DIS, MT7628_EPHY_GPIO_AIO_EN);
-
/* Reset PHY */
-   regmap_update_bits(priv->sysctrl_regmap, MT7628_RSTCTRL_REG,
-  0, RSTCTRL_EPHY_RST);
-   regmap_update_bits(priv->sysctrl_regmap, MT7628_RSTCTRL_REG,
-  RSTCTRL_EPHY_RST, 0);
-   mdelay(10);
-
-   /* Set P0 EPHY LED mode */
-   regmap_update_bits(priv->sysctrl_regmap, MT7628_GPIO2_MODE_REG,
-  0x0ffc0ffc, 0x05540554);
+   reset_assert(&priv->rst_ephy);
+   reset_deassert(&priv->rst_ephy);
mdelay(10);
  
  	mt7628_ephy_init(priv);

@@ -558,7 +537,6 @@ static void mt7628_eth_stop(struct udevice *dev)
  static int mt7628_eth_probe(struct udevice *dev)
  {
struct mt7628_eth_dev *priv = dev_get_priv(dev);
-   struct udevice *syscon;
struct mii_dev *bus;
int ret;
int i;
@@ -573,20 +551,13 @@ static int mt7628_eth_probe(struct udevice *dev)
if (IS_ERR(priv->eth_sw_base))
return PTR_ERR(priv->eth_sw_base);
  
-	/* Get system controller regmap */

-   ret = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
-  "syscon", &syscon);
+   /* Reset controller */
+   ret = reset_get_by_name(dev, "ephy", &priv->rst_ephy);
if (ret) {
-   pr_err("unable to find syscon device\n");
+   pr_err("unable to find reset controller for ethernet PHYs\n");
return ret;
}
  
-	priv->sysctrl_regmap = syscon_get_regmap(syscon);

-   if (!priv->sysctrl_regmap) {
-   pr_err("unable to find regmap\n");
-   return -ENODEV;
-   }
-
/* Put rx and tx rings into KSEG1 area (uncached) */
priv->tx_ring = (struct fe_tx_dma *)
KSEG1ADDR(memalign(ARCH_DMA_MINALIGN,



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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/4] configs: AST2500 EVB: Enable SD controller

2019-08-28 Thread Peng Fan
Hi Eddie,

> Subject: [PATCH v3 3/4] configs: AST2500 EVB: Enable SD controller
> 
> Enable the MMC subsystem and the Aspeed SD controller. Also enable the use
> of the device tree for probing the controller.

Would you add a MAINTAINERS file for this board?

Thanks,
Peng.

> 
> Signed-off-by: Eddie James 
> ---
>  configs/evb-ast2500_defconfig | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
> index 59d41cb..b47ca5b 100644
> --- a/configs/evb-ast2500_defconfig
> +++ b/configs/evb-ast2500_defconfig
> @@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_DHCP=y
>  CONFIG_CMD_MII=y
> +CONFIG_CMD_MMC=y
>  CONFIG_CMD_PING=y
>  CONFIG_DEFAULT_DEVICE_TREE="ast2500-evb"
>  CONFIG_NET_RANDOM_ETHADDR=y
> @@ -36,3 +37,10 @@ CONFIG_SYS_NS16550=y
>  CONFIG_SYSRESET=y
>  CONFIG_TIMER=y
>  CONFIG_WDT=y
> +CONFIG_MMC=y
> +CONFIG_DM_MMC=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ASPEED=y
> +CONFIG_MMC_VERBOSE=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_OF_EMBED=y
> --
> 1.8.3.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 26/26] configs: mtmips: add necessary drivers for mtmips boards

2019-08-28 Thread Daniel Schwierzeck


Am 28.08.19 um 08:38 schrieb Weijie Gao:
> This patch adds pinctrl driver, clock gate driver and reset controller
> support for defconfig files of mtmips boards.
> 
> Signed-off-by: Weijie Gao 
> ---
>  configs/gardena-smart-gateway-mt7688_defconfig | 6 ++
>  configs/linkit-smart-7688_defconfig| 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/configs/gardena-smart-gateway-mt7688_defconfig 
> b/configs/gardena-smart-gateway-mt7688_defconfig
> index 1e270cb61d..83e793042a 100644
> --- a/configs/gardena-smart-gateway-mt7688_defconfig
> +++ b/configs/gardena-smart-gateway-mt7688_defconfig
> @@ -49,6 +49,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_HAVE_BLOCK_DEVICE=y
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_CLK=y
> +CONFIG_CLK_MTMIPS_GATE=y
>  CONFIG_LED=y
>  CONFIG_LED_BLINK=y
>  CONFIG_LED_GPIO=y
> @@ -67,10 +68,15 @@ CONFIG_PHYLIB=y
>  CONFIG_PHY_FIXED=y
>  CONFIG_MT7628_ETH=y
>  CONFIG_PHY=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINMUX=y
> +CONFIG_PINCONF=y
> +CONFIG_PINCTRL_MT7628=y
>  CONFIG_POWER_DOMAIN=y
>  CONFIG_RAM=y
>  CONFIG_DM_RESET=y
>  # CONFIG_SPL_SERIAL_PRESENT is not set
> +CONFIG_RESET_MTMIPS=y

if the SoC only works with those drivers enabled, you should consider to
select all according Kconfig symbols in arch/mips/mach-mtmips/Kconfig so
an user can't configure a non-working board config by mistake.

>  CONFIG_MTK_SERIAL=y
>  CONFIG_SPI=y
>  CONFIG_MT7621_SPI=y
> diff --git a/configs/linkit-smart-7688_defconfig 
> b/configs/linkit-smart-7688_defconfig
> index 743cc48166..13f5cf8a21 100644
> --- a/configs/linkit-smart-7688_defconfig
> +++ b/configs/linkit-smart-7688_defconfig
> @@ -40,6 +40,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
>  # CONFIG_DM_DEVICE_REMOVE is not set
>  CONFIG_BLK=y
>  CONFIG_CLK=y
> +CONFIG_CLK_MTMIPS_GATE=y
>  CONFIG_LED=y
>  CONFIG_LED_BLINK=y
>  CONFIG_LED_GPIO=y
> @@ -55,10 +56,15 @@ CONFIG_PHY_FIXED=y
>  CONFIG_MT7628_ETH=y
>  CONFIG_PHY=y
>  CONFIG_MT76X8_USB_PHY=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINMUX=y
> +CONFIG_PINCONF=y
> +CONFIG_PINCTRL_MT7628=y
>  CONFIG_POWER_DOMAIN=y
>  CONFIG_RAM=y
>  CONFIG_DM_RESET=y
>  # CONFIG_SPL_SERIAL_PRESENT is not set
> +CONFIG_RESET_MTMIPS=y
>  CONFIG_MTK_SERIAL=y
>  CONFIG_SPI=y
>  CONFIG_MT7621_SPI=y
> 

-- 
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 16/26] net: mt7628-eth: remove phy link up detection

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

The mt7628 has an embedded ethernet switch (5 phy ports + 1 cpu port).
Although in IOT mode only port0 is usable, the phy0 is still connected
to the switch, not the ethernet gmac directly.

This patch removes these codes as we should not check only the status of
phy0 because phy0 may not be linked up in router mode which has all 5 phy
ports working.


I understand. But for those embedded targets that use the mainline code
right now, this setup is exactly the one that's used. With this patch applied
this "feature" of link detection of the only ethernet port is removed.

Can't we somehow change this code, that it supports both operations modes?
So targets without switch functionality and targets with multiple ports
(with switch functionality) can be supported? Perhaps via some DT property
or at least a Kconfig option?

BTW: Do you plan to add support for a target with switch functionality? That
would be just great.

Thanks,
Stefan


Signed-off-by: Weijie Gao 
---
  drivers/net/mt7628-eth.c | 32 
  1 file changed, 32 deletions(-)

diff --git a/drivers/net/mt7628-eth.c b/drivers/net/mt7628-eth.c
index 4675b0f003..eef25da8a8 100644
--- a/drivers/net/mt7628-eth.c
+++ b/drivers/net/mt7628-eth.c
@@ -120,9 +120,6 @@ struct fe_tx_dma {
  #define CONFIG_DMA_STOP_TIMEOUT   100
  #define CONFIG_TX_DMA_TIMEOUT 100
  
-#define LINK_DELAY_TIME		500		/* 500 ms */

-#define LINK_TIMEOUT   1   /* 10 seconds */
-
  struct mt7628_eth_dev {
void __iomem *base; /* frame engine base address */
void __iomem *eth_sw_base;  /* switch base address */
@@ -437,14 +434,6 @@ static int mt7628_eth_free_pkt(struct udevice *dev, uchar 
*packet, int length)
return 0;
  }
  
-static int phy_link_up(struct mt7628_eth_dev *priv)

-{
-   u32 val;
-
-   mii_mgr_read(priv, 0x00, MII_BMSR, &val);
-   return !!(val & BMSR_LSTATUS);
-}
-
  static int mt7628_eth_start(struct udevice *dev)
  {
struct mt7628_eth_dev *priv = dev_get_priv(dev);
@@ -493,27 +482,6 @@ static int mt7628_eth_start(struct udevice *dev)
wmb();
eth_dma_start(priv);
  
-	/* Check if link is not up yet */

-   if (!phy_link_up(priv)) {
-   /* Wait for link to come up */
-
-   printf("Waiting for link to come up .");
-   for (i = 0; i < (LINK_TIMEOUT / LINK_DELAY_TIME); i++) {
-   mdelay(LINK_DELAY_TIME);
-   if (phy_link_up(priv)) {
-   mdelay(100);/* Ensure all is ready */
-   break;
-   }
-
-   printf(".");
-   }
-
-   if (phy_link_up(priv))
-   printf(" done\n");
-   else
-   printf(" timeout! Trying anyways\n");
-   }
-
/*
 * The integrated switch seems to queue some received ethernet
 * packets in some FIFO. Lets read the already queued packets



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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-28 Thread Marek Vasut
On 8/28/19 3:28 PM, Ley Foon Tan wrote:

[...]

>>>Tested this on Agilex, look okay. But, pending test on other device
>>> families, like Gen5 or A10. Not sure any side effect with this change.
>>> 2. Secure (for PSCI) and non-secure functions share same functions,
>>> these functions can't use global data (for base address). Secure
>>> functions have its own secure data region.
>>
>> There was a discussion about this before, instead of hacking up this
>> part constantly, maybe we should create a separate build of U-Boot (like
>> SPL/TPL) and use that for the "secure" mode. But that's for another
>> patchset and another discussion.
> Yes, we have discussion here internally regarding this secure firmware.
> We plan change the boot flow to include ATF. But, our downstream git
> still need to maintain this "secure" region for some period (so
> customer can migrate to new boot flow).
> If change to DT address, we need patch our downstream git for these
> secure functions. :)
> Anyway, I will try change for upstream. I'm trying to find where is
> the proper place to get DT address in Uboot. SPL is more straight
> forward, get the DT address in board_init_f.

I have to admit, I have many things to say about ATF and none of them
are positive. So it's real sad this is starting to move onto S10 too.

Anyway, one of the fdt_ functions should allow you to fish out the
address from DT.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 26/26] configs: mtmips: add necessary drivers for mtmips boards

2019-08-28 Thread Stefan Roese

On 28.08.19 15:35, Daniel Schwierzeck wrote:



Am 28.08.19 um 08:38 schrieb Weijie Gao:

This patch adds pinctrl driver, clock gate driver and reset controller
support for defconfig files of mtmips boards.

Signed-off-by: Weijie Gao 
---
  configs/gardena-smart-gateway-mt7688_defconfig | 6 ++
  configs/linkit-smart-7688_defconfig| 6 ++
  2 files changed, 12 insertions(+)

diff --git a/configs/gardena-smart-gateway-mt7688_defconfig 
b/configs/gardena-smart-gateway-mt7688_defconfig
index 1e270cb61d..83e793042a 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -49,6 +49,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
  CONFIG_HAVE_BLOCK_DEVICE=y
  CONFIG_BOOTCOUNT_LIMIT=y
  CONFIG_CLK=y
+CONFIG_CLK_MTMIPS_GATE=y
  CONFIG_LED=y
  CONFIG_LED_BLINK=y
  CONFIG_LED_GPIO=y
@@ -67,10 +68,15 @@ CONFIG_PHYLIB=y
  CONFIG_PHY_FIXED=y
  CONFIG_MT7628_ETH=y
  CONFIG_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINMUX=y
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_MT7628=y
  CONFIG_POWER_DOMAIN=y
  CONFIG_RAM=y
  CONFIG_DM_RESET=y
  # CONFIG_SPL_SERIAL_PRESENT is not set
+CONFIG_RESET_MTMIPS=y


if the SoC only works with those drivers enabled, you should consider to
select all according Kconfig symbols in arch/mips/mach-mtmips/Kconfig so
an user can't configure a non-working board config by mistake.


I agree. Please move those selections to Kconfig (select XXX).

And please re-think about using the generic drivers for pinctrl and clock
(as also remarked by Daniel).

Thanks,
Stefan




  CONFIG_MTK_SERIAL=y
  CONFIG_SPI=y
  CONFIG_MT7621_SPI=y
diff --git a/configs/linkit-smart-7688_defconfig 
b/configs/linkit-smart-7688_defconfig
index 743cc48166..13f5cf8a21 100644
--- a/configs/linkit-smart-7688_defconfig
+++ b/configs/linkit-smart-7688_defconfig
@@ -40,6 +40,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
  # CONFIG_DM_DEVICE_REMOVE is not set
  CONFIG_BLK=y
  CONFIG_CLK=y
+CONFIG_CLK_MTMIPS_GATE=y
  CONFIG_LED=y
  CONFIG_LED_BLINK=y
  CONFIG_LED_GPIO=y
@@ -55,10 +56,15 @@ CONFIG_PHY_FIXED=y
  CONFIG_MT7628_ETH=y
  CONFIG_PHY=y
  CONFIG_MT76X8_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINMUX=y
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_MT7628=y
  CONFIG_POWER_DOMAIN=y
  CONFIG_RAM=y
  CONFIG_DM_RESET=y
  # CONFIG_SPL_SERIAL_PRESENT is not set
+CONFIG_RESET_MTMIPS=y
  CONFIG_MTK_SERIAL=y
  CONFIG_SPI=y
  CONFIG_MT7621_SPI=y





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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 17/26] net: mt7628-eth: free rx descriptor on receiving failure

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

When received a packet with an invalid length recorded in rx descriptor,
we should free this rx descriptor to allow us to continue to receive
following packets.
Without doing so, u-boot will stuck in a dead loop trying to process this
invalid rx descriptor.

This patch adds a call to mt7628_eth_free_pkt() after received an invalid
packet length.

Signed-off-by: Weijie Gao 


Good catch.

Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] python3 support for pylibfdt

2019-08-28 Thread Simon Glass
Hi Peter,

On Wed, 28 Aug 2019 at 05:46, Peter Robinson  wrote:
>
> Hi Simon,
>
> > > > > > > With the EOL of python2 soon I've been looking at the Fedora 
> > > > > > > U-Boot
> > > > > > > builds to see what it would take to move over to python3. There's 
> > > > > > > a
> > > > > > > couple of issues building the bundled pylibfdt, the first is the
> > > > > > > Makefile hard codes python2, the second is that the generated
> > > > > > > libfdt_wrap.c doesn't seem to find the python3 version of Python.h
> > > > > > > (errors below).
> > > > > > >
> > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 
> > > > > > > but I
> > > > > > > couldn't quite work out how this fits into the U-Boot bundled 
> > > > > > > version.
> > > > > > > Is there plans to be able to support pylibfdt with python3?
> > > > > >
> > > > > > Sounds like we need to run the normal kernel script to re-sync with
> > > > > > upstream?  Thanks!
> > > > >
> > > > > Seems reasonable, I'll keep an eye out for a patch series to test,
> > > > > it's quite straight forward to test from my PoV.
> > > >
> > > > It won't be any time soon, sadly.  Updating to the same dtc in the
> > > > kernel (so just v1.4.7+) causes both massive amount of new device tree
> > > > warnings as well as several fail to link due to size growth problems.
> > >
> > > For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3
> > > merge window.
> >
> > Also I sent a series for libfdt to reduce the size, as a first step to
> > syncing up U-Boot again. It needs work, but I expect to get back to it
> > next week.
>
> What's the latest on this?

No new progress but I just emailed David again about my pending question.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 18/26] net: mt7628-eth: add support to isolate LAN/WAN ports

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

This patch add support for mt7628-eth to isolate LAN/WAN ports mainly to


Nitpicking:

s/add/adds


prevent LAN devices from getting IP address from WAN.

Signed-off-by: Weijie Gao 
---
  drivers/net/mt7628-eth.c | 32 
  1 file changed, 32 insertions(+)

diff --git a/drivers/net/mt7628-eth.c b/drivers/net/mt7628-eth.c
index 8ca2c66edb..1215b24eaf 100644
--- a/drivers/net/mt7628-eth.c
+++ b/drivers/net/mt7628-eth.c
@@ -57,6 +57,11 @@
  /* Ethernet switch register */
  #define MT7628_SWITCH_FCT00x0008
  #define MT7628_SWITCH_PFC10x0014
+#define MT7628_SWITCH_PVIDC0   0x0040
+#define MT7628_SWITCH_PVIDC1   0x0044
+#define MT7628_SWITCH_PVIDC2   0x0048
+#define MT7628_SWITCH_PVIDC3   0x004c
+#define MT7628_SWITCH_VMSC00x0070
  #define MT7628_SWITCH_FPA 0x0084
  #define MT7628_SWITCH_SOCPC   0x008c
  #define MT7628_SWITCH_POC00x0090
@@ -137,6 +142,8 @@ struct mt7628_eth_dev {
int tx_dma_idx;
  
  	struct reset_ctl	rst_ephy;

+
+   int wan_port;
  };
  
  static int mt7628_eth_free_pkt(struct udevice *dev, uchar *packet, int length);

@@ -269,6 +276,9 @@ static void mt7628_ephy_init(struct mt7628_eth_dev *priv)
  static void rt305x_esw_init(struct mt7628_eth_dev *priv)
  {
void __iomem *base = priv->eth_sw_base;
+   void __iomem *reg;
+   u32 val = 0, pvid;
+   int i;
  
  	/*

 * FC_RLS_TH=200, FC_SET_TH=160
@@ -290,6 +300,25 @@ static void rt305x_esw_init(struct mt7628_eth_dev *priv)
/* 1us cycle number=125 (FE's clock=125Mhz) */
writel(0x7d00, base + MT7628_SWITCH_BMU_CTRL);
  
+	/* LAN/WAN partition, WAN port will be unusable in u-boot network */

+   if (priv->wan_port >= 0 && priv->wan_port < 6) {
+   for (i = 0; i < 8; i++) {
+   pvid = i == priv->wan_port ? 2 : 1;
+   reg = base + MT7628_SWITCH_PVIDC0 + (i / 2) * 4;
+   if (i % 2 == 0) {
+   val = pvid;
+   } else {
+   val |= (pvid << 12);
+   writel(val, reg);
+   }
+   }
+
+   val = 0x407f;
+   val |= 1 << (8 + priv->wan_port);
+   val &= ~(1 << priv->wan_port);
+   writel(val, base + MT7628_SWITCH_VMSC0);
+   }
+
/* Reset PHY */
reset_assert(&priv->rst_ephy);
reset_deassert(&priv->rst_ephy);
@@ -529,6 +558,9 @@ static int mt7628_eth_probe(struct udevice *dev)
return ret;
}
  
+	/* WAN port will be isolated from LAN ports */

+   priv->wan_port = dev_read_u32_default(dev, "mediatek,wan-port", -1);


Where is this DT property documented? I can't find it in Linux either. We should
find some other way to reference the ports. Perhaps something like done in
Linux DSA?

What is your reasoning for this change? Which board / target are you supporting
with this new code?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] python3 support for pylibfdt

2019-08-28 Thread Tom Rini
On Wed, Aug 28, 2019 at 07:44:11AM -0600, Simon Glass wrote:
> Hi Peter,
> 
> On Wed, 28 Aug 2019 at 05:46, Peter Robinson  wrote:
> >
> > Hi Simon,
> >
> > > > > > > > With the EOL of python2 soon I've been looking at the Fedora 
> > > > > > > > U-Boot
> > > > > > > > builds to see what it would take to move over to python3. 
> > > > > > > > There's a
> > > > > > > > couple of issues building the bundled pylibfdt, the first is the
> > > > > > > > Makefile hard codes python2, the second is that the generated
> > > > > > > > libfdt_wrap.c doesn't seem to find the python3 version of 
> > > > > > > > Python.h
> > > > > > > > (errors below).
> > > > > > > >
> > > > > > > > It seems upstream now supports building pylibfdt with dtc 1.5.0 
> > > > > > > > but I
> > > > > > > > couldn't quite work out how this fits into the U-Boot bundled 
> > > > > > > > version.
> > > > > > > > Is there plans to be able to support pylibfdt with python3?
> > > > > > >
> > > > > > > Sounds like we need to run the normal kernel script to re-sync 
> > > > > > > with
> > > > > > > upstream?  Thanks!
> > > > > >
> > > > > > Seems reasonable, I'll keep an eye out for a patch series to test,
> > > > > > it's quite straight forward to test from my PoV.
> > > > >
> > > > > It won't be any time soon, sadly.  Updating to the same dtc in the
> > > > > kernel (so just v1.4.7+) causes both massive amount of new device tree
> > > > > warnings as well as several fail to link due to size growth problems.
> > > >
> > > > For reference the kernel moved to v1.5.0-30-g702c1b6c0e73 in the 5.3
> > > > merge window.
> > >
> > > Also I sent a series for libfdt to reduce the size, as a first step to
> > > syncing up U-Boot again. It needs work, but I expect to get back to it
> > > next week.
> >
> > What's the latest on this?
> 
> No new progress but I just emailed David again about my pending question.

Should we perhaps sync including your proposed changes for now and
re-sync once it's in?  There's more than just Fedora folks unhappy about
us being one of the last requires python2 things they support.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 19/26] dts: mtmips: enable eth port0 led function for all boards

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

This patch adds default p0led status for all boards.

Signed-off-by: Weijie Gao 


Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 20/26] mmc: mtk-sd: add support for MediaTek MT7620/MT7628 SoCs

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

This patch adds mmc support for MediaTek MT7620/MT7628 SoCs.

Signed-off-by: Weijie Gao 
---
  drivers/mmc/Kconfig  |  2 +-
  drivers/mmc/mtk-sd.c | 23 ---
  2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 0ccb1ea701..564310b293 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -671,7 +671,7 @@ config FTSDC010_SDIO
  
  config MMC_MTK

bool "MediaTek SD/MMC Card Interface support"
-   depends on ARCH_MEDIATEK
+   depends on (ARCH_MEDIATEK || ARCH_MTMIPS)


AFAIK, the braces are not necessary.

Thanks,
Stefan


depends on BLK && DM_MMC
depends on OF_CONTROL
help
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index f555357af2..7069fe8948 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -217,6 +217,7 @@ struct mtk_sd_regs {
  
  struct msdc_compatible {

u8 clk_div_bits;
+   u8 sclk_cycle_shift;
bool pad_tune0;
bool async_fifo;
bool data_tune;
@@ -664,7 +665,7 @@ static int msdc_ops_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
  
  static void msdc_set_timeout(struct msdc_host *host, u32 ns, u32 clks)

  {
-   u32 timeout, clk_ns;
+   u32 timeout, clk_ns, shift;
u32 mode = 0;
  
  	host->timeout_ns = ns;

@@ -673,10 +674,11 @@ static void msdc_set_timeout(struct msdc_host *host, u32 
ns, u32 clks)
if (host->sclk == 0) {
timeout = 0;
} else {
+   shift = host->dev_comp->sclk_cycle_shift;
clk_ns = 10UL / host->sclk;
timeout = (ns + clk_ns - 1) / clk_ns + clks;
/* unit is 1048576 sclk cycles */
-   timeout = (timeout + (0x1 << 20) - 1) >> 20;
+   timeout = (timeout + (0x1 << shift) - 1) >> shift;
if (host->dev_comp->clk_div_bits == 8)
mode = (readl(&host->base->msdc_cfg) &
MSDC_CFG_CKMOD_M) >> MSDC_CFG_CKMOD_S;
@@ -1301,7 +1303,7 @@ static int msdc_drv_probe(struct udevice *dev)
  
  	host->mmc = &plat->mmc;

host->timeout_ns = 1;
-   host->timeout_clks = 3 * 1048576;
+   host->timeout_clks = 3 * (1 << host->dev_comp->sclk_cycle_shift);
  
  #ifdef CONFIG_PINCTRL

pinctrl_select_state(dev, "default");
@@ -1374,8 +1376,20 @@ static const struct dm_mmc_ops msdc_ops = {
  #endif
  };
  
+static const struct msdc_compatible mt7620_compat = {

+   .clk_div_bits = 8,
+   .sclk_cycle_shift = 16,
+   .pad_tune0 = false,
+   .async_fifo = false,
+   .data_tune = false,
+   .busy_check = false,
+   .stop_clk_fix = false,
+   .enhance_rx = false
+};
+
  static const struct msdc_compatible mt7623_compat = {
.clk_div_bits = 12,
+   .sclk_cycle_shift = 20,
.pad_tune0 = true,
.async_fifo = true,
.data_tune = true,
@@ -1386,6 +1400,7 @@ static const struct msdc_compatible mt7623_compat = {
  
  static const struct msdc_compatible mt8516_compat = {

.clk_div_bits = 12,
+   .sclk_cycle_shift = 20,
.pad_tune0 = true,
.async_fifo = true,
.data_tune = true,
@@ -1395,6 +1410,7 @@ static const struct msdc_compatible mt8516_compat = {
  
  static const struct msdc_compatible mt8183_compat = {

.clk_div_bits = 12,
+   .sclk_cycle_shift = 20,
.pad_tune0 = true,
.async_fifo = true,
.data_tune = true,
@@ -1403,6 +1419,7 @@ static const struct msdc_compatible mt8183_compat = {
  };
  
  static const struct udevice_id msdc_ids[] = {

+   { .compatible = "mediatek,mt7620-mmc", .data = (ulong)&mt7620_compat },
{ .compatible = "mediatek,mt7623-mmc", .data = (ulong)&mt7623_compat },
{ .compatible = "mediatek,mt8516-mmc", .data = (ulong)&mt8516_compat },
{ .compatible = "mediatek,mt8183-mmc", .data = (ulong)&mt8183_compat },



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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 23/26] dts: mtmips: add default pinctrl for gardena-smart-gateway-mt7688

2019-08-28 Thread Stefan Roese

On 28.08.19 08:38, Weijie Gao wrote:

This adds default pinctrl (dual SPI chip select) for gardena smart gateway

Signed-off-by: Weijie Gao 


Please see my comment about the pinctrl-single driver usage in Linux. And
my patch to add support to the mt7628.dtsi file as well. We should stay
in sync with the Linux DT bindings here.

Other than that:

Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >