[U-Boot] [PATCH] sunxi: fix sid base address macro name for H6

[Icenowy Zheng]

In the current H6 CPU memory space code, the SUNXI in the macro name of
the SID address base is wrongly spelled as SNUXI, which leads to SID
readout not working.

Fix this macro name.

Fixes: 55f6b1c351c9 ("sunxi: add basic memory map definitions of H6 SoC")
Signed-off-by: Icenowy Zheng 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
index f568def8b4..41a9b0fc47 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
@@ -20,7 +20,7 @@
 #define SUNXI_DMA_BASE 0x03002000
 /* SID address space starts at 0x03006000, but e-fuse is at offset 0x200 */
 #define SUNXI_SIDC_BASE0x03006000
-#define SNUXI_SID_BASE 0x03006200
+#define SUNXI_SID_BASE 0x03006200
 #define SUNXI_TIMER_BASE   0x03009000
 #define SUNXI_PIO_BASE 0x0300B000
 #define SUNXI_PSI_BASE 0x0300C000
-- 
2.18.0

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

[U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

[Adam Ford]

I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards.
Some of these boards use the TWL4030 PMIC which is still using the
older i2c_write and i2c_read functions.

I wonder if someone can point me to a good patch that I can use a
model one how to appropriately port I2C drivers forward?  I'd like to
disable this feature so the notice goes away since it seems like
DM_I2C should be do-able by now.

thanks

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

Re: [U-Boot] [U-Boot, 2/2] FIT image: use compression = "none" for ramdisks

[Tom Rini]

On Mon, Jul 30, 2018 at 12:53:19PM +0200, Simon Goldschmidt wrote:

> To prepare supporting compression for all image types, change
> compression to "none" for ramdisks in all examples.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 2 +-
>  doc/README.bcm7xxx  | 2 +-
>  doc/uImage.FIT/multi.its| 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)

Sorry for the delay.  I think this patch as-is, is wrong.  Please split
it into a patch per file that CCs the appropriate custodian(s) for them
to ack/nak and pick up.  It's also appropriate to do a patch now that
corrects the behavior of uncompressing ramdisks that can be uncompressed
automatically (and no need for a CONFIG option).  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] Convert CONFIG_TWL4030_LED et al to Kconfig

[Tom Rini]

On Mon, Aug 06, 2018 at 02:26:50PM -0500, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_TWL4030_LED
>CONFIG_TWL4030_INPUT
> 
> This also removes dead references to:
>CONFIG_TWL4030_KEYPAD
> 
> Signed-off-by: Adam Ford 

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] Removed unused references to CONFIG_SERIALx

[Tom Rini]

On Tue, Aug 07, 2018 at 07:08:32AM -0500, Adam Ford wrote:

> After creating CONS_INDEX and migrating a bunch of boards to it,
> there are a bunch of defined references to CONFIG_SERIALx which
> are not referenced in any C code or #ifdef, so they can now be
> removed
> 
> Signed-off-by: Adam Ford 

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] Convert CONFIG_SYS_I2C_DAVINCI to Kconfig

[Tom Rini]

On Fri, Aug 10, 2018 at 05:05:22AM -0500, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_I2C_DAVINCI
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/da850_am18xxevm_defconfig 
> b/configs/da850_am18xxevm_defconfig
> index abb2295951..31e0529e40 100644

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, v3, 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit

[Tom Rini]

On Sat, Jul 21, 2018 at 08:25:32PM +, Alex Kiernan wrote:

> Add ability to set environment bootlimit from Kconfig
> 
> Signed-off-by: Alex Kiernan 

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] Convert CONFIG_MISC_INIT_R to Kconfig

[Tom Rini]

On Sun, Jul 29, 2018 at 01:13:29PM -0500, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_MISC_INIT_R
> 
> Signed-off-by: Adam Ford 

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] Convert CONFIG_VIDEO_OMAP3 to Kconfig

[Tom Rini]

On Thu, Aug 02, 2018 at 08:50:20AM -0500, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_VIDEO_OMAP3
> 
> Signed-off-by: Adam Ford 

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] Convert CONFIG_MII et al to Kconfig

[Tom Rini]

On Fri, Jul 20, 2018 at 11:03:57PM -0500, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_MII
>CONFIG_DRIVER_TI_EMAC
> 
> Signed-off-by: Adam Ford 
> Acked-by: Jagan Teki 
> Acked-by: Joe Hershberger 

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,v3,2/2] Migrate bootlimit to Kconfig

[Tom Rini]

On Sat, Jul 21, 2018 at 08:25:33PM +, Alex Kiernan wrote:

> Migrate boards which set bootlimit in the environment to Kconfig.
> 
> We exclude gurnard_defconfig which includes a bootlimit=, but doesn't set
> CONFIG_BOOTCOUNT_LIMIT, so we'd fail to include a bootlimit setting
> if we migrated it.
> 
> display5_defconfig and display5_factory_defconfig share a SYS_CONFIG_NAME,
> but only display5_defconfig enables CONFIG_BOOTCOUNT_LIMIT, so we fail to
> set bootlimit= in display5_factory_defconfig. This is okay because the
> display5_factory_defconfig doesn't need to have it set, as it is only
> meant to prepare the board in the factory.
> 
> Environment changes for all modified configs as seen from buildman:
> 
>   boards.cfg is up to date. Nothing to do.
>   Summary of 3 commits for 32 boards (8 threads, 1 job per thread)
>   01: Merge git://git.denx.de/u-boot-x86
>  arm:  +   draco etamin rastaban pxm2 display5 thuban rut
>   02: Add BOOTCOUNT_BOOTLIMIT to set reboot limit
>   03: Migrate bootlimit to Kconfig
>  - display5_factory: bootlimit=3
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 

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

[U-Boot] [PATCH] GPIO: omap_gpio: Fix gpio name names with device tree

[Adam Ford]

The GPIO bank numbers do not appear in the device tree, so this
patch makes the gpio name based on the address
(ie gpio@49054000_31 vs gpio4_31)

adam

Signed-off-by: Adam Ford 

diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index 651f6994e4..0f1ddeff92 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -288,11 +288,9 @@ static int omap_gpio_probe(struct udevice *dev)
struct gpio_bank *bank = dev_get_priv(dev);
struct omap_gpio_platdata *plat = dev_get_platdata(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-   int banknum;
char name[18], *str;
 
-   banknum = plat->bank_index;
-   sprintf(name, "GPIO%d_", banknum + 1);
+   sprintf(name, "gpio@%4x_", (unsigned int)plat->base);
str = strdup(name);
if (!str)
return -ENOMEM;
-- 
2.17.1

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

Re: [U-Boot] [UBOOT PATCH 2/2] dm: core: Scan "/firmware" node by default

[Simon Glass]

Hi Michael,

On 17 August 2018 at 07:22, Michal Simek  wrote:
> On 17.8.2018 14:49, Simon Glass wrote:
>> On 10 August 2018 at 02:45, Rajan Vaja  wrote:
>>> All Linux firmware drivers are put under "/firmware" node
>>> and it has support to populate "/firmware" node by default.
>>>
>>> u-boot and Linux can share same DTB. In this case, driver
>>> probe for devices under "/firmware" will not be invoked
>>> as "/firmware" does not have its own "compatible" property.
>>>
>>> This patch scans "/firmware" node by default like "/clocks".
>>>
>>> Signed-off-by: Rajan Vaja 
>>> ---
>>>  drivers/core/root.c | 8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> We should add a firmware device for sandbox.
>>
>
> what to add there?

It can be any device, but I suggest something simple like a
demo-shape? Then you can check that it is accessible in a test in
test/dm/core.c, perhaps.

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

[U-Boot] [PATCH v3 10/10] board: Add STM32F769 SoC, discovery board support

[Yannick Fertré]

Signed-off-by: Yannick Fertré 
---
 configs/stm32f769-disco_defconfig | 67 +++
 1 file changed, 67 insertions(+)
 create mode 100644 configs/stm32f769-disco_defconfig

diff --git a/configs/stm32f769-disco_defconfig 
b/configs/stm32f769-disco_defconfig
new file mode 100644
index 000..7fe2d3f
--- /dev/null
+++ b/configs/stm32f769-disco_defconfig
@@ -0,0 +1,67 @@
+CONFIG_ARM=y
+CONFIG_STM32=y
+CONFIG_SYS_TEXT_BASE=0x08008000
+CONFIG_SYS_MALLOC_F_LEN=0xC00
+CONFIG_STM32F7=y
+CONFIG_TARGET_STM32F746_DISCO=y
+CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"
+CONFIG_ENV_VARS_UBOOT_CONFIG=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 
ignore_loglevel"
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+CONFIG_ARM_PL180_MMCI=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+# CONFIG_PINCTRL_FULL is not set
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_STM32_QSPI=y
+CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_VIDEO_BRIDGE=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set
-- 
2.7.4

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

[U-Boot] [PATCH v3 09/10] arm: dts: stm32: add display for STM32F769 disco board

[Yannick Fertré]

Enable the display controller, mipi dsi bridge & panel.
Set panel display timings.

Signed-off-by: Yannick Fertré 
---
 arch/arm/dts/stm32f769-disco.dts | 41 
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 1e8ef74..6903e66 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -85,6 +85,18 @@
compatible = "st,button1";
button-gpio = < 0 0>;
};
+
+   panel: panel {
+   compatible = "orisetech,otm8009a";
+   reset-gpios = < 15 1>;
+   status = "okay";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
 _hse {
@@ -264,3 +276,32 @@
bus-width = <4>;
max-frequency = <2500>;
 };
+
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   port@1 {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.7.4

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

[U-Boot] [PATCH v3 06/10] video: add support of panel OTM8009A

[Yannick Fertré]

Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig  |   8 +
 drivers/video/Makefile |   1 +
 drivers/video/orisetech_otm8009a.c | 367 +
 3 files changed, 376 insertions(+)
 create mode 100644 drivers/video/orisetech_otm8009a.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ede351d..f54f97e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -328,6 +328,14 @@ config VIDEO_LCD_ANX9804
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
 
+config VIDEO_LCD_ORISETECH_OTM8009A
+   bool "OTM8009A DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   help
+ Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ae143dc..67f5ca7 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VIDEO_IPUV3) += mxc_ipuv3_fb.o ipu_common.o 
ipu_disp.o
 obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
+obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
diff --git a/drivers/video/orisetech_otm8009a.c 
b/drivers/video/orisetech_otm8009a.c
new file mode 100644
index 000..fd7fc7c
--- /dev/null
+++ b/drivers/video/orisetech_otm8009a.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *Philippe Cornu  for STMicroelectronics.
+ *
+ * This otm8009a panel driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x  /* Address Shift Function */
+#define MCS_PANSET 0xB3A6  /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2  /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4  /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181  /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1  /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480  /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A  /* Command not documented */
+#define MCS_PWR_CTRL1  0xC580  /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2  0xC590  /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4  0xC5B0  /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80  /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90  /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0  /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0  /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0  /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0  /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0  /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0  /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80  /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90  /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0  /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0  /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0  /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0  /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80  /* GOA VST Setting */
+#define MCS_GOACLKA1   0xCEA0  /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3   0xCEB0  /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0  /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0  /* Command not documented */
+#define MCS_GVDDSET0xD800  /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900  /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P   0xE100  /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N   0xE200  /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6  /* Command not documented */
+#define MCS_CMD2_ENA1  0xFF00  /* Enable Access Command2 "CMD2" */
+#define MCS_CMD2_ENA2  0xFF80  /* Enable Access Orise Command2 */
+
+struct otm8009a_panel_priv {
+   struct udevice *reg;
+   struct gpio_desc reset;
+};
+
+static const struct display_timing default_timing = {
+   .pixelclock.typ = 32729000,
+ 

[U-Boot] [PATCH v3 05/10] video: add support of STM32 MIPI DSI controller driver

[Yannick Fertré]

Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: Yannick Fertré 
---
 drivers/video/stm32/Kconfig |  10 +
 drivers/video/stm32/Makefile|   1 +
 drivers/video/stm32/stm32_dsi.c | 428 
 3 files changed, 439 insertions(+)
 create mode 100644 drivers/video/stm32/stm32_dsi.c

diff --git a/drivers/video/stm32/Kconfig b/drivers/video/stm32/Kconfig
index 78b1fac..5b5e2c4 100644
--- a/drivers/video/stm32/Kconfig
+++ b/drivers/video/stm32/Kconfig
@@ -13,6 +13,16 @@ menuconfig VIDEO_STM32
  DSI. This option enables these supports which can be used on
  devices which have RGB TFT or DSI display connected.
 
+config VIDEO_STM32_DSI
+   bool "Enable STM32 DSI video support"
+   depends on VIDEO_STM32
+   select VIDEO_MIPI_DSI
+   select VIDEO_BRIDGE
+   select VIDEO_DW_MIPI_DSI
+   help
+ This option enables support DSI internal bridge which can be used on
+ devices which have DSI devices connected.
+
 config VIDEO_STM32_MAX_XRES
int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_STM32
diff --git a/drivers/video/stm32/Makefile b/drivers/video/stm32/Makefile
index 7297e5f..f8b42d1 100644
--- a/drivers/video/stm32/Makefile
+++ b/drivers/video/stm32/Makefile
@@ -6,3 +6,4 @@
 #  Yannick Fertre 
 
 obj-${CONFIG_VIDEO_STM32} = stm32_ltdc.o
+obj-${CONFIG_VIDEO_STM32_DSI} += stm32_dsi.o
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
new file mode 100644
index 000..b7feb64
--- /dev/null
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -0,0 +1,428 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * This MIPI DSI controller driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/stm/dw_mipi_dsi-stm.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+/* DSI digital registers & bit definitions */
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCFGR  0x0400  /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0)  /* DSI Mode */
+#define WCFGR_COLMUX   GENMASK(3, 1)   /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404  /* Wrapper Control Reg */
+#define WCR_DSIEN  BIT(3)  /* DSI ENable */
+
+#define DSI_WISR   0x040C  /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8)  /* PLL Lock Status */
+#define WISR_RRS   BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0  0x0418  /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0)   /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR  0x0430  /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0)  /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2)   /* pll loop DIVision Factor */
+#define WRPCR_IDF  GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF  GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN   10
+#define NDIV_MAX   125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+   DSI_RGB565_CONF1,
+   DSI_RGB565_CONF2,
+   DSI_RGB565_CONF3,
+   DSI_RGB666_CONF1,
+   DSI_RGB666_CONF2,
+   DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS  31250
+#define LANE_MAX_KBPS  50
+
+/* Timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define TIMEOUT_US 20
+
+struct stm32_dsi_priv {
+   struct mipi_dsi_device device;
+   void __iomem *base;
+   struct udevice *panel;
+   u32 pllref_clk;
+   u32 hw_version;
+   int lane_min_kbps;
+   int lane_max_kbps;
+};
+
+static inline void dsi_write(struct stm32_dsi_priv *dsi, u32 reg, u32 val)
+{
+   writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct stm32_dsi_priv *dsi, u32 reg)
+{
+   return readl(dsi->base + reg);
+}
+
+static inline void dsi_set(struct stm32_dsi_priv *dsi, u32 reg, u32 mask)
+{
+ 

[U-Boot] [PATCH v3 08/10] arm: dts: stm32: add dsi for STM32F746

[Yannick Fertré]

Add mipi dsi bridge node in device-tree.

Signed-off-by: Yannick Fertré 
---
 arch/arm/dts/stm32f746.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index afa7832..005d267 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -340,6 +340,18 @@
u-boot,dm-pre-reloc;
status = "disabled";
};
+
+   dsi: dsi@40016c00 {
+   compatible = "st,stm32-dsi";
+   reg = <0x40016C00 0x800>;
+   resets = < STM32F7_APB2_RESET(DSI)>;
+   clocks =  < 0 STM32F7_APB2_CLOCK(DSI)>,
+ < 0 STM32F7_APB2_CLOCK(LTDC)>,
+ <_hse>;
+   clock-names = "pclk", "px_clk", "ref";
+   u-boot,dm-pre-reloc;
+   status = "disabled";
+   };
};
 };
 
-- 
2.7.4

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

[U-Boot] [PATCH v3 07/10] video: add support of panel RM68200

[Yannick Fertré]

Support for Raydium RM68200 720p dsi 2dl video mode panel.
This rm68200 panel driver is based on the Linux Kernel driver from
drivers/gpu/drm/panel/panel-raydium-rm68200.c.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig   |   8 +
 drivers/video/Makefile  |   1 +
 drivers/video/raydium-rm68200.c | 339 
 3 files changed, 348 insertions(+)
 create mode 100644 drivers/video/raydium-rm68200.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index f54f97e..1aa826d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -336,6 +336,14 @@ config VIDEO_LCD_ORISETECH_OTM8009A
help
  Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
 
+config VIDEO_LCD_RAYDIUM_RM68200
+   bool "RM68200 DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   help
+ Support for Raydium rm68200 720x1280 dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 67f5ca7..d60ff9d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
 obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
+obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
diff --git a/drivers/video/raydium-rm68200.c b/drivers/video/raydium-rm68200.c
new file mode 100644
index 000..cf48331
--- /dev/null
+++ b/drivers/video/raydium-rm68200.c
@@ -0,0 +1,339 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *Philippe Cornu  for STMicroelectronics.
+ *
+ * This rm68200 panel driver is inspired from the Linux Kernel driver
+ * drivers/gpu/drm/panel/panel-raydium-rm68200.c.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200_panel_priv {
+   struct udevice *reg;
+   struct udevice *backlight;
+   struct gpio_desc reset;
+};
+
+static const 

[U-Boot] [PATCH v3 03/10] video: add support of MIPI DSI interface

[Yannick Fertré]

Mipi_display.c contains a set of dsi helpers.
This file is a copy of file drm_mipi_dsi.c (linux kernel).

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig|   8 +
 drivers/video/Makefile   |   1 +
 drivers/video/mipi_dsi.c | 828 +++
 include/mipi_dsi.h   | 451 ++
 4 files changed, 1288 insertions(+)
 create mode 100644 drivers/video/mipi_dsi.c
 create mode 100644 include/mipi_dsi.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ecb57d8..6048291 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -73,6 +73,14 @@ config VIDEO_ANSI
  Enable ANSI escape sequence decoding for a more fully functional
  console.
 
+config VIDEO_MIPI_DSI
+   bool "Support MIPI DSI interface"
+   depends on DM_VIDEO
+   help
+ Support MIPI DSI interface for driving a MIPI compatible device.
+ The MIPI Display Serial Interface (MIPI DSI) defines a high-speed
+ serial interface between a host processor and a display module.
+
 config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 0f41a23..1e88741 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
+obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
 obj-$(CONFIG_VIDEO_MVEBU) += mvebu_lcd.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
 obj-$(CONFIG_VIDEO_MXS) += mxsfb.o videomodes.o
diff --git a/drivers/video/mipi_dsi.c b/drivers/video/mipi_dsi.c
new file mode 100644
index 000..ccc5794
--- /dev/null
+++ b/drivers/video/mipi_dsi.c
@@ -0,0 +1,828 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Andrzej Hajda 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Mipi_dsi.c contains a set of dsi helpers.
+ * This file is inspired from the drm helper file 
drivers/gpu/drm/drm_mipi_dsi.c
+ * (kernel linux).
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsi helpers
+ *
+ * These functions contain some common logic and helpers to deal with MIPI DSI
+ * peripherals.
+ *
+ * Helpers are provided for a number of standard MIPI DSI command as well as a
+ * subset of the MIPI DCS command set.
+ */
+
+/**
+ * mipi_dsi_attach - attach a DSI device to its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_attach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->attach)
+   return -ENOSYS;
+
+   return ops->attach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_attach);
+
+/**
+ * mipi_dsi_detach - detach a DSI device from its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_detach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->detach)
+   return -ENOSYS;
+
+   return ops->detach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_detach);
+
+/**
+ * mipi_dsi_device_transfer - transfer message to a DSI device
+ * @dsi: DSI peripheral
+ * @msg: message
+ */
+static ssize_t mipi_dsi_device_transfer(struct mipi_dsi_device *dsi,
+   struct mipi_dsi_msg *msg)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->transfer)
+   return -ENOSYS;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+   msg->flags |= MIPI_DSI_MSG_USE_LPM;
+
+   return 

[U-Boot] [PATCH v3 01/10] video: stm32: stm32_ltdc: add bridge to display controller

[Yannick Fertré]

Manage a bridge insert between the display controller & a panel.

Signed-off-by: Yannick Fertré 
---
 drivers/video/stm32/stm32_ltdc.c | 143 ++-
 1 file changed, 82 insertions(+), 61 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index dc6c889..6d075e3 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -4,22 +4,20 @@
  * Author(s): Philippe Cornu  for STMicroelectronics.
  *   Yannick Fertre  for STMicroelectronics.
  */
-
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 struct stm32_ltdc_priv {
void __iomem *regs;
-   struct display_timing timing;
enum video_log2_bpp l2bpp;
u32 bg_col_argb;
u32 crop_x, crop_y, crop_w, crop_h;
@@ -174,8 +172,8 @@ static u32 stm32_ltdc_get_pixel_format(enum video_log2_bpp 
l2bpp)
case VIDEO_BPP2:
case VIDEO_BPP4:
default:
-   debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
- __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
+   pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
+   __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
pf = PF_RGB565;
break;
}
@@ -209,23 +207,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv 
*priv)
setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
 }
 
-static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
+static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
+   struct display_timing *timings)
 {
void __iomem *regs = priv->regs;
-   struct display_timing *timing = >timing;
u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
u32 total_w, total_h;
u32 val;
 
/* Convert video timings to ltdc timings */
-   hsync = timing->hsync_len.typ - 1;
-   vsync = timing->vsync_len.typ - 1;
-   acc_hbp = hsync + timing->hback_porch.typ;
-   acc_vbp = vsync + timing->vback_porch.typ;
-   acc_act_w = acc_hbp + timing->hactive.typ;
-   acc_act_h = acc_vbp + timing->vactive.typ;
-   total_w = acc_act_w + timing->hfront_porch.typ;
-   total_h = acc_act_h + timing->vfront_porch.typ;
+   hsync = timings->hsync_len.typ - 1;
+   vsync = timings->vsync_len.typ - 1;
+   acc_hbp = hsync + timings->hback_porch.typ;
+   acc_vbp = vsync + timings->vback_porch.typ;
+   acc_act_w = acc_hbp + timings->hactive.typ;
+   acc_act_h = acc_vbp + timings->vactive.typ;
+   total_w = acc_act_w + timings->hfront_porch.typ;
+   total_h = acc_act_h + timings->vfront_porch.typ;
 
/* Synchronization sizes */
val = (hsync << 16) | vsync;
@@ -247,14 +245,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv)
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
-   if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
+   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
-   if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
-   if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
val |= GCR_DEPOL;
-   if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
val |= GCR_PCPOL;
clrsetbits_le32(regs + LTDC_GCR,
GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
@@ -330,96 +328,119 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
-   struct udevice *panel;
+   struct udevice *bridge = NULL;
+   struct udevice *panel = NULL;
+   struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
-   int rate, ret;
+   int ret;
 
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
-   debug("%s: ltdc dt register address error\n", __func__);
+   dev_err(dev, "ltdc dt register address error\n");
return -EINVAL;
}
 
ret = clk_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: peripheral clock get error %d\n", __func__, ret);
+   dev_err(dev, "peripheral clock get error %d\n", ret);
return ret;
}
 
ret = clk_enable();
if (ret) {
-   debug("%s: 

[U-Boot] [PATCH v3 04/10] video: add MIPI DSI host controller bridge

[Yannick Fertré]

Add a Synopsys Designware MIPI DSI host bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: Yannick Fertré 
---
 drivers/video/Kconfig   |   9 +
 drivers/video/Makefile  |   1 +
 drivers/video/dw_mipi_dsi.c | 827 
 include/dw_mipi_dsi.h   |  33 ++
 4 files changed, 870 insertions(+)
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6048291..ede351d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -667,6 +667,15 @@ config VIDEO_DW_HDMI
  rather requires a SoC-specific glue driver to call it), it
  can not be enabled from the configuration menu.
 
+config VIDEO_DW_MIPI_DSI
+   bool
+   help
+ Enables the common driver code for the Synopsis Designware
+ MIPI DSI block found in SoCs from various vendors.
+ As this does not provide any functionality by itself (but
+ rather requires a SoC-specific glue driver to call it), it
+ can not be enabled from the configuration menu.
+
 config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 1e88741..ae143dc 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_BROADWELL_IGD) += broadwell_igd.o
 obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
 obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-$(CONFIG_VIDEO_EFI) += efi.o
 obj-$(CONFIG_VIDEO_FSL_DCU_FB) += fsl_dcu_fb.o videomodes.o
 obj-$(CONFIG_VIDEO_IPUV3) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
new file mode 100644
index 000..0fd6687
--- /dev/null
+++ b/drivers/video/dw_mipi_dsi.c
@@ -0,0 +1,827 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *Yannick Fertre  for STMicroelectronics.
+ *
+ * This generic Synopsys DesignWare MIPI DSI host driver is inspired from
+ * the Linux Kernel driver drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVISION(div)   (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVISION(div)   ((div) & 0xff)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VCID(vcid) ((vcid) & 0x3)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define LOOSELY18_EN   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_VCID   0x1c
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_PARTITIONING_EN0x24
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define CRC_RX_EN  BIT(4)
+#define ECC_RX_EN  BIT(3)
+#define BTA_EN BIT(2)
+#define EOTP_RX_EN BIT(1)
+#define EOTP_TX_EN BIT(0)
+
+#define DSI_GEN_VCID   0x30
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define VID_MODE_TYPE_BURST

[U-Boot] [PATCH v3 02/10] include: Add new DCS commands in the enum list

[Yannick Fertré]

Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.

Signed-off-by: Yannick Fertré 
---
 include/mipi_display.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/mipi_display.h b/include/mipi_display.h
index ddcc8ca..19aa65a 100644
--- a/include/mipi_display.h
+++ b/include/mipi_display.h
@@ -115,6 +115,14 @@ enum {
MIPI_DCS_READ_MEMORY_CONTINUE   = 0x3E,
MIPI_DCS_SET_TEAR_SCANLINE  = 0x44,
MIPI_DCS_GET_SCANLINE   = 0x45,
+   MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /* MIPI DCS 1.3 */
+   MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /* MIPI DCS 1.3 */
+   MIPI_DCS_WRITE_CONTROL_DISPLAY  = 0x53, /* MIPI DCS 1.3 */
+   MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /* MIPI DCS 1.3 */
+   MIPI_DCS_WRITE_POWER_SAVE   = 0x55, /* MIPI DCS 1.3 */
+   MIPI_DCS_GET_POWER_SAVE = 0x56, /* MIPI DCS 1.3 */
+   MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,/* MIPI DCS 1.3 */
+   MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,/* MIPI DCS 1.3 */
MIPI_DCS_READ_DDB_START = 0xA1,
MIPI_DCS_READ_DDB_CONTINUE  = 0xA8,
 };
-- 
2.7.4

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

[U-Boot] [PATCH v3 00/10] splash screen on the stm32f769 disco board

[Yannick Fertré]

Version 1:
- Initial commit.

Version 2:
- swap patches to avoid compilation issue.
- remove panel timings from device tree.

Version 3:
- Share same include file mipi_display.h with kernel linux.
- Rework ltdc driver with last comments of Anatolij Gustshin.
- Check ordering (file dw_mipi_dsi.c).
- Rename mipi_display.c to mipi_dsi.c.


This serie contains all patchsets needed for displaying a splash screen
on the stm32f769 disco board.
A new config has been created configs/stm32f769-disco_defconfig.
This is necessary due to the difference of panels between stm32f769-disco &
stm32f746-disco boards.

Yannick Fertré (10):
  video: stm32: stm32_ltdc: add bridge to display controller
  include: Add new DCS commands in the enum list
  video: add support of MIPI DSI interface
  video: add MIPI DSI host controller bridge
  video: add support of STM32 MIPI DSI controller driver
  video: add support of panel OTM8009A
  video: add support of panel RM68200
  arm: dts: stm32: add dsi for STM32F746
  arm: dts: stm32: add display for STM32F769 disco board
  board: Add STM32F769 SoC, discovery board support

 arch/arm/dts/stm32f746.dtsi|  12 +
 arch/arm/dts/stm32f769-disco.dts   |  41 ++
 configs/stm32f769-disco_defconfig  |  67 +++
 drivers/video/Kconfig  |  33 ++
 drivers/video/Makefile |   4 +
 drivers/video/dw_mipi_dsi.c| 827 
 drivers/video/mipi_dsi.c   | 828 +
 drivers/video/orisetech_otm8009a.c | 367 
 drivers/video/raydium-rm68200.c| 339 +++
 drivers/video/stm32/Kconfig|  10 +
 drivers/video/stm32/Makefile   |   1 +
 drivers/video/stm32/stm32_dsi.c| 428 +++
 drivers/video/stm32/stm32_ltdc.c   | 143 ---
 include/dw_mipi_dsi.h  |  33 ++
 include/mipi_display.h |   8 +
 include/mipi_dsi.h | 451 
 16 files changed, 3531 insertions(+), 61 deletions(-)
 create mode 100644 configs/stm32f769-disco_defconfig
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 drivers/video/mipi_dsi.c
 create mode 100644 drivers/video/orisetech_otm8009a.c
 create mode 100644 drivers/video/raydium-rm68200.c
 create mode 100644 drivers/video/stm32/stm32_dsi.c
 create mode 100644 include/dw_mipi_dsi.h
 create mode 100644 include/mipi_dsi.h

--
2.7.4

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

[U-Boot] [PATCH] ARM: dts: da850-evm-u-boot: Remove redundant entries

[Adam Ford]

With the re-sync from Linux 4.18, several entries in
da850-evm-u-boot.dtsi are no longer necessary, so this patch
removes them.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi 
b/arch/arm/dts/da850-evm-u-boot.dtsi
index b3546e792a..ab1de77954 100644
--- a/arch/arm/dts/da850-evm-u-boot.dtsi
+++ b/arch/arm/dts/da850-evm-u-boot.dtsi
@@ -6,17 +6,6 @@
  * Copyright (C) Adam Ford
  */
 
-/ {
-   chosen {
-   stdout-path = 
-   };
-
-   aliases {
-   i2c0 = 
-   spi0 = 
-   };
-};
-
  {
compatible = "m25p64", "spi-flash";
 };
-- 
2.17.1

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

Re: [U-Boot] [PATCH v4 01/17] ram: Add driver for MPC83xx

[Simon Glass]

Hi Mario,

On 6 August 2018 at 02:23, Mario Six  wrote:
> Add a RAM driver for the MPC83xx architecture.
>
> Reviewed-by: Simon Glass 
> Signed-off-by: Mario Six 
> ---
>
> Notes:
> v3 -> v4:
> * Switched preprocessor constants to C constants
> * Improved error reporting
> * Added driver binding file
> * Added full documentation
>
> v2 -> v3:
> * Converted some #ifdefs to if (IS_ENABLED(...))
> * Added driver files to MAINTAINERS
>
> v1 -> v2:
> No changes
>
>  .../bindings/ram/fsl,mpc83xx-mem-controller.txt|  314 ++
>  MAINTAINERS|2 +
>  arch/powerpc/cpu/mpc83xx/spd_sdram.c   |4 +
>  drivers/ram/Kconfig|9 +
>  drivers/ram/Makefile   |1 +
>  drivers/ram/mpc83xx_sdram.c| 1096 
> 
>  include/dt-bindings/memory/mpc83xx-sdram.h |  161 +++
>  include/mpc83xx.h  |6 +
>  8 files changed, 1593 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/ram/fsl,mpc83xx-mem-controller.txt
>  create mode 100644 drivers/ram/mpc83xx_sdram.c
>  create mode 100644 include/dt-bindings/memory/mpc83xx-sdram.h

This series has ended up assigned to me in patchwork.

We are at RC2 now so I can pull it into u-boot-dm/next. But if you
have other plans for the series, please let me know.

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

Re: [U-Boot] dts: Fix typo in OF_LIVE Kconfig help

[Tom Rini]

On Fri, Aug 17, 2018 at 10:16:36AM +0200, Michal Simek wrote:

> Fix typo in Kconfig description.
> 
> Signed-off-by: Michal Simek 

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] [PULL] u-boot-sh/master

[Tom Rini]

On Fri, Aug 17, 2018 at 12:10:11PM +0200, Marek Vasut wrote:

> The following changes since commit a032e0a6aed208977f48e78d2cc497b91543beaf:
> 
>   travis: give every job a name (2018-08-10 13:50:30 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 4f10989280bb91f0981ffe2ffabe936bb2a92364:
> 
>   ARM: rmobile: Enable USB PHY on Gen2 (2018-08-14 11:31:25 +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] [PULL] u-boot-socfpga/master

[Tom Rini]

On Fri, Aug 17, 2018 at 12:08:59PM +0200, Marek Vasut wrote:

> The following changes since commit a032e0a6aed208977f48e78d2cc497b91543beaf:
> 
>   travis: give every job a name (2018-08-10 13:50:30 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to b0c0a715f90690a7dd4f33cb5b5c21960be26d3c:
> 
>   arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask (2018-08-15 12:41:09
> +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,v2] kconfig: fix typo 'parition'

[Tom Rini]

On Thu, Aug 16, 2018 at 09:44:55AM +0200, Simon Goldschmidt wrote:

> Replaced misspelled words "parition"/"paritioning" (missing 't') in two
> Kconfig files by correct words "partition"/"partitioning"
> 
> Signed-off-by: Simon Goldschmidt 
> Reviewed-by: Philipp Tomsich 

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

[U-Boot] [PATCH] arm: dts: da850: Re-sync da850-evm.dts from Linux 4.18

[Adam Ford]

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
index 67e72bc72e..0e82bb988f 100644
--- a/arch/arm/dts/da850-evm.dts
+++ b/arch/arm/dts/da850-evm.dts
@@ -15,143 +15,18 @@
compatible = "ti,da850-evm", "ti,da850";
model = "DA850/AM1808/OMAP-L138 EVM";
 
-   soc@1c0 {
-   pmx_core: pinmux@14120 {
-   status = "okay";
-
-   mcasp0_pins: pinmux_mcasp0_pins {
-   pinctrl-single,bits = <
-   /*
-* AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
-* AFSR, AMUTE
-*/
-   0x00 0x 0x
-   /* AXR11, AXR12 */
-   0x04 0x00011000 0x000ff000
-   >;
-   };
-   nand_pins: nand_pins {
-   pinctrl-single,bits = <
-   /* EMA_WAIT[0], EMA_OE, EMA_WE, 
EMA_CS[4], EMA_CS[3] */
-   0x1c 0x10110110  0xf0ff0ff0
-   /*
-* EMA_D[0], EMA_D[1], EMA_D[2],
-* EMA_D[3], EMA_D[4], EMA_D[5],
-* EMA_D[6], EMA_D[7]
-*/
-   0x24 0x  0x
-   /* EMA_A[1], EMA_A[2] */
-   0x30 0x0110  0x0ff0
-   >;
-   };
-   };
-   serial0: serial@42000 {
-   status = "okay";
-   };
-   serial1: serial@10c000 {
-   status = "okay";
-   };
-   serial2: serial@10d000 {
-   status = "okay";
-   };
-   rtc0: rtc@23000 {
-   status = "okay";
-   };
-   i2c0: i2c@22000 {
-   status = "okay";
-   clock-frequency = <10>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-
-   tps: tps@48 {
-   reg = <0x48>;
-   };
-   tlv320aic3106: tlv320aic3106@18 {
-   #sound-dai-cells = <0>;
-   compatible = "ti,tlv320aic3106";
-   reg = <0x18>;
-   status = "okay";
-
-   /* Regulators */
-   IOVDD-supply = <_reg>;
-   /* Derived from VBAT: Baseboard 3.3V / 1.8V */
-   AVDD-supply = <>;
-   DRVDD-supply = <>;
-   DVDD-supply = <>;
-   };
-   tca6416: gpio@20 {
-   compatible = "ti,tca6416";
-   reg = <0x20>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-   };
-   wdt: wdt@21000 {
-   status = "okay";
-   };
-   mmc0: mmc@4 {
-   max-frequency = <5000>;
-   bus-width = <4>;
-   status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   };
-   spi1: spi@30e000 {
-   status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins _cs0_pin>;
-   flash: m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "m25p64";
-   spi-max-frequency = <3000>;
-   m25p,fast-read;
-   reg = <0>;
-   partition@0 {
-   label = "U-Boot-SPL";
-   reg = <0x 0x0001>;
-   read-only;
-   };
-   partition@1 {
-   label = "U-Boot";
-   reg = <0x0001 0x0008>;
-   read-only;
-   };
-   

Re: [U-Boot] [RFC PATCH v2 3/6] dm: usb: Add UCLASS_USB_DEV_GENERIC shutdown

[Jagan Teki]

Hi Simon,

On Fri, Aug 17, 2018 at 6:18 PM, Simon Glass  wrote:
> Hi Jagan,
>
> On 7 August 2018 at 01:03, Jagan Teki  wrote:
>> On Tue, Jul 24, 2018 at 5:18 AM, Simon Glass  wrote:
>>> Hi Jagan,
>>>
>>> On 20 July 2018 at 01:13, Jagan Teki  wrote:
 Some OTG controllers which operates on Peripheral
 mode are registered as UCLASS_USB_DEV_GENERIC.

 So add support to shutdown them as well. shutdown
 happened during 'usb reset' and U-Boot handoff code
 for Linux boot.

 controller restarting in 'usb reset' like probing
 again is still missing for this type of UCLASS.

 Cc: Simon Glass 
 Signed-off-by: Jagan Teki 
 ---
 Note:
 I tried of traversing for multiple UCLASS in removal
 code in usb_stop, but couldn't come with proper solutions.
 I don't think any other area of code need a requirement like
 this, or may be I'm missing. any help would appreciate.

 Changes for v2:
 - none

  drivers/usb/host/usb-uclass.c | 43 +++
  1 file changed, 43 insertions(+)

 diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
 index 611ea97a72..99cf3d2b49 100644
 --- a/drivers/usb/host/usb-uclass.c
 +++ b/drivers/usb/host/usb-uclass.c
 @@ -158,6 +158,45 @@ int usb_get_max_xfer_size(struct usb_device *udev, 
 size_t *size)
 return ops->get_max_xfer_size(bus, size);
  }

 +int __usb_stop(void)
>>>
>>> Why the __ ? I think it should be something like usb_remove_and_unbind_all()
>>>
 +{
 +   struct udevice *bus;
 +   struct udevice *rh;
 +   struct uclass *uc;
 +   struct usb_uclass_priv *uc_priv;
 +   int err = 0, ret;
 +
 +   /* De-activate any devices that have been activated */
 +   ret = uclass_get(UCLASS_USB_DEV_GENERIC, );
 +   if (ret)
 +   return ret;
 +
 +   uc_priv = uc->priv;
 +
 +   uclass_foreach_dev(bus, uc) {
 +   ret = device_remove(bus, DM_REMOVE_NORMAL);
 +   if (ret && !err)
 +   err = ret;
 +
 +   /* Locate root hub device */
 +   device_find_first_child(bus, );
 +   if (rh) {
 +   /*
 +* All USB devices are children of root hub.
 +* Unbinding root hub will unbind all of its 
 children.
 +*/
 +   ret = device_unbind(rh);
 +   if (ret && !err)
 +   err = ret;
 +   }
 +   }
 +
 +   uc_priv->companion_device_count = 0;
 +   usb_started = 0;
 +
 +   return err;
 +}
 +
  int usb_stop(void)
  {
 struct udevice *bus;
 @@ -166,6 +205,10 @@ int usb_stop(void)
 struct usb_uclass_priv *uc_priv;
 int err = 0, ret;

 +   ret = __usb_stop();
 +   if (ret)
 +   return ret;
 +
>>>
>>> This looks like the same code that appears below here, or very
>>> similar. Why is this needed?
>>
>> Here the usage-case it to remove/unbind UCLASS_USB and
>> UCLASS_USB_DEV_GENERIC and same code will use to do that, any
>> suggestions?
>
> I'm just wondering why you appear to be duplicating the exact code
> that is already there? Maybe I am missing something, iwc please can
> you explain it?

Yes, the code is duplicate. Here, I'm looking for suggestion to
unbind/remove multiple UCLASS's like UCLASS_USB and
ULASS_USB_DEV_GENERIC in this use-case. do you have any? or am I
missing something?

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

Re: [U-Boot] [PATCH 0/4] arm: zynq: migrate to DM I2C driver

[Olliver Schinagl]

Hi all,

On 20-07-18 13:09, Michal Simek wrote:

On 20.7.2018 08:12, Luis Araneda wrote:

Hi Michal,

On Thu, Jul 19, 2018 at 3:28 AM Michal Simek  wrote:

Please take a look at
https://lists.denx.de/pipermail/u-boot/2016-November/274068.html which
was the series which should replace all these boards setting in a
generic way. Unfortunately I don't know why it didn't go through.
Neither do I :) some of them where 'done' as far as I remember, but it 
has been a while and I have somewhat forgotten about them a little. They 
have been used in production since then however for us.


There are plans to work on our u-boot again in the next few months and 
my intention was to pick up the ones that did not get merged.




The last version of that series [1] (v6, 28 patches) has the state
"Changes Requested" on patchwork, and it even has some TODOs. It's a
generic way of reading a MAC address from an EEPROM with helper
functions.
I'm not proposing something as generic and elaborated as that series,
but an improvement to what is used today.

I sent this series to move some legacy options to Kconfig.
Additionally, the Zybo Z7 has its MAC address stored on an SPI FLASH,
which will likely require a new Kconfig option (MAC_ADDR_IN_SPI_FLASH)
eventually. Something that [1] doesn't cover (from what I read).
No, I did not have SPI memory available at the time, and was sort of 
waiting for the generic EEPROM framework to progress (that died).


Having said that, adding SPI eeprom would have been trivial.



It just occurred to me that what I'm really doing in the fourth patch
is reading the MAC address from a generic memory connected to I2C,
because it's a generic memory read operation (device address, memory
address, read operation). So I think the name of the Kconfigs could be
CONFIG_MAC_ADDR_IN_I2C_MEMORY instead of
CONFIG_MAC_ADDR_IN_I2C_EEPROM. It can even be more generic like
CONFIG_MAC_ADDR_IN_I2C. What do yo think?
Well I think the generic memory framework did make sense at the time, 
and didn't compulab merge something like this at some point?





And then regarding DM i2c. Driver is in the driver for a while but for
i2c muxes support it requires all subbusses to be listed in DTS file
which is not what it is common in Linux dt binding. That's why some work
needs to be done in this area to convert all platforms.


Yes, I realize that I2C muxes are a pending issue, but that's why I
only migrated the boards that are not using I2C muxes. From my point
of view, it's less work to be done when porting

Anyway, I just wanted to improve the current state of the code, I
don't need these changes for what I'm doing. So if you like to wait
for [1] to be merged, it's fine with me and we can drop this series,
otherwise, please review it so I can make changes if necessary.

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


I have no problem to move ZYNQ_GEM_EEPROM_ADDR to Kconfig without
changing the name.

Oliver: Any comment about your patch series?

What I just wrote above :)


And I would let Joe to handle that mac address reading.
That v6 series contains a lot of patches which have been acked. The
biggest problem was about sunxi which is something what can be ignored.
If Oliver doesn't want to send v7 then I would recommend you simply take
his v6 version and that patches which are required and just send them
again. I think it won't take so much time because a lot of things were
already done.
I don't mind starting to work on a v7; i think one of the issues I ran 
into was turn around time which took quite a while. I may even have v7 
locally actually! I'll see what can be done within the comming period; 
but again, we are going to update/add more support to our u-boot so I 
should be working on this again soon-ish.




Thanks,
Michal



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

Re: [U-Boot] [UBOOT PATCH 2/2] dm: core: Scan "/firmware" node by default

[Michal Simek]

On 17.8.2018 14:49, Simon Glass wrote:
> On 10 August 2018 at 02:45, Rajan Vaja  wrote:
>> All Linux firmware drivers are put under "/firmware" node
>> and it has support to populate "/firmware" node by default.
>>
>> u-boot and Linux can share same DTB. In this case, driver
>> probe for devices under "/firmware" will not be invoked
>> as "/firmware" does not have its own "compatible" property.
>>
>> This patch scans "/firmware" node by default like "/clocks".
>>
>> Signed-off-by: Rajan Vaja 
>> ---
>>  drivers/core/root.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
> We should add a firmware device for sandbox.
> 

what to add there?

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

Re: [U-Boot] [PATCH 3/3] bootcount: add DM-based backing store for bootcount

[Dr. Philipp Tomsich]

Simon,

> On 17 Aug 2018, at 14:49, Simon Glass  wrote:
> 
> Hi Philipp,
> 
> On 14 August 2018 at 05:39, Dr. Philipp Tomsich
>  > wrote:
>> Lukasz,
>> 
>>> On 14 Aug 2018, at 13:10, Lukasz Majewski  wrote:
>>> 
>>> Hi Philipp,
>>> 
 The original bootcount methods do not provide an interface to DM and
 rely on a static configuration for I2C devices (e.g. bus, chip-addr,
 etc. are configured through defines statically).  On a modern system
 that exposes multiple devices in a DTS-configurable way, this is less
 than optimal and a interface to DM-based devices will be desirable.
 
 This adds a simple driver that is DM-aware and configurable via DTS:
 the /chosen/u-boot,bootcount-device property is used to detect the DM
 device storing the bootcount and deviceclass-specific commands are
 used to read/write the bootcount.
 
 Initially, this provides support for the following DM devices:
 * RTC devices implementing the read8/write8 ops
 
 Signed-off-by: Philipp Tomsich 
 Tested-by: Klaus Goger 
 ---
 
 doc/device-tree-bindings/chosen.txt | 27 +++
 drivers/bootcount/Kconfig   | 12 +
 drivers/bootcount/Makefile  |  1 +
 drivers/bootcount/bootcount_dm.c| 93
 + 4 files changed, 133
 insertions(+) create mode 100644 drivers/bootcount/bootcount_dm.c
 
 diff --git a/doc/device-tree-bindings/chosen.txt
 b/doc/device-tree-bindings/chosen.txt index da7b4e6..734fd15 100644
 --- a/doc/device-tree-bindings/chosen.txt
 +++ b/doc/device-tree-bindings/chosen.txt
 @@ -42,6 +42,33 @@ Example
 };
 };
 
 +u-boot,bootcount-device property
 +
 +In a DM-based system, the bootcount may be stored in a device known
 to +the DM framework (e.g. in a battery-backed SRAM area within a RTC
 +device).  To identify the device to be used for the bootcount, the
 +u-boot,bootcount-device property needs to point to the target device.
 +
 +Further configuration in the target device's node may be required
 +(e.g. an offset into an I2C RTC's address space), depending on the
 +UCLASS of the target device.
 +
 +Example
 +---
 +/ {
 +chosen {
 +u-boot,bootcount-device = 
 +};
 +
 +i2c2 {
 +rv3029: rtc@56 {
 +compatible = "mc,rv3029";
 +reg = <0x56>;
 +u-boot,bootcount-offset = <0x38>;
 +};
 +};
 +};
 +
 u-boot,spl-boot-order property
 --
 
 diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
 index d335ed1..cdde7b5 100644
 --- a/drivers/bootcount/Kconfig
 +++ b/drivers/bootcount/Kconfig
 @@ -70,6 +70,18 @@ config BOOTCOUNT_AT91
 bool "Boot counter for Atmel AT91SAM9XE"
 depends on AT91SAM9XE
 
 +config BOOTCOUNT_DM
 +bool "Boot counter in a device-model device"
 +help
 +  Enables reading/writing the bootcount in a device-model
 +  device referenced from the /chosen node.  The type of the
 +  device is detected from DM and any additional configuration
 +  information (e.g. the offset into a RTC device that
 supports
 +  read32/write32) is read from the device's node.
 +
 +  At this time the following DM device classes are supported:
 +   * RTC (using read32/write32)
 +
 endchoice
 
 config BOOTCOUNT_ALEN
 diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
 index 68bc006..e8ed729 100644
 --- a/drivers/bootcount/Makefile
 +++ b/drivers/bootcount/Makefile
 @@ -7,3 +7,4 @@ obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
 obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
 obj-$(CONFIG_BOOTCOUNT_I2C)  += bootcount_i2c.o
 obj-$(CONFIG_BOOTCOUNT_EXT)  += bootcount_ext.o
 +obj-$(CONFIG_BOOTCOUNT_DM)  += bootcount_dm.o
 diff --git a/drivers/bootcount/bootcount_dm.c
 b/drivers/bootcount/bootcount_dm.c new file mode 100644
 index 000..99bdb88
 --- /dev/null
 +++ b/drivers/bootcount/bootcount_dm.c
 @@ -0,0 +1,93 @@
 +// SPDX-License-Identifier: GPL-2.0+
 +/*
 + * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +const u8 bootcount_magic = 0xbc;
 +
 +static void bootcount_store_rtc(struct udevice *dev, ulong a)
 +{
 +#if CONFIG_IS_ENABLED(DM_RTC)
 +u32 offset;
 +const char *offset_propname = "u-boot,bootcount-offset";
 +const u16 val = bootcount_magic << 8 | (a & 0xff);
 +
 +if (dev_read_u32(dev, 

Re: [U-Boot] [PATCH v2 1/3] efi: Fix truncation of constant value

[Eugeniu Rosca]

On Fri, Aug 17, 2018 at 06:48:52AM -0600, Simon Glass wrote:
> I believe Alex should pick these up.
> 
> Regards,
> Simon

Thanks, Simon!
I then look forward for some feedback from Alex.

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

Re: [U-Boot] [PATCH v2 1/3] efi: Fix truncation of constant value

[Simon Glass]

Hi,

On 8 August 2018 at 14:41, Eugeniu Rosca  wrote:
> Hello Tom, Alexander,
>
> On Wed, Aug 01, 2018 at 01:25:54PM +0200, Eugeniu Rosca wrote:
>> Hello Tom, Simon, Alexander, Heinrich,
>>
>> On Wed, Jul 25, 2018 at 03:30:16PM +0200, Eugeniu Rosca wrote:
>> > Hello Alexander,
>> >
>> > Heinrich was kind to have a look at [1] and already provided his
>> > Reviewed-by. Could you please state your further expectations to accept
>> > the patches?
>> >
>> > [1] https://patchwork.ozlabs.org/patch/944004/
>> >
>> > Thanks,
>> > Eugeniu.
>>
>> Any idea how to move forward with these patches?
>
> I apologize for this second reminder. Could you please suggest the next
> steps for this simple set of three fixes? Thank you.
>
>> Best regards,
>> Eugeniu.
>>

I believe Alex should pick these up.

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

Re: [U-Boot] sunxi: USB gadget does not work on H2+ after 92a30692b2b18f45aae6fdaae38d67ed03dd2d11

[Nuno Gonçalves]

This can be because UMS is not DM aware?

On Fri, Aug 17, 2018 at 2:02 PM Nuno Gonçalves  wrote:

> This test is on 2018.09-rc2 with UMS enabled.
>
> With your patch, I get this dmesg on the host:
>
> [20121.718226] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
> [20122.578151] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
> [20122.578320] usb 1-4-port4: attempt power cycle
> [20123.750104] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
> [20124.602034] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
> [20124.602190] usb 1-4-port4: unable to enumerate USB device
>
> u-boot console is the same, including loading the gadget:
>
> Allwinner mUSB OTG (Peripheral)
>
> If you tell me how you tested USB Gadget to work, I will reproduce your
> test locally to confirm the issue.
>
> Thanks,
> Nuno
>
>
> On Fri, Aug 17, 2018 at 1:38 PM Jagan Teki 
> wrote:
>
>> On Mon, Aug 13, 2018 at 3:59 PM, Nuno Gonçalves 
>> wrote:
>> > After this commit usb gadget does not work anymore for me on the Orange
>> Pi
>> > Zero (H2+).
>>
>> Please send log or full information?
>>
>> Jagan.
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [UBOOT PATCH 1/2] dm: core: Move "/clock" node scan into function

[Simon Glass]

On 10 August 2018 at 02:45, Rajan Vaja  wrote:
> Create separate function for scanning node by path and
> move "/clock" node scan code into that function.
>
> This will be usable if scanning of more node is required.
>
> Signed-off-by: Rajan Vaja 
> ---
>  drivers/core/root.c | 33 ++---
>  1 file changed, 18 insertions(+), 15 deletions(-)
>

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

Re: [U-Boot] [PATCH v3 8/8] video_display: Add Xilinx LogiCore DP TX

[Simon Glass]

On 9 August 2018 at 06:51, Mario Six  wrote:
> Add a driver for the Xilinx LogiCORE DisplayPort IP core, which is a
> pure DP transmitter core for Xiling FPGA (no display capabilities).
>
> Signed-off-by: Mario Six 
>
> ---
>
> v2 -> v3:
> * Fix style errors
> * Added full documentation
>
> v1 -> v2:
> * Switch to display_enable
> * Mentioned that the LogiCORE has no display capabilities
>
> ---
>  drivers/video/Kconfig|   11 +
>  drivers/video/Makefile   |1 +
>  drivers/video/logicore_dp_dpcd.h |  341 +
>  drivers/video/logicore_dp_tx.c   | 2296 
> ++
>  drivers/video/logicore_dp_tx.h   |   54 +
>  drivers/video/logicore_dp_tx_regif.h |  396 ++
>  6 files changed, 3099 insertions(+)
>  create mode 100644 drivers/video/logicore_dp_dpcd.h
>  create mode 100644 drivers/video/logicore_dp_tx.c
>  create mode 100644 drivers/video/logicore_dp_tx.h
>  create mode 100644 drivers/video/logicore_dp_tx_regif.h

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

Re: [U-Boot] [RFC PATCH v2 3/6] dm: usb: Add UCLASS_USB_DEV_GENERIC shutdown

[Simon Glass]

Hi Jagan,

On 7 August 2018 at 01:03, Jagan Teki  wrote:
> On Tue, Jul 24, 2018 at 5:18 AM, Simon Glass  wrote:
>> Hi Jagan,
>>
>> On 20 July 2018 at 01:13, Jagan Teki  wrote:
>>> Some OTG controllers which operates on Peripheral
>>> mode are registered as UCLASS_USB_DEV_GENERIC.
>>>
>>> So add support to shutdown them as well. shutdown
>>> happened during 'usb reset' and U-Boot handoff code
>>> for Linux boot.
>>>
>>> controller restarting in 'usb reset' like probing
>>> again is still missing for this type of UCLASS.
>>>
>>> Cc: Simon Glass 
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Note:
>>> I tried of traversing for multiple UCLASS in removal
>>> code in usb_stop, but couldn't come with proper solutions.
>>> I don't think any other area of code need a requirement like
>>> this, or may be I'm missing. any help would appreciate.
>>>
>>> Changes for v2:
>>> - none
>>>
>>>  drivers/usb/host/usb-uclass.c | 43 +++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
>>> index 611ea97a72..99cf3d2b49 100644
>>> --- a/drivers/usb/host/usb-uclass.c
>>> +++ b/drivers/usb/host/usb-uclass.c
>>> @@ -158,6 +158,45 @@ int usb_get_max_xfer_size(struct usb_device *udev, 
>>> size_t *size)
>>> return ops->get_max_xfer_size(bus, size);
>>>  }
>>>
>>> +int __usb_stop(void)
>>
>> Why the __ ? I think it should be something like usb_remove_and_unbind_all()
>>
>>> +{
>>> +   struct udevice *bus;
>>> +   struct udevice *rh;
>>> +   struct uclass *uc;
>>> +   struct usb_uclass_priv *uc_priv;
>>> +   int err = 0, ret;
>>> +
>>> +   /* De-activate any devices that have been activated */
>>> +   ret = uclass_get(UCLASS_USB_DEV_GENERIC, );
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   uc_priv = uc->priv;
>>> +
>>> +   uclass_foreach_dev(bus, uc) {
>>> +   ret = device_remove(bus, DM_REMOVE_NORMAL);
>>> +   if (ret && !err)
>>> +   err = ret;
>>> +
>>> +   /* Locate root hub device */
>>> +   device_find_first_child(bus, );
>>> +   if (rh) {
>>> +   /*
>>> +* All USB devices are children of root hub.
>>> +* Unbinding root hub will unbind all of its 
>>> children.
>>> +*/
>>> +   ret = device_unbind(rh);
>>> +   if (ret && !err)
>>> +   err = ret;
>>> +   }
>>> +   }
>>> +
>>> +   uc_priv->companion_device_count = 0;
>>> +   usb_started = 0;
>>> +
>>> +   return err;
>>> +}
>>> +
>>>  int usb_stop(void)
>>>  {
>>> struct udevice *bus;
>>> @@ -166,6 +205,10 @@ int usb_stop(void)
>>> struct usb_uclass_priv *uc_priv;
>>> int err = 0, ret;
>>>
>>> +   ret = __usb_stop();
>>> +   if (ret)
>>> +   return ret;
>>> +
>>
>> This looks like the same code that appears below here, or very
>> similar. Why is this needed?
>
> Here the usage-case it to remove/unbind UCLASS_USB and
> UCLASS_USB_DEV_GENERIC and same code will use to do that, any
> suggestions?

I'm just wondering why you appear to be duplicating the exact code
that is already there? Maybe I am missing something, iwc please can
you explain it?

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

Re: [U-Boot] [PATCH v4 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line

[Simon Glass]

On 9 August 2018 at 08:17, Jean-Jacques Hiblot  wrote:
> In some cases it can be useful to be able to bind a device to a driver from
> the command line.
> The obvious example is for versatile devices such as USB gadget.
> Another use case is when the devices are not yet ready at startup and
> require some setup before the drivers are bound (ex: FPGA which bitsream is
> fetched from a mass storage or ethernet)
>
> usage example:
>
> bind usb_dev_generic 0 usb_ether
> unbind usb_dev_generic 0 usb_ether
> or
> unbind eth 1
>
> bind /ocp/omap_dwc3@4838/usb@4839 usb_ether
> unbind /ocp/omap_dwc3@4838/usb@4839
>
> Signed-off-by: Jean-Jacques Hiblot 
>
>
> ---
>
> Changes in v4:
> - Fixed compiler warning: "cmd/bind.c:236:5: warning: ‘ret’ may be used
>   uninitialized in this function [-Wmaybe-uninitialized]"
>
> Changes in v3:
> - factorize code based on comments from ML
> - remove the devices before unbinding them
> - use device_find_global_by_ofnode() to get a device by its node.
>
> Changes in v2:
> - Make the bind/unbind command generic, not specific to usb device.
> - Update the API to be able to bind/unbind based on DTS node path
> - Add a Kconfig option to select the bind/unbind commands
>
>  arch/sandbox/dts/test.dts  |  11 ++
>  cmd/Kconfig|   9 ++
>  cmd/Makefile   |   1 +
>  cmd/bind.c | 255 
> +
>  configs/sandbox_defconfig  |   1 +
>  test/py/tests/test_bind.py | 178 +++
>  6 files changed, 455 insertions(+)
>  create mode 100644 cmd/bind.c
>  create mode 100644 test/py/tests/test_bind.py

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

Re: [U-Boot] sunxi: USB gadget does not work on H2+ after 92a30692b2b18f45aae6fdaae38d67ed03dd2d11

[Nuno Gonçalves]

This test is on 2018.09-rc2 with UMS enabled.

With your patch, I get this dmesg on the host:

[20121.718226] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
[20122.578151] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
[20122.578320] usb 1-4-port4: attempt power cycle
[20123.750104] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
[20124.602034] usb 1-4-port4: Cannot enable. Maybe the USB cable is bad?
[20124.602190] usb 1-4-port4: unable to enumerate USB device

u-boot console is the same, including loading the gadget:

Allwinner mUSB OTG (Peripheral)

If you tell me how you tested USB Gadget to work, I will reproduce your
test locally to confirm the issue.

Thanks,
Nuno


On Fri, Aug 17, 2018 at 1:38 PM Jagan Teki 
wrote:

> On Mon, Aug 13, 2018 at 3:59 PM, Nuno Gonçalves  wrote:
> > After this commit usb gadget does not work anymore for me on the Orange
> Pi
> > Zero (H2+).
>
> Please send log or full information?
>
> Jagan.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/7] uclass: Add dev_get_uclass_index() to get the uclass/index of a device

[Simon Glass]

On 9 August 2018 at 08:17, Jean-Jacques Hiblot  wrote:
>
> This function is the reciprocal of uclass_find_device().
> It will be used to print the index information in dm tree dump.
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - update commit log
> - fixed problem with the function name
>
> Changes in v2: None
>
>  drivers/core/uclass.c| 21 +
>  include/dm/uclass-internal.h | 11 +++
>  2 files changed, 32 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 3/3] bootcount: add DM-based backing store for bootcount

[Simon Glass]

Hi Philipp,

On 14 August 2018 at 05:39, Dr. Philipp Tomsich
 wrote:
> Lukasz,
>
>> On 14 Aug 2018, at 13:10, Lukasz Majewski  wrote:
>>
>> Hi Philipp,
>>
>>> The original bootcount methods do not provide an interface to DM and
>>> rely on a static configuration for I2C devices (e.g. bus, chip-addr,
>>> etc. are configured through defines statically).  On a modern system
>>> that exposes multiple devices in a DTS-configurable way, this is less
>>> than optimal and a interface to DM-based devices will be desirable.
>>>
>>> This adds a simple driver that is DM-aware and configurable via DTS:
>>> the /chosen/u-boot,bootcount-device property is used to detect the DM
>>> device storing the bootcount and deviceclass-specific commands are
>>> used to read/write the bootcount.
>>>
>>> Initially, this provides support for the following DM devices:
>>> * RTC devices implementing the read8/write8 ops
>>>
>>> Signed-off-by: Philipp Tomsich 
>>> Tested-by: Klaus Goger 
>>> ---
>>>
>>> doc/device-tree-bindings/chosen.txt | 27 +++
>>> drivers/bootcount/Kconfig   | 12 +
>>> drivers/bootcount/Makefile  |  1 +
>>> drivers/bootcount/bootcount_dm.c| 93
>>> + 4 files changed, 133
>>> insertions(+) create mode 100644 drivers/bootcount/bootcount_dm.c
>>>
>>> diff --git a/doc/device-tree-bindings/chosen.txt
>>> b/doc/device-tree-bindings/chosen.txt index da7b4e6..734fd15 100644
>>> --- a/doc/device-tree-bindings/chosen.txt
>>> +++ b/doc/device-tree-bindings/chosen.txt
>>> @@ -42,6 +42,33 @@ Example
>>>  };
>>> };
>>>
>>> +u-boot,bootcount-device property
>>> +
>>> +In a DM-based system, the bootcount may be stored in a device known
>>> to +the DM framework (e.g. in a battery-backed SRAM area within a RTC
>>> +device).  To identify the device to be used for the bootcount, the
>>> +u-boot,bootcount-device property needs to point to the target device.
>>> +
>>> +Further configuration in the target device's node may be required
>>> +(e.g. an offset into an I2C RTC's address space), depending on the
>>> +UCLASS of the target device.
>>> +
>>> +Example
>>> +---
>>> +/ {
>>> +chosen {
>>> +u-boot,bootcount-device = 
>>> +};
>>> +
>>> +i2c2 {
>>> +rv3029: rtc@56 {
>>> +compatible = "mc,rv3029";
>>> +reg = <0x56>;
>>> +u-boot,bootcount-offset = <0x38>;
>>> +};
>>> +};
>>> +};
>>> +
>>> u-boot,spl-boot-order property
>>> --
>>>
>>> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
>>> index d335ed1..cdde7b5 100644
>>> --- a/drivers/bootcount/Kconfig
>>> +++ b/drivers/bootcount/Kconfig
>>> @@ -70,6 +70,18 @@ config BOOTCOUNT_AT91
>>>  bool "Boot counter for Atmel AT91SAM9XE"
>>>  depends on AT91SAM9XE
>>>
>>> +config BOOTCOUNT_DM
>>> +bool "Boot counter in a device-model device"
>>> +help
>>> +  Enables reading/writing the bootcount in a device-model
>>> +  device referenced from the /chosen node.  The type of the
>>> +  device is detected from DM and any additional configuration
>>> +  information (e.g. the offset into a RTC device that
>>> supports
>>> +  read32/write32) is read from the device's node.
>>> +
>>> +  At this time the following DM device classes are supported:
>>> +   * RTC (using read32/write32)
>>> +
>>> endchoice
>>>
>>> config BOOTCOUNT_ALEN
>>> diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
>>> index 68bc006..e8ed729 100644
>>> --- a/drivers/bootcount/Makefile
>>> +++ b/drivers/bootcount/Makefile
>>> @@ -7,3 +7,4 @@ obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
>>> obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
>>> obj-$(CONFIG_BOOTCOUNT_I2C)  += bootcount_i2c.o
>>> obj-$(CONFIG_BOOTCOUNT_EXT)  += bootcount_ext.o
>>> +obj-$(CONFIG_BOOTCOUNT_DM)  += bootcount_dm.o
>>> diff --git a/drivers/bootcount/bootcount_dm.c
>>> b/drivers/bootcount/bootcount_dm.c new file mode 100644
>>> index 000..99bdb88
>>> --- /dev/null
>>> +++ b/drivers/bootcount/bootcount_dm.c
>>> @@ -0,0 +1,93 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +const u8 bootcount_magic = 0xbc;
>>> +
>>> +static void bootcount_store_rtc(struct udevice *dev, ulong a)
>>> +{
>>> +#if CONFIG_IS_ENABLED(DM_RTC)
>>> +u32 offset;
>>> +const char *offset_propname = "u-boot,bootcount-offset";
>>> +const u16 val = bootcount_magic << 8 | (a & 0xff);
>>> +
>>> +if (dev_read_u32(dev, offset_propname, ) < 0) {
>>> +debug("%s: requires %s\n", __func__,
>>> offset_propname);
>>> +return;
>>> +}
>>> +
>>> +if (rtc_write16(dev, offset, val) < 0) {
>>> +debug("%s: rtc_write16 failed\n", __func__);

Re: [U-Boot] [PATCH] efi_loader: Rename sections to allow for implicit data

[Simon Glass]

Hi,

On 9 August 2018 at 23:45, Bin Meng  wrote:
>
> Hi Alex,
>
> On Wed, Aug 8, 2018 at 1:16 AM, Alexander Graf  wrote:
> >
> >
> >> Am 07.08.2018 um 18:12 schrieb Simon Glass :
> >>
> >> Hi Alex,
> >>
> >>> On 11 June 2018 at 23:48, Alexander Graf  wrote:
> >>> Some times gcc may generate data that is then used within code that may
> >>> be part of an efi runtime section. That data could be jump tables,
> >>> constants or strings.
> >>>
> >>> In order to make sure we catch these, we need to ensure that gcc emits
> >>> them into a section that we can relocate together with all the other
> >>> efi runtime bits. This only works if the -ffunction-sections and
> >>> -fdata-sections flags are passed and the efi runtime functions are
> >>> in a section that starts with ".text".
> >>>
> >>> Up to now we had all efi runtime bits in sections that did not
> >>> interfere with the normal section naming scheme, but this forces
> >>> us to do so. Hence we need to move the efi_loader text/data/rodata
> >>> sections before the global *(.text*) catch-all section.
> >>>
> >>> With this patch in place, we should hopefully have an easier time
> >>> to extend the efi runtime functionality in the future.
> >>>
> >>> Signed-off-by: Alexander Graf 
> >>> ---
> >>> arch/arm/config.mk|  4 ++--
> >>> arch/arm/cpu/armv8/u-boot.lds | 24 +
> >>> arch/arm/cpu/u-boot.lds   | 36 
> >>> ++-
> >>> arch/arm/mach-zynq/u-boot.lds | 36 
> >>> ++-
> >>> arch/riscv/cpu/ax25/u-boot.lds| 26 +-
> >>> arch/sandbox/config.mk|  3 +++
> >>> arch/sandbox/cpu/u-boot.lds   |  9 
> >>> arch/x86/config.mk|  2 +-
> >>> arch/x86/cpu/u-boot.lds   | 32 ++-
> >>> board/qualcomm/dragonboard410c/u-boot.lds | 17 +--
> >>> board/qualcomm/dragonboard820c/u-boot.lds | 24 +
> >>> board/ti/am335x/u-boot.lds| 36 
> >>> ++-
> >>> include/efi_loader.h  |  4 ++--
> >>> 13 files changed, 154 insertions(+), 99 deletions(-)
> >>>
> >>
> >> I missed this at the time, probably thinking the subject made it sound
> >> innocuous. There is no 'sandbox:' tag.
> >>
> >> This seems to break sandbox in a pretty strange way:
> >>
> >> gdb --args /tmp/crosfw/sandbox/u-boot -D
> >> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> >> Copyright (C) 2016 Free Software Foundation, Inc.
> >> License GPLv3+: GNU GPL version 3 or later 
> >> 
> >> This is free software: you are free to change and redistribute it.
> >> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> >> and "show warranty" for details.
> >> This GDB was configured as "x86_64-linux-gnu".
> >> Type "show configuration" for configuration details.
> >> For bug reporting instructions, please see:
> >> .
> >> Find the GDB manual and other documentation resources online at:
> >> .
> >> For help, type "help".
> >> Type "apropos word" to search for commands related to "word"...
> >> Reading symbols from /tmp/crosfw/sandbox/u-boot...done.
> >> (gdb) r
> >> Starting program: /tmp/crosfw/sandbox/u-boot -D
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x55571520 in open@plt ()
> >> (gdb) up
> >> #1  0x55571e9a in sandbox_read_fdt_from_file ()
> >>at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/cpu.c:264
> >> 264 fd = os_open(fname, OS_O_RDONLY);
> >> (gdb) print fname
> >> $1 = 0x77ff "/tmp/crosfw/sandbox/u-boot.dtb"
> >> (gdb) q
> >>
> >>
> >> Also the commit message suggests that this patch changes sandbox to
> >> use --gc-sections, which is not obvious from the subject. I think that
> >> should be a separate commit and in fact it should really be separate
> >> commits for each arch, I think. That might help people notice it...
> >>
> >> I only noticed now since the EFI pull request has landed.
> >
> > Can you try my bss patch really quick? Maybe we're just overwriting gd.
> >
> > Alex
> >
>
> This patch breaks efi-x86_app_defconfig. The EFI application no longer
> boots. I was testing on top of u-boot/master.
>
> If I do:
>
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index 586e11a..fc119ec 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -24,7 +24,6 @@ endif
>  ifeq ($(IS_32BIT),y)
>  PLATFORM_CPPFLAGS += -march=i386 -m32
>  # TODO: These break on x86_64; need to debug further
> -PLATFORM_RELFLAGS += -fdata-sections
>  else
>  PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64
>  endif
>
> 

Re: [U-Boot] [PATCH v3 7/8] video: Sort Makefile entries

[Simon Glass]

On 9 August 2018 at 06:51, Mario Six  wrote:
> The entries of Makefiles should be sorted, which is not the case in the
> video driver Makefile.
>
> Sort the entries alphabetically as far as this makes sense.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v2 -> v3:
> New in v3
>
> ---
>  drivers/video/Makefile | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
>

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/4] env: fat: drop not needed #ifdef CMD_SAVEENV

[Simon Glass]

On 14 August 2018 at 03:21, Christian Gmeiner
 wrote:
> env_save_ptr(..) macro handles CMD_SAVEENV already.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  env/fat.c | 2 --
>  1 file changed, 2 deletions(-)
>

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

Re: [U-Boot] [PATCH 6/6] x86: efi: payload: Add default TSC frequency in the device tree

[Simon Glass]

On 10 August 2018 at 03:39, Bin Meng  wrote:
> It was observed sometimes U-Boot as the EFI payload fails to boot on
> QEMU. This is because TSC calibration fails with no valid frequency.
> This adds default TSC frequency in the device tree.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/efi-x86_payload.dts | 4 
>  1 file changed, 4 insertions(+)

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

Re: [U-Boot] [UBOOT PATCH 2/2] dm: core: Scan "/firmware" node by default

[Simon Glass]

On 10 August 2018 at 02:45, Rajan Vaja  wrote:
> All Linux firmware drivers are put under "/firmware" node
> and it has support to populate "/firmware" node by default.
>
> u-boot and Linux can share same DTB. In this case, driver
> probe for devices under "/firmware" will not be invoked
> as "/firmware" does not have its own "compatible" property.
>
> This patch scans "/firmware" node by default like "/clocks".
>
> Signed-off-by: Rajan Vaja 
> ---
>  drivers/core/root.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

We should add a firmware device for sandbox.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sandbox: Move BSS after EFI sections

[Simon Glass]

Hi,

On 6 August 2018 at 16:30, Alexander Graf  wrote:
> Something went wrong when writing the sandbox linker scripts and so we
> ended up with a .bss section marker right before the efi runtime sections.
>
> That obviously is a terrible idea, as it may result in overwriting efi
> runtime code and data. So let's move the .bss identifier behind the efi
> sections.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/sandbox/cpu/u-boot.lds | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

I think we should revert the patch that changed this, and deal with
each of its changes one by one. As of now, sandbox is broken.

I already sent a patch for this.

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

Re: [U-Boot] [PATCH 2/4] env: flash: drop not needed #ifdef CMD_SAVEENV

[Simon Glass]

On 14 August 2018 at 03:21, Christian Gmeiner
 wrote:
> env_save_ptr(..) macro handles CMD_SAVEENV already.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  env/flash.c | 2 --
>  1 file changed, 2 deletions(-)

Reviewed-by: Simon Glass 

I'd be tempted to do these changes in one patch, but either is fine with me.

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

Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions

[Simon Glass]

Hi Mario,

On 13 August 2018 at 00:09, Mario Six  wrote:
> The regmap functions currently assume that all register map accesses
> have a data width of 32 bits, but there are maps that have different
> widths.
>
> To rectify this, implement the regmap_raw_read and regmap_raw_write
> functions from the Linux kernel API that specify the width of a desired
> read or write operation on a regmap.
>
> Implement the regmap_read and regmap_write functions using these raw
> functions in a backwards-compatible manner.
>
> Reviewed-by: Anatolij Gustschin 
> Signed-off-by: Mario Six 
>
> ---
>
> v5 -> v6:
> * Corrected format specifier
> * Added support for 64-bit reads/writes
>
> v4 -> v5:
> No changes
>
> v3 -> v4:
> * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> * Explained the difference between the raw and non-raw read/write
>   functions better in the docs
>
> v2 -> v3:
> * Implement the "raw" functions from Linux instead of adding a size
>   parameter to the regmap_{read,write} functions
> * Fixed style violation
> * Improved error handling
>
> v1 -> v2:
> New in v2
>
> ---
>  drivers/core/regmap.c | 59 
> +--
>  include/regmap.h  | 58 ++
>  2 files changed, 110 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 154426269d9..a2f82091af0 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> return 0;
>  }
>
> +int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t 
> val_len)
> +{
> +   void *ptr;
> +
> +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> MAP_NOCACHE);
> +
> +   switch (val_len) {
> +   case REGMAP_SIZE_8:
> +   *((u8 *)valp) = in_8((u8 *)ptr);
> +   break;
> +   case REGMAP_SIZE_16:
> +   *((u16 *)valp) = in_le16((u16 *)ptr);
> +   break;
> +   case REGMAP_SIZE_32:
> +   *((u32 *)valp) = in_le32((u32 *)ptr);
> +   break;
> +#if defined(in_le64) && defined(readq)
> +   case REGMAP_SIZE_64:
> +   *((u32 *)valp) = in_le64((u64 *)ptr);

How come this is u32? Can you please add a comment?

Why is this using in/out rather than read/write? Does it not support
memory-mapped I/O?

> +   break;
> +#endif
> +   default:
> +   debug("%s: regmap size %zu unknown\n", __func__, val_len);
> +   return -EINVAL;
> +   }
> +   return 0;
> +}
> +
>  int regmap_read(struct regmap *map, uint offset, uint *valp)
>  {
> -   u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
> +   return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
> +}
>
> -   *valp = le32_to_cpu(readl(ptr));
> +int regmap_raw_write(struct regmap *map, uint offset, const void *val,
> +size_t val_len)
> +{
> +   void *ptr;
> +
> +   ptr = map_physmem(map->ranges[0].start + offset, val_len, 
> MAP_NOCACHE);
> +
> +   switch (val_len) {
> +   case REGMAP_SIZE_8:
> +   out_8((u8 *)ptr, *((u8 *)val));
> +   break;
> +   case REGMAP_SIZE_16:
> +   out_le16((u16 *)ptr, *((u16 *)val));
> +   break;
> +   case REGMAP_SIZE_32:
> +   out_le32((u32 *)ptr, *((u32 *)val));
> +   break;

No 64-bit?

> +   default:
> +   debug("%s: regmap size %zu unknown\n", __func__, val_len);
> +   return -EINVAL;
> +   }
>
> return 0;
>  }
>
>  int regmap_write(struct regmap *map, uint offset, uint val)
>  {
> -   u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
> -
> -   writel(cpu_to_le32(val), ptr);
> -
> -   return 0;
> +   return regmap_raw_write(map, offset, , REGMAP_SIZE_32);
>  }
>
>  int regmap_update_bits(struct regmap *map, uint offset, uint mask, uint val)
> diff --git a/include/regmap.h b/include/regmap.h
> index 32f75e06f59..8a9759281a5 100644
> --- a/include/regmap.h
> +++ b/include/regmap.h
> @@ -8,6 +8,21 @@
>  #define __REGMAP_H
>
>  /**
> + * enum regmap_size_t - Access sizes for fpgamap reads and writes
> + *
> + * @REGMAP_SIZE_8: 8-bit read/write access size
> + * @REGMAP_SIZE_16: 16-bit read/write access size
> + * @REGMAP_SIZE_32: 32-bit read/write access size
> + * @REGMAP_SIZE_64: 64-bit read/write access size
> + */
> +enum regmap_size_t {
> +   REGMAP_SIZE_8 = 1,
> +   REGMAP_SIZE_16 = 2,
> +   REGMAP_SIZE_32 = 4,
> +   REGMAP_SIZE_64 = 8,
> +};
> +
> +/**
>   * struct regmap_range - a register map range
>   *
>   * @start: Start address
> @@ -41,6 +56,10 @@ struct regmap {
>   * @offset:Offset in the regmap to write to
>   * @val:   Data to write to the regmap at the specified offset
>   *
> + * Note that this function will only write values of 32 bit width to the

Re: [U-Boot] [PATCH 04/10] Add UCLASS_TEE for Trusted Execution Environment

[Simon Glass]

Hi Jens,

On 13 August 2018 at 09:53, Jens Wiklander  wrote:
> Adds a uclass to interface with a TEE (Trusted Execution Environment).
>
> A TEE driver is a driver that interfaces with a trusted OS running in
> some secure environment, for example, TrustZone on ARM cpus, or a
> separate secure co-processor etc.
>
> The TEE subsystem can serve a TEE driver for a Global Platform compliant
> TEE, but it's not limited to only Global Platform TEEs.
>
> The over all design is based on the TEE subsystem in the Linux kernel,
> tailored for U-boot.
>
> Signed-off-by: Jens Wiklander 
> ---
>  MAINTAINERS  |   6 ++
>  drivers/Kconfig  |   2 +
>  drivers/Makefile |   1 +
>  drivers/tee/Kconfig  |   8 ++
>  drivers/tee/Makefile |   3 +
>  drivers/tee/tee-uclass.c | 180 +++
>  include/dm/uclass-id.h   |   1 +
>  include/tee.h| 134 +
>  8 files changed, 335 insertions(+)
>  create mode 100644 drivers/tee/Kconfig
>  create mode 100644 drivers/tee/Makefile
>  create mode 100644 drivers/tee/tee-uclass.c
>  create mode 100644 include/tee.h
>

Please add a sandbox driver and a test in test/dm for any new uclass.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 58b61ac05882..7458c606ee92 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -571,6 +571,12 @@ TQ GROUP
>  S: Orphaned (Since 2016-02)
>  T: git git://git.denx.de/u-boot-tq-group.git
>
> +TEE
> +M: Jens Wiklander 
> +S: Maintained
> +F: drivers/tee/
> +F: include/tee.h
> +
>  UBI
>  M: Kyungmin Park 
>  M: Heiko Schocher 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index c72abf893297..f3249ab1d143 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -94,6 +94,8 @@ source "drivers/spmi/Kconfig"
>
>  source "drivers/sysreset/Kconfig"
>
> +source "drivers/tee/Kconfig"
> +
>  source "drivers/thermal/Kconfig"
>
>  source "drivers/timer/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index d53208540ea6..0fcae36f50f7 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -103,6 +103,7 @@ obj-y += smem/
>  obj-y += soc/
>  obj-$(CONFIG_REMOTEPROC) += remoteproc/
>  obj-y += thermal/
> +obj-$(CONFIG_TEE) += tee/
>
>  obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
>  endif
> diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> new file mode 100644
> index ..817ab331b0f8
> --- /dev/null
> +++ b/drivers/tee/Kconfig
> @@ -0,0 +1,8 @@
> +# Generic Trusted Execution Environment Configuration
> +config TEE
> +   bool "Trusted Execution Environment support"
> +   depends on ARM && (ARM64 || CPU_V7A)
> +   select ARM_SMCCC
> +   help
> + This implements a generic interface towards a Trusted Execution
> + Environment (TEE).
> diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> new file mode 100644
> index ..b6d8e16e6211
> --- /dev/null
> +++ b/drivers/tee/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-y += tee-uclass.o
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> new file mode 100644
> index ..f0243a0f2e4e
> --- /dev/null
> +++ b/drivers/tee/tee-uclass.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +struct tee_uclass_priv {
> +   struct list_head list_shm;

Struct comment please

> +};
> +
> +static const struct tee_driver_ops *tee_get_ops(struct udevice *dev)
> +{
> +   return device_get_ops(dev);
> +}
> +
> +void tee_get_version(struct udevice *dev, struct tee_version_data *vers)
> +{
> +   tee_get_ops(dev)->get_version(dev, vers);
> +}
> +
> +int tee_open_session(struct udevice *dev, struct tee_open_session_arg *arg,
> +ulong num_param, struct tee_param *param)
> +{
> +   return tee_get_ops(dev)->open_session(dev, arg, num_param, param);
> +}
> +
> +int tee_close_session(struct udevice *dev, u32 session)
> +{
> +   return tee_get_ops(dev)->close_session(dev, session);
> +}
> +
> +int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
> +   ulong num_param, struct tee_param *param)
> +{
> +   return tee_get_ops(dev)->invoke_func(dev, arg, num_param, param);
> +}
> +
> +struct tee_shm *__tee_shm_add(struct udevice *dev, ulong align, void *addr,
> + ulong size, u32 flags)
> +{
> +   struct tee_shm *shm;
> +   void *p = addr;
> +
> +   if (flags & TEE_SHM_ALLOC) {
> +   if (align)
> +   p = memalign(align, size);
> +   else
> +   p = malloc(size);
> +   }
> +   if (!p)
> +   return NULL;
> +
> +   shm = calloc(1, sizeof(*shm));

Rather than allocating memory here, can you use driver-model's
auto-alloc features?

> +   if (!shm)
> +   goto err;
> +
> +  

Re: [U-Boot] [PATCH 2/2] fdt: fdtdec_setup_memory_banksize() use livetree

[Simon Glass]

On 10 August 2018 at 06:54, Jens Wiklander  wrote:
> Converts fdtdec_setup_memory_banksize() to use ofnode functions instead.
>
> Signed-off-by: Jens Wiklander 
> ---
>  lib/fdtdec.c | 46 +-
>  1 file changed, 21 insertions(+), 25 deletions(-)
>

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

Re: [U-Boot] [PATCH v4 6/7] device: expose the functions used to remove and unbind children of a device

[Simon Glass]

On 9 August 2018 at 08:17, Jean-Jacques Hiblot  wrote:
> Also add a 'drv' parameter to filter the children to remove/unbind.
> Exporting those functions is a preparatory work for the addition of the
> bind/unbind commands.
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  drivers/core/device-remove.c | 30 +++---
>  include/dm/device-internal.h | 38 ++
>  2 files changed, 49 insertions(+), 19 deletions(-)
>

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

Re: [U-Boot] [PATCH 3/4] env: nand: drop not needed #ifdef CMD_SAVEENV

[Simon Glass]

On 14 August 2018 at 03:21, Christian Gmeiner
 wrote:
> env_save_ptr(..) macro handles CMD_SAVEENV already.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  env/nand.c | 2 --
>  1 file changed, 2 deletions(-)

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

Re: [U-Boot] [PATCH v4 5/7] dm: convert device_get_global_by_of_offset() to device_get_global_by_ofnode()

[Simon Glass]

Hi Jean-Jacques,

On 9 August 2018 at 08:17, Jean-Jacques Hiblot  wrote:
> Also add device_find_global_by_ofnode() that also find a device based on
> the OF node, but doesn't probe the device.
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - new commit
>
> Changes in v2: None
>
>  arch/arm/mach-rockchip/rk3188-board-spl.c |  2 +-
>  arch/arm/mach-rockchip/rk3288-board-spl.c |  2 +-
>  drivers/core/device.c | 19 +--
>  include/dm/device.h   | 23 +++
>  4 files changed, 34 insertions(+), 12 deletions(-)

Can you please add a test for this? See dm/test/ofnode.c

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

Re: [U-Boot] [PATCH 4/4] env: sf: drop not needed #ifdef CMD_SAVEENV

[Simon Glass]

On 14 August 2018 at 03:21, Christian Gmeiner
 wrote:
> env_save_ptr(..) macro handles CMD_SAVEENV already.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  env/sf.c | 2 --
>  1 file changed, 2 deletions(-)

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/2] ofnode: add ofnode_by_prop_value()

[Simon Glass]

Hi Jens,

On 10 August 2018 at 06:54, Jens Wiklander  wrote:
> Adds ofnode_by_prop_value() to search for nodes with a given property
> and value, an ofnode version of fdt_node_offset_by_prop_value().
>
> Signed-off-by: Jens Wiklander 
> ---
>  drivers/core/of_access.c | 27 +++
>  drivers/core/ofnode.c| 14 ++
>  include/dm/of_access.h   | 16 
>  include/dm/ofnode.h  | 14 ++
>  4 files changed, 71 insertions(+)

This looks good, but please add some test code for this function.

E.g. at test/dm/ofnode.c

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

Re: [U-Boot] [PATCH 3/6] x86: dts: Remove coreboot_fb.dtsi

[Simon Glass]

On 10 August 2018 at 03:39, Bin Meng  wrote:
> There is no need to keep a separate coreboot_fb.dtsi since now we
> have a generic coreboot payload dts.
>
> While we are here, this also remove the out-of-date description in
> the documentation regarding to coreboot framebuffer driver with
> U-Boot loaded as a payload from coreboot. As the testing result with
> QEMU 2.5.0 shows, the driver just works like a charm.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts | 1 -
>  arch/x86/dts/chromebook_link.dts   | 1 -
>  arch/x86/dts/chromebook_samus.dts  | 1 -
>  arch/x86/dts/chromebox_panther.dts | 1 -
>  arch/x86/dts/coreboot_fb.dtsi  | 5 -
>  arch/x86/dts/minnowmax.dts | 1 -
>  doc/README.x86 | 7 ---
>  7 files changed, 17 deletions(-)
>  delete mode 100644 arch/x86/dts/coreboot_fb.dtsi

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

Re: [U-Boot] [PATCH] common: fdt: set the value of MEMORY_BANKS_MAX to 8

[Simon Glass]

Hi,

On 10 August 2018 at 10:44, Ramon Fried  wrote:
>
>
>
> On Fri, Aug 10, 2018 at 2:54 PM Anand Moon  wrote:
>>
>> set the value of MEMORY_BANKS_MAX to 8.
>> Odroid-XU4 fails to boot with following message
>>
>> fdt_fixup_memory_banks: num banks 8 exceeds hardcoded limit 4.
>> Recompile with higher MEMORY_BANKS_MAX?
>> ERROR: arch-specific fdt fixup failed
>>  - must RESET the board to recover.
>>
>> Fixes: commit 2a1f4f1758b5 (Revert "fdt_support: Use CONFIG_NR_DRAM_BANKS if 
>> defined")
>>
>> CC: Ramon Fried 
>> CC: Simon Glass 
>> Signed-off-by: Anand Moon 
>> ---
>>  common/fdt_support.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index 34d2bd59c4..ad87f31ab3 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -409,7 +409,7 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64 
>> *address, u64 *size,
>> return p - (char *)buf;
>>  }
>>
> I think it's better to check if MEMORY_BANKS was defined and only if not to 
> define it to 4.
> Then users can define MEMORY_BANKS at include/configs/h
> Simon, what do you say ?

My vote is for Kconfig to define this, perhaps with a defaul of 4. But
I see there is a lot of discussion and I have been out for a few
weeks, so I don't have a strong opinion.

>
>> -#define MEMORY_BANKS_MAX 4
>> +#define MEMORY_BANKS_MAX 8
>>  int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
>>  {
>> int err, nodeoffset;
>> --
>> 2.17.1
>>

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

Re: [U-Boot] [PATCH] configs: Migrate CONFIG_NR_DRAM_BANKS

[Tom Rini]

On Fri, Aug 17, 2018 at 08:17:45AM +0200, Michal Simek wrote:
> Hi Tom,
> 
> On 17.8.2018 03:12, Tom Rini wrote:
> > We have the following cases:
> > - CONFIG_NR_DRAM_BANKS was defined, migrate normally
> > - CONFIG_NR_DRAM_BANKS_MAX was defined and then used for
> >   CONFIG_NR_DRAM_BANKS after a check, just migrate it over now.
> > - CONFIG_NR_DRAM_BANKS was very oddly defined on p2771--* (to 1024 +
> >   2), set this to 8.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> 
> zynq-common.h contained
> 
> #ifndef CONFIG_NR_DRAM_BANKS
> # define CONFIG_NR_DRAM_BANKS  1
> #endif
> 
> that's why I expect you wanted to use default setup which is 4.
> We had this code there only for handling use case with additional bank
> connected to programmable logic which is unused now.
> Anyway will be the best to use 1 for all current zynq boards.
> 
> Also the similar thing happened with zynqmp boards where we had default
> setup 2 and it was changed to 4.
> 
> #ifndef CONFIG_NR_DRAM_BANKS
> # define CONFIG_NR_DRAM_BANKS  2
> #endif
> 
> Code was there to handle mini configurations which use 1 bank all the time.
> 
> I checked microblaze and zynqmp-mini and zynqmp-r5 and they are fine.

OK, sorry about that.  But, a question.  What happens / what to we lose
/ get wrong by having them be set to 4 (or say 8 on the ARMv8 parts) ?

-- 
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] configs: Migrate CONFIG_NR_DRAM_BANKS

[Tom Rini]

On Fri, Aug 17, 2018 at 07:03:04AM -0500, Adam Ford wrote:
> On Thu, Aug 16, 2018 at 8:14 PM Tom Rini  wrote:
> >
> > We have the following cases:
> > - CONFIG_NR_DRAM_BANKS was defined, migrate normally
> > - CONFIG_NR_DRAM_BANKS_MAX was defined and then used for
> >   CONFIG_NR_DRAM_BANKS after a check, just migrate it over now.
> > - CONFIG_NR_DRAM_BANKS was very oddly defined on p2771--* (to 1024 +
> >   2), set this to 8.
> >
> > Signed-off-by: Tom Rini 
> > ---
> 
> What are the chances of using defaults based on architectures?  The
> number of defconfig changes can go down, and those that need changes
> that differ from their standard architecture can still do it.

Well, one of the things I'm wondering about is how many places really
need / benefit from using something other than 4 or 8 and dropping the
usage of 1/2/3/6/7 and just defaulting to 8 if 64bit, else 4.

-- 
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] configs: Migrate CONFIG_NR_DRAM_BANKS

[Adam Ford]

On Thu, Aug 16, 2018 at 8:14 PM Tom Rini  wrote:
>
> We have the following cases:
> - CONFIG_NR_DRAM_BANKS was defined, migrate normally
> - CONFIG_NR_DRAM_BANKS_MAX was defined and then used for
>   CONFIG_NR_DRAM_BANKS after a check, just migrate it over now.
> - CONFIG_NR_DRAM_BANKS was very oddly defined on p2771--* (to 1024 +
>   2), set this to 8.
>
> Signed-off-by: Tom Rini 
> ---

What are the chances of using defaults based on architectures?  The
number of defconfig changes can go down, and those that need changes
that differ from their standard architecture can still do it.

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

Re: [U-Boot] sunxi: USB gadget does not work on H2+ after 92a30692b2b18f45aae6fdaae38d67ed03dd2d11

[Jagan Teki]

On Mon, Aug 13, 2018 at 3:59 PM, Nuno Gonçalves  wrote:
> After this commit usb gadget does not work anymore for me on the Orange Pi
> Zero (H2+).

Please send log or full information?

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

Re: [U-Boot] [PATCH 1/4] arm: omap4+: Move SCLK to include/configs

[Tom Rini]

On Fri, Aug 17, 2018 at 11:22:22AM +0530, Lokesh Vutla wrote:
> 
> 
> On Friday 17 August 2018 06:24 AM, Tom Rini wrote:
> > On Thu, Aug 16, 2018 at 06:26:52PM +0530, Lokesh Vutla wrote:
> > 
> >> Similar to every other SoCs define oscillator clock definitions
> >> for OMAP4+ SoCs to include/configs/. This will allow to not
> >> depend on SoC clock.h header file for getting default timer frequency.
> >>
> >> Signed-off-by: Lokesh Vutla 
> >> ---
> >>  arch/arm/include/asm/arch-omap4/clock.h | 4 
> >>  arch/arm/include/asm/arch-omap5/clock.h | 8 
> >>  include/configs/ti_omap4_common.h   | 4 
> >>  include/configs/ti_omap5_common.h   | 8 
> >>  4 files changed, 12 insertions(+), 12 deletions(-)
> > 
> > Nak.  Long term, include/configs/ files are going away.
> > 
> 
> okay. patch 3/4 and 4/4 are independent of this and are still valid. Any
> objections on them?

Nope, those are fine.  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] [PATCH u-boot-marvell v2 00/12] Updates for Turris Mox

[Stefan Roese]

Hi Marek,

On 17.08.2018 12:58, Marek Behún wrote:

This is second version of updates for Turris Mox.
The first version was sent three months ago, on 16th May. Sorry :).
It would be great if this got to 2018.09 release, but I will
understand if it does not.


I'm afraid, but this will have to wait for the next merge window.
We're at RC2 and I'll be leaving for one week vacation tomorrow.
I'll try to review the patches later then.

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

[U-Boot] [PATCH] cmd: mii: don't check address for 'device' subcommand

[Hector Palacios]

All mii operations require a valid PHY address except the 'device'
command, which expects the PHY name rather than the address.

Signed-off-by: Hector Palacios 
---
 cmd/mii.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/mii.c b/cmd/mii.c
index ce7b393eeaae..c0c42a851f90 100644
--- a/cmd/mii.c
+++ b/cmd/mii.c
@@ -313,7 +313,7 @@ static int do_mii(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
mask = simple_strtoul(argv[5], NULL, 16);
}
 
-   if (addrhi > 31) {
+   if (addrhi > 31 && strncmp(op, "de", 2)) {
printf("Incorrect PHY address. Range should be 0-31\n");
return CMD_RET_USAGE;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] hwmon in current uboot

[Joe Rutledge]

Thanks very much for the response!

So I guess I need to write something new under the new UCLASS_THERMAL 
model for my part. Any gotchas in there I should know about?


Joe


On 17/08/18 07:50, Andy Pont wrote:

Joe wrote...


Apologies in advance if this is answered somewhere else, but I had no
luck finding information about it.

I'm moving from an older version of u-boot (2016) to a current one.
Some of the patches I had against the old uboot included work in the
hwmon subdirectory. These patches now obviously fail as this whole set
of functionality appears to have been removed.

Am I missing something, or does u-boot no longer support any of these
devices? Alternatively, is there a way I should reintroduce it for my
board.

Looking at the git log for some of the files that were in the
drivers/hwmon directory (git log — path/to/filename) then they were
removed in May 2017 in favour of the driver model and UCLASS_THERMAL
which is located in drivers/thermal.

Unfortunately, it doesn’t look as though those I2C based devices got
converted.

-Andy.





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

[U-Boot] Chain loading U-Boot on ARM v7, data abort

[Neil Stainton]

Hello list,

I am attempting to get U-Boot chain loading another instance of U-Boot and need 
a little help: I'm currently using the Freescale iMX6ULL EVK, but am developing 
for a custom platform which is intended to have a primary boot loader in ROM 
and a field-updatable secondary boot loader, with a redundant backup, both 
stored in flash. I am currently testing with QSPI.

I figured on storing the secondary boot loader in ELF format (stripped) at 
known offset in QSPI and have been attempting to get the bootelf command load 
and execute it, either directly from the mapped QSPI address space, or by 'sf 
reading' the ELF file into ${loadaddr} and bootelf it from there. I have 
ensured .text and $loadaddr don't overlap.

The problem I am seeing happens after the secondary image starts, during its 
relocation to the top of external RAM. The processor gets a data abort 
interrupt and U-Boot subsequently hard resets.

I switched on the debug messages just for common/board_f.c on an otherwise 
mostly mx6ull_14x14_evk_defconfig from the v2018.07 tag and this is what I see 
immediately prior to the reset:

  Monitor len: 0005ACCC
  Ram size: 2000
  Ram top: A000
  TLB table from 9fff to 9fff4000
  Reserving 363k for U-Boot at: 9ff95000
  Reserving 16392k for malloc() at: 9ef93000
  Reserving 80 Bytes for Board Info at: 9ef92fb0
  Reserving 240 Bytes for Global Data at: 9ef92ec0
  
  RAM Configuration:
  Bank #0: 8000 
  DRAM:  512 MiB
  New Stack Pointer is: 9ef92ea0
  Relocation Offset is: 18795000
  Relocating to 9ff95000, new gd at 9ef92ec0, sp at 9ef92ea0
  data abort
  pc : [<87800c5c>]  lr : [<9ff9570c>]
  sp : 9ef92ea0  ip : 0030 fp : 0017
  r10: 878538dc  r9 : 9ef92ec0 r8 : 9ffe8e98
  r7 : 9ef95460  r6 : 8780 r5 : 87800320  r4 : 18795000
  r3 : 8785c648  r2 : 8785acd0 r1 : 0017  r0 : 18795000
  Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
  Code: e20110ff e3510017 1a03 e084 (e5901000) 
  Resetting CPU ...
  
  resetting ...
  
  
  U-Boot 2018.07-8-ga14c5cc-dirty (Aug 16 2018 - 14:03:26 +0100)

The PC points to somewhere in arch/arm/lib/relocate.S. Here's the excerpt of 
the disassembly:

  87800c48 :
  fixloop:
  ldmia   r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
  87800c48:   e8b20003ldm r2!, {r0, r1}
  and r1, r1, #0xff
  87800c4c:   e20110ffand r1, r1, #255; 0xff
  cmp r1, #R_ARM_RELATIVE
  87800c50:   e3510017cmp r1, #23
  bne fixnext
  87800c54:   1a03bne 87800c68 
  
  /* relative fix: increase location by offset */
  add r0, r0, r4
  87800c58:   e084add r0, r0, r4
  ldr r1, [r0]
  87800c5c:   e5901000ldr r1, [r0]
  add r1, r1, r4
  87800c60:   e0811004add r1, r1, r4
  str r1, [r0]
  87800c64:   e5801000str r1, [r0]
  
  87800c68 :
  fixnext:
  cmp r2, r3
  87800c68:   e1520003cmp r2, r3
  blo fixloop
  87800c6c:   3af5bcc 87800c48 
  
  87800c70 :
  
What could be going wrong here? Could it be something to do with the MMU or 
cache being left in a non-reset state by bootelf? I did try adding a call to 
cleanup_before_linux in do_bootelf_exec, but it made no obvious difference.

Thanks for any insights,

Neil

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

[U-Boot] [PATCH u-boot-marvell v2 04/12] board: turris_mox: Fixup U-Boot's device tree if PCIe connected

[Marek Behún]

If PCIe Mox module is connected we want to have PCIe node enabled
in U-Boot's device tree.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-3720-turris-mox.dts |  7 +++
 board/CZ.NIC/turris_mox/turris_mox.c| 80 +
 configs/turris_mox_defconfig|  1 +
 3 files changed, 88 insertions(+)

diff --git a/arch/arm/dts/armada-3720-turris-mox.dts 
b/arch/arm/dts/armada-3720-turris-mox.dts
index bef100afce..a817f20920 100644
--- a/arch/arm/dts/armada-3720-turris-mox.dts
+++ b/arch/arm/dts/armada-3720-turris-mox.dts
@@ -130,3 +130,10 @@
vbus-supply = <_usb3_vbus>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   reset-gpio = < 3 GPIO_ACTIVE_HIGH>;
+   status = "disabled";
+};
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index b6a0ca4626..42f55b7915 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -4,17 +4,97 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_WDT_ARMADA_37XX
 #include 
 #endif
 
+#define MAX_MOX_MODULES10
+
+#define MOX_MODULE_SFP 0x1
+#define MOX_MODULE_PCI 0x2
+#define MOX_MODULE_TOPAZ   0x3
+#define MOX_MODULE_PERIDOT 0x4
+#define MOX_MODULE_USB30x5
+#define MOX_MODULE_PASSPCI 0x6
+
+#define ARMADA_37XX_NB_GPIO_SEL0xd0013830
+#define ARMADA_37XX_SPI_CTRL   0xd0010600
+#define ARMADA_37XX_SPI_CFG0xd0010604
+#define ARMADA_37XX_SPI_DOUT   0xd0010608
+#define ARMADA_37XX_SPI_DIN0xd001060c
+
+#define PCIE_PATH  "/soc/pcie@d007"
+
 DECLARE_GLOBAL_DATA_PTR;
 
+#if defined(CONFIG_OF_BOARD_FIXUP)
+int board_fix_fdt(void *blob)
+{
+   u8 topology[MAX_MOX_MODULES];
+   int i, size, node;
+   bool enable;
+
+   /*
+* SPI driver is not loaded in driver model yet, but we have to find out
+* if pcie should be enabled in U-Boot's device tree. Therefore we have
+* to read SPI by reading/writing SPI registers directly
+*/
+
+   writel(0x563fa, ARMADA_37XX_NB_GPIO_SEL);
+   writel(0x10df, ARMADA_37XX_SPI_CFG);
+   writel(0x2005b, ARMADA_37XX_SPI_CTRL);
+
+   while (!(readl(ARMADA_37XX_SPI_CTRL) & 0x2))
+   udelay(1);
+
+   for (i = 0; i < MAX_MOX_MODULES; ++i) {
+   writel(0x0, ARMADA_37XX_SPI_DOUT);
+
+   while (!(readl(ARMADA_37XX_SPI_CTRL) & 0x2))
+   udelay(1);
+
+   topology[i] = readl(ARMADA_37XX_SPI_DIN) & 0xff;
+   if (topology[i] == 0xff)
+   break;
+   }
+
+   size = i;
+
+   writel(0x5b, ARMADA_37XX_SPI_CTRL);
+
+   if (size > 1 && (topology[1] == MOX_MODULE_PCI ||
+topology[1] == MOX_MODULE_USB3 ||
+topology[1] == MOX_MODULE_PASSPCI))
+   enable = true;
+   else
+   enable = false;
+
+   node = fdt_path_offset(blob, PCIE_PATH);
+
+   if (node < 0) {
+   printf("Cannot find PCIe node in U-Boot's device tree!\n");
+   return 0;
+   }
+
+   if (fdt_setprop_string(blob, node, "status",
+  enable ? "okay" : "disabled") < 0) {
+   printf("Cannot %s PCIe in U-Boot's device tree!\n",
+  enable ? "enable" : "disable");
+   return 0;
+   }
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_WDT_ARMADA_37XX
 static struct udevice *watchdog_dev;
 
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index de9aedc764..47ab914ce9 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_ARCH_EARLY_INIT_R=y
+CONFIG_OF_BOARD_FIXUP=y
 CONFIG_CMD_CLK=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 07/12] board: turris_mox: Change SERDES map depending on module topology

[Marek Behún]

When SFP module is connected directly to CPU module we want the SGMII
lane speed at 1.25 Gbps.

Signed-off-by: Marek Behun 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 4a3e78c5d6..224179434b 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -218,6 +219,38 @@ static int mox_get_topology(const u8 **ptopology, int 
*psize,
return 0;
 }
 
+int comphy_update_map(struct comphy_map *serdes_map, int count)
+{
+   int ret, i, size, sfpindex = -1, swindex = -1;
+   const u8 *topology;
+
+   ret = mox_get_topology(, , NULL);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < size; ++i) {
+   if (topology[i] == MOX_MODULE_SFP && sfpindex == -1)
+   sfpindex = i;
+   else if ((topology[i] == MOX_MODULE_TOPAZ ||
+ topology[i] == MOX_MODULE_PERIDOT) &&
+swindex == -1)
+   swindex = i;
+   }
+
+   if (sfpindex >= 0 && swindex >= 0) {
+   if (sfpindex < swindex)
+   serdes_map[0].speed = PHY_SPEED_1_25G;
+   else
+   serdes_map[0].speed = PHY_SPEED_3_125G;
+   } else if (sfpindex >= 0) {
+   serdes_map[0].speed = PHY_SPEED_1_25G;
+   } else if (swindex >= 0) {
+   serdes_map[0].speed = PHY_SPEED_3_125G;
+   }
+
+   return 0;
+}
+
 int last_stage_init(void)
 {
int ret, i;
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 09/12] board: turris_mox: Setup Linux's device tree before boot

[Marek Behún]

Patch Linux's device tree according to which Mox modules are connected.
Linux's device tree is supposed to have some nodes already
preprogrammed. If user wants to use different device tree, they should
disable CONFIG_OF_BOARD_SETUP in U-Boot's config, so that the boot
command does not fail.

Signed-off-by: Marek Behun 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 222 +++
 configs/turris_mox_defconfig |   1 +
 2 files changed, 223 insertions(+)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 21a3e63864..3361579d7c 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -3,6 +3,7 @@
  * Copyright (C) 2018 Marek Behun 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,11 @@
 #define ARMADA_37XX_SPI_DOUT   0xd0010608
 #define ARMADA_37XX_SPI_DIN0xd001060c
 
+#define ETH1_PATH  "/soc/internal-regs@d000/ethernet@4"
+#define MDIO_PATH  "/soc/internal-regs@d000/mdio@32004"
+#define MOXTET_SFP_PATH
"/soc/internal-regs@d000/spi@10600/moxtet@1/moxtet-sfp@0"
 #define PCIE_PATH  "/soc/pcie@d007"
+#define SFP_PATH   "/sfp"
 
 typedef enum {
MOX_UNKNOWN,
@@ -530,3 +535,220 @@ int last_stage_init(void)
 
return 0;
 }
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+
+static int vnode_by_path(void *blob, const char *fmt, va_list ap)
+{
+   char path[128];
+
+   vsprintf(path, fmt, ap);
+   return fdt_path_offset(blob, path);
+}
+
+static int node_by_path(void *blob, const char *fmt, ...)
+{
+   va_list ap;
+   int res;
+
+   va_start(ap, fmt);
+   res = vnode_by_path(blob, fmt, ap);
+   va_end(ap);
+
+   return res;
+}
+
+static int phandle_by_path(void *blob, const char *fmt, ...)
+{
+   va_list ap;
+   int node, phandle, res;
+
+   va_start(ap, fmt);
+   node = vnode_by_path(blob, fmt, ap);
+   va_end(ap);
+
+   if (node < 0)
+   return node;
+
+   phandle = fdt_get_phandle(blob, node);
+   if (phandle > 0)
+   return phandle;
+
+   phandle = fdt_get_max_phandle(blob);
+   if (phandle < 0)
+   return phandle;
+
+   phandle += 1;
+
+   res = fdt_setprop_u32(blob, node, "linux,phandle", phandle);
+   if (res < 0)
+   return res;
+
+   res = fdt_setprop_u32(blob, node, "phandle", phandle);
+   if (res < 0)
+   return res;
+
+   return phandle;
+}
+
+static int enable_by_path(void *blob, const char *fmt, ...)
+{
+   va_list ap;
+   int node;
+
+   va_start(ap, fmt);
+   node = vnode_by_path(blob, fmt, ap);
+   va_end(ap);
+
+   if (node < 0)
+   return node;
+
+   return fdt_setprop_string(blob, node, "status", "okay");
+}
+
+static bool is_topaz(int id)
+{
+   return topaz && id == peridot + topaz - 1;
+}
+
+static int switch_addr(int id)
+{
+   return is_topaz(id) ? 0x2 : 0x10 + id;
+}
+
+static int setup_switch(void *blob, int id)
+{
+   int res, addr, i, node, phandle;
+
+   addr = switch_addr(id);
+
+   /* first enable the switch by setting status = "okay" */
+   res = enable_by_path(blob, MDIO_PATH "/switch%i@%x", id, addr);
+   if (res < 0)
+   return res;
+
+   /*
+* now if there are more switches or a SFP module coming after,
+* enable corresponding ports
+*/
+   if (id < peridot + topaz - 1)
+   res = enable_by_path(blob,
+MDIO_PATH "/switch%i@%x/ports/port@a",
+id, addr);
+   else if (id == peridot - 1 && !topaz && sfp)
+   res = enable_by_path(blob,
+MDIO_PATH "/switch%i@%x/ports/port-sfp@a",
+id, addr);
+   else
+   res = 0;
+   if (res < 0)
+   return res;
+
+   if (id >= peridot + topaz - 1)
+   return 0;
+
+   /* finally change link property if needed */
+   node = node_by_path(blob, MDIO_PATH "/switch%i@%x/ports/port@a", id,
+   addr);
+   if (node < 0)
+   return node;
+
+   for (i = id + 1; i < peridot + topaz; ++i) {
+   phandle = phandle_by_path(blob,
+ MDIO_PATH 
"/switch%i@%x/ports/port@%x",
+ i, switch_addr(i),
+ is_topaz(i) ? 5 : 9);
+   if (phandle < 0)
+   return phandle;
+
+   if (i == id + 1)
+   res = fdt_setprop_u32(blob, node, "link", phandle);
+   else
+   res = fdt_appendprop_u32(blob, node, "link", phandle);
+   if (res < 0)
+   return res;
+   }
+
+   return 0;
+}
+
+int ft_board_setup(void *blob, 

[U-Boot] [PATCH u-boot-marvell v2 11/12] arch/arm/dts: Update Turris Mox device tree

[Marek Behún]

Remove smi_pins definition since it is already in armada-37xx.dtsi.
Add assigned-clocks definitions to spi0.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-3720-turris-mox.dts | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/armada-3720-turris-mox.dts 
b/arch/arm/dts/armada-3720-turris-mox.dts
index 05904387d2..9c96dd39a9 100644
--- a/arch/arm/dts/armada-3720-turris-mox.dts
+++ b/arch/arm/dts/armada-3720-turris-mox.dts
@@ -94,17 +94,13 @@
};
 };
 
-_sb {
-   smi_pins: smi-pins {
-   groups = "smi";
-   function = "smi";
-   };
-};
-
  {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_cs1_pins>;
+   assigned-clocks = <_periph_clk 7>;
+   assigned-clock-parents = < 1>;
+   assigned-clock-rates = <2000>;
 
spi-flash@0 {
#address-cells = <1>;
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 06/12] board: turris_mox: Cosmetic restructurization

[Marek Behún]

Restructure the board initialization source.
Remove the module_topology environment variable since it won't be
needed.

Signed-off-by: Marek Behun 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 153 ---
 1 file changed, 106 insertions(+), 47 deletions(-)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 42f55b7915..4a3e78c5d6 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -33,6 +33,12 @@
 
 #define PCIE_PATH  "/soc/pcie@d007"
 
+typedef enum {
+   MOX_UNKNOWN,
+   MOX_EMMC,
+   MOX_SD
+} mox_version_t;
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #if defined(CONFIG_OF_BOARD_FIXUP)
@@ -133,17 +139,15 @@ int board_init(void)
return 0;
 }
 
-int last_stage_init(void)
+static int mox_do_spi(u8 *in, u8 *out, size_t size)
 {
struct spi_slave *slave;
struct udevice *dev;
-   u8 din[10], dout[10];
-   int ret, i;
-   size_t len = 0;
-   char module_topology[128];
+   int ret;
 
-   ret = spi_get_bus_and_cs(0, 1, 2000, SPI_CPHA, "spi_generic_drv",
-"mox-modules@1", , );
+   ret = spi_get_bus_and_cs(0, 1, 100, SPI_CPHA | SPI_CPOL,
+"spi_generic_drv", "moxtet@1", ,
+);
if (ret)
goto fail;
 
@@ -151,57 +155,112 @@ int last_stage_init(void)
if (ret)
goto fail_free;
 
-   memset(din, 0, 10);
-   memset(dout, 0, 10);
+   ret = spi_xfer(slave, size * 8, out, in, SPI_XFER_ONCE);
+
+   spi_release_bus(slave);
+fail_free:
+   spi_free_slave(slave);
+fail:
+   return ret;
+}
 
-   ret = spi_xfer(slave, 80, dout, din, SPI_XFER_ONCE);
+static int mox_get_topology(const u8 **ptopology, int *psize,
+   mox_version_t *pversion)
+{
+   static mox_version_t mox_version;
+   static u8 topology[MAX_MOX_MODULES - 1];
+   static int size;
+   u8 din[MAX_MOX_MODULES], dout[MAX_MOX_MODULES];
+   int ret, i;
+
+   if (size) {
+   if (ptopology)
+   *ptopology = topology;
+   if (psize)
+   *psize = size;
+   if (pversion)
+   *pversion = mox_version;
+   return 0;
+   }
+
+   memset(din, 0, MAX_MOX_MODULES);
+   memset(dout, 0, MAX_MOX_MODULES);
+
+   ret = mox_do_spi(din, dout, MAX_MOX_MODULES);
if (ret)
-   goto fail_release;
+   return ret;
+
+   switch (din[0]) {
+   case 0x00:
+   mox_version = MOX_EMMC;
+   break;
+   case 0x10:
+   mox_version = MOX_SD;
+   break;
+   case 0xff:
+   mox_version = MOX_UNKNOWN;
+   break;
+   default:
+   return -ENODEV;
+   }
+
+   for (i = 1; i < MAX_MOX_MODULES && din[i] != 0xff; ++i)
+   topology[i - 1] = din[i] & 0xf;
+   size = i - 1;
+
+   if (ptopology)
+   *ptopology = topology;
+   if (psize)
+   *psize = size;
+   if (pversion)
+   *pversion = mox_version;
+
+   return 0;
+}
 
-   if (din[0] != 0x00 && din[0] != 0xff)
-   goto fail_release;
+int last_stage_init(void)
+{
+   int ret, i;
+   const u8 *topology;
+   int module_count;
+   mox_version_t version;
+
+   ret = mox_get_topology(, _count, );
+   if (ret) {
+   printf("Cannot read module topology!\n");
+   return 0;
+   }
 
+   printf("Found Turris Mox %s version\n", version == MOX_SD ? "SD" :
+   version == MOX_EMMC ? "eMMC" :
+   "unknown");
printf("Module Topology:\n");
-   for (i = 1; i < 10 && din[i] != 0xff; ++i) {
-   u8 mid = din[i] & 0xf;
-   size_t mlen;
-   const char *mname = "";
-
-   switch (mid) {
-   case 0x1:
-   mname = "sfp-";
-   printf("% 4i: SFP Module\n", i);
+   for (i = 0; i < module_count; ++i) {
+   switch (topology[i]) {
+   case MOX_MODULE_SFP:
+   printf("% 4i: SFP Module\n", i + 1);
+   break;
+   case MOX_MODULE_PCI:
+   printf("% 4i: Mini-PCIe Module\n", i + 1);
+   break;
+   case MOX_MODULE_TOPAZ:
+   printf("% 4i: Topaz Switch Module (4-port)\n", i + 1);
break;
-   case 0x2:
-   mname = "pci-";
-   printf("% 4i: Mini-PCIe Module\n", i);
+   case MOX_MODULE_PERIDOT:
+   printf("% 4i: Peridot Switch Module (8-port)\n", i + 1);

[U-Boot] [PATCH u-boot-marvell v2 10/12] board: turris_mox: Add gpio command to defconfig

[Marek Behún]

This can be used to detect whether the button is pressed or light LEDs.

Signed-off-by: Marek Behun 
---
 configs/turris_mox_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index fb4192df56..cc28a1fe95 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -16,6 +16,7 @@ CONFIG_ARCH_EARLY_INIT_R=y
 CONFIG_OF_BOARD_FIXUP=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_CMD_CLK=y
+CONFIG_CMD_GPIO=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 05/12] board: turris_mox: Enable PCI in defconfig

[Marek Behún]

Enable the pci-aardvark driver in defconfig for Turris Mox and also
enable the pci command.

Signed-off-by: Marek Behun 
---
 configs/turris_mox_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index 47ab914ce9..1dd6826dbc 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -18,6 +18,7 @@ CONFIG_CMD_CLK=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -51,6 +52,10 @@ CONFIG_MVEBU_COMPHY_SUPPORT=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_ARMADA_37XX=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_PCI_AARDVARK=y
+# CONFIG_PCI_PNP is not set
 # CONFIG_SPL_SERIAL_PRESENT is not set
 CONFIG_DEBUG_MVEBU_A3700_UART=y
 CONFIG_DEBUG_UART_SHIFT=2
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 08/12] board: turris_mox: Check and configure modules

[Marek Behún]

Check if Mox modules are connected in supported mode, then configure
the MDIO addresses of switch modules.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-3720-turris-mox.dts |  11 ++
 board/CZ.NIC/turris_mox/turris_mox.c| 235 +++-
 2 files changed, 245 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-3720-turris-mox.dts 
b/arch/arm/dts/armada-3720-turris-mox.dts
index a817f20920..05904387d2 100644
--- a/arch/arm/dts/armada-3720-turris-mox.dts
+++ b/arch/arm/dts/armada-3720-turris-mox.dts
@@ -114,6 +114,17 @@
spi-max-frequency = <2000>;
m25p,fast-read;
};
+
+   moxtet@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "cznic,moxtet";
+   reg = <1>;
+   devrst-gpio = < 2 GPIO_ACTIVE_LOW>;
+   spi-max-frequency = <100>;
+   spi-cpol;
+   spi-cpha;
+   };
 };
 
  {
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 224179434b..21a3e63864 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -4,11 +4,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -251,12 +253,131 @@ int comphy_update_map(struct comphy_map *serdes_map, int 
count)
return 0;
 }
 
+#define SW_SMI_CMD_R(d, r) (0x9800 | (((d) & 0x1f) << 5) | ((r) & 0x1f))
+#define SW_SMI_CMD_W(d, r) (0x9400 | (((d) & 0x1f) << 5) | ((r) & 0x1f))
+
+static int sw_multi_read(struct mii_dev *bus, int sw, int dev, int reg)
+{
+   bus->write(bus, sw, 0, 0, SW_SMI_CMD_R(dev, reg));
+   mdelay(5);
+   return bus->read(bus, sw, 0, 1);
+}
+
+static void sw_multi_write(struct mii_dev *bus, int sw, int dev, int reg,
+  u16 val)
+{
+   bus->write(bus, sw, 0, 1, val);
+   bus->write(bus, sw, 0, 0, SW_SMI_CMD_W(dev, reg));
+   mdelay(5);
+}
+
+static int sw_scratch_read(struct mii_dev *bus, int sw, int reg)
+{
+   sw_multi_write(bus, sw, 0x1c, 0x1a, (reg & 0x7f) << 8);
+   return sw_multi_read(bus, sw, 0x1c, 0x1a) & 0xff;
+}
+
+static void sw_led_write(struct mii_dev *bus, int sw, int port, int reg,
+u16 val)
+{
+   sw_multi_write(bus, sw, port, 0x16, 0x8000 | ((reg & 7) << 12)
+   | (val & 0x7ff));
+}
+
+static void sw_blink_leds(struct mii_dev *bus, int peridot, int topaz)
+{
+   int i, p;
+   struct {
+   int port;
+   u16 val;
+   int wait;
+   } regs[] = {
+   { 2, 0xef, 1 }, { 2, 0xfe, 1 }, { 2, 0x33, 0 },
+   { 4, 0xef, 1 }, { 4, 0xfe, 1 }, { 4, 0x33, 0 },
+   { 3, 0xfe, 1 }, { 3, 0xef, 1 }, { 3, 0x33, 0 },
+   { 1, 0xfe, 1 }, { 1, 0xef, 1 }, { 1, 0x33, 0 }
+   };
+
+   for (i = 0; i < 12; ++i) {
+   for (p = 0; p < peridot; ++p) {
+   sw_led_write(bus, 0x10 + p, regs[i].port, 0,
+regs[i].val);
+   sw_led_write(bus, 0x10 + p, regs[i].port + 4, 0,
+regs[i].val);
+   }
+   if (topaz) {
+   sw_led_write(bus, 0x2, 0x10 + regs[i].port, 0,
+regs[i].val);
+   }
+
+   if (regs[i].wait)
+   mdelay(75);
+   }
+}
+
+static void check_switch_address(struct mii_dev *bus, int addr)
+{
+   if (sw_scratch_read(bus, addr, 0x70) >> 3 != addr)
+   printf("Check of switch MDIO address failed for 0x%02x\n",
+  addr);
+}
+
+static int sfp, pci, topaz, peridot, usb, passpci;
+static int sfp_pos, peridot_pos[3];
+static int module_count;
+
+static int configure_peridots(void)
+{
+   int node, i, ret;
+   struct gpio_desc gpio = {};
+   u8 dout[MAX_MOX_MODULES];
+
+   node = fdt_node_offset_by_compatible(gd->fdt_blob, 0, "cznic,moxtet");
+   if (node < 0) {
+   printf("Cannot find Moxtet bus device node!\n");
+   return -1;
+   }
+
+   gpio_request_by_name_nodev(offset_to_ofnode(node), "devrst-gpio", 0,
+  , GPIOD_IS_OUT);
+
+   if (!dm_gpio_is_valid()) {
+   printf("Cannot find reset GPIO for Moxtet bus!\n");
+   return -1;
+   }
+
+   memset(dout, 0, MAX_MOX_MODULES);
+
+   /* set addresses of Peridot modules */
+   for (i = 0; i < peridot; ++i)
+   dout[module_count - peridot_pos[i]] = (~i) & 3;
+
+   /*
+* if there is a SFP module connected to the last Peridot module, set
+* the P10_SMODE to 1 for the Peridot module
+*/
+   if (sfp)
+   dout[module_count - peridot_pos[i - 1]] |= 1 << 3;
+
+   

[U-Boot] [PATCH u-boot-marvell v2 12/12] arch/arm/mvebu: Support 1 GB version of Turris Mox

[Marek Behún]

Add configuration variables to differentiate between the 512 MB and 1 GB
versions of Turris Mox and change the RAM size in U-Boot's device tree
accordingly.

Signed-off-by: Marek Behun 
---
 MAINTAINERS |  7 +++
 arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi | 16 
 arch/arm/mach-mvebu/Kconfig | 15 +++
 configs/turris_mox_defconfig|  1 +
 4 files changed, 39 insertions(+)
 create mode 100644 arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 1893090b8f..1a55d80c13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -360,6 +360,13 @@ S: Maintained
 T: git git://git.denx.de/u-boot-coldfire.git
 F: arch/m68k/
 
+CZ.NIC TURRIS
+M: Marek Behun 
+S: Maintained
+F: arch/arm/dts/armada-3720-turris-mox.dts
+F: arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
+F: board/CZ.NIC/
+
 DFU
 M: Lukasz Majewski 
 S: Maintained
diff --git a/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi 
b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
new file mode 100644
index 00..122f5c8ae1
--- /dev/null
+++ b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+ or X11
+/*
+ * 2018 by Marek Behun 
+ */
+
+#include 
+
+/ {
+   memory {
+#ifdef CONFIG_TARGET_TURRIS_MOX_1GB
+   reg = <0x 0x 0x 0x4000>;
+#else
+   reg = <0x 0x 0x 0x2000>;
+#endif
+   };
+};
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d1f71338ac..3e88b3757b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -198,6 +198,21 @@ config MVEBU_SPL_BOOT_DEVICE_UART
 
 endchoice
 
+if TARGET_TURRIS_MOX
+
+choice
+   prompt "Turris Mox RAM size"
+
+config TARGET_TURRIS_MOX_512MB
+   bool "512 MB"
+
+config TARGET_TURRIS_MOX_1GB
+   bool "1 GB"
+
+endchoice
+
+endif
+
 config MVEBU_EFUSE
bool "Enable eFuse support"
default n
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index cc28a1fe95..2bcbdd8133 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_SYS_TEXT_BASE=0x
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_TURRIS_MOX=y
+CONFIG_TARGET_TURRIS_MOX_512MB=y
 CONFIG_DEBUG_UART_BASE=0xd0012000
 CONFIG_DEBUG_UART_CLOCK=25804800
 CONFIG_DEFAULT_DEVICE_TREE="armada-3720-turris-mox"
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 03/12] board: turris_mox: Fix watchdog macro name

[Marek Behún]

The macro name CONFIG_WDT_ARMADA_3720 is called CONFIG_WDT_ARMADA_37XX
instead. Fix this so that watchdog really is enabled in board_init.

Signed-off-by: Marek Behun 
---
 board/CZ.NIC/turris_mox/turris_mox.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 130d4c606d..b6a0ca4626 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -9,13 +9,13 @@
 #include 
 #include 
 
-#ifdef CONFIG_WDT_ARMADA_3720
+#ifdef CONFIG_WDT_ARMADA_37XX
 #include 
 #endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdef CONFIG_WDT_ARMADA_3720
+#ifdef CONFIG_WDT_ARMADA_37XX
 static struct udevice *watchdog_dev;
 
 void watchdog_reset(void)
@@ -41,7 +41,7 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
-#ifdef CONFIG_WDT_ARMADA_3720
+#ifdef CONFIG_WDT_ARMADA_37XX
if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
printf("Cannot find Armada 3720 watchdog!\n");
} else {
-- 
2.16.4

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

[U-Boot] [PATCH u-boot-marvell v2 02/12] clk: armada-37xx-periph: Support changing clock parent and rate

[Marek Behún]

Add support for changing clock rate and parent clock for Armada 37xx
peripheral clocks.

Only clocks which can be disabled (.can_gate is true) can have parent
or rate changed.

This is needed so that Turris Mox can change SPI clock in device tree.

Signed-off-by: Marek Behun 
---
 drivers/clk/mvebu/armada-37xx-periph.c | 130 -
 1 file changed, 129 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
b/drivers/clk/mvebu/armada-37xx-periph.c
index 902a6cc9ef..b1a35968e1 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -224,11 +224,21 @@ static const struct clk_periph clks_sb[] = {
{ },
 };
 
-static inline int get_mux(struct a37xx_periphclk *priv, int shift)
+static int get_mux(struct a37xx_periphclk *priv, int shift)
 {
return (readl(priv->reg + TBG_SEL) >> shift) & 3;
 }
 
+static void set_mux(struct a37xx_periphclk *priv, int shift, int val)
+{
+   u32 reg;
+
+   reg = readl(priv->reg + TBG_SEL);
+   reg &= ~(3 << shift);
+   reg |= (val & 3) << shift;
+   writel(reg, priv->reg + TBG_SEL);
+}
+
 static ulong periph_clk_get_rate(struct a37xx_periphclk *priv, int id);
 
 static ulong get_parent_rate(struct a37xx_periphclk *priv, int id)
@@ -277,6 +287,17 @@ static ulong get_div(struct a37xx_periphclk *priv,
return 0;
 }
 
+static void set_div_val(struct a37xx_periphclk *priv,
+   const struct clk_periph *clk, int idx, int val)
+{
+   u32 reg;
+
+   reg = readl(priv->reg + clk->div_reg_off[idx]);
+   reg &= ~(clk->div_mask[idx] << clk->div_shift[idx]);
+   reg |= (val & clk->div_mask[idx]) << clk->div_shift[idx];
+   writel(reg, priv->reg + clk->div_reg_off[idx]);
+}
+
 static ulong periph_clk_get_rate(struct a37xx_periphclk *priv, int id)
 {
const struct clk_periph *clk = >clks[id];
@@ -337,6 +358,111 @@ static int armada_37xx_periph_clk_disable(struct clk *clk)
return periph_clk_enable(clk, 0);
 }
 
+#define diff(a, b) abs((long)(a) - (long)(b))
+
+static ulong find_best_div(const struct clk_div_table *t0,
+  const struct clk_div_table *t1, ulong parent_rate,
+  ulong req_rate, int *v0, int *v1)
+{
+   const struct clk_div_table *i, *j;
+   ulong rate, best_rate = 0;
+
+   for (i = t0; i && i->div; ++i) {
+   for (j = t1; j && j->div; ++j) {
+   rate = DIV_ROUND_UP(parent_rate, i->div * j->div);
+
+   if (!best_rate ||
+   diff(rate, req_rate) < diff(best_rate, req_rate)) {
+   best_rate = rate;
+   *v0 = i->val;
+   *v1 = j->val;
+   }
+   }
+   }
+
+   return best_rate;
+}
+
+static ulong armada_37xx_periph_clk_set_rate(struct clk *clk, ulong req_rate)
+{
+   struct a37xx_periphclk *priv = dev_get_priv(clk->dev);
+   const struct clk_periph *periph_clk = >clks[clk->id];
+   ulong rate, old_rate, parent_rate;
+   int div_val0 = 0, div_val1 = 0;
+   const struct clk_div_table *t1;
+   static const struct clk_div_table empty_table[2] = {
+   { 1, 0 },
+   { 0, 0 }
+   };
+
+   if (clk->id > priv->count)
+   return -EINVAL;
+
+   old_rate = periph_clk_get_rate(priv, clk->id);
+   if (old_rate == -EINVAL)
+   return -EINVAL;
+
+   if (old_rate == req_rate)
+   return old_rate;
+
+   if (!periph_clk->can_gate || !periph_clk->dividers)
+   return -ENOTSUPP;
+
+   parent_rate = get_parent_rate(priv, clk->id);
+   if (parent_rate == -EINVAL)
+   return -EINVAL;
+
+   t1 = empty_table;
+   if (periph_clk->dividers > 1)
+   t1 = periph_clk->div_table[1];
+
+   rate = find_best_div(periph_clk->div_table[0], t1, parent_rate,
+req_rate, _val0, _val1);
+
+   periph_clk_enable(clk, 0);
+
+   set_div_val(priv, periph_clk, 0, div_val0);
+   if (periph_clk->dividers > 1)
+   set_div_val(priv, periph_clk, 1, div_val1);
+
+   periph_clk_enable(clk, 1);
+
+   return rate;
+}
+
+static int armada_37xx_periph_clk_set_parent(struct clk *clk,
+struct clk *parent)
+{
+   struct a37xx_periphclk *priv = dev_get_priv(clk->dev);
+   const struct clk_periph *periph_clk = >clks[clk->id];
+   struct clk check_parent;
+   int ret;
+
+   /* We also check if parent is our TBG clock */
+   if (clk->id > priv->count || parent->id >= MAX_TBG_PARENTS)
+   return -EINVAL;
+
+   if (!periph_clk->can_mux || !periph_clk->can_gate)
+   return -ENOTSUPP;
+
+   ret = clk_get_by_index(clk->dev, 0, _parent);
+   if (ret < 0)
+   return ret;
+
+   if 

[U-Boot] [PATCH u-boot-marvell v2 01/12] phy: marvell: Support changing SERDES map in board file

[Marek Behún]

This adds a weak definition of comphy_update_map to comphy_core,
which does nothing. If this function is defined elsewhere, for example
in board file, the board file can change some parameters of SERDES
configuration.

This is needed on Turris Mox, where the SERDES speed on lane 1 has to
be set differently when SFP module is connected and when Topaz Switch
module is connected.

This is a temporary solution. When the comphy driver for armada-3720
will be added to the kernel, the comphy driver in u-boot shall also be
updated and this should be done differently then.

Signed-off-by: Marek Behun 
---
 MAINTAINERS |  3 ++-
 drivers/phy/marvell/comphy_a3700.h  |  2 +-
 drivers/phy/marvell/comphy_core.c   | 12 +++-
 drivers/phy/marvell/{comphy.h => comphy_core.h} | 16 
 drivers/phy/marvell/comphy_cp110.c  |  2 +-
 drivers/phy/marvell/comphy_mux.c|  2 +-
 include/mvebu/comphy.h  | 22 ++
 7 files changed, 42 insertions(+), 17 deletions(-)
 rename drivers/phy/marvell/{comphy.h => comphy_core.h} (96%)
 create mode 100644 include/mvebu/comphy.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8f237128b2..1893090b8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -139,7 +139,7 @@ S:  Maintained
 F: arch/arm/cpu/armv8/hisilicon
 F: arch/arm/include/asm/arch-hi6220/
 
-ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X
+ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX
 M: Prafulla Wadaskar 
 M: Luka Perkov 
 M: Stefan Roese 
@@ -148,6 +148,7 @@ T:  git git://git.denx.de/u-boot-marvell.git
 F: arch/arm/mach-kirkwood/
 F: arch/arm/mach-mvebu/
 F: drivers/ata/ahci_mvebu.c
+F: drivers/phy/marvell/
 
 ARM MARVELL PXA
 M: Marek Vasut 
diff --git a/drivers/phy/marvell/comphy_a3700.h 
b/drivers/phy/marvell/comphy_a3700.h
index a14767d809..b0941ffb37 100644
--- a/drivers/phy/marvell/comphy_a3700.h
+++ b/drivers/phy/marvell/comphy_a3700.h
@@ -6,7 +6,7 @@
 #ifndef _COMPHY_A3700_H_
 #define _COMPHY_A3700_H_
 
-#include "comphy.h"
+#include "comphy_core.h"
 #include "comphy_hpipe.h"
 
 #define MVEBU_REG(offs)\
diff --git a/drivers/phy/marvell/comphy_core.c 
b/drivers/phy/marvell/comphy_core.c
index c6e2cc8897..9c24692629 100644
--- a/drivers/phy/marvell/comphy_core.c
+++ b/drivers/phy/marvell/comphy_core.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 
-#include "comphy.h"
+#include "comphy_core.h"
 
 #define COMPHY_MAX_CHIP 4
 
@@ -66,6 +66,11 @@ void comphy_print(struct chip_serdes_phy_config *chip_cfg,
}
 }
 
+__weak int comphy_update_map(struct comphy_map *serdes_map, int count)
+{
+   return 0;
+}
+
 static int comphy_probe(struct udevice *dev)
 {
const void *blob = gd->fdt_blob;
@@ -76,6 +81,7 @@ static int comphy_probe(struct udevice *dev)
int lane;
int last_idx = 0;
static int current_idx;
+   int res;
 
/* Save base addresses for later use */
chip_cfg->comphy_base_addr = (void *)devfdt_get_addr_index(dev, 0);
@@ -143,6 +149,10 @@ static int comphy_probe(struct udevice *dev)
lane++;
}
 
+   res = comphy_update_map(comphy_map_data, chip_cfg->comphy_lanes_count);
+   if (res < 0)
+   return res;
+
/* Save CP index for MultiCP devices (A8K) */
chip_cfg->cp_index = current_idx++;
/* PHY power UP sequence */
diff --git a/drivers/phy/marvell/comphy.h b/drivers/phy/marvell/comphy_core.h
similarity index 96%
rename from drivers/phy/marvell/comphy.h
rename to drivers/phy/marvell/comphy_core.h
index b588ae41f0..12ab921d24 100644
--- a/drivers/phy/marvell/comphy.h
+++ b/drivers/phy/marvell/comphy_core.h
@@ -3,11 +3,11 @@
  * Copyright (C) 2015-2016 Marvell International Ltd.
  */
 
-#ifndef _COMPHY_H_
-#define _COMPHY_H_
+#ifndef _COMPHY_CORE_H_
+#define _COMPHY_CORE_H_
 
-#include 
 #include 
+#include 
 
 #if defined(DEBUG)
 #define debug_enter()  printf("> Enter %s\n", __func__);
@@ -80,14 +80,6 @@ struct comphy_mux_data {
struct comphy_mux_options mux_values[MAX_LANE_OPTIONS];
 };
 
-struct comphy_map {
-   u32 type;
-   u32 speed;
-   u32 invert;
-   bool clk_src;
-   bool end_point;
-};
-
 struct chip_serdes_phy_config {
struct comphy_mux_data *mux_data;
int (*ptr_comphy_chip_init)(struct chip_serdes_phy_config *,
@@ -183,5 +175,5 @@ void comphy_pcie_config_detect(u32 comphy_max_count,
   struct comphy_map *serdes_map);
 void comphy_pcie_unit_general_config(u32 pex_index);
 
-#endif /* _COMPHY_H_ */
+#endif /* _COMPHY_CORE_H_ */
 
diff --git a/drivers/phy/marvell/comphy_cp110.c 
b/drivers/phy/marvell/comphy_cp110.c
index b0d5d5ca26..6a60da3df0 100644
--- a/drivers/phy/marvell/comphy_cp110.c
+++ b/drivers/phy/marvell/comphy_cp110.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#include "comphy.h"
+#include "comphy_core.h"
 

[U-Boot] [PATCH u-boot-marvell v2 00/12] Updates for Turris Mox

[Marek Behún]

This is second version of updates for Turris Mox.
The first version was sent three months ago, on 16th May. Sorry :).
It would be great if this got to 2018.09 release, but I will
understand if it does not.

I changed the first patch, "phy: marvell: Support changing SERDES
map in board file", according to Stefan's suggestions.

The other patches have changed, since I have reworked the system
of how U-Boot tells kernel about the different Mox modules.

Previously the board code created a variable module_topology, which
then was used by boot script to load correct device tree. There were
many device trees, one for each correct module topology.

Now there is only one device tree, and U-Boot patches the device tree
in ft_board_setup, according to which modules are connected.

Patch 2 adds code to peripheral clocks, so that their parents/rates
can be changed.

Patch 3 fixes watchdog setup.

Patch 4 adds fixup for U-Boot's device tree according to module
topology (enables PCIe node if PCIe device is connected).

Patches 5 and 10 add configs to defcofnig.

Patch 6 is cosmetic.

Patch 7 adds comphy_update_map which updates SERDES lane 1 speed
according to module topology.

Patch 8 adds check for module topology, if it is correct and so on,
then adds configuration of switch modules via SPI and finally some
fancy switch LED blinking.

Patch 9 adds the code which patches Linux's device tree according
to module topology.

Patch 11 changes the Mox's U-Boot device tree.

Patch 12 creates a new config variable to support 1 GB RAM version
of Mox (and adds a -u-boot.dtsi to support the change).

Marek

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

Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config

[Christian Gmeiner]

HI all

Am Mo., 13. Aug. 2018 um 13:12 Uhr schrieb Gerard Salvatella
:
>
> Some boards require specific configuration prior to booting the kernel.
> For instance, our boards require shutting down the display to avoid
> fading transitions before the drivers are reloaded by the kernel. This
> could be facilitated by adding an extra hook during the os booting
> process.
>

I really like this idea (as I also need to do some pre-os-boot stuff
for a legacy operating system).

Reviewed-by: Christian Gmeiner 

> Signed-off-by: Gerard Salvatella 
> ---
>  common/bootm_os.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
>  }
>
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> +   /* please define board specific board_preboot_os() */
> +}
> +
>  int boot_selected_os(int argc, char * const argv[], int state,
>  bootm_headers_t *images, boot_os_fn *boot_fn)
>  {
> +   board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
>
> --
> 2.18.0
>
>
> [Toradex Logo]  Global Leader in Arm®
> Embedded Computer Modules
>
> Choose 
> Us | 
> Products | Developer 
> Center | 
> Community | 
> Careers
> Meet our engineers 
> at:
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [U-Boot] [PATCH 3/7] common: kconfig: Mark AVB_VERIFY as dependent on PARTITION_UUIDS

[Igor Opaniuk]

Hi Eugeniu,

Makes sense, thanks for the explanation.

Reviewed-by: Igor Opaniuk 

On 16 August 2018 at 21:25, Eugeniu Rosca  wrote:
> Hi Igor,
>
> First, thanks for the reviews!
>
> On Thu, Aug 16, 2018 at 11:38:18AM +0300, Igor Opaniuk wrote:
>> Hi Eugeniu,
>>
>> Why not keep all dependencies on the same line in this case? Simply:
>> depends LIBAVB && FASTBOOT && PARTITION_UUIDS
>
> I guess it's a matter of personal preference (but maybe not entirely).
> Let's say one needs to replace "depends on PARTITION_UUIDS" with
> "select PARTITION_UUIDS" due to e.g. a circular dependency detected
> by Kconfig at some point. For me below two lines:
>
> - depends on PARTITION_UUIDS
> + select PARTITION_UUIDS
>
> look more readable and are easier to review than:
>
> - depends LIBAVB && FASTBOOT && PARTITION_UUIDS
> + depends LIBAVB && FASTBOOT
> + select PARTITION_UUIDS
>
> I still can update the patch. Just let me know.
>
>>
>> Regards,
>> Igor
>
> Best regards,
> Eugeniu.



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

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

[Marek Vasut]

On 08/17/2018 03:51 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Thu, Aug 16, 2018 at 7:47 PM, Marek Vasut  wrote:
>> On 08/15/2018 01:25 PM, Tom Rini wrote:
>>> On Wed, Aug 15, 2018 at 06:19:25PM +0800, Bin Meng wrote:
 Hi Marek,

 On Wed, Aug 15, 2018 at 5:22 PM, Marek Vasut  wrote:
> On 08/14/2018 11:40 AM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut  
>> wrote:
>>> On 08/14/2018 03:46 AM, Bin Meng wrote:
 Hi Marek,

 On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut  
 wrote:
> On 08/13/2018 04:24 AM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut  
>> wrote:
>>> On 08/10/2018 02:01 PM, Tom Rini wrote:
 On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
> On 08/08/2018 05:32 PM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut 
>>  wrote:
>>> On 08/08/2018 03:39 PM, Bin Meng wrote:
 Hi Marek,

 On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut 
  wrote:
> On 08/08/2018 03:14 PM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut 
>>  wrote:
>>> The PCI controller can have DT subnodes describing extra 
>>> properties
>>> of particular PCI devices, ie. a PHY attached to an EHCI 
>>> controller
>>> on a PCI bus. This patch parses those DT subnodes and 
>>> assigns a node
>>> to the PCI device instance, so that the driver can extract 
>>> details
>>> from that node and ie. configure the PHY using the PHY 
>>> subsystem.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Simon Glass 
>>> ---
>>>  drivers/pci/pci-uclass.c | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci-uclass.c 
>>> b/drivers/pci/pci-uclass.c
>>> index 46e9c71bdf..306bea0dbf 100644
>>> --- a/drivers/pci/pci-uclass.c
>>> +++ b/drivers/pci/pci-uclass.c
>>> @@ -662,6 +662,8 @@ static int 
>>> pci_find_and_bind_driver(struct udevice *parent,
>>> for (id = entry->match;
>>>  id->vendor || id->subvendor || 
>>> id->class_mask;
>>>  id++) {
>>> +   ofnode node;
>>> +
>>> if (!pci_match_one_id(id, find_id))
>>> continue;
>>>
>>> @@ -691,6 +693,18 @@ static int 
>>> pci_find_and_bind_driver(struct udevice *parent,
>>> goto error;
>>> debug("%s: Match found: %s\n", 
>>> __func__, drv->name);
>>> dev->driver_data = 
>>> find_id->driver_data;
>>> +
>>> +   dev_for_each_subnode(node, parent) {
>>> +   phys_addr_t df, size;
>>> +   df = 
>>> ofnode_get_addr_size(node, "reg", );
>>> +
>>> +   if (PCI_FUNC(df) == 
>>> PCI_FUNC(bdf) &&
>>> +   PCI_DEV(df) == 
>>> PCI_DEV(bdf)) {
>>> +   dev->node = node;
>>> +   break;
>>> +   }
>>
>> The function pci_find_and_bind_driver() is supposed to bind 
>> devices
>> that are NOT in the device tree. Adding device tree access 
>> in this
>> routine is quite odd. You can add the EHCI controller that 
>> need such
>> PHY subnodes in the device tree and there is no need to 
>> modify
>> anything I believe. If you are looking for an example, 
>> please check
>> pciuart0 in arch/x86/dts/crownbay.dts.
>
> Well this does not work for me, the EHCI PCI doesn't get a DT 
> node
> assigned, check r8a7794.dtsi 

[U-Boot] [PULL] u-boot-sh/master

[Marek Vasut]

The following changes since commit a032e0a6aed208977f48e78d2cc497b91543beaf:

  travis: give every job a name (2018-08-10 13:50:30 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 4f10989280bb91f0981ffe2ffabe936bb2a92364:

  ARM: rmobile: Enable USB PHY on Gen2 (2018-08-14 11:31:25 +0200)


Marek Vasut (3):
  phy: Fix off-by-one error when parsing DT PHY bindings
  phy: rcar: Add R-Car Gen2 PHY driver
  ARM: rmobile: Enable USB PHY on Gen2

 arch/arm/mach-rmobile/Kconfig.32 |   2 ++
 drivers/phy/Kconfig  |   8 +++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-rcar-gen2.c  | 190
++
 drivers/phy/phy-uclass.c |   2 +-
 5 files changed, 202 insertions(+), 1 deletion(-)
 create mode 100644 drivers/phy/phy-rcar-gen2.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Fix mailbox urgent command with urgent register

[Marek Vasut]

On 08/17/2018 10:22 AM, Ley Foon Tan wrote:
> According to mailbox spec, software should send urgent command with
> urgent register instead of COUT location. This patch write urgent
> command index to urgent register.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/mailbox_s10.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/mailbox_s10.c 
> b/arch/arm/mach-socfpga/mailbox_s10.c
> index cccd1a4..0d906c3 100644
> --- a/arch/arm/mach-socfpga/mailbox_s10.c
> +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> @@ -160,15 +160,15 @@ static __always_inline int mbox_send_cmd_common(u8 id, 
> u32 cmd, u8 is_indirect,
>   u32 buf_len;
>   int ret;
>  
> - ret = mbox_prepare_cmd_only(id, cmd, is_indirect, len, arg);
> - if (ret)
> - return ret;
> -
>   if (urgent) {
>   /* Read status because it is toggled */
>   status = MBOX_READL(MBOX_STATUS) & MBOX_STATUS_UA_MSK;
> - /* Send command as urgent command */
> - MBOX_WRITEL(1, MBOX_URG);
> + /* Write urgent command to urgent register */
> + MBOX_WRITEL(cmd, MBOX_URG);
> + } else {
> + ret = mbox_prepare_cmd_only(id, cmd, is_indirect, len, arg);
> + if (ret)
> + return ret;
>   }
>  
>   /* write doorbell */
> @@ -188,8 +188,7 @@ static __always_inline int mbox_send_cmd_common(u8 id, 
> u32 cmd, u8 is_indirect,
>  
>   if (urgent) {
>   u32 new_status = MBOX_READL(MBOX_STATUS);
> - /* urgent command doesn't have response */
> - MBOX_WRITEL(0, MBOX_URG);
> +
>   /* Urgent ACK is toggled */
>   if ((new_status & MBOX_STATUS_UA_MSK) ^ status)
>   return 0;
> 
Applied, thanks.

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

[U-Boot] [PULL] u-boot-socfpga/master

[Marek Vasut]

The following changes since commit a032e0a6aed208977f48e78d2cc497b91543beaf:

  travis: give every job a name (2018-08-10 13:50:30 -0400)

are available in the Git repository at:

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

for you to fetch changes up to b0c0a715f90690a7dd4f33cb5b5c21960be26d3c:

  arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask (2018-08-15 12:41:09
+0200)


Ley Foon Tan (1):
  arm: socfpga: Fix SYSMGR_FPGAINTF_EMACx bit mask

Marek Vasut (20):
  ARM: socfpga: Register the FPGA on A10 in SPL again
  ARM: dts: socfpga: Flag reset manager on A10 as pre-reloc
  ARM: dts: socfpga: Add missing UART resets
  ARM: dts: socfpga: Fix Arria10 GMAC resets
  ARM: dts: socfpga: Add missing I2C resets
  ARM: dts: socfpga: Add i2c alias to A10 SoCDK
  ARM: socfpga: Enable DM reset framework on A10
  ARM: socfpga: Enable DM I2C framework on A10
  ARM: socfpga: Zap all the UART handling complexity
  net: designware: socfpga: Add Arria10 extras
  ARM: socfpga: Zap unused reset code
  ARM: socfpga: Remove adhoc ethernet reset and configuration
  ARM: socfpga: Enable DM ethernet on A10
  ARM: socfpga: clk: Obtain handoff base clock via DM
  ARM: socfpga: clk: Make L4SP and MMC clock calculation Gen5 only
  ARM: socfpga: clk: Drop unused variables on Arria10
  ARM: dts: socfpga: Add u-boot,dm-pre-reloc to necessary clock nodes
  clk: socfpga: Add initial Arria10 clock driver
  mmc: socfpga: Add clock framework support
  ARM: socfpga: clk: Convert to clock framework

Simon Goldschmidt (5):
  arm: socfpga: fix SPL on gen5 after moving to DM serial
  arm: socfpga: spl_gen5: clean up malloc_base assignment
  arm: socfpga: cyclone5: handle debug uart
  arm: socfpga: fix device trees to work with DM serial
  arm: socfpga: gen5: combine some init code for SPL and U-Boot

 arch/arm/Kconfig   |   2 +-
 arch/arm/dts/socfpga_arria10.dtsi  |  32
++--
 arch/arm/dts/socfpga_arria10_socdk.dtsi|  26 ++
 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 ++
 arch/arm/dts/socfpga_arria5_socdk.dts  |   5 ++
 arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts |   5 ++
 arch/arm/dts/socfpga_cyclone5_de0_nano_soc.dts |   5 ++
 arch/arm/dts/socfpga_cyclone5_de10_nano.dts|   5 ++
 arch/arm/dts/socfpga_cyclone5_de1_soc.dts  |   5 ++
 arch/arm/dts/socfpga_cyclone5_is1.dts  |   5 ++
 arch/arm/dts/socfpga_cyclone5_socdk.dts|   5 ++
 arch/arm/dts/socfpga_cyclone5_sockit.dts   |   5 ++
 arch/arm/dts/socfpga_cyclone5_socrates.dts |   5 ++
 arch/arm/dts/socfpga_cyclone5_sr1500.dts   |   2 +
 arch/arm/dts/socfpga_cyclone5_vining_fpga.dts  |   5 ++
 arch/arm/mach-socfpga/Kconfig  |  10 
 arch/arm/mach-socfpga/clock_manager.c  |   2 +
 arch/arm/mach-socfpga/clock_manager_arria10.c  | 306

 arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h |   6 ---
 arch/arm/mach-socfpga/include/mach/misc.h  |   6 +--
 arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h |   4 --
 arch/arm/mach-socfpga/include/mach/system_manager_s10.h|   6 +--
 arch/arm/mach-socfpga/misc_arria10.c   | 176
--
 arch/arm/mach-socfpga/misc_gen5.c  |  29
++-
 arch/arm/mach-socfpga/reset_manager_arria10.c  | 135

 arch/arm/mach-socfpga/spl_a10.c|   9 ++--
 arch/arm/mach-socfpga/spl_gen5.c   |  44
+---
 configs/socfpga_arria10_defconfig  |   2 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/altera/Makefile|   7 +++
 drivers/clk/altera/clk-arria10.c   | 363

 drivers/mmc/socfpga_dw_mmc.c   |  40
++
 drivers/net/Kconfig|   8 +++
 drivers/net/Makefile   |   1 +
 drivers/net/dwmac_socfpga.c| 143
+++
 35 files changed, 800 insertions(+), 627 deletions(-)
 create mode 100644 drivers/clk/altera/Makefile
 create mode 100644 drivers/clk/altera/clk-arria10.c
 create mode 

Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Enable EMAC to FPGA bridge based on handoff

[Marek Vasut]

On 08/17/2018 10:22 AM, Ley Foon Tan wrote:
> Code checking and setting EMAC use fpga is in
> populate_sysmgr_fpgaintf_module(). So, call to sysmgr_pinmux_init()
> instead of populate_sysmgr_pinmux().
> In sysmgr_pinmux_init(), it will call to both populate_sysmgr_pinmux()
> and populate_sysmgr_fpgaintf_module().
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/spl_s10.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> index 69d6e91..cc5dc4f 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -136,7 +136,7 @@ void board_init_f(ulong dummy)
>   socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
>   timer_init();
>  
> - populate_sysmgr_pinmux();
> + sysmgr_pinmux_init();
>  
>   /* configuring the HPS clocks */
>   cm_basic_init(cm_default_cfg);
> 
Applied, thanks.

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

Re: [U-Boot] [PATCH v5] arm: socfpga: fix U-Boot running from fpga OnChip RAM

[Marek Vasut]

On 08/17/2018 08:56 AM, Simon Goldschmidt wrote:
> On Fri, Aug 17, 2018 at 1:57 AM Marek Vasut  wrote:
>>
>> On 08/16/2018 09:44 PM, Simon Goldschmidt wrote:
>>> On Thu, Aug 16, 2018 at 4:04 PM Marek Vasut  wrote:

 On 08/16/2018 03:50 PM, Simon Goldschmidt wrote:
> On Thu, Aug 16, 2018 at 3:15 PM Marek Vasut  wrote:
>>
>> On 08/16/2018 03:12 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 16.
>>> Aug. 2018, 15:06:
>>>
>>> On 08/16/2018 03:00 PM, Simon Goldschmidt wrote:
>>> > On Thu, Aug 16, 2018 at 1:18 PM Marek Vasut >> > wrote:
>>> >>
>>> >> On 08/16/2018 09:38 AM, Simon Goldschmidt wrote:
>>> >>> gd->env_addr points to pre-relocation address even after
>>> >>> relocation. This leads to an abort in env_callback_init
>>> >>> when loading the environment.
>>> >>>
>>> >>> Fix this by enabling CONFIG_SYS_EXTRA_ENV_RELOC.
>>> >>>
>>> >>> Signed-off-by: Simon Goldschmidt
>>> >> >
>>> >>
>>> >> I have one last question -- does this somehow influence SPL ?
>>> >
>>> > No, it doesn't. The code that gets enabled by this define is in
>>> > common/board_r.c, which is not linked for SPL.
>>>
>>> Ah, thanks for checking.
>>>
>>> btw do you think it'd make sense to just enable this by default on 
>>> all
>>> systems and zap the EXTRA_ENV_RELOC macro altogether ?
>>>
>>>
>>> Yes, that's what I have thought about already. Just like the for the
>>> embedded device tree relocation, we could then probably use
>>> gd->reloc_off instead of CONFIG_SYS_MONITOR_BASE. I'm just not sure this
>>> really works for all boards, but it would be worth a try to push after
>>> this release is out.
>>
>> I think so too. I cannot think of a reason why this shouldn't be enabled
>> in fact.
>
> Exactly. Too me it seems like a leftover, especially given the use of
> CONFIG_SYS_MONITOR_BASE, which seems a little outdated, too.
> I've set up a reminder for a patch to remove it after the release.

 Feel free to send it now.
>>>
>>> OK, I have tried, but it seems it's not that easy: some boards
>>> override the initial gd->env_addr by setting CONFIG_ENV_ADDR. So if
>>> this is outside of U-Boot's pre-relocation range, it clearly should
>>> not be relocated. One might find an improved way to relocate
>>> gd->env_addr if it is internal (e.g. checking the range to be in
>>> pre-relocation?). But simply removing the EXTRA_ENV_RELOC  does not
>>> seem to work.
>>
>> Shouldn't most of those boards be easily fixable ?
> 
> Well, if we unconditionally alter gd->env_addr by gd->reloc_off,
> boards that have their initial gd->env_addr outside of the initial
> binary can be fixed only by changing their behaviour. I don't know how
> widely used this feature is, but since it's a config option
> (CONFIG_ENV_ADDR), how would we know?

git grep ? But aren't you mixing CONFIG_ENV_ADDR and CONFIG_ENV_RELOC ?

> So to me that means we still have to make this overridable and could
> change the "default" state of such an option only. Meaning that the
> default is "relocate gd->env_addr" with an option to leave it. But is
> this really worth breaking existing boards?

I think you do want to relocate the env alongside U-Boot, always, no ?

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

Re: [U-Boot] [PATCH] [RFC] blk: Increase cache element size

[Marek Vasut]

On 08/17/2018 04:43 AM, Tom Rini wrote:
> On Thu, Aug 16, 2018 at 01:42:33PM +0200, Marek Vasut wrote:
>> On 08/15/2018 06:27 PM, Tom Rini wrote:
>>> On Wed, Aug 15, 2018 at 06:20:16PM +0200, Marek Vasut wrote:
 On 08/15/2018 06:12 PM, Tom Rini wrote:
> On Wed, Aug 15, 2018 at 06:04:50PM +0200, Marek Vasut wrote:
>
>> On 08/15/2018 04:30 PM, Tom Rini wrote:
>>> On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
>>>
 Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
 the underlying block layer devices usually report support for 512B . In
 most cases, the 512B support is emulated (ie. SD cards, SSDs, USB 
 sticks
 etc.) and the real block size of those devices is much bigger.

 To avoid performance degradation with such devices and FS setup, bump
 the maximum cache entry size to 4 kiB.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
>>>
>>> Reviewed-by: Tom Rini 
>>>
>>> I'll pick this up post v2018.09 if no one objects, thanks!
>>
>> I object. I was hoping there'd be some discussion on how to solve this
>> in a future-proof manner ... it's only a matter of time until someone
>> uses ext4 with 8k blocks on an SSD ...
>
> In general, sure?  In specific, mkfs.ext4 1.42.13 man page says 1/2/4KiB
> are the only valid values of block size, and based on having to whack
> this for some other projects it's pretty common for OpenEmbedded at
> least to spit out 1KiB block size images.

 OE spits 4k , that's how I triggered it,
 meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext2 ?= "-i 4096"
 meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext3 ?= "-i 4096"
 meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext4 ?= "-i 4096"
>>>
>>> That's bytes-per-inode, I was referring to block size which is -b and
>>> dynamic unless specified.
>>
>> Right. Although, I think we mostly care about caching the inodes, not
>> blocks, since the inodes are accessed repeatedly.
> 
> OK, so it's the inode block.
> 
> So unless you know of cases
> today (or tomorrow, but not next year) where 8KiB is common or likely,
> we should probably just bump this for now and maybe make it a tunable so
> it's easily changed?

 It is already tunable, see blkcache config in blkcache command.

 But what I'd like to see is somehow the FS and the underlying storage
 negotiating the best settings. Can we get the FS block size from the
 block cache perspective ?
>>>
>>> Good questions that I don't have an answer to.
>>
>> What we can do is extend fs_devread() and blk_dread() with a new flag,
>> bool cachable, to allow FS and other upper layers which read block
>> devices to mark blocks that should specifically be cached as such. The
>> block cache would then cache the block no matter what size it has.
>>
>> The FS implementations should know which data should be cached because
>> they will be accessed repeatedly and which data are not, so they can set
>> the flag accordingly.
>>
>> The other users of blk_dread() would need to be examined. Possibly the
>> best solution right now to avoid problems would be to apply this patch
>> first. Then, second, add the flag to blk_dread() and set it accordingly
>> where applicable AND make the block cache cache blocks which are either
>> <= 8 kiB OR with cachable flag. Then finally, probably in next release,
>> drop the <= 8 kiB condition and cache only blocks which are flagged as
>> cachable to avoid polluting the block cache with useless small crumbs of
>> data.
>>
>> The downside is, the blk_dread() would look a bit asymmetrical compared
>> to the other functions with the cachable flag in it's parameters.
>>
>> Thoughts ?
> 
> Frankly, this sounds rather complicated when we might just need to
> increase the size of what we can cache a bit.  We aren't a long running
> facility and so long as it's tunable, it's also most likely being used
> in machines where we have enough DDR that we can a few more kilobytes.

It maybe increase the performance slightly though by not polluting the
cache with which shouldn't be there. Might even be useful in SPL.

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

Re: [U-Boot] [PATCH v2 2/2] ARM: mach-mvebu: handle fall-back to UART boot

[Sean Nyekjær]

On 17/08/2018 10.47, Chris Packham wrote:

The bootROM in the Armada-38x (and similar) SoC has two modes for UART
boot. The first is when the normal boot media is blank (or otherwise
missing the kwb header). The second is when the boot sequence has been
interrupted with the magic byte sequence on the UART lines.

In the first mode the bootROM routine and error code register will
indicate that there was an error booting from the configured media in
bits 7:0. In the second mode there is no error to indicate but the boot
source is provided via bits 31:28.

Handle both situations so that kwboot can be used for both boot
strapping a blank board and for intercepting a regular boot sequence.

Signed-off-by: Chris Packham 

Signed-off-by: Sean Nyekjaer 

---
I think this probably applies to more than just the A38X but I've been
conservative in restricting this for now. If other Marvell SoCs are
found to have the same behaviour we can extend this to cover them.

Changes in v2:
- new

  arch/arm/mach-mvebu/include/mach/soc.h |  2 ++
  arch/arm/mach-mvebu/spl.c  | 10 ++
  2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 660dd148abc5..6e2e14efe0b7 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -114,6 +114,8 @@
  #define BOOTROM_ERR_MODE_OFFS 28
  #define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS)
  #define BOOTROM_ERR_MODE_UART 0x6
+#define BOOTROM_ERR_CODE_OFFS  0
+#define BOOTROM_ERR_CODE_MASK  (0xf << BOOTROM_ERR_CODE_OFFS)
  
  #if defined(CONFIG_ARMADA_375)

  /* SAR values for Armada 375 */
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 4c3933b8354d..9dd7c84b6874 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -28,6 +28,16 @@ static u32 get_boot_device(void)
if (boot_device == BOOTROM_ERR_MODE_UART)
return BOOT_DEVICE_UART;
  
+#ifdef CONFIG_ARMADA_38X

+   /*
+* If the bootrom error code contains any other than zeros it's an
+* error condition and the bootROM has fallen back to UART boot
+*/
+   boot_device = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
+   if (boot_device)
+   return BOOT_DEVICE_UART;
+#endif
+
/*
 * Now check the SAR register for the strapped boot-device
 */


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

Re: [U-Boot] [PATCH] mtd: nand: spi: Add Gigadevice SPI NAND support

[Stefan Roese]

Hi Miquel,

On 17.08.2018 10:45, Miquel Raynal wrote:

Stefan Roese  wrote on Thu, 16 Aug 2018 18:05:08 +0200:


This patch adds support for Gigadevices SPI NAND device to the new SPI
NAND infrastructure in U-Boot. Currently only the 128MiB GD5F1GQ4UC
device is supported.

Signed-off-by: Stefan Roese 
Cc: Miquel Raynal 
Cc: Boris Brezillon 
Cc: Jagan Teki 
---
Miquel, I somehow always forgot to send this Gigadevice support
patch in my last series versions. This is the chip I'm currently
testing with. Either please fold it into your series, if you
re-send it at a later time. Or we should add it on top. Of course
only if nobody has any objections or change requests.


No problem, as I don't wan't to resend another series of 30+ patches I
just asked Jagan/Tom if they could take them (up to patch 23 included),
so this one could be applied on top of it, alone.

Reviewed-by: Miquel Raynal 


Thanks.


BTW, I see #ifndef __UBOOT__ but I don't think it has been contributed
to Linux yet, do you plan to do it?


Ah, yes. That ifdef if from a copy-and-paste. Its not been used in Linux
yet (we are still on some older OpenWRT branch that uses an older SPI
NAND infrastructure). But the plan is to move to the new IF soon and
we will definitely push this SPI NAND chip support into mainline.

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

Re: [U-Boot] [PATCH] tools: kwboot: Make kwboot more robust on a38x

[Chris Packham]

On Fri, Aug 17, 2018 at 8:11 PM Jon Nettleton  wrote:
>
> On Fri, Aug 17, 2018 at 1:22 AM Chris Packham  wrote:
> >
> > On Fri, Aug 17, 2018 at 11:06 AM Chris Packham  
> > wrote:
> > >
> > > On Fri, Aug 17, 2018 at 11:01 AM Chris Packham  
> > > wrote:
> > > >
> > > > On Thu, Aug 16, 2018 at 8:38 PM Baruch Siach  wrote:
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Chris Packham writes:
> > > > > > On Tue, Aug 14, 2018 at 3:25 AM Baruch Siach  
> > > > > > wrote:
> > > > > >> From: Jon Nettleton 
> > > > > >>
> > > > > >> This patch accomplishes 2 things to make the kwboot procedure
> > > > > >> on the a38x more reliable.
> > > > > >>
> > > > > >> 1)  We fill the tty with 1K of the magic bootparam.  This helps
> > > > > >> with the timing of where the microcode picks up in the read of
> > > > > >> the line to ensure we actually catch the break to go into recovery
> > > > > >> mode
> > > > > >>
> > > > > >> 2)  Before starting the xmodem transfer we sleep for 2 seconds
> > > > > >> and then flush the line.  This allows all the magic bootparam
> > > > > >> to be flushed from the line and makes the xmodem transfer reliable
> > > > > >> and removes the Bad message failures.
> > > > > >>
> > > > > >> Signed-off-by: Jon Nettleton 
> > > > > >> Signed-off-by: Baruch Siach 
> > > > > >> ---
> > > > > >
> > > > > > Reviewed-by: Chris Packham 
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > Lately I haven't had much luck with using kwboot on a38x. I seem to 
> > > > > > be
> > > > > > able to get the spl to boot from uart (even better now thanks to 
> > > > > > this
> > > > > > patch) but the next stage still loads from SPI. I haven't been brave
> > > > > > enough to blank a board to see if that changes behaviour. Are your
> > > > > > experiences any different? I'm wondering if there is something we 
> > > > > > need
> > > > > > to do in the SPL to figure out that we need to load the next stage 
> > > > > > via
> > > > > > xmodem.
> > > > >
> > > > > It works for me here on the Clearfog.
> > > > >
> > > > > The code that determines the seconds stage load device is in
> > > > > arch/arm/mach-mvebu/spl.c:get_boot_device(). Does the code there get 
> > > > > it
> > > > > right? What do you read from CONFIG_BOOTROM_ERR_REG?
> > > > >
> > > >
> > > > I get the following from enabling the debug
> > > >
> > > > BOOTROM_REG=0x63001000 boot_device=0x0
> > > > SAR_REG=0xcb20b342 boot_device=0x34
> > > > BOOTROM_REG=0x63001000 boot_device=0x0
> > > > SAR_REG=0xcb20b342 boot_device=0x34
> > > >
> > > > The strapping is for SPI so the second part isn't surprising.
> > >
> > > (sorry hit send too soon)
> > >
> > > If I hard code get_boot_device() to return BOOT_DEVICE_UART then
> > > kwboot works for me.
> >
> > And if I revert commit e83e2b390038 ("arm: mvebu: fix boot from UART
> > when in fallback mode") it works properly.
>
> Chris,
>
> I see the issue.  Mainline is still missing another patch from our
> local tree.  I don't think Baruch has broken it out and submitted it
> to mainline yet.  Look at this #ifndef here.
>
> https://github.com/SolidRun/u-boot/blob/v2018.01-solidrun-a38x/arch/arm/mach-mvebu/spl.c#L35
>
> Basically this allows you to specifically build u-boot for UART
> recovery and short circuits the detected boot device if it is already
> configured.  Please try adding that in and verify that it works for
> you.
>
> This also requires u-boot with commit
> 72c4e67d08fe2389754b4ce874d76b1bbd9fef24 and
> CONFIG_MVEBU_SPL_BOOT_DEVICE_UART set in your  .config
>
> Thanks,
> Jon
>
> This does bring up the question as to whether Boot Method should be
> individual choices and then we build multiple images named for each
> boot type rather than requiring an individual build for each boot
> type.

That's certainly what Marvell's USP does. But I find it a pain because
you have to remember to load the right image and you waste so much
time sending an image configured for spi over xmodem only to realise
you copied the wrong one. Or you brick a board by writing the UART
version into flash.I like the kwboot method of patching the image on
the fly.

I think the real issue I was experiencing is that there are 2
different behaviours depending on whether your intercepting a normal
boot. Or bringing up a blank board. I've just sent a series to deal
with this http://patchwork.ozlabs.org/patch/958704/ (I got your main
just after sending it, I'll include you in the Cc if there is a
re-roll).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] ARM: mach-mvebu: handle fall-back to UART boot

[Chris Packham]

The bootROM in the Armada-38x (and similar) SoC has two modes for UART
boot. The first is when the normal boot media is blank (or otherwise
missing the kwb header). The second is when the boot sequence has been
interrupted with the magic byte sequence on the UART lines.

In the first mode the bootROM routine and error code register will
indicate that there was an error booting from the configured media in
bits 7:0. In the second mode there is no error to indicate but the boot
source is provided via bits 31:28.

Handle both situations so that kwboot can be used for both boot
strapping a blank board and for intercepting a regular boot sequence.

Signed-off-by: Chris Packham 
---
I think this probably applies to more than just the A38X but I've been
conservative in restricting this for now. If other Marvell SoCs are
found to have the same behaviour we can extend this to cover them.

Changes in v2:
- new

 arch/arm/mach-mvebu/include/mach/soc.h |  2 ++
 arch/arm/mach-mvebu/spl.c  | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 660dd148abc5..6e2e14efe0b7 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -114,6 +114,8 @@
 #define BOOTROM_ERR_MODE_OFFS  28
 #define BOOTROM_ERR_MODE_MASK  (0xf << BOOTROM_ERR_MODE_OFFS)
 #define BOOTROM_ERR_MODE_UART  0x6
+#define BOOTROM_ERR_CODE_OFFS  0
+#define BOOTROM_ERR_CODE_MASK  (0xf << BOOTROM_ERR_CODE_OFFS)
 
 #if defined(CONFIG_ARMADA_375)
 /* SAR values for Armada 375 */
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 4c3933b8354d..9dd7c84b6874 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -28,6 +28,16 @@ static u32 get_boot_device(void)
if (boot_device == BOOTROM_ERR_MODE_UART)
return BOOT_DEVICE_UART;
 
+#ifdef CONFIG_ARMADA_38X
+   /*
+* If the bootrom error code contains any other than zeros it's an
+* error condition and the bootROM has fallen back to UART boot
+*/
+   boot_device = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
+   if (boot_device)
+   return BOOT_DEVICE_UART;
+#endif
+
/*
 * Now check the SAR register for the strapped boot-device
 */
-- 
2.18.0

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

[U-Boot] [PATCH v2 1/2] Revert "arm: mvebu: fix boot from UART when in fallback mode"

[Chris Packham]

This reverts commit e83e2b390038c9075642cb243a6292241beb8d73. This
prevents kwboot from overriding the hardware strapped boot source.

Signed-off-by: Chris Packham 
---

Changes in v2: None

 arch/arm/mach-mvebu/include/mach/soc.h | 6 --
 arch/arm/mach-mvebu/spl.c  | 9 -
 2 files changed, 15 deletions(-)

diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 623ab4eb8d93..660dd148abc5 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -110,16 +110,10 @@
 #define COMPHY_REFCLK_ALIGNMENT(MVEBU_REGISTER(0x182f8))
 
 /* BootROM error register (also includes some status infos) */
-#if defined(CONFIG_ARMADA_38X)
-#define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
-#define BOOTROM_ERR_MODE_OFFS  0
-#define BOOTROM_ERR_MODE_MASK  (0xf << BOOTROM_ERR_MODE_OFFS)
-#else
 #define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
 #define BOOTROM_ERR_MODE_OFFS  28
 #define BOOTROM_ERR_MODE_MASK  (0xf << BOOTROM_ERR_MODE_OFFS)
 #define BOOTROM_ERR_MODE_UART  0x6
-#endif
 
 #if defined(CONFIG_ARMADA_375)
 /* SAR values for Armada 375 */
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 50b24f5760b7..4c3933b8354d 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -25,16 +25,7 @@ static u32 get_boot_device(void)
val = readl(CONFIG_BOOTROM_ERR_REG);
boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
-#if defined(CONFIG_ARMADA_38X)
-   /*
-* If the bootrom error register contains any else than zeros
-* in the first 8 bits it's an error condition. And in that case
-* try to boot from UART.
-*/
-   if (boot_device)
-#else
if (boot_device == BOOTROM_ERR_MODE_UART)
-#endif
return BOOT_DEVICE_UART;
 
/*
-- 
2.18.0

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

Re: [U-Boot] [PATCH] mtd: nand: spi: Add Gigadevice SPI NAND support

[Miquel Raynal]

Hi Stefan,

Stefan Roese  wrote on Thu, 16 Aug 2018 18:05:08 +0200:

> This patch adds support for Gigadevices SPI NAND device to the new SPI
> NAND infrastructure in U-Boot. Currently only the 128MiB GD5F1GQ4UC
> device is supported.
> 
> Signed-off-by: Stefan Roese 
> Cc: Miquel Raynal 
> Cc: Boris Brezillon 
> Cc: Jagan Teki 
> ---
> Miquel, I somehow always forgot to send this Gigadevice support
> patch in my last series versions. This is the chip I'm currently
> testing with. Either please fold it into your series, if you
> re-send it at a later time. Or we should add it on top. Of course
> only if nobody has any objections or change requests.

No problem, as I don't wan't to resend another series of 30+ patches I
just asked Jagan/Tom if they could take them (up to patch 23 included),
so this one could be applied on top of it, alone.

Reviewed-by: Miquel Raynal 

BTW, I see #ifndef __UBOOT__ but I don't think it has been contributed
to Linux yet, do you plan to do it?

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

Re: [U-Boot] [PATCH v6 00/31] SPI-NAND support

[Miquel Raynal]

Hi Tom, Jagan,

Boris Brezillon  wrote on Thu, 16 Aug 2018
18:58:58 +0200:

> Tom, Jagan,
> 
> On Thu, 16 Aug 2018 17:29:58 +0200
> Miquel Raynal  wrote:
> 
> > During the last months, Boris Brezillon shared his work to support
> > serial flashes within Linux. First, he delivered (and merged) a new
> > layer called spi-mem. He also initiated in Linux MTD subsystem the move
> > of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> > same time a NAND core that would be shared with all NAND devices. Then,
> > he contributed a generic SPI-NAND driver, making use of this NAND core,
> > as well as some vendor code to drive a few chips.
> > 
> > On top of this work, I made some cleanups in the MTD layer and added an
> > 'mtd' U-Boot command to handle all sort of MTD devices. This should
> > become the default command instead of having one per flash flavor
> > ('sf', 'nand', 'spi-nand' ?).
> > 
> > The series has been tested on an Ocelot board PCB123 (VSC7514),
> > featuring a Macronix SPI NAND chip.
> > 
> > TL;DR: the series contains:
> > - A few patches from Linux to resynchronize some areas of the MTD layer.
> > - Various fixes and re-organization of the MTD subsystem.
> > - The introduction of the SPI-mem interface.
> > - The addition of the generic SPI-NAND driver (and its bindings).
> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > - A new 'mtd' command.
> > - Support for spi-nand devices in mtdparts.
> > 
> > To test your SPI-NAND device with U-Boot simply follow these lines:
> >   
> > > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> > > ubi part bar # create a static UBI volume in the bar partition
> > > mtd list # show the current MTD devices/partitions
> > 
> > Thanks,
> > Miquèl
> >   
> 
> [...]
> 
> Can we get some of those patches merged to avoid sending another
> version containing more than 30 patches. Here is a list of patches which
> IMO are ready to be merged:
> 
>  - 1 to 4
>  - 5 and 6 if 6 is squashed in 5
>  - 7 to 23
> 

Yes, I agree with Boris, I do not want to resend another 30+ patch
series while the changes are on the last 5 only, could one of you
please apply them from 1 to 23 (with 6 squashed in 5) ?

Next week I will send a v7 for patches 24..31.

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