Re: [U-Boot] [PATCH] menu: fix timeout duration

2018-05-23 Thread Masahiro Yamada
2018-05-24 13:29 GMT+09:00 Masahiro Yamada :
> menu_interactive_choice() divides the timeout value by 10 before
> passing it to cli_readline_into_buffer().
>
> For distro-boot, the "timeout" variable in the boot script should
> specify the time in _seconds_ to wait for keyboard input before
> booting the default menu entry.
>
> Due to the division, "timeout 50" actually wait for only 5 seconds
> instead of 50.  What is worse, "timeout 5" never breaks because
> "m->timeout / 10" is zero, which means no timeout.
>
> For CONFIG_MENU_SHOW case, menu_show() should also take the timeout
> value in seconds because its default comes from CONFIG_BOOTDELAY.
>
> The "division by 10" was introduced by commit 8594753ba0a7 ("menu:
> only timeout when menu is displayed").  Its log claimed "fixed",
> but to me, it rather looks the root cause of the problem.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Rob,
>
> I know commit 8594753ba0a7 is already 6 years ago.
> If you remember something about "/ 10", please comment.
>

I was misunderstanding.

I will do v2.



>  common/menu.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/common/menu.c b/common/menu.c
> index bf2b471..bf23194 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -194,8 +194,7 @@ static inline int menu_interactive_choice(struct menu *m, 
> void **choice)
>
> if (!m->item_choice) {
> readret = cli_readline_into_buffer("Enter choice: ",
> -  cbuf,
> -  m->timeout / 10);
> +  cbuf, timeout);
>
> if (readret >= 0) {
> choice_item = menu_item_by_key(m, cbuf);
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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


[U-Boot] [PATCH v2 3/3] common: Generic loader for file system

2018-05-23 Thread tien . fong . chee
From: Tien Fong Chee 

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.

Signed-off-by: Tien Fong Chee 
---
 drivers/misc/Kconfig |  11 +++
 drivers/misc/Makefile|   1 +
 drivers/misc/fs_loader.c | 240 +++
 include/dm/uclass-id.h   |   1 +
 include/fs_loader.h  |  28 ++
 5 files changed, 281 insertions(+)
 create mode 100644 drivers/misc/fs_loader.c
 create mode 100644 include/fs_loader.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index be900cf..59f716b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -268,4 +268,15 @@ config GDSYS_RXAUI_CTRL
depends on MISC
help
  Support gdsys FPGA's RXAUI control.
+
+config FS_LOADER
+   bool "Enable loader driver for file system"
+   depends on DM
+   help
+ This is file system generic loader which can be used to load
+ the file image from the storage into target such as memory.
+
+ The consumer driver would then use this loader to program whatever,
+ ie. the FPGA device.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e362609..74364a0 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
 obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
 obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
 obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_FS_LOADER) += fs_loader.o
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
new file mode 100644
index 000..127f7f1
--- /dev/null
+++ b/drivers/misc/fs_loader.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (C) 2018 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct firmware_priv {
+   const char *name;   /* Filename */
+   u32 offset; /* Offset of reading a file */
+};
+
+static int select_fs_dev(struct udevice *dev)
+{
+   int ret;
+   struct device_platdata *plat;
+
+   plat = dev->platdata;
+   if (!strcmp("mmc", plat->name)) {
+   ret = fs_set_blk_dev("mmc", plat->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("usb", plat->name)) {
+   ret = fs_set_blk_dev("usb", plat->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("sata", plat->name)) {
+   ret = fs_set_blk_dev("sata", plat->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("ubi", plat->name)) {
+   if (plat->ubivol)
+   ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
+   else
+   ret = -ENODEV;
+   } else {
+   debug("Error: unsupported storage device.\n");
+   return -ENODEV;
+   }
+
+   if (ret)
+   debug("Error: could not access storage.\n");
+
+   return ret;
+}
+
+static void set_storage_devpart(struct udevice *dev, char *devpart)
+{
+   struct device_platdata *plat;
+
+   plat = dev->platdata;
+   plat->devpart = devpart;
+}
+
+static void set_storage_mtdpart(struct udevice *dev, char *mtdpart)
+{
+   struct device_platdata *plat;
+
+   plat = dev->platdata;
+   plat->mtdpart = mtdpart;
+}
+
+static void set_storage_ubivol(struct udevice *dev, char *ubivol)
+{
+   struct device_platdata *plat;
+
+   plat = dev->platdata;
+   plat->ubivol = ubivol;
+}
+
+/**
+ * _request_firmware_prepare - Prepare firmware struct.
+ *
+ * @firmware_p: Pointer to pointer to firmware image.
+ * @name: Name of firmware file.
+ * @dbuf: Address of buffer to load firmware into.
+ * @size: Size of buffer.
+ * @offset: Offset of a file for start reading into buffer.
+ *
+ * Return: Negative value if fail, 0 for successful.
+ */
+static int _request_firmware_prepare(struct firmware **firmware_p,
+   const char *name, void *dbuf,
+   size_t size, u32 offset)
+{
+   struct firmware *firmware;
+   struct firmware_priv *fw_priv;
+
+   *firmware_p = NULL;
+
+   if (!name || name[0] == '\0')
+   return -EINVAL;
+
+   firmware = calloc(1, sizeof(*firmware));
+   if (!firmware)
+   return -ENOMEM;
+
+   fw_priv = calloc(1, sizeof(*fw_priv));
+   if (!fw_priv) {
+   free(firmware);
+   return -ENOMEM;
+   }
+
+   fw_priv->name = name;
+   fw_priv->offset = offset;
+   firmware->data = dbuf;
+   firmware->size = size;
+   firmware->priv = fw_priv;
+   *firmware_p = firmware;
+
+   return 0;
+}
+
+/**
+ * fw_get_filesystem_firmware - load firmware into an allocated buffer.
+ 

[U-Boot] [PATCH v2 2/3] doc: dtbinding: Add file system firmware loader binding document

2018-05-23 Thread tien . fong . chee
From: Tien Fong Chee 

Add a document to describe file system firmware loader binding
information.

Signed-off-by: Tien Fong Chee 
---
 doc/device-tree-bindings/misc/fs_loader.txt | 50 +
 1 file changed, 50 insertions(+)
 create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt

diff --git a/doc/device-tree-bindings/misc/fs_loader.txt 
b/doc/device-tree-bindings/misc/fs_loader.txt
new file mode 100644
index 000..066d690
--- /dev/null
+++ b/doc/device-tree-bindings/misc/fs_loader.txt
@@ -0,0 +1,50 @@
+* File system firmware loader
+
+Required properties:
+
+
+- compatible: should contain "fs_loader"
+- storage_device: which storage device loading from, could be:
+ - mmc, usb, sata, and ubi.
+- devpart: which storage device and partition the image loading from,
+  this property is required for mmc, usb and sata.
+- mdtpart: which partition of ubi the image loading from, this property is
+  required for ubi.
+- ubivol: which volume of ubi the image loading from, this proprety is required
+ for ubi.
+
+Example of default storage device partition search set for mmc, usb, sata and
+ubi in device tree source as shown in below:
+
+Example for mmc:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "mmc";
+   devpart = "0:1";
+   };
+
+Example for usb:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "usb";
+   devpart = "0:1";
+   };
+
+Example for sata:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "sata";
+   devpart = "0:1";
+   };
+
+Example for ubi:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "ubi";
+   mtdpart = "UBI",
+   ubivol = "ubi0";
+   };
-- 
2.2.0

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


[U-Boot] [PATCH v2 1/3] doc: Add new doc for file system firmware loader driver model

2018-05-23 Thread tien . fong . chee
From: Tien Fong Chee 

Provide information about

- overview of file system firmware loader driver model
- describe default storage device in device tree source
- describe fie system firmware loader API

Signed-off-by: Tien Fong Chee 
---
 doc/driver-model/fs_firmware_loader.txt | 103 
 1 file changed, 103 insertions(+)
 create mode 100644 doc/driver-model/fs_firmware_loader.txt

diff --git a/doc/driver-model/fs_firmware_loader.txt 
b/doc/driver-model/fs_firmware_loader.txt
new file mode 100644
index 000..f05db8d
--- /dev/null
+++ b/doc/driver-model/fs_firmware_loader.txt
@@ -0,0 +1,103 @@
+# Copyright (C) 2018 Intel Corporation 
+#
+# SPDX-License-Identifier:GPL-2.0
+
+Introduction
+
+
+This is file system firmware loader for U-Boot framework, which has very close
+to some Linux Firmware API. For the details of Linux Firmware API, you can 
refer
+to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html.
+
+File system firmware loader can be used to load whatever(firmware, image,
+and binary) from the storage device in file system format into target location
+such as memory, then consumer driver such as FPGA driver can program FPGA image
+from the target location into FPGA.
+
+To enable firmware loader driver model, CONFIG_FS_LOADER need to be set at
+_defconfig such as "CONFIG_FS_LOADER=y".
+
+Firmware Loader API core features
+-
+
+Firmware storage device described in device tree source
+---
+   Example of default storage device partition search set for mmc, usb,
+   sata and ubi as shown in below:
+   Example for mmc:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "mmc";
+   devpart = "0:1";
+   };
+
+   Example for usb:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "usb";
+   devpart = "0:1";
+   };
+
+   Example for sata:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "sata";
+   devpart = "0:1";
+   };
+
+   Example for ubi:
+   fs_loader {
+   u-boot,dm-pre-reloc;
+   compatible = "fs_loader";
+   storage_device = "ubi";
+   mtdpart = "UBI",
+   ubivol = "ubi0";
+   };
+
+
+   However, the default fs_loader with property devpart, mtdpart, and
+   ubivol values can be overwritten with value which is defined in the
+   environment variable "fw_dev_part", "fw_ubi_mtdpart", and
+   "fw_ubi_volume" respectively.
+   For example: env_set("fw_dev_part", "0:2");
+
+File system firmware Loader API
+---
+
+int request_firmware_into_buf(struct udevice *dev,
+struct firmware **firmware_p,
+const char *name,
+void *buf, size_t size, u32 offset)
+
+Load firmware into a previously allocated buffer
+
+Parameters:
+
+1. struct udevice *dev
+   An instance of a driver
+
+2. struct firmware **firmware_p
+   pointer to firmware image
+
+3. const char *name
+   name of firmware file
+
+4. void *buf
+   address of buffer to load firmware into
+
+5. size_t size
+   size of buffer
+
+6. u32 offset
+   offset of a file for start reading into buffer
+
+return:
+   size of total read
+   -ve when error
+
+Description:
+   The firmware is loaded directly into the buffer pointed to by buf and
+   the @firmware_p data member is pointed at buf.
-- 
2.2.0

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


[U-Boot] [PATCH v2 0/3] Generic file system firmware loader DM

2018-05-23 Thread tien . fong . chee
From: Tien Fong Chee 

This patchset contains generic file system loader DM which is very close to
Linux firmware loader but for U-Boot framework. Generic file system firmware
loader can be used load whatever into target location, and then consumer driver
would use it to program whatever, ie. the FPGA. This version mainly resolved
comments from Tom Rini in [v1].

This series is working on top of u-boot-socfpga.git -
 http://git.denx.de/u-boot.git .

[v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg286294.html

v1 -> v2 changes

- Changed the documents to rST format.

Tien Fong Chee (3):
  doc: Add new doc for file system firmware loader driver model
  doc: dtbinding: Add file system firmware loader binding document
  common: Generic loader for file system

 doc/device-tree-bindings/misc/fs_loader.txt |  50 ++
 doc/driver-model/fs_firmware_loader.txt | 103 
 drivers/misc/Kconfig|  11 ++
 drivers/misc/Makefile   |   1 +
 drivers/misc/fs_loader.c| 240 
 include/dm/uclass-id.h  |   1 +
 include/fs_loader.h |  28 
 7 files changed, 434 insertions(+)
 create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
 create mode 100644 doc/driver-model/fs_firmware_loader.txt
 create mode 100644 drivers/misc/fs_loader.c
 create mode 100644 include/fs_loader.h

-- 
2.2.0

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


[U-Boot] [PATCH v2] sunxi: add support for Banana Pi M2 Zero board

2018-05-23 Thread Jun Nie
Banana Pi M2 Zero is a board by Sinovoip with Allwinner H2+ SoC, 16-bit
512MiB DDR3 memory, a MicroSD slot, two MicroUSB ports (one OTG and one
powering-only) and a miniHDMI port.

DTS file is from Linux kernel with removing some nodes that are not needed
in u-boot or not merged into u-boot yet.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Jun Nie 
---
 arch/arm/dts/Makefile   |  1 +
 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 68 +
 board/sunxi/MAINTAINERS |  5 ++
 configs/bananapi_m2_zero_defconfig  | 15 ++
 4 files changed, 89 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
 create mode 100644 configs/bananapi_m2_zero_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20a4c37..8d6fab2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -338,6 +338,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-a83t-tbs-a711.dts
 dtb-$(CONFIG_MACH_SUN8I_H3) += \
+   sun8i-h2-plus-bananapi-m2-zero.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-libretech-all-h3-cc.dtb \
diff --git a/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts 
b/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
new file mode 100644
index 000..92e8cf4
--- /dev/null
+++ b/arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ *
+ * Based on sun8i-h3-bananapi-m2-plus.dts, which is:
+ *   Copyright (C) 2016 Chen-Yu Tsai 
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "Banana Pi BPI-M2-Zero";
+   compatible = "sinovoip,bpi-m2-zero", "allwinner,sun8i-h2-plus";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pwr_led {
+   label = "bananapi-m2-zero:red:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+   default-state = "on";
+   };
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   sw4 {
+   label = "power";
+   linux,code = ;
+   gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   /*
+* On the production batch of this board the card detect GPIO is
+* high active (card inserted), although on the early samples it's
+* low active.
+*/
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 5eb8bbe..0d904d9 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -363,6 +363,11 @@ M: Icenowy Zheng 
 S: Maintained
 F: configs/Sinovoip_BPI_M2_Plus_defconfig
 
+SINOVOIP BPI M2 ZERO BOARD
+M: Icenowy Zheng 
+S: Maintained
+F: configs/Sinovoip_BPI_M2_Zero_defconfig
+
 SINOVOIP BPI M3 A83T BOARD
 M: VishnuPatekar 
 S: Maintained
diff --git a/configs/bananapi_m2_zero_defconfig 
b/configs/bananapi_m2_zero_defconfig
new file mode 100644
index 000..b919d8b
--- /dev/null
+++ b/configs/bananapi_m2_zero_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SYS_TEXT_BASE=0x4a00
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=408
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y
+CONFIG_MMC0_CD_PIN=""
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h2-plus-bananapi-m2-zero"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION 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] menu: fix timeout duration

2018-05-23 Thread Masahiro Yamada
menu_interactive_choice() divides the timeout value by 10 before
passing it to cli_readline_into_buffer().

For distro-boot, the "timeout" variable in the boot script should
specify the time in _seconds_ to wait for keyboard input before
booting the default menu entry.

Due to the division, "timeout 50" actually wait for only 5 seconds
instead of 50.  What is worse, "timeout 5" never breaks because
"m->timeout / 10" is zero, which means no timeout.

For CONFIG_MENU_SHOW case, menu_show() should also take the timeout
value in seconds because its default comes from CONFIG_BOOTDELAY.

The "division by 10" was introduced by commit 8594753ba0a7 ("menu:
only timeout when menu is displayed").  Its log claimed "fixed",
but to me, it rather looks the root cause of the problem.

Signed-off-by: Masahiro Yamada 
---

Rob,

I know commit 8594753ba0a7 is already 6 years ago.
If you remember something about "/ 10", please comment.


 common/menu.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/common/menu.c b/common/menu.c
index bf2b471..bf23194 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -194,8 +194,7 @@ static inline int menu_interactive_choice(struct menu *m, 
void **choice)
 
if (!m->item_choice) {
readret = cli_readline_into_buffer("Enter choice: ",
-  cbuf,
-  m->timeout / 10);
+  cbuf, timeout);
 
if (readret >= 0) {
choice_item = menu_item_by_key(m, cbuf);
-- 
2.7.4

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


Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq

2018-05-23 Thread Bin Meng
Hi Christian,

On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner
 wrote:
> Fixes performance related issue when running vxWorks 5/7 images.

nits: vxWorks -> VxWorks

> The overall memory performance (L1, L2 cache and ram) was measured
> with Bandwidth [0].
>
> Without this patch we get following numbers:
>  - sequential 128-bit reads:  ~5.2 GB/s
>  - sequential 128-bit copy:   ~2.1 GB/s
>  - random 32-bit writes:  ~1.2 GB/s
>
> With this patch patch we get the following numbers:
>  - sequential 128-bit reads: ~18.0 GB/s
>  - sequential 128-bit copy:   ~9.5 GB/s
>  - random 32-bit writes:  ~5.0 GB/s
>
> [0] https://zsmith.co/bandwidth.html
>
> v1 -> v2:
>  - incorporate feedback from Bin Meng

This should not show in the commit message.

>
> Signed-off-by: Christian Gmeiner 
> ---
>  arch/x86/cpu/queensbay/Makefile |  2 +-
>  arch/x86/cpu/queensbay/cpu.c| 58 
> +
>  2 files changed, 59 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>
> diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
> index c0681995bd..3dd23465d4 100644
> --- a/arch/x86/cpu/queensbay/Makefile
> +++ b/arch/x86/cpu/queensbay/Makefile
> @@ -5,4 +5,4 @@
>  #
>
>  obj-y += fsp_configs.o irq.o
> -obj-y += tnc.o
> +obj-y += tnc.o cpu.o
> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
> new file mode 100644
> index 00..805a94cc27
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/cpu.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2018, Bachmann electronic GmbH
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void set_max_freq(void)
> +{
> +   msr_t msr;
> +
> +   /* Enable enhanced speed step */
> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
> +   msr.lo |= (1 << 16);
> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
> +
> +   /* Set new performance state */
> +   msr = msr_read(MSR_IA32_PERF_CTL);
> +   msr.lo = 0x101f;
> +   msr_write(MSR_IA32_PERF_CTL, msr);
> +}

I tried to find any documentation that describes the performance state
values of the TunnelCreek processor, but in vain. However when I read
the doc, I do have a question here:

The enhanced speedstep technology is set to disabled by the processor
after power-on, that means we don't need set the performance state
(P-state) via the MSR_IA32_PERF_CTL and the processor itself should
work under its maximum base frequency. So I believe this whole
set_max_freq() is not needed. Can you clarify this?

> +
> +static int cpu_x86_tunnelcreek_probe(struct udevice *dev)
> +{
> +   if (!ll_boot_init())
> +   return 0;
> +   debug("Init TunnelCreek core\n");
> +
> +   /* Set core to max frequency ratio */
> +   set_max_freq();
> +
> +   return 0;
> +}
> +
> +static const struct cpu_ops cpu_x86_tunnelcreek_ops = {
> +   .get_desc   = cpu_x86_get_desc,
> +   .get_count  = cpu_x86_get_count,
> +};
> +
> +static const struct udevice_id cpu_x86_tunnelcreek_ids[] = {
> +   { .compatible = "intel,tunnelcreek-cpu" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(cpu_x86_tunnelcreek_drv) = {
> +   .name   = "cpu_x86_tunnelcreek",
> +   .id = UCLASS_CPU,
> +   .of_match   = cpu_x86_tunnelcreek_ids,
> +   .bind   = cpu_x86_bind,
> +   .probe  = cpu_x86_tunnelcreek_probe,
> +   .ops= _x86_tunnelcreek_ops,
> +};
> --

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


Re: [U-Boot] mtd: spi-nor: new NXP FlexSPI driver location & framework to use ?

2018-05-23 Thread Prabhakar Kushwaha
HI Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Monday, May 21, 2018 8:36 PM
> To: Prabhakar Kushwaha 
> Cc: u-boot@lists.denx.de
> Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & framework to
> use ?
> 
> On Fri, May 18, 2018 at 3:46 PM, Prabhakar Kushwaha
>  wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Friday, May 18, 2018 11:54 AM
> >> To: Prabhakar Kushwaha 
> >> Cc: u-boot@lists.denx.de
> >> Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location & framework to
> use ?
> >>
> >> On Fri, May 18, 2018 at 10:31 AM, Prabhakar Kushwaha
> >>  wrote:
> >> > Dear Jagan,
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> Sent: Friday, May 18, 2018 10:24 AM
> >> >> To: Prabhakar Kushwaha 
> >> >> Cc: u-boot@lists.denx.de
> >> >> Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location &
> >> >> framework to use ?
> >> >>
> >> >> On Thu, May 17, 2018 at 4:49 PM, Prabhakar Kushwaha
> >> >>  wrote:
> >> >> > Dear Jagan,
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> >> >> >> Prabhakar Kushwaha
> >> >> >> Sent: Monday, May 14, 2018 6:55 PM
> >> >> >> To: Jagan Teki 
> >> >> >> Cc: u-boot@lists.denx.de
> >> >> >> Subject: Re: [U-Boot] mtd: spi-nor: new NXP FlexSPI driver
> >> >> >> location & framework to use ?
> >> >> >>
> >> >> >> Thanks Jagan,
> >> >> >>
> >> >> >> > -Original Message-
> >> >> >> > From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> >> > Sent: Friday, May 11, 2018 11:31 AM
> >> >> >> > To: Prabhakar Kushwaha 
> >> >> >> > Cc: Jagan Teki ; York Sun
> >> >> >> > ; Yogesh Narayan Gaur
> >> >> >> ;
> >> >> >> > Poonam Aggrwal ; Ashish Kumar
> >> >> >> > ; u- b...@lists.denx.de
> >> >> >> > Subject: Re: mtd: spi-nor: new NXP FlexSPI driver location &
> >> >> >> > framework to use ?
> >> >> >> >
> >> >> >> > On Fri, May 11, 2018 at 11:08 AM, Prabhakar Kushwaha
> >> >> >> >  wrote:
> >> >> >> > > Dear Jagan,
> >> >> >> > >
> >> >> >> > > NXP is coming up with new FlexSPI controller. It is similar
> >> >> >> > > to existing QSPI
> >> >> >> > with enhanced feature-set.
> >> >> >> > > We have the driver ready as per existing framework i.e.
> driver/spi.
> >> >> >> > >
> >> >> >> > > From recend discussion, we go to know about framework
> change.
> >> >> >> > > Migration of qspi drivers in
> >> >> >> > > u-boot-spi/drivers/mtd/spi-nor/
> >> >> >> > git://git.denx.de/u-boot-spi.git branch mtd-spinor-working.
> >> >> >> > >
> >> >> >> > > We are in dilemma for sending FlexSPI driver upstream.
> >> >> >> > > Do we follow existing framework i.e. driver/spi   or new
> proposed
> >> >> >> > framework i.e. u-boot-spi/drivers/mtd/spi-nor/
> >> >> >> > >
> >> >> >> > > Also, do we have any timeline of
> >> >> >> > > u-boot-spi/drivers/mtd/spi-nor/ to
> >> >> >> > become default.
> >> >> >> >
> >> >> >> > Idea is to move spi-nor, mtd-spinor-working is paused because
> >> >> >> > of non-dm drivers accessing.
> >> >> >>
> >> >> >> This means, flexspi controller driver should be upstream'ed via
> >> >> >> u-boot- spi/drivers/mtd/spi-nor branch mtd-spinor-working
> >> >> >>
> >> >> >
> >> >> > Please help me with the query.
> >> >> > We don’t want to end up with 2 FlexSPI drivers being posted in
> upstream.
> >> >>
> >> >> Let me understand is this FlexSPI is spi-nor controller, is it
> >> >> Linux upstreamed or ML?
> >> >
> >> > RFC patch
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpat
> >> chw
> >>
> ork.ozlabs.org%2Fpatch%2F894918%2F=02%7C01%7Cprabhakar.kushw
> ah
> >>
> a%40nxp.com%7C32aaec29f75b416004ec08d5bc87f8f1%7C686ea1d3bc2b4c6f
> >>
> a92cd99c5c301635%7C0%7C0%7C636622214533987461=%2F8i9vHtQF1
> >> S5Q6Bn65HVNPIMe%2FI6eSvP%2FKmKs1gxA8U%3D=0 is
> under
> >> discussion.
> >> > It is with assumption of driver/mtd/spi-nor
> >>
> >> Ohh, there is chance to move this to spi-mem is it?
> >>
> >> >
> >> >> I think for now you can add it mtd/spi with UCLASS_SPI_FLASH
> >> >> driver, Since Boris mentioned about spi-mem(I still need to see
> >> >> the Linux framework for more details) which may be re-placer for
> >> >> spi-nor but once we decided to go with spi-mem or spi-nor then the
> >> >> flexspi can convert
> >> accordingly.
> >> >>
> >> >
> >> > This means,  FlexSPI should be part of driver/mtd/spi-nor for now.
> >> > When You decide way forward(mtd/spi or spi-mem), flexSPI driver can
> >> > move
> >> accordingly.
> >>
> 

Re: [U-Boot] [PATCH 1/2] ARM: dts: exynos5: remove the duplicated nodes

2018-05-23 Thread Minkyu Kang
2018년 5월 23일 (수) 16:20, Minkyu Kang 님이 작성:

> Hi,
>
> 2018년 5월 16일 (수) 11:30, Minkyu Kang 님이 작성:
>
>>
>>
>> 2018년 5월 9일 (수) 12:53, Anand Moon 님이 작성:
>>
>>> Hi Jaehoon,
>>>
>>> On 12 January 2018 at 16:37, Jaehoon Chung 
>>> wrote:
>>> > Remove the duplicated gic and combiner nodes in exynos5.dtsi.
>>> >
>>> > Signed-off-by: Jaehoon Chung 
>>> > ---
>>> >  arch/arm/dts/exynos5.dtsi | 27 ---
>>> >  1 file changed, 27 deletions(-)
>>> >
>>> > diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi
>>> > index 8650800f52..8b725c0ddc 100644
>>> > --- a/arch/arm/dts/exynos5.dtsi
>>> > +++ b/arch/arm/dts/exynos5.dtsi
>>> > @@ -45,33 +45,6 @@
>>> > #size-cells = <0>;
>>> > };
>>> >
>>> > -   combiner: interrupt-controller@1044 {
>>> > -   compatible = "samsung,exynos4210-combiner";
>>> > -   #interrupt-cells = <2>;
>>> > -   interrupt-controller;
>>> > -   samsung,combiner-nr = <32>;
>>> > -   reg = <0x1044 0x1000>;
>>> > -   interrupts =<0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
>>> > -   <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
>>> > -   <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
>>> > -   <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
>>> > -   <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>,
>>> > -   <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>,
>>> > -   <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>,
>>> > -   <0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>;
>>> > -   };
>>> > -
>>> > -   gic: interrupt-controller@10481000 {
>>> > -   compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>>> > -   #interrupt-cells = <3>;
>>> > -   interrupt-controller;
>>> > -   reg =   <0x10481000 0x1000>,
>>> > -   <0x10482000 0x1000>,
>>> > -   <0x10484000 0x2000>,
>>> > -   <0x10486000 0x2000>;
>>> > -   interrupts = <1 9 0xf04>;
>>> > -   };
>>> > -
>>> > i2c_0: i2c@12C6 {
>>> > compatible = "samsung,s3c2440-i2c";
>>> > reg = <0x12C6 0x100>;
>>> > --
>>> > 2.15.1
>>> >
>>> > ___
>>> > U-Boot mailing list
>>> > U-Boot@lists.denx.de
>>> > https://lists.denx.de/listinfo/u-boot
>>>
>>> Looks like this series of patch is missing in u-boot git repository.
>>>
>>> Best Regards
>>> -Anand
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>
>>
>>
>> applied to u-boot-samsung.
>>
>
> I accepted this patch series, but I cannot push now since network problem
> in my office.
> So please wait few days more.
>

Done!

Thanks.


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


[U-Boot] [PATCH v2] gadget: f_thor: Fix memory leaks of usb request and its buffer

2018-05-23 Thread Seung-Woo Kim
There are memory leaks of usb request and its buffer for ep0,
in_ep, and out ep. Fix memory leaks of usb request and its buffer.

Signed-off-by: Seung-Woo Kim 
---
Change from v1
- remove allocation of out_ep request instead of allocating and freeing
- fix use error path instead of duplicated error handling code
---
 drivers/usb/gadget/f_thor.c |   45 ---
 1 file changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index c8eda05..02d6844 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -752,6 +752,13 @@ int thor_handle(void)
return 0;
 }
 
+static void free_ep_req(struct usb_ep *ep, struct usb_request *req)
+{
+   if (req->buf)
+   free(req->buf);
+   usb_ep_free_request(ep, req);
+}
+
 static int thor_func_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct usb_gadget *gadget = c->cdev->gadget;
@@ -860,21 +867,18 @@ static int thor_func_bind(struct usb_configuration *c, 
struct usb_function *f)
return 0;
 
  fail:
+   if (dev->req)
+   free_ep_req(gadget->ep0, dev->req);
free(dev);
return status;
 }
 
-static void free_ep_req(struct usb_ep *ep, struct usb_request *req)
-{
-   free(req->buf);
-   usb_ep_free_request(ep, req);
-}
-
 static void thor_unbind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_thor *f_thor = func_to_thor(f);
struct thor_dev *dev = f_thor->dev;
 
+   free_ep_req(dev->gadget->ep0, dev->req);
free(dev);
memset(thor_func, 0, sizeof(*thor_func));
thor_func = NULL;
@@ -895,8 +899,6 @@ static void thor_func_disable(struct usb_function *f)
}
 
if (dev->out_ep->driver_data) {
-   free(dev->out_req->buf);
-   dev->out_req->buf = NULL;
usb_ep_free_request(dev->out_ep, dev->out_req);
usb_ep_disable(dev->out_ep);
dev->out_ep->driver_data = NULL;
@@ -924,14 +926,13 @@ static int thor_eps_setup(struct usb_function *f)
 
result = usb_ep_enable(ep, d);
if (result)
-   goto exit;
+   goto err;
 
ep->driver_data = cdev; /* claim */
req = thor_start_ep(ep);
if (!req) {
-   usb_ep_disable(ep);
result = -EIO;
-   goto exit;
+   goto err_disable_in_ep;
}
 
dev->in_req = req;
@@ -941,22 +942,34 @@ static int thor_eps_setup(struct usb_function *f)
 
result = usb_ep_enable(ep, d);
if (result)
-   goto exit;
+   goto err_free_in_req;
 
ep->driver_data = cdev; /* claim */
-   req = thor_start_ep(ep);
+   req = usb_ep_alloc_request(ep, 0);
if (!req) {
-   usb_ep_disable(ep);
result = -EIO;
-   goto exit;
+   goto err_disable_out_ep;
}
 
+   req->complete = thor_rx_tx_complete;
dev->out_req = req;
/* ACM control EP */
ep = dev->int_ep;
ep->driver_data = cdev; /* claim */
 
- exit:
+   return 0;
+
+ err_disable_out_ep:
+   usb_ep_disable(dev->out_ep);
+
+ err_free_in_req:
+   free_ep_req(dev->in_ep, dev->in_req);
+   dev->in_req = NULL;
+
+ err_disable_in_ep:
+   usb_ep_disable(dev->in_ep);
+
+ err:
return result;
 }
 
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH v3 1/3] mmc: dwmmc: socfpga: Add reset ctrl to driver

2018-05-23 Thread Ley Foon Tan
On Mon, May 14, 2018 at 6:01 AM, Simon Glass  wrote:
> On 8 May 2018 at 13:19, Ley Foon Tan  wrote:
>> Add code to reset all reset signals as in mmc DT node. A reset property is 
>> an optional feature,
>> so only print out a warning and do not fail if a reset property is not 
>> present.
>>
>> If a reset property is discovered, then use it to deassert, thus bringing the
>> IP out of reset.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  drivers/mmc/socfpga_dw_mmc.c |   17 +
>>  1 files changed, 17 insertions(+), 0 deletions(-)
>
> Reviewed-by: Simon Glass 

Hi Jaehoon

Can you help to merge this patch?

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


Re: [U-Boot] [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory

2018-05-23 Thread Ken Ma
Hi Simon

Patman is very helpful and useful!
I have sent my patches v2 with patman.

Thanks a lot for your kind help!

Yours,
Ken

-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: 2018年5月24日 0:22
To: Ken Ma
Cc: U-Boot Mailing List; Stefan Roese; Wilson Ding; Nadav Haklai; Hua Jing
Subject: Re: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to 
drivers/ata directory

Hi Ken,

On 23 May 2018 at 01:06, Ken Ma  wrote:
> Dear Simon
>
> Thanks a lot for your kind help and review.
>
> Previously I did not use patman and generated my patches as below:
> 1. used "git mv arch/arm/mach-mvebu/sata.c drivers/ata/ahci_mvebu.c" to do 
> the file renaming with makefiles and Kconfig file updating.
> 2. After the 4 patches are all finished, I used "git format-patch -4 
> --cover-letter -o outgoing/sata" to generate the patch set with cover letter.
> 3. I used " git send-email --to u-boot@lists.denx.de outgoing/sata* --force" 
> to send out patches.
>
> And I try to use patman as your advice, I find that the patch generated by 
> "patman" can indicate the file "rename" relationship while the patch 
> generated by "git format-patch" can not.
> arch/arm/mach-mvebu/Makefile   | 1 -
> drivers/ata/Kconfig| 9 +
> drivers/ata/Makefile   | 1 +
> arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++---
> 4 files changed, 13 insertions(+), 4 deletions(-)
> rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%)
> …
> diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c
> similarity index 89%
> rename from arch/arm/mach-mvebu/sata.c
> rename to drivers/ata/ahci_mvebu.c
> index 5d8032b..5c1b293 100644
> --- a/arch/arm/mach-mvebu/sata.c
> +++ b/drivers/ata/ahci_mvebu.c
> @@ -1,15 +1,15 @@
>  /*
> + * Copyright (C) 2018 Marvell International Ltd.
>   * Copyright (C) 2016 Stefan Roese 
>   *
> - * SPDX-License-Identifier:GPL-2.0+
> + * SPDX-License-Identifier: GPL-2.0+
> + * https://spdx.org/licenses
>   */
>
>  #include 
>  #include 
>  #include 
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  /*
>   * Dummy implementation that can be overwritten by a board
>   * specific function
>
> But I failed to send out patches by patman as below, it says " Alias 'ata' 
> not found ".
> ken@mshsrv05:~/git_ken/u-boot/u-boot$ tools/patman/patman -c4
> Cleaned 4 patches
> 0 errors, 1 warnings, 0 checks for 
> 0001-ata-mvebu-move-mvebu-sata-driver-to-drivers-ata-dire.patch:
> :0: warning: added, moved or deleted file(s), does 
> MAINTAINERS need updating?
>
> checkpatch.pl found 0 error(s), 1 warning(s), 0 checks(s)
> Traceback (most recent call last):
>   File "tools/patman/patman", line 161, in 
> options.add_maintainers)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/series.py", line 
> 231, in MakeCcFile
> raise_on_error=raise_on_error)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", 
> line 326, in BuildEmailList
> raw += LookupEmail(item, alias, raise_on_error=raise_on_error)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", 
> line 503, in LookupEmail
> raise ValueError(msg)
> ValueError: Alias 'ata' not found
>
>
> Thanks a lot for your kind help!

You can use the -t flag to ignore the missing alias.

Regards,
Simon

>
> Yours,
> Ken
>
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2018年5月23日 7:30
> To: Ken Ma
> Cc: U-Boot Mailing List; Stefan Roese
> Subject: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to 
> drivers/ata directory
>
> External Email
>
> --
> Hi Ken,
>
> On 17 May 2018 at 19:27,   wrote:
>> From: Ken Ma 
>>
>> Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this
>> patch moves it to drivers/ata directory with renaming "sata.c" to
>> "ahci_mvebu.c" which is aligned to Linux.
>> New ahci driver's kconfig option is added as AHCI_MVEBU which selects
>> DM_SCSI.
>>
>> Signed-off-by: Ken Ma 
>> Cc: Simon Glass 
>> Cc: Stefan Roese 
>> ---
>>  arch/arm/mach-mvebu/Makefile |  1 -
>>  arch/arm/mach-mvebu/sata.c   | 54 
>> 
>>  drivers/ata/Kconfig  |  9 
>>  drivers/ata/Makefile |  1 +
>>  drivers/ata/ahci_mvebu.c | 54 
>> 
>>  5 

Re: [U-Boot] [PATCH v3 2/3] serial: ns16550: Add reset ctrl to driver

2018-05-23 Thread Ley Foon Tan
On Tue, May 8, 2018 at 11:19 AM, Ley Foon Tan  wrote:
> Add code to reset all reset signals as in serial DT node. A reset property is 
> an optional feature,
> so do not fail if a reset property is not present.
>
> If a reset property is discovered, then use it to deassert, thus bringing the
> IP out of reset.
>
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Marek Vasut 
> ---
>  drivers/serial/ns16550.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 53550bf..9c80090 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -177,6 +178,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
>  #if defined(CONFIG_ARCH_OMAP2PLUS)
> serial_out(0x7, _port->mdr1);   /* mode select reset 
> TL16C750*/
>  #endif
> +
> serial_out(UART_MCRVAL, _port->mcr);
> serial_out(ns16550_getfcr(com_port), _port->fcr);
> if (baud_divisor != -1)
> @@ -370,6 +372,12 @@ static int ns16550_serial_setbrg(struct udevice *dev, 
> int baudrate)
>  int ns16550_serial_probe(struct udevice *dev)
>  {
> struct NS16550 *const com_port = dev_get_priv(dev);
> +   struct reset_ctl_bulk reset_bulk;
> +   int ret;
> +
> +   ret = reset_get_bulk(dev, _bulk);
> +   if (!ret)
> +   reset_deassert_bulk(_bulk);
>
> com_port->plat = dev_get_platdata(dev);
> NS16550_init(com_port, -1);
> --
> 1.7.1
>

Hi Tom

Can you help to merge this patch if okay with this patch?

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


Re: [U-Boot] [PATCH v3 3/3] net: designware: Add reset ctrl to driver

2018-05-23 Thread Ley Foon Tan
On Wed, May 16, 2018 at 5:08 AM, Joe Hershberger  wrote:
> On Mon, May 7, 2018 at 10:19 PM, Ley Foon Tan  wrote:
>> Add code to reset all reset signals as in Ethernet DT node. A reset property 
>> is an optional feature,
>> so only print out a warning and do not fail if a reset property is not 
>> present.
>>
>> If a reset property is discovered, then use it to deassert, thus bringing the
>> IP out of reset.
>>
>> Signed-off-by: Ley Foon Tan 
>
> Acked-by: Joe Hershberger 

Hi Joe

Will you merge this patch to mainline?

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


[U-Boot] [PATCH v2 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory

2018-05-23 Thread make
From: Ken Ma 

Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this
patch moves it to drivers/ata directory with renaming "sata.c" to
"ahci_mvebu.c" which is aligned to Linux.
New ahci driver's kconfig option is added as AHCI_MVEBU which selects
DM_SCSI.

Signed-off-by: Ken Ma 
---

Changes in v2:
- Add MAINTAINERS updating

 MAINTAINERS| 1 +
 arch/arm/mach-mvebu/Makefile   | 1 -
 drivers/ata/Kconfig| 9 +
 drivers/ata/Makefile   | 1 +
 arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++---
 5 files changed, 14 insertions(+), 4 deletions(-)
 rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 077828c..97c0752 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -134,6 +134,7 @@ S:  Maintained
 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
 
 ARM MARVELL PXA
 M: Marek Vasut 
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index d4210af..7f0d692 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -9,7 +9,6 @@ ifdef CONFIG_ARM64
 obj-$(CONFIG_ARMADA_3700) += armada3700/
 obj-$(CONFIG_ARMADA_8K) += armada8k/
 obj-y += arm64-common.o
-obj-y += sata.o
 
 else # CONFIG_ARM64
 
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 86ec628..9ef4589 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -99,4 +99,13 @@ config SATA_SIL3114
help
  Enable this driver to support the SIL3114 SATA controllers.
 
+config AHCI_MVEBU
+   bool "Marvell EBU AHCI SATA support"
+   depends on ARCH_MVEBU
+   select DM_SCSI
+   help
+ This option enables support for the Marvell EBU SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
 endmenu
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a94c804..0254640 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_SATA_MV) += sata_mv.o
 obj-$(CONFIG_SATA_SIL3114) += sata_sil3114.o
 obj-$(CONFIG_SATA_SIL) += sata_sil.o
 obj-$(CONFIG_SANDBOX) += sata_sandbox.o
+obj-$(CONFIG_AHCI_MVEBU) += ahci_mvebu.o
diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c
similarity index 89%
rename from arch/arm/mach-mvebu/sata.c
rename to drivers/ata/ahci_mvebu.c
index 5d8032b..5c1b293 100644
--- a/arch/arm/mach-mvebu/sata.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -1,15 +1,15 @@
 /*
+ * Copyright (C) 2018 Marvell International Ltd.
  * Copyright (C) 2016 Stefan Roese 
  *
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier: GPL-2.0+
+ * https://spdx.org/licenses
  */
 
 #include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /*
  * Dummy implementation that can be overwritten by a board
  * specific function
-- 
1.9.1

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


[U-Boot] [PATCH v2 0/4] ahci mvebu driver updates

2018-05-23 Thread make
From: Ken Ma 


These patches move ahci mvebu driver to drivers/ata directory with bug
fixing and scsi supporting.

Changes in v2:
- Add MAINTAINERS updating

David Sniatkiwicz (1):
  ata: ahci_mvebu: a8040 a0: remove bad port register offsets
workarounds

Ken Ma (3):
  ata: mvebu: move mvebu sata driver to drivers/ata directory
  ata: ahci_mvebu: add scsi support
  arm64: mvebu: defconfig: enable CONFIG_AHCI_MVEBU

 MAINTAINERS|  1 +
 arch/arm/mach-mvebu/Makefile   |  1 -
 configs/mvebu_db-88f3720_defconfig |  1 +
 configs/mvebu_db_armada8k_defconfig|  1 +
 configs/mvebu_espressobin-88f3720_defconfig|  1 +
 configs/mvebu_mcbin-88f8040_defconfig  |  1 +
 drivers/ata/Kconfig|  9 
 drivers/ata/Makefile   |  1 +
 .../mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c  | 25 ++
 9 files changed, 31 insertions(+), 10 deletions(-)
 rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (63%)

-- 
1.9.1

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


[U-Boot] [PATCH v2 4/4] arm64: mvebu: defconfig: enable CONFIG_AHCI_MVEBU

2018-05-23 Thread make
From: Ken Ma 

This patch enables the new ahci mvebu driver for marvell arm64 platform
SOCs(A3k and A8k).

Signed-off-by: Ken Ma 
---

Changes in v2: None

 configs/mvebu_db-88f3720_defconfig  | 1 +
 configs/mvebu_db_armada8k_defconfig | 1 +
 configs/mvebu_espressobin-88f3720_defconfig | 1 +
 configs/mvebu_mcbin-88f8040_defconfig   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/mvebu_db-88f3720_defconfig 
b/configs/mvebu_db-88f3720_defconfig
index 1d6233a..d40dd42 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_MAC_PARTITION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_BLOCK_CACHE=y
 CONFIG_DM_GPIO=y
 # CONFIG_MVEBU_GPIO is not set
diff --git a/configs/mvebu_db_armada8k_defconfig 
b/configs/mvebu_db_armada8k_defconfig
index da67aad..72c86f3 100644
--- a/configs/mvebu_db_armada8k_defconfig
+++ b/configs/mvebu_db_armada8k_defconfig
@@ -30,6 +30,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_MAC_PARTITION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_BLOCK_CACHE=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index 314d405..cc41711 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_MAC_PARTITION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_BLOCK_CACHE=y
 CONFIG_DM_I2C=y
 CONFIG_MISC=y
diff --git a/configs/mvebu_mcbin-88f8040_defconfig 
b/configs/mvebu_mcbin-88f8040_defconfig
index e16a56e..dea0cd0 100644
--- a/configs/mvebu_mcbin-88f8040_defconfig
+++ b/configs/mvebu_mcbin-88f8040_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_MAC_PARTITION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_BLOCK_CACHE=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
-- 
1.9.1

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


[U-Boot] [PATCH v2 3/4] ata: ahci_mvebu: add scsi support

2018-05-23 Thread make
From: Ken Ma 

Mvebu AHCI is AHCI driver which uses SCSI under the hood.
This patch adjusts AHCI setup to support SCSI by creating
a SCSI device as a child.

Signed-off-by: Ken Ma 
---

Changes in v2: None

 drivers/ata/ahci_mvebu.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index 97a04d9..9041a72 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -19,6 +19,20 @@ __weak int board_ahci_enable(void)
return 0;
 }
 
+static int mvebu_ahci_bind(struct udevice *dev)
+{
+   struct udevice *scsi_dev;
+   int ret;
+
+   ret = ahci_bind_scsi(dev, _dev);
+   if (ret) {
+   debug("%s: Failed to bind (err=%d\n)", __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int mvebu_ahci_probe(struct udevice *dev)
 {
/*
@@ -27,7 +41,7 @@ static int mvebu_ahci_probe(struct udevice *dev)
 */
board_ahci_enable();
 
-   ahci_init(devfdt_get_addr_ptr(dev));
+   ahci_probe_scsi(dev, (ulong)devfdt_get_addr_ptr(dev));
 
return 0;
 }
@@ -42,5 +56,6 @@ U_BOOT_DRIVER(ahci_mvebu_drv) = {
.name   = "ahci_mvebu",
.id = UCLASS_AHCI,
.of_match   = mvebu_ahci_ids,
+   .bind   = mvebu_ahci_bind,
.probe  = mvebu_ahci_probe,
 };
-- 
1.9.1

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


[U-Boot] [PATCH v2 2/4] ata: ahci_mvebu: a8040 a0: remove bad port register offsets workarounds

2018-05-23 Thread make
From: David Sniatkiwicz 

This workaround was added for A8040/7040 A0.
A8040/7040 A0 is no longer supported so this workaround
can be removed.

Signed-off-by: David Sniatkiwicz 
Signed-off-by: Ken Ma 
---

Changes in v2: None

 drivers/ata/ahci_mvebu.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index 5c1b293..97a04d9 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -19,14 +19,6 @@ __weak int board_ahci_enable(void)
return 0;
 }
 
-#ifdef CONFIG_ARMADA_8K
-/* CP110 has different AHCI port addresses */
-void __iomem *ahci_port_base(void __iomem *base, u32 port)
-{
-   return base + 0x1 + (port * 0x1);
-}
-#endif
-
 static int mvebu_ahci_probe(struct udevice *dev)
 {
/*
-- 
1.9.1

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


[U-Boot] [PATCH 2/4] riscv: dts: Support cfi flash

2018-05-23 Thread Andes
From: Rick Chen 

Add nor node for cfi-flash driver and smc node
for smc(aftsmc020) controller.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/dts/ae350.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/riscv/dts/ae350.dts b/arch/riscv/dts/ae350.dts
index f7d4190..be72b5c 100644
--- a/arch/riscv/dts/ae350.dts
+++ b/arch/riscv/dts/ae350.dts
@@ -117,6 +117,18 @@
 interrupt-parent = <>;
   };
 
+  smc0: smc@e040 {
+compatible = "andestech,atfsmc020";
+reg = <0x0 0xe040 0x0 0x1000>;
+  };
+
+  nor@0,0 {
+compatible = "cfi-flash";
+reg = <0x0 0x8800 0x0 0x1000>;
+bank-width = <2>;
+device-width = <1>;
+  };
+
   spi: spi@f0b0 {
 compatible = "andestech,atcspi200";
 reg = <0x0 0xf0b0 0x0 0x1000>;
-- 
2.7.4

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


[U-Boot] [PATCH 4/4] mtd: ftsmc020: Drop unsed code

2018-05-23 Thread Andes
From: Rick Chen 

ftsmc020_init is not used anymore.
So it can be removed.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 drivers/mtd/Makefile   |  1 -
 drivers/mtd/ftsmc020.c | 38 --
 2 files changed, 39 deletions(-)
 mode change 100644 => 100755 drivers/mtd/Makefile
 delete mode 100644 drivers/mtd/ftsmc020.c

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
old mode 100644
new mode 100755
index 20c0d0a..c4ffbe3
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
 obj-$(CONFIG_ALTERA_QSPI) += altera_qspi.o
 obj-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o
 obj-$(CONFIG_FLASH_CFI_MTD) += cfi_mtd.o
-obj-$(CONFIG_FTSMC020) += ftsmc020.o
 obj-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o
 obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o
 obj-$(CONFIG_FLASH_PIC32) += pic32_flash.o
diff --git a/drivers/mtd/ftsmc020.c b/drivers/mtd/ftsmc020.c
deleted file mode 100644
index e2e8082..000
--- a/drivers/mtd/ftsmc020.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * (C) Copyright 2009 Faraday Technology
- * Po-Yu Chuang 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-
-struct ftsmc020_config {
-   unsigned intconfig;
-   unsigned inttiming;
-};
-
-static void ftsmc020_setup_bank(unsigned int bank, struct ftsmc020_config *cfg)
-{
-   struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE;
-
-   if (bank > 3) {
-   printf("bank # %u invalid\n", bank);
-   return;
-   }
-
-   writel(cfg->config, >bank[bank].cr);
-   writel(cfg->timing, >bank[bank].tpr);
-}
-
-void ftsmc020_init(void)
-{
-   struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS;
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(config); i++)
-   ftsmc020_setup_bank(i, [i]);
-}
-- 
2.7.4

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


[U-Boot] [PATCH 3/4] board: ax25-ae350: Support cfi flash

2018-05-23 Thread Andes
From: Rick Chen 

Add smc_init() to get register base from dts and
deal with atfsmc020 controler initialzation job.

Write protect is enabled by default. So WP shall
be disabled when startup, then cfi flash can be
detected and erasing and writing can be executed.

Adp-ae3xx and adp-ag101p both do smc initilize job
in lowlevel_init.S and get register base fron
CONFIG_FTSMC020_BASE. They also can be moved those
codes to board stage. Remind them as todo jobs.
After that CONFIG_FTSMC020_BASE can be removed.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 board/AndesTech/ax25-ae350/ax25-ae350.c | 34 +
 1 file changed, 34 insertions(+)

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index d2e9bcb..ffec1e1 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -11,6 +11,8 @@
 #include 
 #endif
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -73,3 +75,35 @@ void *board_fdt_blob_setup(void)
 
return (void *)CONFIG_SYS_FDT_BASE;
 }
+
+int smc_init(void)
+{
+   int node = -1;
+   const char *compat = "andestech,atfsmc020";
+   void *blob = (void *)gd->fdt_blob;
+   fdt_addr_t addr;
+   struct ftsmc020_bank *regs;
+
+   node = fdt_node_offset_by_compatible(blob, -1, compat);
+   if (node < 0)
+   return -FDT_ERR_NOTFOUND;
+
+   addr = fdtdec_get_addr(blob, node, "reg");
+
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   regs = (struct ftsmc020_bank *)addr;
+   regs->cr &= ~FTSMC020_BANK_WPROT;
+
+   return 0;
+}
+
+#ifdef CONFIG_BOARD_EARLY_INIT_F
+int board_early_init_f(void)
+{
+   smc_init();
+
+   return 0;
+}
+#endif
-- 
2.7.4

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


[U-Boot] [PATCH 1/4] configs: ax25-ae350: Support cfi flash

2018-05-23 Thread Andes
From: Rick Chen 

Enable cfi flash driver and setup flash
parameters to support parallel nor flash
which type is JS28F00A-M29EWH.

Verification:
Size detection, data read, erase and write are all ok.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 configs/ax25-ae350_defconfig |  5 +
 include/configs/ax25-ae350.h | 38 ++
 2 files changed, 43 insertions(+)
 mode change 100644 => 100755 include/configs/ax25-ae350.h

diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
index 4ceccb7..59919b8 100644
--- a/configs/ax25-ae350_defconfig
+++ b/configs/ax25-ae350_defconfig
@@ -4,8 +4,10 @@ CONFIG_DEFAULT_DEVICE_TREE="ae350"
 CONFIG_TARGET_AX25_AE350=y
 CONFIG_FIT=y
 CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
 # CONFIG_AUTO_COMPLETE is not set
 CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_CMD_IMLS=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SF_TEST=y
@@ -25,6 +27,9 @@ CONFIG_MMC=y
 CONFIG_DM_MMC=y
 CONFIG_FTSDC010=y
 CONFIG_FTSDC010_SDIO=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_CFI_FLASH=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
old mode 100644
new mode 100755
index a90c75a..8ce3e6c
--- a/include/configs/ax25-ae350.h
+++ b/include/configs/ax25-ae350.h
@@ -80,6 +80,44 @@
 #define CONFIG_SYS_MEMTEST_START   PHYS_SDRAM_0
 #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_0 + PHYS_SDRAM_0_SIZE)
 
+/*
+ * FLASH and environment organization
+ */
+
+/* use CFI framework */
+#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_FLASH_CFI_DRIVER
+
+#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT
+#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
+#define CONFIG_SYS_CFI_FLASH_STATUS_POLL
+
+/* support JEDEC */
+#ifdef CONFIG_CFI_FLASH
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT  1
+#endif/* Do not use CONFIG_FLASH_CFI_LEGACY to detect on board flash */
+#define PHYS_FLASH_1   0x8800  /* BANK 0 */
+#define CONFIG_SYS_FLASH_BASE  PHYS_FLASH_1
+#define CONFIG_SYS_FLASH_BANKS_LIST{ PHYS_FLASH_1, }
+#define CONFIG_SYS_MONITOR_BASEPHYS_FLASH_1
+
+#define CONFIG_SYS_FLASH_ERASE_TOUT12  /* TO for Flash Erase (ms) */
+#define CONFIG_SYS_FLASH_WRITE_TOUT500 /* TO for Flash Write (ms) */
+
+/* max number of memory banks */
+/*
+ * There are 4 banks supported for this Controller,
+ * but we have only 1 bank connected to flash on board
+*/
+#ifndef CONFIG_SYS_MAX_FLASH_BANKS_DETECT
+#define CONFIG_SYS_MAX_FLASH_BANKS 1
+#endif
+#define CONFIG_SYS_FLASH_BANKS_SIZES {0x400}
+
+/* max number of sectors on one chip */
+#define CONFIG_FLASH_SECTOR_SIZE   (0x1*2)
+#define CONFIG_SYS_MAX_FLASH_SECT  512
+
 /* environments */
 #define CONFIG_ENV_SPI_BUS 0
 #define CONFIG_ENV_SPI_CS  0
-- 
2.7.4

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


Re: [U-Boot] [PATCH v3 00/10] Add Intel Stratix 10 SoC support

2018-05-23 Thread Ley Foon Tan
On Wed, May 23, 2018 at 6:00 PM, Marek Vasut  wrote:
> On 05/23/2018 06:17 PM, Ley Foon Tan wrote:
>> This is 3rd version of patchset to adds support for Intel Stratix 10 SoC.
>> This patchset is work on top of uboot.git/master and patchset in [1].
>>
>> Changes:
>> - rebase on uboot.git/master
>> - update reviewed-by
>>
>> Patchset history:
>> [v1]: https://patchwork.ozlabs.org/cover/900499/
>> [v2]: https://patchwork.ozlabs.org/cover/916060/
>>
>> [1]: https://patchwork.ozlabs.org/cover/910018/
>
> Applied, thanks
>
> --

Thanks!

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


Re: [U-Boot] [U-Boot-DM] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support

2018-05-23 Thread Andreas Dannenberg
Vabhav, Simon,

On Wed, May 23, 2018 at 12:55:41PM -0600, Simon Glass wrote:
> Hi,
> 
> On 23 May 2018 at 12:04, Simon Glass  wrote:
> > On 23 May 2018 at 11:56, Vabhav Sharma  wrote:
> >> Hello Everyone,
> >>
> >> I am working on integrating  generic PL011 driver in u-boot and linux for
> 
> Note, it is 'U-Boot'
> 
> >> ARMv8 NXP SoC and facing issue with multiple UART console enablement in
> >> u-boot using DM model
> >>
> >> Kindly provide your valuable feedback and experts comments.
> >>
> >>
> >>
> >> DTS require stdout-path(e.g-UART0) to the /chosen device tree node
> >> ,Accordingly controller(UART0) is probed/initialized as boot console
> >>
> >> On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for
> >> linux boot but kernel hangs after “Starting kernel ... print”
> >>
> >>
> >>
> >> After debugging it’s found that UART1 is not initialized and single(first)
> >> controller is  probed/initialized in u-boot (Irrespective of 4 UART nodes
> >> are enabled in dts)
> >>
> >> In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT
> >> stdout-path or CONFIG_CONS_INDEX or platform data(first index)
> >>
> >>
> >>
> >> Does the u-boot DM model support only one or multiple UART driver
> >> probing/initialization? Is there any configuration parameter required to
> >> define number of UART controllers to be probed/initialized.
> >>
> >> This looks limitation as same boot console is used for u-boot and linux and
> >> unable to use all available UART controllers.
> >>
> >>
> >>
> >> I am new to u-boot and please correct any misunderstanding
> >>
> >> Let me know If I can submit a patch for multiple UART probe in 
> >> serial-uclass
> >> or open a bug for multiple UART support in u-boot DM model
> 
> You can probe additional serial drivers if you like. U-Boot only
> probes things in a 'lazy' manner so far. Perhaps you could submit a
> patch which probes all serial devices? That is just a case of using
> uclass_first_device()...uclass_next_device() to iterate through them.
> I suppose we could have a CONFIG option to enable this.

That would indeed be useful. I was facing a similar issue of having to
initialize multiple UARTs, and ended up probing additional instances
manually from the board file using the respective DM functions
(unreleased code). Not pretty but it worked. I'll be happy to test such
a patch if created.


--
Andreas Dannenberg
Texas Instruments Inc


 
> >>
> >>
> >>
> >> PS:I am unable to find owner of serial uclass driver from MAINTAINERS file
> 
> Not guilty but I did port a lot of things to driver model.
> 
> >>
> >>
> >>
> >> Regards,
> >>
> >> Vabhav
> >>
> >>
> 
> Regards,
> Simon
> ___
> U-Boot-DM mailing list
> u-boot...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] watchdog: driver support for layerscape

2018-05-23 Thread Xiaoliang Yang
Hi york,

Yes, I sent it two days ago, but it's failed to send to u-boot list, so I 
resend it.

Xiaoliang Yang

-Original Message-
From: York Sun 
Sent: 2018年5月24日 6:58
To: Xiaoliang Yang ; u-boot@lists.denx.de
Subject: Re: [PATCH 1/2] watchdog: driver support for layerscape

On 05/23/2018 12:52 AM, Xiaoliang Yang wrote:
> Support watchdog driver for layerscape. If you want to use it, please 
> define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG, define 
> CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout.
> 
> Signed-off-by: Xiaoliang Yang 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |   10 ++
>  drivers/watchdog/Makefile  |2 +-
>  drivers/watchdog/imx_watchdog.c|   11 +++
>  3 files changed, 22 insertions(+), 1 deletions(-)
> 

Isn't this the same as you sent two days ago?

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


Re: [U-Boot] [PATCH] ehci: msm: Replace board_prepare_usb with board_usb_init

2018-05-23 Thread Ramon Fried
On Wed, May 23, 2018 at 2:30 AM, Simon Glass  wrote:
> Hi Ramon,
> On 20 May 2018 at 13:04, Ramon Fried  wrote:
>> Use standard board_usb_init() instead of the specific board_prepare_usb.
>
> You should mention why...
>
> For any patch:
> - what the problem is / motivation
> - what your patch does
Sure, thanks.
I'll resend the updated patch shortly.
Thanks,
Ramon
>
>>
>> Signed-off-by: Ramon Fried 
>> ---
>>  board/qualcomm/dragonboard410c/dragonboard410c.c |  4 ++--
>>  drivers/usb/host/ehci-msm.c  | 11 ---
>>  2 files changed, 6 insertions(+), 9 deletions(-)
>>
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2018-05-23 Thread Thomas Fitzsimmons
Add support for loading U-Boot on the Broadcom 7445 SoC.  This port
assumes Broadcom's BOLT bootloader is acting as the second stage
bootloader, and U-Boot is acting as the third stage bootloader, loaded
as an ELF program by BOLT.

Signed-off-by: Thomas Fitzsimmons 
Cc: Stefan Roese 
Cc: Tom Rini 
Cc: Florian Fainelli 
---
Changes for v2:
   - Reorganize Kconfig to create ARCH_BCMSTB
   - Use generic bcmstb SoC name wherever possible
   - Eliminate crt0.S changes by moving relocation logic to bcmstb.c
   - Use debug() macro where appropriate
   - Read bcmstb_spi register base addresses from prior stage device
 tree, where possible
   - Read bcmstb_sdhci register base address from prior stage DT
   - Make timer register addresses configurable
   - Fix BOLT typos
   - Eliminate CONFIG_BCMSTB_ACCOMMODATE_STBLINUX by keeping FIT
 initramfs and device tree binary in-place
   - Add README.bcm7xxx
   - Read memory configuration from prior stage device tree
   - Add CONFIG_OF_PRIOR_STAGE support in spi-uclass.c
   - Fix issues reported by checkpatch.pl
   - Fix issues reported by sparse
   - Update some comments and formatting
   - Add a MAINTAINERS file

 arch/arm/Kconfig|  12 +
 arch/arm/Makefile   |   1 +
 arch/arm/mach-bcmstb/Kconfig|  64 
 arch/arm/mach-bcmstb/Makefile   |   9 +
 arch/arm/mach-bcmstb/include/mach/gpio.h|  12 +
 arch/arm/mach-bcmstb/include/mach/hardware.h|  12 +
 arch/arm/mach-bcmstb/include/mach/prior_stage.h |  31 ++
 arch/arm/mach-bcmstb/include/mach/sdhci.h   |  16 +
 arch/arm/mach-bcmstb/include/mach/timer.h   |  14 +
 arch/arm/mach-bcmstb/lowlevel_init.S|  22 ++
 board/broadcom/bcmstb/MAINTAINERS   |   6 +
 board/broadcom/bcmstb/Makefile  |   9 +
 board/broadcom/bcmstb/bcmstb.c  | 192 +++
 configs/bcm7445_defconfig   |  27 ++
 doc/README.bcm7xxx  | 147 
 drivers/mmc/Kconfig |  11 +
 drivers/mmc/Makefile|   1 +
 drivers/mmc/bcmstb_sdhci.c  |  68 
 drivers/spi/Kconfig |   7 +
 drivers/spi/Makefile|   1 +
 drivers/spi/bcmstb_spi.c| 440 
 drivers/spi/spi-uclass.c|   2 +-
 dts/Kconfig |   7 +
 include/configs/bcmstb.h| 189 ++
 include/fdtdec.h|   4 +
 lib/fdtdec.c|   4 +
 26 files changed, 1307 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-bcmstb/Kconfig
 create mode 100644 arch/arm/mach-bcmstb/Makefile
 create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h
 create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S
 create mode 100644 board/broadcom/bcmstb/MAINTAINERS
 create mode 100644 board/broadcom/bcmstb/Makefile
 create mode 100644 board/broadcom/bcmstb/bcmstb.c
 create mode 100644 configs/bcm7445_defconfig
 create mode 100644 doc/README.bcm7xxx
 create mode 100644 drivers/mmc/bcmstb_sdhci.c
 create mode 100644 drivers/spi/bcmstb_spi.c
 create mode 100644 include/configs/bcmstb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9bd70f4..fa3089f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -498,6 +498,16 @@ config TARGET_VEXPRESS_CA15_TC2
select CPU_V7_HAS_VIRT
select PL011_SERIAL
 
+config ARCH_BCMSTB
+   bool "Broadcom BCM7XXX family"
+   select CPU_V7
+   select DM
+   select OF_CONTROL
+   select OF_PRIOR_STAGE
+   help
+ This enables support for Broadcom ARM-based set-top box
+ chipsets, including the 7445 family of chips.
+
 config TARGET_VEXPRESS_CA5X2
bool "Support vexpress_ca5x2"
select CPU_V7
@@ -1237,6 +1247,8 @@ source "arch/arm/mach-at91/Kconfig"
 
 source "arch/arm/mach-bcm283x/Kconfig"
 
+source "arch/arm/mach-bcmstb/Kconfig"
+
 source "arch/arm/mach-davinci/Kconfig"
 
 source "arch/arm/mach-exynos/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4fa8b38..b0cd152 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -53,6 +53,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
 machine-$(CONFIG_ARCH_ASPEED)  += aspeed
 machine-$(CONFIG_ARCH_AT91)+= at91
 machine-$(CONFIG_ARCH_BCM283X) += bcm283x
+machine-$(CONFIG_ARCH_BCMSTB)  += bcmstb
 machine-$(CONFIG_ARCH_DAVINCI) += davinci
 

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

2018-05-23 Thread Thomas Fitzsimmons
Add support for Broadcom BCM7445

Changes for v2:
   - Reorganize Kconfig to create ARCH_BCMSTB
   - Use generic bcmstb SoC name wherever possible
   - Eliminate crt0.S changes by moving relocation logic to bcmstb.c
   - Use debug() macro where appropriate
   - Read bcmstb_spi register base addresses from prior stage device
 tree, where possible
   - Read bcmstb_sdhci register base address from prior stage DT
   - Make timer register addresses configurable
   - Fix BOLT typos
   - Eliminate CONFIG_BCMSTB_ACCOMMODATE_STBLINUX by keeping FIT
 initramfs and device tree binary in-place
   - Add README.bcm7xxx
   - Read memory configuration from prior stage device tree
   - Add CONFIG_OF_PRIOR_STAGE support in spi-uclass.c
   - Fix issues reported by checkpatch.pl
   - Fix issues reported by sparse
   - Update some comments and formatting
   - Add a MAINTAINERS file

Thomas Fitzsimmons (1):
  board: arm: Add support for Broadcom BCM7445

 arch/arm/Kconfig|  12 +
 arch/arm/Makefile   |   1 +
 arch/arm/mach-bcmstb/Kconfig|  64 
 arch/arm/mach-bcmstb/Makefile   |   9 +
 arch/arm/mach-bcmstb/include/mach/gpio.h|  12 +
 arch/arm/mach-bcmstb/include/mach/hardware.h|  12 +
 arch/arm/mach-bcmstb/include/mach/prior_stage.h |  31 ++
 arch/arm/mach-bcmstb/include/mach/sdhci.h   |  16 +
 arch/arm/mach-bcmstb/include/mach/timer.h   |  14 +
 arch/arm/mach-bcmstb/lowlevel_init.S|  22 ++
 board/broadcom/bcmstb/MAINTAINERS   |   6 +
 board/broadcom/bcmstb/Makefile  |   9 +
 board/broadcom/bcmstb/bcmstb.c  | 192 +++
 configs/bcm7445_defconfig   |  27 ++
 doc/README.bcm7xxx  | 147 
 drivers/mmc/Kconfig |  11 +
 drivers/mmc/Makefile|   1 +
 drivers/mmc/bcmstb_sdhci.c  |  68 
 drivers/spi/Kconfig |   7 +
 drivers/spi/Makefile|   1 +
 drivers/spi/bcmstb_spi.c| 440 
 drivers/spi/spi-uclass.c|   2 +-
 dts/Kconfig |   7 +
 include/configs/bcmstb.h| 189 ++
 include/fdtdec.h|   4 +
 lib/fdtdec.c|   4 +
 26 files changed, 1307 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-bcmstb/Kconfig
 create mode 100644 arch/arm/mach-bcmstb/Makefile
 create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h
 create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h
 create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S
 create mode 100644 board/broadcom/bcmstb/MAINTAINERS
 create mode 100644 board/broadcom/bcmstb/Makefile
 create mode 100644 board/broadcom/bcmstb/bcmstb.c
 create mode 100644 configs/bcm7445_defconfig
 create mode 100644 doc/README.bcm7xxx
 create mode 100644 drivers/mmc/bcmstb_sdhci.c
 create mode 100644 drivers/spi/bcmstb_spi.c
 create mode 100644 include/configs/bcmstb.h

-- 
1.8.3.1

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


[U-Boot] [PATCH 2/2] mmc: ftsdc010_mci: Sync compatible with DT mmc node

2018-05-23 Thread Andes
From: Rick Chen 

The compatible string of ftsdc010_mci.c is different from
the mmc driver in Linux Kernel. Modify it for consistency.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 drivers/mmc/ftsdc010_mci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c
index 9de3a15..f98472c 100644
--- a/drivers/mmc/ftsdc010_mci.c
+++ b/drivers/mmc/ftsdc010_mci.c
@@ -464,7 +464,7 @@ int ftsdc010_mmc_bind(struct udevice *dev)
 }
 
 static const struct udevice_id ftsdc010_mmc_ids[] = {
-   { .compatible = "andestech,atsdc010" },
+   { .compatible = "andestech,atfsdc010" },
{ }
 };
 
-- 
2.7.4

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


[U-Boot] [PATCH 1/2] riscv: dts: Sync DT with Linux Kernel

2018-05-23 Thread Andes
From: Rick Chen 

Use same dts to boot U-Boot and RISC-V
Linux Kernel v4.16-rc2 in ax25-ae350 platform.

Signed-off-by: Rick Chen 
Signed-off-by: Rick Chen 
Cc: Greentime Hu 
---
 arch/riscv/dts/ae350.dts | 204 ---
 1 file changed, 122 insertions(+), 82 deletions(-)

diff --git a/arch/riscv/dts/ae350.dts b/arch/riscv/dts/ae350.dts
index 4bfb876..f7d4190 100644
--- a/arch/riscv/dts/ae350.dts
+++ b/arch/riscv/dts/ae350.dts
@@ -1,97 +1,137 @@
 /dts-v1/;
+
 / {
-   compatible = "riscv32 ax25";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   interrupt-parent = <>;
+  #address-cells = <2>;
+  #size-cells = <2>;
+  compatible = "andestech,ax25";
+  model = "andestech,ax25";
+
+  aliases {
+uart0 = 
+spi0 = 
+  } ;
+
+  chosen {
+bootargs = "console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf030 
debug loglevel=7";
+stdout-path = "uart0:38400n8";
+  };
 
-   aliases {
-   uart0 = 
-   ethernet0 = 
-   spi0 = 
-   } ;
+  cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+timebase-frequency = <1000>;
+CPU0: cpu@0 {
+  device_type = "cpu";
+  reg = <0>;
+  status = "okay";
+  compatible = "riscv";
+  riscv,isa = "rv64imafdc";
+  mmu-type = "riscv,sv39";
+  clock-frequency = <6000>;
+  CPU0_intc: interrupt-controller {
+#interrupt-cells = <1>;
+interrupt-controller;
+compatible = "riscv,cpu-intc";
+  };
+};
+  };
 
-   chosen {
-   bootargs = "console=ttyS0,38400n8 
earlyprintk=uart8250-32bit,0xf030 debug loglevel=7";
-   stdout-path = "uart0:38400n8";
-   tick-timer = 
-   };
+  memory@0 {
+device_type = "memory";
+reg = <0x0 0x 0x0 0x4000>;
+  };
 
-   memory@0 {
-   device_type = "memory";
-   reg = <0x 0x4000>;
-   };
+  soc {
+#address-cells = <2>;
+#size-cells = <2>;
+compatible = "andestech,riscv-ae350-soc";
+ranges;
+  };
 
-   spiclk: virt_100mhz {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <1>;
-   };
+  plmt0@e600 {
+compatible = "riscv,plmt0";
+interrupts-extended = <_intc 7>;
+reg = <0x0 0xe600 0x0 0x10>;
+  };
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   cpu@0 {
-   compatible = "andestech,n13";
-   reg = <0>;
-   /* FIXME: to fill correct frqeuency */
-   clock-frequency = <6000>;
-   };
-   };
+  plic0: interrupt-controller@e400 {
+compatible = "riscv,plic0";
+#address-cells = <2>;
+#interrupt-cells = <2>;
+interrupt-controller;
+reg = <0x0 0xe400 0x0 0x200>;
+riscv,ndev=<31>;
+interrupts-extended = <_intc 11 _intc 9>;
+  };
 
-   intc: interrupt-controller {
-   compatible = "andestech,atnointc010";
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   };
+  plic1: interrupt-controller@e640 {
+compatible = "riscv,plic1";
+#address-cells = <2>;
+#interrupt-cells = <2>;
+interrupt-controller;
+reg = <0x0 0xe640 0x0 0x40>;
+riscv,ndev=<1>;
+interrupts-extended = <_intc 3>;
+  };
 
-   serial0: serial@f030 {
-   compatible = "andestech,uart16550", "ns16550a";
-   reg = <0xf030 0x1000>;
-   interrupts = <7 4>;
-   clock-frequency = <19660800>;
-   reg-shift = <2>;
-   reg-offset = <32>;
-   no-loopback-test = <1>;
-   };
+  spiclk: virt_100mhz {
+#clock-cells = <0>;
+compatible = "fixed-clock";
+clock-frequency = <1>;
+  };
 
-   timer0: timer@f040 {
-   compatible = "andestech,atcpit100";
-   reg = <0xf040 0x1000>;
-   interrupts = <2 4>;
-   clock-frequency = <4000>;
-   };
+  timer0: timer@f040 {
+compatible = "andestech,atcpit100";
+reg = <0x0 0xf040 0x0 0x1000>;
+clock-frequency = <4000>;
+interrupts = <3 4>;
+interrupt-parent = <>;
+  };
 
-   mac0: mac@e010 {
-   compatible = "andestech,atmac100";
-   reg = <0xe010 0x1000>;
-   interrupts = <25 4>;
-   };
+  serial0: serial@f030 {
+compatible = "andestech,uart16550", "ns16550a";
+reg = <0x0 0xf030 0x0 0x1000>;
+interrupts = <9 4>;
+clock-frequency = <19660800>;
+reg-shift = <2>;
+reg-offset = <32>;
+no-loopback-test = <1>;
+interrupt-parent = <>;
+  };
 
-   mmc0: mmc@f0e0 {
-   compatible = 

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

2018-05-23 Thread Thomas Fitzsimmons
Tom Rini  writes:

> On Sun, May 06, 2018 at 07:09:22AM -0400, Thomas Fitzsimmons wrote:
>
>> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
>> assumes Broadcom's BOLT bootloader is acting as the second stage
>> bootloader, and U-Boot is acting as the third stage bootloader, loaded
>> as an ELF program by BOLT.
>> 
>> Signed-off-by: Thomas Fitzsimmons 
>> Cc: Stefan Roese 
> [snip]
>> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
>> index fa81317..f1a6f35 100644
>> --- a/arch/arm/lib/crt0.S
>> +++ b/arch/arm/lib/crt0.S
>> @@ -94,6 +94,7 @@ ENTRY(_main)
>>   * 'here' but relocated.
>>   */
>>  
>> +#if !defined(CONFIG_OF_PRIOR_STAGE)
>>  ldr r0, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
>>  bic r0, r0, #7  /* 8-byte alignment for ABI compliance */
>>  mov sp, r0
>> @@ -108,6 +109,7 @@ ENTRY(_main)
>>  #endif
>>  ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */
>>  b   relocate_code
>> +#endif
>>  here:
>>  /*
>>   * now relocate vectors
>
> Can you explain this bit a good bit more?

When BOLT loads U-Boot as an ELF program, this relocation code hangs --
I haven't found out why yet -- but if I skip the relocation, U-Boot runs
successfully.  I figured out a different approach to preventing the
relocation, one that only requires logic in an SoC-specific file, so v2
of the patch will not have any crt0.S changes.

>> +config BCHP_BSPI_MAST_N_BOOT_CTRL
>> +hex ""
>> +default 0x003e3208
>
> Doing hex "" seems wrong.  What are you doing here exactly?

I've reorganized all these into more appropriate locations, and
documented all the remaining Kconfig items, which you'll see in the v2
patch I'll post shortly.

>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index 66a313e..f07dfe3 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -242,11 +242,13 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
>> initrd_end)
>>  }
>>  }
>>  
>> +#if !defined(CONFIG_BCMSTB_ACCOMMODATE_STBLINUX)
>>  err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
>>  if (err < 0) {
>>  printf("fdt_initrd: %s\n", fdt_strerror(err));
>>  return err;
>>  }
>> +#endif
>
> Why do we need this?

The background is that stblinux is designed to use some physical memory
for Linux itself, and leave the rest of physical memory for direct use
by video decode blocks in the SoC.

Basically, without making accommodations for it in U-Boot, stblinux will
allocate less memory for use by the video decode blocks than is actually
available, even if it could safely allocate more.

In v2 of the patch, I've documented a different approach to loading FIT
images (one that keeps the RFS and DTB in-place), which eliminates the
need for this configuration macro.

>> +#ifdef DEBUG
>> +static int debug_tx_rx;
>> +#define D(fmt, args...) debug_cond(debug_tx_rx, fmt, ##args)
>> +#else
>> +#define D(fmt, args...)
>> +#endif
>
> We have dbg() etc, please use.  Thanks!

OK, done in v2 of the patch.

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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread Marek Vasut
On 05/23/2018 10:51 PM, DATACOM - Paulo.Zaneti wrote:
> 
> 
> On 23/05/2018 15:00, Marek Vasut wrote:
>> On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
>>>
>>> On 23/05/2018 14:43, Marek Vasut wrote:
 On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
> On 23/05/2018 14:03, Marek Vasut wrote:
>> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
>>> Hi,
>> Hi,
>>
>>> When trying to migrate a board from u-boot version 2016.09 to
>>> version
>>> 2018.03, I found a problem with a USB 2.0 device which used to
>>> work on
>>> version 2016.09.
>> Does it still happen in u-boot/master ?
> Yes, it still happens.
>
> I just tested it with the following commit:
> dca268a .travis.yml: Further optimizations
>>> In u-boot version 2016.09 the device appears like this:
>>>
>>> 2: Mass Storage,  USB Revision 2.0
>>> - SanDisk Cruzer Blade 200443243002FB509E64
 Let me guess, is this a DWC2-based host ? You didn't mention which SoC
 or USB controller it is.

 Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
 DWC2 has problems with those sandisk sticks.
>>> No, it is a NXP T1024 SoC.
>>> Do you think it may be a problem with the SoC or NXP USB host driver ?
>>>
>> So that's chipidea ? That one should be reasonably sane.
> I don't think so. It uses following drivers:
>   drivers/usb/host/ehci-fsl.c
>   drivers/usb/host/ehci-hcd.c

Should be chipidea IP.

>> Submit the patch you had in mind and let's see what happens.
> I just noticed that this stick needs more time after the
> usb_set_address() call.
> I increased the mdelay(10) to mdelay(20) and the "usb start" command
> worked.
> But the problem is that I am still not convinced that this should be the
> solution.

Try setenv usb_pgood_delay 1 ; usb reset then ?

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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread Bin Meng
Hi,

On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti
 wrote:
>
>
> On 23/05/2018 15:00, Marek Vasut wrote:
>>
>> On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
>>>
>>>
>>> On 23/05/2018 14:43, Marek Vasut wrote:

 On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
>
> On 23/05/2018 14:03, Marek Vasut wrote:
>>
>> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
>>>
>>> Hi,
>>
>> Hi,
>>
>>> When trying to migrate a board from u-boot version 2016.09 to version
>>> 2018.03, I found a problem with a USB 2.0 device which used to work
>>> on
>>> version 2016.09.
>>
>> Does it still happen in u-boot/master ?
>
> Yes, it still happens.
>
> I just tested it with the following commit:
> dca268a .travis.yml: Further optimizations
>>>
>>> In u-boot version 2016.09 the device appears like this:
>>>
>>> 2: Mass Storage,  USB Revision 2.0
>>> - SanDisk Cruzer Blade 200443243002FB509E64

 Let me guess, is this a DWC2-based host ? You didn't mention which SoC
 or USB controller it is.

 Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
 DWC2 has problems with those sandisk sticks.
>>>
>>> No, it is a NXP T1024 SoC.
>>> Do you think it may be a problem with the SoC or NXP USB host driver ?
>>>
>> So that's chipidea ? That one should be reasonably sane.
>
> I don't think so. It uses following drivers:
>   drivers/usb/host/ehci-fsl.c
>   drivers/usb/host/ehci-hcd.c
>
>>
>> Submit the patch you had in mind and let's see what happens.
>
> I just noticed that this stick needs more time after the usb_set_address()
> call.
> I increased the mdelay(10) to mdelay(20) and the "usb start" command worked.
> But the problem is that I am still not convinced that this should be the
> solution.
>

Agreed. Can you bisect to see which commit broke your stick?

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


Re: [U-Boot] [PATCH 1/2] watchdog: driver support for layerscape

2018-05-23 Thread York Sun
On 05/23/2018 12:52 AM, Xiaoliang Yang wrote:
> Support watchdog driver for layerscape. If you want to use it,
> please define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG,
> define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout.
> 
> Signed-off-by: Xiaoliang Yang 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |   10 ++
>  drivers/watchdog/Makefile  |2 +-
>  drivers/watchdog/imx_watchdog.c|   11 +++
>  3 files changed, 22 insertions(+), 1 deletions(-)
> 

Isn't this the same as you sent two days ago?

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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread DATACOM - Paulo.Zaneti



On 23/05/2018 15:00, Marek Vasut wrote:

On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:


On 23/05/2018 14:43, Marek Vasut wrote:

On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:

On 23/05/2018 14:03, Marek Vasut wrote:

On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:

Hi,

Hi,


When trying to migrate a board from u-boot version 2016.09 to version
2018.03, I found a problem with a USB 2.0 device which used to work on
version 2016.09.

Does it still happen in u-boot/master ?

Yes, it still happens.

I just tested it with the following commit:
dca268a .travis.yml: Further optimizations

In u-boot version 2016.09 the device appears like this:

2: Mass Storage,  USB Revision 2.0
    - SanDisk Cruzer Blade 200443243002FB509E64

Let me guess, is this a DWC2-based host ? You didn't mention which SoC
or USB controller it is.

Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
DWC2 has problems with those sandisk sticks.

No, it is a NXP T1024 SoC.
Do you think it may be a problem with the SoC or NXP USB host driver ?


So that's chipidea ? That one should be reasonably sane.

I don't think so. It uses following drivers:
  drivers/usb/host/ehci-fsl.c
  drivers/usb/host/ehci-hcd.c



Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the 
usb_set_address() call.

I increased the mdelay(10) to mdelay(20) and the "usb start" command worked.
But the problem is that I am still not convinced that this should be the 
solution.




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


Re: [U-Boot] [PATCH] dlmalloc: ensure gd is set for early free

2018-05-23 Thread Eugeniu Rosca
Hi Stephen,

On Wed, May 23, 2018 at 01:32:53PM -0600, Stephen Warren wrote:
> On 05/23/2018 01:07 PM, Eugeniu Rosca wrote:
> >This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc:
> >ensure gd is set for early alloc"). Here is a gdb backtrace to make them
> >look even more similar (sandbox build):
> ...
> >Interestingly, this issue appears on a very old v2015.04 U-boot, but
> >not on u-boot/master (even if the fix applies cleanly to u-boot/master).
> >With the patch applied, my ancient u-boot starts to work properly:
> 
> That's probably because of 2f0bcd4de1ab0cb03f01428a334cd91f8870504c "malloc:
> use hidden visibility" which prevents code outside of U-Boot from using
> U-Boot's malloc/free?

This fixes my issue in apparently much cleaner way. Thanks! The break
down of sandbox into phases is very informative. Like the comments/code
ratio.

> (I only remember this because I very recently bisected an issue in an old
> branch that caused sandbox crashes after upgrading the OS on a test machine
> and triggering the bug that commit fixes.)

Thanks again!

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


[U-Boot] [PATCH] mmc: Unirqify bcm2835_sdhost and fix writes

2018-05-23 Thread Alexander Graf
The bcm2835 sdhost driver has a problem with "write multiple" commands.
It seems to boil down to the fact that the controller dislikes its FIFO
to get drained at the end of a block when a write multiple blocks command
is in flight.

The easy fix is to simply get rid of all the IRQ driven logic and make
the driver push as much data into the FIFO as it can. That way we never
drain and we never run into the problem.

Reported-by: Jan Leonhardt 
Signed-off-by: Alexander Graf 
---
 drivers/mmc/bcm2835_sdhost.c | 265 ---
 1 file changed, 47 insertions(+), 218 deletions(-)

diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
index 96428333b0..1ce019af57 100644
--- a/drivers/mmc/bcm2835_sdhost.c
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -163,7 +163,6 @@ struct bcm2835_host {
int clock;  /* Current clock speed */
unsigned intmax_clk;/* Max possible freq */
unsigned intblocks; /* remaining PIO blocks */
-   int irq;/* Device IRQ */
 
u32 ns_per_fifo_word;
 
@@ -173,14 +172,7 @@ struct bcm2835_host {
 
struct mmc_cmd  *cmd;   /* Current command */
struct mmc_data *data;  /* Current data request */
-   booldata_complete:1;/* Data finished before cmd */
booluse_busy:1; /* Wait for busy interrupt */
-   boolwait_data_complete:1;   /* Wait for data */
-
-   /* for threaded irq handler */
-   boolirq_block;
-   boolirq_busy;
-   boolirq_data;
 
struct udevice  *dev;
struct mmc  *mmc;
@@ -240,17 +232,9 @@ static void bcm2835_reset_internal(struct bcm2835_host 
*host)
writel(host->cdiv, host->ioaddr + SDCDIV);
 }
 
-static int bcm2835_finish_command(struct bcm2835_host *host);
-
-static void bcm2835_wait_transfer_complete(struct bcm2835_host *host)
+static int bcm2835_wait_transfer_complete(struct bcm2835_host *host)
 {
-   int timediff;
-   u32 alternate_idle;
-
-   alternate_idle = (host->data->flags & MMC_DATA_READ) ?
-   SDEDM_FSM_READWAIT : SDEDM_FSM_WRITESTART1;
-
-   timediff = 0;
+   int timediff = 0;
 
while (1) {
u32 edm, fsm;
@@ -261,7 +245,10 @@ static void bcm2835_wait_transfer_complete(struct 
bcm2835_host *host)
if ((fsm == SDEDM_FSM_IDENTMODE) ||
(fsm == SDEDM_FSM_DATAMODE))
break;
-   if (fsm == alternate_idle) {
+
+   if ((fsm == SDEDM_FSM_READWAIT) ||
+   (fsm == SDEDM_FSM_WRITESTART1) ||
+   (fsm == SDEDM_FSM_READDATA)) {
writel(edm | SDEDM_FORCE_DATA_MODE,
   host->ioaddr + SDEDM);
break;
@@ -273,9 +260,11 @@ static void bcm2835_wait_transfer_complete(struct 
bcm2835_host *host)
"wait_transfer_complete - still waiting after 
%d retries\n",
timediff);
bcm2835_dumpregs(host);
-   return;
+   return -ETIMEDOUT;
}
}
+
+   return 0;
 }
 
 static int bcm2835_transfer_block_pio(struct bcm2835_host *host, bool is_read)
@@ -322,6 +311,9 @@ static int bcm2835_transfer_block_pio(struct bcm2835_host 
*host, bool is_read)
  fsm_state != SDEDM_FSM_READCRC)) ||
(!is_read &&
 (fsm_state != SDEDM_FSM_WRITEDATA &&
+ fsm_state != SDEDM_FSM_WRITEWAIT1 &&
+ fsm_state != SDEDM_FSM_WRITEWAIT2 &&
+ fsm_state != SDEDM_FSM_WRITECRC &&
  fsm_state != SDEDM_FSM_WRITESTART1 &&
  fsm_state != SDEDM_FSM_WRITESTART2))) {
hsts = readl(host->ioaddr + SDHSTS);
@@ -358,9 +350,8 @@ static int bcm2835_transfer_pio(struct bcm2835_host *host)
 
is_read = (host->data->flags & MMC_DATA_READ) != 0;
ret = bcm2835_transfer_block_pio(host, is_read);
-
-   if (host->wait_data_complete)
-   bcm2835_wait_transfer_complete(host);
+   if (ret)
+   return ret;
 
sdhsts = readl(host->ioaddr + SDHSTS);
if (sdhsts & (SDHSTS_CRC16_ERROR |
@@ -379,21 +370,8 @@ static int bcm2835_transfer_pio(struct bcm2835_host *host)
return ret;
 }
 
-static void bcm2835_set_transfer_irqs(struct bcm2835_host *host)
-{
-   u32 all_irqs = SDHCFG_DATA_IRPT_EN | SDHCFG_BLOCK_IRPT_EN |
-   SDHCFG_BUSY_IRPT_EN;
-
-   host->hcfg = (host->hcfg & ~all_irqs) |
-   

Re: [U-Boot] [PATCH] dlmalloc: ensure gd is set for early free

2018-05-23 Thread Stephen Warren

On 05/23/2018 01:07 PM, Eugeniu Rosca wrote:

This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc:
ensure gd is set for early alloc"). Here is a gdb backtrace to make them
look even more similar (sandbox build):

...

Interestingly, this issue appears on a very old v2015.04 U-boot, but
not on u-boot/master (even if the fix applies cleanly to u-boot/master).
With the patch applied, my ancient u-boot starts to work properly:


That's probably because of 2f0bcd4de1ab0cb03f01428a334cd91f8870504c 
"malloc: use hidden visibility" which prevents code outside of U-Boot 
from using U-Boot's malloc/free?


(I only remember this because I very recently bisected an issue in an 
old branch that caused sandbox crashes after upgrading the OS on a test 
machine and triggering the bug that commit fixes.)

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


[U-Boot] [PATCH] dlmalloc: ensure gd is set for early free

2018-05-23 Thread Eugeniu Rosca
This fix seems to be a twin of v2015.01 commit 854d2b9753e4 ("dlmalloc:
ensure gd is set for early alloc"). Here is a gdb backtrace to make them
look even more similar (sandbox build):

(gdb) run
Starting program: /path/to/u-boot
[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.
0x004123c0 in free (mem=0x0) at common/dlmalloc.c:2460
2460  if (mem == NULL)  /* free(0) has no 
effect */
(gdb) where
 #0  0x004123c0 in free (mem=0x0) at common/dlmalloc.c:2460
 #1  0x73f46cea in ?? () from /lib/x86_64-linux-gnu/libselinux.so.1
 #2  0x77de76ba in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0x7fffd928, env=env@entry=0x7fffd938) at dl-init.c:72
 #3  0x77de77cb in call_init (env=0x7fffd938, argv=0x7fffd928, 
argc=1, l=) at dl-init.c:30
 #4  _dl_init (main_map=0x77ffe168, argc=1, argv=0x7fffd928, 
env=0x7fffd938) at dl-init.c:120
 #5  0x77dd7c6a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
 #6  0x0001 in ?? ()
 #7  0x7fffddbb in ?? ()
 #8  0x in ?? ()

Interestingly, this issue appears on a very old v2015.04 U-boot, but
not on u-boot/master (even if the fix applies cleanly to u-boot/master).
With the patch applied, my ancient u-boot starts to work properly:

$ ./u-boot

U-Boot 2015.04-00280-g5755c9e48b83 (May 23 2018 - 20:53:31)

DRAM:  128 MiB
Using default environment

In:serial
Out:   lcd
Err:   lcd
=>

Signed-off-by: Eugeniu Rosca 
---
 common/dlmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index b395eefbf862..6012f9f162c0 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1524,7 +1524,7 @@ void fREe(mem) Void_t* mem;
 
 #if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* free() is a no-op - all the memory will be freed on relocation */
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
return;
 #endif
 
-- 
2.17.0

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


Re: [U-Boot] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support

2018-05-23 Thread Simon Glass
Hi,

On 23 May 2018 at 12:04, Simon Glass  wrote:
> On 23 May 2018 at 11:56, Vabhav Sharma  wrote:
>> Hello Everyone,
>>
>> I am working on integrating  generic PL011 driver in u-boot and linux for

Note, it is 'U-Boot'

>> ARMv8 NXP SoC and facing issue with multiple UART console enablement in
>> u-boot using DM model
>>
>> Kindly provide your valuable feedback and experts comments.
>>
>>
>>
>> DTS require stdout-path(e.g-UART0) to the /chosen device tree node
>> ,Accordingly controller(UART0) is probed/initialized as boot console
>>
>> On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for
>> linux boot but kernel hangs after “Starting kernel ... print”
>>
>>
>>
>> After debugging it’s found that UART1 is not initialized and single(first)
>> controller is  probed/initialized in u-boot (Irrespective of 4 UART nodes
>> are enabled in dts)
>>
>> In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT
>> stdout-path or CONFIG_CONS_INDEX or platform data(first index)
>>
>>
>>
>> Does the u-boot DM model support only one or multiple UART driver
>> probing/initialization? Is there any configuration parameter required to
>> define number of UART controllers to be probed/initialized.
>>
>> This looks limitation as same boot console is used for u-boot and linux and
>> unable to use all available UART controllers.
>>
>>
>>
>> I am new to u-boot and please correct any misunderstanding
>>
>> Let me know If I can submit a patch for multiple UART probe in serial-uclass
>> or open a bug for multiple UART support in u-boot DM model

You can probe additional serial drivers if you like. U-Boot only
probes things in a 'lazy' manner so far. Perhaps you could submit a
patch which probes all serial devices? That is just a case of using
uclass_first_device()...uclass_next_device() to iterate through them.
I suppose we could have a CONFIG option to enable this.

>>
>>
>>
>> PS:I am unable to find owner of serial uclass driver from MAINTAINERS file

Not guilty but I did port a lot of things to driver model.

>>
>>
>>
>> Regards,
>>
>> Vabhav
>>
>>

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


Re: [U-Boot] [PATCH] sunxi: allow CONFIG_DEFAULT_FDT_FILE override

2018-05-23 Thread Martin Kelly

On 05/17/2018 05:01 AM, Maxime Ripard wrote:

On Tue, May 01, 2018 at 05:46:41PM -0700, Martin Kelly wrote:

Currently, sunxi-common.h ignores CONFIG_DEFAULT_FDT_FILE and assumes
the kernel fdtfile and the u-boot devicetree names are the same.
Although this is typically the case, sometimes you might want to
customize one of these differently, so it's useful to allow them to be
different.

Add logic in sunxi-common.h to respect CONFIG_DEFAULT_FDT_FILE, if set,
and default to the values it currently uses.

Signed-off-by: Martin Kelly 


Acked-by: Maxime Ripard 

Maxime



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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread DATACOM - Paulo.Zaneti



On 23/05/2018 14:43, Marek Vasut wrote:

On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:


On 23/05/2018 14:03, Marek Vasut wrote:

On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:

Hi,

Hi,


When trying to migrate a board from u-boot version 2016.09 to version
2018.03, I found a problem with a USB 2.0 device which used to work on
version 2016.09.

Does it still happen in u-boot/master ?

Yes, it still happens.

I just tested it with the following commit:
dca268a .travis.yml: Further optimizations

In u-boot version 2016.09 the device appears like this:

2: Mass Storage,  USB Revision 2.0
   - SanDisk Cruzer Blade 200443243002FB509E64

Let me guess, is this a DWC2-based host ? You didn't mention which SoC
or USB controller it is.

Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
DWC2 has problems with those sandisk sticks.

No, it is a NXP T1024 SoC.
Do you think it may be a problem with the SoC or NXP USB host driver ?

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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread DATACOM - Paulo.Zaneti



On 23/05/2018 14:03, Marek Vasut wrote:

On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:

Hi,

Hi,


When trying to migrate a board from u-boot version 2016.09 to version
2018.03, I found a problem with a USB 2.0 device which used to work on
version 2016.09.

Does it still happen in u-boot/master ?

Yes, it still happens.

I just tested it with the following commit:
dca268a .travis.yml: Further optimizations



In u-boot version 2016.09 the device appears like this:

2: Mass Storage,  USB Revision 2.0
  - SanDisk Cruzer Blade 200443243002FB509E64
  - Class: (from Interface) Mass Storage
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x0781  Product 0x5567 Version 1.38
    Configuration: 1
    - Interfaces: 1 Bus Powered 200mA
  Interface: 0
  - Alternate Setting 0, Endpoints: 2
  - Class Mass Storage, Transp. SCSI, Bulk only
  - Endpoint 1 In Bulk MaxPacket 512
  - Endpoint 2 Out Bulk MaxPacket 512


But in version 2018.03 I just can't start usb. It fails with following
error:

=> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
unable to get device descriptor (error=-1)
1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
    scanning usb for storage devices... 0 Storage Device(s) found


I did a "git bisect" and found that this problem is related to the
following commit:

c008faa usb: Only get 64 bytes device descriptor for full speed devices

I am not an expert on USB, so I would like to ask for help on this issue.

In u-boot v2018.03, file common/usb.c, line 973, shouldn't the
comparison be like this:

     if (do_read && dev->speed >= USB_SPEED_FULL) {

or, at list:

     if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed ==
USB_SPEED_HIGH)) {


I would submit a patch for this, but I lack on USB knowledge for
explaining the patch.





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


Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0

2018-05-23 Thread Manjukumar Harthikote Matha


> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Wednesday, May 23, 2018 2:49 AM
> To: Manjukumar Harthikote Matha ; Rajan Vaja
> 
> Cc: mon...@monstr.eu; Albert Aribaud ; Jolly Shah
> ; Michal Simek ; u-
> b...@lists.denx.de; Moritz Fischer 
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/22/2018 06:44 PM, Manjukumar Harthikote Matha wrote:
> [...]
> >> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1
> >> (the one on github, not the one on git.yoctoproject) without version
> >> which provides the ABI 1.0 rather than the v2017.03 one from
> >> meta-xilinx rel-v2018.1. And then the new release of meta-xilinx
> >> rel-v2018.2 will get PMUFW v2018.1 .
> >>
> >> But why is such vital component as the working PMUFW recipe stashed
> >> in some other repo than meta-xilinx , while meta-xilinx contains a
> >> non working one is not clear to me. Anyway.
> >>
> >
> > Release branches in github are related to Xilinx tools release to
> > support PetaLinux, xsct etc The flow using github release uses a layer
> > stack and how to use is documented here
> >
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct
> o
> > and manifest is here
> > https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1
> >
> > We don’t support a flow where you use only one layer instead of the entire
> stack.
> 
> Then the obvious question is, why is it not a single metalayer ...
> 

The proposal was sent out, there are dependencies on why the merge has not 
happened 
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-November/003309.html

We plan to resolve in the next release (Thud)

> >> It is also becoming less and less clear to me which PMUFW provides
> >> which ABI based on the recipe versions, since they do not reflect the
> >> ABI in any way. And, back to my original question-ish, there is an
> >> ABI break between PMUFW v0.3 and PMUFW v1.0 which may render systems
> >> unbootable if everything is not updated in tandem, right ?
> >>
> >
> > I was not aware of the breakage, I will have to check.
> 
> Try using mainline U-Boot 2018.05 with PMUFW v0.3 and load FPGA image from
> U-Boot, it'll fail.
> 
> > If you use our entire layer stack for rel-v2018.1 (manifest) then you 
> > shouldn’t
> see the issue.
> >
> > As far as master branch is considred, we are in process of updating it for 
> > sumo
> release.
> > If you are on mailing list, you will see the patches sent for review and is 
> > on 4th
> version.
> > We hope to get it merged if there are no hiccups by end of week.
> > See :
> > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.h
> > tml
> > See:
> > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.h
> > tml
> 
> Great
> 
>  btw I presume you do mean OpenEmbedded.
> 
> >>>
> >>>
> >>> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> >>>
> >>>
> >> So it's this pmu-firmware_git recipe which provides different ABI
> >> in different versions of meta-xilinx-bsp, yet this is not in any
> >> way indicated by the package version, right ?
> >
> > Didn’t get what you mean here? Package version is set according to
> > the release under use
> > https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xs
> > ctap
> > p.bbclass#L9
> 
>  Ah, I see, so unlike any other regular recipe which encodes the
>  version in the recipe file name, Xilinx stuff has custom class
>  which is inherited into version-
> >> less
>  recipe and sets the version. This is horrid.
> 
> >>>
> >>> Not true, any recipe which includes version can be in an include
> >>> file or in a class
> >> or in a conf file.
> >>> There is no strict guidelines on where this version should be set
> >>> (recipe, include,
> >> conf or class).
> >>> Just because you are familiar with one way of doing things, does not
> >>> mean
> >> everything else is horrid.
> >>
> >> Well, I think I've seen my share of recipes over the years, both good
> >> and bad. OE gives the user a lot of freedom to do all kinds of hacks,
> >> which still doesn't mean it's a good idea to do them.
> >>
> >> Writing your own bbclass as a sort-of header file to be included by a
> >> recipe is one of the bad ideas. With the ABI break at hand, there is
> >> also no migration strategy for this PMUFW recipe, the platform just
> >> breaks during the update and stops booting or misbehaves, which is 
> >> grueling.
> >>
> >
> > The same class is shared for multiple components, FSBL, DTG etc hence
> > the reasoning to use a class However, this something for us to consider and
> work in future releases.
> 
> This seems to be long overdue
>

Debatable according to me.
 
> > This should indicate, release version with a part of commit id of
> > git being
> >> 

[U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread DATACOM - Paulo.Zaneti

Hi,

When trying to migrate a board from u-boot version 2016.09 to version 
2018.03, I found a problem with a USB 2.0 device which used to work on 
version 2016.09.


In u-boot version 2016.09 the device appears like this:

2: Mass Storage,  USB Revision 2.0
 - SanDisk Cruzer Blade 200443243002FB509E64
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0781  Product 0x5567 Version 1.38
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 In Bulk MaxPacket 512
 - Endpoint 2 Out Bulk MaxPacket 512


But in version 2018.03 I just can't start usb. It fails with following 
error:


=> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
unable to get device descriptor (error=-1)
1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found


I did a "git bisect" and found that this problem is related to the 
following commit:


c008faa usb: Only get 64 bytes device descriptor for full speed devices

I am not an expert on USB, so I would like to ask for help on this issue.

In u-boot v2018.03, file common/usb.c, line 973, shouldn't the 
comparison be like this:


    if (do_read && dev->speed >= USB_SPEED_FULL) {

or, at list:

    if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == 
USB_SPEED_HIGH)) {



I would submit a patch for this, but I lack on USB knowledge for 
explaining the patch.


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


Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler

2018-05-23 Thread Moore, Robert


> -Original Message-
> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: Wednesday, May 23, 2018 3:30 AM
> To: Bin Meng 
> Cc: Simon Glass ; U-Boot Mailing List  b...@lists.denx.de>; Moore, Robert ; Sami
> Mujawar ; Evan Lloyd 
> Subject: Re: [PATCH v1] x86: acpi: Adopt new version of iASL compiler
> 
> On Wed, 2018-05-23 at 18:22 +0800, Bin Meng wrote:
> > Hi Andy,
> >
> > On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenko
> >  wrote:
> > > The commit
> > >
> > >   f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file
> > > in C)")
> > >
[Moore, Robert] 

This change was requested by a customer, and it seemed quite reasonable to us. 
Sorry for any inconvenience.

Bob





> > > in ACPICA project changed a template of the a of variable that is
> > > used
> >
> > a template of the a of variable? Cannot understand this.
> 
> "a template of the variable"
> 
> >
> > > in the generated C-file. Now, instead of hard coded "AmlCode" the
> > > "%s_aml_code" is in use, where the prefix is a lowered case base
> > > name of the output file. In our case it will be "dsdt" producing a
> > > name as "dsdt_aml_code".
> > >
> > > The quick solution is to call sed which replaces new name by the old
> > > one to keep compatibility with old version of iASL.
> > >
> > > The long term solution would be to modify code to use the new name
> > > because it more scalable.
> >
> > it *is* more scalable.
> 
> Yes, thanks.
> 
> >
> > >
> > > Cc: Robert Moore 
> > > Cc: Sami Mujawar 
> > > Cc: Evan Lloyd 
> > > Signed-off-by: Andy Shevchenko 
> > > ---
> > >  scripts/Makefile.lib | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index
> > > f9809ce7ce..b5cf7e5427 100644
> > > --- a/scripts/Makefile.lib
> > > +++ b/scripts/Makefile.lib
> > > @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \
> > >
> > >  $(obj)/dsdt.c:$(src)/dsdt.asl
> > > $(call cmd,acpi_c_asl)
> > > +   $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@
> > >
> > >  # Bzip2
> > >  # ---
> > > 
> > > --
> >
> > Otherwise,
> > Reviewed-by: Bin Meng 
> >
> > Regards,
> > Bin
> 
> --
> Andy Shevchenko 
> Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread Marek Vasut
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
> 
> 
> On 23/05/2018 14:43, Marek Vasut wrote:
>> On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
>>>
>>> On 23/05/2018 14:03, Marek Vasut wrote:
 On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
> Hi,
 Hi,

> When trying to migrate a board from u-boot version 2016.09 to version
> 2018.03, I found a problem with a USB 2.0 device which used to work on
> version 2016.09.
 Does it still happen in u-boot/master ?
>>> Yes, it still happens.
>>>
>>> I just tested it with the following commit:
>>> dca268a .travis.yml: Further optimizations
> In u-boot version 2016.09 the device appears like this:
>
> 2: Mass Storage,  USB Revision 2.0
>    - SanDisk Cruzer Blade 200443243002FB509E64
>> Let me guess, is this a DWC2-based host ? You didn't mention which SoC
>> or USB controller it is.
>>
>> Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
>> DWC2 has problems with those sandisk sticks.
> No, it is a NXP T1024 SoC.
> Do you think it may be a problem with the SoC or NXP USB host driver ?
> 
So that's chipidea ? That one should be reasonably sane.

Submit the patch you had in mind and let's see what happens.

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


Re: [U-Boot] QUERY:U-boot DM:SERIAL:Multiple On-chip UART Controller Support

2018-05-23 Thread Simon Glass
On 23 May 2018 at 11:56, Vabhav Sharma  wrote:
> Hello Everyone,
>
> I am working on integrating  generic PL011 driver in u-boot and linux for
> ARMv8 NXP SoC and facing issue with multiple UART console enablement in
> u-boot using DM model
>
> Kindly provide your valuable feedback and experts comments.
>
>
>
> DTS require stdout-path(e.g-UART0) to the /chosen device tree node
> ,Accordingly controller(UART0) is probed/initialized as boot console
>
> On u-boot prompt, Bootargs is modified to use UART1(ttyAMA1) console for
> linux boot but kernel hangs after “Starting kernel ... print”
>
>
>
> After debugging it’s found that UART1 is not initialized and single(first)
> controller is  probed/initialized in u-boot (Irrespective of 4 UART nodes
> are enabled in dts)
>
> In drivers/serial/serial-uclass.c ,gd->cur_serial_dev is updated to the DT
> stdout-path or CONFIG_CONS_INDEX or platform data(first index)
>
>
>
> Does the u-boot DM model support only one or multiple UART driver
> probing/initialization? Is there any configuration parameter required to
> define number of UART controllers to be probed/initialized.
>
> This looks limitation as same boot console is used for u-boot and linux and
> unable to use all available UART controllers.
>
>
>
> I am new to u-boot and please correct any misunderstanding
>
> Let me know If I can submit a patch for multiple UART probe in serial-uclass
> or open a bug for multiple UART support in u-boot DM model
>
>
>
> PS:I am unable to find owner of serial uclass driver from MAINTAINERS file
>
>
>
> Regards,
>
> Vabhav
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread Marek Vasut
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
> 
> 
> On 23/05/2018 14:03, Marek Vasut wrote:
>> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
>>> Hi,
>> Hi,
>>
>>> When trying to migrate a board from u-boot version 2016.09 to version
>>> 2018.03, I found a problem with a USB 2.0 device which used to work on
>>> version 2016.09.
>> Does it still happen in u-boot/master ?
> Yes, it still happens.
> 
> I just tested it with the following commit:
> dca268a .travis.yml: Further optimizations
>>
>>> In u-boot version 2016.09 the device appears like this:
>>>
>>> 2: Mass Storage,  USB Revision 2.0
>>>   - SanDisk Cruzer Blade 200443243002FB509E64

Let me guess, is this a DWC2-based host ? You didn't mention which SoC
or USB controller it is.

Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html ,
DWC2 has problems with those sandisk sticks.

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


Re: [U-Boot] usb: Fail to get descriptor for USB 2.0 device

2018-05-23 Thread Marek Vasut
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
> Hi,

Hi,

> When trying to migrate a board from u-boot version 2016.09 to version
> 2018.03, I found a problem with a USB 2.0 device which used to work on
> version 2016.09.

Does it still happen in u-boot/master ?

> In u-boot version 2016.09 the device appears like this:
> 
> 2: Mass Storage,  USB Revision 2.0
>  - SanDisk Cruzer Blade 200443243002FB509E64
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0781  Product 0x5567 Version 1.38
>    Configuration: 1
>    - Interfaces: 1 Bus Powered 200mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 1 In Bulk MaxPacket 512
>  - Endpoint 2 Out Bulk MaxPacket 512
> 
> 
> But in version 2018.03 I just can't start usb. It fails with following
> error:
> 
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> unable to get device descriptor (error=-1)
> 1 USB Device(s) found
> USB1:   USB EHCI 1.00
> scanning bus 1 for devices... 1 USB Device(s) found
>    scanning usb for storage devices... 0 Storage Device(s) found
> 
> 
> I did a "git bisect" and found that this problem is related to the
> following commit:
> 
> c008faa usb: Only get 64 bytes device descriptor for full speed devices
> 
> I am not an expert on USB, so I would like to ask for help on this issue.
> 
> In u-boot v2018.03, file common/usb.c, line 973, shouldn't the
> comparison be like this:
> 
>     if (do_read && dev->speed >= USB_SPEED_FULL) {
> 
> or, at list:
> 
>     if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed ==
> USB_SPEED_HIGH)) {
> 
> 
> I would submit a patch for this, but I lack on USB knowledge for
> explaining the patch.
> 


-- 
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 4/5] lib: Import hexdump.c from Linux

2018-05-23 Thread Simon Glass
Hi Mario,

On 23 May 2018 at 06:09, Mario Six  wrote:
> Especially for commands, it is useful to be able to turn a hexadecimal
> string into its binary representation.
>
> Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the
> Linux kernel.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  include/linux/kernel.h |   4 +
>  lib/Makefile   |   1 +
>  lib/hexdump.c  | 321 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 lib/hexdump.c

Does Linux have any tests for this code?

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


Re: [U-Boot] [PATCH v2] add FIT data-position & data-offset property support

2018-05-23 Thread Simon Glass
Hi Kelvin,

On 22 May 2018 at 19:34, Kelvin Cheung  wrote:
> Hi Simon,
>
>
> 2018-05-23 7:30 GMT+08:00 Simon Glass :
>>
>> Hi,
>>
>> On 18 May 2018 at 01:56, Kelvin Cheung  wrote:
>> > Add FIT data-position & data-offset property support for bootm,
>> > which were already supported in SPL.
>> >
>> > Signed-off-by: Kelvin Cheung 
>> > ---
>> >
>> > Changes for v2:
>> >create fit_image_get_data_and_size() to remove duplicated code
>> >
>> > ---
>> >  common/image-fit.c | 54
>> > +++---
>> >  include/image.h|  2 ++
>> >  2 files changed, 53 insertions(+), 3 deletions(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> How can we get this feature integrated into the tests?
>>
> Do you mean the test scripts under test dir?

I mean the test_fit.py test.

>
> BTW, I updated this patch to v3 several days ago.

OK, well please take a look at the test.

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


Re: [U-Boot] [PATCH v2 1/5] drivers: Add OSD uclass

2018-05-23 Thread Simon Glass
On 23 May 2018 at 06:09, Mario Six  wrote:
> Some devices offer a text-based OSD (on-screen display) that can be
> programmatically controlled (i.e. text displayed on).
>
> Add a uclass to support such devices.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> * Use singular case for UCLASS_VIDEO_OSD description
> * Expanded description of video_osd_set_mem with example
> * Replaced all left-over mentions of pixels with text
> * Renamed x and y parameters to col and row
> * Expaneded description of color parameter
> * Added general description of the OSD uclass
> * Expanded description of video_osd_info
>
> ---
>  drivers/video/Kconfig|   8 ++
>  drivers/video/Makefile   |   2 +
>  drivers/video/video_osd-uclass.c |  46 ++
>  include/dm/uclass-id.h   |   1 +
>  include/video_osd.h  | 193 
> +++
>  5 files changed, 250 insertions(+)
>  create mode 100644 drivers/video/video_osd-uclass.c
>  create mode 100644 include/video_osd.h

Why drop the 'u' on 'colour'?

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


Re: [U-Boot] [PATCH v2 2/5] video_osd: Add ihs_video_out driver

2018-05-23 Thread Simon Glass
Hi Mario,

On 23 May 2018 at 06:09, Mario Six  wrote:
> Add a driver for IHS OSDs on IHS FPGAs.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> * Renamed x and y parameters to col and row
> * Removed duplicate IHS_VIDEO_OUT definition
> * Switched error return code of ihs_video_out_set_mem to E2BIG
> * Dropped blank lines between dev_read_u32_default calls
> * Documented members of ihs_video_out_priv
> * Turned printfs into debugs
> * Don't display OSD until something has been written to it
> * Made the code a bit more readable
> * Added binding file
> * Expanded documentation and help
> * Switched to display_enable
> * Switched to regmap usage (instead of fpgamap uclass)
> * Renamed 'dp_tx' property to 'video_tx'
>
> ---
>  .../video/osd/gdsys,ihs_video_out.txt  |  22 ++
>  drivers/video/Kconfig  |   9 +
>  drivers/video/Makefile |   1 +
>  drivers/video/ihs_video_out.c  | 277 
> +
>  4 files changed, 309 insertions(+)
>  create mode 100644 doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
>  create mode 100644 drivers/video/ihs_video_out.c
>

Reviewed-by: Simon Glass 

You could perhaps s/dev_read_prop/dev_read_string/ to avoid the cast.
Also is there a binding file for your driver's device-tree node
somewhere?

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


Re: [U-Boot] [PATCH v2 5/5] cmd: Add osd commands

2018-05-23 Thread Simon Glass
Hi Mario,

On 23 May 2018 at 06:09, Mario Six  wrote:
> Add command to query information from and write text to on-screen
> display (OSD) devices.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> * Added explanation for what a OSD is
> * Added explanation of the color parameter
> * Moved GDSYS_LEGACY_OSD_CMDS to gdsys Kconfig
>
> ---
>  board/gdsys/mpc8308/Kconfig |  11 ++
>  cmd/Kconfig |   8 +
>  cmd/Makefile|   1 +
>  cmd/osd.c   | 378 
> 
>  4 files changed, 398 insertions(+)
>  create mode 100644 cmd/osd.c

To me it seems unfortunate that the legacy and new commands are named
the same. I suppose that is unavoidable?

I wonder if the legacy code could be moved to board/gdsys instead? It
is out of the way then.

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


Re: [U-Boot] [PATCH] malloc: Use malloc simple before malloc is fully initialized in memalign()

2018-05-23 Thread Simon Glass
Hi,

On 23 May 2018 at 00:32, Ley Foon Tan  wrote:
> On Sat, May 19, 2018 at 10:37 PM, Simon Glass  wrote:
>> Hi Ley,
>>
>> On 18 May 2018 at 04:03, Ley Foon Tan  wrote:
>>> Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and 
>>> use
>>> malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the malloc bytes
>>> to align with the requested alignment.
>>>
>>> The original memalign() function will access mchunkptr struct to adjust the
>>> alignment if there is misalignment happen, but mchunkptr struct is not being
>>> initialized before full malloc is initialized. This cause the system crash.
>>>
>>> Signed-off-by: Ley Foon Tan 
>>> ---
>>>  common/dlmalloc.c |7 +++
>>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
>>> index b395eef..edaad29 100644
>>> --- a/common/dlmalloc.c
>>> +++ b/common/dlmalloc.c
>>> @@ -1891,6 +1891,13 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; 
>>> size_t bytes;
>>>
>>>if ((long)bytes < 0) return NULL;
>>>
>>> +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
>>
>> How about:
>>
>> if (IS_ENABLED(CONFIG_SYS_MALLOC_F))
>
> I think this is the reason it uses #if CONFIG_VAL(SYS_MALLOC_F_LEN),
> same for malloc().
>
> "spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN"
>
> http://git.denx.de/?p=u-boot.git;a=commit;h=f1896c45cb2f7d8dbed27e784a6459a129fc0762

So how about

if (CONFIG_IS_ENABLED(SYS_MALLOC_F_LEN)

Or you could use #if if you need to

To me it seems better to use the setting itself (i.e. whether the
pre-reloc malloc() is enabled) rather than one of its parameters (the
size of the region).

>
>
>>
>> ?
>>
>>> +   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
>>> +   nb = roundup(bytes, alignment);
>>> +   return malloc_simple(nb);
>>> +   }
>>> +#endif
>>> +
>>>/* If need less alignment than we give anyway, just relay to malloc */
>>>
>>>if (alignment <= MALLOC_ALIGNMENT) return mALLOc(bytes);
>>> --
>>> 1.7.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/5] video_osd: Add osd sandbox driver and tests

2018-05-23 Thread Simon Glass
Hi Mario,

On 23 May 2018 at 06:09, Mario Six  wrote:
> Add sandbox driver and tests for the new OSD uclass.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  arch/sandbox/dts/test.dts  |   4 +
>  configs/sandbox64_defconfig|   3 +
>  configs/sandbox_defconfig  |   3 +
>  configs/sandbox_flattree_defconfig |   3 +
>  configs/sandbox_noblk_defconfig|   3 +
>  configs/sandbox_spl_defconfig  |   3 +
>  drivers/video/Kconfig  |   6 ++
>  drivers/video/Makefile |   1 +
>  drivers/video/sandbox_osd.c| 157 
>  drivers/video/sandbox_osd.h|  14 +++
>  drivers/video/video_osd-uclass.c   |   9 ++
>  include/video_osd.h|   7 ++
>  test/dm/Makefile   |   1 +
>  test/dm/osd.c  | 208 
> +
>  14 files changed, 422 insertions(+)
>  create mode 100644 drivers/video/sandbox_osd.c
>  create mode 100644 drivers/video/sandbox_osd.h
>  create mode 100644 test/dm/osd.c

This looks good. But you can't add a new get_mem() operation just for sandbox.

Instead, how about a back-door function that allows sandbox to get its
information. You can call it sandbox_video_osd_get_mem(), for example,
and just directly call it from you test code and implement it in your
driver.

There are some functions like this in arch/sandbox/include/asm/test.h

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


Re: [U-Boot] [PATCH 2/2] dm: pci: use a 1:1 mapping for bus <-> phy addresses

2018-05-23 Thread Simon Glass
Hi Christian,

On 23 May 2018 at 06:00, Christian Gmeiner  wrote:
> If u-boot gets used as coreboot payload all pci resources got

U-Boot

(please use this consistently)

> assigned by coreboot. If a dts without any pci ranges gets used
> the dm is not able to access pci device memory. To get things
> working make use of a 1:1 mapping for bus <-> phy addresses.
>
> This change makes it possible to get the e1000 u-boot driver
> working on a sandybridge device where u-boot is used as coreboot
> payload.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/pci/pci-uclass.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 416444a230..9cec619bb2 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -1175,6 +1175,11 @@ static int _dm_pci_bus_to_phys(struct udevice *ctlr,
> struct pci_region *res;
> int i;
>
> +   if (hose->region_count == 0) {

Or just if (!hose->region_count)

Please add a comment as to the case you are covering here. How come
the mapping will be 1:1? Is that guaranteed?

> +   *pa = bus_addr;
> +   return 0;
> +   }
> +
> for (i = 0; i < hose->region_count; i++) {
> res = >regions[i];
>
> @@ -1238,6 +1243,11 @@ int _dm_pci_phys_to_bus(struct udevice *dev, 
> phys_addr_t phys_addr,
> ctlr = pci_get_controller(dev);
> hose = dev_get_uclass_priv(ctlr);
>
> +   if (hose->region_count == 0) {
> +   *ba = phys_addr;
> +   return 0;
> +   }
> +
> for (i = 0; i < hose->region_count; i++) {
> res = >regions[i];
>
> --
> 2.17.0
>

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


Re: [U-Boot] [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to drivers/ata directory

2018-05-23 Thread Simon Glass
Hi Ken,

On 23 May 2018 at 01:06, Ken Ma  wrote:
> Dear Simon
>
> Thanks a lot for your kind help and review.
>
> Previously I did not use patman and generated my patches as below:
> 1. used "git mv arch/arm/mach-mvebu/sata.c drivers/ata/ahci_mvebu.c" to do 
> the file renaming with makefiles and Kconfig file updating.
> 2. After the 4 patches are all finished, I used "git format-patch -4 
> --cover-letter -o outgoing/sata" to generate the patch set with cover letter.
> 3. I used " git send-email --to u-boot@lists.denx.de outgoing/sata* --force" 
> to send out patches.
>
> And I try to use patman as your advice, I find that the patch generated by 
> "patman" can indicate the file "rename" relationship while the patch 
> generated by "git format-patch" can not.
> arch/arm/mach-mvebu/Makefile   | 1 -
> drivers/ata/Kconfig| 9 +
> drivers/ata/Makefile   | 1 +
> arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c | 6 +++---
> 4 files changed, 13 insertions(+), 4 deletions(-)
> rename arch/arm/mach-mvebu/sata.c => drivers/ata/ahci_mvebu.c (89%)
> …
> diff --git a/arch/arm/mach-mvebu/sata.c b/drivers/ata/ahci_mvebu.c
> similarity index 89%
> rename from arch/arm/mach-mvebu/sata.c
> rename to drivers/ata/ahci_mvebu.c
> index 5d8032b..5c1b293 100644
> --- a/arch/arm/mach-mvebu/sata.c
> +++ b/drivers/ata/ahci_mvebu.c
> @@ -1,15 +1,15 @@
>  /*
> + * Copyright (C) 2018 Marvell International Ltd.
>   * Copyright (C) 2016 Stefan Roese 
>   *
> - * SPDX-License-Identifier:GPL-2.0+
> + * SPDX-License-Identifier: GPL-2.0+
> + * https://spdx.org/licenses
>   */
>
>  #include 
>  #include 
>  #include 
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  /*
>   * Dummy implementation that can be overwritten by a board
>   * specific function
>
> But I failed to send out patches by patman as below, it says " Alias 'ata' 
> not found ".
> ken@mshsrv05:~/git_ken/u-boot/u-boot$ tools/patman/patman -c4
> Cleaned 4 patches
> 0 errors, 1 warnings, 0 checks for 
> 0001-ata-mvebu-move-mvebu-sata-driver-to-drivers-ata-dire.patch:
> :0: warning: added, moved or deleted file(s), does 
> MAINTAINERS need updating?
>
> checkpatch.pl found 0 error(s), 1 warning(s), 0 checks(s)
> Traceback (most recent call last):
>   File "tools/patman/patman", line 161, in 
> options.add_maintainers)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/series.py", line 
> 231, in MakeCcFile
> raise_on_error=raise_on_error)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", 
> line 326, in BuildEmailList
> raw += LookupEmail(item, alias, raise_on_error=raise_on_error)
>   File "/home/ken/git_ken/u-boot/u-boot/tools/patman/gitutil.py", 
> line 503, in LookupEmail
> raise ValueError(msg)
> ValueError: Alias 'ata' not found
>
>
> Thanks a lot for your kind help!

You can use the -t flag to ignore the missing alias.

Regards,
Simon

>
> Yours,
> Ken
>
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2018年5月23日 7:30
> To: Ken Ma
> Cc: U-Boot Mailing List; Stefan Roese
> Subject: [EXT] Re: [PATCH 1/4] ata: mvebu: move mvebu sata driver to 
> drivers/ata directory
>
> External Email
>
> --
> Hi Ken,
>
> On 17 May 2018 at 19:27,   wrote:
>> From: Ken Ma 
>>
>> Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this
>> patch moves it to drivers/ata directory with renaming "sata.c" to
>> "ahci_mvebu.c" which is aligned to Linux.
>> New ahci driver's kconfig option is added as AHCI_MVEBU which selects
>> DM_SCSI.
>>
>> Signed-off-by: Ken Ma 
>> Cc: Simon Glass 
>> Cc: Stefan Roese 
>> ---
>>  arch/arm/mach-mvebu/Makefile |  1 -
>>  arch/arm/mach-mvebu/sata.c   | 54 
>> 
>>  drivers/ata/Kconfig  |  9 
>>  drivers/ata/Makefile |  1 +
>>  drivers/ata/ahci_mvebu.c | 54 
>> 
>>  5 files changed, 64 insertions(+), 55 deletions(-)
>>  delete mode 100644 arch/arm/mach-mvebu/sata.c
>>  create mode 100644 drivers/ata/ahci_mvebu.c
>>
>
> How come this doesn't show up as a file move? Are you using patman to
> generate your patches?
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, PATCHv3, 2/3] buildman: support newer gcc versions from kernel.org

2018-05-23 Thread Tom Rini
On Thu, May 10, 2018 at 07:15:53AM -0400, Tom Rini wrote:

> From: Daniel Schwierzeck 
> 
> Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
> 
> Also use a regex for matching the tarball names. Some gcc versions
> use '-ARCH-' instead of '_ARCH-'.
> 
> As part of this, we switch TravisCI to also using these toolchains for
> all platforms.
> 
> Signed-off-by: Daniel Schwierzeck 
> Signed-off-by: Tom Rini 

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, PATCHv3, 3/3] .travis.yml: Further optimizations

2018-05-23 Thread Tom Rini
On Thu, May 10, 2018 at 07:15:54AM -0400, Tom Rini wrote:

> - Xilinx aarch64 is caught in the general xilinx arm job, exclude from
>   the general aarch64 job.
> - Give the generic aarch64 job a better name
> - Re-sort the PowerPC jobs so that we can complete them a bit quicker.
> 
> Signed-off-by: Tom Rini 

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, PATCHv3, 1/3] at91: Minor tweaks to SPL logic for space savings on smartweb

2018-05-23 Thread Tom Rini
On Thu, May 10, 2018 at 07:15:52AM -0400, Tom Rini wrote:

> - spl_board_init is empty on smartweb so drop that function
> - When CONFIG_AT91SAM9_WATCHDOG is set we do not disable the watchdog in
>   SPL and instead let full U-Boot handle it.  Instead of an empty
>   function just do not call a function.
> 
> Signed-off-by: Tom Rini 

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 v3 2/3] misc: uclass: Add enable/disable function

2018-05-23 Thread Mario Six
Add generic enable/disable function to the misc uclass.

Signed-off-by: Mario Six 

---

v2 -> v3:
* Now return old state from misc_set_enabled

v1 -> v2:
* Merged the two functions into one function
* Explained the semantics of enabling/disabling more throughly

---
 drivers/misc/misc-uclass.c | 10 ++
 include/misc.h | 27 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c
index 0dc62d00344..f240cda5c05 100644
--- a/drivers/misc/misc-uclass.c
+++ b/drivers/misc/misc-uclass.c
@@ -55,6 +55,16 @@ int misc_call(struct udevice *dev, int msgid, void *tx_msg, 
int tx_size,
return ops->call(dev, msgid, tx_msg, tx_size, rx_msg, rx_size);
 }

+int misc_set_enabled(struct udevice *dev, bool val)
+{
+   const struct misc_ops *ops = device_get_ops(dev);
+
+   if (!ops->set_enabled)
+   return -ENOSYS;
+
+   return ops->set_enabled(dev, val);
+}
+
 UCLASS_DRIVER(misc) = {
.id = UCLASS_MISC,
.name   = "misc",
diff --git a/include/misc.h b/include/misc.h
index 0acb4c4df64..ffc489ec6b0 100644
--- a/include/misc.h
+++ b/include/misc.h
@@ -60,6 +60,23 @@ int misc_call(struct udevice *dev, int msgid, void *tx_msg, 
int tx_size,
  void *rx_msg, int rx_size);

 /**
+ * misc_set_enabled() - Enable or disable a device.
+ *
+ * The semantics of "disable" and "enable" should be understood here as
+ * activating or deactivating the device's primary function, hence a "disabled"
+ * device should be dormant, but still answer to commands and queries.
+ *
+ * A probed device may start in a disabled or enabled state, depending on the
+ * driver and hardware.
+ *
+ * @dev: the device to enable or disable.
+ * @val: the flag that tells the driver to either enable or disable the device.
+ * Return: -ve on error, 0 if the previous state was "disabled", 1 if the
+ *previous state was "enabled"
+ */
+int misc_set_enabled(struct udevice *dev, bool val);
+
+/*
  * struct misc_ops - Driver model Misc operations
  *
  * The uclass interface is implemented by all miscellaneous devices which
@@ -112,6 +129,16 @@ struct misc_ops {
 */
int (*call)(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
void *rx_msg, int rx_size);
+   /**
+* Enable or disable a device, optional.
+*
+* @dev: the device to enable.
+* @val: the flag that tells the driver to either enable or disable the
+*   device.
+* Return: -ve on error, 0 if the previous state was "disabled", 1 if
+* the previous state was "enabled"
+*/
+   int (*set_enabled)(struct udevice *dev, bool val);
 };

 #endif /* _MISC_H_ */
--
2.11.0

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


[U-Boot] [PATCH v3 1/3] misc: docs: Fix comments in misc.h

2018-05-23 Thread Mario Six
The comments in misc.h are not in kernel-doc format. Correct the format.

Signed-off-by: Mario Six 

---

v2 -> v3:
New in v3

---
 include/misc.h | 66 +++---
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/include/misc.h b/include/misc.h
index 68f8e64d61a..0acb4c4df64 100644
--- a/include/misc.h
+++ b/include/misc.h
@@ -6,38 +6,40 @@
 #ifndef _MISC_H_
 #define _MISC_H_

-/*
- * Read the device to buffer, optional.
+/**
+ * misc_read() - Read the device to buffer, optional.
  *
  * @dev: the device
  * @offset: offset to read the device
  * @buf: pointer to data buffer
  * @size: data size in bytes to read the device
- * @return: 0 if OK, -ve on error
+ * Return: 0 if OK, -ve on error
  */
 int misc_read(struct udevice *dev, int offset, void *buf, int size);
-/*
- * Write buffer to the device, optional.
+
+/**
+ * misc_write() - Write buffer to the device, optional.
  *
  * @dev: the device
  * @offset: offset to write the device
  * @buf: pointer to data buffer
  * @size: data size in bytes to write the device
- * @return: 0 if OK, -ve on error
+ * Return: 0 if OK, -ve on error
  */
 int misc_write(struct udevice *dev, int offset, void *buf, int size);
-/*
- * Assert command to the device, optional.
+
+/**
+ * misc_ioctl() - Assert command to the device, optional.
  *
  * @dev: the device
  * @request: command to be sent to the device
  * @buf: pointer to buffer related to the request
- * @return: 0 if OK, -ve on error
+ * Return: 0 if OK, -ve on error
  */
 int misc_ioctl(struct udevice *dev, unsigned long request, void *buf);

-/*
- * Send a message to the device and wait for a response.
+/**
+ * misc_call() - Send a message to the device and wait for a response.
  *
  * The caller provides the message type/ID and payload to be sent.
  * The callee constructs any message header required, transmits it to the
@@ -47,64 +49,66 @@ int misc_ioctl(struct udevice *dev, unsigned long request, 
void *buf);
  *
  * @dev: the device.
  * @msgid: the message ID/number to send.
- * tx_msg: the request/transmit message payload.
- * tx_size: the size of the buffer pointed at by tx_msg.
- * rx_msg: the buffer to receive the response message payload. May be NULL if
- * the caller only cares about the error code.
- * rx_size: the size of the buffer pointed at by rx_msg.
- * @return the response message size if OK, -ve on error
+ * @tx_msg: the request/transmit message payload.
+ * @tx_size: the size of the buffer pointed at by tx_msg.
+ * @rx_msg: the buffer to receive the response message payload. May be NULL if
+ *  the caller only cares about the error code.
+ * @rx_size: the size of the buffer pointed at by rx_msg.
+ * Return: the response message size if OK, -ve on error
  */
 int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
  void *rx_msg, int rx_size);

-/*
+/**
  * struct misc_ops - Driver model Misc operations
  *
  * The uclass interface is implemented by all miscellaneous devices which
  * use driver model.
  */
 struct misc_ops {
-   /*
+   /**
 * Read the device to buffer, optional.
 *
 * @dev: the device
 * @offset: offset to read the device
 * @buf: pointer to data buffer
 * @size: data size in bytes to read the device
-* @return: 0 if OK, -ve on error
+* Return: 0 if OK, -ve on error
 */
int (*read)(struct udevice *dev, int offset, void *buf, int size);
-   /*
+
+   /**
 * Write buffer to the device, optional.
 *
 * @dev: the device
 * @offset: offset to write the device
 * @buf: pointer to data buffer
 * @size: data size in bytes to write the device
-* @return: 0 if OK, -ve on error
+* Return: 0 if OK, -ve on error
 */
int (*write)(struct udevice *dev, int offset, const void *buf,
 int size);
-   /*
+   /**
 * Assert command to the device, optional.
 *
 * @dev: the device
 * @request: command to be sent to the device
 * @buf: pointer to buffer related to the request
-* @return: 0 if OK, -ve on error
+* Return: 0 if OK, -ve on error
 */
int (*ioctl)(struct udevice *dev, unsigned long request, void *buf);
-   /*
+
+   /**
 * Send a message to the device and wait for a response.
 *
 * @dev: the device
 * @msgid: the message ID/number to send
-* tx_msg: the request/transmit message payload
-* tx_size: the size of the buffer pointed at by tx_msg
-* rx_msg: the buffer to receive the response message payload. May be
-* NULL if the caller only cares about the error code.
-* rx_size: the size of the buffer pointed at by rx_msg
-* @return the response message size if OK, -ve on error
+* @tx_msg: the 

[U-Boot] [PATCH v3 3/3] misc: Add gdsys_ioep driver

2018-05-23 Thread Mario Six
Add driver for the IHS IO endpoint on IHS FPGAs.

Signed-off-by: Mario Six 

---

v2 -> v3:
No changes

v1 -> v2:
* Switched to regmap usage (instead of fpgamap)

---
 drivers/misc/Kconfig  |   6 ++
 drivers/misc/Makefile |   1 +
 drivers/misc/gdsys_ioep.c | 155 ++
 drivers/misc/gdsys_ioep.h |  73 ++
 4 files changed, 235 insertions(+)
 create mode 100644 drivers/misc/gdsys_ioep.c
 create mode 100644 drivers/misc/gdsys_ioep.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index be900cf4d6e..dc4cd4ec110 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -268,4 +268,10 @@ config GDSYS_RXAUI_CTRL
depends on MISC
help
  Support gdsys FPGA's RXAUI control.
+
+config GDSYS_IOEP
+   bool "Enable gdsys IOEP driver"
+   depends on MISC
+   help
+ Support gdsys FPGA's IO endpoint driver.
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e362609d62a..1782dc8be42 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
 obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
 obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
 obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o
diff --git a/drivers/misc/gdsys_ioep.c b/drivers/misc/gdsys_ioep.c
new file mode 100644
index 000..2c29e8c4e8c
--- /dev/null
+++ b/drivers/misc/gdsys_ioep.c
@@ -0,0 +1,155 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * based on the cmd_ioloop driver/command, which is
+ *
+ * (C) Copyright 2014
+ * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "gdsys_ioep.h"
+
+struct gdsys_ioep_priv {
+   struct regmap *map;
+   bool state;
+};
+
+enum last_spec {
+   READ_DATA_IS_LAST,
+   READ_DATA_IS_NOT_LAST,
+};
+
+int gdsys_ioep_set_receive(struct udevice *dev, bool val)
+{
+   struct gdsys_ioep_priv *priv = dev_get_priv(dev);
+   u16 state;
+
+   priv->state = !priv->state;
+
+   if (val)
+   state = CTRL_PROC_RECEIVE_ENABLE;
+   else
+   state = ~CTRL_PROC_RECEIVE_ENABLE;
+
+   gdsys_ioep_set(priv->map, tx_control, state);
+
+   if (val) {
+   /* Set device address to dummy 1*/
+   gdsys_ioep_set(priv->map, device_address, 1);
+   }
+
+   return !priv->state;
+}
+
+int gdsys_ioep_send(struct udevice *dev, int offset, const void *buf, int size)
+{
+   struct gdsys_ioep_priv *priv = dev_get_priv(dev);
+   int k;
+   u16 *p = (u16 *)buf;
+
+   for (k = 0; k < size; ++k)
+   gdsys_ioep_set(priv->map, transmit_data, *(p++));
+
+   gdsys_ioep_set(priv->map, tx_control, CTRL_PROC_RECEIVE_ENABLE |
+ CTRL_FLUSH_TRANSMIT_BUFFER);
+
+   return 0;
+}
+
+int receive_byte_buffer(struct udevice *dev, uint len, u16 *buffer, enum 
last_spec last_spec)
+{
+   struct gdsys_ioep_priv *priv = dev_get_priv(dev);
+   int k;
+   int res = -EIO;
+
+   for (k = 0; k < len; ++k) {
+   u16 rx_tx_status;
+
+   gdsys_ioep_get(priv->map, receive_data, buffer++);
+
+   gdsys_ioep_get(priv->map, rx_tx_status, _tx_status);
+   if (k == (len - 1) && (last_spec == READ_DATA_IS_NOT_LAST ||
+  rx_tx_status & STATE_RX_DATA_LAST))
+   res = 0;
+   }
+
+   return res;
+}
+
+int gdsys_ioep_receive(struct udevice *dev, int offset, void *buf, int size)
+{
+   int res1, res2;
+   struct io_generic_packet header;
+   u16 *p = (u16 *)buf;
+   const int header_words = sizeof(struct io_generic_packet) / 2;
+   uint len;
+
+   res1 = receive_byte_buffer(dev, header_words, p, READ_DATA_IS_NOT_LAST);
+   memcpy(, p, 2 * header_words);
+   p += header_words;
+
+   len = (header.packet_length + 1) / 2;
+
+   if (!res1)
+   res2 = receive_byte_buffer(dev, len, p, READ_DATA_IS_LAST);
+
+   return res1 ? res1 : res2;
+}
+
+int gdsys_ioep_get_and_reset_status(struct udevice *dev, int msgid,
+   void *tx_msg, int tx_size, void *rx_msg,
+   int rx_size)
+{
+   struct gdsys_ioep_priv *priv = dev_get_priv(dev);
+   const u16 mask = STATE_RX_DIST_ERR | STATE_RX_LENGTH_ERR |
+STATE_RX_FRAME_CTR_ERR | STATE_RX_FCS_ERR |
+STATE_RX_PACKET_DROPPED | STATE_TX_ERR;
+   u16 *status = rx_msg;
+
+   gdsys_ioep_get(priv->map, rx_tx_status, status);
+
+   gdsys_ioep_set(priv->map, rx_tx_status, *status);
+
+   return (*status & mask) ? 1 : 0;
+}
+
+static const struct misc_ops 

Re: [U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional

2018-05-23 Thread Christian Gmeiner
Hi Bin,

Am Mi., 23. Mai 2018 um 15:10 Uhr schrieb Bin Meng :

> Hi Christian,

> On Wed, May 23, 2018 at 8:00 PM, Christian Gmeiner
>  wrote:
> > If we use u-boot as coreboot payload with a generic dts without
> > any ranges specified we fail in pci pre_probe and our pci bus
> > is not usable.
> >

> What do you mean by "a generic dts"?


> The coreboot payload needs to specify a dedicated dts for that board,
> for example to build a coreboot payload for minnowmax, we need specify
> minnowmax.dts in the Kconfig. README.x86 documents this.


Yeah.. so in my eyes a "generic dts" contains only this part regarding pci:

 pci {
 compatible = "pci-x86";
 #address-cells = <0x3>;
 #size-cells = <0x2>;
 };

The important part is that it does not contain any ranges. Coreboot is the
one
who does the pci bus setup (assigning memory windows for devices etc). So I
do not want to know in u-boot at build time (ranges thing for pci) how the
pci
bus looks regarding addresses. My end goal is one generic u-boot payload
that
gets used for different FSP 2.0 based boards.

> > So convert decode_regions(..) into a void function and do the simple
> > error handling there.
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  drivers/pci/pci-uclass.c | 21 +
> >  1 file changed, 9 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > index 49be1ebdd7..416444a230 100644
> > --- a/drivers/pci/pci-uclass.c
> > +++ b/drivers/pci/pci-uclass.c
> > @@ -810,7 +810,7 @@ error:
> > return ret;
> >  }
> >
> > -static int decode_regions(struct pci_controller *hose, ofnode
parent_node,
> > +static void decode_regions(struct pci_controller *hose, ofnode
parent_node,
> >   ofnode node)
> >  {
> > int pci_addr_cells, addr_cells, size_cells;
> > @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller
*hose, ofnode parent_node,
> > int i;
> >
> > prop = ofnode_get_property(node, "ranges", );
> > -   if (!prop)
> > -   return -EINVAL;
> > +   if (!prop) {
> > +   debug("%s: Cannot decode regions\n", __func__);
> > +   return;
> > +   }
> > +
> > pci_addr_cells = ofnode_read_simple_addr_cells(node);
> > addr_cells = ofnode_read_simple_addr_cells(parent_node);
> > size_cells = ofnode_read_simple_size_cells(node);
> > @@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller
*hose, ofnode parent_node,
> > bd_t *bd = gd->bd;
> >
> > if (!bd)
> > -   return 0;
> > +   return;
> >
> > for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> > if (bd->bi_dram[i].size) {
> > @@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller
*hose, ofnode parent_node,
> > base, size, PCI_REGION_MEM |
PCI_REGION_SYS_MEMORY);
> >  #endif
> >
> > -   return 0;
> > +   return;
> >  }
> >
> >  static int pci_uclass_pre_probe(struct udevice *bus)
> >  {
> > struct pci_controller *hose;
> > -   int ret;
> >
> > debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq,
bus->name,
> >   bus->parent->name);
> > @@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice
*bus)
> > /* For bridges, use the top-level PCI controller */
> > if (!device_is_on_pci_bus(bus)) {
> > hose->ctlr = bus;
> > -   ret = decode_regions(hose, dev_ofnode(bus->parent),
> > -dev_ofnode(bus));
> > -   if (ret) {
> > -   debug("%s: Cannot decode regions\n", __func__);
> > -   return ret;
> > -   }
> > +   decode_regions(hose, dev_ofnode(bus->parent),
dev_ofnode(bus));
> > } else {
> > struct pci_controller *parent_hose;
> >
> > --
> >

> Regards,
> Bin



-- 
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 0/5] Add KConfig option for cache maintenance availability

2018-05-23 Thread Emmanuel Vadot

 Hi Faiz,

On Tue, 22 May 2018 11:47:41 +0530
Faiz Abbas  wrote:

> Hi,
> 
> On Monday 30 April 2018 02:03 PM, Emmanuel Vadot wrote:
> > Hi,
> > 
> > In order to correctly exectute some binaries on some arch we need to flush
> > the data cache or instructions cache. Some arch offer helper functions for
> > this while others don't (or don't have the ability to do this in hardware).
> > Introduce some kconfig option name SYS_HAVE_DCACHE_MAINTENANCE and
> > SYS_HAVE_ICACHE_MAINTENANCE and enable it on some arm CPU that have cache
> > maintenance helpers.
> 
> It was decided that instead of flushing/invalidating caches,
> architectures should add support for allocating coherent data in the
> first place.
> 
> See the discussion here:
> https://patchwork.ozlabs.org/patch/826131/
> 
> Thanks,
> Faiz

 Thanks for the heads up.
 Are you working on on this for arm ?

 Cheers,

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


Re: [U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional

2018-05-23 Thread Bin Meng
Hi Christian,

On Wed, May 23, 2018 at 8:00 PM, Christian Gmeiner
 wrote:
> If we use u-boot as coreboot payload with a generic dts without
> any ranges specified we fail in pci pre_probe and our pci bus
> is not usable.
>

What do you mean by "a generic dts"?

The coreboot payload needs to specify a dedicated dts for that board,
for example to build a coreboot payload for minnowmax, we need specify
minnowmax.dts in the Kconfig. README.x86 documents this.

> So convert decode_regions(..) into a void function and do the simple
> error handling there.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/pci/pci-uclass.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 49be1ebdd7..416444a230 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -810,7 +810,7 @@ error:
> return ret;
>  }
>
> -static int decode_regions(struct pci_controller *hose, ofnode parent_node,
> +static void decode_regions(struct pci_controller *hose, ofnode parent_node,
>   ofnode node)
>  {
> int pci_addr_cells, addr_cells, size_cells;
> @@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, 
> ofnode parent_node,
> int i;
>
> prop = ofnode_get_property(node, "ranges", );
> -   if (!prop)
> -   return -EINVAL;
> +   if (!prop) {
> +   debug("%s: Cannot decode regions\n", __func__);
> +   return;
> +   }
> +
> pci_addr_cells = ofnode_read_simple_addr_cells(node);
> addr_cells = ofnode_read_simple_addr_cells(parent_node);
> size_cells = ofnode_read_simple_size_cells(node);
> @@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller *hose, 
> ofnode parent_node,
> bd_t *bd = gd->bd;
>
> if (!bd)
> -   return 0;
> +   return;
>
> for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> if (bd->bi_dram[i].size) {
> @@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller *hose, 
> ofnode parent_node,
> base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>  #endif
>
> -   return 0;
> +   return;
>  }
>
>  static int pci_uclass_pre_probe(struct udevice *bus)
>  {
> struct pci_controller *hose;
> -   int ret;
>
> debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name,
>   bus->parent->name);
> @@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice *bus)
> /* For bridges, use the top-level PCI controller */
> if (!device_is_on_pci_bus(bus)) {
> hose->ctlr = bus;
> -   ret = decode_regions(hose, dev_ofnode(bus->parent),
> -dev_ofnode(bus));
> -   if (ret) {
> -   debug("%s: Cannot decode regions\n", __func__);
> -   return ret;
> -   }
> +   decode_regions(hose, dev_ofnode(bus->parent), 
> dev_ofnode(bus));
> } else {
> struct pci_controller *parent_hose;
>
> --
>

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


[U-Boot] [PATCH v2 4/7] sandbox: Add and build AXI bus and device

2018-05-23 Thread Mario Six
Add test AXI drivers to the sandbox.

Reviewed-by: Simon Glass 
Signed-off-by: Mario Six 

---

v1 -> v2:
No changes

---
 arch/sandbox/dts/sandbox.dts | 11 +++
 arch/sandbox/dts/test.dts| 11 +++
 configs/sandbox_defconfig|  3 +++
 3 files changed, 25 insertions(+)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 86680a6b11d..8a236ea76b2 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -12,6 +12,7 @@
i2c0 = _0;
pci0 = 
rtc0 = _0;
+   axi0 = 
};

chosen {
@@ -315,6 +316,16 @@
};
};
};
+
+   axi: axi@0 {
+   compatible = "sandbox,axi";
+   #address-cells = <0x1>;
+   #size-cells = <0x1>;
+   store@0 {
+   compatible = "sandbox,sandbox_store";
+   reg = <0x0 0x400>;
+   };
+   };
 };

 #include "cros-ec-keyboard.dtsi"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5a0f187d8b7..5822c5dd59a 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -34,6 +34,7 @@
usb0 = _0;
usb1 = _1;
usb2 = _2;
+   axi0 = 
};

a-test {
@@ -507,6 +508,16 @@
compatible = "sandbox,wdt";
};

+   axi: axi@0 {
+   compatible = "sandbox,axi";
+   #address-cells = <0x1>;
+   #size-cells = <0x1>;
+   store@0 {
+   compatible = "sandbox,sandbox_store";
+   reg = <0x0 0x400>;
+   };
+   };
+
chosen {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 2fc84a16c91..83107c7f99a 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -45,6 +45,7 @@ CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_AXI=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_TFTPSRV=y
 CONFIG_CMD_RARP=y
@@ -81,6 +82,8 @@ CONFIG_DEVRES=y
 CONFIG_DEBUG_DEVRES=y
 CONFIG_ADC=y
 CONFIG_ADC_SANDBOX=y
+CONFIG_AXI=y
+CONFIG_AXI_SANDBOX=y
 CONFIG_CLK=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
--
2.11.0

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


[U-Boot] [PATCH v2 7/7] video_display: Add Xilinx LogiCore DP TX

2018-05-23 Thread Mario Six
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 

---

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 |  342 ++
 drivers/video/logicore_dp_tx.c   | 1975 ++
 drivers/video/logicore_dp_tx.h   |   40 +
 drivers/video/logicore_dp_tx_regif.h |  365 +++
 6 files changed, 2734 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

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c4d2861fe7..ddec697e359 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -423,6 +423,17 @@ config ATMEL_HLCD
help
   HLCDC supports video output to an attached LCD panel.

+config LOGICORE_DP_TX
+   bool "Enable Logicore DP TX driver"
+   depends on DISPLAY
+   help
+ Enable the driver for the transmitter part of the Xilinx LogiCORE
+ DisplayPort, a IP core for Xilinx FPGAs that implements a DisplayPort
+ video interface as defined by VESA DisplayPort v1.2.
+
+ Note that this is a pure transmitter device, and has no display
+ capabilities by itself.
+
 config VIDEO_BROADWELL_IGD
bool "Enable Intel Broadwell integrated graphics device"
depends on X86
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index cf7ad281c3b..fa4ac715fcf 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o

 obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o
 obj-$(CONFIG_ATMEL_HLCD) += atmel_hlcdfb.o
+obj-$(CONFIG_LOGICORE_DP_TX) += logicore_dp_tx.o
 obj-$(CONFIG_ATMEL_LCD) += atmel_lcdfb.o
 obj-$(CONFIG_CFB_CONSOLE) += cfb_console.o
 obj-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o
diff --git a/drivers/video/logicore_dp_dpcd.h b/drivers/video/logicore_dp_dpcd.h
new file mode 100644
index 000..68582945514
--- /dev/null
+++ b/drivers/video/logicore_dp_dpcd.h
@@ -0,0 +1,342 @@
+/*
+ * logicore_dp_dpcd.h
+ *
+ * DPCD interface definition for XILINX LogiCore DisplayPort v6.1
+ * based on Xilinx dp_v3_1 driver sources
+ *
+ * (C) Copyright 2016
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __GDSYS_LOGICORE_DP_DPCD_H__
+#define __GDSYS_LOGICORE_DP_DPCD_H__
+
+/* receiver capability field */
+#define DPCD_REV   0x0
+#define DPCD_MAX_LINK_RATE 0x1
+#define DPCD_MAX_LANE_COUNT0x2
+#define DPCD_MAX_DOWNSPREAD0x3
+#define DPCD_NORP_PWR_V_CAP0x4
+#define DPCD_DOWNSP_PRESENT0x5
+#define DPCD_ML_CH_CODING_CAP  0x6
+#define DPCD_DOWNSP_COUNT_MSA_OUI  0x7
+#defineDPCD_RX_PORT0_CAP_0 0x8
+#defineDPCD_RX_PORT0_CAP_1 0x9
+#defineDPCD_RX_PORT1_CAP_0 0xA
+#defineDPCD_RX_PORT1_CAP_1 0xB
+#define DPCD_I2C_SPEED_CTL_CAP 0xC
+#define DPCD_EDP_CFG_CAP   0xD
+#define DPCD_TRAIN_AUX_RD_INTERVAL 0xE
+#define DPCD_ADAPTER_CAP   0xF
+#define DPCD_FAUX_CAP  0x00020
+#define DPCD_MSTM_CAP  0x00021
+#define DPCD_NUM_AUDIO_EPS 0x00022
+#defineDPCD_AV_GRANULARITY 0x00023
+#define DPCD_AUD_DEC_LAT_7_0   0x00024
+#define DPCD_AUD_DEC_LAT_15_8  0x00025
+#define DPCD_AUD_PP_LAT_7_00x00026
+#define DPCD_AUD_PP_LAT_15_8   0x00027
+#define DPCD_VID_INTER_LAT 0x00028
+#define DPCD_VID_PROG_LAT  0x00029
+#define DPCD_REP_LAT   0x0002A
+#define DPCD_AUD_DEL_INS_7_0   0x0002B
+#define DPCD_AUD_DEL_INS_15_8  0x0002C
+#define DPCD_AUD_DEL_INS_23_16

[U-Boot] [PATCH v2 3/7] axi: Add AXI sandbox driver and simple emulator

2018-05-23 Thread Mario Six
Add test infrastructure and tests for the AXI uclass.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Spelled out abbreviations in Kconfig help
* Expanded emulation documentation
* Renamed storage pointer to storep
* Expanded AXI emulator usage documentation
* Switched AXI emulator to aligned access

---
 drivers/axi/Kconfig   |   7 +++
 drivers/axi/Makefile  |   3 ++
 drivers/axi/axi-emul-uclass.c |  68 ++
 drivers/axi/axi_sandbox.c |  77 +
 drivers/axi/sandbox_store.c   | 110 ++
 include/axi.h |  84 
 include/dm/uclass-id.h|   1 +
 7 files changed, 350 insertions(+)
 create mode 100644 drivers/axi/axi-emul-uclass.c
 create mode 100644 drivers/axi/axi_sandbox.c
 create mode 100644 drivers/axi/sandbox_store.c

diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig
index ae80c98af8a..f81d843f894 100644
--- a/drivers/axi/Kconfig
+++ b/drivers/axi/Kconfig
@@ -22,4 +22,11 @@ config IHS_AXI
  Interface (IHS AXI) bus on a gdsys IHS FPGA used to communicate with
  IP cores in the FPGA (e.g. video transmitter cores).

+config AXI_SANDBOX
+   bool "Enable AXI sandbox driver"
+   depends on DM
+   help
+ Support AXI (Advanced eXtensible Interface) emulation for the sandbox
+ environment.
+
 endif
diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile
index 18d9380e9ba..66b6c5a28f4 100644
--- a/drivers/axi/Makefile
+++ b/drivers/axi/Makefile
@@ -7,3 +7,6 @@

 obj-$(CONFIG_AXI) += axi-uclass.o
 obj-$(CONFIG_IHS_AXI) += ihs_axi.o
+obj-$(CONFIG_SANDBOX) += axi-emul-uclass.o
+obj-$(CONFIG_SANDBOX) += sandbox_store.o
+obj-$(CONFIG_AXI_SANDBOX) += axi_sandbox.o
diff --git a/drivers/axi/axi-emul-uclass.c b/drivers/axi/axi-emul-uclass.c
new file mode 100644
index 000..8d37935323f
--- /dev/null
+++ b/drivers/axi/axi-emul-uclass.c
@@ -0,0 +1,68 @@
+/*
+ * (C) Copyright 2018
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int axi_sandbox_get_emul(struct udevice *bus, ulong address, enum axi_size_t 
size,
+struct udevice **emulp)
+{
+   struct udevice *dev;
+   u32 reg[2];
+   uint offset;
+
+   switch (size) {
+   case AXI_SIZE_8:
+   offset = 1;
+   break;
+   case AXI_SIZE_16:
+   offset = 2;
+   break;
+   case AXI_SIZE_32:
+   offset = 4;
+   break;
+   default:
+   offset = 0;
+   }
+
+   for (device_find_first_child(bus, );
+dev;
+device_find_next_child()) {
+   int ret;
+
+   ret = dev_read_u32_array(dev, "reg", reg, ARRAY_SIZE(reg));
+   if (ret)
+   continue;
+
+   if (address >= reg[0] && address <= reg[0] + reg[1] - offset) {
+   if (device_probe(dev))
+   return -ENODEV;
+
+   *emulp = dev;
+   return 0;
+   }
+   }
+
+   return -ENODEV;
+}
+
+int axi_get_store(struct udevice *dev, u8 **storep)
+{
+   struct axi_emul_ops *ops = axi_emul_get_ops(dev);
+
+   if (!ops->get_store)
+   return -ENOSYS;
+
+   return ops->get_store(dev, storep);
+}
+
+UCLASS_DRIVER(axi_emul) = {
+   .id = UCLASS_AXI_EMUL,
+   .name   = "axi_emul",
+};
diff --git a/drivers/axi/axi_sandbox.c b/drivers/axi/axi_sandbox.c
new file mode 100644
index 000..7a485b114bf
--- /dev/null
+++ b/drivers/axi/axi_sandbox.c
@@ -0,0 +1,77 @@
+/*
+ * (C) Copyright 2018
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * This driver implements a AXI bus for the sandbox architecture for testing
+ * purposes.
+ *
+ * The bus forwards every access to it to a special AXI emulation device (which
+ * it gets via the axi_emul_get_ops function) that implements a simple
+ * read/write storage.
+ *
+ * The emulator device must still be contained in the device tree in the usual
+ * way, since configuration data for the storage is read from the DT.
+ */
+
+int axi_sandbox_read(struct udevice *bus, ulong address, void *data,
+enum axi_size_t size)
+{
+   struct axi_emul_ops *ops;
+   struct udevice *emul;
+   int ret;
+
+   /* Get emulator device */
+   ret = axi_sandbox_get_emul(bus, address, size, );
+   if (ret)
+   return ret == -ENODEV ? 0 : ret;
+   /* Forward all reads to the AXI emulator */
+   ops = axi_emul_get_ops(emul);
+   if (!ops || !ops->read)
+   return -ENOSYS;
+
+   return ops->read(emul, address, data, size);
+}
+
+int 

[U-Boot] [PATCH v2 6/7] cmd: Add axi command

2018-05-23 Thread Mario Six
Add a command to debug the AXI bus.

Signed-off-by: Mario Six 

---

v1 -> v2:
No changes

---
 cmd/Kconfig  |   8 ++
 cmd/Makefile |   1 +
 cmd/axi.c| 310 +++
 3 files changed, 319 insertions(+)
 create mode 100644 cmd/axi.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 38406fcfdac..0f730f7a397 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -995,6 +995,14 @@ config CMD_USB_MASS_STORAGE
help
  USB mass storage support

+config CMD_AXI
+   bool "axi"
+   depends on AXI
+   help
+ Enable the command "axi" for accessing AXI (Advanced eXtensible
+ Interface) busses, a on-chip interconnect specification for managing
+ functional blocks in SoC designs, which is also often used in designs
+ involving FPGAs (e.g.  communication with IP cores in Xilinx FPGAs).
 endmenu


diff --git a/cmd/Makefile b/cmd/Makefile
index 0d7322ee0a4..cfca11499ec 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_CMD_ZFS) += zfs.o
 obj-$(CONFIG_CMD_DFU) += dfu.o
 obj-$(CONFIG_CMD_GPT) += gpt.o
 obj-$(CONFIG_CMD_ETHSW) += ethsw.o
+obj-$(CONFIG_CMD_AXI) += axi.o

 # Power
 obj-$(CONFIG_CMD_PMIC) += pmic.o
diff --git a/cmd/axi.c b/cmd/axi.c
new file mode 100644
index 000..d8001875e2c
--- /dev/null
+++ b/cmd/axi.c
@@ -0,0 +1,310 @@
+/*
+ * (C) Copyright 2016
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
+ *
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct udevice *axi_cur_bus;
+static uint dp_last_size;
+static uint dp_last_addr;
+static uint dp_last_length = 0x40;
+
+static void show_bus(struct udevice *bus)
+{
+   struct udevice *dev;
+
+   printf("Bus %d:\t%s", bus->req_seq, bus->name);
+   if (device_active(bus))
+   printf("  (active %d)", bus->seq);
+   printf("\n");
+   for (device_find_first_child(bus, );
+dev;
+device_find_next_child())
+   printf("  %s\n", dev->name);
+}
+
+static int do_axi_show_bus(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   if (argc == 1) {
+   /* show all busses */
+   struct udevice *bus;
+
+   for (uclass_first_device(UCLASS_AXI, );
+bus;
+uclass_next_device())
+   show_bus(bus);
+   } else {
+   int i;
+
+   /* show specific bus */
+   i = simple_strtoul(argv[1], NULL, 10);
+
+   struct udevice *bus;
+   int ret;
+
+   ret = uclass_get_device_by_seq(UCLASS_AXI, i, );
+   if (ret) {
+   printf("Invalid bus %d: err=%d\n", i, ret);
+   return CMD_RET_FAILURE;
+   }
+   show_bus(bus);
+   }
+
+   return 0;
+}
+
+static int cmd_axi_set_bus_num(unsigned int busnum)
+{
+   struct udevice *bus;
+   struct udevice *dummy;
+   int ret;
+
+   /* Make sure that all sequence numbers are initialized */
+   for (uclass_first_device(UCLASS_AXI, );
+dummy;
+uclass_next_device())
+   ;
+
+   ret = uclass_get_device_by_seq(UCLASS_AXI, busnum, );
+   if (ret) {
+   debug("%s: No bus %d\n", __func__, busnum);
+   return ret;
+   }
+   axi_cur_bus = bus;
+
+   return 0;
+}
+
+static int axi_get_cur_bus(struct udevice **busp)
+{
+   if (!axi_cur_bus) {
+   puts("No AXI bus selected\n");
+   return ENODEV;
+   }
+   *busp = axi_cur_bus;
+
+   return 0;
+}
+
+static int do_axi_bus_num(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+   int ret = 0;
+   int bus_no;
+
+   if (argc == 1) {
+   /* querying current setting */
+   struct udevice *bus;
+
+   if (!axi_get_cur_bus())
+   bus_no = bus->seq;
+   else
+   bus_no = -1;
+   printf("Current bus is %d\n", bus_no);
+   } else {
+   bus_no = simple_strtoul(argv[1], NULL, 10);
+   printf("Setting bus to %d\n", bus_no);
+
+   ret = cmd_axi_set_bus_num(bus_no);
+
+   if (ret)
+   printf("Failure changing bus number (%d)\n", ret);
+   }
+
+   return ret ? CMD_RET_FAILURE : 0;
+}
+
+#define DISP_LINE_LEN  16
+
+int do_axi_md(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   unsigned int k;
+   ulong addr, length, size;
+   int rc = 0;
+   u32 linebuf[DISP_LINE_LEN / sizeof(u32)];
+   ulong nbytes;
+   enum axi_size_t axisize;
+   int unitsize;
+
+  

[U-Boot] [PATCH v2 2/7] axi: Add ihs_axi driver

2018-05-23 Thread Mario Six
Add a driver for the gdsys IHS AXI bus used on IHS FPGAs.

Signed-off-by: Mario Six 

---

v1 -> v2:
New in v2

---
 drivers/axi/Kconfig   |  12 
 drivers/axi/Makefile  |   1 +
 drivers/axi/ihs_axi.c | 179 ++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/axi/ihs_axi.c

diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig
index 4e4153b4283..ae80c98af8a 100644
--- a/drivers/axi/Kconfig
+++ b/drivers/axi/Kconfig
@@ -11,3 +11,15 @@ menuconfig AXI
  for now).

  Other similar bus architectures may be compatible as well.
+
+if AXI
+
+config IHS_AXI
+   bool "Enable IHS AXI driver"
+   depends on DM
+   help
+ Support for gdsys Integrated Hardware Systems Advanced eXtensible
+ Interface (IHS AXI) bus on a gdsys IHS FPGA used to communicate with
+ IP cores in the FPGA (e.g. video transmitter cores).
+
+endif
diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile
index 100a77788a2..18d9380e9ba 100644
--- a/drivers/axi/Makefile
+++ b/drivers/axi/Makefile
@@ -6,3 +6,4 @@
 #

 obj-$(CONFIG_AXI) += axi-uclass.o
+obj-$(CONFIG_IHS_AXI) += ihs_axi.o
diff --git a/drivers/axi/ihs_axi.c b/drivers/axi/ihs_axi.c
new file mode 100644
index 000..21227638f78
--- /dev/null
+++ b/drivers/axi/ihs_axi.c
@@ -0,0 +1,179 @@
+/*
+ * (C) Copyright 2016
+ * Dirk Eibach,  Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
+ *
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct ihs_axi_regs {
+   u16 interrupt_status;
+   u16 interrupt_enable_control;
+   u16 address_lsb;
+   u16 address_msb;
+   u16 write_data_lsb;
+   u16 write_data_msb;
+   u16 read_data_lsb;
+   u16 read_data_msb;
+};
+
+#define ihs_axi_set(map, member, val) \
+   regmap_set(map, struct ihs_axi_regs, member, val)
+
+#define ihs_axi_get(map, member, valp) \
+   regmap_get(map, struct ihs_axi_regs, member, valp)
+
+struct ihs_axi_priv {
+   struct regmap *map;
+};
+
+enum {
+   STATUS_EVENT_MASK = GENMASK(15, 12),
+
+   STATUS_READ_COMPLETE_EVENT = BIT(15),
+   STATUS_WRITE_COMPLETE_EVENT = BIT(14),
+   STATUS_TIMEOUT_EVENT = BIT(13),
+   STATUS_ERROR_EVENT = BIT(12),
+   STATUS_AXI_INT = BIT(11),
+   STATUS_READ_DATA_AVAILABLE = BIT(7),
+   STATUS_BUSY = BIT(6),
+   STATUS_INIT_DONE = BIT(5),
+};
+
+enum {
+   CONTROL_EVENT_ENABLE_MASK = GENMASK(15, 11),
+   CONTROL_CMD_MASK = GENMASK(3, 0),
+
+   CONTROL_READ_COMPLETE_EVENT_ENABLE = BIT(15),
+   CONTROL_WRITE_COMPLETE_EVENT_ENABLE = BIT(14),
+   CONTROL_TIMEOUT_EVENT_ENABLE = BIT(13),
+   CONTROL_ERROR_EVENT_ENABLE = BIT(12),
+   CONTROL_AXI_INT_ENABLE = BIT(11),
+
+   CONTROL_CMD_NOP = 0x0,
+   CONTROL_CMD_WRITE = 0x8,
+   CONTROL_CMD_WRITE_POST_INC = 0x9,
+   CONTROL_CMD_READ = 0xa,
+   CONTROL_CMD_READ_POST_INC = 0xb,
+
+};
+
+static int ihs_axi_transfer(struct udevice *bus, ulong address, u16 cmd,
+   u16 complete_flag)
+{
+   struct ihs_axi_priv *priv = dev_get_priv(bus);
+   u16 wait_mask = complete_flag | STATUS_TIMEOUT_EVENT |
+   STATUS_ERROR_EVENT;
+   u16 status;
+   uint k;
+
+   cmd &= CONTROL_CMD_MASK;
+
+   ihs_axi_set(priv->map, address_lsb, address & 0x);
+   ihs_axi_set(priv->map, address_msb, (address >> 16) & 0x);
+
+   ihs_axi_set(priv->map, interrupt_status, wait_mask);
+   ihs_axi_set(priv->map, interrupt_enable_control, cmd);
+
+   for (k = 10; k > 0; --k) {
+   ihs_axi_get(priv->map, interrupt_status, );
+   if (status & wait_mask)
+   break;
+   udelay(1);
+   }
+
+   if (!k)
+   ihs_axi_get(priv->map, interrupt_status, );
+
+   if (status & complete_flag)
+   return 0;
+
+   if (status & STATUS_ERROR_EVENT)
+   return -EIO;
+
+   return -ETIMEDOUT;
+}
+
+/*
+ * API
+ */
+
+int ihs_axi_read(struct udevice *dev, ulong address, void *data,
+enum axi_size_t size)
+{
+   struct ihs_axi_priv *priv = dev_get_priv(dev);
+   int res = 0;
+   u16 data_lsb, data_msb;
+   u32 *p = data;
+
+   if (size != AXI_SIZE_32)
+   return -ENOSYS;
+
+   res = ihs_axi_transfer(dev, address, CONTROL_CMD_READ,
+  STATUS_READ_COMPLETE_EVENT);
+   if (res < 0)
+   return res;
+
+   ihs_axi_get(priv->map, read_data_lsb, _lsb);
+   ihs_axi_get(priv->map, read_data_msb, _msb);
+
+   *p = (data_msb << 16) | data_lsb;
+
+   return res;
+}
+
+int ihs_axi_write(struct udevice *dev, ulong address, void *data,
+ enum axi_size_t size)
+{
+   struct ihs_axi_priv 

[U-Boot] [PATCH v2 5/7] test: Add AXI test

2018-05-23 Thread Mario Six
Add tests for the AXI uclass.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Fixed asserts (moved expected values first)

---
 test/dm/Makefile |  1 +
 test/dm/axi.c| 74 
 2 files changed, 75 insertions(+)
 create mode 100644 test/dm/axi.c

diff --git a/test/dm/Makefile b/test/dm/Makefile
index 5511a85700c..de8b9940888 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -43,4 +43,5 @@ obj-$(CONFIG_DM_VIDEO) += video.o
 obj-$(CONFIG_ADC) += adc.o
 obj-$(CONFIG_SPMI) += spmi.o
 obj-$(CONFIG_WDT) += wdt.o
+obj-$(CONFIG_AXI) += axi.o
 endif
diff --git a/test/dm/axi.c b/test/dm/axi.c
new file mode 100644
index 000..cd31efd6126
--- /dev/null
+++ b/test/dm/axi.c
@@ -0,0 +1,74 @@
+/*
+ * (C) Copyright 2018
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Test that sandbox AXI works correctly */
+static int dm_test_axi_base(struct unit_test_state *uts)
+{
+   struct udevice *bus;
+
+   ut_assertok(uclass_get_device(UCLASS_AXI, 0, ));
+
+   return 0;
+}
+DM_TEST(dm_test_axi_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test that sandbox PCI bus numbering works correctly */
+static int dm_test_axi_busnum(struct unit_test_state *uts)
+{
+   struct udevice *bus;
+
+   ut_assertok(uclass_get_device_by_seq(UCLASS_AXI, 0, ));
+
+   return 0;
+}
+DM_TEST(dm_test_axi_busnum, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test that we can use the store device correctly */
+static int dm_test_axi_store(struct unit_test_state *uts)
+{
+   struct udevice *store;
+   u8 tdata1[] = {0x55, 0x66, 0x77, 0x88};
+   u8 tdata2[] = {0xAA, 0xBB, 0xCC, 0xDD};
+   u32 val;
+   u8 *data;
+
+   /* Check that asking for the device automatically fires up AXI */
+   ut_assertok(uclass_get_device(UCLASS_AXI_EMUL, 0, ));
+   ut_assert(device_active(store));
+
+   axi_get_store(store, );
+
+   /* Test reading */
+   memcpy(data, tdata1, ARRAY_SIZE(tdata1));
+   axi_read(store, 0, , AXI_SIZE_32);
+   ut_asserteq(0x55667788, val);
+
+   memcpy(data + 3, tdata2, ARRAY_SIZE(tdata2));
+   axi_read(store, 3, , AXI_SIZE_32);
+   ut_asserteq(0xAABBCCDD, val);
+
+   /* Reset data store */
+   memset(data, 0, 16);
+
+   /* Test writing */
+   val = 0x55667788;
+   axi_write(store, 0, , AXI_SIZE_32);
+   ut_asserteq(0, memcmp(data, tdata1, ARRAY_SIZE(tdata1)));
+
+   val = 0xAABBCCDD;
+   axi_write(store, 3, , AXI_SIZE_32);
+   ut_asserteq(0, memcmp(data + 3, tdata2, ARRAY_SIZE(tdata1)));
+
+   return 0;
+}
+DM_TEST(dm_test_axi_store, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.11.0

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


[U-Boot] [PATCH v2 1/7] drivers: Add AXI uclass

2018-05-23 Thread Mario Six
Add a uclass for AXI (Advanced eXtensible Interface) busses, and a
driver for the gdsys IHS AXI bus on IHS FPGAs.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Spelled out all abbreviations in the Kconfig help
* Split commit into uclass addition and driver addition

---
 drivers/Kconfig  |  2 ++
 drivers/Makefile |  1 +
 drivers/axi/Kconfig  | 13 +
 drivers/axi/Makefile |  8 ++
 drivers/axi/axi-uclass.c | 40 ++
 include/axi.h| 75 
 include/dm/uclass-id.h   |  1 +
 7 files changed, 140 insertions(+)
 create mode 100644 drivers/axi/Kconfig
 create mode 100644 drivers/axi/Makefile
 create mode 100644 drivers/axi/axi-uclass.c
 create mode 100644 include/axi.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c2e813f5adf..eeaaa7575cd 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -8,6 +8,8 @@ source "drivers/adc/Kconfig"

 source "drivers/ata/Kconfig"

+source "drivers/axi/Kconfig"
+
 source "drivers/block/Kconfig"

 source "drivers/bootcount/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index b3f1b600a55..54b396d6368 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -99,6 +99,7 @@ obj-y += input/
 obj-y += soc/
 obj-$(CONFIG_REMOTEPROC) += remoteproc/
 obj-y += thermal/
+obj-y += axi/

 obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
 endif
diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig
new file mode 100644
index 000..4e4153b4283
--- /dev/null
+++ b/drivers/axi/Kconfig
@@ -0,0 +1,13 @@
+menuconfig AXI
+   bool "AXI bus drivers"
+   help
+ Support AXI (Advanced eXtensible Interface) busses, a on-chip
+ interconnect specification for managing functional blocks in SoC
+ designs, which is also often used in designs involving FPGAs (e.g.
+ communication with IP cores in Xilinx FPGAs).
+
+ These types of busses expose a virtual address space that can be
+ accessed using different address widths (8, 16, and 32 are supported
+ for now).
+
+ Other similar bus architectures may be compatible as well.
diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile
new file mode 100644
index 000..100a77788a2
--- /dev/null
+++ b/drivers/axi/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2017
+# Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_AXI) += axi-uclass.o
diff --git a/drivers/axi/axi-uclass.c b/drivers/axi/axi-uclass.c
new file mode 100644
index 000..3a5ddf3a46a
--- /dev/null
+++ b/drivers/axi/axi-uclass.c
@@ -0,0 +1,40 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+int axi_read(struct udevice *dev, ulong address, void *data,
+enum axi_size_t size)
+{
+   struct axi_ops *ops = axi_get_ops(dev);
+
+   if (!ops->read)
+   return -ENOSYS;
+
+   return ops->read(dev, address, data, size);
+}
+
+int axi_write(struct udevice *dev, ulong address, void *data,
+ enum axi_size_t size)
+{
+   struct axi_ops *ops = axi_get_ops(dev);
+
+   if (!ops->write)
+   return -ENOSYS;
+
+   return ops->write(dev, address, data, size);
+}
+
+UCLASS_DRIVER(axi) = {
+   .id = UCLASS_AXI,
+   .name   = "axi",
+   .post_bind  = dm_scan_fdt_dev,
+   .flags  = DM_UC_FLAG_SEQ_ALIAS,
+};
+
diff --git a/include/axi.h b/include/axi.h
new file mode 100644
index 000..317e931a6cf
--- /dev/null
+++ b/include/axi.h
@@ -0,0 +1,75 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _AXI_H_
+#define _AXI_H_
+
+enum axi_size_t {
+   AXI_SIZE_8,
+   AXI_SIZE_16,
+   AXI_SIZE_32,
+};
+
+/**
+ * struct axi_ops - driver operations for AXI uclass
+ *
+ * Drivers should support these operations unless otherwise noted. These
+ * operations are intended to be used by uclass code, not directly from
+ * other code.
+ */
+struct axi_ops {
+   /**
+* read() - Read a single value from a specified address on a AXI bus
+*
+* @dev:AXI bus to read from.
+* @address:The address to read from.
+* @data:   Pointer to a variable that takes the data value read
+*  from the address on the AXI bus.
+* @size:   The size of the data to be read.
+* @return 0 if OK, -ve on error.
+*/
+   int (*read)(struct udevice *dev, ulong address, void *data, enum 
axi_size_t size);
+
+   /**
+* write() - Write a single value to a specified address on a AXI bus
+*
+* @dev:AXI bus to write to.
+* @address:The address to write to.
+* @data:   

[U-Boot] [PATCH v2 5/5] cmd: Add osd commands

2018-05-23 Thread Mario Six
Add command to query information from and write text to on-screen
display (OSD) devices.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Added explanation for what a OSD is
* Added explanation of the color parameter
* Moved GDSYS_LEGACY_OSD_CMDS to gdsys Kconfig

---
 board/gdsys/mpc8308/Kconfig |  11 ++
 cmd/Kconfig |   8 +
 cmd/Makefile|   1 +
 cmd/osd.c   | 378 
 4 files changed, 398 insertions(+)
 create mode 100644 cmd/osd.c

diff --git a/board/gdsys/mpc8308/Kconfig b/board/gdsys/mpc8308/Kconfig
index cb29c25c650..9d99f686923 100644
--- a/board/gdsys/mpc8308/Kconfig
+++ b/board/gdsys/mpc8308/Kconfig
@@ -1,3 +1,9 @@
+config GDSYS_LEGACY_OSD_CMDS
+   bool
+   help
+ Use the 'osdw', 'osdp', and 'osdsize' legacy commands required by
+ gdsys devices.
+
 if TARGET_HRCON

 config SYS_BOARD
@@ -9,6 +15,9 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "hrcon"

+config GDSYS_LEGACY_OSD_CMDS
+   default y
+
 endif

 if TARGET_STRIDER
@@ -22,6 +31,8 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "strider"

+config GDSYS_LEGACY_OSD_CMDS
+   default y
 endif

 config CMD_IOLOOP
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 38406fcfdac..898839c8d75 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -865,6 +865,14 @@ config CMD_ONENAND
  and erasing blocks. It allso provides a way to show and change
  bad blocks, and test the device.

+config CMD_OSD
+   bool "osd"
+   help
+ Enable the 'osd' command which allows to query information from and
+ write text data to a on-screen display (OSD) device; a virtual device
+ associated with a display capable of displaying a text overlay on the
+ display it's associated with..
+
 config CMD_PART
bool "part"
select PARTITION_UUIDS
diff --git a/cmd/Makefile b/cmd/Makefile
index 0d7322ee0a4..4aeab8e5c77 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_CMD_FUSE) += fuse.o
 obj-$(CONFIG_CMD_GETTIME) += gettime.o
 obj-$(CONFIG_CMD_GPIO) += gpio.o
 obj-$(CONFIG_CMD_HVC) += smccc.o
+obj-$(CONFIG_CMD_OSD) += osd.o
 obj-$(CONFIG_CMD_I2C) += i2c.o
 obj-$(CONFIG_CMD_IOTRACE) += iotrace.o
 obj-$(CONFIG_CMD_HASH) += hash.o
diff --git a/cmd/osd.c b/cmd/osd.c
new file mode 100644
index 000..8afbe85475b
--- /dev/null
+++ b/cmd/osd.c
@@ -0,0 +1,378 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * based on the gdsys osd driver, which is
+ *
+ * (C) Copyright 2010
+ * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_GDSYS_LEGACY_OSD_CMDS
+static struct udevice *osd_cur;
+#endif
+
+#ifdef CONFIG_GDSYS_LEGACY_OSD_CMDS
+int do_osd_write(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   struct udevice *dev;
+   uint x, y;
+   uint count;
+   char *hexstr;
+   u8 *buffer;
+   size_t buflen;
+
+   if (argc < 4 || (strlen(argv[3])) % 2) {
+   cmd_usage(cmdtp);
+   return CMD_RET_FAILURE;
+   }
+
+   x = simple_strtoul(argv[1], NULL, 16);
+   y = simple_strtoul(argv[2], NULL, 16);
+   hexstr = argv[3];
+   count = (argc > 4) ? simple_strtoul(argv[4], NULL, 16) : 1;
+
+   buflen = strlen(hexstr) / 2;
+   buffer = malloc(buflen);
+   hex2bin(buffer, hexstr, buflen);
+
+   for (uclass_first_device(UCLASS_VIDEO_OSD, );
+dev;
+uclass_next_device()) {
+   int res;
+
+   res = video_osd_set_mem(dev, x, y, buffer, buflen, count);
+
+   if (res) {
+   printf("Could not write to video mem on osd %s\n",
+  dev->name);
+   return CMD_RET_FAILURE;
+   }
+   }
+
+   free(buffer);
+
+   return CMD_RET_SUCCESS;
+}
+
+static int do_osd_print(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   struct udevice *dev;
+   uint x, y;
+   u8 color;
+   char *text;
+
+   if (argc < 5) {
+   cmd_usage(cmdtp);
+   return CMD_RET_FAILURE;
+   }
+
+   x = simple_strtoul(argv[1], NULL, 16);
+   y = simple_strtoul(argv[2], NULL, 16);
+   color = simple_strtoul(argv[3], NULL, 16);
+   text = argv[4];
+
+   for (uclass_first_device(UCLASS_VIDEO_OSD, );
+dev;
+uclass_next_device()) {
+   int res;
+
+   res = video_osd_print(dev, x, y, color, text);
+   if (res) {
+   printf("Could not print string to osd %s\n", dev->name);
+   return CMD_RET_FAILURE;
+   }
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
+int do_osd_size(cmd_tbl_t *cmdtp, 

[U-Boot] [PATCH v2 3/5] video_osd: Add osd sandbox driver and tests

2018-05-23 Thread Mario Six
Add sandbox driver and tests for the new OSD uclass.

Signed-off-by: Mario Six 

---

v1 -> v2:
New in v2

---
 arch/sandbox/dts/test.dts  |   4 +
 configs/sandbox64_defconfig|   3 +
 configs/sandbox_defconfig  |   3 +
 configs/sandbox_flattree_defconfig |   3 +
 configs/sandbox_noblk_defconfig|   3 +
 configs/sandbox_spl_defconfig  |   3 +
 drivers/video/Kconfig  |   6 ++
 drivers/video/Makefile |   1 +
 drivers/video/sandbox_osd.c| 157 
 drivers/video/sandbox_osd.h|  14 +++
 drivers/video/video_osd-uclass.c   |   9 ++
 include/video_osd.h|   7 ++
 test/dm/Makefile   |   1 +
 test/dm/osd.c  | 208 +
 14 files changed, 422 insertions(+)
 create mode 100644 drivers/video/sandbox_osd.c
 create mode 100644 drivers/video/sandbox_osd.h
 create mode 100644 test/dm/osd.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5a0f187d8b7..b6cdda0fd33 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -559,6 +559,10 @@
};
};
};
+
+   osd {
+   compatible = "sandbox,sandbox_osd";
+   };
 };

 #include "sandbox_pmic.dtsi"
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 20a2ab3ffb7..7464a3ca3af 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -39,6 +39,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_GPT_RENAME=y
 CONFIG_CMD_IDE=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_OSD=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_READ=y
 CONFIG_CMD_REMOTEPROC=y
@@ -185,6 +186,8 @@ CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
 CONFIG_VIDEO_SANDBOX_SDL=y
+CONFIG_OSD=y
+CONFIG_SANDBOX_OSD=y
 CONFIG_WDT=y
 CONFIG_WDT_SANDBOX=y
 CONFIG_FS_CBFS=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 2fc84a16c91..f7925dfe6fb 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -39,6 +39,7 @@ CONFIG_CMD_GPT=y
 CONFIG_CMD_GPT_RENAME=y
 CONFIG_CMD_IDE=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_OSD=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_READ=y
 CONFIG_CMD_REMOTEPROC=y
@@ -186,6 +187,8 @@ CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
 CONFIG_VIDEO_SANDBOX_SDL=y
+CONFIG_OSD=y
+CONFIG_SANDBOX_OSD=y
 CONFIG_WDT=y
 CONFIG_WDT_SANDBOX=y
 CONFIG_FS_CBFS=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index e922c4b38ff..126b9c07c54 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -31,6 +31,7 @@ CONFIG_CMD_DEMO=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_OSD=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
@@ -167,6 +168,8 @@ CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
 CONFIG_VIDEO_SANDBOX_SDL=y
+CONFIG_OSD=y
+CONFIG_SANDBOX_OSD=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 CONFIG_LZ4=y
diff --git a/configs/sandbox_noblk_defconfig b/configs/sandbox_noblk_defconfig
index 8bdd4edcda6..243234b6c72 100644
--- a/configs/sandbox_noblk_defconfig
+++ b/configs/sandbox_noblk_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_IDE=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_OSD=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
@@ -166,6 +167,8 @@ CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
 CONFIG_VIDEO_SANDBOX_SDL=y
+CONFIG_OSD=y
+CONFIG_SANDBOX_OSD=y
 CONFIG_FS_CBFS=y
 CONFIG_FS_CRAMFS=y
 CONFIG_CMD_DHRYSTONE=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index fb6bb4baa2b..771d0f05a48 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -43,6 +43,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_IDE=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_OSD=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
@@ -185,6 +186,8 @@ CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
 CONFIG_VIDEO_SANDBOX_SDL=y
+CONFIG_OSD=y
+CONFIG_SANDBOX_OSD=y
 CONFIG_FS_CBFS=y
 CONFIG_FS_CRAMFS=y
 CONFIG_CMD_DHRYSTONE=y
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4ca15174bb2..b1a8e05ad74 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -667,6 +667,12 @@ config OSD
   is a (usually text-oriented) graphics buffer to show information on
   a display.

+config SANDBOX_OSD
+   bool "Enable sandbox OSD"
+   depends on OSD
+   help
+ Enable support for sandbox OSD device used for testing purposes.
+
 config IHS_VIDEO_OUT
bool "Enable IHS video out driver"
depends on OSD
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 44252b5989a..80a8b19ed5d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -56,6 

[U-Boot] [PATCH v2 4/5] lib: Import hexdump.c from Linux

2018-05-23 Thread Mario Six
Especially for commands, it is useful to be able to turn a hexadecimal
string into its binary representation.

Hence, import the hex_to_bin, bin2hex, and hex2bin functions from the
Linux kernel.

Signed-off-by: Mario Six 

---

v1 -> v2:
New in v2

---
 include/linux/kernel.h |   4 +
 lib/Makefile   |   1 +
 lib/hexdump.c  | 321 +
 3 files changed, 326 insertions(+)
 create mode 100644 lib/hexdump.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 04a09eb4f64..ea31759667c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -150,6 +150,10 @@
(__x < 0) ? -__x : __x; \
})

+extern int hex_to_bin(char ch);
+extern int __must_check hex2bin(u8 *dst, const char *src, size_t count);
+extern char *bin2hex(char *dst, const void *src, size_t count);
+
 /*
  * min()/max()/clamp() macros that also do
  * strict type-checking.. See the
diff --git a/lib/Makefile b/lib/Makefile
index d531ea54b31..0f6d744579f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o
 obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
 obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
 obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o
+obj-y += hexdump.o
 obj-y += initcall.o
 obj-$(CONFIG_LMB) += lmb.o
 obj-y += ldiv.o
diff --git a/lib/hexdump.c b/lib/hexdump.c
new file mode 100644
index 000..81587c2ee75
--- /dev/null
+++ b/lib/hexdump.c
@@ -0,0 +1,321 @@
+/*
+ * lib/hexdump.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation. See README and COPYING for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+const char hex_asc[] = "0123456789abcdef";
+EXPORT_SYMBOL(hex_asc);
+const char hex_asc_upper[] = "0123456789ABCDEF";
+EXPORT_SYMBOL(hex_asc_upper);
+
+#define hex_asc_lo(x)  hex_asc[((x) & 0x0f)]
+#define hex_asc_hi(x)  hex_asc[((x) & 0xf0) >> 4]
+
+static inline char *hex_byte_pack(char *buf, u8 byte)
+{
+   *buf++ = hex_asc_hi(byte);
+   *buf++ = hex_asc_lo(byte);
+   return buf;
+}
+
+extern const char hex_asc_upper[];
+#define hex_asc_upper_lo(x)hex_asc_upper[((x) & 0x0f)]
+#define hex_asc_upper_hi(x)hex_asc_upper[((x) & 0xf0) >> 4]
+
+static inline char *hex_byte_pack_upper(char *buf, u8 byte)
+{
+   *buf++ = hex_asc_upper_hi(byte);
+   *buf++ = hex_asc_upper_lo(byte);
+   return buf;
+}
+
+/**
+ * hex_to_bin - convert a hex digit to its real value
+ * @ch: ascii character represents hex digit
+ *
+ * hex_to_bin() converts one hex digit to its actual value or -1 in case of bad
+ * input.
+ */
+int hex_to_bin(char ch)
+{
+   if ((ch >= '0') && (ch <= '9'))
+   return ch - '0';
+   ch = tolower(ch);
+   if ((ch >= 'a') && (ch <= 'f'))
+   return ch - 'a' + 10;
+   return -1;
+}
+EXPORT_SYMBOL(hex_to_bin);
+
+/**
+ * hex2bin - convert an ascii hexadecimal string to its binary representation
+ * @dst: binary result
+ * @src: ascii hexadecimal string
+ * @count: result length
+ *
+ * Return 0 on success, -EINVAL in case of bad input.
+ */
+int hex2bin(u8 *dst, const char *src, size_t count)
+{
+   while (count--) {
+   int hi = hex_to_bin(*src++);
+   int lo = hex_to_bin(*src++);
+
+   if ((hi < 0) || (lo < 0))
+   return -EINVAL;
+
+   *dst++ = (hi << 4) | lo;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(hex2bin);
+
+/**
+ * bin2hex - convert binary data to an ascii hexadecimal string
+ * @dst: ascii hexadecimal result
+ * @src: binary data
+ * @count: binary data length
+ */
+char *bin2hex(char *dst, const void *src, size_t count)
+{
+   const unsigned char *_src = src;
+
+   while (count--)
+   dst = hex_byte_pack(dst, *_src++);
+   return dst;
+}
+EXPORT_SYMBOL(bin2hex);
+
+/**
+ * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
+ * @buf: data blob to dump
+ * @len: number of bytes in the @buf
+ * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
+ * @linebuf: where to put the converted data
+ * @linebuflen: total size of @linebuf, including space for terminating NUL
+ * @ascii: include ASCII after the hex output
+ *
+ * hex_dump_to_buffer() works on one "line" of output at a time, i.e.,
+ * 16 or 32 bytes of input data converted to hex + ASCII output.
+ *
+ * Given a buffer of u8 data, hex_dump_to_buffer() converts the input data
+ * to a hex + ASCII dump at the supplied memory location.
+ * The converted output is always NUL-terminated.
+ *
+ * E.g.:
+ *   hex_dump_to_buffer(frame->data, frame->len, 16, 1,
+ * linebuf, sizeof(linebuf), true);
+ *
+ * example 

[U-Boot] [PATCH v2 1/5] drivers: Add OSD uclass

2018-05-23 Thread Mario Six
Some devices offer a text-based OSD (on-screen display) that can be
programmatically controlled (i.e. text displayed on).

Add a uclass to support such devices.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Use singular case for UCLASS_VIDEO_OSD description
* Expanded description of video_osd_set_mem with example
* Replaced all left-over mentions of pixels with text
* Renamed x and y parameters to col and row
* Expaneded description of color parameter
* Added general description of the OSD uclass
* Expanded description of video_osd_info

---
 drivers/video/Kconfig|   8 ++
 drivers/video/Makefile   |   2 +
 drivers/video/video_osd-uclass.c |  46 ++
 include/dm/uclass-id.h   |   1 +
 include/video_osd.h  | 193 +++
 5 files changed, 250 insertions(+)
 create mode 100644 drivers/video/video_osd-uclass.c
 create mode 100644 include/video_osd.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c4d2861fe7..37be23d2fcc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -658,4 +658,12 @@ config VIDEO_DT_SIMPLEFB
  The video output is initialized by U-Boot, and kept by the
  kernel.

+config OSD
+   bool "Enable OSD support"
+   depends on DM
+   default n
+   help
+  This supports drivers that provide a OSD (on-screen display), which
+  is a (usually text-oriented) graphics buffer to show information on
+  a display.
 endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index cf7ad281c3b..1889c5a5208 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -55,5 +55,7 @@ obj-${CONFIG_EXYNOS_FB} += exynos/
 obj-${CONFIG_VIDEO_ROCKCHIP} += rockchip/
 obj-${CONFIG_VIDEO_STM32} += stm32/

+obj-${CONFIG_OSD} += video_osd-uclass.o
+
 obj-y += bridge/
 obj-y += sunxi/
diff --git a/drivers/video/video_osd-uclass.c b/drivers/video/video_osd-uclass.c
new file mode 100644
index 000..ae9b6a6fa82
--- /dev/null
+++ b/drivers/video/video_osd-uclass.c
@@ -0,0 +1,46 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+int video_osd_get_info(struct udevice *dev, struct video_osd_info *info)
+{
+   struct video_osd_ops *ops = video_osd_get_ops(dev);
+
+   return ops->get_info(dev, info);
+}
+
+int video_osd_set_mem(struct udevice *dev, uint col, uint row, u8 *buf,
+ size_t buflen, uint count)
+{
+   struct video_osd_ops *ops = video_osd_get_ops(dev);
+
+   return ops->set_mem(dev, col, row, buf, buflen, count);
+}
+
+int video_osd_set_size(struct udevice *dev, uint col, uint row)
+{
+   struct video_osd_ops *ops = video_osd_get_ops(dev);
+
+   return ops->set_size(dev, col, row);
+}
+
+int video_osd_print(struct udevice *dev, uint col, uint row, ulong color,
+   char *text)
+{
+   struct video_osd_ops *ops = video_osd_get_ops(dev);
+
+   return ops->print(dev, col, row, color, text);
+}
+
+UCLASS_DRIVER(video_osd) = {
+   .id = UCLASS_VIDEO_OSD,
+   .name   = "video_osd",
+   .flags  = DM_UC_FLAG_SEQ_ALIAS,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index d7f9df3583a..e42f8481bf8 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -89,6 +89,7 @@ enum uclass_id {
UCLASS_VIDEO,   /* Video or LCD device */
UCLASS_VIDEO_BRIDGE,/* Video bridge, e.g. DisplayPort to LVDS */
UCLASS_VIDEO_CONSOLE,   /* Text console driver for video device */
+   UCLASS_VIDEO_OSD,   /* On-screen display */
UCLASS_WDT, /* Watchdot Timer driver */

UCLASS_COUNT,
diff --git a/include/video_osd.h b/include/video_osd.h
new file mode 100644
index 000..c3bcd3a4fd8
--- /dev/null
+++ b/include/video_osd.h
@@ -0,0 +1,193 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _VIDEO_OSD_H_
+#define _VIDEO_OSD_H_
+
+struct video_osd_info {
+   /* The width of the OSD display in columns */
+   uint width;
+   /* The height of the OSD display in rows */
+   uint height;
+   /* The major version of the OSD device */
+   uint major_version;
+   /* The minor version of the OSD device */
+   uint minor_version;
+};
+
+/**
+ * struct video_osd_ops - driver operations for OSD uclass
+ *
+ * The OSD uclass implements support for text-oriented on-screen displays,
+ * which are taken to be devices that independently display a graphical
+ * text-based overlay over the video output of an associated display.
+ *
+ * The functions defined by the uclass support writing text to the display in
+ * either a generic form (by specifying a string, a driver-specific color value
+ * for the text, and 

[U-Boot] [PATCH v2 2/5] video_osd: Add ihs_video_out driver

2018-05-23 Thread Mario Six
Add a driver for IHS OSDs on IHS FPGAs.

Signed-off-by: Mario Six 

---

v1 -> v2:
* Renamed x and y parameters to col and row
* Removed duplicate IHS_VIDEO_OUT definition
* Switched error return code of ihs_video_out_set_mem to E2BIG
* Dropped blank lines between dev_read_u32_default calls
* Documented members of ihs_video_out_priv
* Turned printfs into debugs
* Don't display OSD until something has been written to it
* Made the code a bit more readable
* Added binding file
* Expanded documentation and help
* Switched to display_enable
* Switched to regmap usage (instead of fpgamap uclass)
* Renamed 'dp_tx' property to 'video_tx'

---
 .../video/osd/gdsys,ihs_video_out.txt  |  22 ++
 drivers/video/Kconfig  |   9 +
 drivers/video/Makefile |   1 +
 drivers/video/ihs_video_out.c  | 277 +
 4 files changed, 309 insertions(+)
 create mode 100644 doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
 create mode 100644 drivers/video/ihs_video_out.c

diff --git a/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt 
b/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
new file mode 100644
index 000..464374613b8
--- /dev/null
+++ b/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
@@ -0,0 +1,22 @@
+* Guntermann & Drunck Integrated Hardware Systems OSD
+
+Required properties:
+- compatible: "gdsys,ihs_video_out"
+- reg: Register base for the video registers
+- osd_base: Register base for the OSD registers
+- osd_buffer_base: Address of the OSD video memory
+- mode: The initial resolution and frequency: "1024_768_60", "720_400_70", or
+"640_480_70"
+- clk_gen: phandle to the pixel clock generator
+- dp_tx: phandle to the display associated with the OSD
+
+Example:
+
+fpga0_video0 {
+   compatible = "gdsys,ihs_video_out";
+   reg = <0x100 0x40>;
+   osd_base = <0x180>;
+   osd_buffer_base = <0x1000>;
+   dp_tx = <_dp_video0>;
+   clk_gen = <_video0_clkgen>;
+};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 37be23d2fcc..4ca15174bb2 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -666,4 +666,13 @@ config OSD
   This supports drivers that provide a OSD (on-screen display), which
   is a (usually text-oriented) graphics buffer to show information on
   a display.
+
+config IHS_VIDEO_OUT
+   bool "Enable IHS video out driver"
+   depends on OSD
+   help
+ Enable support for the gdsys Integrated Hardware Systems (IHS) video
+ out On-screen Display (OSD) used on gdsys FPGAs to control dynamic
+ textual overlays of the display outputs.
+
 endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 1889c5a5208..44252b5989a 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -56,6 +56,7 @@ obj-${CONFIG_VIDEO_ROCKCHIP} += rockchip/
 obj-${CONFIG_VIDEO_STM32} += stm32/

 obj-${CONFIG_OSD} += video_osd-uclass.o
+obj-$(CONFIG_IHS_VIDEO_OUT) += ihs_video_out.o

 obj-y += bridge/
 obj-y += sunxi/
diff --git a/drivers/video/ihs_video_out.c b/drivers/video/ihs_video_out.c
new file mode 100644
index 000..3a870e22c2e
--- /dev/null
+++ b/drivers/video/ihs_video_out.c
@@ -0,0 +1,277 @@
+/*
+ * (C) Copyright 2017
+ * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+ *
+ * based on the gdsys osd driver, which is
+ *
+ * (C) Copyright 2010
+ * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_X_CHARS 53
+#define MAX_Y_CHARS 26
+#define MAX_VIDEOMEM_WIDTH (2 * 64)
+#define MAX_VIDEOMEM_HEIGHT (2 * 32)
+#define CHAR_WIDTH 12
+#define CHAR_HEIGHT 18
+
+struct ihs_video_out_regs {
+   u16 versions;
+   u16 features;
+   u16 control;
+   u16 xy_size;
+   u16 xy_scale;
+   u16 x_pos;
+   u16 y_pos;
+};
+
+#define ihs_video_out_set(map, member, val) \
+   regmap_range_set(map, 1, struct ihs_video_out_regs, member, val)
+
+#define ihs_video_out_get(map, member, valp) \
+   regmap_range_get(map, 1, struct ihs_video_out_regs, member, valp)
+
+enum {
+   CONTROL_FILTER_BLACK = (0 << 0),
+   CONTROL_FILTER_ORIGINAL = (1 << 0),
+   CONTROL_FILTER_DARKER = (2 << 0),
+   CONTROL_FILTER_GRAY = (3 << 0),
+
+   CONTROL_MODE_PASSTHROUGH = (0 << 3),
+   CONTROL_MODE_OSD = (1 << 3),
+   CONTROL_MODE_AUTO = (2 << 3),
+   CONTROL_MODE_OFF = (3 << 3),
+
+   CONTROL_ENABLE_OFF = (0 << 6),
+   CONTROL_ENABLE_ON = (1 << 6),
+};
+
+struct ihs_video_out_priv {
+   /* Register map for OSD device */
+   struct regmap *map;
+   /* Pointer to video memory */
+   u16 *vidmem;
+   /* Display width in text columns */
+   uint base_width;
+   /* Display height in text rows */
+   uint base_height;

Re: [U-Boot] [PATCH] x86: tsc: add support for reading CPU freq from cpuid

2018-05-23 Thread Christian Gmeiner
Am Mi., 23. Mai 2018 um 11:48 Uhr schrieb Bin Meng :

> On Mon, May 14, 2018 at 5:32 PM, Christian Gmeiner
>  wrote:
> > Starting with cpuid level 0x16 (Skylake-based processors)
> > it is possible to get CPU base freq via cpuid.
> >
> > This fixes booting on a skylake based system.
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  drivers/timer/tsc_timer.c | 31 +--
> >  1 file changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
> > index c7fefd2031..96a3e55513 100644
> > --- a/drivers/timer/tsc_timer.c
> > +++ b/drivers/timer/tsc_timer.c
> > @@ -21,6 +21,17 @@
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > +static unsigned long cpu_mhz_from_cpuid(void)
> > +{
> > +   if (gd->arch.x86_vendor != X86_VENDOR_INTEL)
> > +   return 0;
> > +
> > +   if (cpuid_eax(0) < 0x16)
> > +   return 0;
> > +
> > +   return cpuid_eax(0x16);
> > +}
> > +
> >  /*
> >   * According to Intel 64 and IA-32 System Programming Guide,
> >   * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
> > @@ -343,14 +354,22 @@ static void tsc_timer_ensure_setup(void)
> > if (!gd->arch.clock_rate) {
> > unsigned long fast_calibrate;
> >
> > +   fast_calibrate = cpu_mhz_from_cpuid();
> > +   if (fast_calibrate)
> > +   goto done;
> > +
> > fast_calibrate = cpu_mhz_from_msr();
> > -   if (!fast_calibrate) {
> > -   fast_calibrate = quick_pit_calibrate();
> > -   if (!fast_calibrate)
> > -   panic("TSC frequency is ZERO");
> > -   }
> > +   if (fast_calibrate)
> > +   goto done;
> > +
> > +   fast_calibrate = quick_pit_calibrate();
> > +   if (fast_calibrate)
> > +   goto done;
> > +
> > +   panic("TSC frequency is ZERO");
> >
> > -   gd->arch.clock_rate = fast_calibrate * 100;
> > +   done:

> nits: this indention is wrong, and will cause checkpatch warnings.

Oops.

> > +   gd->arch.clock_rate = fast_calibrate * 100;
> > }
> >  }

> Reviewed-by: Bin Meng 

> I can fix the nits when applying.


That would be great - thanks!
-- 
greets
--
Christian Gmeiner, MSc

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


[U-Boot] [PATCH 2/2] dm: pci: use a 1:1 mapping for bus <-> phy addresses

2018-05-23 Thread Christian Gmeiner
If u-boot gets used as coreboot payload all pci resources got
assigned by coreboot. If a dts without any pci ranges gets used
the dm is not able to access pci device memory. To get things
working make use of a 1:1 mapping for bus <-> phy addresses.

This change makes it possible to get the e1000 u-boot driver
working on a sandybridge device where u-boot is used as coreboot
payload.

Signed-off-by: Christian Gmeiner 
---
 drivers/pci/pci-uclass.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 416444a230..9cec619bb2 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1175,6 +1175,11 @@ static int _dm_pci_bus_to_phys(struct udevice *ctlr,
struct pci_region *res;
int i;
 
+   if (hose->region_count == 0) {
+   *pa = bus_addr;
+   return 0;
+   }
+
for (i = 0; i < hose->region_count; i++) {
res = >regions[i];
 
@@ -1238,6 +1243,11 @@ int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t 
phys_addr,
ctlr = pci_get_controller(dev);
hose = dev_get_uclass_priv(ctlr);
 
+   if (hose->region_count == 0) {
+   *ba = phys_addr;
+   return 0;
+   }
+
for (i = 0; i < hose->region_count; i++) {
res = >regions[i];
 
-- 
2.17.0

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


[U-Boot] [PATCH 1/2] dm: pci: make ranges dt property optional

2018-05-23 Thread Christian Gmeiner
If we use u-boot as coreboot payload with a generic dts without
any ranges specified we fail in pci pre_probe and our pci bus
is not usable.

So convert decode_regions(..) into a void function and do the simple
error handling there.

Signed-off-by: Christian Gmeiner 
---
 drivers/pci/pci-uclass.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 49be1ebdd7..416444a230 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -810,7 +810,7 @@ error:
return ret;
 }
 
-static int decode_regions(struct pci_controller *hose, ofnode parent_node,
+static void decode_regions(struct pci_controller *hose, ofnode parent_node,
  ofnode node)
 {
int pci_addr_cells, addr_cells, size_cells;
@@ -820,8 +820,11 @@ static int decode_regions(struct pci_controller *hose, 
ofnode parent_node,
int i;
 
prop = ofnode_get_property(node, "ranges", );
-   if (!prop)
-   return -EINVAL;
+   if (!prop) {
+   debug("%s: Cannot decode regions\n", __func__);
+   return;
+   }
+
pci_addr_cells = ofnode_read_simple_addr_cells(node);
addr_cells = ofnode_read_simple_addr_cells(parent_node);
size_cells = ofnode_read_simple_size_cells(node);
@@ -876,7 +879,7 @@ static int decode_regions(struct pci_controller *hose, 
ofnode parent_node,
bd_t *bd = gd->bd;
 
if (!bd)
-   return 0;
+   return;
 
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
if (bd->bi_dram[i].size) {
@@ -901,13 +904,12 @@ static int decode_regions(struct pci_controller *hose, 
ofnode parent_node,
base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
 #endif
 
-   return 0;
+   return;
 }
 
 static int pci_uclass_pre_probe(struct udevice *bus)
 {
struct pci_controller *hose;
-   int ret;
 
debug("%s, bus=%d/%s, parent=%s\n", __func__, bus->seq, bus->name,
  bus->parent->name);
@@ -916,12 +918,7 @@ static int pci_uclass_pre_probe(struct udevice *bus)
/* For bridges, use the top-level PCI controller */
if (!device_is_on_pci_bus(bus)) {
hose->ctlr = bus;
-   ret = decode_regions(hose, dev_ofnode(bus->parent),
-dev_ofnode(bus));
-   if (ret) {
-   debug("%s: Cannot decode regions\n", __func__);
-   return ret;
-   }
+   decode_regions(hose, dev_ofnode(bus->parent), dev_ofnode(bus));
} else {
struct pci_controller *parent_hose;
 
-- 
2.17.0

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


Re: [U-Boot] [PATCH v3 00/10] Add Intel Stratix 10 SoC support

2018-05-23 Thread Marek Vasut
On 05/23/2018 06:17 PM, Ley Foon Tan wrote:
> This is 3rd version of patchset to adds support for Intel Stratix 10 SoC.
> This patchset is work on top of uboot.git/master and patchset in [1].
> 
> Changes:
> - rebase on uboot.git/master
> - update reviewed-by
> 
> Patchset history:
> [v1]: https://patchwork.ozlabs.org/cover/900499/
> [v2]: https://patchwork.ozlabs.org/cover/916060/
> 
> [1]: https://patchwork.ozlabs.org/cover/910018/

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] soc: zynqmp: Update required API version to 1.0

2018-05-23 Thread Marek Vasut
On 05/22/2018 06:44 PM, Manjukumar Harthikote Matha wrote:
[...]
>> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 (the
>> one on github, not the one on git.yoctoproject) without version which
>> provides the ABI 1.0 rather than the v2017.03 one from meta-xilinx
>> rel-v2018.1. And then the new release of meta-xilinx rel-v2018.2 will
>> get PMUFW v2018.1 .
>>
>> But why is such vital component as the working PMUFW recipe stashed in
>> some other repo than meta-xilinx , while meta-xilinx contains a non
>> working one is not clear to me. Anyway.
>>
> 
> Release branches in github are related to Xilinx tools release to support 
> PetaLinux, xsct etc
> The flow using github release uses a layer stack and how to use is documented 
> here
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto
> and manifest is here
> https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1
> 
> We don’t support a flow where you use only one layer instead of the entire 
> stack.

Then the obvious question is, why is it not a single metalayer ...

>> It is also becoming less and less clear to me which PMUFW provides which
>> ABI based on the recipe versions, since they do not reflect the ABI in
>> any way. And, back to my original question-ish, there is an ABI break
>> between PMUFW v0.3 and PMUFW v1.0 which may render systems unbootable if
>> everything is not updated in tandem, right ?
>>
> 
> I was not aware of the breakage, I will have to check.

Try using mainline U-Boot 2018.05 with PMUFW v0.3 and load FPGA image
from U-Boot, it'll fail.

> If you use our entire layer stack for rel-v2018.1 (manifest) then you 
> shouldn’t see the issue. 
> 
> As far as master branch is considred, we are in process of updating it for 
> sumo release. 
> If you are on mailing list, you will see the patches sent for review and is 
> on 4th version. 
> We hope to get it merged if there are no hiccups by end of week.
> See : 
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.html
> See: https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.html

Great

 btw I presume you do mean OpenEmbedded.

>>>
>>>
>>> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
>>>
>>>
>> So it's this pmu-firmware_git recipe which provides different ABI in
>> different versions of meta-xilinx-bsp, yet this is not in any way
>> indicated by the package version, right ?
>
> Didn’t get what you mean here? Package version is set according to the
> release under use
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctap
> p.bbclass#L9

 Ah, I see, so unlike any other regular recipe which encodes the version in 
 the
 recipe file name, Xilinx stuff has custom class which is inherited into 
 version-
>> less
 recipe and sets the version. This is horrid.

>>>
>>> Not true, any recipe which includes version can be in an include file or in 
>>> a class
>> or in a conf file.
>>> There is no strict guidelines on where this version should be set (recipe, 
>>> include,
>> conf or class).
>>> Just because you are familiar with one way of doing things, does not mean
>> everything else is horrid.
>>
>> Well, I think I've seen my share of recipes over the years, both good
>> and bad. OE gives the user a lot of freedom to do all kinds of hacks,
>> which still doesn't mean it's a good idea to do them.
>>
>> Writing your own bbclass as a sort-of header file to be included by a
>> recipe is one of the bad ideas. With the ABI break at hand, there is
>> also no migration strategy for this PMUFW recipe, the platform just
>> breaks during the update and stops booting or misbehaves, which is grueling.
>>
> 
> The same class is shared for multiple components, FSBL, DTG etc hence the 
> reasoning to use a class
> However, this something for us to consider and work in future releases.

This seems to be long overdue

> This should indicate, release version with a part of commit id of git 
> being
>> used.

 Right ...

>> Also, do I understand it correctly that Xilinx doesn't support arm64
>> with multilib?
>>
>
> Yes Xilinx does not support multilib way of building PMUFW

 What are you talking about ? PMUFW is microblaze, which doesn't do multilib
>> in
 the first place.

>>>
>>> Exactly, when you are building for zynqmp (zcu102 board)
>>
>> No, I am not building for zcu102.
>>
>>> , it is aarch64. Yocto build system needs to understand mixed architectures 
>>> when
>> building in the same project, hence the use of multilib to be build PMUFW.
>>
>> But you never build the microblaze toolchain, so how do you use multilib
>> here at all ? From what I see, the pmu-firmware is compiled with
>> toolchain referenced from outside of the OE build, in fact from vivado,
>> see my comment below from using external tools like that.
>>
> 
> I am not sure how your dependencies are wired in:
> We 

[U-Boot] [PATCH 2/2] watchdog: Kconfig: add config to disable wdog reset

2018-05-23 Thread Xiaoliang Yang
Add Kconfig support for CONFIG_WATCHDOG_RESET_DISABLE, use this config
to disable watchdog reset in imx_watchdog driver, so that the watchdog
will not be fed in u-boot.

Signed-off-by: Xiaoliang Yang 
---
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |3 +++
 drivers/watchdog/Kconfig   |5 +
 drivers/watchdog/imx_watchdog.c|2 ++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
index 87b91eb..c43a99b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
@@ -18,3 +18,6 @@ Use following config to set watchdog timeout, if this config 
is not defined,
 the default timeout value is 128s which is the maximum. Set 10 seconds for
 example:
 #define CONFIG_WATCHDOG_TIMEOUT_MSECS 1
+Use following config to disable reset watchdog, so that the watchdog will
+not be fed in u-boot:
+#define CONFIG_WATCHDOG_RESET_DISABLE
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 148c6a0..f9b3035 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -103,4 +103,9 @@ config WDT_CDNS
   Select this to enable Cadence watchdog timer, which can be found on 
some
   Xilinx Microzed Platform.
 
+config WATCHDOG_RESET_DISABLE
+   bool "Disable reset watchdog"
+   help
+  Disable reset watchdog, which can let WATCHDOG_RESET invalid.
+
 endmenu
diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index 3ad4e55..6691ee9 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -20,10 +20,12 @@
 #ifdef CONFIG_IMX_WATCHDOG
 void hw_watchdog_reset(void)
 {
+#ifndef CONFIG_WATCHDOG_RESET_DISABLE
struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
 
writew(0x, >wsr);
writew(0x, >wsr);
+#endif /* CONFIG_WATCHDOG_RESET_DISABLE*/
 }
 
 void hw_watchdog_init(void)
-- 
1.7.1

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


[U-Boot] [PATCH 1/2] watchdog: driver support for layerscape

2018-05-23 Thread Xiaoliang Yang
Support watchdog driver for layerscape. If you want to use it,
please define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG,
define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout.

Signed-off-by: Xiaoliang Yang 
---
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |   10 ++
 drivers/watchdog/Makefile  |2 +-
 drivers/watchdog/imx_watchdog.c|   11 +++
 3 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
index a6ef830..87b91eb 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
@@ -8,3 +8,13 @@ Freescale LayerScape with Chassis Generation 2
 
 This architecture supports Freescale ARMv8 SoCs with Chassis generation 2,
 for example LS1043A.
+
+Watchdog support Overview
+---
+Support watchdog driver for Layerscape. Use following configs to enable it:
+#define CONFIG_IMX_WATCHDOG
+#define CONFIG_HW_WATCHDOG
+Use following config to set watchdog timeout, if this config is not defined,
+the default timeout value is 128s which is the maximum. Set 10 seconds for
+example:
+#define CONFIG_WATCHDOG_TIMEOUT_MSECS 1
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f405f51..4835b27 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -5,7 +5,7 @@
 
 obj-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o
 obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o
-ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mx7 vf610))
+ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mx7 vf610 fsl-layerscape))
 obj-y += imx_watchdog.o
 endif
 obj-$(CONFIG_S5P)   += s5p_wdt.o
diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index 3f826d1..3ad4e55 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -8,6 +8,13 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FSL_LAYERSCAPE
+#ifdef CONFIG_FSL_LSCH3
+#include 
+#elif defined(CONFIG_FSL_LSCH2)
+#include 
+#endif
+#endif
 #include 
 
 #ifdef CONFIG_IMX_WATCHDOG
@@ -33,8 +40,12 @@ void hw_watchdog_init(void)
 #define CONFIG_WATCHDOG_TIMEOUT_MSECS 128000
 #endif
timeout = (CONFIG_WATCHDOG_TIMEOUT_MSECS / 500) - 1;
+#ifdef CONFIG_FSL_LAYERSCAPE
+   writew((WCR_WDA | WCR_SRS | WCR_WDE) << 8 | timeout, >wcr);
+#else
writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
WCR_WDA | SET_WCR_WT(timeout), >wcr);
+#endif /* CONFIG_FSL_LAYERSCAPE*/
hw_watchdog_reset();
 }
 #endif
-- 
1.7.1

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


Re: [U-Boot] [PATCH v2] add FIT data-position & data-offset property support

2018-05-23 Thread Kelvin Cheung
Hi Simon,


2018-05-23 7:30 GMT+08:00 Simon Glass :

> Hi,
>
> On 18 May 2018 at 01:56, Kelvin Cheung  wrote:
> > Add FIT data-position & data-offset property support for bootm,
> > which were already supported in SPL.
> >
> > Signed-off-by: Kelvin Cheung 
> > ---
> >
> > Changes for v2:
> >create fit_image_get_data_and_size() to remove duplicated code
> >
> > ---
> >  common/image-fit.c | 54 ++
> +---
> >  include/image.h|  2 ++
> >  2 files changed, 53 insertions(+), 3 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> How can we get this feature integrated into the tests?
>
> Do you mean the test scripts under test dir?

BTW, I updated this patch to v3 several days ago.
Thanks!


> Regards,
> Simon
>



-- 
Best regards,

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


Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0

2018-05-23 Thread Manjukumar Harthikote Matha
Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, May 22, 2018 4:28 AM
> To: Manjukumar Harthikote Matha ; Rajan Vaja
> 
> Cc: mon...@monstr.eu; Albert Aribaud ; Jolly Shah
> ; Michal Simek ; u-
> b...@lists.denx.de; Moritz Fischer 
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/21/2018 11:26 PM, Manjukumar Harthikote Matha wrote:
> [...]
>  Ah, I see, so there are three versions of pmu-firmware in a single
>  release, but the one which is actually needed for the system to boot
>  correctly is not in the meta-xilinx repo as one would expect, but in
>  some other repo. That ... doesn't make any sense, but so be it.
> 
> >>>
> >>> If you are planning to use rel-v2018.x Xilinx tools release branches,
> >>> stick with all the layers provided by Xilinx. The same is documented
> >>> in wiki as well
> >>>
> >>>
> >>
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct
> >> o
> >>>
> >>> If you want to use Yocto open-source release stick with branches likes 
> >>> rocko,
> >> morty etc. These branches will not have dependencies on Xilinx tools.
> >>
> >> I think you missed my point, there are three different PMUFW recipes in 
> >> those
> >> metalayers. The only one that matters is not in the BSP layer, which makes 
> >> no
> >> sense to me, but so be it.
> >
> > AFAIK, there are two. One in meta-xilinx-bsp and other in 
> > meta-xilinx-tools. You
> can use PREFERRED_PROVIDER to switch between the two in your distro.
> >
> > I still don’t think you get the difference between Xilinx tools releases 
> > from
> Github and upstream Yocto project repository.
> > See http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> 
> Do I understand it correctly that you have two repositories with the
> same name, but with different content ? Talk about confusing. Assume I
> use the meta-xilinx stuff from github/xilinx.
> 
> > Also note that none of the Xilinx tool release branches are present at
> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> >
> > The thing that matters to you is pmu-firmware recipe in meta-xilinx-bsp. The
> recipe is present and based on 2017.3 in master and Rocko. Stick with Rocko
> branch till the next release,Sumo branch is cut, which will get 2018.1 
> version.
> 
> Ah, I see.
> 
> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 (the
> one on github, not the one on git.yoctoproject) without version which
> provides the ABI 1.0 rather than the v2017.03 one from meta-xilinx
> rel-v2018.1. And then the new release of meta-xilinx rel-v2018.2 will
> get PMUFW v2018.1 .
> 
> But why is such vital component as the working PMUFW recipe stashed in
> some other repo than meta-xilinx , while meta-xilinx contains a non
> working one is not clear to me. Anyway.
> 

Release branches in github are related to Xilinx tools release to support 
PetaLinux, xsct etc
The flow using github release uses a layer stack and how to use is documented 
here
http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto
and manifest is here
https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1

We don’t support a flow where you use only one layer instead of the entire 
stack.

> It is also becoming less and less clear to me which PMUFW provides which
> ABI based on the recipe versions, since they do not reflect the ABI in
> any way. And, back to my original question-ish, there is an ABI break
> between PMUFW v0.3 and PMUFW v1.0 which may render systems unbootable if
> everything is not updated in tandem, right ?
> 

I was not aware of the breakage, I will have to check.

If you use our entire layer stack for rel-v2018.1 (manifest) then you shouldn’t 
see the issue. 

As far as master branch is considred, we are in process of updating it for sumo 
release. 
If you are on mailing list, you will see the patches sent for review and is on 
4th version. 
We hope to get it merged if there are no hiccups by end of week.
See : https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.html
See: https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.html

> >> btw I presume you do mean OpenEmbedded.
> >>
> >
> >
> > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> >
> >
>  So it's this pmu-firmware_git recipe which provides different ABI in
>  different versions of meta-xilinx-bsp, yet this is not in any way
>  indicated by the package version, right ?
> >>>
> >>> Didn’t get what you mean here? Package version is set according to the
> >>> release under use
> >>> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctap
> >>> p.bbclass#L9
> >>
> >> Ah, I see, so unlike any other regular recipe which encodes the version in 
> >> the
> >> recipe file name, Xilinx stuff has custom class which is inherited 

Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler

2018-05-23 Thread Andy Shevchenko
On Wed, 2018-05-23 at 18:22 +0800, Bin Meng wrote:
> Hi Andy,
> 
> On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenko
>  wrote:
> > The commit
> > 
> >   f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file
> > in C)")
> > 
> > in ACPICA project changed a template of the a of variable that is
> > used
> 
> a template of the a of variable? Cannot understand this.

"a template of the variable"

> 
> > in the generated C-file. Now, instead of hard coded "AmlCode" the
> > "%s_aml_code" is in use, where the prefix is a lowered case base
> > name of
> > the output file. In our case it will be "dsdt" producing a name as
> > "dsdt_aml_code".
> > 
> > The quick solution is to call sed which replaces new name by the old
> > one
> > to keep compatibility with old version of iASL.
> > 
> > The long term solution would be to modify code to use the new name
> > because it more scalable.
> 
> it *is* more scalable.

Yes, thanks.

> 
> > 
> > Cc: Robert Moore 
> > Cc: Sami Mujawar 
> > Cc: Evan Lloyd 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  scripts/Makefile.lib | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index f9809ce7ce..b5cf7e5427 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \
> > 
> >  $(obj)/dsdt.c:$(src)/dsdt.asl
> > $(call cmd,acpi_c_asl)
> > +   $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@
> > 
> >  # Bzip2
> >  # ---
> > 
> > --
> 
> Otherwise,
> Reviewed-by: Bin Meng 
> 
> Regards,
> Bin

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler

2018-05-23 Thread Bin Meng
Hi Andy,

On Wed, May 23, 2018 at 5:38 PM, Andy Shevchenko
 wrote:
> The commit
>
>   f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file in C)")
>
> in ACPICA project changed a template of the a of variable that is used

a template of the a of variable? Cannot understand this.

> in the generated C-file. Now, instead of hard coded "AmlCode" the
> "%s_aml_code" is in use, where the prefix is a lowered case base name of
> the output file. In our case it will be "dsdt" producing a name as
> "dsdt_aml_code".
>
> The quick solution is to call sed which replaces new name by the old one
> to keep compatibility with old version of iASL.
>
> The long term solution would be to modify code to use the new name
> because it more scalable.

it *is* more scalable.

>
> Cc: Robert Moore 
> Cc: Sami Mujawar 
> Cc: Evan Lloyd 
> Signed-off-by: Andy Shevchenko 
> ---
>  scripts/Makefile.lib | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index f9809ce7ce..b5cf7e5427 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -416,6 +416,7 @@ cmd_acpi_c_asl= \
>
>  $(obj)/dsdt.c:$(src)/dsdt.asl
> $(call cmd,acpi_c_asl)
> +   $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@
>
>  # Bzip2
>  # ---
> --

Otherwise,
Reviewed-by: Bin Meng 

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


[U-Boot] [PATCH 3/3] LS1012AFRWY: Add Secure Boot support

2018-05-23 Thread Bhaskar Upadhaya
From: Vinitha V Pillai 

Added the following:
1. defconfig for LS1012AFRWY Secure boot
2. PfE Validation support

Signed-off-by: Vinitha V Pillai 
---
 arch/arm/Kconfig   |  1 +
 board/freescale/ls1012afrdm/Kconfig|  8 
 board/freescale/ls1012afrdm/MAINTAINERS|  4 ++
 board/freescale/ls1012afrdm/ls1012afrdm.c  |  5 +++
 configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 54 ++
 drivers/net/pfe_eth/pfe_firmware.c | 29 ++
 include/configs/ls1012afrwy.h  | 16 +++-
 7 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b1eb7c6..4f0ea04 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1036,6 +1036,7 @@ config TARGET_LS1012A2G5RDB
 config TARGET_LS1012AFRWY
bool "Support ls1012afrwy"
select ARCH_LS1012A
+   select BOARD_LATE_INIT
select ARM64
imply SCSI
imply SCSI_AHCI
diff --git a/board/freescale/ls1012afrdm/Kconfig 
b/board/freescale/ls1012afrdm/Kconfig
index 73ad2fe..f52a896 100644
--- a/board/freescale/ls1012afrdm/Kconfig
+++ b/board/freescale/ls1012afrdm/Kconfig
@@ -70,6 +70,14 @@ config SYS_LS_PPA_FW_ADDR
hex "PPA Firmware Addr"
default 0x4006
 
+config SYS_LS_PPA_ESBC_ADDR
+   hex "PPA Firmware HDR Addr"
+   default 0x401f4000
+
+config SYS_LS_PFE_ESBC_ADDR
+   hex "PFE Firmware HDR Addr"
+   default 0x401f8000
+
 endif
 
 source "board/freescale/common/Kconfig"
diff --git a/board/freescale/ls1012afrdm/MAINTAINERS 
b/board/freescale/ls1012afrdm/MAINTAINERS
index 36e3e5a..f3fcdb8 100644
--- a/board/freescale/ls1012afrdm/MAINTAINERS
+++ b/board/freescale/ls1012afrdm/MAINTAINERS
@@ -11,3 +11,7 @@ S:  Maintained
 F:  board/freescale/ls1012afrwy/
 F:  include/configs/ls1012afrwy.h
 F:  configs/ls1012afrwy_qspi_defconfig
+
+M: Vinitha V Pillai 
+S: Maintained
+F: configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls1012afrdm/ls1012afrdm.c 
b/board/freescale/ls1012afrdm/ls1012afrdm.c
index e30ad6e..315da8b 100644
--- a/board/freescale/ls1012afrdm/ls1012afrdm.c
+++ b/board/freescale/ls1012afrdm/ls1012afrdm.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -140,6 +141,10 @@ int board_init(void)
gd->env_addr = (ulong)_environment[0];
 #endif
 
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
+
 #ifdef CONFIG_FSL_LS_PPA
ppa_init();
 #endif
diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig 
b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
new file mode 100644
index 000..bfc120a
--- /dev/null
+++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
@@ -0,0 +1,54 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1012AFRWY=y
+CONFIG_SECURE_BOOT=y
+CONFIG_SYS_TEXT_BASE=0x4010
+CONFIG_FSL_LS_PPA=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-frwy"
+CONFIG_DISTRO_DEFAULTS=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21c0500 quiet lpj=25"
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+# CONFIG_BLK is not set
+CONFIG_DM_MMC=y
+# CONFIG_DM_MMC_OPS is not set
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_ETH=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_FSL_PFE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_DSPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_RSA=y
+CONFIG_RSA_SOFTWARE_EXP=y
diff --git a/drivers/net/pfe_eth/pfe_firmware.c 
b/drivers/net/pfe_eth/pfe_firmware.c
index f06ed37..adb2d06 100644
--- a/drivers/net/pfe_eth/pfe_firmware.c
+++ b/drivers/net/pfe_eth/pfe_firmware.c
@@ -12,6 +12,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_CHAIN_OF_TRUST
+#include 
+#endif
 
 #define PFE_FIRMEWARE_FIT_CNF_NAME "config@1"
 
@@ -168,10 +171,15 @@ static int pfe_fit_check(void)
  */
 int pfe_firmware_init(void)
 {
+#define PFE_KEY_HASH   NULL
char *pfe_firmware_name;
const void *raw_image_addr;
size_t raw_image_size = 0;
u8 *pfe_firmware;
+#ifdef CONFIG_CHAIN_OF_TRUST
+   uintptr_t pfe_esbc_hdr = 0;
+   uintptr_t pfe_img_addr = 0;
+#endif
int ret = 0;
int fw_count;
 
@@ 

[U-Boot] [PATCH 2/3] board: ls1012a: FRWY-LS1012A board support

2018-05-23 Thread Bhaskar Upadhaya
FRWY-LS1012A belongs to LS1012A family with features
2 1G SGMII PFE MAC, Micro SD, USB 3.0, DDR, QuadSPI, Audio,
UART.

Signed-off-by: Bhaskar Upadhaya 
---
 arch/arm/Kconfig  |  12 +++
 arch/arm/cpu/armv8/Kconfig|   1 +
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-ls1012a-frwy.dts |  43 +++
 board/freescale/ls1012afrdm/Kconfig   |  35 +++--
 board/freescale/ls1012afrdm/MAINTAINERS   |   7 ++
 board/freescale/ls1012afrdm/ls1012afrdm.c |  68 -
 configs/ls1012afrwy_qspi_defconfig|  50 +
 include/configs/ls1012afrwy.h | 120 ++
 9 files changed, 330 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-frwy.dts
 create mode 100644 configs/ls1012afrwy_qspi_defconfig
 create mode 100644 include/configs/ls1012afrwy.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3e05f79..b1eb7c6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1033,6 +1033,18 @@ config TARGET_LS1012A2G5RDB
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1012AFRWY
+   bool "Support ls1012afrwy"
+   select ARCH_LS1012A
+   select ARM64
+   imply SCSI
+   imply SCSI_AHCI
+   help
+Support for Freescale LS1012AFRWY platform.
+The LS1012A FRWY board (FRWY) is a high-performance
+development platform that supports the QorIQ LS1012A
+Layerscape Architecture processor.
+
 config TARGET_LS1012AFRDM
bool "Support ls1012afrdm"
select ARCH_LS1012A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 3a0e129..22d2f29 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -91,6 +91,7 @@ config PSCI_RESET
   !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1012A2G5RDB && !TARGET_LS1012AQDS && \
+  !TARGET_LS1012AFRWY && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
   !TARGET_LS2081ARDB && \
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a0349a8..0a46b0e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -227,7 +227,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1012a-qds.dtb \
fsl-ls1012a-rdb.dtb \
fsl-ls1012a-2g5rdb.dtb \
-   fsl-ls1012a-frdm.dtb
+   fsl-ls1012a-frdm.dtb \
+   fsl-ls1012a-frwy.dtb
 
 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
diff --git a/arch/arm/dts/fsl-ls1012a-frwy.dts 
b/arch/arm/dts/fsl-ls1012a-frwy.dts
new file mode 100644
index 000..3158246
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-frwy.dts
@@ -0,0 +1,43 @@
+/*
+ * NXP ls1012a FRWY board device tree source
+ *
+ * Copyright 2018 NXP
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a.dtsi"
+
+/ {
+   model = "FRWY-LS1012A Board";
+
+   aliases {
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: w25q16dw@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/freescale/ls1012afrdm/Kconfig 
b/board/freescale/ls1012afrdm/Kconfig
index fd33807..73ad2fe 100644
--- a/board/freescale/ls1012afrdm/Kconfig
+++ b/board/freescale/ls1012afrdm/Kconfig
@@ -12,20 +12,23 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012afrdm"
 
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"
+   default 0x40a0
+
 config SYS_LS_PPA_FW_ADDR
hex "PPA Firmware Addr"
default 0x4040
 
+endif
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select PHYLIB
imply PHY_REALTEK
-
-config SYS_LS_PFE_FW_ADDR
-   hex "Flash address of PFE firmware"
-   default 0x40a0
+   imply PHY_ATHEROS
 
 config DDR_PFE_PHYS_BASEADDR
hex "PFE DDR physical base address"
@@ -45,6 +48,28 @@ config PFE_EMAC2_PHY_ADDR
 
 endif
 
-source "board/freescale/common/Kconfig"
+if TARGET_LS1012AFRWY
+
+config SYS_BOARD
+   default "ls1012afrdm"
+
+config SYS_VENDOR
+   default "freescale"
+
+config SYS_SOC
+   default "fsl-layerscape"
+
+config SYS_CONFIG_NAME
+   default "ls1012afrwy"
+
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"
+   default 0x4002
+
+config 

[U-Boot] [PATCH 1/3] board: Kconfig: Re-Arrangement of PPA firmware and header addresses

2018-05-23 Thread Bhaskar Upadhaya
ppa firmware and header address may vary depending upon different boards,
configure ppa firmware and header address in board specific kconfig

Signed-off-by: Vinitha V Pillai 
Signed-off-by: Jagdish Gediya 
Signed-off-by: Bhaskar Upadhaya 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 34 ---
 board/freescale/ls1012afrdm/Kconfig   |  4 
 board/freescale/ls1012aqds/Kconfig|  3 +++
 board/freescale/ls1012ardb/Kconfig| 14 +
 board/freescale/ls1043aqds/Kconfig| 16 +++
 board/freescale/ls1043ardb/Kconfig| 14 +
 board/freescale/ls1046aqds/Kconfig| 16 +++
 board/freescale/ls1046ardb/Kconfig| 15 ++
 board/freescale/ls1088a/Kconfig   | 28 +
 board/freescale/ls2080aqds/Kconfig| 16 +++
 board/freescale/ls2080ardb/Kconfig| 31 ++--
 11 files changed, 141 insertions(+), 50 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 546de33..f2111fa 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -261,40 +261,6 @@ config SYS_LS_PPA_FW_IN_NAND
 
 endchoice
 
-config SYS_LS_PPA_FW_ADDR
-   hex "Address of PPA firmware loading from"
-   depends on FSL_LS_PPA
-   default 0x2040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A
-   default 0x4040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT
-   default 0x58040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
-   default 0x2040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
-   default 0x6040 if SYS_LS_PPA_FW_IN_XIP
-   default 0x40 if SYS_LS_PPA_FW_IN_MMC
-   default 0x40 if SYS_LS_PPA_FW_IN_NAND
-
-   help
- If the PPA firmware locate at XIP flash, such as NOR or
- QSPI flash, this address is a directly memory-mapped.
- If it is in a serial accessed flash, such as NAND and SD
- card, it is a byte offset.
-
-config SYS_LS_PPA_ESBC_ADDR
-   hex "hdr address of PPA firmware loading from"
-   depends on FSL_LS_PPA && CHAIN_OF_TRUST
-   default 0x6068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1043A
-   default 0x4068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
-   default 0x4068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
-   default 0x2068 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A
-   default 0x58068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
-   default 0x2068 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
-   default 0x68 if SYS_LS_PPA_FW_IN_MMC
-   default 0x68 if SYS_LS_PPA_FW_IN_NAND
-   help
- If the PPA header firmware locate at XIP flash, such as NOR or
- QSPI flash, this address is a directly memory-mapped.
- If it is in a serial accessed flash, such as NAND and SD
- card, it is a byte offset.
-
 config LS_PPA_ESBC_HDR_SIZE
hex "Length of PPA ESBC header"
depends on FSL_LS_PPA && CHAIN_OF_TRUST && !SYS_LS_PPA_FW_IN_XIP
diff --git a/board/freescale/ls1012afrdm/Kconfig 
b/board/freescale/ls1012afrdm/Kconfig
index 22d521b..fd33807 100644
--- a/board/freescale/ls1012afrdm/Kconfig
+++ b/board/freescale/ls1012afrdm/Kconfig
@@ -12,6 +12,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012afrdm"
 
+config SYS_LS_PPA_FW_ADDR
+   hex "PPA Firmware Addr"
+   default 0x4040
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
diff --git a/board/freescale/ls1012aqds/Kconfig 
b/board/freescale/ls1012aqds/Kconfig
index c0b12ed..b702fb2 100644
--- a/board/freescale/ls1012aqds/Kconfig
+++ b/board/freescale/ls1012aqds/Kconfig
@@ -12,6 +12,9 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012aqds"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
 
 if FSL_PFE
 
diff --git a/board/freescale/ls1012ardb/Kconfig 
b/board/freescale/ls1012ardb/Kconfig
index 493d477..4cd66bd 100644
--- a/board/freescale/ls1012ardb/Kconfig
+++ b/board/freescale/ls1012ardb/Kconfig
@@ -12,6 +12,16 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012ardb"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
+if CHAIN_OF_TRUST
+config SYS_LS_PPA_ESBC_ADDR
+   hex "PPA Firmware HDR Addr"
+   default 0x4068
+endif
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
@@ -59,6 +69,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
 default "ls1012a2g5rdb"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
diff --git a/board/freescale/ls1043aqds/Kconfig 
b/board/freescale/ls1043aqds/Kconfig
index 95d2888..182900e 100644
--- a/board/freescale/ls1043aqds/Kconfig
+++ 

Re: [U-Boot] [PATCH] disk: efi: Correct backing up the MBR boot code

2018-05-23 Thread Andy Shevchenko
On Tue, May 22, 2018 at 2:04 AM, Sam Protsenko
 wrote:
> In commit e163a931af34 ("cmd: gpt: backup boot code before writing MBR")
> there was added the procedure for storing old boot code when doing "gpt
> write". But instead of storing just backup code, the whole MBR was
> stored, and only specific fields were replaced further, keeping
> everything else intact. That's obviously not what we want.
>
> Fix the code to actually store only old boot code and zero out
> everything else. This fixes next testing case:
>
> => mmc write $loadaddr 0x0 0x7b
> => gpt write mmc 1 $partitions
>
> In case when $loadaddr address and further memory contains 0xff, the
> board was bricked (ROM-code probably didn't like partition entries that
> were clobbered with 0xff). With this patch applied, commands above don't
> brick the board.

Tested-by: Andy Shevchenko 

At least it doesn't break Intel Edison.

>
> Signed-off-by: Sam Protsenko 
> Cc: Alejandro Hernandez 
> ---
>  disk/part_efi.c| 6 --
>  include/part_efi.h | 3 ++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index 72e3997b84..5c1039f013 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -350,8 +350,6 @@ static int set_protective_mbr(struct blk_desc *dev_desc)
>  {
> /* Setup the Protective MBR */
> ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, p_mbr, 1, dev_desc->blksz);
> -   memset(p_mbr, 0, sizeof(*p_mbr));
> -
> if (p_mbr == NULL) {
> printf("%s: calloc failed!\n", __func__);
> return -1;
> @@ -363,6 +361,10 @@ static int set_protective_mbr(struct blk_desc *dev_desc)
> return -1;
> }
>
> +   /* Clear all data in MBR except of backed up boot code */
> +   memset((char *)p_mbr + MSDOS_MBR_BOOT_CODE_SIZE, 0, sizeof(*p_mbr) -
> +   MSDOS_MBR_BOOT_CODE_SIZE);
> +
> /* Append signature */
> p_mbr->signature = MSDOS_MBR_SIGNATURE;
> p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
> diff --git a/include/part_efi.h b/include/part_efi.h
> index 6065c571f3..8525770445 100644
> --- a/include/part_efi.h
> +++ b/include/part_efi.h
> @@ -20,6 +20,7 @@
>  #include 
>
>  #define MSDOS_MBR_SIGNATURE 0xAA55
> +#define MSDOS_MBR_BOOT_CODE_SIZE 440
>  #define EFI_PMBR_OSTYPE_EFI 0xEF
>  #define EFI_PMBR_OSTYPE_EFI_GPT 0xEE
>
> @@ -111,7 +112,7 @@ typedef struct _gpt_entry {
>  } __packed gpt_entry;
>
>  typedef struct _legacy_mbr {
> -   u8 boot_code[440];
> +   u8 boot_code[MSDOS_MBR_BOOT_CODE_SIZE];
> __le32 unique_mbr_signature;
> __le16 unknown;
> struct partition partition_record[4];
> --
> 2.17.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: tsc: add support for reading CPU freq from cpuid

2018-05-23 Thread Bin Meng
On Mon, May 14, 2018 at 5:32 PM, Christian Gmeiner
 wrote:
> Starting with cpuid level 0x16 (Skylake-based processors)
> it is possible to get CPU base freq via cpuid.
>
> This fixes booting on a skylake based system.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/timer/tsc_timer.c | 31 +--
>  1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
> index c7fefd2031..96a3e55513 100644
> --- a/drivers/timer/tsc_timer.c
> +++ b/drivers/timer/tsc_timer.c
> @@ -21,6 +21,17 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +static unsigned long cpu_mhz_from_cpuid(void)
> +{
> +   if (gd->arch.x86_vendor != X86_VENDOR_INTEL)
> +   return 0;
> +
> +   if (cpuid_eax(0) < 0x16)
> +   return 0;
> +
> +   return cpuid_eax(0x16);
> +}
> +
>  /*
>   * According to Intel 64 and IA-32 System Programming Guide,
>   * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
> @@ -343,14 +354,22 @@ static void tsc_timer_ensure_setup(void)
> if (!gd->arch.clock_rate) {
> unsigned long fast_calibrate;
>
> +   fast_calibrate = cpu_mhz_from_cpuid();
> +   if (fast_calibrate)
> +   goto done;
> +
> fast_calibrate = cpu_mhz_from_msr();
> -   if (!fast_calibrate) {
> -   fast_calibrate = quick_pit_calibrate();
> -   if (!fast_calibrate)
> -   panic("TSC frequency is ZERO");
> -   }
> +   if (fast_calibrate)
> +   goto done;
> +
> +   fast_calibrate = quick_pit_calibrate();
> +   if (fast_calibrate)
> +   goto done;
> +
> +   panic("TSC frequency is ZERO");
>
> -   gd->arch.clock_rate = fast_calibrate * 100;
> +   done:

nits: this indention is wrong, and will cause checkpatch warnings.

> +   gd->arch.clock_rate = fast_calibrate * 100;
> }
>  }

Reviewed-by: Bin Meng 

I can fix the nits when applying.

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


[U-Boot] [PATCH v1] x86: acpi: Adopt new version of iASL compiler

2018-05-23 Thread Andy Shevchenko
The commit

  f9a88a4c1cd0 ("iASL: Enhance the -tc option (create AML hex file in C)")

in ACPICA project changed a template of the a of variable that is used
in the generated C-file. Now, instead of hard coded "AmlCode" the
"%s_aml_code" is in use, where the prefix is a lowered case base name of
the output file. In our case it will be "dsdt" producing a name as
"dsdt_aml_code".

The quick solution is to call sed which replaces new name by the old one
to keep compatibility with old version of iASL.

The long term solution would be to modify code to use the new name
because it more scalable.

Cc: Robert Moore 
Cc: Sami Mujawar 
Cc: Evan Lloyd 
Signed-off-by: Andy Shevchenko 
---
 scripts/Makefile.lib | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index f9809ce7ce..b5cf7e5427 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -416,6 +416,7 @@ cmd_acpi_c_asl= \
 
 $(obj)/dsdt.c:$(src)/dsdt.asl
$(call cmd,acpi_c_asl)
+   $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@
 
 # Bzip2
 # ---
-- 
2.17.0

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


Re: [U-Boot] [PATCH v3] arm: zynq: Add initial support for Avnet MiniZed

2018-05-23 Thread Michal Simek
On 22.5.2018 18:03, Ibai Erkiaga wrote:
> Initial support for Avnet MiniZed board. Tested UART1 (serial console),
> QSPI(Flash), SDHCI1 (eMMC), USB.
> 
> Signed-off-by: Ibai Erkiaga 
> ---
> 
> Changes in v3:
> -dts formating refactor
> -CONFIG_DISPLAY_CPUINFO removed from config
> -CONFIG_OF_EMBED removed from config
> 
> Changes in v2:
> -board model changed to use Avent prefix
> -usb phy driver changed usb-no-xceiv
> -removed gpio and intc binding
> -fixed-partitions usage
> 
> ---
>  arch/arm/dts/Makefile  |1 +
>  arch/arm/dts/zynq-minized.dts  |  106 
> 
>  configs/zynq_minized_defconfig |   66 +
>  3 files changed, 173 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/dts/zynq-minized.dts
>  create mode 100644 configs/zynq_minized_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7bec3d6..f7b33f9 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>   zynq-cc108.dtb \
>   zynq-cse-qspi-single.dtb \
>   zynq-microzed.dtb \
> + zynq-minized.dtb \
>   zynq-picozed.dtb \
>   zynq-syzygy-hub.dtb \
>   zynq-topic-miami.dtb \
> diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
> new file mode 100644
> index 000..525921e
> --- /dev/null
> +++ b/arch/arm/dts/zynq-minized.dts
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Avnet MiniZed board
> + *
> + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> + *
> + * Ibai Erkiaga 
> + */
> +
> +/dts-v1/;
> +#include "zynq-7000.dtsi"
> +
> +/ {
> + model = "Avnet Zynq MiniZed Development Board";
> + compatible = "avnet,minized", "xlnx,zynq-7000";
> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + spi0 = 
> + mmc0 = 
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x2000>;
> + };
> +
> + chosen {
> + bootargs = "";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> + {
> + status = "okay";
> + is-dual = <0>;
> + num-cs = <1>;
> + flash@0 {
> + compatible = "micron,m25p128";
> + reg = <0x0>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + spi-max-frequency = <5000>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "boot";
> + reg = <0x0 0xff>;
> + };
> +
> + partition@27 {
> + label = "kernel";
> + reg = <0x27 0xd8>;
> + };
> +
> + partition@ff {
> + label = "bootenv";
> + reg = <0xff 0x1>;
> + };
> +
> + partition@100 {
> + label = "spare";
> + reg = <0x100 0x0>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <_phy0>;
> + usb-reset = < 7 0>; /* USB_RST_N-MIO7 */
> +};
> +
> + {
> + status = "okay";
> + non-removable;
> + bus-width = <4>;
> + max-frequency = <1200>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mmccard: mmccard@0 {
> + compatible = "mmc-card";
> + reg = <0>;
> + broken-hpi;
> + };
> +};
> diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
> new file mode 100644
> index 000..8cf3215
> --- /dev/null
> +++ b/configs/zynq_minized_defconfig
> @@ -0,0 +1,66 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ZYNQ=y
> +CONFIG_SYS_TEXT_BASE=0x400
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R_ADDR=0x20
> +CONFIG_DEFAULT_DEVICE_TREE="zynq-minized"
> +CONFIG_DEBUG_UART=y
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_FIT_SIGNATURE=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd"
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_OS_BOOT=y
> +CONFIG_SYS_PROMPT="Zynq> "
> +CONFIG_CMD_THOR_DOWNLOAD=y
> +CONFIG_CMD_DFU=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_FPGA_LOADBP=y
> +CONFIG_CMD_FPGA_LOADFS=y
> +CONFIG_CMD_FPGA_LOADMK=y
> 

  1   2   >