[U-Boot] [PATCH] arm64: zynqmp: Show model information instead of custom IDENT_STRING

[Michal Simek]

DISPLAY_BOARDINFO in OF case show model identification string from DT.
Enable this feature instead of custom IDENT_STRING which does the same
thing.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_zc1232_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zc1254_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zc1275_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zc1275_revB_defconfig  | 2 --
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 2 --
 configs/xilinx_zynqmp_zcu100_revC_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 2 --
 configs/xilinx_zynqmp_zcu102_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu104_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu104_revC_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu106_revA_defconfig  | 2 --
 configs/xilinx_zynqmp_zcu111_revA_defconfig  | 2 --
 17 files changed, 34 deletions(-)

diff --git a/configs/xilinx_zynqmp_zc1232_revA_defconfig 
b/configs/xilinx_zynqmp_zc1232_revA_defconfig
index f4e680d1be11..70dc870fa99e 100644
--- a/configs/xilinx_zynqmp_zc1232_revA_defconfig
+++ b/configs/xilinx_zynqmp_zc1232_revA_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 # CONFIG_SPL_LIBDISK_SUPPORT is not set
 CONFIG_SPL=y
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1232 revA"
 # CONFIG_SPL_FAT_SUPPORT is not set
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1232-revA"
 CONFIG_DEBUG_UART=y
@@ -13,7 +12,6 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/xilinx_zynqmp_zc1254_revA_defconfig 
b/configs/xilinx_zynqmp_zc1254_revA_defconfig
index 77b4ada4e271..09de18d8ffc5 100644
--- a/configs/xilinx_zynqmp_zc1254_revA_defconfig
+++ b/configs/xilinx_zynqmp_zc1254_revA_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 # CONFIG_SPL_LIBDISK_SUPPORT is not set
 CONFIG_SPL=y
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1254 revA"
 # CONFIG_SPL_FAT_SUPPORT is not set
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1254-revA"
 CONFIG_DEBUG_UART=y
@@ -13,7 +12,6 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/xilinx_zynqmp_zc1275_revA_defconfig 
b/configs/xilinx_zynqmp_zc1275_revA_defconfig
index 17c1be879dd4..a7e79f5d0e90 100644
--- a/configs/xilinx_zynqmp_zc1275_revA_defconfig
+++ b/configs/xilinx_zynqmp_zc1275_revA_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 # CONFIG_SPL_LIBDISK_SUPPORT is not set
 CONFIG_SPL=y
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1275 revA"
 # CONFIG_SPL_FAT_SUPPORT is not set
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1275-revA"
 CONFIG_DEBUG_UART=y
@@ -13,7 +12,6 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/xilinx_zynqmp_zc1275_revB_defconfig 
b/configs/xilinx_zynqmp_zc1275_revB_defconfig
index b073282e6508..823b50392c64 100644
--- a/configs/xilinx_zynqmp_zc1275_revB_defconfig
+++ b/configs/xilinx_zynqmp_zc1275_revB_defconfig
@@ -5,7 +5,6 @@ CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 # CONFIG_SPL_LIBDISK_SUPPORT is not set
 CONFIG_SPL=y
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1275 revB"
 # CONFIG_SPL_FAT_SUPPORT is not set
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1275-revB"
 CONFIG_DEBUG_UART=y
@@ -14,7 +13,6 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 8493c9a760c4..9e2c0127474b 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -4,7 +4,6 @@ CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_SPL=y
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1751 xm015 dc1"
 CONFIG_PMUFW_INIT_FILE="board/xilinx/zynqmp/zynqmp-zc1751-xm015-dc1/pmufw.bin"
 CONFIG_ZYNQMP_USB=y
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1751-xm015-dc1"
@@ -15,7 +14,6 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
 

[U-Boot] Pull request: u-boot-spi/master

[Jagan Teki]

Hi Tom, 

Please pull this PR.

thanks,
Jagan.

The following changes since commit 40df6b3e1882c55dd34b9177a42e21a591d668ee:

  Merge git://git.denx.de/u-boot-socfpga (2018-04-17 17:45:28 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-spi.git master

for you to fetch changes up to 9b14ac5cc2294ac3eaae92421abff27ed3e6caae:

  spi: dw: invert wait condition in dw_spi_xfer (2018-04-23 11:16:41 +0530)


Eugeniy Paltsev (3):
  mtd: sf: Add support of sst26wf* flash ICs protection ops
  mtd: sf: add support for sst26wf016, sst26wf032, sst26wf064
  spi: dw: invert wait condition in dw_spi_xfer

Sean Nyekjaer (1):
  sf: Add Spansion s25fl208k entry

 drivers/mtd/spi/sf_internal.h   |  13 
 drivers/mtd/spi/spi_flash.c | 168 
 drivers/mtd/spi/spi_flash_ids.c |   4 +
 drivers/spi/designware_spi.c|   2 +-
 4 files changed, 186 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/5] net: sun8i-emac: support R40 GMAC

[Jagan Teki]

On Mon, Apr 23, 2018 at 8:27 PM, Lothar Felten  wrote:
> Add support for the GMAC found in the Allwinner R40/V40 SoC.
>
> The R40 GMAC interface is not controlled by the syscon register but
> has a separate configuration register in the CCU.
> The clock gate and reset bits are in a different register compared
> to the other SoCs supported by this driver.
> The diver uses the -gmac suffix for the R40 because the R40 also
> has a different 100 MBit MAC (EMAC).
>
> Signed-off-by: Lothar Felten 
> ---
>  drivers/net/sun8i_emac.c | 69 
> +---
>  1 file changed, 47 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index b6e5dafe83..83844a1d40 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -68,6 +68,8 @@
>
>  #if defined(CONFIG_MACH_SUNXI_H3_H5)
>  #define SUN8I_GPD8_GMAC2
> +#elif defined(CONFIG_MACH_SUN8I_R40)
> +#define SUN8I_GPD8_GMAC5

Can be done through driver_data?

>  #else
>  #define SUN8I_GPD8_GMAC4
>  #endif
> @@ -99,6 +101,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  enum emac_variant {
> A83T_EMAC = 1,
> H3_EMAC,
> +   R40_GMAC,
> A64_EMAC,
>  };
>
> @@ -279,6 +282,9 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev 
> *priv)
> int ret;
> u32 reg;
>
> +   if (priv->variant == R40_GMAC)
> +   return 0;
> +
> reg = readl(priv->sysctl_reg + 0x30);
>
> if (priv->variant == H3_EMAC) {
> @@ -630,11 +636,25 @@ static void sun8i_emac_board_setup(struct emac_eth_dev 
> *priv)
> }
>  #endif
>
> +#ifdef CONFIG_MACH_SUN8I_R40
> +   /* Set clock gating for emac */
> +   setbits_le32(>ahb_reset1_cfg, BIT(AHB_RESET_OFFSET_GMAC));
> +
> +   /* De-assert EMAC */
> +   setbits_le32(>ahb_gate1, BIT(AHB_GATE_OFFSET_GMAC));
> +
> +   /* Select RGMII for R40 */
> +   setbits_le32(>gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
> +   CCM_GMAC_CTRL_GPIT_RGMII);
> +   setbits_le32(>gmac_clk_cfg,
> +CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY));
> +#else

Can be done through driver_data variant?

Jagan.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, Feb 7, 2018 at 3:40 PM, Siva Durga Prasad Paladugu
 wrote:
> Hi Jagan,
>
>
>> -Original Message-
>> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> Sent: Tuesday, January 23, 2018 10:41 PM
>> To: Siva Durga Prasad Paladugu 
>> Cc: U-Boot-Denx ; Siva Durga Prasad Paladugu
>> 
>> Subject: Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for
>> ZynqMP qspi driver
>>
>> On Thu, Jan 4, 2018 at 1:07 PM, Siva Durga Prasad Paladugu
>>  wrote:
>> > This patch adds qspi driver support for ZynqMP SoC. This driver is
>> > responsible for communicating with qspi flash devices.
>> >
>> > Signed-off-by: Siva Durga Prasad Paladugu 
>> > ---
>> > Changes from v1:
>> > - Rebased on top of latest master
>> > - Moved macro definitions to .h file as per comment
>> > - Fixed magic values with macros as per comment
>> > ---
>> >  arch/arm/cpu/armv8/zynqmp/Kconfig  |   7 +
>> >  arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h | 154 ++
>> >  drivers/spi/Makefile   |   1 +
>> >  drivers/spi/zynqmp_qspi.c  | 678
>> +
>>
>> Was this gqspi like linux spi-zynqmp-gqspi.c or different?
> Yes.

then try to use similar naming conventions in macros, or in function
names as well.

>
>>
>> >  4 files changed, 840 insertions(+)
>> >  create mode 100644 arch/arm/include/asm/arch-
>> zynqmp/zynqmp_qspi.h
>> >  create mode 100644 drivers/spi/zynqmp_qspi.c
>> >
>> > diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig
>> > b/arch/arm/cpu/armv8/zynqmp/Kconfig
>> > index 3f922b4..2fe4f71 100644
>> > --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
>> > +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
>> > @@ -65,6 +65,13 @@ config PMUFW_INIT_FILE
>> >   Include external PMUFW (Platform Management Unit FirmWare) to
>> >   a Xilinx bootable image (boot.bin).
>> >
>> > +config ZYNQMP_QSPI
>> > +   bool "Configure ZynqMP QSPI"
>> > +   select DM_SPI
>> > +   help
>> > + This option is used to enable ZynqMP QSPI controller driver which
>> > + is used to communicate with qspi flash devices.
>>
>> I've commented this before, what is the reason for adding spi kconfig entry
>> in arch area instead of drivers/spi?
>
> I might have missed it, Will move to drivers/spi
>>
>> > +
>> >  config ZYNQMP_USB
>> > bool "Configure ZynqMP USB"
>> >
>> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h
>> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h
>> > new file mode 100644
>> > index 000..5e2926e
>> > --- /dev/null
>> > +++ b/arch/arm/include/asm/arch-zynqmp/zynqmp_qspi.h
>> > @@ -0,0 +1,154 @@
>> > +/*
>> > + * (C) Copyright 2014 - 2015 Xilinx
>> > + *
>> > + * Xilinx ZynqMP Quad-SPI(QSPI) controller driver (master mode only)
>> > + *
>> > + * SPDX-License-Identifier:GPL-2.0+
>> > + */
>> > +
>> > +#ifndef _ASM_ARCH_ZYNQMP_QSPI_H_
>> > +#define _ASM_ARCH_ZYNQMP_QSPI_H_
>> > +
>> > +#define ZYNQMP_QSPI_GFIFO_STRT_MODE_MASK   BIT(29)
>> > +#define ZYNQMP_QSPI_CONFIG_MODE_EN_MASK(3 << 30)
>> > +#define ZYNQMP_QSPI_CONFIG_DMA_MODE(2 << 30)
>> > +#define ZYNQMP_QSPI_CONFIG_CPHA_MASK   BIT(2)
>> > +#define ZYNQMP_QSPI_CONFIG_CPOL_MASK   BIT(1)
>> > +
>> > +/* QSPI MIO's count for different connection topologies */
>> > +#define ZYNQMP_QSPI_MIO_NUM_QSPI0  6
>> > +#define ZYNQMP_QSPI_MIO_NUM_QSPI1  5
>> > +#define ZYNQMP_QSPI_MIO_NUM_QSPI1_CS   1
>> > +
>> > +/*
>> > + * QSPI Interrupt Registers bit Masks
>> > + *
>> > + * All the four interrupt registers (Status/Mask/Enable/Disable) have
>> > +the same
>> > + * bit definitions.
>> > + */
>> > +#define ZYNQMP_QSPI_IXR_TXNFULL_MASK   0x0004 /* QSPI TX
>> FIFO Overflow */
>> > +#define ZYNQMP_QSPI_IXR_TXFULL_MASK0x0008 /* QSPI TX
>> FIFO is full */
>> > +#define ZYNQMP_QSPI_IXR_RXNEMTY_MASK   0x0010 /* QSPI RX
>> FIFO Not Empty */
>> > +#define ZYNQMP_QSPI_IXR_GFEMTY_MASK0x0080 /* QSPI
>> Generic FIFO Empty */
>> > +#define ZYNQMP_QSPI_IXR_ALL_MASK
>> (ZYNQMP_QSPI_IXR_TXNFULL_MASK | \
>> > +   ZYNQMP_QSPI_IXR_RXNEMTY_MASK)
>> > +
>> > +/*
>> > + * QSPI Enable Register bit Masks
>> > + *
>> > + * This register is used to enable or disable the QSPI controller  */
>> > +#define ZYNQMP_QSPI_ENABLE_ENABLE_MASK 0x0001 /* QSPI
>> Enable Bit
>> > +Mask */
>> > +
>> > +#define ZYNQMP_QSPI_GFIFO_LOW_BUS  BIT(14)
>> > +#define ZYNQMP_QSPI_GFIFO_CS_LOWER BIT(12)
>> > +#define ZYNQMP_QSPI_GFIFO_UP_BUS   BIT(15)
>> > +#define ZYNQMP_QSPI_GFIFO_CS_UPPER BIT(13)
>> > +#define ZYNQMP_QSPI_SPI_MODE_QSPI  (3 << 10)
>> > +#define ZYNQMP_QSPI_SPI_MODE_SPI   BIT(10)
>> > +#define ZYNQMP_QSPI_SPI_MODE_DUAL_SPI  (2 << 10)
>> > +#define ZYNQMP_QSPI_IMD_DATA_CS_ASSERT 5
>> > +#define 

Re: [U-Boot] [PATCH v10 3/3] Adding wget

[Simon Glass]

Hi Duncan,

On 22 April 2018 at 21:22, Duncan Hare  wrote:
>
>
> 
>>From: Simon Glass 
>>To: Duncan Hare 
>>Sent: Sunday, April 22, 2018 1:10 PM
>>Subject: Re: [PATCH v10 3/3] Adding wget
>>
>>Hi Duncan,
>
>>On 17 April 2018 at 15:58, Duncan Hare  wrote:
>>> From: Simon Glass 
>
>>> It has been through patman, and the only errors flagged a packed
>>> structures,
>>> necessary for packed headers.
>
>>It should be possible in the Python test to enable an http server on
>> localhost with a few lines of code, and then connect to it in the test?
>
> Yes server at port 80. The server can be tested with the wget command
which
> can be installed on linux.
> I doubt that loop-back like this will produce the scrambling of packet
order
> which is a feature of push down stacks for packet queues
> in the internet.
>
> The pi is easy to overrun when testing on a low latency network, because
the
> TCP send window size is defined by the number of
> net_rx_buffers, which is controlled the CONFIG_SYS_RX_ETH_BUFFER in
> include.net.h,  which sets PKTBUFSRX at the beginning of include/net.h,
> which in-turn defines a buffer pool in net/net.c, array named
net_pkt_buf.
>
> Hence my comment in a different thread about buffering on the pi. Few of
the
> socs appear to use net_pkt_buf  buffers for net traffic.
>
> If there are too many transmission errors the sending tcp drops the
> connection. My solution to this is to halve the size of
> CONFIG_SYS_RX_ETH_BUFFER until transmission works.
>
> If I was thinking about a buffer pool for in the drivers, I'd implement it
> in net/net.c. Interface "getbuffer," returns a pointer,
> and increments an index to the next net_rx_buffer with no protection for
> overrun. Overrun is managed by ack numbers in TCP
> and timeout in UDP.
>
> Possibly CONFIG_SYS_RX_ETH_BUFFER could come under Kconfig.

Just to be clear, I was wondering about having an automated test. Manual
tests are not very useful since people won't do them. See 'make tests' for
all the test that we currently run. I'm pretty sure you could standard up a
little server, run your wget, then shut it down, all within a pytest test.

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

Re: [U-Boot] [PATCH 2/4] dm: ofnode: add ofnode_device_is_compatible() helper

[Simon Glass]

Hi Masahiro,

On 22 April 2018 at 22:50, Masahiro Yamada 
wrote:
> 2018-04-23 5:11 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 17 April 2018 at 20:38, Masahiro Yamada 
>> wrote:
>>> device_is_compatible() takes udevice, but there is no such a helper
>>> that takes ofnode.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  drivers/core/device.c |  8 +---
>>>  drivers/core/ofnode.c | 11 +++
>>>  include/dm/ofnode.h   | 11 +++
>>>  3 files changed, 23 insertions(+), 7 deletions(-)
>>
>> Please can you add a call to this to a test?
>>
>
> No.
>
> I do not see any ofnode helper test in test/dm/.
>
> You are requesting additional work beyond this patch.
> It is unfair.
>
>
> This helper is tested indirectly by other tests.
>
> Of course, you (and anybody) are free to add per-helper grained tests,
> but this is not a good reason to block this patch.

I understand what you are saying, but you don't need to do any plumbing to
make this work. A simple call is enough, perhaps in test-fdt.c? If we get
enough tests we can refactor them into a separate ofnode test suite.

We should not add code without tests. I plan to go back and add tests for
specific calls, but don't want the work to become any harder for me.

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

Re: [U-Boot] [PATCH 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice

[Simon Glass]

Hi Masahiro,

On 22 April 2018 at 22:56, Masahiro Yamada 
wrote:
> Hi Simon,
>
>
> 2018-04-23 5:10 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 17 April 2018 at 20:38, Masahiro Yamada 
>> wrote:
>>> Currently, regmap_init_mem() takes udevice. This requires the node
>>> has already been associated with a device. It prevents syscon/regmap
>>> from behaving like those in Linux.
>>>
>>> Change the first argumenet to take the device node.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
>>>  drivers/core/regmap.c| 11 +--
>>>  drivers/core/syscon-uclass.c |  2 +-
>>>  drivers/phy/meson-gxl-usb2.c |  2 +-
>>>  drivers/phy/meson-gxl-usb3.c |  2 +-
>>>  drivers/ram/rockchip/dmc-rk3368.c|  2 +-
>>>  drivers/ram/rockchip/sdram_rk3188.c  |  2 +-
>>>  drivers/ram/rockchip/sdram_rk322x.c  |  2 +-
>>>  drivers/ram/rockchip/sdram_rk3288.c  |  2 +-
>>>  drivers/ram/rockchip/sdram_rk3399.c  |  2 +-
>>>  drivers/ram/stm32mp1/stm32mp1_ram.c  |  2 +-
>>>  drivers/reset/reset-meson.c  |  2 +-
>>>  include/regmap.h |  4 ++--
>>>  13 files changed, 18 insertions(+), 19 deletions(-)
>>
>> Can you please add a simple test for regmap on sandbox?
>>
>
> No.
>
> Please stop this boiler-plate response.
>
> Simple tests for regmap already exist in test/dm/regmap.c
>
> regmap_init_mem() is not a new function, and it is tested
> through other function tests.

Can you please point to that? I don't see anything for sandbox.

>
> You block patches several times before
> by making the contributors say "Sorry, I am busy".
>
>
> I am really busy, but I need to fix the misimplementation
> of syscon for Socionext drivers.
>
> Why should I be annoyed by additional work
> to fix the problem?

Because otherwise I have no idea if the code works, no one will be able to
change it later without potentially breaking it, etc. If people get into
the habit of writing a little test at the same time, it takes very little
extra effort.

I have pour an ENORMOUS amount of time into making testing in U-Boot
better, as has Stephen Warren. We need to continue the effort. I'm sorry
that this adds a little more time to the patch submission process, but we
gain a lot of benefits. Look at all the times we have tried to fix address
translation in U-Boot, or FIT behaviour, when we don't have tests or even a
clear definition of the correct behaviour.

So please try to understand my point of view here. This is not just about
your patch, it is about the future of U-Boot for future users and
contributors.

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

Re: [U-Boot] [PATCH 4/4] syscon: add Linux-compatible syscon API

[Simon Glass]

On 22 April 2018 at 22:58, Masahiro Yamada 
wrote:
> Hi Simon,
>
>
> 2018-04-23 5:11 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 17 April 2018 at 20:38, Masahiro Yamada 
>> wrote:
>>> The syscon implementation in U-Boot is different from that in Linux.
>>> Thus, DT files imported from Linux do not work for U-Boot.
>>>
>>> In U-Boot driver model, each node is bound to a dedicated driver
>>> that is the most compatible to it.  This design gets along with the
>>> concept of DT, and the syscon in Linux originally worked like that.
>>>
>>> However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
>>> interface from platform devices") changed the behavior because it is
>>> useful to let a device bind to another driver, but still works as a
>>> syscon provider.
>>>
>>> That change had happened before U-Boot initially supported the syscon
>>> driver by commit 6f98b7504f70 ("dm: Add support for generic system
>>> controllers (syscon)").  So, the U-Boot's syscon works differently
>>> from the beginning.  I'd say this is mis-implementation given that
>>> DT is not oriented to a particular project, but Linux is the canon
>>> of DT in practice.
>>>
>>> The problem typically arises in the combination of "syscon" and
>>> "simple-mfd" compatibles.
>>>
>>> In Linux, they are orthogonal, i.e., the order between "syscon" and
>>> "simple-mfd" does not matter at all.
>>>
>>> Assume the following compatible.
>>>
>>>compatible = "foo,bar-syscon", "syscon", "simple-mfd";
>>>
>>> In U-Boot, this device node is bound to the syscon driver
>>> (driver/core/syscon-uclass.c) since the "syscon" is found to be the
>>> most compatible.  Then, syscon_get_regmap() succeeds.
>>>
>>> However,
>>>
>>>compatible = "foo,bar-syscon", "simple-mfd", "syscon";
>>>
>>> does not work because this node is bound to the simple-bus driver
>>> (drivers/core/simple-bus.c) in the favor of "simple-mfd" compatible.
>>> The compatible string "syscon" is just dismissed.
>>>
>>> Moreover,
>>>
>>>compatible = "foo,bar-syscon", "syscon";
>>>
>>> works like the first case because the syscon driver populates the
>>> child devices.  This is wrong because populating children is the job
>>> of "simple-mfd" (or "simple-bus").
>>>
>>> This commit ports syscon_node_to_regmap() from Linux.  This API
>>> does not require the given node to be bound to a driver in any way.
>>>
>>> Reported-by: Kunihiko Hayashi 
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  drivers/core/syscon-uclass.c | 63
>> 
>>>  include/syscon.h |  8 ++
>>>  2 files changed, 71 insertions(+)
>>
>> I was not aware of this change in how Linux worked, but it makes sense.
>>
>> Please can you add a test for this?
>
>
> I do not believe a missing test would block this patch,
> but I volunteered to add it (as a separate patch).
>
> http://patchwork.ozlabs.org/patch/902733/

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

Re: [U-Boot] [PATCH 1/1] cmd: CONFIG_CMD_LOG select CONFIG_LOG

[Simon Glass]

On 19 April 2018 at 14:02, Heinrich Schuchardt  wrote:
> CONFIG_CMD_LOG without CONFIG_LOG leads to a build error:
> ‘gd_t {aka volatile struct global_data}’ has no member named
> ‘default_log_level’
>
> So CMD_LOG should select LOG.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH] test: regmap: test Linux-compatible syscon_node_to_regmap()

[Simon Glass]

On 22 April 2018 at 22:26, Masahiro Yamada 
wrote:
> Like Linux, syscon_node_to_regmap() allows a node to work as a syscon
> provider without binding it to a syscon driver.  Test this.
>
> Requested-by: Simon Glass 
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/sandbox/dts/test.dts |  8 
>  test/dm/regmap.c  | 17 +
>  2 files changed, 25 insertions(+)

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

Re: [U-Boot] [PATCH] lib/rsa: Kconfig: Remove superfluous 'depends on RSA'

[Simon Glass]

On 21 April 2018 at 06:00, Eugeniu Rosca  wrote:
> RSA_SOFTWARE_EXP and RSA_FREESCALE_EXP are wrapped inside:
>
> if RSA
> ...
> endif
>
> So, remove the redundant "depends on RSA" from their depends expression.
> In addition, move SPL_RSA into the same "if RSA ... endif" block, since
> its only direct dependeny is CONFIG_RSA. This tidies up and simplifies
> reading of lib/rsa/Kconfig.
>
> No functional change intended.
>
> Signed-off-by: Eugeniu Rosca 
> ---
>  lib/rsa/Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [[RESEND] PATCH v3 1/2] mmc: sdhci: add SDHCI_QUIRK_BROKEN_HISPD_MODE

[Simon Glass]

On 20 April 2018 at 02:55, Hannes Schmelzer <
hannes.schmel...@br-automation.com> wrote:
> From: Hannes Schmelzer 
>
> Some IP-core implementations of the SDHCI have different troubles on the
> silicon where they are placed.
>
> On ZYNQ platform for example Xilinx doesn't accept the hold timing of an
> eMMC chip which operates in High-Speed mode and must be forced to
> operate in non high-speed mode. To get rid of this
> "SDHCI_QUIRK_BROKEN_HISPD_MODE" is introduced.
>
> For more details about this refer to the Xilinx answer-recor #5
> https://www.xilinx.com/support/answers/5.html
>
> This commit:
> - doesn't set HISPD bit on the host-conroller
> - reflects this fact within the host-controller capabilities
>
> Upon this the layer above (mmc-driver) can setup the card correctly.
>
> Otherwise the MMC card will be switched into high-speed mode and causes
> possible timing violation on the host-controller side.
>
> Signed-off-by: Hannes Schmelzer 
>
> Signed-off-by: Hannes Schmelzer 
> ---
>
> Changes in v3:
> - cleanup sign-off tag
> - fix typo (sdci -> sdhci)
> - combine the if instruction SDHCI_QUIRK_BROKEN_HISPD_MODE with the
>   existing SDHCI_QUIRK_NO_HISPD_BIT
>
> Changes in v2:
> - don't use the SDHCI_QUIRK_NO_HISPD_BIT for getting rid of this,
> since this quirk was designed for another purpose. Instead introduce the
> new SDHCI_QUIRK_BROKEN_HISPD_MODE quirk.
>
>  drivers/mmc/sdhci.c | 8 +++-
>  include/sdhci.h | 6 ++
>  2 files changed, 13 insertions(+), 1 deletion(-)
>

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

Re: [U-Boot] [PATCH 1/1] log: CONFIG_LOG should select CONFIG_DM

[Simon Glass]

On 19 April 2018 at 13:59, Heinrich Schuchardt  wrote:
> Compling with CONFIG_LOG and without CONFIG_DM results in
> common/log.c:47: undefined reference to `uclass_get_name'
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Or should we solve this with an #ifdef?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

[Jagan Teki]

On Wed, Apr 25, 2018 at 1:46 AM, Tom Rini  wrote:
> On Tue, Apr 24, 2018 at 09:57:58PM +0200, Maxime Ripard wrote:
>> Hi Jagan,
>>
>> On Fri, Apr 06, 2018 at 11:36:59AM +0530, Jagan Teki wrote:
>> > On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
>> >  wrote:
>> > > On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
>> > >> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
>> > >>  wrote:
>> > >> > From: Philipp Tomsich 
>> > >> >
>> > >> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> > >> > read 10MB from a fast eMMC device due to excessive delays in polling
>> > >> > loops.
>> > >> >
>> > >> > This commit restructures the main polling loops to use get_timer(...)
>> > >> > to determine whether a (millisecond) timeout has expired.  We choose
>> > >> > not to use the wait_bit function, as we don't need interruptability
>> > >> > with ctrl-c and have at least one case where two bits (one for an
>> > >> > error condition and another one for completion) need to be read and
>> > >> > using wait_bit would have not added to the clarity.
>> > >> >
>> > >> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
>> > >> > 10MB write decreases from 9.302s to 0.884s).
>> > >>
>> > >> Fyi: I've seen significant improvement, but not 10x on A64
>> > >> (bananpi-m64) with read
>> > >>
>> > >> Before this change:
>> > >>
>> > >> => mmc dev 0
>> > >> switch to partitions #0, OK
>> > >> mmc0 is current device
>> > >> => fatload mmc 0:1 $kernel_addr_r Image
>> > >> reading Image
>> > >> 16310784 bytes read in 821 ms (18.9 MiB/s)
>> > >> => mmc dev 1
>> > >> switch to partitions #0, OK
>> > >> mmc1(part 0) is current device
>> > >> => ext4load mmc 1:1 $kernel_addr_r Image
>> > >> 16310784 bytes read in 1109 ms (14 MiB/s)
>> > >>
>> > >>
>> > >> After this change:
>> > >>
>> > >> => mmc dev 0
>> > >> switch to partitions #0, OK
>> > >> mmc0 is current device
>> > >> => fatload mmc 0:1 $kernel_addr_r Image
>> > >> 16310784 bytes read in 784 ms (19.8 MiB/s)
>> > >> => mmc dev 1
>> > >> switch to partitions #0, OK
>> > >> mmc1(part 0) is current device
>> > >> => ext4load mmc 1:1 $kernel_addr_r Image
>> > >> 16310784 bytes read in 793 ms (19.6 MiB/s)
>> > >
>> > > Yeah, the smaller the file is, the bigger the gain is. Since you have
>> > > an almost twice bigger file, the gains are probably just noise at that
>> > > point and the bottleneck starts to be your MMC.
>> >
>> > Acked-by: Jagan Teki 
>>
>> Jaehoon doesn't seem to reply at all, can we merge this through the
>> sunxi tree?

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

[U-Boot] DWC3 USB driver regression

[Masahiro Yamada]

Hi.


I found DWC3 usb driver on UniPhier SoC family
not working.


I did git-bisect, and the first bad commit is


7c839ea70c4991e8d4c322e074359ac5e155d59d is the first bad commit
commit 7c839ea70c4991e8d4c322e074359ac5e155d59d
Author: Neil Armstrong 
Date:   Wed Apr 11 17:08:01 2018 +0200

usb: host: dwc3: Add support for multiple PHYs

DWC3 Ips can have more than 1 PHY for USB2 and 1 PHY for USB3, add support
for a generic number of PHYs and adapt the code to handle a generic
number of PHYs.

Signed-off-by: Neil Armstrong 




If I revert this commit, I can get the USB on my board working.

Any insight about the cause of the problem?



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

Re: [U-Boot] NDS32 toolchain?

[rick]

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Tuesday, April 24, 2018 8:14 PM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: u-boot@lists.denx.de; Greentime Ying-Han Hu(胡英漢);
> rickche...@gmail.com
> Subject: Re: NDS32 toolchain?
>
> On Tue, Apr 24, 2018 at 03:10:02AM +, r...@andestech.com wrote:
> >
> >
> > > -Original Message-
> > > From: Tom Rini [mailto:tr...@konsulko.com]
> > > Sent: Tuesday, April 24, 2018 4:17 AM
> > > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> > > Subject: NDS32 toolchain?
> > >
> > > Hey,
> > >
> > > So I'm looking over my setups again at what we do and do not have
> > > build testing and run-time testing, and I see that for nds32 I just 
> > > cannot find a
> good toolchain.
> > > If I try for example
> > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64
> > > /7.3.0/x86_ 64-gcc-7.3.0-nolibc-nds32-elf.tar.xz
> > > it first fails on the -G0 flag that we have set in and then it
> > > complains about a lack of position independent code support.  Is the
> > > kernel.org toolchain perhaps configured incorrectly?
> > >
> >
> > Hi Tom
> >
> > You may try the following paths:
> >
> > 1.
> > github version
> > https://github.com/andestech/build_script.git
> > https://github.com/greentime/prebuilt-nds32-toolchain/releases
>
> This binary gets a lot farther:
>   CC  drivers/mtd/cfi_flash.o
> drivers/mtd/cfi_flash.c: In function 'write_buff':
> drivers/mtd/cfi_flash.c:1435:1: internal compiler error: in change_address_1, 
> at
> emit-rtl.c:2126  }  ^
> 0x81fecd6 change_address_1
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/
> emit-rtl.c:2126
> 0x81ff26d adjust_address_1(rtx_def*, machine_mode, long long, int, int, int,
> long long)
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/
> emit-rtl.c:2264
> 0x8762488 nds32_spilt_doubleword(rtx_def**, bool)
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/c
> onfig/nds32/nds32-md-auxiliary.c:3238
> 0x886be2f gen_split_7(rtx_insn*, rtx_def**)
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/c
> onfig/nds32/nds32-doubleword.md:209
> 0x81fdf74 try_split(rtx_def*, rtx_insn*, int)
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/
> emit-rtl.c:3658
> 0x8450a37 split_insn
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r
> ecog.c:2865
> 0x8450d0e split_all_insns()
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r
> ecog.c:2955
> 0x8450d6a rest_of_handle_split_before_sched2
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r
> ecog.c:3995
> 0x8450d6a execute
>
> /NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r
> ecog.c:4034
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> /home/trini/work/u-boot/u-boot/scripts/Makefile.build:280: recipe for target
> 'drivers/mtd/cfi_flash.o' failed
> make[2]: *** [drivers/mtd/cfi_flash.o] Error 1
> /home/trini/work/u-boot/u-boot/Makefile:1355: recipe for target 'drivers/mtd'
> failed
> make[1]: *** [drivers/mtd] Error 2
> make[1]: Leaving directory '/tmp/adp-ag101p'
> Makefile:150: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
Hi Tom

Very Sorry about the build failure.
I shall verify it before sending to you.

Our teammates are trying to fix this problem.
I will offer you a refine one ASAP.

> > 2.
> > Arnd Bergmann built
> > https://lkml.org/lkml/2018/4/17/395
> > www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6
> > .4.0-nolibc-nds32le-linux.tar.xz
>
> Oddly, his 6.4.0 gets farther along than his 7.3.0 ones, but still doesn't 
> work as I
> get things like this:
>   AS  arch/nds32/cpu/n1213/start.o
> arch/nds32/cpu/n1213/start.S: Assembler messages:
> arch/nds32/cpu/n1213/start.S:256:
> Error: Incorrect syntax, sethi $ta,hi20(_start@GOTOFF).
> arch/nds32/cpu/n1213/start.S:256:
> Error: Incorrect syntax, ori $ta,$ta,lo12(_start@GOTOFF).
> arch/nds32/cpu/n1213/start.S:256:
> Warning: relax hint unrecognized instruction: line 254.
>
> and it just keeps going from there.  You may want to drop him an email about
> how he's configuring for nds32le.  Last time I talked with him, he wasn't
> planning to re-spin the 7.3.x ones, but he might do gcc-8 once it's ready.
>
> > > Related, is there a QEMU target for nds32 that we could leverage so
> > > that once the toolchain issue is resolved we can update .travis.yml to run
> tests on it?
> > > Thanks!
> >
> > I am applying the QEMU offering permit.
> > If it is ok. I will prepare it for you.
>

Because I always verify NDS32 on board (AG101P or AE3XX).
I never verify it on NDS32 QEMU.
It seem still have some problems, maybe need some time to debug for 

Re: [U-Boot] Please pull u-boot-video/master

[Tom Rini]

On Tue, Apr 24, 2018 at 09:10:13PM +0200, Anatolij Gustschin wrote:

> Hi Tom,
> 
> The following changes since commit 5bc0543df3079add8152afa041b887d081d71839:
> 
>   treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08 18:31:09 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> for you to fetch changes up to 751641814c1db245695dd8f40e9c811320e69f79:
> 
>   video-uclass: Fix logical-not-parentheses warning (2018-04-24 20:57:14 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
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] u-boot.dtb is not generated when enabling verified boot

[Davis Roman]

Hi Fabio,

Additionally, I did check that my-blob.dtb does contain the public key
after signing the fitimage by using 'fdtdump -s'

Thank you,

Davis

On Tue, Apr 24, 2018 at 9:19 PM, Davis Roman 
wrote:

> Hi Fabio,
>
> Thank you so much for responding. It's good to know that I'm not alone in
> the world. :)
>
> Unfortunately, I'm stuck with 2016.03 for the moment.
>
> So I'm still having issues with getting verified boot to work. After
> compiling and installing the new u-boot image on my board I noticed that it
> bricked my board.
>
> After lots of trail and error, I tracked it down to CONFIG_OF_CONTROL.
> When enabled, u-boot refuses to boot. ( no output is shown on the serial
> debug interface)
>
> Since I'm using CONFIG_OF_SEPERATE, I suspect u-boot tries to read my
> attached dtb blob however it's probably wrong.
>
> So my dts file looks like this:
>
> /dts-v1/;
>
> / {
> model = "dummy";
> compatible = "dummy";
>
> reset@0 {
> compatible = "dummy";
> };
> };
>
>
>
> I know that the properties 'model' and 'compatible' matter when in regards
> to the kernel however u-boot is using the device tree just to hold the
> public key so do they still matter?
> For now I just set them to "dummy"
>
>
> Secondly, I'm doing:
>
> $ cat u-boot.imx my-blob.dtb > u-boot.imx.final
>
>
> Do you see anything that stands out to you?
>
> Thank you!
>
> Davis
>
>
>
> On Tue, Apr 24, 2018 at 7:40 PM, Fabio Estevam  wrote:
>
>> Hi Davis,
>>
>> On Fri, Apr 20, 2018 at 9:00 PM, Davis Roman 
>> wrote:
>> > Hello,
>> >
>> > I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.
>>
>> It would be better to try something more recent, such as 2018.03 instead.
>>
>> > So far I've managed to figure out that I need the following additional
>> > config settings:
>> >  #define CONFIG_DM
>> > #define CONFIG_ENABLE_VBOOT
>> > #define CONFIG_RSA
>> > #define CONFIG_FIT
>> > #define CONFIG_OF_CONTROL
>> > #define CONFIG_FIT_SIGNATURE
>> > #define CONFIG_OF_SEPERATE
>> > #define CONFIG_OF_LIBFDT
>> > #define CONFIG_FIT_VERBOSE
>> >
>> > However, no matter what I do I can't seem to generate u-boot.dtb.
>>
>> This is expected if your board does not use device tree file in U-Boot.
>>
>> >
>> > My understanding is that u-boot automatically generates this
>> > u-boot.dtb for the purpose of storing
>> > the public key when mkimage signs the fitimage and that this process
>> > does not require that I provide a dts file.
>> >
>> > However, below are the files that are generated with my current
>> > configuration and no u-boot.dtb file is generated.
>> >
>> > Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
>> > was reasonable to believe that u-boot.bin contained the device tree
>> > however as shown below both u-boot-nodtb.bin and u-boot.bin have an
>> > idential hash.
>> >
>> > Is there something that I'm missing here? Any advice would be greatly
>> > appreciated
>> >
>> > Thank you,
>> >
>> > Davis
>> >
>> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
>> > -rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
>> > -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
>> > -rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
>> > -rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx
>>
>> That's the one you need.
>>
>> If your board does not use device tree you will get a u-boot.imx
>> binary that you can flash into your boot media.
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot.dtb is not generated when enabling verified boot

[Davis Roman]

Hi Fabio,

Thank you so much for responding. It's good to know that I'm not alone in
the world. :)

Unfortunately, I'm stuck with 2016.03 for the moment.

So I'm still having issues with getting verified boot to work. After
compiling and installing the new u-boot image on my board I noticed that it
bricked my board.

After lots of trail and error, I tracked it down to CONFIG_OF_CONTROL. When
enabled, u-boot refuses to boot. ( no output is shown on the serial debug
interface)

Since I'm using CONFIG_OF_SEPERATE, I suspect u-boot tries to read my
attached dtb blob however it's probably wrong.

So my dts file looks like this:

/dts-v1/;

/ {
model = "dummy";
compatible = "dummy";

reset@0 {
compatible = "dummy";
};
};



I know that the properties 'model' and 'compatible' matter when in regards
to the kernel however u-boot is using the device tree just to hold the
public key so do they still matter?
For now I just set them to "dummy"


Secondly, I'm doing:

$ cat u-boot.imx my-blob.dtb > u-boot.imx.final


Do you see anything that stands out to you?

Thank you!

Davis



On Tue, Apr 24, 2018 at 7:40 PM, Fabio Estevam  wrote:

> Hi Davis,
>
> On Fri, Apr 20, 2018 at 9:00 PM, Davis Roman 
> wrote:
> > Hello,
> >
> > I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.
>
> It would be better to try something more recent, such as 2018.03 instead.
>
> > So far I've managed to figure out that I need the following additional
> > config settings:
> >  #define CONFIG_DM
> > #define CONFIG_ENABLE_VBOOT
> > #define CONFIG_RSA
> > #define CONFIG_FIT
> > #define CONFIG_OF_CONTROL
> > #define CONFIG_FIT_SIGNATURE
> > #define CONFIG_OF_SEPERATE
> > #define CONFIG_OF_LIBFDT
> > #define CONFIG_FIT_VERBOSE
> >
> > However, no matter what I do I can't seem to generate u-boot.dtb.
>
> This is expected if your board does not use device tree file in U-Boot.
>
> >
> > My understanding is that u-boot automatically generates this
> > u-boot.dtb for the purpose of storing
> > the public key when mkimage signs the fitimage and that this process
> > does not require that I provide a dts file.
> >
> > However, below are the files that are generated with my current
> > configuration and no u-boot.dtb file is generated.
> >
> > Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
> > was reasonable to believe that u-boot.bin contained the device tree
> > however as shown below both u-boot-nodtb.bin and u-boot.bin have an
> > idential hash.
> >
> > Is there something that I'm missing here? Any advice would be greatly
> > appreciated
> >
> > Thank you,
> >
> > Davis
> >
> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
> > -rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
> > -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
> > -rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
> > -rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx
>
> That's the one you need.
>
> If your board does not use device tree you will get a u-boot.imx
> binary that you can flash into your boot media.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot.dtb is not generated when enabling verified boot

[Fabio Estevam]

Hi Davis,

On Fri, Apr 20, 2018 at 9:00 PM, Davis Roman  wrote:
> Hello,
>
> I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.

It would be better to try something more recent, such as 2018.03 instead.

> So far I've managed to figure out that I need the following additional
> config settings:
>  #define CONFIG_DM
> #define CONFIG_ENABLE_VBOOT
> #define CONFIG_RSA
> #define CONFIG_FIT
> #define CONFIG_OF_CONTROL
> #define CONFIG_FIT_SIGNATURE
> #define CONFIG_OF_SEPERATE
> #define CONFIG_OF_LIBFDT
> #define CONFIG_FIT_VERBOSE
>
> However, no matter what I do I can't seem to generate u-boot.dtb.

This is expected if your board does not use device tree file in U-Boot.

>
> My understanding is that u-boot automatically generates this
> u-boot.dtb for the purpose of storing
> the public key when mkimage signs the fitimage and that this process
> does not require that I provide a dts file.
>
> However, below are the files that are generated with my current
> configuration and no u-boot.dtb file is generated.
>
> Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
> was reasonable to believe that u-boot.bin contained the device tree
> however as shown below both u-boot-nodtb.bin and u-boot.bin have an
> idential hash.
>
> Is there something that I'm missing here? Any advice would be greatly
> appreciated
>
> Thank you,
>
> Davis
>
> davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
> -rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
> -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
> -rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
> -rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx

That's the one you need.

If your board does not use device tree you will get a u-boot.imx
binary that you can flash into your boot media.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot.dtb is not generated when enabling verified boot

[Davis Roman]

Okay I found my answer. I'll post here for any other poor soul that might
need this.

So I ended up using:

$ make EXT_DTB=

to get past my previous error.



On Fri, Apr 20, 2018 at 8:21 PM, Davis Roman 
wrote:

> Okay. I found my first mistake. I would help if I could spell properly!
>
> Turns out it was:
> #define CONFIG_OF_SEPARATE
> and not
> #define CONFIG_OF_SEPERATE
>
> but now I'm getting an error:
>
>   LD  test/dm/built-in.o
>   CC  examples/standalone/stubs.o
>   LD  examples/standalone/libstubs.o
>   CC  examples/standalone/hello_world.o
>   LD  examples/standalone/hello_world
>   OBJCOPY examples/standalone/hello_world.srec
>   OBJCOPY examples/standalone/hello_world.bin
>   LDS u-boot.lds
>   LD  u-boot
>   OBJCOPY u-boot-nodtb.bin
>
> Device Tree Source is not correctly specified.
> Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> or build with 'DEVICE_TREE=' argument
>
> dts/Makefile:27: recipe for target 'arch/arm/dts/unset.dtb' failed
> make[1]: *** [arch/arm/dts/unset.dtb] Error 1
> Makefile:820: recipe for target 'dts/dt.dtb' failed
> make: *** [dts/dt.dtb] Error 2
>
>
>
> Do I need to provide a dts file? I got the impression that this wasn't
> the case from the docs.
>
> Thank you,
>
> Davis
>
> On Fri, Apr 20, 2018 at 8:00 PM, Davis Roman 
> wrote:
> > Hello,
> >
> > I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.
> >
> > So far I've managed to figure out that I need the following additional
> > config settings:
> >  #define CONFIG_DM
> > #define CONFIG_ENABLE_VBOOT
> > #define CONFIG_RSA
> > #define CONFIG_FIT
> > #define CONFIG_OF_CONTROL
> > #define CONFIG_FIT_SIGNATURE
> > #define CONFIG_OF_SEPERATE
> > #define CONFIG_OF_LIBFDT
> > #define CONFIG_FIT_VERBOSE
> >
> > However, no matter what I do I can't seem to generate u-boot.dtb.
> >
> > My understanding is that u-boot automatically generates this
> > u-boot.dtb for the purpose of storing
> > the public key when mkimage signs the fitimage and that this process
> > does not require that I provide a dts file.
> >
> > However, below are the files that are generated with my current
> > configuration and no u-boot.dtb file is generated.
> >
> > Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
> > was reasonable to believe that u-boot.bin contained the device tree
> > however as shown below both u-boot-nodtb.bin and u-boot.bin have an
> > idential hash.
> >
> > Is there something that I'm missing here? Any advice would be greatly
> > appreciated
> >
> > Thank you,
> >
> > Davis
> >
> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
> > -rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
> > -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
> > -rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
> > -rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx
> > -rw-rw-r-- 1 davis davis1286 Apr 20 23:37 u-boot.lds
> > -rw-rw-r-- 1 davis davis  456812 Apr 20 23:41 u-boot.map
> > -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot-nodtb.bin
> > -rwxrwxr-x 1 davis davis 1518250 Apr 20 23:37 u-boot.srec
> > -rw-rw-r-- 1 davis davis  119239 Apr 20 23:37 u-boot.sym
> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ sha1sum  *u-boot*
> > cf00f776da67d1081fdfb8578ce71d0a63f16c48  u-boot
> > 1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot.bin
> > 1d2ad68da6c9aa7915f8684c53b6c532a07d7c7b  u-boot.cfg
> > 599cec8e768eebf313d6735951c02c1271475f72  u-boot.imx
> > 97054bccafd82b873a0af24f8e012ff032809b29  u-boot.lds
> > 547e4e8cd4e46b5f9755aee4906a5f84906e2331  u-boot.map
> > 1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot-nodtb.bin
> > bb5839b8f23c6c8d952e65f99efac695ae91  u-boot.srec
> > 5f933891f3939802ab92c4d642af16973b60af37  u-boot.sym
> > davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function

[Simon Glass]

Hi Mario,

On 19 April 2018 at 01:50, Mario Six  wrote:
>
> Hi Simon,
>
> On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass  wrote:
> > Hi Mario,
> >
> > On 18 April 2018 at 02:35, Mario Six  wrote:
> >> Hi Simon,
> >>
> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass  wrote:
> >>> Hi Mario,
> >>>
> >>> On 11 April 2018 at 00:39, Mario Six  wrote:
>  Hi Simon,
> 
>  On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass  wrote:
> > Hi,
> >
> > On 28 March 2018 at 20:38, Mario Six  wrote:
> >> Add a cpu_print_info function to the CPU uclass to emulate the behavior
> >> of some current non-DM drivers (e.g. MPC83xx) to print CPU information
> >> during startup.
> >>
> >> Signed-off-by: Mario Six 
> >> ---
> >>  drivers/cpu/cpu-uclass.c | 10 ++
> >>  include/cpu.h| 15 +++
> >>  2 files changed, 25 insertions(+)
> >>
> >
> > I really don't want drivers printing stuff. Can you use the existing
> > get_info() method?
> >
> 
>  I could, but I'm just emulating the behavior of the legacy code here, 
>  which
>  prints some information when the CPU is initialized. I think that's 
>  pretty
>  useful, and I can do that in our board file, but that would mean 
>  implementing
>  the same routine in every MPC83xx board to get the legacy behavior back.
> >>>
> >>> Yes, but I don't want the legacy code creeping into the eclass. Can
> >>> you convert the board to use the CPU eclass instead?
> >>>
> >>
> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does 
> >> exactly
> >> what is needed. I'll implement the print_cpuinfo function in the CPU 
> >> driver, so
> >> I can get rid of the print function in the uclass (and still retain the
> >> information printing at bootup).
> >
> > OK I see. Ideally we would have a function (perhaps in board_f) which
> > prints out the CPU info after obtaining it from the uclass. So could
> > you move your print_cpuinfo() function into board_f? Would it be
> > possible to use that if CONFIG_CPU is defined?
> >
> > At some point print_cpuinfo() could be removed from various board files.
> >
>
> The function prints the following (example for our device):
>
> --- >8 ---
>
> Reset Status: External/Internal Soft, External/Internal Hard
>
> CPU:   e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz
>
> --- >8 ---
>
> So there are some values that are very specific to the platform, such as the
> CSB (Coherent System Bus) frequency, or the reset status. While it's probably
> possible to put some of that into a generic info printing routine, lots of it
> is so MPC83xx-specific that it doesn't make much sense for other CPUs.

Well you get to provide a string from get_desc() so you can add
whatever you like!

>
> Any idea how to tackle this? I don't really want to get rid of the Reset 
> Status
> printing especially, since it's pretty useful information for debugging 
> devices
> in the field.

Re the reset status, shouldn't that come from the sysreset driver? I
wonder if we should add an API call for that? Or is it something
printed by the board?

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

Re: [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support

[Jocelyn Bohr]

Thanks so much for porting this, Alex!

On Tue, Apr 24, 2018 at 4:58 AM Alex Kiernan  wrote:

> On Tue, Apr 24, 2018 at 11:24 AM, Alex Deymo  wrote:
> > +Jocelyn.
> >
> > Thanks Alex for taking the time to port this!!
>
> It turned out to be a great opportunity to play with coccinelle on
> something trivial, which I'd been meaning to do for ages... the
> refactor to add response into the fastboot_okay/fail call chain was a
> breeze with it.
>
> > 2018-04-24 11:37 GMT+02:00 Alex Kiernan :
> >>
> >>
> >> This series merges the fastboot UDP support from AOSP into mainline
> >> U-Boot.
> >>
> >> Open questions:
> >>
> >> - what's the correct way of attributing the original authors? I've added
> >>   Co-authored-by, is that right? checkpatch doesn't seem to know any
> >>   of the co- tags
> >> - currently there's no NAND support and I've no way of testing that, so
> >>   my inclination is towards leaving it like that until someone with that
> >>   particular itch to scratch can look at it
> >
> >
> > Fastboot uses partition names, like "system" and "boot" which have a
> meaning
> > in the Android partition scheme. For GPT, we just use the partition
> names as
> > the android names; but if you are booting from some other storage like
> NAND
> > where you don't have that then you need some mapping glue ("system" -->
> > device and partition number). I've seen U-Boot modifications for several
> > devices where they just stick a table hard-coded in the U-Boot code;
> which
> > works great for that device but it isn't really a generic approach. Other
> > than handling the names issue, I don't see any problem with supporting
> NAND
> > here, but a generic way to set global names / alias would be needed for
> > this.
> >
>
> With the fastboot NAND support in mainline it looks like we end up in
> mtdparts to deliver that mapping through environment variables. No
> actual idea what that looks like when you're driving it.
>
> >>
> >> - you can select both USB and UDP fastboot, but the comments in the
> >>   AOSP code suggest that needs fixing - again, I've no board I can test
> >>   USB fastboot on
> >
> >
> > I thought we checked in the Kconfig that you couldn't enable both. I
> don't
> > remember the details now but yeah you can't wait for network or USB
> traffic
> > on the current code.
> >
>
> The version I picked from (o-mr1-iot-preview-8) has them as
> independent symbols, but making them a choice would resolve the issue
> for now.
>

You can select both network and USB fastboot to be enabled with the Kconfig,
but at runtime you have to select to wait on either USB or network by
running
"fastboot udp" or "fastboot usb ". When the Android
bootloader
gets the command to reboot back to fastboot, it will read the "fastbootcmd"
env
variable and run that as a command (common/android_bootloader.c:151).


>
> >> I've not tested all the code paths yet, but the obvious stuff works
> >> (basic interaction, download, boot) - every interaction elicits a
> >> `WARNING: unknown variable: slot-count` on the console; I'm guessing
> that
> >> my local end is sending a getvar for that, but I've not investigated.
> >
> >
> > Yes, there's a bit of different handling of partitions for A/B android
> > devices. Instead of "system" you have two partitions: "system_a" and
> > "system_b" (potentially more although 2 is the most common case) so to
> know
> > whether you have an old device or a newer device the fastboot client
> checks
> > the "slot-count" variable. Undefined means of course that you have an
> > old-style device, but if you return something like "2" you would be able
> to
> > flash "system" on the "slot A" which is translated (again in the fastboot
> > client) to flash "system_a" partition. This is useful when using the
> higher
> > level operations like flashall/update and you want to specify to flash
> only
> > "slot A", "slot B" or even both of them. There are other fastboot
> variables
> > that require some plumbing, such as "has-slot:" to tell
> whether
> > "system" is a partition that indeed has the two versions _a and _b.
> > Typically some partitions are twice (like "system" and "boot") and some
> > other are not (like "misc" or "userdata"). Anyway, this as is should work
> > for either old-style partition schemes or by force flashing "system_a"
> with
> > the system.img.
> >
>
> Cool, thanks... that saves me a bunch of investigation!
>
> --
> Alex Kiernan
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] How to modify devicetree blob inside fit image via the u-boot shell using the fdt command

[Davis Roman]

Hello

How can I make an on the fly modification to a particular devicetree
(contained inside a fitimage blob ) via the u-boot shell using the fdt
command?

The fdt command allows for modifications in ram so I figure this should be
possible.

Thank you,

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

Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

[Tom Rini]

On Tue, Apr 24, 2018 at 09:57:58PM +0200, Maxime Ripard wrote:
> Hi Jagan,
> 
> On Fri, Apr 06, 2018 at 11:36:59AM +0530, Jagan Teki wrote:
> > On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
> >  wrote:
> > > On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
> > >> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
> > >>  wrote:
> > >> > From: Philipp Tomsich 
> > >> >
> > >> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
> > >> > read 10MB from a fast eMMC device due to excessive delays in polling
> > >> > loops.
> > >> >
> > >> > This commit restructures the main polling loops to use get_timer(...)
> > >> > to determine whether a (millisecond) timeout has expired.  We choose
> > >> > not to use the wait_bit function, as we don't need interruptability
> > >> > with ctrl-c and have at least one case where two bits (one for an
> > >> > error condition and another one for completion) need to be read and
> > >> > using wait_bit would have not added to the clarity.
> > >> >
> > >> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
> > >> > 10MB write decreases from 9.302s to 0.884s).
> > >>
> > >> Fyi: I've seen significant improvement, but not 10x on A64
> > >> (bananpi-m64) with read
> > >>
> > >> Before this change:
> > >>
> > >> => mmc dev 0
> > >> switch to partitions #0, OK
> > >> mmc0 is current device
> > >> => fatload mmc 0:1 $kernel_addr_r Image
> > >> reading Image
> > >> 16310784 bytes read in 821 ms (18.9 MiB/s)
> > >> => mmc dev 1
> > >> switch to partitions #0, OK
> > >> mmc1(part 0) is current device
> > >> => ext4load mmc 1:1 $kernel_addr_r Image
> > >> 16310784 bytes read in 1109 ms (14 MiB/s)
> > >>
> > >>
> > >> After this change:
> > >>
> > >> => mmc dev 0
> > >> switch to partitions #0, OK
> > >> mmc0 is current device
> > >> => fatload mmc 0:1 $kernel_addr_r Image
> > >> 16310784 bytes read in 784 ms (19.8 MiB/s)
> > >> => mmc dev 1
> > >> switch to partitions #0, OK
> > >> mmc1(part 0) is current device
> > >> => ext4load mmc 1:1 $kernel_addr_r Image
> > >> 16310784 bytes read in 793 ms (19.6 MiB/s)
> > >
> > > Yeah, the smaller the file is, the bigger the gain is. Since you have
> > > an almost twice bigger file, the gains are probably just noise at that
> > > point and the bottleneck starts to be your MMC.
> > 
> > Acked-by: Jagan Teki 
> 
> Jaehoon doesn't seem to reply at all, can we merge this through the
> sunxi tree?

Yes.

Reviewed-by: Tom Rini 

-- 
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] sunxi: improve throughput in the sunxi_mmc driver

[Maxime Ripard]

Hi Jagan,

On Fri, Apr 06, 2018 at 11:36:59AM +0530, Jagan Teki wrote:
> On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
>  wrote:
> > On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
> >> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
> >>  wrote:
> >> > From: Philipp Tomsich 
> >> >
> >> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
> >> > read 10MB from a fast eMMC device due to excessive delays in polling
> >> > loops.
> >> >
> >> > This commit restructures the main polling loops to use get_timer(...)
> >> > to determine whether a (millisecond) timeout has expired.  We choose
> >> > not to use the wait_bit function, as we don't need interruptability
> >> > with ctrl-c and have at least one case where two bits (one for an
> >> > error condition and another one for completion) need to be read and
> >> > using wait_bit would have not added to the clarity.
> >> >
> >> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
> >> > 10MB write decreases from 9.302s to 0.884s).
> >>
> >> Fyi: I've seen significant improvement, but not 10x on A64
> >> (bananpi-m64) with read
> >>
> >> Before this change:
> >>
> >> => mmc dev 0
> >> switch to partitions #0, OK
> >> mmc0 is current device
> >> => fatload mmc 0:1 $kernel_addr_r Image
> >> reading Image
> >> 16310784 bytes read in 821 ms (18.9 MiB/s)
> >> => mmc dev 1
> >> switch to partitions #0, OK
> >> mmc1(part 0) is current device
> >> => ext4load mmc 1:1 $kernel_addr_r Image
> >> 16310784 bytes read in 1109 ms (14 MiB/s)
> >>
> >>
> >> After this change:
> >>
> >> => mmc dev 0
> >> switch to partitions #0, OK
> >> mmc0 is current device
> >> => fatload mmc 0:1 $kernel_addr_r Image
> >> 16310784 bytes read in 784 ms (19.8 MiB/s)
> >> => mmc dev 1
> >> switch to partitions #0, OK
> >> mmc1(part 0) is current device
> >> => ext4load mmc 1:1 $kernel_addr_r Image
> >> 16310784 bytes read in 793 ms (19.6 MiB/s)
> >
> > Yeah, the smaller the file is, the bigger the gain is. Since you have
> > an almost twice bigger file, the gains are probably just noise at that
> > point and the bottleneck starts to be your MMC.
> 
> Acked-by: Jagan Teki 

Jaehoon doesn't seem to reply at all, can we merge this through the
sunxi tree?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] zynqmp: Add generic target

[Alexander Graf]

I would like to create a generic U-Boot build that adapts itself completely
based on the DT passed in. That way we can potentially support running
random board configurations with a single U-Boot binary built as part of
the distribution.

Currently a few things are still missing to make it a full reality. The
most obvious one I think is the EEPROM location. This would need to also
move into something described by DT.

Apart from that, we're almost there. This patch adds a defconfig that simply
contains all drivers we could make use of. We can then enable individual
boards along the way and slowly adapt everything to be fully DT described
while we identify each missing bit.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - Remove debug uart
---
 configs/xilinx_zynqmp_generic_defconfig | 96 +
 include/configs/xilinx_zynqmp_generic.h | 23 
 2 files changed, 119 insertions(+)
 create mode 100644 configs/xilinx_zynqmp_generic_defconfig
 create mode 100644 include/configs/xilinx_zynqmp_generic.h

diff --git a/configs/xilinx_zynqmp_generic_defconfig 
b/configs/xilinx_zynqmp_generic_defconfig
new file mode 100644
index 00..d534866d23
--- /dev/null
+++ b/configs/xilinx_zynqmp_generic_defconfig
@@ -0,0 +1,96 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_generic"
+CONFIG_ARCH_ZYNQMP=y
+CONFIG_SYS_TEXT_BASE=0x800
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_IDENT_STRING=" Xilinx ZynqMP based platform"
+CONFIG_DEFAULT_DEVICE_TREE="zynqmp-mini-emmc"
+CONFIG_ZYNQMP_USB=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_ATF=y
+CONFIG_SYS_PROMPT="ZynqMP> "
+CONFIG_FASTBOOT=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_CMD_THOR_DOWNLOAD=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_SYS_ALT_MEMTEST=y
+CONFIG_CMD_CLK=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_FPGA_LOADBP=y
+CONFIG_CMD_FPGA_LOADP=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_BOARD=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SCSI_AHCI=y
+CONFIG_SATA_CEVA=y
+CONFIG_CLK_ZYNQMP=y
+CONFIG_DFU_RAM=y
+CONFIG_FPGA_XILINX=y
+CONFIG_FPGA_ZYNQMPPL=y
+CONFIG_DM_GPIO=y
+CONFIG_CMD_PCA953X=y
+CONFIG_SYS_I2C_ZYNQ=y
+CONFIG_ZYNQ_I2C0=y
+CONFIG_ZYNQ_I2C1=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_NATSEMI=y
+CONFIG_PHY_REALTEK=y
+CONFIG_PHY_TI=y
+CONFIG_PHY_VITESSE=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_ZYNQ_GEM=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
+CONFIG_ZYNQ_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_XHCI_ZYNQMP=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_ULPI_VIEWPORT=y
+CONFIG_USB_ULPI=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Xilinx"
+CONFIG_USB_GADGET_VENDOR_NUM=0x03FD
+CONFIG_USB_GADGET_PRODUCT_NUM=0x0300
+CONFIG_USB_FUNCTION_THOR=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/include/configs/xilinx_zynqmp_generic.h 
b/include/configs/xilinx_zynqmp_generic.h
new file mode 100644
index 00..56bd5bd6f1
--- /dev/null
+++ b/include/configs/xilinx_zynqmp_generic.h
@@ -0,0 +1,23 @@
+/*
+ * Configuration for the Xilinx ZynqMP generic platform
+ *
+ * (C) Copyright 2018 Alexander Graf 
+ * (C) Copyright 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_ZYNQMP_GENERIC_H
+#define __CONFIG_ZYNQMP_GENERIC_H
+
+/* All of these should be enumerated using DT instead ... */
+
+#define CONFIG_ZYNQ_SDHCI0
+#define CONFIG_ZYNQ_SDHCI1
+
+#define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR}
+
+#include 
+
+#endif /* __CONFIG_ZYNQMP_GENERIC_H */
-- 
2.12.3

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

[U-Boot] [PATCH] zynqmp: Add generic target

[Alexander Graf]

I would like to create a generic U-Boot build that adapts itself completely
based on the DT passed in. That way we can potentially support running
random board configurations with a single U-Boot binary built as part of
the distribution.

Currently a few things are still missing to make it a full reality. The
most obvious one I think is the EEPROM location. This would need to also
move into something described by DT.

Apart from that, we're almost there. This patch adds a defconfig that simply
contains all drivers we could make use of. We can then enable individual
boards along the way and slowly adapt everything to be fully DT described
while we identify each missing bit.

Signed-off-by: Alexander Graf 
---
 configs/xilinx_zynqmp_generic_defconfig | 97 +
 include/configs/xilinx_zynqmp_generic.h | 23 
 2 files changed, 120 insertions(+)
 create mode 100644 configs/xilinx_zynqmp_generic_defconfig
 create mode 100644 include/configs/xilinx_zynqmp_generic.h

diff --git a/configs/xilinx_zynqmp_generic_defconfig 
b/configs/xilinx_zynqmp_generic_defconfig
new file mode 100644
index 00..afbf6ad0af
--- /dev/null
+++ b/configs/xilinx_zynqmp_generic_defconfig
@@ -0,0 +1,97 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_generic"
+CONFIG_ARCH_ZYNQMP=y
+CONFIG_SYS_TEXT_BASE=0x800
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_IDENT_STRING=" Xilinx ZynqMP based platform"
+CONFIG_DEFAULT_DEVICE_TREE="zynqmp-mini-emmc"
+CONFIG_ZYNQMP_USB=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_ATF=y
+CONFIG_SYS_PROMPT="ZynqMP> "
+CONFIG_FASTBOOT=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_CMD_THOR_DOWNLOAD=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_SYS_ALT_MEMTEST=y
+CONFIG_CMD_CLK=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_FPGA_LOADBP=y
+CONFIG_CMD_FPGA_LOADP=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_BOARD=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SCSI_AHCI=y
+CONFIG_SATA_CEVA=y
+CONFIG_CLK_ZYNQMP=y
+CONFIG_DFU_RAM=y
+CONFIG_FPGA_XILINX=y
+CONFIG_FPGA_ZYNQMPPL=y
+CONFIG_DM_GPIO=y
+CONFIG_CMD_PCA953X=y
+CONFIG_SYS_I2C_ZYNQ=y
+CONFIG_ZYNQ_I2C0=y
+CONFIG_ZYNQ_I2C1=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_NATSEMI=y
+CONFIG_PHY_REALTEK=y
+CONFIG_PHY_TI=y
+CONFIG_PHY_VITESSE=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_ZYNQ_GEM=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
+CONFIG_ZYNQ_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_XHCI_ZYNQMP=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_ULPI_VIEWPORT=y
+CONFIG_USB_ULPI=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Xilinx"
+CONFIG_USB_GADGET_VENDOR_NUM=0x03FD
+CONFIG_USB_GADGET_PRODUCT_NUM=0x0300
+CONFIG_USB_FUNCTION_THOR=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/include/configs/xilinx_zynqmp_generic.h 
b/include/configs/xilinx_zynqmp_generic.h
new file mode 100644
index 00..56bd5bd6f1
--- /dev/null
+++ b/include/configs/xilinx_zynqmp_generic.h
@@ -0,0 +1,23 @@
+/*
+ * Configuration for the Xilinx ZynqMP generic platform
+ *
+ * (C) Copyright 2018 Alexander Graf 
+ * (C) Copyright 2015 Xilinx, Inc.
+ * Michal Simek 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_ZYNQMP_GENERIC_H
+#define __CONFIG_ZYNQMP_GENERIC_H
+
+/* All of these should be enumerated using DT instead ... */
+
+#define CONFIG_ZYNQ_SDHCI0
+#define CONFIG_ZYNQ_SDHCI1
+
+#define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR}
+
+#include 
+
+#endif /* __CONFIG_ZYNQMP_GENERIC_H */
-- 
2.12.3

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

Re: [U-Boot] [PATCH v3 4/5] sunxi: R40: add gigabit ethernet devicetree node

[Maxime Ripard]

Hi,

On Mon, Apr 23, 2018 at 04:57:19PM +0200, Lothar Felten wrote:
> Add a device tree node for the Allwinner R40/V40 GMAC gigabit
> ethernet interface.
> The R40 SoC does not use the syscon register for GMAC settings.
> 
> Signed-off-by: Lothar Felten 
> ---
>  arch/arm/dts/sun8i-r40.dtsi | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
> index ee22f6eb3a..b46fcbb0b9 100644
> --- a/arch/arm/dts/sun8i-r40.dtsi
> +++ b/arch/arm/dts/sun8i-r40.dtsi
> @@ -168,6 +168,27 @@
>   #size-cells = <0>;
>   };
>  
> + gmac: ethernet@01c5 {
> + compatible = "allwinner,sun8i-r40-gmac";
> + reg = <0x01c5 0x2000>;
> + interrupts = ;
> + interrupt-names = "macirq";
> + clocks = <>, <>;
> + clock-names = "stmmaceth", "allwinner_gmac_tx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_rgmii>;
> + phy-mode = "rgmii";

If that's going to be overwritten in the DTS, maybe we should just
drop it from the DTSI.

The rest of the serie looks good to me, however, it is a best practice
to have a changelog either in the cover letter (if you have one) or in
the patches themselves so that reviewer know what changed between the
two versions.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-video/master

[Anatolij Gustschin]

Hi Tom,

The following changes since commit 5bc0543df3079add8152afa041b887d081d71839:

  treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08 18:31:09 
-0400)

are available in the git repository at:

  git://git.denx.de/u-boot-video.git master

for you to fetch changes up to 751641814c1db245695dd8f40e9c811320e69f79:

  video-uclass: Fix logical-not-parentheses warning (2018-04-24 20:57:14 +0200)


Fabio Estevam (1):
  treewide: fix up files incorrectly marked executable

Tom Rini (1):
  video-uclass: Fix logical-not-parentheses warning

 drivers/video/anx9804.c  | 0
 drivers/video/video-uclass.c | 2 +-
 include/configs/blanche.h| 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 mode change 100755 => 100644 drivers/video/anx9804.c
 mode change 100755 => 100644 include/configs/blanche.h

Please pull. Thanks!

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

Re: [U-Boot] [PATCH] video-uclass: Fix logical-not-parentheses warning

[Anatolij Gustschin]

On Sun, 22 Apr 2018 09:47:48 -0400
Tom Rini tr...@konsulko.com wrote:

> With clang-4.0 and later we see:
> warning: logical not is only applied to the left hand side of this bitwise
> operator [-Wlogical-not-parentheses]
> if ((!gd->flags & GD_FLG_RELOC))
>  ^  ~
> 
> And while the compiler suggests adding parenthesis around gd->flags, a
> reading of the code says that we want to know when GD_FLG_RELOC is not
> set and then return.
> 
> Cc: Simon Glass 
> Cc: Anatolij Gustschin 
> Signed-off-by: Tom Rini 
> ---
>  drivers/video/video-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-video/master, thanks!

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

[U-Boot] [PATCH v4 04/18] warp7: hab: Set environment variable indicating HAB enable

[Bryan O'Donoghue]

This patch adds an environment variable called "hab_enabled" which gets set
to a boolean status indicating whether HAB is enabled or not.

Subsequent patches can use this environment variable to determine if its
necessary to run a given binary through the hab_auth_img console command.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/warp7.c | 8 
 include/configs/warp7.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 327f656c44..0d3d324571 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,6 +204,13 @@ int board_late_init(void)
 */
clrsetbits_le16(>wcr, 0, 0x10);
 
+#ifdef CONFIG_SECURE_BOOT
+   /* Determine HAB state */
+   env_set_ulong(HAB_ENABLED_ENVNAME, imx_hab_is_enabled());
+#else
+   env_set_ulong(HAB_ENABLED_ENVNAME, 0);
+#endif
+
 #ifdef CONFIG_SERIAL_TAG
/* Set serial# standard environment variable based on OTP settings */
get_board_serial();
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 0c3b605de3..c6ab29a831 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -139,4 +139,7 @@
 
 #define CONFIG_USBNET_DEV_ADDR "de:ad:be:af:00:01"
 
+/* Environment variable name to represent HAB enable state */
+#define HAB_ENABLED_ENVNAME"hab_enabled"
+
 #endif
-- 
2.17.0

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

[U-Boot] [PATCH v4 13/18] warp7: select uuid partition based on rootpart

[Bryan O'Donoghue]

Assigning the UUID discovery path to a tweakable environment variable means
that later steps in the boot process - particularly a boot script can
change the target root partition of a particular Linux boot.

Retargeting the rootfs is an important feature when doing ping/pong
upgrades allowing a boot script to select ping or pong as necessary without
reprogramming the bootloader.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/configs/warp7.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index a92e6758bf..f2ee09b831 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -45,7 +45,8 @@
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
-   "finduuid=part uuid mmc 0:2 uuid\0" \
+   "rootpart=" __stringify(CONFIG_WARP7_ROOT_PART) "\0" \
+   "finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"loadbootscript=" \
-- 
2.17.0

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

[U-Boot] [PATCH v4 17/18] warp7: defconfig: Enable CMD_SETEXPR

[Bryan O'Donoghue]

setexpr allows us to do arithmetic for env variables - something that is
both useful and required when doing HAB authentication without hard-coding
HAB load addresses.

This patch enables CMD_SETEXPR for the WaRP7 defconfig.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 configs/warp7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index b72c2262dd..b936f4aab1 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -21,7 +21,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_SETEXPR=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 14/18] warp7: Define the name of a signed boot-script file

[Bryan O'Donoghue]

We need to know the name of a signed boot-script, its better to have a
separate variable for this then to simply append some fixed string to an
existing image name.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index f2ee09b831..53fbcb2f4a 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -33,6 +33,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_DFU_ENV_SETTINGS \
"script=boot.scr\0" \
+   "script_signed=boot.scr.imx-signed\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
-- 
2.17.0

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

[U-Boot] [PATCH v4 02/18] imximage: Specify default IVT offset in IMX image

[Bryan O'Donoghue]

This patch adds BOOTROM_IVT_HDR_OFFSET at 0xC00. The BootROM expects to
find the IVT header at a particular offset in an i.MX image.

Defining the expected offset of the IVT header in the first-stage BootROM
image format is of use of later stage authentication routines where those
routines continue to follow the first-stage authentication layout.

This patch defines the first stage offset which later patch make use of.

Signed-off-by: Bryan O'Donoghue 
Cc: Utkarsh Gupta 
Cc: Breno Lima 
Cc: Fabio Estevam 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/imximage.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/imximage.h b/include/imximage.h
index 553b852367..800fd6383b 100644
--- a/include/imximage.h
+++ b/include/imximage.h
@@ -14,6 +14,9 @@
 #define APP_CODE_BARKER0xB1
 #define DCD_BARKER 0xB17219E9
 
+/* Specify the offset of the IVT in the IMX header as expected by BootROM */
+#define BOOTROM_IVT_HDR_OFFSET 0xC00
+
 /*
  * NOTE: This file must be kept in sync with arch/arm/include/asm/\
  *   mach-imx/imximage.cfg because tools/imximage.c can not
-- 
2.17.0

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

[U-Boot] [PATCH v4 00/18] warp7: Enable automated OPTEE/HAB boot flow

[Bryan O'Donoghue]

This tree here is pullable

http://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod-nouart

v4:

- Add Tested-by and Reviewed-by from Fabio and Breno as indicated.
  Thanks very much guys for taking the time to do that :)

- Adds patch tools/imximage: Fix fruity lack of 0x prefix in DCD Blocks
  Previously sent this patch.
  Reviewed-by Fabio added for completeness.

v3:
- Reword commit message of patch #16 - Breno

- This patchset now relies on five in-flight patch-sets the first four of
  which should be applied first
 
1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
   Already has a Reviewed-by from Fabio

2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
   Has a Reviewed-by: from Breno

3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs

4. Pierre-Jean's generic load patches

   [U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
   in CONFIG_EXTRA_ENV_SETTINGS

   [U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC

5. [PATCH] bootm: Align cache flush begin address
   This last patch can be applied in any order

v2:
- Ensure warp7_defconfig boots existing yocto with this change plus the
  automated HAB layer being added here following on from "[PATCH v3 0/2]
  WaRP7 unify secure and non-secure defconfigs"

- Fix reference to partition #1 versus partition #2 in select uuidpart
  patch

- Rebase on top of Pierre-Jean Texier generic load patches

- Drop my patch which did the same thing as Pierre-Jean's patch via
  ${loadcmd}

- Update example boot.scr from v1 to reflect use of generic 'load' command

- This patchset now relies on four in-flight patch-sets which all have the
  relevant Reviewed-by tags from the board Maintainer Fabio.
 
1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
   Already has a Reviewed-by from Fabio

2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
   Has a Reviewed-by: from Breno

3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs

4. Pierre-Jean's generic load patches

   [U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
   in CONFIG_EXTRA_ENV_SETTINGS

   [U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC
 
v1:
This series enables an automated HAB verified secure boot which chain-loads
via OPTEE see `git show 5cf3251..c225e7c` for details.

This set depends on three in-flight patchsets

1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
   Already has a Reviewed-by from Fabio

2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
   Has a Reviewed-by: from Breno

3. [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree

I'm trying not to make this cover email too long. So - once this set is
applied it is possible to boot from the BootROM using HAB to verify

- u-boot
- boot.scr
- Kernel
- DTB

Chainload via OPTEE and boot up to Linux. If there is a HAB failure at any
stage of the process we force-drop down to the USB HID failover mode, from
which we can send up a recovery image to unblock.

I've run the WaRP7 default u-boot and this new version on NXP's reference
yocto image and verified that that yocto image boots with both versions of
the WaRP7 -> warp7_defconfig and warp7_secure_defconfig.

http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland

In addition the modifications targeting warp7_secure_defconfig mean it is
possible to chain-load via OPTEE using scripted HAB to verify images prior
to exiting the u-boot domain.

Here is an example of the scripting we are doing which shows further reuse
of shell functions introduced in previous patches.

 Example secure-boot boot.scr.imx-signed 

# This section is responsbile for loading a signed Linux kernel
setenv image_signed zImage.imx-signed
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}
load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${image_signed}
run warp7_auth_or_fail
else
run loadimage;
fi

# This section is responsbile for loading a signed FDT image
setenv fdt_file_signed imx7s-warp.dtb.imx-signed
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${fdt_addr} - ${ivt_offset}
load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${fdt_file_signed}
run warp7_auth_or_fail
else
run loadfdt;
fi

# Boot from rootfs1 by default
setenv mmcpart 3

# But if the rootfs2 file exists in partition 2, boot from rootfs2
ext4size mmc 0:2 rootfs2 && setenv mmcpart 5

# This section is responsbile for loading a signed OPTEE image
setenv optee_file /lib/firmware/uTee.optee
setenv optee_file_signed /lib/firmware/uTee.optee.imx-signed
setenv loadoptee "load mmc ${mmcdev}:${mmcpart} ${optee_addr}
${optee_file}"
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${optee_addr} - 

[U-Boot] [PATCH v4 18/18] warp7: Add support for automated secure boot.scr verification

[Bryan O'Donoghue]

This patch adds support for verifying a signed boot.scr. With this in place
it's possible for run-time Linux to update boot.scr to set different
variables such as switching between different boot partitions, pointing to
different kernels etc and for u-boot to verify these changes via the HAB
prior to executing the commands contained in boot.scr.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/configs/warp7.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 3b1e7c7e88..c9be70ca2a 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -53,6 +53,14 @@
"root=PARTUUID=${uuid} rootwait rw\0" \
"ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
+   "do_bootscript_hab=" \
+   "if test ${hab_enabled} -eq 1; then " \
+   "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+   "setenv script ${script_signed}; " \
+   "load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} 
${script}; " \
+   "run warp7_auth_or_fail; " \
+   "run bootscript; "\
+   "fi;\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
@@ -79,6 +87,7 @@
 #define CONFIG_BOOTCOMMAND \
   "mmc dev ${mmcdev};" \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
+  "run do_bootscript_hab;" \
   "if run loadbootscript; then " \
   "run bootscript; " \
   "else " \
-- 
2.17.0

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

[U-Boot] [PATCH v4 11/18] warp7: Make CONFIG_SYS_FDT_ADDR a define

[Bryan O'Donoghue]

In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Ryan Harkin 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/Kconfig | 6 ++
 include/configs/warp7.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 61c33fb53e..00df19d47f 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,4 +6,10 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config SYS_FDT_ADDR
+   hex "FDT load address"
+   default 0x8300
+   help
+ The address the FDT file should be loaded to.
+
 endif
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 9ae2ca4a53..a92e6758bf 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -39,7 +39,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
-   "fdt_addr=0x8300\0" \
+   "fdt_addr=" __stringify(CONFIG_SYS_FDT_ADDR)"\0" \
"optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
-- 
2.17.0

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

[U-Boot] [PATCH v4 08/18] warp7: Specify CONFIG_OPTEE_LOAD_ADDR

[Bryan O'Donoghue]

In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.

This patch makes the OPTEE_LOAD_ADDR available via u-boot.cfg for further
parsing by external tools.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Ryan Harkin 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 configs/warp7_defconfig | 1 +
 include/configs/warp7.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 75a141b8b9..f79c019d0c 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -46,3 +46,4 @@ CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE=y
+CONFIG_OPTEE_LOAD_ADDR=0x8400
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index c6ab29a831..9ae2ca4a53 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -40,6 +40,7 @@
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
"fdt_addr=0x8300\0" \
+   "optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
-- 
2.17.0

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

[U-Boot] [PATCH v4 01/18] tools/imximage: Fix fruity lack of 0x prefix in DCD Blocks

[Bryan O'Donoghue]

commit 8519c9c98ad6 ("tools/imximage: use 0x prefix in HAB Blocks line")
adds an 0x prefix to each HAB Block number to make it easier for host tools
to process the HAB Block output, however it neglects to apply the same
prefix to the DCD Blocks directive. You need the DCD Blocks directive if
you are making a u-boot recovery image which the BootROM will accept via
the USB upload utility.

This disparity results in a fruity output like this with HAB Blocks
prefixed but DCD Blocks not prefixed - which is pretty inconsistent.

This patch fixes the difference assuming the original commit was a
legitimate change.

Old:
Image Type:   Freescale IMX Boot Image
Image Ver:2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size:430080 Bytes = 420.00 KiB = 0.41 MiB
Load Address: 877ff420
Entry Point:  8780
HAB Blocks:   0x877ff400 0x 0x00066c00
DCD Blocks:   0091 002c 01d4

New:
Image Type:   Freescale IMX Boot Image
Image Ver:2 (i.MX53/6/7 compatible)
Mode: DCD
Data Size:430080 Bytes = 420.00 KiB = 0.41 MiB
Load Address: 877ff420
Entry Point:  8780
HAB Blocks:   0x877ff400 0x 0x00066c00
DCD Blocks:   0x0091 0x002c 0x01d4

Signed-off-by: Bryan O'Donoghue 
Cc: Rasmus Villemoes 
Cc: Fabio Estevam 
Cc: Breno Lima 
Cc: Stefano Babic 
Reviewed-by: Fabio Estevam 
---
 tools/imximage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/imximage.c b/tools/imximage.c
index 6dabb13520..6f16d45351 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -520,7 +520,7 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
   (uint32_t)fhdr_v2->self, 0,
   hdr_v2->boot_data.size - imximage_ivt_offset -
   imximage_csf_size);
-   printf("DCD Blocks:   0091 %08x %08x\n",
+   printf("DCD Blocks:   0x0091 0x%08x 0x%08x\n",
   offs, be16_to_cpu(dcdlen));
}
} else {
-- 
2.17.0

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

[U-Boot] [PATCH v4 07/18] warp7: Print out the OPTEE DRAM region

[Bryan O'Donoghue]

Right now a region of 0x30 bytes is allocated at the end of DRAM for
the purposes of loading an OPTEE firmware inside of it. This patch adds the
printout of the relevant address ranges.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/warp7.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 56f0cdd175..da52b183bd 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -181,7 +181,17 @@ int checkboard(void)
else
mode = "non-secure";
 
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   unsigned long optee_start, optee_end;
+
+   optee_end = PHYS_SDRAM + PHYS_SDRAM_SIZE;
+   optee_start = optee_end - CONFIG_OPTEE_TZDRAM_SIZE;
+
+   printf("Board: WARP7 in %s mode OPTEE DRAM 0x%08lx-0x%08lx\n",
+  mode, optee_start, optee_end);
+#else
printf("Board: WARP7 in %s mode\n", mode);
+#endif
 
return 0;
 }
-- 
2.17.0

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

[U-Boot] [PATCH v4 15/18] warp7: add warp7_auth_or_fail

[Bryan O'Donoghue]

Doing secure boot on the WaRP7 using a common image format and the same
variable to represent the base address for each call means we can reduce
down the command to a single environment command.

This patch adds warp7_auth_or_fail as a wrapper around
"hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0".

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 53fbcb2f4a..c957b2d579 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
-- 
2.17.0

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

[U-Boot] [PATCH v4 09/18] warp7: defconfig: Enable CONFIG_SECURE_BOOT

[Bryan O'Donoghue]

Various function associated with booting the WaRP7 in High Assurance Boot
(HAB) mode are enabled by switching on CONFIG_SECURE_BOOT.

This patch enables CONFIG_SECURE_BOOT for the WaRP7 defconfig.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index f79c019d0c..e251acce04 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
+CONFIG_SECURE_BOOT=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
 CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 16/18] warp7: hab: Set environment variable indicating IVT offset

[Bryan O'Donoghue]

This patch introduces the environment variable ivt_offset. When we define a
load address for Linux or DTB or any file the IVT associated with that file
is prepended. We extract the actual load addresses from u-boot.cfg and feed
these values into the code-signing process - hence we want u-boot to have
the real load addresses exported in uboot.cfg.

ivt_offset represents the addition or subtraction from the load address
that must happen to find an IVT header.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 include/configs/warp7.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index c957b2d579..3b1e7c7e88 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -10,6 +10,7 @@
 #define __WARP7_CONFIG_H
 
 #include "mx7_common.h"
+#include 
 
 #define PHYS_SDRAM_SIZESZ_512M
 
@@ -50,6 +51,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-- 
2.17.0

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

[U-Boot] [PATCH v4 10/18] warp7: defconfig: Enable CONFIG_BOOTM_TEE

[Bryan O'Donoghue]

This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to
chain-load Linux through OPTEE.

Loading kernel to 0x8080
=> run loadimage

Load FDT to 0x8300
=> run loadfdt

Load OPTEE to 0x8400
=> fatload mmc 0:5 0x8400 /lib/firmware/uTee.optee

Then chain-load to the kernel via OPTEE

=> bootm 0x8400 - 0x8300

   Image Name:
   Image Type:   ARM Trusted Execution Environment Kernel Image (uncompressed)
   Data Size:249844 Bytes = 244 KiB
   Load Address: 9de4
   Entry Point:  9e00
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index e251acce04..b72c2262dd 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -48,3 +48,4 @@ CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE=y
 CONFIG_OPTEE_LOAD_ADDR=0x8400
+CONFIG_BOOTM_OPTEE=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 05/18] warp7: defconfig: Enable OPTEE for WaRP7

[Bryan O'Donoghue]

Requires setting CONFIG_OPTEE=y and setting an OPTEE TrustZone DRAM base in
include/configs/warp7.h.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 73f3f09dc1..75a141b8b9 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -45,3 +45,4 @@ CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
+CONFIG_OPTEE=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 12/18] warp7: Add Kconfig WARP7_ROOT_PART

[Bryan O'Donoghue]

Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition
is use as the root partition on WaRP7, this is a desirable change in order
to support a different partitioning schemes. The default is the current
partition #2.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 00df19d47f..c089bca2ba 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,6 +6,14 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config WARP7_ROOT_PART
+   int "Partition number to use for root filesystem"
+   default 2
+   help
+ The partition number to use for root filesystem this is the
+ partition that is typically specified with root=/dev/sdaX or
+ which gets converted into a root=PARTUUID=some_uuid.
+
 config SYS_FDT_ADDR
hex "FDT load address"
default 0x8300
-- 
2.17.0

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

[U-Boot] [PATCH v4 03/18] warp7: hab: Add a CSF location definition

[Bryan O'Donoghue]

In order to correctly produce an image with a IVT/DCD header we need to
define a CSF in imximage.cfg. We just use the mx7 default here.

All we have to do with this option switched on is "make u-boot.imx" and we
then will get

- u-boot.imx
- u-boot.imx.log

The log file is really important because it gives the addresses for the HAB
that we will require to sign the u-boot image using the CST. Since the
addresses can change this logfile is a critical output.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/imximage.cfg | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/warp7/imximage.cfg b/board/warp7/imximage.cfg
index 5b42793786..51a5bff723 100644
--- a/board/warp7/imximage.cfg
+++ b/board/warp7/imximage.cfg
@@ -13,6 +13,10 @@
 #include 
 
 IMAGE_VERSION  2
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
 BOOT_FROM  sd
 
 /*
-- 
2.17.0

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

[U-Boot] [PATCH v4 06/18] warp7: Allocate specific region of memory to OPTEE

[Bryan O'Donoghue]

Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size.

On WaRP7 we simply define the OPTEE region as from the maximum DRAM address
minus CONFIG_OPTEE_TZDRAM_SIZE bytes.

Note the OPTEE boot process will itself subtract the DRAM region it lives
in from the memory map passed to Linux.

Signed-off-by: Bryan O'Donoghue 
Tested-by: Breno Lima 
Reviewed-by: Fabio Estevam 
---
 board/warp7/warp7.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 0d3d324571..56f0cdd175 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -58,6 +58,11 @@ int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
 
+   /* Subtract the defined OPTEE runtime firmware length */
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
 }
 
-- 
2.17.0

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

[U-Boot] [PATCH v5 1/3] warp7: defconfig: Fix CAAM on boot with tip-of-tree

[Bryan O'Donoghue]

Booting the following image with tip-of-tree we get a CAAM DECO error (and
subsequent crash due to a kernel bug in 4.1).

http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland

Image: fsl-image-multimedia-imx7s-warp-20180323-90.rootfs.sdcard

Error:
caam 3090.caam: Entropy delay = 3200
caam 3090.caam: failed to acquire DECO 0

caam 3090.caam: failed to acquire DECO 0
caam 3090.caam: Entropy delay = 12400
caam 3090.caam: failed to acquire DECO 0
caam 3090.caam: failed to instantiate RNG
[ cut here ]
WARNING: CPU: 0 PID: 1 at
/home/jenkins/workspace/fsl-community-bsp-pyro_xwayland_2/build/tmp/work-shared/imx7s-warp/kernel-source/mm/vmalloc.c:1465
caam_remove+0x6)
Trying to vfree() nonexistent vm area (88047000)
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.1.36-4.1-1.0.x-imx-warp7+ga543d1b #1
Hardware name: Freescale i.MX7 Dual (Device Tree)
[<80015d54>] (unwind_backtrace) from [<80012688>] (show_stack+0x10/0x14)
[<80012688>] (show_stack) from [<8076e810>] (dump_stack+0x78/0x8c)
[<8076e810>] (dump_stack) from [<800346a0>]
(warn_slowpath_common+0x80/0xb0)
[<800346a0>] (warn_slowpath_common) from [<80034700>]
(warn_slowpath_fmt+0x30/0x40)
[<80034700>] (warn_slowpath_fmt) from [<8054c278>] (caam_remove+0x6c/0x3f4)
[<8054c278>] (caam_remove) from [<8054ce74>] (caam_probe+0x874/0xfa8)
[<8054ce74>] (caam_probe) from [<80382a7c>] (platform_drv_probe+0x48/0xa4)
[<80382a7c>] (platform_drv_probe) from [<80381328>]
(driver_probe_device+0x174/0x2a8)
[<80381328>] (driver_probe_device) from [<8038152c>]
(__driver_attach+0x8c/0x90)
[<8038152c>] (__driver_attach) from [<8037f9d4>]
(bus_for_each_dev+0x68/0x9c)
[<8037f9d4>] (bus_for_each_dev) from [<80380a68>]
(bus_add_driver+0xf4/0x1e8)
[<80380a68>] (bus_add_driver) from [<80381b38>] (driver_register+0x78/0xf4)
[<80381b38>] (driver_register) from [<80009738>]
(do_one_initcall+0x8c/0x1d0)
[<80009738>] (do_one_initcall) from [<80a66dac>]
(kernel_init_freeable+0x140/0x1d0)
[<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
(kernel_init+0x8/0xe8)
[<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
---[ end trace d5f941204ed8cb28 ]---
caam: probe of 3090.caam failed with error -11
Unable to handle kernel NULL pointer dereference at virtual address
0004
pgd = 80004000
[0004] *pgd=
Internal error: Oops: 805 [#1] PREEMPT SMP ARM

[<8055cdf8>] (caam_sm_startup) from [<80aa83c8>] (caam_sm_init+0x50/0x58)
[<80aa83c8>] (caam_sm_init) from [<80009738>] (do_one_initcall+0x8c/0x1d0)
[<80009738>] (do_one_initcall) from [<80a66dac>]
(kernel_init_freeable+0x140/0x1d0)
[<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
(kernel_init+0x8/0xe8)
[<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
Code: e59d300c e2832010 e5843008 e5834068 (e58a2004)
---[ end trace d5f941204ed8cb29 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

Fix: Enable the CAAM correctly by setting CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
in the upstream defconfig.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Breno Lima 
Reviewed-by: Fabio Estevam 
Tested-by: Breno Lima 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 3901a2741b..540dafd120 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
+CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
 # CONFIG_ARMV7_VIRT is not set
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
-- 
2.17.0

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

[U-Boot] [PATCH v5 3/3] warp7: configs: enable CONFIG_CMD_FS_GENERIC

[Bryan O'Donoghue]

From: Pierre-Jean TEXIER 

This enable generic file system commands (load, ls).

Signed-off-by: Pierre-Jean TEXIER 
Acked-by: Bryan O'Donoghue 
Reviewed-by: Fabio Estevam 
Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 540dafd120..73f3f09dc1 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -27,6 +27,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
 CONFIG_FSL_ESDHC=y
-- 
2.17.0

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

[U-Boot] [PATCH v5 2/3] warp7: secure_defconfig: Remove secure_defconfig

[Bryan O'Donoghue]

This patch removes warp7_secure_defconfig. A previous patch set
CONFIG_ARMV7_BOOT_SEC_DEFAULT=y on the unsecure WaRP7 config. Fabio asked
if I could confirm that the NXP and upstream kernels will boot on the WaRP7
with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. I can confirm that this is the case,
so there's no need to support the secure defconfig - drop it now.

Signed-off-by: Bryan O'Donoghue 
Suggested-by: Fabio Estevam 
Reviewed-by: Fabio Estevam 
---
 board/warp7/MAINTAINERS|  1 -
 configs/warp7_secure_defconfig | 43 --
 2 files changed, 44 deletions(-)
 delete mode 100644 configs/warp7_secure_defconfig

diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
index 0fc9746606..1d3ee29222 100644
--- a/board/warp7/MAINTAINERS
+++ b/board/warp7/MAINTAINERS
@@ -4,4 +4,3 @@ S:  Maintained
 F: board/warp7/
 F: include/configs/warp7.h
 F: configs/warp7_defconfig
-F: configs/warp7_secure_defconfig
diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
deleted file mode 100644
index 915f2185c9..00
--- a/configs/warp7_secure_defconfig
+++ /dev/null
@@ -1,43 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_MX7=y
-CONFIG_SYS_TEXT_BASE=0x8780
-CONFIG_TARGET_WARP7=y
-CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
-# CONFIG_ARMV7_VIRT is not set
-CONFIG_IMX_RDC=y
-CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp7/imximage.cfg"
-CONFIG_HUSH_PARSER=y
-# CONFIG_CMD_BOOTD is not set
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMI is not set
-# CONFIG_CMD_XIMG is not set
-CONFIG_CMD_MEMTEST=y
-CONFIG_CMD_DFU=y
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_PART=y
-CONFIG_CMD_USB=y
-CONFIG_CMD_USB_MASS_STORAGE=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_DFU_MMC=y
-CONFIG_FSL_ESDHC=y
-CONFIG_USB=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_MXC_USB_OTG_HACTIVE=y
-CONFIG_USB_GADGET=y
-CONFIG_USB_GADGET_MANUFACTURER="FSL"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
-CONFIG_CI_UDC=y
-CONFIG_USB_GADGET_DOWNLOAD=y
-CONFIG_USB_ETHER=y
-CONFIG_USB_ETH_CDC=y
-CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
-CONFIG_OF_LIBFDT=y
-- 
2.17.0

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

[U-Boot] [PATCH v5 0/3] WaRP7 unify secure and non-secure defconfigs

[Bryan O'Donoghue]

This tree here is pullable

http://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod-nouart

v5:
- Fixes broken merge conflict missed in last patch resend

V4:
- Adds Tested-by/Reviewed-by from Beno and Fabio as indicated
  for my patches

- Resends Pierre-Jean's patch
  Since my parallel patchset relies on this patch I'm sending it again with
  my own series to make sure it doesn't get lost.
  To Pierre-Jean's patch I've added
  - Reviewed-by as Fabio indicated
  - Signed-off-by from me too

V3:
- Remove warp7_secure_defconfig from board/warp7/MAINTAINERS
- Add RB-tag from Fabio as indicated

V2:
Maintaining a secure and non-secure defconfig is a PITA. Having discussed
an observed bug with the non-secure boot-path with Fabio and undertaken to
ensure both upstream and NXP BSP kernels would work - this patchset does
two things.

1. Switches on CONFIG_ARMV7_BOOT_SEC_DEFAULT for warp7_defconfig
2. Removes warp7_secure_defconfig in its entirety

I have an upcoming set of patches that uses the secure defconfig which I've
already verified can simply be merged into mainline WaRP7 as-is so, in this
context there appears to be no justification for keeping separate
configuration files.

Fix the bug and zap the fat !

Bryan O'Donoghue (2):
  warp7: defconfig: Fix CAAM on boot with tip-of-tree
  warp7: secure_defconfig: Remove secure_defconfig

Pierre-Jean TEXIER (1):
  warp7: configs: enable CONFIG_CMD_FS_GENERIC

 board/warp7/MAINTAINERS|  1 -
 configs/warp7_defconfig|  2 ++
 configs/warp7_secure_defconfig | 43 --
 3 files changed, 2 insertions(+), 44 deletions(-)
 delete mode 100644 configs/warp7_secure_defconfig

-- 
2.17.0

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

Re: [U-Boot] [PATCH v4 2/3] warp7: secure_defconfig: Remove secure_defconfig

[Bryan O'Donoghue]

On 24/04/18 18:37, Fabio Estevam wrote:

Hi Bryan,

On Tue, Apr 24, 2018 at 2:34 PM, Bryan O'Donoghue
 wrote:

This patch removes warp7_secure_defconfig. A previous patch set
CONFIG_ARMV7_BOOT_SEC_DEFAULT=y on the unsecure WaRP7 config. Fabio asked
if I could confirm that the NXP and upstream kernels will boot on the WaRP7
with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. I can confirm that this is the case,
so there's no need to support the secure defconfig - drop it now.

Signed-off-by: Bryan O'Donoghue 
Suggested-by: Fabio Estevam 
Reviewed-by: Fabio Estevam 
---
  board/warp7/MAINTAINERS | 1 -
  1 file changed, 1 deletion(-)

diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
index 0fc9746606..1d3ee29222 100644
--- a/board/warp7/MAINTAINERS
+++ b/board/warp7/MAINTAINERS
@@ -4,4 +4,3 @@ S:  Maintained
  F: board/warp7/
  F: include/configs/warp7.h
  F: configs/warp7_defconfig
-F: configs/warp7_secure_defconfig


In v4 you missed to actually remove configs/warp7_secure_defconfig :-)


ah damnit i had a merge conflict ... I remember now

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

Re: [U-Boot] [PATCH v4 2/3] warp7: secure_defconfig: Remove secure_defconfig

[Fabio Estevam]

Hi Bryan,

On Tue, Apr 24, 2018 at 2:34 PM, Bryan O'Donoghue
 wrote:
> This patch removes warp7_secure_defconfig. A previous patch set
> CONFIG_ARMV7_BOOT_SEC_DEFAULT=y on the unsecure WaRP7 config. Fabio asked
> if I could confirm that the NXP and upstream kernels will boot on the WaRP7
> with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. I can confirm that this is the case,
> so there's no need to support the secure defconfig - drop it now.
>
> Signed-off-by: Bryan O'Donoghue 
> Suggested-by: Fabio Estevam 
> Reviewed-by: Fabio Estevam 
> ---
>  board/warp7/MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
> index 0fc9746606..1d3ee29222 100644
> --- a/board/warp7/MAINTAINERS
> +++ b/board/warp7/MAINTAINERS
> @@ -4,4 +4,3 @@ S:  Maintained
>  F: board/warp7/
>  F: include/configs/warp7.h
>  F: configs/warp7_defconfig
> -F: configs/warp7_secure_defconfig

In v4 you missed to actually remove configs/warp7_secure_defconfig :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 2/3] warp7: secure_defconfig: Remove secure_defconfig

[Bryan O'Donoghue]

This patch removes warp7_secure_defconfig. A previous patch set
CONFIG_ARMV7_BOOT_SEC_DEFAULT=y on the unsecure WaRP7 config. Fabio asked
if I could confirm that the NXP and upstream kernels will boot on the WaRP7
with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y. I can confirm that this is the case,
so there's no need to support the secure defconfig - drop it now.

Signed-off-by: Bryan O'Donoghue 
Suggested-by: Fabio Estevam 
Reviewed-by: Fabio Estevam 
---
 board/warp7/MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
index 0fc9746606..1d3ee29222 100644
--- a/board/warp7/MAINTAINERS
+++ b/board/warp7/MAINTAINERS
@@ -4,4 +4,3 @@ S:  Maintained
 F: board/warp7/
 F: include/configs/warp7.h
 F: configs/warp7_defconfig
-F: configs/warp7_secure_defconfig
-- 
2.17.0

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

[U-Boot] [PATCH v4 3/3] warp7: configs: enable CONFIG_CMD_FS_GENERIC

[Bryan O'Donoghue]

From: Pierre-Jean TEXIER 

This enable generic file system commands (load, ls).

Signed-off-by: Pierre-Jean TEXIER 
Acked-by: Bryan O'Donoghue 
Reviewed-by: Fabio Estevam 
Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 540dafd120..73f3f09dc1 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -27,6 +27,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DFU_MMC=y
 CONFIG_FSL_ESDHC=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 1/3] warp7: defconfig: Fix CAAM on boot with tip-of-tree

[Bryan O'Donoghue]

Booting the following image with tip-of-tree we get a CAAM DECO error (and
subsequent crash due to a kernel bug in 4.1).

http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland

Image: fsl-image-multimedia-imx7s-warp-20180323-90.rootfs.sdcard

Error:
caam 3090.caam: Entropy delay = 3200
caam 3090.caam: failed to acquire DECO 0

caam 3090.caam: failed to acquire DECO 0
caam 3090.caam: Entropy delay = 12400
caam 3090.caam: failed to acquire DECO 0
caam 3090.caam: failed to instantiate RNG
[ cut here ]
WARNING: CPU: 0 PID: 1 at
/home/jenkins/workspace/fsl-community-bsp-pyro_xwayland_2/build/tmp/work-shared/imx7s-warp/kernel-source/mm/vmalloc.c:1465
caam_remove+0x6)
Trying to vfree() nonexistent vm area (88047000)
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.1.36-4.1-1.0.x-imx-warp7+ga543d1b #1
Hardware name: Freescale i.MX7 Dual (Device Tree)
[<80015d54>] (unwind_backtrace) from [<80012688>] (show_stack+0x10/0x14)
[<80012688>] (show_stack) from [<8076e810>] (dump_stack+0x78/0x8c)
[<8076e810>] (dump_stack) from [<800346a0>]
(warn_slowpath_common+0x80/0xb0)
[<800346a0>] (warn_slowpath_common) from [<80034700>]
(warn_slowpath_fmt+0x30/0x40)
[<80034700>] (warn_slowpath_fmt) from [<8054c278>] (caam_remove+0x6c/0x3f4)
[<8054c278>] (caam_remove) from [<8054ce74>] (caam_probe+0x874/0xfa8)
[<8054ce74>] (caam_probe) from [<80382a7c>] (platform_drv_probe+0x48/0xa4)
[<80382a7c>] (platform_drv_probe) from [<80381328>]
(driver_probe_device+0x174/0x2a8)
[<80381328>] (driver_probe_device) from [<8038152c>]
(__driver_attach+0x8c/0x90)
[<8038152c>] (__driver_attach) from [<8037f9d4>]
(bus_for_each_dev+0x68/0x9c)
[<8037f9d4>] (bus_for_each_dev) from [<80380a68>]
(bus_add_driver+0xf4/0x1e8)
[<80380a68>] (bus_add_driver) from [<80381b38>] (driver_register+0x78/0xf4)
[<80381b38>] (driver_register) from [<80009738>]
(do_one_initcall+0x8c/0x1d0)
[<80009738>] (do_one_initcall) from [<80a66dac>]
(kernel_init_freeable+0x140/0x1d0)
[<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
(kernel_init+0x8/0xe8)
[<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
---[ end trace d5f941204ed8cb28 ]---
caam: probe of 3090.caam failed with error -11
Unable to handle kernel NULL pointer dereference at virtual address
0004
pgd = 80004000
[0004] *pgd=
Internal error: Oops: 805 [#1] PREEMPT SMP ARM

[<8055cdf8>] (caam_sm_startup) from [<80aa83c8>] (caam_sm_init+0x50/0x58)
[<80aa83c8>] (caam_sm_init) from [<80009738>] (do_one_initcall+0x8c/0x1d0)
[<80009738>] (do_one_initcall) from [<80a66dac>]
(kernel_init_freeable+0x140/0x1d0)
[<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
(kernel_init+0x8/0xe8)
[<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
Code: e59d300c e2832010 e5843008 e5834068 (e58a2004)
---[ end trace d5f941204ed8cb29 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

Fix: Enable the CAAM correctly by setting CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
in the upstream defconfig.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Breno Lima 
Reviewed-by: Fabio Estevam 
Tested-by: Breno Lima 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 3901a2741b..540dafd120 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
+CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
 # CONFIG_ARMV7_VIRT is not set
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
-- 
2.17.0

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

[U-Boot] [PATCH v4 0/3] WaRP7 unify secure and non-secure defconfigs

[Bryan O'Donoghue]

This tree here is pullable

http://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod-nouart

V4:
- Adds Tested-by/Reviewed-by from Beno and Fabio as indicated
  for my patches

- Resends Pierre-Jean's patch
  Since my parallel patchset relies on this patch I'm sending it again with
  my own series to make sure it doesn't get lost.
  To Pierre-Jean's patch I've added
  - Reviewed-by as Fabio indicated
  - Signed-off-by from me too

V3:
- Remove warp7_secure_defconfig from board/warp7/MAINTAINERS
- Add RB-tag from Fabio as indicated

V2:
Maintaining a secure and non-secure defconfig is a PITA. Having discussed
an observed bug with the non-secure boot-path with Fabio and undertaken to
ensure both upstream and NXP BSP kernels would work - this patchset does
two things.

1. Switches on CONFIG_ARMV7_BOOT_SEC_DEFAULT for warp7_defconfig
2. Removes warp7_secure_defconfig in its entirety

I have an upcoming set of patches that uses the secure defconfig which I've
already verified can simply be merged into mainline WaRP7 as-is so, in this
context there appears to be no justification for keeping separate
configuration files.

Fix the bug and zap the fat !

Bryan O'Donoghue (2):
  warp7: defconfig: Fix CAAM on boot with tip-of-tree
  warp7: secure_defconfig: Remove secure_defconfig

Pierre-Jean TEXIER (1):
  warp7: configs: enable CONFIG_CMD_FS_GENERIC

 board/warp7/MAINTAINERS | 1 -
 configs/warp7_defconfig | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
2.17.0

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

Re: [U-Boot] [RFC PATCH 0/5] arm: Introduce v7R support

[Michal Simek]

On 24.4.2018 17:06, Lokesh Vutla wrote:
> Hi Michal,
> 
> On Tuesday 24 April 2018 08:06 PM, Michal Simek wrote:
>> Hi Lokesh,
>>
>> On 24.4.2018 14:54, Lokesh Vutla wrote:
>>> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
>>> real-time systems. It implements the ARMv7-R architecture, and includes
>>> Thumb-2 technology for optimum code density and processing throughput.
>>>
>>> Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
>>> features are compatible with v7 architecture. This series adds minimal
>>> support for v7-R architecture by reusing the v7 support. Also adding
>>> support for MPU.
>>>
>>> Lokesh Vutla (4):
>>>   arm: v7: Update VBAR only if available
>>>   arm: Kconfig: Add entry for MMU
>>>   arm: v7R: Add support for MPU
>>>   arm: v7R: Add support for enabling caches
>>>
>>> Michal Simek (1):
>>>   arm: v7R: Add initial support
>>>
>>>  arch/arm/Kconfig  |  33 
>>>  arch/arm/Makefile |   2 +
>>>  arch/arm/cpu/armv7/Makefile   |   2 +
>>>  arch/arm/cpu/armv7/mpu_v7r.c  | 120 ++
>>>  arch/arm/cpu/armv7/start.S|   4 +
>>>  arch/arm/cpu/armv7m/Makefile  |   3 +-
>>>  arch/arm/cpu/armv7m/mpu.c |  41 +-
>>>  arch/arm/include/asm/armv7m_mpu.h |  69 +
>>>  arch/arm/lib/Makefile |   5 +-
>>>  arch/arm/lib/cache-cp15.c |  14 +++-
>>>  10 files changed, 248 insertions(+), 45 deletions(-)
>>>  create mode 100644 arch/arm/cpu/armv7/mpu_v7r.c
>>>
>>
>> I have tested your series, also wired MPU (protect one region and try to
>> access it) and with caches on and off (running mtest to see number of
>> iterations and improving numbers with cache on) and nothing is showing
>> any functional fundamental problem.
> 
> Thanks a lot for testing. Can I take it as your Tested-by:?

I didn't add it officially because I expect v1 based on comments. It
means I will test v1 again and give you that.

Thanks,
Michal


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

[U-Boot] [PATCH v2 07/20] phy: marvell: a3700: Access USB3 register indirectly on lane 2

[Marek Behún]

When USB3 is on comphy lane 2 on the Armada 37xx, the registers
have to be accessed indirectly via SATA indirect access.

This is the case of the Turris Mox board from CZ.NIC.

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.c | 102 -
 drivers/phy/marvell/comphy_a3700.h |   1 +
 2 files changed, 68 insertions(+), 35 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index d289bdf434..bcfe89e636 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -133,7 +133,7 @@ static u32 comphy_poll_reg(void *addr, u32 val, u32 mask, 
u8 op_type)
  */
 static int comphy_pcie_power_up(u32 speed, u32 invert)
 {
-   int ret;
+   int ret;
 
debug_enter();
 
@@ -300,14 +300,36 @@ static int comphy_sata_power_up(void)
return ret;
 }
 
+/*
+ * usb3_reg_set16
+ *
+ * return: void
+ */
+static void usb3_reg_set16(u32 reg, u16 data, u16 mask, u32 lane)
+{
+   /*
+* When Lane 2 PHY is for USB3, access the PHY registers
+* through indirect Address and Data registers INDIR_ACC_PHY_ADDR
+* (RD00E0178h [31:0]) and INDIR_ACC_PHY_DATA (RD00E017Ch [31:0])
+* within the SATA Host Controller registers, Lane 2 base register
+* offset is 0x200
+*/
+
+   if (lane == 2)
+   reg_set_indirect(USB3PHY_LANE2_REG_BASE_OFFSET + reg, data,
+mask);
+   else
+   reg_set16(phy_addr(USB3, reg), data, mask);
+}
+
 /*
  * comphy_usb3_power_up
  *
  * return: 1 if PLL locked (OK), 0 otherwise (FAIL)
  */
-static int comphy_usb3_power_up(u32 type, u32 speed, u32 invert)
+static int comphy_usb3_power_up(u32 lane, u32 type, u32 speed, u32 invert)
 {
-   int ret;
+   int ret;
 
debug_enter();
 
@@ -325,39 +347,38 @@ static int comphy_usb3_power_up(u32 type, u32 speed, u32 
invert)
 
/* 0xd005c300 = 0x1001 */
/* set PRD_TXDEEMPH (3.5db de-emph) */
-   reg_set16(phy_addr(USB3, LANE_CFG0), 0x1, 0xFF);
+   usb3_reg_set16(LANE_CFG0, 0x1, 0xFF, lane);
 
/*
 * unset BIT0: set Tx Electrical Idle Mode: Transmitter is in
-* low impedance mode during electrical idle
+* low impedance mode during electrical idle
+* unset BIT4: set G2 Tx Datapath with no Delayed Latency
+* unset BIT6: set Tx Detect Rx Mode at LoZ mode
 */
-   /* unset BIT4: set G2 Tx Datapath with no Delayed Latency */
-   /* unset BIT6: set Tx Detect Rx Mode at LoZ mode */
-   reg_set16(phy_addr(USB3, LANE_CFG1), 0x0, 0x);
+   usb3_reg_set16(LANE_CFG1, 0x0, 0x, lane);
 
 
-   /* 0xd005c310 = 0x93: set Spread Spectrum Clock Enabled  */
-   reg_set16(phy_addr(USB3, LANE_CFG4), bf_spread_spectrum_clock_en, 0x80);
+   /* 0xd005c310 = 0x93: set Spread Spectrum Clock Enabled */
+   usb3_reg_set16(LANE_CFG4, bf_spread_spectrum_clock_en, 0x80, lane);
 
/*
 * set Override Margining Controls From the MAC: Use margining signals
 * from lane configuration
 */
-   reg_set16(phy_addr(USB3, TEST_MODE_CTRL), rb_mode_margin_override,
- 0x);
+   usb3_reg_set16(TEST_MODE_CTRL, rb_mode_margin_override, 0x, lane);
 
/* set Lane-to-Lane Bundle Clock Sampling Period = per PCLK cycles */
/* set Mode Clock Source = PCLK is generated from REFCLK */
-   reg_set16(phy_addr(USB3, GLOB_CLK_SRC_LO), 0x0, 0xFF);
+   usb3_reg_set16(GLOB_CLK_SRC_LO, 0x0, 0xFF, lane);
 
/* set G2 Spread Spectrum Clock Amplitude at 4K */
-   reg_set16(phy_addr(USB3, GEN2_SETTINGS_2), g2_tx_ssc_amp, 0xF000);
+   usb3_reg_set16(GEN2_SETTINGS_2, g2_tx_ssc_amp, 0xF000, lane);
 
/*
 * unset G3 Spread Spectrum Clock Amplitude & set G3 TX and RX Register
 * Master Current Select
 */
-   reg_set16(phy_addr(USB3, GEN2_SETTINGS_3), 0x0, 0x);
+   usb3_reg_set16(GEN2_SETTINGS_3, 0x0, 0x, lane);
 
/*
 * 3. Check crystal jumper setting and program the Power and PLL
@@ -365,62 +386,72 @@ static int comphy_usb3_power_up(u32 type, u32 speed, u32 
invert)
 */
if (get_ref_clk() == 40) {
/* 40 MHz */
-   reg_set16(phy_addr(USB3, PWR_PLL_CTRL), 0xFCA3, 0x);
+   usb3_reg_set16(PWR_PLL_CTRL, 0xFCA3, 0x, lane);
} else {
/* 25 MHz */
-   reg_set16(phy_addr(USB3, PWR_PLL_CTRL), 0xFCA2, 0x);
+   usb3_reg_set16(PWR_PLL_CTRL, 0xFCA2, 0x, lane);
}
 
/*
 * 4. Change RX wait
 */
-   reg_set16(phy_addr(USB3, PWR_MGM_TIM1), 0x10C, 0x);
+   usb3_reg_set16(PWR_MGM_TIM1, 0x10C, 0x, lane);
 
/*
 * 5. Enable idle sync
 */
-   reg_set16(phy_addr(USB3, UNIT_CTRL), 0x60 | rb_idle_sync_en, 

[U-Boot] [PATCH v2 19/20] watchdog: Add support for Armada 37xx CPU watchdog

[Marek Behún]

This adds support for the CPU watchdog found on Marvell Armada 37xx
SoCs.

There are 4 counters which can be set as CPU watchdog counters.
This driver uses the second counter (ID 1, counting from 0)
(Marvell's Linux also uses second counter by default).
In the future it could be adapted to use other counters, with
definition in the device tree.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-37xx.dtsi  |   6 ++
 drivers/watchdog/Kconfig   |   9 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/armada-37xx-wdt.c | 175 +
 4 files changed, 191 insertions(+)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index 5b4a1a49bb..a1052add0c 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -107,6 +107,12 @@
status = "disabled";
};
 
+   wdt: watchdog-timer@8300 {
+   compatible = "marvell,armada-3700-wdt";
+   reg = <0xd064 0x4>,
+ <0x8300 0x40>;
+   };
+
nb_periph_clk: nb-periph-clk@13000 {
compatible = 
"marvell,armada-3700-periph-clock-nb";
reg = <0x13000 0x100>;
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index dca2c901ac..148c6a0d68 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -60,6 +60,15 @@ config WDT_SANDBOX
  can be probed and supports all of the methods of WDT, but does not
  really do anything.
 
+config WDT_ARMADA_37XX
+   bool "Marvell Armada 37xx watchdog timer support"
+   depends on WDT && ARMADA_3700
+   help
+  Enable this to support Watchdog Timer on Marvell Armada 37xx SoC.
+  There are 4 possible clocks which can be used on these SoCs. This
+  driver uses the second clock (ID 1), assuming that so will also
+  Linux's driver.
+
 config WDT_ASPEED
bool "Aspeed ast2400/ast2500 watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 4fee6dbd1f..e17aa2b835 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TANGIER_WATCHDOG) += tangier_wdt.o
 obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
 obj-$(CONFIG_WDT) += wdt-uclass.o
 obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
+obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
 obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
 obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
 obj-$(CONFIG_BCM2835_WDT)   += bcm2835_wdt.o
diff --git a/drivers/watchdog/armada-37xx-wdt.c 
b/drivers/watchdog/armada-37xx-wdt.c
new file mode 100644
index 00..0fa4fda4fc
--- /dev/null
+++ b/drivers/watchdog/armada-37xx-wdt.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Marvell Armada 37xx SoC Watchdog Driver
+ *
+ * Marek Behun 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct a37xx_wdt {
+   void __iomem *sel_reg;
+   void __iomem *reg;
+   ulong clk_rate;
+   u64 timeout;
+};
+
+/*
+ * We use Counter 1 for watchdog timer, because so does Marvell's Linux by
+ * default.
+ */
+
+#define CNTR_CTRL  0x10
+#define CNTR_CTRL_ENABLE   0x0001
+#define CNTR_CTRL_ACTIVE   0x0002
+#define CNTR_CTRL_MODE_MASK0x000c
+#define CNTR_CTRL_MODE_ONESHOT 0x
+#define CNTR_CTRL_PRESCALE_MASK0xff00
+#define CNTR_CTRL_PRESCALE_MIN 2
+#define CNTR_CTRL_PRESCALE_SHIFT   8
+
+#define CNTR_COUNT_LOW 0x14
+#define CNTR_COUNT_HIGH0x18
+
+static void set_counter_value(struct a37xx_wdt *priv)
+{
+   writel(priv->timeout & 0x, priv->reg + CNTR_COUNT_LOW);
+   writel(priv->timeout >> 32, priv->reg + CNTR_COUNT_HIGH);
+}
+
+static void a37xx_wdt_enable(struct a37xx_wdt *priv)
+{
+   u32 reg = readl(priv->reg + CNTR_CTRL);
+
+   reg |= CNTR_CTRL_ENABLE;
+   writel(reg, priv->reg + CNTR_CTRL);
+}
+
+static void a37xx_wdt_disable(struct a37xx_wdt *priv)
+{
+   u32 reg = readl(priv->reg + CNTR_CTRL);
+
+   reg &= ~CNTR_CTRL_ENABLE;
+   writel(reg, priv->reg + CNTR_CTRL);
+}
+
+static int a37xx_wdt_reset(struct udevice *dev)
+{
+   struct a37xx_wdt *priv = dev_get_priv(dev);
+
+   if (!priv->timeout)
+   return -EINVAL;
+
+   a37xx_wdt_disable(priv);
+   set_counter_value(priv);
+   a37xx_wdt_enable(priv);
+
+   return 0;
+}
+
+static int a37xx_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+   struct a37xx_wdt *priv = dev_get_priv(dev);
+
+   a37xx_wdt_disable(priv);
+   priv->timeout = 0;
+   set_counter_value(priv);
+   

[U-Boot] [PATCH v2 18/20] net: mvneta: Fix fault when wrong device tree

[Marek Behún]

The driver does not check id phy_connect failed (for example on wrong
property name in device tree). In such a case a fault occurs and the
CPU is restarted.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/net/mvneta.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index f2e9acfd1f..7ea61ae582 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -1563,6 +1563,10 @@ static int mvneta_start(struct udevice *dev)
 
phydev = phy_connect(pp->bus, pp->phyaddr, dev,
 pp->phy_interface);
+   if (!phydev) {
+   printf("phy_connect failed\n");
+   return -ENODEV;
+   }
 
pp->phydev = phydev;
phy_config(phydev);
-- 
2.16.1

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

[U-Boot] [PATCH v2 10/20] phy: marvell: mux: Support nontrivial node order in selector register

[Marek Behún]

Currently comphy_mux supports only trivial order of nodes in pin
selector register, that is lane N on position N*bitcount.

Add support for nontrivial order, with map stored in device tree
property mux-lane-order.

This is needed for Armada 37xx.

As far as I know, there is no driver for Armada 37xx comphy in the
kernel. When such a driver comes, this will need to be rewritten to
support the device tree bindings from the kernel.

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy.h  |  1 +
 drivers/phy/marvell/comphy_core.c |  4 
 drivers/phy/marvell/comphy_mux.c  | 17 ++---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/marvell/comphy.h b/drivers/phy/marvell/comphy.h
index c9b94a4c5e..32e0a1e652 100644
--- a/drivers/phy/marvell/comphy.h
+++ b/drivers/phy/marvell/comphy.h
@@ -97,6 +97,7 @@ struct chip_serdes_phy_config {
void __iomem *hpipe3_base_addr;
u32 comphy_lanes_count;
u32 comphy_mux_bitcount;
+   const fdt32_t *comphy_mux_lane_order;
u32 cp_index;
 };
 
diff --git a/drivers/phy/marvell/comphy_core.c 
b/drivers/phy/marvell/comphy_core.c
index 426db30f73..1e5664c435 100644
--- a/drivers/phy/marvell/comphy_core.c
+++ b/drivers/phy/marvell/comphy_core.c
@@ -135,6 +135,10 @@ static int comphy_probe(struct udevice *dev)
return -EINVAL;
}
 
+   chip_cfg->comphy_mux_lane_order =
+   fdtdec_locate_array(blob, node, "mux-lane-order",
+   chip_cfg->comphy_lanes_count);
+
if (device_is_compatible(dev, "marvell,comphy-armada-3700"))
chip_cfg->ptr_comphy_chip_init = comphy_a3700_init;
 
diff --git a/drivers/phy/marvell/comphy_mux.c b/drivers/phy/marvell/comphy_mux.c
index b036fb13b9..75110b6ba0 100644
--- a/drivers/phy/marvell/comphy_mux.c
+++ b/drivers/phy/marvell/comphy_mux.c
@@ -79,7 +79,8 @@ static u32 comphy_mux_get_mux_value(struct comphy_mux_data 
*mux_data,
 static void comphy_mux_reg_write(struct comphy_mux_data *mux_data,
 struct comphy_map *comphy_map_data,
 int comphy_max_lanes,
-void __iomem *selector_base, u32 bitcount)
+void __iomem *selector_base,
+const fdt32_t *mux_lane_order, u32 bitcount)
 {
u32 lane, value, offset, mask;
 
@@ -90,7 +91,15 @@ static void comphy_mux_reg_write(struct comphy_mux_data 
*mux_data,
if (comphy_map_data->type == PHY_TYPE_IGNORE)
continue;
 
-   offset = lane * bitcount;
+   /*
+* if the order of nodes in selector base register is
+* nontrivial, use mapping from mux_lane_order
+*/
+   if (mux_lane_order)
+   offset = fdt32_to_cpu(mux_lane_order[lane]) * bitcount;
+   else
+   offset = lane * bitcount;
+
mask = (((1 << bitcount) - 1) << offset);
value = (comphy_mux_get_mux_value(mux_data,
  comphy_map_data->type,
@@ -106,6 +115,7 @@ void comphy_mux_init(struct chip_serdes_phy_config 
*chip_cfg,
 void __iomem *selector_base)
 {
struct comphy_mux_data *mux_data;
+   const fdt32_t *mux_lane_order;
u32 mux_bitcount;
u32 comphy_max_lanes;
 
@@ -113,13 +123,14 @@ void comphy_mux_init(struct chip_serdes_phy_config 
*chip_cfg,
 
comphy_max_lanes = chip_cfg->comphy_lanes_count;
mux_data = chip_cfg->mux_data;
+   mux_lane_order = chip_cfg->comphy_mux_lane_order;
mux_bitcount = chip_cfg->comphy_mux_bitcount;
 
/* check if the configuration is valid */
comphy_mux_check_config(mux_data, comphy_map_data, comphy_max_lanes);
/* Init COMPHY selectors */
comphy_mux_reg_write(mux_data, comphy_map_data, comphy_max_lanes,
-selector_base, mux_bitcount);
+selector_base, mux_lane_order, mux_bitcount);
 
debug_exit();
 }
-- 
2.16.1

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

[U-Boot] [PATCH v2 12/20] phy: marvell: a3700: Use comphy_mux on Armada 37xx.

[Marek Behún]

Lane 0 supports SGMII1 and USB3.
Lane 1 supports SGMII0 and PEX0.
Lane 2 supports SATA0 and USB3.

This is needed for Armada 37xx.

This introduces new device tree bindings. AFAIK there is currently no
driver for Armada 37xx comphy in Linux. When such a driver will be
pushed into Linux, this will need to be rewritten accordingly.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-37xx.dtsi  |  5 +++--
 drivers/phy/marvell/comphy_a3700.c | 36 
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index 54007428ed..040e8568e6 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -290,8 +290,9 @@
compatible = "marvell,mvebu-comphy", 
"marvell,comphy-armada-3700";
reg = <0x18300 0x28>,
  <0x1f300 0x3d000>;
-   mux-bitcount = <1>;
-   max-lanes = <2>;
+   mux-bitcount = <4>;
+   mux-lane-order = <1 0 2>;
+   max-lanes = <3>;
};
};
 
diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index bc9914724a..8b44732e52 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -14,6 +14,38 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct comphy_mux_data a3700_comphy_mux_data[] = {
+/* Lane 0 */
+   {
+   4,
+   {
+   { PHY_TYPE_UNCONNECTED, 0x0 },
+   { PHY_TYPE_SGMII1,  0x0 },
+   { PHY_TYPE_USB3_HOST0,  0x1 },
+   { PHY_TYPE_USB3_DEVICE, 0x1 }
+   }
+   },
+/* Lane 1 */
+   {
+   3,
+   {
+   { PHY_TYPE_UNCONNECTED, 0x0},
+   { PHY_TYPE_SGMII0,  0x0},
+   { PHY_TYPE_PEX0,0x1}
+   }
+   },
+/* Lane 2 */
+   {
+   4,
+   {
+   { PHY_TYPE_UNCONNECTED, 0x0},
+   { PHY_TYPE_SATA0,   0x0},
+   { PHY_TYPE_USB3_HOST0,  0x1},
+   { PHY_TYPE_USB3_DEVICE, 0x1}
+   }
+   },
+};
+
 struct sgmii_phy_init_data_fix {
u16 addr;
u16 value;
@@ -933,6 +965,10 @@ int comphy_a3700_init(struct chip_serdes_phy_config 
*chip_cfg,
 
debug_enter();
 
+   /* Initialize PHY mux */
+   chip_cfg->mux_data = a3700_comphy_mux_data;
+   comphy_mux_init(chip_cfg, serdes_map, COMPHY_SEL_ADDR);
+
for (lane = 0, comphy_map = serdes_map; lane < comphy_max_count;
 lane++, comphy_map++) {
debug("Initialize serdes number %d\n", lane);
-- 
2.16.1

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

[U-Boot] [PATCH v2 13/20] phy: marvell: a3700: Save/restore selector reg in SGMII init

[Marek Behún]

In SGMII initialization PIN_PIPE_SEL has to be zero when resetting
the PHY. Since comphy_mux already set the selector register to
correct values, we have to store it's value before setting it to 0
and restore it after SGMII init.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy_a3700.c | 9 -
 drivers/phy/marvell/comphy_a3700.h | 1 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 8b44732e52..7f5371afe9 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -698,13 +698,15 @@ static void comphy_sgmii_phy_init(u32 lane, u32 speed)
 static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 invert)
 {
int ret;
+   u32 saved_selector;
 
debug_enter();
 
/*
 * 1. Configure PHY to SATA/SAS mode by setting pin PIN_PIPE_SEL=0
 */
-   reg_set(COMPHY_SEL_ADDR, 0, rf_compy_select(lane));
+   saved_selector = readl(COMPHY_SEL_ADDR);
+   reg_set(COMPHY_SEL_ADDR, 0, 0x);
 
/*
 * 2. Reset PHY by setting PHY input port PIN_RESET=1.
@@ -875,6 +877,11 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
if (!ret)
printf("Failed to init RX of SGMII PHY %d\n", lane);
 
+   /*
+* Restore saved selector.
+*/
+   reg_set(COMPHY_SEL_ADDR, saved_selector, 0x);
+
debug_exit();
 
return ret;
diff --git a/drivers/phy/marvell/comphy_a3700.h 
b/drivers/phy/marvell/comphy_a3700.h
index 2468468162..6d737967ab 100644
--- a/drivers/phy/marvell/comphy_a3700.h
+++ b/drivers/phy/marvell/comphy_a3700.h
@@ -23,7 +23,6 @@
  * COMPHY SB definitions
  */
 #define COMPHY_SEL_ADDRMVEBU_REG(0x0183FC)
-#define rf_compy_select(lane)  (0x1 << (((lane) == 1) ? 4 : 0))
 
 #define COMPHY_PHY_CFG1_ADDR(lane) MVEBU_REG(0x018300 + (1 - lane) * 0x28)
 #define rb_pin_pu_iveref   BIT(1)
-- 
2.16.1

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

[U-Boot] [PATCH v2 20/20] arm64: mvebu: Add basic support for the Turris Mox board

[Marek Behún]

This adds basic support for the Turris Mox board from CZ.NIC, which is
currently being crowdfunded on Indiegogo.

Turris Mox is as modular router based on the Armada 3720 SOC (same as
EspressoBin).

The basic module can be extended by different modules. The device tree
binary for the kernel can be dependent on which modules are connected,
and in what order. Because of this, the board specific code creates
in U-Boot a variable called module_topology, which carries this
information.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/armada-3720-turris-mox.dts | 132 
 arch/arm/mach-mvebu/Kconfig |   7 ++
 arch/arm/mach-mvebu/Makefile|   2 +-
 board/CZ.NIC/turris_mox/MAINTAINERS |   6 ++
 board/CZ.NIC/turris_mox/Makefile|   5 ++
 board/CZ.NIC/turris_mox/turris_mox.c| 127 ++
 configs/turris_mox_defconfig|  76 ++
 include/configs/turris_mox.h| 108 ++
 9 files changed, 463 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ac7667b1e8..07692769d7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -89,6 +89,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
 dtb-$(CONFIG_ARCH_MVEBU) +=\
armada-3720-db.dtb  \
armada-3720-espressobin.dtb \
+   armada-3720-turris-mox.dtb  \
armada-375-db.dtb   \
armada-388-clearfog.dtb \
armada-388-gp.dtb   \
diff --git a/arch/arm/dts/armada-3720-turris-mox.dts 
b/arch/arm/dts/armada-3720-turris-mox.dts
new file mode 100644
index 00..bef100afce
--- /dev/null
+++ b/arch/arm/dts/armada-3720-turris-mox.dts
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+ or X11
+/*
+ * Device Tree file for CZ.NIC Turris Mox Board
+ * 2018 by Marek Behun 
+ *
+ * Based on armada-3720-espressobin.dts by:
+ *   Gregory CLEMENT 
+ *   Konstantin Porotchkin 
+ */
+
+/dts-v1/;
+
+#include 
+#include "armada-372x.dtsi"
+
+/ {
+   model = "CZ.NIC Turris Mox Board";
+   compatible = "cznic,turris-mox", "marvell,armada3720",
+"marvell,armada3710";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   ethernet0 = 
+   i2c0 = 
+   spi0 = 
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x 0x 0x2000>;
+   };
+
+   reg_usb3_vbus: usb3_vbus@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb3-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   shutdown-delay-us = <100>;
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   regulator-boot-on;
+   };
+
+   mdio {
+   eth_phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   };
+};
+
+ {
+   max-lanes = <3>;
+   phy0 {
+   phy-type = ;
+   phy-speed = ;
+   };
+
+   phy1 {
+   phy-type = ;
+   phy-speed = ;
+   };
+
+   phy2 {
+   phy-type = ;
+   phy-speed = ;
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>, <_pins>;
+   phy-mode = "rgmii";
+   phy = <_phy1>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   bus-width = <4>;
+   status = "okay";
+};
+
+_nb {
+   spi_cs1_pins: spi-cs1-pins {
+   groups = "spi_cs1";
+   function = "spi";
+   };
+};
+
+_sb {
+   smi_pins: smi-pins {
+   groups = "smi";
+   function = "smi";
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_cs1_pins>;
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,s25fl064l", "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   m25p,fast-read;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vbus-supply = <_usb3_vbus>;
+   status = "okay";
+};
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 01d700bf2e..5f6ff0b5f3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -96,6 +96,10 @@ config TARGET_TURRIS_OMNIA
bool "Support Turris Omnia"
select 88F6820

[U-Boot] [PATCH v2 15/20] spi: mvebu_a3700_spi: Use Armada 37xx clk driver for SPI clock frequency

[Marek Behún]

Since now we have driver for clocks on Armada 37xx, use it to determine
SQF clock frequency for the SPI driver.

Also change the default config files for Armada 37xx devices so that
the clock driver is enabled by default, otherwise the SPI driver cannot
be enabled.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-37xx.dtsi   |  4 +--
 configs/mvebu_db-88f3720_defconfig  |  3 ++
 configs/mvebu_espressobin-88f3720_defconfig |  3 ++
 drivers/spi/Kconfig |  1 +
 drivers/spi/mvebu_a3700_spi.c   | 52 -
 5 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index c72fd25abc..5b4a1a49bb 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -301,8 +301,8 @@
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <0>;
-   clock-frequency = <16>;
-   spi-max-frequency = <4>;
+   spi-max-frequency = <5000>;
+   clocks = <_periph_clk 7>;
status = "disabled";
};
 
diff --git a/configs/mvebu_db-88f3720_defconfig 
b/configs/mvebu_db-88f3720_defconfig
index 67a8077a58..691d7211dc 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -36,6 +36,9 @@ CONFIG_DM_GPIO=y
 # CONFIG_MVEBU_GPIO is not set
 CONFIG_DM_I2C=y
 CONFIG_MISC=y
+CONFIG_CLK=y
+CONFIG_CLK_MVEBU=y
+CONFIG_CLK_ARMADA_3720=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index 48dae2d791..60259bcf2c 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -35,6 +35,9 @@ CONFIG_BLOCK_CACHE=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_MISC=y
+CONFIG_CLK=y
+CONFIG_CLK_MVEBU=y
+CONFIG_CLK_ARMADA_3720=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84ed2..06fa14ae36 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -101,6 +101,7 @@ config ICH_SPI
 
 config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
+   select CLK_ARMADA_3720
help
  Enable the Marvell Armada 3700 SPI driver. This driver can be
  used to access the SPI NOR flash on platforms embedding this
diff --git a/drivers/spi/mvebu_a3700_spi.c b/drivers/spi/mvebu_a3700_spi.c
index d1708a8d56..9b8b5e4d06 100644
--- a/drivers/spi/mvebu_a3700_spi.c
+++ b/drivers/spi/mvebu_a3700_spi.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -22,9 +23,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MVEBU_SPI_A3700_CLK_POLBIT(7)
 #define MVEBU_SPI_A3700_FIFO_ENBIT(17)
 #define MVEBU_SPI_A3700_SPI_EN_0   BIT(16)
-#define MVEBU_SPI_A3700_CLK_PRESCALE_BIT   0
-#define MVEBU_SPI_A3700_CLK_PRESCALE_MASK  \
-   (0x1f << MVEBU_SPI_A3700_CLK_PRESCALE_BIT)
+#define MVEBU_SPI_A3700_CLK_PRESCALE_MASK  0x1f
+
 
 /* SPI registers */
 struct spi_reg {
@@ -36,8 +36,7 @@ struct spi_reg {
 
 struct mvebu_spi_platdata {
struct spi_reg *spireg;
-   unsigned int frequency;
-   unsigned int clock;
+   struct clk clk;
 };
 
 static void spi_cs_activate(struct spi_reg *reg, int cs)
@@ -178,17 +177,18 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
hz)
 {
struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
struct spi_reg *reg = plat->spireg;
-   u32 data;
+   u32 data, prescale;
 
data = readl(>cfg);
 
-   /* Set Prescaler */
-   data &= ~MVEBU_SPI_A3700_CLK_PRESCALE_MASK;
+   prescale = DIV_ROUND_UP(clk_get_rate(>clk), hz);
+   if (prescale > 0x1f)
+   prescale = 0x1f;
+   else if (prescale > 0xf)
+   prescale = 0x10 + (prescale + 1) / 2;
 
-   /* Calculate Prescaler = (spi_input_freq / spi_max_freq) */
-   if (hz > plat->frequency)
-   hz = plat->frequency;
-   data |= plat->clock / hz;
+   data &= ~MVEBU_SPI_A3700_CLK_PRESCALE_MASK;
+   data |= prescale & MVEBU_SPI_A3700_CLK_PRESCALE_MASK;
 
writel(data, >cfg);
 
@@ -252,21 +252,24 @@ static int mvebu_spi_probe(struct udevice *bus)
 static int mvebu_spi_ofdata_to_platdata(struct udevice *bus)
 {
struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
+   int ret;
 
plat->spireg = (struct spi_reg *)devfdt_get_addr(bus);
 
-   /*
-* FIXME
-* Right now, mvebu does not have a clock infrastructure in U-Boot
-* which should be used to query the input clock to the SPI
-* 

[U-Boot] [PATCH v2 16/20] clk: armada-37xx: Support soc_clk_dump

[Marek Behún]

Add support for the clk dump command on Armada 37xx.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/clk/mvebu/armada-37xx-periph.c | 36 +-
 drivers/clk/mvebu/armada-37xx-tbg.c|  2 ++
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
b/drivers/clk/mvebu/armada-37xx-periph.c
index af08e3df08..902a6cc9ef 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -337,7 +337,8 @@ static int armada_37xx_periph_clk_disable(struct clk *clk)
return periph_clk_enable(clk, 0);
 }
 
-int armada_37xx_periph_clk_dump(struct udevice *dev)
+#if defined(CONFIG_CMD_CLK) && defined(CONFIG_CLK_ARMADA_3720)
+static int armada_37xx_periph_clk_dump(struct udevice *dev)
 {
struct a37xx_periphclk *priv = dev_get_priv(dev);
const struct clk_periph *clks;
@@ -356,6 +357,39 @@ int armada_37xx_periph_clk_dump(struct udevice *dev)
return 0;
 }
 
+static int clk_dump(const char *name, int (*func)(struct udevice *))
+{
+   struct udevice *dev;
+
+   if (uclass_get_device_by_name(UCLASS_CLK, name, )) {
+   printf("Cannot find device %s\n", name);
+   return -ENODEV;
+   }
+
+   return func(dev);
+}
+
+int armada_37xx_tbg_clk_dump(struct udevice *);
+
+int soc_clk_dump(void)
+{
+   printf("  xtal at %u00 Hz\n\n", get_ref_clk());
+
+   if (clk_dump("tbg@13200", armada_37xx_tbg_clk_dump))
+   return 1;
+
+   if (clk_dump("nb-periph-clk@13000",
+armada_37xx_periph_clk_dump))
+   return 1;
+
+   if (clk_dump("sb-periph-clk@18000",
+armada_37xx_periph_clk_dump))
+   return 1;
+
+   return 0;
+}
+#endif
+
 static int armada_37xx_periph_clk_probe(struct udevice *dev)
 {
struct a37xx_periphclk *priv = dev_get_priv(dev);
diff --git a/drivers/clk/mvebu/armada-37xx-tbg.c 
b/drivers/clk/mvebu/armada-37xx-tbg.c
index c035b8f1fa..aa7ccd690f 100644
--- a/drivers/clk/mvebu/armada-37xx-tbg.c
+++ b/drivers/clk/mvebu/armada-37xx-tbg.c
@@ -93,6 +93,7 @@ static ulong armada_37xx_tbg_clk_get_rate(struct clk *clk)
return priv->rates[clk->id];
 }
 
+#if defined(CONFIG_CMD_CLK) && defined(CONFIG_CLK_ARMADA_3720)
 int armada_37xx_tbg_clk_dump(struct udevice *dev)
 {
struct a37xx_tbgclk *priv = dev_get_priv(dev);
@@ -105,6 +106,7 @@ int armada_37xx_tbg_clk_dump(struct udevice *dev)
 
return 0;
 }
+#endif
 
 static int armada_37xx_tbg_clk_probe(struct udevice *dev)
 {
-- 
2.16.1

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

[U-Boot] [PATCH v2 09/20] phy: marvell: a3700: revise the USB3 comphy setting during power on

[Marek Behún]

From: zachary 

This commit is based on commit d9899826 by
  zachary 
from u-boot-marvell, see
github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/d9899826

- According to design specification, the transmitter should be set to high
  impedence mode during electrical idle. Thus transmitter should detect RX
  at high impedence mode also, and delay is needed to accommodate high
  impedence off latency. Otherwise the USB3 will have detection issue that
  most of the time the USB3 device can not be detected at all, or be
  detected as USB2 device sometimes.
  Modified registers: RD005C302h (R181h) (0051h) Lane Configuration 1
  Bit 6: set to 1 to let Tx detect Rx at HiZ mode
  Bit [3:4]: set to 2 to be delayed by 2 clock cycles
  Bit 0: set to 1 to set transmitter to high impedance mode during idle.
- USB3 De-emphasize level of -3.5dB is mandatory, but USB3 MAC selects 0x2
  (emphasize disabled) in the MAC_PHY_TXDEEMPH [1:0], while it is supposed
  to select 0x1(3.5dB emphasize). Thus need to override what comes from
  the MAC(by setting register 0x1c2 bit2 to 0x1) and to configure the
  overridded values of MAC_PHY_TXDEEMPH [1:0] to 0x1(bit15 of register
  0x181 and bit0 of register 0x180).
- According to USB3 application note, need to update below comphy
  registers:
  Set max speed generation to USB3.0 5Gbps(set RD005C04Ah bit[11:10] to 1)
  Set capacitor value to 0xF(set RF005C224 bit[3:0] to 0xF)

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.c | 31 +++
 drivers/phy/marvell/comphy_a3700.h |  5 +
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 82dffc4f83..bc9914724a 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -350,13 +350,18 @@ static int comphy_usb3_power_up(u32 lane, u32 type, u32 
speed, u32 invert)
usb3_reg_set16(LANE_CFG0, 0x1, 0xFF, lane);
 
/*
-* unset BIT0: set Tx Electrical Idle Mode: Transmitter is in
-* low impedance mode during electrical idle
-* unset BIT4: set G2 Tx Datapath with no Delayed Latency
-* unset BIT6: set Tx Detect Rx Mode at LoZ mode
-*/
-   usb3_reg_set16(LANE_CFG1, 0x0, 0x, lane);
-
+* Set BIT0: enable transmitter in high impedance mode
+* Set BIT[3:4]: delay 2 clock cycles for HiZ off latency
+* Set BIT6: Tx detect Rx at HiZ mode
+* Unset BIT15: set to 0 to set USB3 De-emphasize level to -3.5db
+*  together with bit 0 of COMPHY_REG_LANE_CFG0_ADDR
+*  register
+*/
+   usb3_reg_set16(LANE_CFG1,
+  tx_det_rx_mode | gen2_tx_data_dly_deft
+  | tx_elec_idle_mode_en,
+  prd_txdeemph1_mask | tx_det_rx_mode
+  | gen2_tx_data_dly_mask | tx_elec_idle_mode_en, lane);
 
/* 0xd005c310 = 0x93: set Spread Spectrum Clock Enabled */
usb3_reg_set16(LANE_CFG4, bf_spread_spectrum_clock_en, 0x80, lane);
@@ -426,7 +431,17 @@ static int comphy_usb3_power_up(u32 lane, u32 type, u32 
speed, u32 invert)
usb3_reg_set16(SYNC_PATTERN, phy_rxd_inv, 0, lane);
 
/*
-* 10. Release SW reset
+* 10. Set max speed generation to USB3.0 5Gbps
+*/
+   usb3_reg_set16(SYNC_MASK_GEN, 0x0400, 0x0C00, lane);
+
+   /*
+* 11. Set capacitor value for FFE gain peaking to 0xF
+*/
+   usb3_reg_set16(GEN3_SETTINGS_3, 0xF, 0xF, lane);
+
+   /*
+* 12. Release SW reset
 */
usb3_reg_set16(GLOB_PHY_CTRL0,
   rb_mode_core_clk_freq_sel | rb_mode_pipe_width_32
diff --git a/drivers/phy/marvell/comphy_a3700.h 
b/drivers/phy/marvell/comphy_a3700.h
index 51c95c1618..952d28e221 100644
--- a/drivers/phy/marvell/comphy_a3700.h
+++ b/drivers/phy/marvell/comphy_a3700.h
@@ -142,6 +142,11 @@ static inline void __iomem *phy_addr(enum phy_unit unit, 
u32 addr)
 
 #define LANE_CFG1  0x181
 #define bf_use_max_pll_rateBIT(9)
+#define prd_txdeemph1_mask BIT(15)
+#define tx_det_rx_mode BIT(6)
+#define gen2_tx_data_dly_deft  (2 << 3)
+#define gen2_tx_data_dly_mask  (BIT(3) | BIT(4))
+#define tx_elec_idle_mode_en   BIT(0)
 
 #define LANE_CFG4  0x188
 #define bf_spread_spectrum_clock_enBIT(7)
-- 
2.16.1

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

[U-Boot] [PATCH v2 06/20] phy: marvell: a3700: Use reg_set_indirect istead of 2 reg_sets

[Marek Behún]

Create a special function for indirect register setting,
reg_set_indirect, and use it instead of the two calls to reg_set.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy_a3700.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 429ad6b018..d289bdf434 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -224,6 +224,17 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
return ret;
 }
 
+/*
+ * reg_set_indirect
+ *
+ * return: void
+ */
+static void reg_set_indirect(u32 reg, u16 data, u16 mask)
+{
+   reg_set(rh_vsreg_addr, reg, 0x);
+   reg_set(rh_vsreg_data, data, mask);
+}
+
 /*
  * comphy_sata_power_up
  *
@@ -231,43 +242,40 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
  */
 static int comphy_sata_power_up(void)
 {
-   int ret;
+   int ret;
 
debug_enter();
 
/*
 * 0. Swap SATA TX lines
 */
-   reg_set(rh_vsreg_addr, vphy_sync_pattern_reg, 0x);
-   reg_set(rh_vsreg_data, bs_txd_inv, bs_txd_inv);
+   reg_set_indirect(vphy_sync_pattern_reg, bs_txd_inv, bs_txd_inv);
 
/*
 * 1. Select 40-bit data width width
 */
-   reg_set(rh_vsreg_addr, vphy_loopback_reg0, 0x);
-   reg_set(rh_vsreg_data, 0x800, bs_phyintf_40bit);
+   reg_set_indirect(vphy_loopback_reg0, 0x800, bs_phyintf_40bit);
 
/*
 * 2. Select reference clock and PHY mode (SATA)
 */
-   reg_set(rh_vsreg_addr, vphy_power_reg0, 0x);
if (get_ref_clk() == 40) {
-   reg_set(rh_vsreg_data, 0x3, 0x00FF); /* 40 MHz */
+   /* 40 MHz */
+   reg_set_indirect(vphy_power_reg0, 0x3, 0x00FF);
} else {
-   reg_set(rh_vsreg_data, 0x1, 0x00FF); /* 25 MHz */
+   /* 20 MHz */
+   reg_set_indirect(vphy_power_reg0, 0x1, 0x00FF);
}
 
/*
 * 3. Use maximum PLL rate (no power save)
 */
-   reg_set(rh_vsreg_addr, vphy_calctl_reg, 0x);
-   reg_set(rh_vsreg_data, bs_max_pll_rate, bs_max_pll_rate);
+   reg_set_indirect(vphy_calctl_reg, bs_max_pll_rate, bs_max_pll_rate);
 
/*
 * 4. Reset reserved bit (??)
 */
-   reg_set(rh_vsreg_addr, vphy_reserve_reg, 0x);
-   reg_set(rh_vsreg_data, 0, bs_phyctrl_frm_pin);
+   reg_set_indirect(vphy_reserve_reg, 0, bs_phyctrl_frm_pin);
 
/*
 * 5. Set vendor-specific configuration (??)
-- 
2.16.1

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

[U-Boot] [PATCH v2 17/20] phy: marvell: core: Cosmetic fixes

[Marek Behún]

Move the reg_set* functions into comphy.h as static inline functions.
Change return type of get_*_string to const char *.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy.h  | 41 ++---
 drivers/phy/marvell/comphy_core.c | 64 +--
 2 files changed, 52 insertions(+), 53 deletions(-)

diff --git a/drivers/phy/marvell/comphy.h b/drivers/phy/marvell/comphy.h
index 32e0a1e652..176bc89cac 100644
--- a/drivers/phy/marvell/comphy.h
+++ b/drivers/phy/marvell/comphy.h
@@ -102,10 +102,43 @@ struct chip_serdes_phy_config {
 };
 
 /* Register helper functions */
-void reg_set(void __iomem *addr, u32 data, u32 mask);
-void reg_set_silent(void __iomem *addr, u32 data, u32 mask);
-void reg_set16(void __iomem *addr, u16 data, u16 mask);
-void reg_set_silent16(void __iomem *addr, u16 data, u16 mask);
+static inline void reg_set_silent(void __iomem *addr, u32 data, u32 mask)
+{
+   u32 reg_data;
+
+   reg_data = readl(addr);
+   reg_data &= ~mask;
+   reg_data |= data;
+   writel(reg_data, addr);
+}
+
+static inline void reg_set(void __iomem *addr, u32 data, u32 mask)
+{
+   debug("Write to address = %#010lx, data = %#010x (mask = %#010x) - ",
+ (unsigned long)addr, data, mask);
+   debug("old value = %#010x ==> ", readl(addr));
+   reg_set_silent(addr, data, mask);
+   debug("new value %#010x\n", readl(addr));
+}
+
+static inline void reg_set_silent16(void __iomem *addr, u16 data, u16 mask)
+{
+   u16 reg_data;
+
+   reg_data = readw(addr);
+   reg_data &= ~mask;
+   reg_data |= data;
+   writew(reg_data, addr);
+}
+
+static inline void reg_set16(void __iomem *addr, u16 data, u16 mask)
+{
+   debug("Write to address = %#010lx, data = %#06x (mask = %#06x) - ",
+ (unsigned long)addr, data, mask);
+   debug("old value = %#06x ==> ", readw(addr));
+   reg_set_silent16(addr, data, mask);
+   debug("new value %#06x\n", readw(addr));
+}
 
 /* SoC specific init functions */
 #ifdef CONFIG_ARMADA_3700
diff --git a/drivers/phy/marvell/comphy_core.c 
b/drivers/phy/marvell/comphy_core.c
index 1e5664c435..55f1d5 100644
--- a/drivers/phy/marvell/comphy_core.c
+++ b/drivers/phy/marvell/comphy_core.c
@@ -18,11 +18,13 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static char *get_speed_string(u32 speed)
+static const char *get_speed_string(u32 speed)
 {
-   char *speed_strings[] = {"1.25 Gbps", "1.5 Gbps", "2.5 Gbps",
-"3.0 Gbps", "3.125 Gbps", "5 Gbps", "6 Gbps",
-"6.25 Gbps", "10.31 Gbps" };
+   static const char * const speed_strings[] = {
+   "1.25 Gbps", "1.5 Gbps", "2.5 Gbps",
+   "3.0 Gbps", "3.125 Gbps", "5 Gbps", "6 Gbps",
+   "6.25 Gbps", "10.31 Gbps"
+   };
 
if (speed < 0 || speed > PHY_SPEED_MAX)
return "invalid";
@@ -30,14 +32,16 @@ static char *get_speed_string(u32 speed)
return speed_strings[speed];
 }
 
-static char *get_type_string(u32 type)
+static const char *get_type_string(u32 type)
 {
-   char *type_strings[] = {"UNCONNECTED", "PEX0", "PEX1", "PEX2", "PEX3",
-   "SATA0", "SATA1", "SATA2", "SATA3", "SGMII0",
-   "SGMII1", "SGMII2", "SGMII3", "QSGMII",
-   "USB3_HOST0", "USB3_HOST1", "USB3_DEVICE",
-   "XAUI0", "XAUI1", "XAUI2", "XAUI3",
-   "RXAUI0", "RXAUI1", "SFI", "IGNORE"};
+   static const char * const type_strings[] = {
+   "UNCONNECTED", "PEX0", "PEX1", "PEX2", "PEX3",
+   "SATA0", "SATA1", "SATA2", "SATA3", "SGMII0",
+   "SGMII1", "SGMII2", "SGMII3", "QSGMII",
+   "USB3_HOST0", "USB3_HOST1", "USB3_DEVICE",
+   "XAUI0", "XAUI1", "XAUI2", "XAUI3",
+   "RXAUI0", "RXAUI1", "SFI", "IGNORE"
+   };
 
if (type < 0 || type > PHY_TYPE_MAX)
return "invalid";
@@ -45,44 +49,6 @@ static char *get_type_string(u32 type)
return type_strings[type];
 }
 
-void reg_set(void __iomem *addr, u32 data, u32 mask)
-{
-   debug("Write to address = %#010lx, data = %#010x (mask = %#010x) - ",
- (unsigned long)addr, data, mask);
-   debug("old value = %#010x ==> ", readl(addr));
-   reg_set_silent(addr, data, mask);
-   debug("new value %#010x\n", readl(addr));
-}
-
-void reg_set_silent(void __iomem *addr, u32 data, u32 mask)
-{
-   u32 reg_data;
-
-   reg_data = readl(addr);
-   reg_data &= ~mask;
-   reg_data |= data;
-   writel(reg_data, addr);
-}
-
-void reg_set16(void __iomem *addr, u16 data, u16 mask)
-{
-   debug("Write to address = %#010lx, data = %#06x (mask = %#06x) - ",
- (unsigned long)addr, data, mask);
-   debug("old value = %#06x ==> ", readw(addr));

[U-Boot] [PATCH v2 14/20] driver: clk: Add support for clocks on Armada 37xx

[Marek Behún]

The drivers are based on Linux driver by Gregory Clement.

The TBG clocks support only the .get_rate method.
  - since setting rate is not supported, the driver computes the rates
when probing and so subsequent calls to the .get_rate method do not
read the corresponding registers again

The peripheral clocks support methods .get_rate, .enable and .disable.

  - the .set_parent method theoretically could be supported on some clocks
(the parent would have to be one of the TBG clocks)

  - the .set_rate method would have to try all the divider values to find
the best approximation of a given rate, and it doesn't seem like
this should be needed in U-Boot, therefore not implemented

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 arch/arm/dts/armada-37xx.dtsi  |  20 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/mvebu/Kconfig  |  11 +
 drivers/clk/mvebu/Makefile |   1 +
 drivers/clk/mvebu/armada-37xx-periph.c | 465 +
 drivers/clk/mvebu/armada-37xx-tbg.c| 152 +++
 7 files changed, 651 insertions(+)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index 040e8568e6..c72fd25abc 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -107,6 +107,26 @@
status = "disabled";
};
 
+   nb_periph_clk: nb-periph-clk@13000 {
+   compatible = 
"marvell,armada-3700-periph-clock-nb";
+   reg = <0x13000 0x100>;
+   clocks = < 0>, < 1>, < 2>, < 3>;
+   #clock-cells = <1>;
+   };
+
+   sb_periph_clk: sb-periph-clk@18000 {
+   compatible = 
"marvell,armada-3700-periph-clock-sb";
+   reg = <0x18000 0x100>;
+   clocks = < 0>, < 1>, < 2>, < 3>;
+   #clock-cells = <1>;
+   };
+
+   tbg: tbg@13200 {
+   compatible = "marvell,armada-3700-tbg-clock";
+   reg = <0x13200 0x100>;
+   #clock-cells = <1>;
+   };
+
pinctrl_nb: pinctrl-nb@13800 {
compatible = "marvell,armada3710-nb-pinctrl",
"syscon", "simple-mfd";
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c382e8865f..e182e2ab08 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -88,5 +88,6 @@ source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/renesas/Kconfig"
+source "drivers/clk/mvebu/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e05c607223..73f179be20 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-y += tegra/
 obj-$(CONFIG_ARCH_ASPEED) += aspeed/
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
 obj-$(CONFIG_CLK_AT91) += at91/
+obj-$(CONFIG_CLK_MVEBU) += mvebu/
 obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
new file mode 100644
index 00..e776a15e7b
--- /dev/null
+++ b/drivers/clk/mvebu/Kconfig
@@ -0,0 +1,11 @@
+config CLK_MVEBU
+   bool "MVEBU clock drivers"
+   depends on CLK && ARCH_MVEBU
+   help
+ Enable support for clock present on Marvell MVEBU SoCs.
+
+config CLK_ARMADA_3720
+   bool "Marvell Armada 3720 clock driver"
+   depends on CLK_MVEBU && ARM64
+   help
+ Enable this to support the clocks on Marvell Armada 3720 SoC.
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
new file mode 100644
index 00..7f80313203
--- /dev/null
+++ b/drivers/clk/mvebu/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CLK_ARMADA_3720) += armada-37xx-periph.o armada-37xx-tbg.o
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
b/drivers/clk/mvebu/armada-37xx-periph.c
new file mode 100644
index 00..af08e3df08
--- /dev/null
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Marvell Armada 37xx SoC Peripheral clocks
+ *
+ * Marek Behun 
+ *
+ * Based on Linux driver by:
+ *   Gregory CLEMENT 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TBG_SEL0x0
+#define DIV_SEL0   0x4
+#define DIV_SEL1   0x8
+#define DIV_SEL2   0xC
+#define CLK_SEL0x10
+#define CLK_DIS0x14
+
+enum a37xx_periph_parent 

[U-Boot] [PATCH v2 02/20] phy: marvell: a3700: Use reg_set16 instead of phy_write16

[Marek Behún]

The macro phy_write16 is not used by the rest of the code,
phy_read16 is not used at all.
We also change the macro SGMIIPHY_ADDR to a static inline function.

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.c | 25 ++---
 drivers/phy/marvell/comphy_a3700.h | 15 ---
 2 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index bf92672275..90c9d02e2c 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -611,7 +611,7 @@ static void comphy_sgmii_phy_init(u32 lane, u32 speed)
val = sgmii_phy_init[addr];
}
 
-   phy_write16(lane, addr, val, 0x);
+   reg_set16(sgmiiphy_addr(lane, addr), val, 0x);
}
 }
 
@@ -674,26 +674,26 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
mdelay(10);
 
/* 9. Program COMPHY register PHY_MODE */
-   phy_write16(lane, PHY_PWR_PLL_CTRL_ADDR,
-   PHY_MODE_SGMII << rf_phy_mode_shift, rf_phy_mode_mask);
+   reg_set16(sgmiiphy_addr(lane, PHY_PWR_PLL_CTRL_ADDR),
+ PHY_MODE_SGMII << rf_phy_mode_shift, rf_phy_mode_mask);
 
/*
 * 10. Set COMPHY register REFCLK_SEL to select the correct REFCLK
 * source
 */
-   phy_write16(lane, PHY_MISC_REG0_ADDR, 0, rb_ref_clk_sel);
+   reg_set16(sgmiiphy_addr(lane, PHY_MISC_REG0_ADDR), 0, rb_ref_clk_sel);
 
/*
 * 11. Set correct reference clock frequency in COMPHY register
 * REF_FREF_SEL.
 */
if (get_ref_clk() == 40) {
-   phy_write16(lane, PHY_PWR_PLL_CTRL_ADDR,
-   0x4 << rf_ref_freq_sel_shift, rf_ref_freq_sel_mask);
+   reg_set16(sgmiiphy_addr(lane, PHY_PWR_PLL_CTRL_ADDR),
+ 0x4 << rf_ref_freq_sel_shift, rf_ref_freq_sel_mask);
} else {
/* 25MHz */
-   phy_write16(lane, PHY_PWR_PLL_CTRL_ADDR,
-   0x1 << rf_ref_freq_sel_shift, rf_ref_freq_sel_mask);
+   reg_set16(sgmiiphy_addr(lane, PHY_PWR_PLL_CTRL_ADDR),
+ 0x1 << rf_ref_freq_sel_shift, rf_ref_freq_sel_mask);
}
 
/* 12. Program COMPHY register PHY_GEN_MAX[1:0] */
@@ -709,7 +709,8 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
 * bus width
 */
/* 10bit */
-   phy_write16(lane, PHY_DIG_LB_EN_ADDR, 0, rf_data_width_mask);
+   reg_set16(sgmiiphy_addr(lane, PHY_DIG_LB_EN_ADDR), 0,
+ rf_data_width_mask);
 
/*
 * 14. As long as DFE function needs to be enabled in any mode,
@@ -752,10 +753,12 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
 * 18. Check the PHY Polarity invert bit
 */
if (invert & PHY_POLARITY_TXD_INVERT)
-   phy_write16(lane, PHY_SYNC_PATTERN_ADDR, phy_txd_inv, 0);
+   reg_set16(sgmiiphy_addr(lane, PHY_SYNC_PATTERN_ADDR),
+ phy_txd_inv, 0);
 
if (invert & PHY_POLARITY_RXD_INVERT)
-   phy_write16(lane, PHY_SYNC_PATTERN_ADDR, phy_rxd_inv, 0);
+   reg_set16(sgmiiphy_addr(lane, PHY_SYNC_PATTERN_ADDR),
+ phy_rxd_inv, 0);
 
/*
 * 19. Set PHY input ports PIN_PU_PLL, PIN_PU_TX and PIN_PU_RX to 1
diff --git a/drivers/phy/marvell/comphy_a3700.h 
b/drivers/phy/marvell/comphy_a3700.h
index 33d1f3f77d..40f4638e15 100644
--- a/drivers/phy/marvell/comphy_a3700.h
+++ b/drivers/phy/marvell/comphy_a3700.h
@@ -61,13 +61,14 @@
 #define USB32_CTRL_BASEMVEBU_REG(0x05D800)
 #define USB3PHY_SHFT   2
 
-#define SGMIIPHY_BASE(l)   (l == 1 ? USB3PHY_BASE : PCIEPHY_BASE)
-#define SGMIIPHY_ADDR(l, a)\
-   ((void __iomem *)(((a & 0x7FF) * 2) + SGMIIPHY_BASE(l)))
-
-#define phy_read16(l, a)   read16((void __iomem *)SGMIIPHY_ADDR(l, a))
-#define phy_write16(l, a, data, mask)  \
-   reg_set16(SGMIIPHY_ADDR(l, a), data, mask)
+static inline void __iomem *sgmiiphy_addr(u32 lane, u32 addr)
+{
+   addr = (addr & 0x7FF) * 2;
+   if (lane == 1)
+   return PCIEPHY_BASE + addr;
+   else
+   return USB3PHY_BASE + addr;
+}
 
 /* units */
 #define PCIE   1
-- 
2.16.1

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

[U-Boot] [PATCH v2 08/20] phy: marvell: a3700: Set USB3 RX wait depending on ref clock

[Marek Behún]

According to specification, CFG_PM_RXDLOZ_WAIT should be set to 0x7
when reference clock is at 25 MHz. The specification (at least the
version I have) does not mentoin the setting for 40 MHz reference
clock, but Marvell's U-Boot sets 0xC in that case.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy_a3700.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index bcfe89e636..82dffc4f83 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -383,20 +383,18 @@ static int comphy_usb3_power_up(u32 lane, u32 type, u32 
speed, u32 invert)
/*
 * 3. Check crystal jumper setting and program the Power and PLL
 * Control accordingly
+* 4. Change RX wait
 */
if (get_ref_clk() == 40) {
/* 40 MHz */
usb3_reg_set16(PWR_PLL_CTRL, 0xFCA3, 0x, lane);
+   usb3_reg_set16(PWR_MGM_TIM1, 0x10C, 0x, lane);
} else {
/* 25 MHz */
usb3_reg_set16(PWR_PLL_CTRL, 0xFCA2, 0x, lane);
+   usb3_reg_set16(PWR_MGM_TIM1, 0x107, 0x, lane);
}
 
-   /*
-* 4. Change RX wait
-*/
-   usb3_reg_set16(PWR_MGM_TIM1, 0x10C, 0x, lane);
-
/*
 * 5. Enable idle sync
 */
-- 
2.16.1

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

[U-Boot] [PATCH v2 03/20] phy: marvell: a3700: Don't create functional macro for each register

[Marek Behún]

Currently there is for each register special functional macro, ie:
  LANE_CFG1_ADDR(u)
  GLOB_CLK_SRC_LO_ADDR(u)
  ...
where can be either PCIE or USB3.

Change this to one function PHY_ADDR(unit, addr). The code becomes:
  phy_addr(PCIE, LANE_CFG1)
  phy_addr(PCIE, GLOB_CLK_SRC_LO)
  ...

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.c | 108 ++---
 drivers/phy/marvell/comphy_a3700.h |  92 +--
 2 files changed, 89 insertions(+), 111 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 90c9d02e2c..702ddd7db2 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -141,72 +141,70 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
/*
 * 1. Enable max PLL.
 */
-   reg_set16(LANE_CFG1_ADDR(PCIE), bf_use_max_pll_rate, 0);
+   reg_set16(phy_addr(PCIE, LANE_CFG1), bf_use_max_pll_rate, 0);
 
/*
 * 2. Select 20 bit SERDES interface.
 */
-   reg_set16(GLOB_CLK_SRC_LO_ADDR(PCIE), bf_cfg_sel_20b, 0);
+   reg_set16(phy_addr(PCIE, GLOB_CLK_SRC_LO), bf_cfg_sel_20b, 0);
 
/*
 * 3. Force to use reg setting for PCIe mode
 */
-   reg_set16(MISC_REG1_ADDR(PCIE), bf_sel_bits_pcie_force, 0);
+   reg_set16(phy_addr(PCIE, MISC_REG1), bf_sel_bits_pcie_force, 0);
 
/*
 * 4. Change RX wait
 */
-   reg_set16(PWR_MGM_TIM1_ADDR(PCIE), 0x10C, 0x);
+   reg_set16(phy_addr(PCIE, PWR_MGM_TIM1), 0x10C, 0x);
 
/*
 * 5. Enable idle sync
 */
-   reg_set16(UNIT_CTRL_ADDR(PCIE), 0x60 | rb_idle_sync_en, 0x);
+   reg_set16(phy_addr(PCIE, UNIT_CTRL), 0x60 | rb_idle_sync_en, 0x);
 
/*
 * 6. Enable the output of 100M/125M/500M clock
 */
-   reg_set16(MISC_REG0_ADDR(PCIE),
+   reg_set16(phy_addr(PCIE, MISC_REG0),
  0xA00D | rb_clk500m_en | rb_clk100m_125m_en, 0x);
 
/*
 * 7. Enable TX
 */
-   reg_set(PHY_REF_CLK_ADDR, 0x1342, 0x);
+   reg_set(PCIE_REF_CLK_ADDR, 0x1342, 0x);
 
/*
 * 8. Check crystal jumper setting and program the Power and PLL
 *Control accordingly
 */
if (get_ref_clk() == 40) {
-   reg_set16(PWR_PLL_CTRL_ADDR(PCIE),
- 0xFC63, 0x); /* 40 MHz */
+   /* 40 MHz */
+   reg_set16(phy_addr(PCIE, PWR_PLL_CTRL), 0xFC63, 0x);
} else {
-   reg_set16(PWR_PLL_CTRL_ADDR(PCIE),
- 0xFC62, 0x); /* 25 MHz */
+   /* 25 MHz */
+   reg_set16(phy_addr(PCIE, PWR_PLL_CTRL), 0xFC62, 0x);
}
 
/*
 * 9. Override Speed_PLL value and use MAC PLL
 */
-   reg_set16(KVCO_CAL_CTRL_ADDR(PCIE), 0x0040 | rb_use_max_pll_rate,
+   reg_set16(phy_addr(PCIE, KVCO_CAL_CTRL), 0x0040 | rb_use_max_pll_rate,
  0x);
 
/*
 * 10. Check the Polarity invert bit
 */
-   if (invert & PHY_POLARITY_TXD_INVERT) {
-   reg_set16(SYNC_PATTERN_ADDR(PCIE), phy_txd_inv, 0);
-   }
+   if (invert & PHY_POLARITY_TXD_INVERT)
+   reg_set16(phy_addr(PCIE, SYNC_PATTERN), phy_txd_inv, 0);
 
-   if (invert & PHY_POLARITY_RXD_INVERT) {
-   reg_set16(SYNC_PATTERN_ADDR(PCIE), phy_rxd_inv, 0);
-   }
+   if (invert & PHY_POLARITY_RXD_INVERT)
+   reg_set16(phy_addr(PCIE, SYNC_PATTERN), phy_rxd_inv, 0);
 
/*
 * 11. Release SW reset
 */
-   reg_set16(GLOB_PHY_CTRL0_ADDR(PCIE),
+   reg_set16(phy_addr(PCIE, GLOB_PHY_CTRL0),
  rb_mode_core_clk_freq_sel | rb_mode_pipe_width_32,
  bf_soft_rst | bf_mode_refdiv);
 
@@ -214,11 +212,11 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
udelay(PLL_SET_DELAY_US);
 
/* Assert PCLK enabled */
-   ret = comphy_poll_reg(LANE_STAT1_ADDR(PCIE),/* address */
- rb_txdclk_pclk_en,/* value */
- rb_txdclk_pclk_en,/* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
- POLL_16B_REG);/* 16bit */
+   ret = comphy_poll_reg(phy_addr(PCIE, LANE_STAT1),   /* address */
+ rb_txdclk_pclk_en,/* value */
+ rb_txdclk_pclk_en,/* mask */
+ PLL_LOCK_TIMEOUT, /* timeout */
+ POLL_16B_REG);/* 16bit */
if (ret == 0)
printf("Failed to lock PCIe PLL\n");
 
@@ -322,7 +320,7 @@ static int comphy_usb3_power_up(u32 type, u32 speed, u32 
invert)
 
/* 0xd005c300 = 

[U-Boot] [PATCH v2 04/20] phy: marvell: a3700: Use same timeout for all register polling

[Marek Behún]

The timeout is set to PLL_LOCK_TIMEOUT in every call to
comphy_poll_reg. Remove this parameter from the function.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy_a3700.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 702ddd7db2..0c06c00796 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -106,12 +106,11 @@ static u16 sgmii_phy_init[512] = {
  *
  * return: 1 on success, 0 on timeout
  */
-static u32 comphy_poll_reg(void *addr, u32 val, u32 mask, u32 timeout,
-  u8 op_type)
+static u32 comphy_poll_reg(void *addr, u32 val, u32 mask, u8 op_type)
 {
-   u32 rval = 0xDEAD;
+   u32 rval = 0xDEAD, timeout;
 
-   for (; timeout > 0; timeout--) {
+   for (timeout = PLL_LOCK_TIMEOUT; timeout > 0; timeout--) {
if (op_type == POLL_16B_REG)
rval = readw(addr); /* 16 bit */
else
@@ -215,7 +214,6 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
ret = comphy_poll_reg(phy_addr(PCIE, LANE_STAT1),   /* address */
  rb_txdclk_pclk_en,/* value */
  rb_txdclk_pclk_en,/* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_16B_REG);/* 16bit */
if (ret == 0)
printf("Failed to lock PCIe PLL\n");
@@ -285,7 +283,6 @@ static int comphy_sata_power_up(void)
ret = comphy_poll_reg(rh_vsreg_data,/* address */
  bs_pll_ready_tx,  /* value */
  bs_pll_ready_tx,  /* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
if (ret == 0)
printf("Failed to lock SATA PLL\n");
@@ -415,7 +412,6 @@ static int comphy_usb3_power_up(u32 type, u32 speed, u32 
invert)
ret = comphy_poll_reg(phy_addr(USB3, LANE_STAT1),   /* address */
  rb_txdclk_pclk_en,/* value */
  rb_txdclk_pclk_en,/* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_16B_REG);/* 16bit */
if (ret == 0)
printf("Failed to lock USB3 PLL\n");
@@ -496,7 +492,6 @@ static int comphy_usb2_power_up(u8 usb32)
ret = comphy_poll_reg(USB2_PHY_CAL_CTRL_ADDR(usb32),
  rb_usb2phy_pllcal_done,   /* value */
  rb_usb2phy_pllcal_done,   /* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
if (ret == 0)
printf("Failed to end USB2 PLL calibration\n");
@@ -505,7 +500,6 @@ static int comphy_usb2_power_up(u8 usb32)
ret = comphy_poll_reg(USB2_PHY_CAL_CTRL_ADDR(usb32),
  rb_usb2phy_impcal_done,   /* value */
  rb_usb2phy_impcal_done,   /* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
if (ret == 0)
printf("Failed to end USB2 impedance calibration\n");
@@ -514,7 +508,6 @@ static int comphy_usb2_power_up(u8 usb32)
ret = comphy_poll_reg(USB2_PHY_RX_CHAN_CTRL1_ADDR(usb32),
  rb_usb2phy_sqcal_done,/* value */
  rb_usb2phy_sqcal_done,/* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
if (ret == 0)
printf("Failed to end USB2 unknown calibration\n");
@@ -523,7 +516,6 @@ static int comphy_usb2_power_up(u8 usb32)
ret = comphy_poll_reg(USB2_PHY_PLL_CTRL0_ADDR(usb32),
  rb_usb2phy_pll_ready, /* value */
  rb_usb2phy_pll_ready, /* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
 
if (ret == 0)
@@ -773,7 +765,6 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
ret = comphy_poll_reg(COMPHY_PHY_STAT1_ADDR(lane),  /* address */
  rb_pll_ready_tx | rb_pll_ready_rx, /* value */
  rb_pll_ready_tx | rb_pll_ready_rx, /* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
  POLL_32B_REG);/* 32bit */
if (ret == 0)
   

[U-Boot] [PATCH v2 11/20] phy: marvell: a3700: Fix SGMII cfg and stat register addresses

[Marek Behún]

The register addresses on lanes 0 and 1 are switched, first comes 1 and
then 0.

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.h 
b/drivers/phy/marvell/comphy_a3700.h
index 952d28e221..2468468162 100644
--- a/drivers/phy/marvell/comphy_a3700.h
+++ b/drivers/phy/marvell/comphy_a3700.h
@@ -25,7 +25,7 @@
 #define COMPHY_SEL_ADDRMVEBU_REG(0x0183FC)
 #define rf_compy_select(lane)  (0x1 << (((lane) == 1) ? 4 : 0))
 
-#define COMPHY_PHY_CFG1_ADDR(lane) MVEBU_REG(0x018300 + (lane) * 0x28)
+#define COMPHY_PHY_CFG1_ADDR(lane) MVEBU_REG(0x018300 + (1 - lane) * 0x28)
 #define rb_pin_pu_iveref   BIT(1)
 #define rb_pin_reset_core  BIT(11)
 #define rb_pin_reset_comphyBIT(12)
@@ -39,7 +39,7 @@
 #define rf_gen_tx_select   (0x0F << rf_gen_tx_sel_shift)
 #define rb_phy_rx_init BIT(30)
 
-#define COMPHY_PHY_STAT1_ADDR(lane)MVEBU_REG(0x018318 + (lane) * 0x28)
+#define COMPHY_PHY_STAT1_ADDR(lane)MVEBU_REG(0x018318 + (1 - lane) * 0x28)
 #define rb_rx_init_doneBIT(0)
 #define rb_pll_ready_rxBIT(2)
 #define rb_pll_ready_txBIT(3)
-- 
2.16.1

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

[U-Boot] [PATCH v2 00/20] More support for Armada 37xx boards (for Turris Mox)

[Marek Behún]

This is the second version of patches for updating the support of Armada 37xx
devices. Here I also send first version of code which adds basic support for the
Turris Mox board, a router currently being developed here at CZ.NIC, which is
being crowdfunded now on Indiegogo.

Changes since v1:
  - these patches were removed, since the update has already been merged into
U-Boot:
  arm64: mvebu_armada_37xx: Use Armada 37xx pinctrl driver by default
  armada-37xx: Fix SB pinctrl groups according to new revision
  - I have changed the names of the functions SGMIIPHY_ADDR and PHY_ADDR to
lowercase, as Stefan requested
  - I have used checkpatch on the patches. There still are come warnings, like
"added, moved or deleted file(s), does MAINTAINERS need updating?" or
"line over 80 characters" (long string constant in dts). How should I solve
these?
  - some minor changes based on comments from Stefan
  - added a patch to fix SGMII register addresses
  - added a patch which adds support for the CPU watchdog on Armada 3720
  - added a patch which adds basic support for the Turris Mox board

Please review.

Marek Behun

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

[U-Boot] [PATCH v2 05/20] phy: marvell: a3700: Use (!ret) instead of (ret == 0)

[Marek Behún]

In U-Boot it is usually written this way.

Signed-off-by: Marek Behun 
Reviewed-by: Stefan Roese 
---
 drivers/phy/marvell/comphy_a3700.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 0c06c00796..429ad6b018 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -215,7 +215,7 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
  rb_txdclk_pclk_en,/* value */
  rb_txdclk_pclk_en,/* mask */
  POLL_16B_REG);/* 16bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to lock PCIe PLL\n");
 
debug_exit();
@@ -284,7 +284,7 @@ static int comphy_sata_power_up(void)
  bs_pll_ready_tx,  /* value */
  bs_pll_ready_tx,  /* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to lock SATA PLL\n");
 
debug_exit();
@@ -413,7 +413,7 @@ static int comphy_usb3_power_up(u32 type, u32 speed, u32 
invert)
  rb_txdclk_pclk_en,/* value */
  rb_txdclk_pclk_en,/* mask */
  POLL_16B_REG);/* 16bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to lock USB3 PLL\n");
 
/*
@@ -493,7 +493,7 @@ static int comphy_usb2_power_up(u8 usb32)
  rb_usb2phy_pllcal_done,   /* value */
  rb_usb2phy_pllcal_done,   /* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to end USB2 PLL calibration\n");
 
/* Assert impedance calibration done */
@@ -501,7 +501,7 @@ static int comphy_usb2_power_up(u8 usb32)
  rb_usb2phy_impcal_done,   /* value */
  rb_usb2phy_impcal_done,   /* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to end USB2 impedance calibration\n");
 
/* Assert squetch calibration done */
@@ -509,7 +509,7 @@ static int comphy_usb2_power_up(u8 usb32)
  rb_usb2phy_sqcal_done,/* value */
  rb_usb2phy_sqcal_done,/* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to end USB2 unknown calibration\n");
 
/* Assert PLL is ready */
@@ -518,7 +518,7 @@ static int comphy_usb2_power_up(u8 usb32)
  rb_usb2phy_pll_ready, /* mask */
  POLL_32B_REG);/* 32bit */
 
-   if (ret == 0)
+   if (!ret)
printf("Failed to lock USB2 PLL\n");
 
debug_exit();
@@ -766,7 +766,7 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
  rb_pll_ready_tx | rb_pll_ready_rx, /* value */
  rb_pll_ready_tx | rb_pll_ready_rx, /* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to lock PLL for SGMII PHY %d\n", lane);
 
/*
@@ -788,7 +788,7 @@ static int comphy_sgmii_power_up(u32 lane, u32 speed, u32 
invert)
  rb_rx_init_done,  /* value */
  rb_rx_init_done,  /* mask */
  POLL_32B_REG);/* 32bit */
-   if (ret == 0)
+   if (!ret)
printf("Failed to init RX of SGMII PHY %d\n", lane);
 
debug_exit();
@@ -819,7 +819,7 @@ void comphy_dedicated_phys_init(void)
if (node > 0) {
if (fdtdec_get_is_enabled(blob, node)) {
ret = comphy_usb2_power_up(usb32);
-   if (ret == 0)
+   if (!ret)
printf("Failed to initialize UTMI 
PHY\n");
else
debug("UTMI PHY init succeed\n");
@@ -837,7 +837,7 @@ void comphy_dedicated_phys_init(void)
if (node > 0) {
if (fdtdec_get_is_enabled(blob, node)) {
ret = comphy_sata_power_up();
-   if (ret == 0)
+   if (!ret)
printf("Failed to initialize SATA PHY\n");
else

[U-Boot] [PATCH v2 01/20] phy: marvell: a3700: Change return type of macro MVEBU_REG

[Marek Behún]

All the calls to reg_set and friends have to cast the first argument
to void __iomem *. Lets change the return type of the MVEBU_REG macro
instead.

Signed-off-by: Marek Behun 
---
 drivers/phy/marvell/comphy_a3700.c | 206 -
 drivers/phy/marvell/comphy_a3700.h |   8 +-
 2 files changed, 96 insertions(+), 118 deletions(-)

diff --git a/drivers/phy/marvell/comphy_a3700.c 
b/drivers/phy/marvell/comphy_a3700.c
index 5afd23c052..bf92672275 100644
--- a/drivers/phy/marvell/comphy_a3700.c
+++ b/drivers/phy/marvell/comphy_a3700.c
@@ -141,78 +141,72 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
/*
 * 1. Enable max PLL.
 */
-   reg_set16((void __iomem *)LANE_CFG1_ADDR(PCIE),
- bf_use_max_pll_rate, 0);
+   reg_set16(LANE_CFG1_ADDR(PCIE), bf_use_max_pll_rate, 0);
 
/*
 * 2. Select 20 bit SERDES interface.
 */
-   reg_set16((void __iomem *)GLOB_CLK_SRC_LO_ADDR(PCIE),
- bf_cfg_sel_20b, 0);
+   reg_set16(GLOB_CLK_SRC_LO_ADDR(PCIE), bf_cfg_sel_20b, 0);
 
/*
 * 3. Force to use reg setting for PCIe mode
 */
-   reg_set16((void __iomem *)MISC_REG1_ADDR(PCIE),
- bf_sel_bits_pcie_force, 0);
+   reg_set16(MISC_REG1_ADDR(PCIE), bf_sel_bits_pcie_force, 0);
 
/*
 * 4. Change RX wait
 */
-   reg_set16((void __iomem *)PWR_MGM_TIM1_ADDR(PCIE), 0x10C, 0x);
+   reg_set16(PWR_MGM_TIM1_ADDR(PCIE), 0x10C, 0x);
 
/*
 * 5. Enable idle sync
 */
-   reg_set16((void __iomem *)UNIT_CTRL_ADDR(PCIE),
- 0x60 | rb_idle_sync_en, 0x);
+   reg_set16(UNIT_CTRL_ADDR(PCIE), 0x60 | rb_idle_sync_en, 0x);
 
/*
 * 6. Enable the output of 100M/125M/500M clock
 */
-   reg_set16((void __iomem *)MISC_REG0_ADDR(PCIE),
+   reg_set16(MISC_REG0_ADDR(PCIE),
  0xA00D | rb_clk500m_en | rb_clk100m_125m_en, 0x);
 
/*
 * 7. Enable TX
 */
-   reg_set((void __iomem *)PHY_REF_CLK_ADDR, 0x1342, 0x);
+   reg_set(PHY_REF_CLK_ADDR, 0x1342, 0x);
 
/*
 * 8. Check crystal jumper setting and program the Power and PLL
 *Control accordingly
 */
if (get_ref_clk() == 40) {
-   reg_set16((void __iomem *)PWR_PLL_CTRL_ADDR(PCIE),
+   reg_set16(PWR_PLL_CTRL_ADDR(PCIE),
  0xFC63, 0x); /* 40 MHz */
} else {
-   reg_set16((void __iomem *)PWR_PLL_CTRL_ADDR(PCIE),
+   reg_set16(PWR_PLL_CTRL_ADDR(PCIE),
  0xFC62, 0x); /* 25 MHz */
}
 
/*
 * 9. Override Speed_PLL value and use MAC PLL
 */
-   reg_set16((void __iomem *)KVCO_CAL_CTRL_ADDR(PCIE),
- 0x0040 | rb_use_max_pll_rate, 0x);
+   reg_set16(KVCO_CAL_CTRL_ADDR(PCIE), 0x0040 | rb_use_max_pll_rate,
+ 0x);
 
/*
 * 10. Check the Polarity invert bit
 */
if (invert & PHY_POLARITY_TXD_INVERT) {
-   reg_set16((void __iomem *)SYNC_PATTERN_ADDR(PCIE),
- phy_txd_inv, 0);
+   reg_set16(SYNC_PATTERN_ADDR(PCIE), phy_txd_inv, 0);
}
 
if (invert & PHY_POLARITY_RXD_INVERT) {
-   reg_set16((void __iomem *)SYNC_PATTERN_ADDR(PCIE),
- phy_rxd_inv, 0);
+   reg_set16(SYNC_PATTERN_ADDR(PCIE), phy_rxd_inv, 0);
}
 
/*
 * 11. Release SW reset
 */
-   reg_set16((void __iomem *)GLOB_PHY_CTRL0_ADDR(PCIE),
+   reg_set16(GLOB_PHY_CTRL0_ADDR(PCIE),
  rb_mode_core_clk_freq_sel | rb_mode_pipe_width_32,
  bf_soft_rst | bf_mode_refdiv);
 
@@ -220,11 +214,11 @@ static int comphy_pcie_power_up(u32 speed, u32 invert)
udelay(PLL_SET_DELAY_US);
 
/* Assert PCLK enabled */
-   ret = comphy_poll_reg((void *)LANE_STAT1_ADDR(PCIE),/* address */
- rb_txdclk_pclk_en,/* value */
- rb_txdclk_pclk_en,/* mask */
- PLL_LOCK_TIMEOUT, /* timeout */
- POLL_16B_REG);/* 16bit */
+   ret = comphy_poll_reg(LANE_STAT1_ADDR(PCIE),/* address */
+ rb_txdclk_pclk_en,/* value */
+ rb_txdclk_pclk_en,/* mask */
+ PLL_LOCK_TIMEOUT, /* timeout */
+ POLL_16B_REG);/* 16bit */
if (ret == 0)
printf("Failed to lock PCIe PLL\n");
 
@@ -248,57 +242,53 @@ static int comphy_sata_power_up(void)
/*
 * 0. Swap SATA TX lines
 */
-   reg_set((void __iomem *)rh_vsreg_addr,
-   

Re: [U-Boot] [RFC PATCH 4/5] arm: v7R: Add support for MPU

[Lokesh Vutla]

On Tuesday 24 April 2018 08:38 PM, Tom Rini wrote:
> On Tue, Apr 24, 2018 at 08:32:40PM +0530, Lokesh Vutla wrote:
>>
>>
>> On Tuesday 24 April 2018 06:50 PM, Tom Rini wrote:
>>> On Tue, Apr 24, 2018 at 06:24:47PM +0530, Lokesh Vutla wrote:
>>>
 The Memory Protection Unit(MPU) allows to partition memory into regions
 and set individual protection attributes for each region. In absence
 of MPU a default map[1] will take effect. Add support for configuring
 MPU on Cortex-R, by reusing the existing support for Cortex-M processor.

 [1] 
 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1002400.html

 Signed-off-by: Lokesh Vutla 
 ---
  arch/arm/Kconfig  |  11 +++
  arch/arm/cpu/armv7/Makefile   |   2 +
  arch/arm/cpu/armv7/mpu_v7r.c  | 109 ++
  arch/arm/cpu/armv7m/Makefile  |   3 +-
  arch/arm/cpu/armv7m/mpu.c |  41 +--
  arch/arm/include/asm/armv7m_mpu.h |  69 +++
>>>
>>> How close are armv7/mpu_v7r.c and armv7m/mpu.c ?  If we did some
>>> underlying work so that armv7m/ and be put into armv7/ (and we introduce
>>> CPU_V7A say, as I mentioned in another part of the thread so the
>>> Makefile isn't too ugly) could we have a single mpu.c file, cleanly?
>>>
>>
>> I did start with that but found out that the way we program the mpu
>> registers are entirely different. For v7m mmio registers are used, but
>> for v7r system registers are used. I couldn't find a way to get a common
>> driver for these two. If you prefer #ifdefs and merged these two, I can
>> do it but it doesn't look clean.
> 
> OK, if it's not clean then it's not clean.  But lets go for consistent
> file naming.  And how about adding a CPU_V7A flag so that we could dump

okay. Will try to create CPU_V7A flag and see how things looks like.

Thanks and regards,
Lokesh

> the armv7m directory in?  Then mpu_v7[mr].c would make sense too.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 4/5] arm: v7R: Add support for MPU

[Tom Rini]

On Tue, Apr 24, 2018 at 08:32:40PM +0530, Lokesh Vutla wrote:
> 
> 
> On Tuesday 24 April 2018 06:50 PM, Tom Rini wrote:
> > On Tue, Apr 24, 2018 at 06:24:47PM +0530, Lokesh Vutla wrote:
> > 
> >> The Memory Protection Unit(MPU) allows to partition memory into regions
> >> and set individual protection attributes for each region. In absence
> >> of MPU a default map[1] will take effect. Add support for configuring
> >> MPU on Cortex-R, by reusing the existing support for Cortex-M processor.
> >>
> >> [1] 
> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1002400.html
> >>
> >> Signed-off-by: Lokesh Vutla 
> >> ---
> >>  arch/arm/Kconfig  |  11 +++
> >>  arch/arm/cpu/armv7/Makefile   |   2 +
> >>  arch/arm/cpu/armv7/mpu_v7r.c  | 109 ++
> >>  arch/arm/cpu/armv7m/Makefile  |   3 +-
> >>  arch/arm/cpu/armv7m/mpu.c |  41 +--
> >>  arch/arm/include/asm/armv7m_mpu.h |  69 +++
> > 
> > How close are armv7/mpu_v7r.c and armv7m/mpu.c ?  If we did some
> > underlying work so that armv7m/ and be put into armv7/ (and we introduce
> > CPU_V7A say, as I mentioned in another part of the thread so the
> > Makefile isn't too ugly) could we have a single mpu.c file, cleanly?
> > 
> 
> I did start with that but found out that the way we program the mpu
> registers are entirely different. For v7m mmio registers are used, but
> for v7r system registers are used. I couldn't find a way to get a common
> driver for these two. If you prefer #ifdefs and merged these two, I can
> do it but it doesn't look clean.

OK, if it's not clean then it's not clean.  But lets go for consistent
file naming.  And how about adding a CPU_V7A flag so that we could dump
the armv7m directory in?  Then mpu_v7[mr].c would make sense too.

-- 
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] [RFC PATCH 0/5] arm: Introduce v7R support

[Lokesh Vutla]

Hi Michal,

On Tuesday 24 April 2018 08:06 PM, Michal Simek wrote:
> Hi Lokesh,
> 
> On 24.4.2018 14:54, Lokesh Vutla wrote:
>> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
>> real-time systems. It implements the ARMv7-R architecture, and includes
>> Thumb-2 technology for optimum code density and processing throughput.
>>
>> Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
>> features are compatible with v7 architecture. This series adds minimal
>> support for v7-R architecture by reusing the v7 support. Also adding
>> support for MPU.
>>
>> Lokesh Vutla (4):
>>   arm: v7: Update VBAR only if available
>>   arm: Kconfig: Add entry for MMU
>>   arm: v7R: Add support for MPU
>>   arm: v7R: Add support for enabling caches
>>
>> Michal Simek (1):
>>   arm: v7R: Add initial support
>>
>>  arch/arm/Kconfig  |  33 
>>  arch/arm/Makefile |   2 +
>>  arch/arm/cpu/armv7/Makefile   |   2 +
>>  arch/arm/cpu/armv7/mpu_v7r.c  | 120 ++
>>  arch/arm/cpu/armv7/start.S|   4 +
>>  arch/arm/cpu/armv7m/Makefile  |   3 +-
>>  arch/arm/cpu/armv7m/mpu.c |  41 +-
>>  arch/arm/include/asm/armv7m_mpu.h |  69 +
>>  arch/arm/lib/Makefile |   5 +-
>>  arch/arm/lib/cache-cp15.c |  14 +++-
>>  10 files changed, 248 insertions(+), 45 deletions(-)
>>  create mode 100644 arch/arm/cpu/armv7/mpu_v7r.c
>>
> 
> I have tested your series, also wired MPU (protect one region and try to
> access it) and with caches on and off (running mtest to see number of
> iterations and improving numbers with cache on) and nothing is showing
> any functional fundamental problem.

Thanks a lot for testing. Can I take it as your Tested-by:?

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

Re: [U-Boot] [RFC PATCH 5/5] arm: v7R: Add support for enabling caches

[Lokesh Vutla]

On Tuesday 24 April 2018 06:50 PM, Tom Rini wrote:
> On Tue, Apr 24, 2018 at 06:24:48PM +0530, Lokesh Vutla wrote:
> 
>> Cache maintenance procedure is same for v7 and v7R
>> processors. So re-use cache-cp15.c file except for
>> mmu parts.
> 
> I also don't like CONFIG_MMU as it's too generic of a name.  Since for
> this part of the series we need a flag for "we have an MMU we need to
> fiddle", CONFIG_SYS_ARM_MMU ?  Thanks!
> 

okay will make it CONFIG_SYS_ARM_MMU instead.

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

Re: [U-Boot] [RFC PATCH 4/5] arm: v7R: Add support for MPU

[Lokesh Vutla]

On Tuesday 24 April 2018 06:50 PM, Tom Rini wrote:
> On Tue, Apr 24, 2018 at 06:24:47PM +0530, Lokesh Vutla wrote:
> 
>> The Memory Protection Unit(MPU) allows to partition memory into regions
>> and set individual protection attributes for each region. In absence
>> of MPU a default map[1] will take effect. Add support for configuring
>> MPU on Cortex-R, by reusing the existing support for Cortex-M processor.
>>
>> [1] 
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1002400.html
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/Kconfig  |  11 +++
>>  arch/arm/cpu/armv7/Makefile   |   2 +
>>  arch/arm/cpu/armv7/mpu_v7r.c  | 109 ++
>>  arch/arm/cpu/armv7m/Makefile  |   3 +-
>>  arch/arm/cpu/armv7m/mpu.c |  41 +--
>>  arch/arm/include/asm/armv7m_mpu.h |  69 +++
> 
> How close are armv7/mpu_v7r.c and armv7m/mpu.c ?  If we did some
> underlying work so that armv7m/ and be put into armv7/ (and we introduce
> CPU_V7A say, as I mentioned in another part of the thread so the
> Makefile isn't too ugly) could we have a single mpu.c file, cleanly?
> 

I did start with that but found out that the way we program the mpu
registers are entirely different. For v7m mmio registers are used, but
for v7r system registers are used. I couldn't find a way to get a common
driver for these two. If you prefer #ifdefs and merged these two, I can
do it but it doesn't look clean.

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

Re: [U-Boot] [RFC PATCH 3/5] arm: Kconfig: Add entry for MMU

[Lokesh Vutla]

On Tuesday 24 April 2018 06:50 PM, Tom Rini wrote:
> On Tue, Apr 24, 2018 at 06:24:46PM +0530, Lokesh Vutla wrote:
> 
>> Add a Kconfig entry for MMU and imply for all platforms
>> using cache-cp15.c. Using imply instead of select so that
>> MMU can be disabled by defconfigs when not needed.
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  arch/arm/Kconfig  | 15 +++
>>  arch/arm/lib/Makefile |  6 +-
>>  2 files changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index de36ab6701..fe5bff097d 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -74,6 +74,12 @@ config ARM_ASM_UNIFIED
>>  config THUMB2_KERNEL
>>  bool
>>  
>> +config MMU
>> +bool "MMU-based Paged Memory Management Support"
>> +help
>> +  Select if you want MMU-based virtualised addressing space
>> +  support by paged memory management.
>> +
>>  # If set, the workarounds for these ARM errata are applied early during 
>> U-Boot
>>  # startup. Note that in general these options force the workarounds to be
>>  # applied; no CPU-type/version detection exists, unlike the similar options 
>> in
>> @@ -158,33 +164,40 @@ config ARM_ERRATA_855873
>>  config CPU_ARM720T
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_ARM920T
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_ARM926EJS
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_ARM946ES
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_ARM1136
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_ARM1176
>>  bool
>>  select HAS_VBAR
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_V7
>>  bool
>>  select HAS_VBAR
>>  select HAS_THUMB2
>>  select SYS_CACHE_SHIFT_6
>> +imply MMU
>>  
>>  config CPU_V7M
>>  bool
>> @@ -200,10 +213,12 @@ config CPU_V7R
>>  config CPU_PXA
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config CPU_SA1100
>>  bool
>>  select SYS_CACHE_SHIFT_5
>> +imply MMU
>>  
>>  config SYS_CPU
>>  default "arm720t" if CPU_ARM720T
>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>> index 3d3085e917..f907adc161 100644
>> --- a/arch/arm/lib/Makefile
>> +++ b/arch/arm/lib/Makefile
>> @@ -63,11 +63,7 @@ obj-y += reset.o
>>  endif
>>  
>>  obj-y   += cache.o
>> -ifndef CONFIG_ARM64
>> -ifndef CONFIG_CPU_V7M
>> -obj-y   += cache-cp15.o
>> -endif
>> -endif
>> +obj-$(CONFIG_MMU)   += cache-cp15.o
>>  
>>  obj-y   += psci-dt.o
> 
> So, funny enough.  We have CONFIG_MMU code in ARM today that I bet
> doesn't work and is just copy/pasted from the kernel and we should drop.
> 
> For right here, I think I'd rather see some CONFIG flag about
> CONFIG_SYS_ARM_CACHE_CP15 instead.

Sure will update it in next version.

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

Re: [U-Boot] [RFC PATCH 2/5] arm: v7R: Add initial support

[Lokesh Vutla]

On Tuesday 24 April 2018 06:35 PM, Alexander Graf wrote:
> On 04/24/2018 02:54 PM, Lokesh Vutla wrote:
>> From: Michal Simek 
>>
>> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
>> real-time systems. It implements the ARMv7-R architecture, and includes
>> Thumb-2 technology for optimum code density and processing throughput.
>>
>> Except for MPU(Memory Protection Unit) and few CP15 registers, most of
>> the
>> features are compatible with v7 architecture. So,reuse the same armv7
>> folder and introduce a new config CPU_V7R in order to differentiate
>> from v7 based platforms.
>>
>> Signed-off-by: Michal Simek 
>> Signed-off-by: Lokesh Vutla 
>> ---
>>   arch/arm/Kconfig   | 7 +++
>>   arch/arm/Makefile  | 2 ++
>>   arch/arm/cpu/armv7/start.S | 2 ++
>>   3 files changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 7212fc5afa..de36ab6701 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -192,6 +192,11 @@ config CPU_V7M
>>   select THUMB2_KERNEL
>>   select SYS_CACHE_SHIFT_5
>>   +config CPU_V7R
>> +    bool
>> +    select HAS_THUMB2
> 
> spaces vs tabs?
will fix it in next version.

> 
>> +    select SYS_CACHE_SHIFT_6
>> +
>>   config CPU_PXA
>>   bool
>>   select SYS_CACHE_SHIFT_5
>> @@ -208,6 +213,7 @@ config SYS_CPU
>>   default "arm1136" if CPU_ARM1136
>>   default "arm1176" if CPU_ARM1176
>>   default "armv7" if CPU_V7
>> +    default "armv7" if CPU_V7R
> 
> same here

will fix.

> 
>>   default "armv7m" if CPU_V7M
>>   default "pxa" if CPU_PXA
>>   default "sa1100" if CPU_SA1100
>> @@ -223,6 +229,7 @@ config SYS_ARM_ARCH
>>   default 6 if CPU_ARM1176
>>   default 7 if CPU_V7
>>   default 7 if CPU_V7M
>> +    default 7 if CPU_V7R
>>   default 5 if CPU_PXA
>>   default 4 if CPU_SA1100
>>   default 8 if ARM64
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 4fa8b38397..f4bc1f250d 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -18,6 +18,7 @@ arch-$(CONFIG_CPU_ARM1136)    =-march=armv5
>>   arch-$(CONFIG_CPU_ARM1176)    =-march=armv5t
>>   arch-$(CONFIG_CPU_V7)    =$(call cc-option, -march=armv7-a, \
>>    $(call cc-option, -march=armv7, -march=armv5))
>> +arch-$(CONFIG_CPU_V7R)    =-march=armv7-r
>>   arch-$(CONFIG_ARM64)    =-march=armv8-a
>>     # On Tegra systems we must build SPL for the armv4 core on the device
>> @@ -41,6 +42,7 @@ tune-$(CONFIG_CPU_PXA)    =-mcpu=xscale
>>   tune-$(CONFIG_CPU_ARM1136)    =
>>   tune-$(CONFIG_CPU_ARM1176)    =
>>   tune-$(CONFIG_CPU_V7)    =
>> +tune-$(CONFIG_CPU_V7R)    =
>>   tune-$(CONFIG_ARM64)    =
>>     # Evaluate tune cc-option calls now
>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>> index 937f7051fe..97cd830dc5 100644
>> --- a/arch/arm/cpu/armv7/start.S
>> +++ b/arch/arm/cpu/armv7/start.S
>> @@ -82,7 +82,9 @@ switch_to_hypervisor_ret:
>>     /* the mask ROM code should have PLL and others stable */
>>   #ifndef CONFIG_SKIP_LOWLEVEL_INIT
>> +#ifdef CONFIG_CPU_V7
> 
> Shouldn't this be V7A now?

As Tom suggested, ill not update it for now.

Thanks and regards,
Lokesh

> 
> 
> Alex
> 
>>   bl    cpu_init_cp15
>> +#endif
>>   #ifndef CONFIG_SKIP_LOWLEVEL_INIT_ONLY
>>   bl    cpu_init_crit
>>   #endif
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/5] arm: Introduce v7R support

[Michal Simek]

Hi Lokesh,

On 24.4.2018 14:54, Lokesh Vutla wrote:
> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
> real-time systems. It implements the ARMv7-R architecture, and includes
> Thumb-2 technology for optimum code density and processing throughput.
> 
> Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
> features are compatible with v7 architecture. This series adds minimal
> support for v7-R architecture by reusing the v7 support. Also adding
> support for MPU.
> 
> Lokesh Vutla (4):
>   arm: v7: Update VBAR only if available
>   arm: Kconfig: Add entry for MMU
>   arm: v7R: Add support for MPU
>   arm: v7R: Add support for enabling caches
> 
> Michal Simek (1):
>   arm: v7R: Add initial support
> 
>  arch/arm/Kconfig  |  33 
>  arch/arm/Makefile |   2 +
>  arch/arm/cpu/armv7/Makefile   |   2 +
>  arch/arm/cpu/armv7/mpu_v7r.c  | 120 ++
>  arch/arm/cpu/armv7/start.S|   4 +
>  arch/arm/cpu/armv7m/Makefile  |   3 +-
>  arch/arm/cpu/armv7m/mpu.c |  41 +-
>  arch/arm/include/asm/armv7m_mpu.h |  69 +
>  arch/arm/lib/Makefile |   5 +-
>  arch/arm/lib/cache-cp15.c |  14 +++-
>  10 files changed, 248 insertions(+), 45 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/mpu_v7r.c
> 

I have tested your series, also wired MPU (protect one region and try to
access it) and with caches on and off (running mtest to see number of
iterations and improving numbers with cache on) and nothing is showing
any functional fundamental problem.

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

Re: [U-Boot] [PATCH v1 15/19] spi: mvebu_a3700_spi: Use Armada 37xx clk driver for SPI clock frequency

[Marek Behún]

On Wed, 21 Mar 2018 10:37:33 +0100
Stefan Roese  wrote:

> Please add Jagan (on Cc) to Cc for SPI driver related changes.
Will do with next version

> Wouldn't it be easier to "select" CLK_ARMADA_3720 here instead? No
> changes to the config files necessary this way.

okay :)

> checkpatch will most likely complain about missing space in the line
> above.

yes, thanks

> Perhaps its better to check on "prescale >
> MVEBU_SPI_A3700_CLK_PRESCALE_MASK" instead of silently removing the
> potential additional bits.

The code just above ensures that prescale is never greater than 0x1f
which also is prescale_mask. The compiler should optimize the logical
and away.

I am using constants instead of macros in that code because when I
tried to put macros there with names like
MVEBU_SPI_A3700_CLK_PRESCALE_(MAX|HALF) or what not, the code was
uglier and the name of the macro does not explain much...

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

Re: [U-Boot] [RFC PATCH 3/5] arm: Kconfig: Add entry for MMU

[Tom Rini]

On Tue, Apr 24, 2018 at 06:24:46PM +0530, Lokesh Vutla wrote:

> Add a Kconfig entry for MMU and imply for all platforms
> using cache-cp15.c. Using imply instead of select so that
> MMU can be disabled by defconfigs when not needed.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/Kconfig  | 15 +++
>  arch/arm/lib/Makefile |  6 +-
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index de36ab6701..fe5bff097d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -74,6 +74,12 @@ config ARM_ASM_UNIFIED
>  config THUMB2_KERNEL
>   bool
>  
> +config MMU
> + bool "MMU-based Paged Memory Management Support"
> + help
> +   Select if you want MMU-based virtualised addressing space
> +   support by paged memory management.
> +
>  # If set, the workarounds for these ARM errata are applied early during 
> U-Boot
>  # startup. Note that in general these options force the workarounds to be
>  # applied; no CPU-type/version detection exists, unlike the similar options 
> in
> @@ -158,33 +164,40 @@ config ARM_ERRATA_855873
>  config CPU_ARM720T
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_ARM920T
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_ARM926EJS
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_ARM946ES
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_ARM1136
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_ARM1176
>   bool
>   select HAS_VBAR
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_V7
>   bool
>   select HAS_VBAR
>   select HAS_THUMB2
>   select SYS_CACHE_SHIFT_6
> + imply MMU
>  
>  config CPU_V7M
>   bool
> @@ -200,10 +213,12 @@ config CPU_V7R
>  config CPU_PXA
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config CPU_SA1100
>   bool
>   select SYS_CACHE_SHIFT_5
> + imply MMU
>  
>  config SYS_CPU
>   default "arm720t" if CPU_ARM720T
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 3d3085e917..f907adc161 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -63,11 +63,7 @@ obj-y  += reset.o
>  endif
>  
>  obj-y+= cache.o
> -ifndef CONFIG_ARM64
> -ifndef CONFIG_CPU_V7M
> -obj-y+= cache-cp15.o
> -endif
> -endif
> +obj-$(CONFIG_MMU)+= cache-cp15.o
>  
>  obj-y+= psci-dt.o

So, funny enough.  We have CONFIG_MMU code in ARM today that I bet
doesn't work and is just copy/pasted from the kernel and we should drop.

For right here, I think I'd rather see some CONFIG flag about
CONFIG_SYS_ARM_CACHE_CP15 instead.

-- 
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] [RFC PATCH 5/5] arm: v7R: Add support for enabling caches

[Tom Rini]

On Tue, Apr 24, 2018 at 06:24:48PM +0530, Lokesh Vutla wrote:

> Cache maintenance procedure is same for v7 and v7R
> processors. So re-use cache-cp15.c file except for
> mmu parts.

I also don't like CONFIG_MMU as it's too generic of a name.  Since for
this part of the series we need a flag for "we have an MMU we need to
fiddle", CONFIG_SYS_ARM_MMU ?  Thanks!

-- 
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] [RFC PATCH 2/5] arm: v7R: Add initial support

[Tom Rini]

On Tue, Apr 24, 2018 at 03:05:46PM +0200, Alexander Graf wrote:

> On 04/24/2018 02:54 PM, Lokesh Vutla wrote:
> >From: Michal Simek 
> >
> >The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
> >real-time systems. It implements the ARMv7-R architecture, and includes
> >Thumb-2 technology for optimum code density and processing throughput.
> >
> >Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
> >features are compatible with v7 architecture. So,reuse the same armv7
> >folder and introduce a new config CPU_V7R in order to differentiate
> >from v7 based platforms.
[snip]
> >diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> >index 937f7051fe..97cd830dc5 100644
> >--- a/arch/arm/cpu/armv7/start.S
> >+++ b/arch/arm/cpu/armv7/start.S
> >@@ -82,7 +82,9 @@ switch_to_hypervisor_ret:
> > /* the mask ROM code should have PLL and others stable */
> >  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> >+#ifdef CONFIG_CPU_V7
> 
> Shouldn't this be V7A now?

I'm not sure if we need to add a CPU_V7A flag now.  Maybe..

-- 
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] [RFC PATCH 4/5] arm: v7R: Add support for MPU

[Tom Rini]

On Tue, Apr 24, 2018 at 06:24:47PM +0530, Lokesh Vutla wrote:

> The Memory Protection Unit(MPU) allows to partition memory into regions
> and set individual protection attributes for each region. In absence
> of MPU a default map[1] will take effect. Add support for configuring
> MPU on Cortex-R, by reusing the existing support for Cortex-M processor.
> 
> [1] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1002400.html
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/Kconfig  |  11 +++
>  arch/arm/cpu/armv7/Makefile   |   2 +
>  arch/arm/cpu/armv7/mpu_v7r.c  | 109 ++
>  arch/arm/cpu/armv7m/Makefile  |   3 +-
>  arch/arm/cpu/armv7m/mpu.c |  41 +--
>  arch/arm/include/asm/armv7m_mpu.h |  69 +++

How close are armv7/mpu_v7r.c and armv7m/mpu.c ?  If we did some
underlying work so that armv7m/ and be put into armv7/ (and we introduce
CPU_V7A say, as I mentioned in another part of the thread so the
Makefile isn't too ugly) could we have a single mpu.c file, cleanly?

-- 
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] [RFC PATCH 0/5] arm: Introduce v7R support

[Tom Rini]

On Tue, Apr 24, 2018 at 06:24:43PM +0530, Lokesh Vutla wrote:

> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
> real-time systems. It implements the ARMv7-R architecture, and includes
> Thumb-2 technology for optimum code density and processing throughput.
> 
> Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
> features are compatible with v7 architecture. This series adds minimal
> support for v7-R architecture by reusing the v7 support. Also adding
> support for MPU.

There's some whitespace issues that I'm sure you'll fix for the next
version.  One naming thing that I think needs a little work is that we
say CONFIG_ARM_MPU (which is OK'ish, can we use something a little more
specific?  It's a V7 architectural thing, yes?) but then v7m_mpu.h, even
tho we use it on both v7r and v7m as there's just a few differences.
That should get consolidated, off the top of my head, to
CONFIG_CPU_V7_HAS_MPU (following other things like virt) and maybe
v7_mpu.h ?

-- 
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 v2 11/19] tpm: add TPM2_Clear command support

[Miquel Raynal]

Hi Simon,

On Fri, 30 Mar 2018 06:42:32 +0800, Simon Glass 
wrote:

> Hi Miquel,
> 
> On 29 March 2018 at 15:43, Miquel Raynal  wrote:
> > Add support for the TPM2_Clear command.
> >
> > Change the command file and the help accordingly.
> >
> > Signed-off-by: Miquel Raynal 
> > ---
> >  cmd/tpm.c  | 29 ++---
> >  cmd/tpm_test.c |  6 +++---
> >  include/tpm.h  | 21 +
> >  lib/tpm.c  | 42 ++
> >  4 files changed, 84 insertions(+), 14 deletions(-)
> >
> > diff --git a/cmd/tpm.c b/cmd/tpm.c
> > index fc9ef9d4a3..32921e1a70 100644
> > --- a/cmd/tpm.c
> > +++ b/cmd/tpm.c
> > @@ -454,6 +454,29 @@ static int do_tpm_init(cmd_tbl_t *cmdtp, int flag,
> > return report_return_code(tpm_init());
> >  }
> >
> > +static int do_tpm_force_clear(cmd_tbl_t *cmdtp, int flag,
> > + int argc, char * const argv[])
> > +{
> > +   u32 handle = 0;
> > +   const char *pw = (argc < 3) ? NULL : argv[2];
> > +   const ssize_t pw_sz = pw ? strlen(pw) : 0;
> > +
> > +   if (argc < 2 || argc > 3)
> > +   return CMD_RET_USAGE;
> > +
> > +   if (pw_sz > TPM2_DIGEST_LENGTH)
> > +   return -EINVAL;
> > +
> > +   if (!strcasecmp("TPM2_RH_LOCKOUT", argv[1]))
> > +   handle = TPM2_RH_LOCKOUT;
> > +   else if (!strcasecmp("TPM2_RH_PLATFORM", argv[1]))
> > +   handle = TPM2_RH_PLATFORM;
> > +   else
> > +   return CMD_RET_USAGE;
> > +
> > +   return report_return_code(tpm_force_clear(handle, pw, pw_sz));
> > +}
> > +
> >  #define TPM_COMMAND_NO_ARG(cmd)\
> >  static int do_##cmd(cmd_tbl_t *cmdtp, int flag,\
> > int argc, char * const argv[])  \
> > @@ -465,7 +488,6 @@ static int do_##cmd(cmd_tbl_t *cmdtp, int flag, 
> > \
> >
> >  TPM_COMMAND_NO_ARG(tpm_self_test_full)
> >  TPM_COMMAND_NO_ARG(tpm_continue_self_test)
> > -TPM_COMMAND_NO_ARG(tpm_force_clear)
> >  TPM_COMMAND_NO_ARG(tpm_physical_enable)
> >  TPM_COMMAND_NO_ARG(tpm_physical_disable)
> >
> > @@ -951,8 +973,9 @@ U_BOOT_CMD(tpm, CONFIG_SYS_MAXARGS, 1, do_tpm,
> >  "  physical_set_deactivated 0|1\n"
> >  "- Set deactivated flag.\n"
> >  "Admin Ownership Commands:\n"
> > -"  force_clear\n"
> > -"- Issue TPM_ForceClear command.\n"
> > +"  force_clear []\n"
> > +"- Issue TPM_[Force]Clear command, with  one of (TPMv2 only):\n"
> > +"  * TPM2_RH_LOCKOUT, TPM2_RH_PLATFORM.\n"
> >  "  tsc_physical_presence flags\n"
> >  "- Set TPM device's Physical Presence flags to .\n"
> >  "The Capability Commands:\n"
> > diff --git a/cmd/tpm_test.c b/cmd/tpm_test.c
> > index 37ad2ff33d..da40dbc423 100644
> > --- a/cmd/tpm_test.c
> > +++ b/cmd/tpm_test.c
> > @@ -176,7 +176,7 @@ static int test_fast_enable(void)
> > TPM_CHECK(tpm_get_flags(, , NULL));
> > printf("\tdisable is %d, deactivated is %d\n", disable, 
> > deactivated);
> > for (i = 0; i < 2; i++) {
> > -   TPM_CHECK(tpm_force_clear());
> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
> > TPM_CHECK(tpm_get_flags(, , NULL));
> > printf("\tdisable is %d, deactivated is %d\n", disable,
> >deactivated);
> > @@ -458,7 +458,7 @@ static int test_write_limit(void)
> > TPM_CHECK(TlclStartupIfNeeded());
> > TPM_CHECK(tpm_self_test_full());
> > TPM_CHECK(tpm_tsc_physical_presence(PRESENCE));
> > -   TPM_CHECK(tpm_force_clear());
> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
> > TPM_CHECK(tpm_physical_enable());
> > TPM_CHECK(tpm_physical_set_deactivated(0));
> >
> > @@ -477,7 +477,7 @@ static int test_write_limit(void)
> > }
> >
> > /* Reset write count */
> > -   TPM_CHECK(tpm_force_clear());
> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
> > TPM_CHECK(tpm_physical_enable());
> > TPM_CHECK(tpm_physical_set_deactivated(0));
> >
> > diff --git a/include/tpm.h b/include/tpm.h
> > index 38d7cb899d..2f1712 100644
> > --- a/include/tpm.h
> > +++ b/include/tpm.h
> > @@ -43,13 +43,23 @@ enum tpm_startup_type {
> >  };
> >
> >  enum tpm2_startup_types {
> > -   TPM2_SU_CLEAR   = 0x,
> > -   TPM2_SU_STATE   = 0x0001,
> > +   TPM2_SU_CLEAR   = 0x,
> > +   TPM2_SU_STATE   = 0x0001,
> > +};
> > +
> > +enum tpm2_handles {  
> 
> Please add comment to enum

Fine, I will document all of them. Just for you to know, these are
values extracted from the (publicly available) specification, I did
not change any of them.

> 
> > +   TPM2_RH_OWNER   = 0x4001,
> > +   TPM2_RS_PW  = 0x4009,
> > +   TPM2_RH_LOCKOUT = 0x400A,
> > +   TPM2_RH_ENDORSEMENT = 0x400B,
> > +   TPM2_RH_PLATFORM 

Re: [U-Boot] [RFC PATCH 2/5] arm: v7R: Add initial support

[Alexander Graf]

On 04/24/2018 02:54 PM, Lokesh Vutla wrote:

From: Michal Simek 

The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
real-time systems. It implements the ARMv7-R architecture, and includes
Thumb-2 technology for optimum code density and processing throughput.

Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
features are compatible with v7 architecture. So,reuse the same armv7
folder and introduce a new config CPU_V7R in order to differentiate
from v7 based platforms.

Signed-off-by: Michal Simek 
Signed-off-by: Lokesh Vutla 
---
  arch/arm/Kconfig   | 7 +++
  arch/arm/Makefile  | 2 ++
  arch/arm/cpu/armv7/start.S | 2 ++
  3 files changed, 11 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7212fc5afa..de36ab6701 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -192,6 +192,11 @@ config CPU_V7M
select THUMB2_KERNEL
select SYS_CACHE_SHIFT_5
  
+config CPU_V7R

+   bool
+select HAS_THUMB2


spaces vs tabs?


+   select SYS_CACHE_SHIFT_6
+
  config CPU_PXA
bool
select SYS_CACHE_SHIFT_5
@@ -208,6 +213,7 @@ config SYS_CPU
default "arm1136" if CPU_ARM1136
default "arm1176" if CPU_ARM1176
default "armv7" if CPU_V7
+default "armv7" if CPU_V7R


same here


default "armv7m" if CPU_V7M
default "pxa" if CPU_PXA
default "sa1100" if CPU_SA1100
@@ -223,6 +229,7 @@ config SYS_ARM_ARCH
default 6 if CPU_ARM1176
default 7 if CPU_V7
default 7 if CPU_V7M
+   default 7 if CPU_V7R
default 5 if CPU_PXA
default 4 if CPU_SA1100
default 8 if ARM64
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4fa8b38397..f4bc1f250d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -18,6 +18,7 @@ arch-$(CONFIG_CPU_ARM1136)=-march=armv5
  arch-$(CONFIG_CPU_ARM1176)=-march=armv5t
  arch-$(CONFIG_CPU_V7) =$(call cc-option, -march=armv7-a, \
 $(call cc-option, -march=armv7, -march=armv5))
+arch-$(CONFIG_CPU_V7R) =-march=armv7-r
  arch-$(CONFIG_ARM64)  =-march=armv8-a
  
  # On Tegra systems we must build SPL for the armv4 core on the device

@@ -41,6 +42,7 @@ tune-$(CONFIG_CPU_PXA)=-mcpu=xscale
  tune-$(CONFIG_CPU_ARM1136)=
  tune-$(CONFIG_CPU_ARM1176)=
  tune-$(CONFIG_CPU_V7) =
+tune-$(CONFIG_CPU_V7R) =
  tune-$(CONFIG_ARM64)  =
  
  # Evaluate tune cc-option calls now

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 937f7051fe..97cd830dc5 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -82,7 +82,9 @@ switch_to_hypervisor_ret:
  
  	/* the mask ROM code should have PLL and others stable */

  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
+#ifdef CONFIG_CPU_V7


Shouldn't this be V7A now?


Alex


bl  cpu_init_cp15
+#endif
  #ifndef CONFIG_SKIP_LOWLEVEL_INIT_ONLY
bl  cpu_init_crit
  #endif



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

Re: [U-Boot] [PATCH v2 03/19] tpm: add support for TPMv2 SPI modules

[Miquel Raynal]

Hi Simon,

On Fri, 30 Mar 2018 06:41:52 +0800, Simon Glass 
wrote:

> Hi Miquel,
> 
> On 29 March 2018 at 15:43, Miquel Raynal  wrote:
> > Add the tpm_tis_spi driver that should support any TPMv2 compliant (SPI)
> > module.
> >
> > Signed-off-by: Miquel Raynal 
> > ---
> >  drivers/tpm/Kconfig   |   9 +
> >  drivers/tpm/Makefile  |   1 +
> >  drivers/tpm/tpm_tis.h |   3 +
> >  drivers/tpm/tpm_tis_spi.c | 656 
> > ++
> >  4 files changed, 669 insertions(+)
> >  create mode 100644 drivers/tpm/tpm_tis_spi.c  
> 
> I think this came up in another context. Would it make sense to create
> a common interface to i2c and SPI and then have a common driver?

I hesitated to do it (even started to write down some common code), and
finally there was not so much of it, I was not sure if it would bring
something more than obfuscation so I chose not to add an extra layer as
I had currently only one SPI chip and no I2C chip to check the
architecture. Maybe the question should be asked again when someone
will want I2C support.

Regards,
Miquèl

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

[U-Boot] [RFC PATCH 5/5] arm: v7R: Add support for enabling caches

[Lokesh Vutla]

Cache maintenance procedure is same for v7 and v7R
processors. So re-use cache-cp15.c file except for
mmu parts.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/mpu_v7r.c | 11 +++
 arch/arm/lib/Makefile|  3 +++
 arch/arm/lib/cache-cp15.c| 14 +-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/mpu_v7r.c b/arch/arm/cpu/armv7/mpu_v7r.c
index 703f744b31..b998ab9320 100644
--- a/arch/arm/cpu/armv7/mpu_v7r.c
+++ b/arch/arm/cpu/armv7/mpu_v7r.c
@@ -107,3 +107,14 @@ void setup_mpu_regions(struct mpu_region_config *rgns, u32 
num_rgns)
 
icache_enable();
 }
+
+void enable_caches(void)
+{
+   /*
+* setup_mpu_regions() might have enabled Icache. So add a check
+* before enabling Icache
+*/
+   if (!icache_status())
+   icache_enable();
+   dcache_enable();
+}
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index f907adc161..f8377ba18a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -64,6 +64,9 @@ endif
 
 obj-y  += cache.o
 obj-$(CONFIG_MMU)  += cache-cp15.o
+ifeq ($(CONFIG_CPU_V7R)$(CONFIG_ARM_MPU),yy)
+obj-y  += cache-cp15.o
+endif
 
 obj-y  += psci-dt.o
 
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index f0c1b03728..fea7d3fdec 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -9,11 +9,15 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_ARM_MPU
+#include 
+#endif
 
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_MMU
 __weak void arm_init_before_mmu(void)
 {
 }
@@ -202,15 +206,23 @@ static int mmu_enabled(void)
 {
return get_cr() & CR_M;
 }
+#endif /* CONFIG_MMU */
 
 /* cache_bit must be either CR_I or CR_C */
 static void cache_enable(uint32_t cache_bit)
 {
uint32_t reg;
 
-   /* The data cache is not active unless the mmu is enabled too */
+   /* The data cache is not active unless the mmu/mpu is enabled too */
+#ifdef CONFIG_MMU
if ((cache_bit == CR_C) && !mmu_enabled())
mmu_setup();
+#elif defined(CONFIG_ARM_MPU)
+   if ((cache_bit == CR_C) && !mpu_enabled()) {
+   printf("Consider enabling MPU before enabling caches\n");
+   return;
+   }
+#endif
reg = get_cr(); /* get control reg. */
set_cr(reg | cache_bit);
 }
-- 
2.17.0

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