date:20190520

Re: [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework

2019-05-20 Thread Chee, Tien Fong

On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> Introduce a framework that allows loading the System Firmware (SYSFW)
> binary as well as the associated configuration data from an image
> tree
> blob named "sysfw.itb" from an FS-based boot media using the FS
> loader
> framework.
> 
> Signed-off-by: Andreas Dannenberg 
> ---
>  arch/arm/mach-k3/Kconfig |  22 ++
>  arch/arm/mach-k3/Makefile|   3 +
>  arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>  arch/arm/mach-k3/sysfw-loader.c  | 296
> +++
>  4 files changed, 333 insertions(+)
>  create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>  create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> 
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index e677a2e01b..fd28593cec 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,28 @@ config SYS_K3_BOOT_CORE_ID
>   int
>   default 16
>  
> +config K3_LOAD_SYSFW
> + bool
> + depends on SPL
> +
> +config K3_SYSFW_IMAGE_NAME
> + string "File name of SYSFW firmware and configuration blob"
> + depends on K3_LOAD_SYSFW
> + default "sysfw.itb"
> + help
> +   Filename of the combined System Firmware and configuration
> image tree
> +   blob to be loaded when booting from a filesystem.
> +
> +config K3_SYSFW_IMAGE_SIZE_MAX
> + int "Amount of memory dynamically allocated for loading
> SYSFW blob"
> + depends on K3_LOAD_SYSFW
> + default 269000
> + help
> +   Amount of memory (in bytes) reserved through dynamic
> allocation at
> +   runtime for loading the combined System Firmware and
> configuration image
> +   tree blob. Keep it as tight as possible, as this directly
> affects the
> +   overall SPL memory footprint.
> +
>  config SYS_K3_SPL_ATF
>   bool "Start Cortex-A from SPL"
>   depends on SPL && CPU_V7R
> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> index 0c3a4f7db1..3af7f2ec96 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,7 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
>  obj-$(CONFIG_ARM64) += arm64-mmu.o
>  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
>  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> +endif
>  obj-y += common.o
> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h
> b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> new file mode 100644
> index 00..c335c7ed92
> --- /dev/null
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + *   Andreas Dannenberg 
> + */
> +
> +#ifndef _SYSFW_LOADER_H_
> +#define _SYSFW_LOADER_H_
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void));
> +
> +#endif
> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-
> k3/sysfw-loader.c
> new file mode 100644
> index 00..1191640acd
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: System Firmware Loader
> + *
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + *   Andreas Dannenberg 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Name of the FIT image nodes for SYSFW and its config data */
> +#define SYSFW_FIRMWARE   "sysfw.bin"
> +#define SYSFW_CFG_BOARD  "board-cfg.bin"
> +#define SYSFW_CFG_PM "pm-cfg.bin"
> +#define SYSFW_CFG_RM "rm-cfg.bin"
> +#define SYSFW_CFG_SEC"sec-cfg.bin"
> +
> +static int fit_get_data_by_name(const void *fit, int images, const
> char *name,
> + const void **addr, size_t *size)
> +{
> + int node_offset;
> +
> + node_offset = fdt_subnode_offset(fit, images, name);
> + if (node_offset < 0)
> + return -ENOENT;
> +
> + return fit_image_get_data(fit, node_offset, addr, size);
> +}
> +
> +static void k3_sysfw_load_using_fit(void *fit, struct ti_sci_handle
> **ti_sci)
> +{
> + int images;
> + const void *sysfw_addr;
> + size_t sysfw_size;
> + struct udevice *dev;
> + int ret;
> +
> + /* Find the node holding the images information */
> + images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> + if (images < 0)
> + panic("Cannot find /images node (%d)\n", images);
> +
> + /* Extract System Firmware (SYSFW) image from FIT */
> + ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
> +    _addr, _size);
> + if

[U-Boot] [PATCH 1/1] cmd: remove unused `display` command

2019-05-20 Thread Heinrich Schuchardt

Compiling the display command leads to an error

undefined reference to `display_set'

No implementation of display_set() exists in U-Boot.

Eliminate the `display` command as well as the accompanying files.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/Kconfig|  8 ---
 cmd/Makefile   |  1 -
 cmd/display.c  | 53 --
 doc/README.LED_display | 26 -
 include/led-display.h  | 18 --
 5 files changed, 106 deletions(-)
 delete mode 100644 cmd/display.c
 delete mode 100644 doc/README.LED_display
 delete mode 100644 include/led-display.h

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0d36da2a5c4..0badcb3fe00 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1425,14 +1425,6 @@ config CMD_CLS
  Enable the 'cls' command which clears the screen contents
  on video frame buffer.

-config CMD_DISPLAY
-   bool "Enable the 'display' command, for character displays"
-   help
- (this needs porting to driver model)
- This enables the 'display' command which allows a string to be
- displayed on a simple board-specific display. Implement
- display_putc() to use it.
-
 config CMD_EFIDEBUG
bool "efidebug - display/configure UEFI environment"
depends on EFI_LOADER
diff --git a/cmd/Makefile b/cmd/Makefile
index 7864fcf95c3..f982564ab9f 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -45,7 +45,6 @@ obj-$(CONFIG_CMD_SOUND) += sound.o
 ifdef CONFIG_POST
 obj-$(CONFIG_CMD_DIAG) += diag.o
 endif
-obj-$(CONFIG_CMD_DISPLAY) += display.o
 obj-$(CONFIG_CMD_DTIMG) += dtimg.o
 obj-$(CONFIG_CMD_ECHO) += echo.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
diff --git a/cmd/display.c b/cmd/display.c
deleted file mode 100644
index fbe5514a707..000
--- a/cmd/display.c
+++ /dev/null
@@ -1,53 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2005
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- */
-
-#include 
-#include 
-#include 
-
-#undef DEBUG_DISP
-
-int do_display (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
-   int i;
-
-   /* Clear display */
-   display_set(DISPLAY_CLEAR | DISPLAY_HOME);
-
-   if (argc < 2)
-   return (0);
-
-   for (i = 1; i < argc; i++) {
-   char *p = argv[i];
-
-   if (i > 1) { /* Insert a space between strings */
-   display_putc(' ');
-   }
-
-   while ((*p)) {
-#ifdef DEBUG_DISP
-   putc(*p);
-#endif
-   display_putc(*p++);
-   }
-   }
-
-#ifdef DEBUG_DISP
-   putc('\n');
-#endif
-
-   return (0);
-}
-
-/***/
-
-U_BOOT_CMD(
-   display,CONFIG_SYS_MAXARGS, 1,  do_display,
-   "display string on dot matrix display",
-   "[]\n"
-   "- with  argument: display  on dot matrix display\n"
-   "- without arguments: clear dot matrix display"
-);
diff --git a/doc/README.LED_display b/doc/README.LED_display
deleted file mode 100644
index 19977ea7e0d..000
--- a/doc/README.LED_display
+++ /dev/null
@@ -1,26 +0,0 @@
-LED display internal API
-===
-
-This README describes the LED display API.
-
-The API is defined by the include file include/led-display.h
-
-The first step in to define CONFIG_CMD_DISPLAY in the board config file.
-Then you need to provide the following functions to access LED display:
-
-void display_set(int cmd);
-
-This function should control the state of the LED display. Argument is
-an ORed combination of the following values:
- DISPLAY_CLEAR -- clear the display
- DISPLAY_HOME  -- set the position to the beginning of display
-
-int display_putc(char c);
-
-This function should display it's parameter on the LED display in the
-current position. Returns the displayed character on success or -1 in
-case of failure.
-
-With this functions defined 'display' command will display it's
-arguments on the LED display (or clear the display if called without
-arguments).
diff --git a/include/led-display.h b/include/led-display.h
deleted file mode 100644
index b21f3b05700..000
--- a/include/led-display.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2005-2010
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * (C) Copyright 2010
- * Sergei Poselenov, Emcraft Systems, sposele...@emcraft.com.
- */
-#ifndef _led_display_h_
-#define _led_display_h_
-
-/* Display Commands */
-#define DISPLAY_CLEAR  0x1 /* Clear the display */
-#define DISPLAY_HOME   0x2 /* Set cursor at home position */
-
-void display_set(int cmd);
-int display_putc(char c);
-#endif
--
2.20.1

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

Re: [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC

2019-05-20 Thread Chee, Tien Fong

On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> From: Lokesh Vutla 
> 
> In order to load the sysfw.itb from an MMC device, clocks should be
> hard
> coded to the same value as ROM configured frequency. Clock updates
> cannot
> happen at this point as SYSFW is not yet available. So updating the
> clock
> properties for MMC nodes.
> 
> Furthermore, create a new node for the FS loader framework which we
> want
> to use to load the actual firmware file from the boot media.
> 
> Signed-off-by: Andreas Dannenberg 
> ---
>  arch/arm/dts/k3-am654-r5-base-board.dts | 24
> 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
> b/arch/arm/dts/k3-am654-r5-base-board.dts
> index a07038be70..75880158a2 100644
> --- a/arch/arm/dts/k3-am654-r5-base-board.dts
> +++ b/arch/arm/dts/k3-am654-r5-base-board.dts
> @@ -22,6 +22,12 @@
>   chosen {
>   stdout-path = "serial2:115200n8";
>   tick-timer = 
> + firmware-loader = _loader0;
> + };
> +
> + fs_loader0: fs_loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";

Why not using phandlepart = < 1>, this would help to avoid mmc init
duplication in a few places such as patch [05/11].

>   };
>  
>   aliases {
> @@ -96,6 +102,12 @@
>   u-boot,dm-spl;
>   };
>  
> + clk_200mhz: dummy_clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2>;
> + u-boot,dm-spl;
> + };
>  };
>  
>   {
> @@ -137,3 +149,15 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_vtt_pins_default>;
>  };
> +
> + {
> + clock-names = "clk_xin";
> + clocks = <_200mhz>;
> + /delete-property/ power-domains;
> +};
> +
> + {
> + clock-names = "clk_xin";
> + clocks = <_200mhz>;
> + /delete-property/ power-domains;
> +};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data

2019-05-20 Thread Chee, Tien Fong

On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> To give us more flexibility using the FS loader eliminate the need of
> always having to use the ENV to configure the block device but rather
> allow the respective block device and partition to be setup through
> platform data.
> 
> Signed-off-by: Andreas Dannenberg 

Why not using DT method?

> ---
>  drivers/misc/fs_loader.c | 17 -
>  include/fs_loader.h  |  4 
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index f42eeff8f6..69f474da99 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -81,6 +81,15 @@ static int select_fs_dev(struct device_platdata
> *plat)
>   return -ENODEV;
>   }
>   }
> + } else if (plat->blkdev) {
> + struct blk_desc *desc = blk_get_by_device(plat-
> >blkdev);
> +
> + if (desc) {
> + ret = fs_set_blk_dev_with_part(desc, plat-
> >blkpart);
> + } else {
> + debug("%s: No device found\n", __func__);
> + return -ENODEV;
> + }
>   } else if (plat->mtdpart && plat->ubivol) {
>   ret = mount_ubifs(plat->mtdpart, plat->ubivol);
>   if (ret)
> @@ -138,13 +147,18 @@ static int _request_firmware_prepare(struct
> udevice *dev,
>  static int fw_get_filesystem_firmware(struct udevice *dev)
>  {
>   loff_t actread;
> - char *storage_interface, *dev_part, *ubi_mtdpart,
> *ubi_volume;
> + char *storage_interface = NULL;
> + char *dev_part = NULL;
> + char *ubi_mtdpart = NULL;
> + char *ubi_volume = NULL;
>   int ret;
>  
> +#if CONFIG_IS_ENABLED(ENV_SUPPORT)
>   storage_interface = env_get("storage_interface");
>   dev_part = env_get("fw_dev_part");
>   ubi_mtdpart = env_get("fw_ubi_mtdpart");
>   ubi_volume = env_get("fw_ubi_volume");
> +#endif
>  
>   if (storage_interface && dev_part) {
>   ret = fs_set_blk_dev(storage_interface, dev_part,
> FS_TYPE_ANY);
> @@ -159,6 +173,7 @@ static int fw_get_filesystem_firmware(struct
> udevice *dev)
>   else
>   ret = -ENODEV;
>   } else {
> + debug("%s: init via platdata\n", __func__);
>   ret = select_fs_dev(dev->platdata);
>   }
>  
> diff --git a/include/fs_loader.h b/include/fs_loader.h
> index b728c06fcf..adaa2b5db8 100644
> --- a/include/fs_loader.h
> +++ b/include/fs_loader.h
> @@ -28,11 +28,15 @@ struct phandle_part {
>   * This holds information about all supported storage devices for
> driver use.
>   *
>   * @phandlepart: Attribute data for block device.
> + * @blkdev: Block device (alternative to using phandlepart)
> + * @blkpart: Partition number of block device (alternative to using
> phandlepart)
>   * @mtdpart: MTD partition for ubi partition.
>   * @ubivol: UBI volume-name for ubifsmount.
>   */
>  struct device_platdata {
>   struct phandle_part phandlepart;
> + struct udevice *blkdev;
> + u32 blkpart;
>   char *mtdpart;
>   char *ubivol;
>  };
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework

2019-05-20 Thread Chee, Tien Fong

On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> Introduce a framework that allows loading the System Firmware (SYSFW)
> binary as well as the associated configuration data from an image
> tree
> blob named "sysfw.itb" from an FS-based boot media using the FS
> loader
> framework.
> 
> Signed-off-by: Andreas Dannenberg 
> ---
>  arch/arm/mach-k3/Kconfig |  22 ++
>  arch/arm/mach-k3/Makefile|   3 +
>  arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>  arch/arm/mach-k3/sysfw-loader.c  | 296
> +++
>  4 files changed, 333 insertions(+)
>  create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>  create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> 
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index e677a2e01b..fd28593cec 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,28 @@ config SYS_K3_BOOT_CORE_ID
>   int
>   default 16
>  
> +config K3_LOAD_SYSFW
> + bool
> + depends on SPL
> +
> +config K3_SYSFW_IMAGE_NAME
> + string "File name of SYSFW firmware and configuration blob"
> + depends on K3_LOAD_SYSFW
> + default "sysfw.itb"
> + help
> +   Filename of the combined System Firmware and configuration
> image tree
> +   blob to be loaded when booting from a filesystem.
> +
> +config K3_SYSFW_IMAGE_SIZE_MAX
> + int "Amount of memory dynamically allocated for loading
> SYSFW blob"
> + depends on K3_LOAD_SYSFW
> + default 269000
> + help
> +   Amount of memory (in bytes) reserved through dynamic
> allocation at
> +   runtime for loading the combined System Firmware and
> configuration image
> +   tree blob. Keep it as tight as possible, as this directly
> affects the
> +   overall SPL memory footprint.
> +
>  config SYS_K3_SPL_ATF
>   bool "Start Cortex-A from SPL"
>   depends on SPL && CPU_V7R
> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> index 0c3a4f7db1..3af7f2ec96 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,7 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
>  obj-$(CONFIG_ARM64) += arm64-mmu.o
>  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
>  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> +endif
>  obj-y += common.o
> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h
> b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> new file mode 100644
> index 00..c335c7ed92
> --- /dev/null
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + *   Andreas Dannenberg 
> + */
> +
> +#ifndef _SYSFW_LOADER_H_
> +#define _SYSFW_LOADER_H_
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void));
> +
> +#endif
> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-
> k3/sysfw-loader.c
> new file mode 100644
> index 00..1191640acd
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: System Firmware Loader
> + *
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + *   Andreas Dannenberg 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Name of the FIT image nodes for SYSFW and its config data */
> +#define SYSFW_FIRMWARE   "sysfw.bin"
> +#define SYSFW_CFG_BOARD  "board-cfg.bin"
> +#define SYSFW_CFG_PM "pm-cfg.bin"
> +#define SYSFW_CFG_RM "rm-cfg.bin"
> +#define SYSFW_CFG_SEC"sec-cfg.bin"
> +
> +static int fit_get_data_by_name(const void *fit, int images, const
> char *name,
> + const void **addr, size_t *size)
> +{
> + int node_offset;
> +
> + node_offset = fdt_subnode_offset(fit, images, name);
> + if (node_offset < 0)
> + return -ENOENT;
> +
> + return fit_image_get_data(fit, node_offset, addr, size);
> +}
> +
> +static void k3_sysfw_load_using_fit(void *fit, struct ti_sci_handle
> **ti_sci)
> +{
> + int images;
> + const void *sysfw_addr;
> + size_t sysfw_size;
> + struct udevice *dev;
> + int ret;
> +
> + /* Find the node holding the images information */
> + images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> + if (images < 0)
> + panic("Cannot find /images node (%d)\n", images);
> +
> + /* Extract System Firmware (SYSFW) image from FIT */
> + ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
> +    _addr, _size);
> + if

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-20 Thread Peng Fan

> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/21/19 4:55 AM, Peng Fan wrote:
> [...]
> 
> > I do not know how other SoC vendor did FIT hardware secure boot,
> > please share you have any information.
> 
>  The SPL can be in the custom format, but then can load fitImage
>  with the next stage(s), right ?
> >>>
> >>> I am not able to follow you, could you share more details?
> >>
> >> Wrap the SPL into this custom format and then have the SPL
> >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
> >> Would that work ?
> >
> > It not work.
> > We already wrap SPL in i.MX container format, this patchset is to let
> > SPL could load the 2nd container file which contains
> > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
> > (U-Boot/DTB and etc), it could not pass secure boot authentication,
> > because ROM not know fitimage, it only know i.MX container format.
> 
> It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> BootROM already authenticated and started the U-Boot SPL, so that's a
> trusted code. Now this trusted code can authenticate and start the next stage
> (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the picture at
> this point.

Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API for others 
to use, 
sc_seco_authenticate is the API that used for authentication. I could not
share more information about this API works inside SCFW and ROM.
sc_err_t sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t 
addr)

SPL will call this API, one parameter is address which needs a container image 
there.

> 
> > For authentication, we always let ROM to authenticate including SPL
> > authenticating U-Boot, so we need pass an image to ROM that ROM could
> > recognize when SPL booting 2nd image.
> 
> Shouldn't the CPU have some sort of facility, like a crypto engine, which
> authenticates whatever blob with the right signature against a key burned into
> the CPU ? If so, then you would just implement a crypto driver and pass the
> blob and signature to it. I suspect that's how it should work, how else would
> Linux be able to make use of these secure bits if it cannot call the bootrom
> anymore ?

sc_seco_authenticate on i.MX8 will always be available. It is exported by a 
runtime
firmware running on a Cortex-M core inside i.MX8. The API will do 
authentication,
its accepts container format image as input and no other format.

Thanks,
Peng.

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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-20 Thread Marek Vasut

On 5/21/19 4:55 AM, Peng Fan wrote:
[...]

> I do not know how other SoC vendor did FIT hardware secure boot,
> please share you have any information.

 The SPL can be in the custom format, but then can load fitImage with
 the next stage(s), right ?
>>>
>>> I am not able to follow you, could you share more details?
>>
>> Wrap the SPL into this custom format and then have the SPL
>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
>> Would that work ?
> 
> It not work.
> We already wrap SPL in i.MX container format, this patchset
> is to let SPL could load the 2nd container file which contains
> U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
> (U-Boot/DTB and etc), it could not pass secure boot authentication,
> because ROM not know fitimage, it only know i.MX container format.

It's not bootrom that authenticates the next stage, it's U-Boot SPL.
BootROM already authenticated and started the U-Boot SPL, so that's a
trusted code. Now this trusted code can authenticate and start the next
stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the
picture at this point.

> For authentication, we always let ROM to authenticate including
> SPL authenticating U-Boot, so we need pass an image to ROM that ROM
> could recognize when SPL booting 2nd image.

Shouldn't the CPU have some sort of facility, like a crypto engine,
which authenticates whatever blob with the right signature against a key
burned into the CPU ? If so, then you would just implement a crypto
driver and pass the blob and signature to it. I suspect that's how it
should work, how else would Linux be able to make use of these secure
bits if it cannot call the bootrom anymore ?

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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-20 Thread Peng Fan

Hi Marek,
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/21/19 4:31 AM, Peng Fan wrote:
> > Hi Marek,
> >
> >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >> container format file
> >>
> >> On 5/20/19 3:54 AM, Peng Fan wrote:
> >>> Hi Marek,
> >>>
>  Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>  container format file
> 
>  On 5/20/19 3:30 AM, Peng Fan wrote:
> > Hi Simon,
> >
> >> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> >> format file
> >>
> >> Hi Peng,
> >>
> >> On Tue, 7 May 2019 at 06:52, Peng Fan  wrote:
> >>>
> >>> i.MX8 only support AHAB secure boot with Container format image,
> >>> we could not use FIT to support secure boot, so introduce
> >>> container
> >>
> >> Why not FIT?
> >
> > Actually before we implement secure boot, we use FIT image,
> > however
> > i.MX8 only support i.MX container format image for secure boot,
> > The chip will verify the container image when secure boot. It
> > could not recognize FIT image. So we have to drop FIT image.
> >
> >>
> >>> support to let SPL could load container images.
> >>
> >> What is a container image? Can you please point to documentation?
> >
> > Sadly, there is no public reference manual. There is a doc that
> > has a bit of information.
> >
> 
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
>  m
> >
> 
> >>
> unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4
>  0nxp.co
> >
> 
> >>
> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
>  9c5c30163
> >
> 
> >>
> 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7
>  HCGdWHTCJ
> > bEpmGBio15j46U%3Dreserved=0
> 
>  Shouldn't it suffice for the SPL to be in this custom format ,
>  while the rest of the binaries can be in fitImage ?
> >>>
> >>> The issue is the SoC only support i.MX container format for secure
> >>> boot(AHAB boot), if we not use secure boot, FIT image do work and
> >>> could
> >> work well.
> >>>
> >>> We investigated using FIT for i.MX8 secure boot, but it does not
> >>> make sense we did a FIT wrapper for container. Container itself is
> >>> also an image format, it contains image load/entry/size and etc
> information.
> >>>
> >>> I add a kconfig entry in SPL code, it does not hurt others if the
> >>> Kconfig entry
> >> not chosen.
> >>>
> >>> I do not know how other SoC vendor did FIT hardware secure boot,
> >>> please share you have any information.
> >>
> >> The SPL can be in the custom format, but then can load fitImage with
> >> the next stage(s), right ?
> >
> > I am not able to follow you, could you share more details?
> 
> Wrap the SPL into this custom format and then have the SPL
> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
> Would that work ?

It not work.
We already wrap SPL in i.MX container format, this patchset
is to let SPL could load the 2nd container file which contains
U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
(U-Boot/DTB and etc), it could not pass secure boot authentication,
because ROM not know fitimage, it only know i.MX container format.

For authentication, we always let ROM to authenticate including
SPL authenticating U-Boot, so we need pass an image to ROM that ROM
could recognize when SPL booting 2nd image.

Thanks,
Peng.


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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-20 Thread Marek Vasut

On 5/21/19 4:31 AM, Peng Fan wrote:
> Hi Marek,
> 
>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
>> format file
>>
>> On 5/20/19 3:54 AM, Peng Fan wrote:
>>> Hi Marek,
>>>
 Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
 container format file

 On 5/20/19 3:30 AM, Peng Fan wrote:
> Hi Simon,
>
>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
>> format file
>>
>> Hi Peng,
>>
>> On Tue, 7 May 2019 at 06:52, Peng Fan  wrote:
>>>
>>> i.MX8 only support AHAB secure boot with Container format image,
>>> we could not use FIT to support secure boot, so introduce
>>> container
>>
>> Why not FIT?
>
> Actually before we implement secure boot, we use FIT image, however
> i.MX8 only support i.MX container format image for secure boot, The
> chip will verify the container image when secure boot. It could not
> recognize FIT image. So we have to drop FIT image.
>
>>
>>> support to let SPL could load container images.
>>
>> What is a container image? Can you please point to documentation?
>
> Sadly, there is no public reference manual. There is a doc that has
> a bit of information.
>

>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
 m
>

>> unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4
 0nxp.co
>

>> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
 9c5c30163
>

>> 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7
 HCGdWHTCJ
> bEpmGBio15j46U%3Dreserved=0

 Shouldn't it suffice for the SPL to be in this custom format , while
 the rest of the binaries can be in fitImage ?
>>>
>>> The issue is the SoC only support i.MX container format for secure
>>> boot(AHAB boot), if we not use secure boot, FIT image do work and could
>> work well.
>>>
>>> We investigated using FIT for i.MX8 secure boot, but it does not make
>>> sense we did a FIT wrapper for container. Container itself is also an
>>> image format, it contains image load/entry/size and etc information.
>>>
>>> I add a kconfig entry in SPL code, it does not hurt others if the Kconfig 
>>> entry
>> not chosen.
>>>
>>> I do not know how other SoC vendor did FIT hardware secure boot,
>>> please share you have any information.
>>
>> The SPL can be in the custom format, but then can load fitImage with the next
>> stage(s), right ?
> 
> I am not able to follow you, could you share more details?

Wrap the SPL into this custom format and then have the SPL
load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
Would that work ?

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

Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

2019-05-20 Thread Peng Fan

Hi Marek,

> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/20/19 3:54 AM, Peng Fan wrote:
> > Hi Marek,
> >
> >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >> container format file
> >>
> >> On 5/20/19 3:30 AM, Peng Fan wrote:
> >>> Hi Simon,
> >>>
>  Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
>  format file
> 
>  Hi Peng,
> 
>  On Tue, 7 May 2019 at 06:52, Peng Fan  wrote:
> >
> > i.MX8 only support AHAB secure boot with Container format image,
> > we could not use FIT to support secure boot, so introduce
> > container
> 
>  Why not FIT?
> >>>
> >>> Actually before we implement secure boot, we use FIT image, however
> >>> i.MX8 only support i.MX container format image for secure boot, The
> >>> chip will verify the container image when secure boot. It could not
> >>> recognize FIT image. So we have to drop FIT image.
> >>>
> 
> > support to let SPL could load container images.
> 
>  What is a container image? Can you please point to documentation?
> >>>
> >>> Sadly, there is no public reference manual. There is a doc that has
> >>> a bit of information.
> >>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
> >> m
> >>>
> >>
> unity.nxp.com%2Fdocs%2FDOC-343178data=02%7C01%7Cpeng.fan%4
> >> 0nxp.co
> >>>
> >>
> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
> >> 9c5c30163
> >>>
> >>
> 5%7C0%7C0%7C636939135344595378sdata=vmIaO78XmuL1tQJufqf7
> >> HCGdWHTCJ
> >>> bEpmGBio15j46U%3Dreserved=0
> >>
> >> Shouldn't it suffice for the SPL to be in this custom format , while
> >> the rest of the binaries can be in fitImage ?
> >
> > The issue is the SoC only support i.MX container format for secure
> > boot(AHAB boot), if we not use secure boot, FIT image do work and could
> work well.
> >
> > We investigated using FIT for i.MX8 secure boot, but it does not make
> > sense we did a FIT wrapper for container. Container itself is also an
> > image format, it contains image load/entry/size and etc information.
> >
> > I add a kconfig entry in SPL code, it does not hurt others if the Kconfig 
> > entry
> not chosen.
> >
> > I do not know how other SoC vendor did FIT hardware secure boot,
> > please share you have any information.
> 
> The SPL can be in the custom format, but then can load fitImage with the next
> stage(s), right ?

I am not able to follow you, could you share more details?

Thanks,
Peng.

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

Re: [U-Boot] [PULL] u-boot-mpc83xx/master

2019-05-20 Thread Tom Rini

On Mon, May 20, 2019 at 01:59:53PM +0200, Mario Six wrote:

> Hi Tom,
> 
> The following changes since commit 7eafd61a43b102808dc83066de35a1a51d00330f:
> 
>   ihs_mdio: Use new regmap interface (2019-05-20 13:50:35 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mpc83xx.git
> 
> for you to fetch changes up to 7eafd61a43b102808dc83066de35a1a51d00330f:
> 
>   ihs_mdio: Use new regmap interface (2019-05-20 13:50:35 +0200)
> 

NAK, sorry.  Minor, and I fixed up:
configs/MPC8349EMDS_SDRAM_defconfig is missing from
board/freescale/mpc8349emds/MAINTAINERS

But major, new fail to builds:
https://travis-ci.org/trini/u-boot/jobs/534940540

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] Pull request for mmc sub-system for v2019.07

2019-05-20 Thread Peng Fan

Hi Tom,

Please pull mmc-5-20 for v2019.07, this is to avoid break i.MX53 boot.

Thanks,
Peng

The following changes since commit e14d9ca4919e5bc987fc628135104f2b2c91af90:

  Merge git://git.denx.de/u-boot-x86 (2019-05-19 09:42:19 -0400)

are available in the Git repository at:

  https://github.com/MrVan/u-boot.git tags/mmc-5-20

for you to fetch changes up to b6a0427554424a9d6bb563cae4f487f38caf:

  Revert "mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue" (2019-05-20 
11:34:27 +0800)


Lukasz Majewski (1):
  Revert "mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue"

 drivers/mmc/fsl_esdhc.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 17/17] spi: Avoid using malloc() in a critical function

2019-05-20 Thread Simon Glass

Hi Urja,

On Mon, 20 May 2019 at 10:36, Urja Rannikko  wrote:
>
> Hi Simon,
>
> On Mon, May 20, 2019 at 7:09 PM Simon Glass  wrote:
> >
> > Hi Urja,
> 
> > Is it possible to add a build-time assert for this somewhere?
> I'm not sure, you'd need to check every user of these operations - i
> was going to suggest just bailing out with an error code or a runtime
> assert, and going through the users of the SPI_MEM_OP macros to make
> sure there's no surprises.

I think bailing out with -ENOSPC would be fine.

> >
> > Is VLA very large array? How large is very large?
> VLA as in variable length array, the C feature you're using above.
> For a reference of sorts, more on VLAs and the kernel, which got rid
> of them in 4.20: https://lwn.net/Articles/749064/

OK I see. My only concern with variable-length arrays is when the
length is unbounded. If we had a run-time check beforehand (size < 100
for example), then I suppose it would be OK. It seems like in this
case we don't need one though.

>
> > I think the stack is much better place than a fixed buffer for
> > something only 8 bytes in size.
> Yes.

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

Re: [U-Boot] [PATCH 1/2] fdtdec: test: Fix memory leak

2019-05-20 Thread Simon Glass

Hi Thierry,

On Mon, 20 May 2019 at 10:05, Thierry Reding  wrote:
>
> From: Thierry Reding 
>
> Free the memory allocated to store the test FDT upon test completion to
> avoid leaking the memory. We don't bother cleaning up on test failure
> since the code is broken in that case and should be fixed, in which case
> the leak would also go away.
>
> Reported-by: Tom Rini 
> Suggested-by: Heinrich Schuchardt 
> Signed-off-by: Thierry Reding 
> ---
>  lib/fdtdec_test.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
> index f6defe16c5a6..54efcc3d46ac 100644
> --- a/lib/fdtdec_test.c
> +++ b/lib/fdtdec_test.c
> @@ -138,6 +138,7 @@ static int run_test(const char *aliases, const char 
> *nodes, const char *expect)
> }
>
> printf("pass\n");
> +   free(blob);

Strictly speaking, CHECKVAL() can cause a function return in the case
of an error.

So a better solution might be to put the code after the malloc() into
a separate function.


> return 0;
>  }
>
> @@ -288,6 +289,7 @@ static int check_carveout(void)
> CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 2, 2), 0);
> CHECKOK(check_fdt_carveout(fdt, 2, 2));
>
> +   free(fdt);
> return 0;
>  }
>
> --
> 2.21.0
>

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

Re: [U-Boot] [PATCH v2 7/9] configs: migrate ubispl boards to KConfig

2019-05-20 Thread Enric Balletbo Serra

Missatge de Markus Klotzbuecher  del dia dc., 15 de maig
2019 a les 15:16:
>
> From: Markus Klotzbuecher 
>
> Migrate the ubispl configuration for the omap3_igep00x0 and
> am335x_igep003x boards to KConfig. Both boards were built with
> SOURCE_DATE_EPOCH=0 and found to be equal before and after.
>
> Signed-off-by: Markus Klotzbuecher 
> Cc: Heiko Schocher 
> Cc: Kyungmin Park 
> Cc: Javier Martínez Canillas 
> Cc: Enric Balletbo i Serra 

Acked-by: Enric Balletbo i Serra 

Thanks,
 Enric

> ---
> Changes for v2: new patch
>
>  configs/am335x_igep003x_defconfig | 12 
>  configs/igep00x0_defconfig| 12 
>  include/configs/am335x_igep003x.h | 16 
>  include/configs/omap3_igep00x0.h  | 14 --
>  4 files changed, 24 insertions(+), 30 deletions(-)
>
> diff --git a/configs/am335x_igep003x_defconfig 
> b/configs/am335x_igep003x_defconfig
> index f44fb09b31..5874831ba1 100644
> --- a/configs/am335x_igep003x_defconfig
> +++ b/configs/am335x_igep003x_defconfig
> @@ -21,6 +21,18 @@ CONFIG_VERSION_VARIABLE=y
>  CONFIG_SPL_FS_EXT4=y
>  CONFIG_SPL_I2C_SUPPORT=y
>  CONFIG_SPL_MTD_SUPPORT=y
> +CONFIG_SPL_UBI=y
> +CONFIG_SPL_UBI_MAX_VOL_LEBS=256
> +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144
> +CONFIG_SPL_UBI_MAX_PEBS=4096
> +CONFIG_SPL_UBI_PEB_OFFSET=4
> +CONFIG_SPL_UBI_VID_OFFSET=512
> +CONFIG_SPL_UBI_LEB_START=2048
> +CONFIG_SPL_UBI_INFO_ADDR=0x8808
> +CONFIG_SPL_UBI_VOL_IDS=8
> +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0
> +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3
> +CONFIG_SPL_UBI_LOAD_ARGS_ID=4
>  CONFIG_SPL_OS_BOOT=y
>  CONFIG_SPL_POWER_SUPPORT=y
>  CONFIG_SPL_WATCHDOG_SUPPORT=y
> diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> index 927d7f0ecd..ab11935f48 100644
> --- a/configs/igep00x0_defconfig
> +++ b/configs/igep00x0_defconfig
> @@ -17,6 +17,18 @@ CONFIG_SPL_TEXT_BASE=0x4020
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  # CONFIG_SPL_FS_EXT4 is not set
>  CONFIG_SPL_MTD_SUPPORT=y
> +CONFIG_SPL_UBI=y
> +CONFIG_SPL_UBI_MAX_VOL_LEBS=256
> +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144
> +CONFIG_SPL_UBI_MAX_PEBS=4096
> +CONFIG_SPL_UBI_PEB_OFFSET=4
> +CONFIG_SPL_UBI_VID_OFFSET=512
> +CONFIG_SPL_UBI_LEB_START=2048
> +CONFIG_SPL_UBI_INFO_ADDR=0x8808
> +CONFIG_SPL_UBI_VOL_IDS=8
> +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0
> +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3
> +CONFIG_SPL_UBI_LOAD_ARGS_ID=4
>  CONFIG_SPL_ONENAND_SUPPORT=y
>  CONFIG_SPL_OS_BOOT=y
>  CONFIG_CMD_SPL=y
> diff --git a/include/configs/am335x_igep003x.h 
> b/include/configs/am335x_igep003x.h
> index 5131cd38e4..5b5e16026e 100644
> --- a/include/configs/am335x_igep003x.h
> +++ b/include/configs/am335x_igep003x.h
> @@ -106,22 +106,6 @@
>  /* NAND support */
>  #define CONFIG_SYS_NAND_ONFI_DETECTION 1
>
> -/* SPL */
> -
> -/* UBI configuration */
> -#define CONFIG_SPL_UBI 1
> -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256
> -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024)
> -#define CONFIG_SPL_UBI_MAX_PEBS4096
> -#define CONFIG_SPL_UBI_VOL_IDS 8
> -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0
> -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID  3
> -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4
> -#define CONFIG_SPL_UBI_PEB_OFFSET  4
> -#define CONFIG_SPL_UBI_VID_OFFSET  512
> -#define CONFIG_SPL_UBI_LEB_START   2048
> -#define CONFIG_SPL_UBI_INFO_ADDR   0x8808
> -
>  /* NAND config */
>  #define CONFIG_SYS_NAND_5_ADDR_CYCLE
>  #define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \
> diff --git a/include/configs/omap3_igep00x0.h 
> b/include/configs/omap3_igep00x0.h
> index a95a9cc664..4ad7dc18b1 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -96,18 +96,4 @@
>  #define CONFIG_SYS_NAND_ECCBYTES   14
>  #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
>
> -/* UBI configuration */
> -#define CONFIG_SPL_UBI 1
> -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256
> -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024)
> -#define CONFIG_SPL_UBI_MAX_PEBS4096
> -#define CONFIG_SPL_UBI_VOL_IDS 8
> -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0
> -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID  3
> -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4
> -#define CONFIG_SPL_UBI_PEB_OFFSET  4
> -#define CONFIG_SPL_UBI_VID_OFFSET  512
> -#define CONFIG_SPL_UBI_LEB_START   2048
> -#define CONFIG_SPL_UBI_INFO_ADDR   0x8808
> -
>  #endif /* __IGEP00X0_H */
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

2019-05-20 Thread Atish Patra


On 5/20/19 10:26 AM, Björn Töpel wrote:

Waking this thread up, because I'm seeing similar behavior as Karsten
-- i.e. the system hangs when launching init.

Software:
QEMU emulator version 4.0.50 (v4.0.0-576-g6d8e75d41c58)
Linux kernel v5.2-rc1, defconfig
OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware")

Toolchain-wise: Ubuntu/Debian:
   riscv64-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0

Launching the VM with:
~/pkg/qemu/bin/qemu-system-riscv64 \
   -nographic  \

   -machine virt  \
   -smp 2  \
   -m 8G  \
   -object rng-random,filename=/dev/urandom,id=rng0  \
   -device virtio-rng-device,rng=rng0  \
   -append "console=ttyS0 selinux=0 apparmor=0 loglevel=7 rw
root=/dev/vda2"  \
   -device virtio-blk-device,drive=hd0  \
   -drive file=~/rv/play/debian-sid-sda.raw,format=raw,id=hd0  \
   -device virtio-net,mac=36:8c:88:13:10:d2,netdev=network0  \
   -netdev tap,id=network0,fd=3 3<>/dev/tap5

Where :
   -kernel ~/src/rv/opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
   -device 
loader,file=/home/btopel/build/rv/arch/riscv/boot/Image,addr=0x8020
\

or
   -kernel bbl \ # riscv-pk HEAD

* When riscv-pk carries the payload, the kernel boots and succeeds to
   launch init.
* Using OpenSBI commit 392749f6338a ("docs: Add documentation about
   dynamic firmware"), the kernel boots, but hangs/spins ("info
   registers" says it's "rdcycle").

Bisecting OpenSBI, it looks like commit 90cb4917b584 ("lib: Implement
sfence.vma correctly.") broke something. At least prior that, the VM
launches correctly.

I haven't looked further -- any ideas?


Thanks,
Björn

___
opensbi mailing list
open...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi



Try this patch. This should solve this issue.

http://lists.infradead.org/pipermail/opensbi/2019-May/000118.html


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

Re: [U-Boot] MMC boot broken on OMAP-L138 LCDK

2019-05-20 Thread Adam Ford

On Mon, May 20, 2019 at 10:00 AM Adam Ford  wrote:
>
> On Mon, May 20, 2019 at 7:38 AM Sekhar Nori  wrote:
> >
> > On 20/05/19 5:55 PM, Adam Ford wrote:
> > > What about adding a memset function to the end of spl_board_init() so
> > > after arch_cpu_init() is called,and after preloader_consol_init() is
> > > called, we clear BSS?  I ran some preliminary tests on da850evm and it
> > > didn't see to break anything.  There are a few boards that appear to
> > > do things in this order.
> >
> > This will work, but, looks like there is a desire to maintain some
> > "standard" around this. Ie board_init_r() can assume BSS is available
> > (see README -> Board Initialisation Flow:).
> >
> > Doing BSS init in in spl_board_init() called from board_init_r() will
> > violate that.
>
> Based on your previous comment about board_init_f and your comment
> above, I read through the readme and I agree with your assessment that
> the current setup appears to already violate the startup flow.
>
> Looking at board_f.c, there is a board_init_f which calls
> arch_cpu_init(), so I thought I might try to remove the call from
> spl_board_init.  This didn't work.  I then I attempted to rename
> spl_board_init to board_init_f to move these function calls earlier in
> the startup sequence. I also undefined SPL_BOARD_INIT from menuconfig,
> so the call to spl_board_init() wouldn't happen. Unfortunately, now
> the da850 doesn't start with that either.  If you have any
> suggestions, I'm willing to try them.

I just submitted a patch which moves the initialization to
board_init_f and clears BSS inside there.  I was only able to test it
on the da850evm.  I am trying to get the da850 to boot from MMC, but
it's not something I've done before, so it's taking a bit of time.  It
does appear to be recognizing whether or not the card initializes, but
I am not sure why it's not run u-boot.img yet.

With card installed:

U-Boot SPL 2019.07-rc2-00579-gc17c82f15a-dirty (May 20 2019 - 14:48:11 -0500)
>>SPL: board_init_r()
Trying to boot from MMC1
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Without card installed:

U-Boot SPL 2019.07-rc2-00579-gc17c82f15a-dirty (May 20 2019 - 14:48:11 -0500)
>>SPL: board_init_r()
Trying to boot from MMC1
Card did not respond to voltage select!
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I am at least making some progress.

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

[U-Boot] [PATCH] davinci: spl: Create board_init_f for explicit initialization

2019-05-20 Thread Adam Ford

The arch_cpu_init() and preloader_console_init() functions
were not getting called until board_init_r() as part of the
spl_board_init() functions.  This patch explicitly moves these
initialization sequences earlier in startup, and now clears BSS
per the suggested workflow in the README. This also means that
CONFIG_SPL_BOARD_INIT can be removed from the defconfig

Suggested-by: Sekhar Nori 
Signed-off-by: Adam Ford 

diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index 103639e347..05c78f1801 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -37,6 +37,33 @@ void spl_board_init(void)
preloader_console_init();
 }
 
+void board_init_f(ulong boot_flags)
+{
+   gd->flags = boot_flags;
+   gd->have_console = 0;
+
+   if (!(gd->flags & GD_FLG_SPL_INIT)) {
+   if (spl_init())
+   hang();
+   }
+
+   arch_cpu_init();
+
+   board_early_init_f();
+
+   /* setup GP timer */
+   timer_init();
+
+   /* UART clocks enabled and gd valid - init serial console */
+   preloader_console_init();
+
+   /* Clear the BSS. */
+   memset(__bss_start, 0, __bss_end - __bss_start);
+
+   /* load/boot image from boot device */
+   board_init_r(NULL, 0);
+}
+
 u32 spl_boot_device(void)
 {
switch (davinci_syscfg_regs->bootcfg) {
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 8c16d5c4f5..c095058282 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -21,7 +21,6 @@ CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_SPI_LOAD=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index b8eac0e659..7271016346 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -19,7 +19,6 @@ CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_TEXT_BASE=0x8000
-CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_NAND_SUPPORT=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH 1/1] efi_loader: check device path in InstallMultipleProtocolInterfaces

2019-05-20 Thread Heinrich Schuchardt

On 5/16/19 9:59 PM, Heinrich Schuchardt wrote:
> According to the UEFI spec InstallMultipleProtocolInterfaces() must check
> if a device path has already been installed. In this case it must return
> EFI_ALREADY_STARTED.
>
> Cf. UEFI SCT II 2.6 A (2017),
> 3.3.16 InstallMultipleProtocolInterfaces(), 5.1.3.16.1.
>
> Signed-off-by: Heinrich Schuchardt 

This patch causes iPXE to fail. It hangs when executing the iPXE `dhcp`
command. Some nice debugging ahead.

Best regards

Heinrich

> ---
>  lib/efi_loader/efi_boottime.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index ec6f5758de..d3f21f15b7 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -2334,6 +2334,7 @@ efi_status_t EFIAPI 
> efi_install_multiple_protocol_interfaces
>   efi_va_list argptr;
>   const efi_guid_t *protocol;
>   void *protocol_interface;
> + efi_handle_t old_handle;
>   efi_status_t r = EFI_SUCCESS;
>   int i = 0;
>
> @@ -2346,6 +2347,17 @@ efi_status_t EFIAPI 
> efi_install_multiple_protocol_interfaces
>   if (!protocol)
>   break;
>   protocol_interface = efi_va_arg(argptr, void*);
> + /* Check that a device path has not been installed before */
> + if (!guidcmp(protocol, _guid_device_path)) {
> + struct efi_device_path *dp = protocol_interface;
> +
> + r = EFI_CALL(efi_locate_device_path(protocol, ,
> + _handle));
> + if (r == EFI_SUCCESS) {
> + r = EFI_ALREADY_STARTED;
> + break;
> + }
> + }
>   r = EFI_CALL(efi_install_protocol_interface(
>   handle, protocol,
>   EFI_NATIVE_INTERFACE,
> --
> 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/4] add command env erase

2019-05-20 Thread Frank Wunderlich

Hi,

Just a friendly reminder.

Any comments on my patches?

Regards Frank

Am 28. April 2019 10:51:24 MESZ schrieb Frank Wunderlich 
:
>sometimes it is needed to erase the non-volatile environment
>e.g. for boot-up with builtin-environment or after resizing env
>
>this series add basic functionality for erasing environment from
>storage
>as a first storage-driver mmc is introduced, other needs to be added
>later
>
>changes since v3:
> - fixes
> - Kconfig-option as suggested by Simon Goldschmidt
> - including CONFIG_ENV_OFFSET_REDUND (4/4 is RFC)
>
>Frank Wunderlich (4):
>  env: register erase command
>  env: mmc: add erase-function
>  env: add option to use redundant offset
>  [RFC] env: call env_erase twice if CONFIG_ENV_OFFSET_REDUND is set
>
> cmd/Kconfig   |  8 
> cmd/nvedit.c  | 26 ++
> env/env.c | 30 ++
> env/mmc.c | 36 
> include/environment.h | 17 +
> 5 files changed, 117 insertions(+)
>
>--
>2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sun50i: a64: Fix broken A64-Teres-I board config

2019-05-20 Thread Jonas Smedegaard

Quoting Jagan Teki (2019-05-20 19:02:52)
> On Mon, May 20, 2019 at 10:03 PM Jagan Teki  
> wrote:
> >
> > Patchwork show empty while applying, please look into that.
> 
> Anyway, I have created and applied this change.

Oh, I saw this follow-up too late: Please ignore my re-post.

Thanks for applying!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

[U-Boot] [PATCH v2] sun50i: a64: Fix broken A64-Teres-I board config

2019-05-20 Thread Jonas Smedegaard

Set CONFIG_SPL_TEXT_BASE in teres_i_defconfig, as required since
commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig").

commit f89d6133eef2 ("configs: move CONFIG_SPL_TEXT_BASE to Kconfig")
was accepted before commit 997b857ae31f ("sun50i: a64: Add Olimex
A64-Teres-I board initial support") but after the latter was submitted.

commit 997b857ae31f ("sun50i: a64: Add Olimex A64-Teres-I board initial
support") was submitted prior to CONFIG_SPL_TEXT_BASE being moved but
accepted after the move, rendering the accepted patch broken at the time
of acceptance.

Tested-by: Jonas Smedegaard 
Signed-off-by: Jonas Smedegaard 
Series-Cc: Jagan Teki 

---


Changes in v2:
- Rephrase commit message

---
 configs/teres_i_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/teres_i_defconfig b/configs/teres_i_defconfig
index 421a8d3d40..1b57a48712 100644
--- a/configs/teres_i_defconfig
+++ b/configs/teres_i_defconfig
@@ -7,6 +7,7 @@ CONFIG_DRAM_ZQ=3881949
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_USB1_VBUS_PIN="PL7"
 CONFIG_I2C0_ENABLE=y
+CONFIG_SPL_TEXT_BASE=0x10060
 # CONFIG_CMD_FLASH is not set
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
-- 
2.20.1

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

Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig

2019-05-20 Thread Vagrant Cascadian

On 2019-05-20, Matwey V. Kornilov wrote:
> пн, 20 мая 2019 г. в 20:11, Vagrant Cascadian :
>>
>> On 2019-05-19, Matwey V. Kornilov wrote:
>> > The ROCK64 is a credit card size SBC based on Rockchip RK3328
>> > Quad-Core ARM Cortex A53.
>> >
>> > This series allow building u-boot SPL and u-boot.itb for Rock64
>> > board. The proprietary TPL is stil required for deploy:
>> >
>> >   ./tools/mkimage -n rk3328 -T rksd \
>> > -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img
>> >   cat ./spl/u-boot-spl.bin >> idbloader.img
>> >   dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
>> >   dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc
>>
>> Could you add a patch documenting this in doc/README.rockchip or a
>> board-specific README? That would be more useful than having to search
>> the git commit messages or mailing list archives.
>>
>>
>> Tested this patch series against v2019.07-rc2, and I was able to pxe
>> boot fine, but unfortunately was unable to boot from microSD.
>>
>> I presume this is caused by some other change since v2019.07-rc1, since
>> the earlier rock64 patches worked fine with microSD on v2019.07-rc1.\
>
> Thanks for the report. This series is based on 98b3156b0df4 At least
> bootefi works fine for me.

No obvious relevent changes between 98b3156b0df4 and v2019.07-rc2.

I haven't tested with bootefi ... will give that a try too.


> Do v1 patches works for you on v2019.07-rc2?

With some minor rebasing to apply to -rc2, the v1 patches fail in the
same way as the v2 patches on top of v2019.07-rc2.


live well,
  vagrant


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

Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

2019-05-20 Thread Björn Töpel

Waking this thread up, because I'm seeing similar behavior as Karsten
-- i.e. the system hangs when launching init.

Software:
QEMU emulator version 4.0.50 (v4.0.0-576-g6d8e75d41c58)
Linux kernel v5.2-rc1, defconfig
OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware")

Toolchain-wise: Ubuntu/Debian:
  riscv64-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0

Launching the VM with:
~/pkg/qemu/bin/qemu-system-riscv64 \
  -nographic  \

  -machine virt  \
  -smp 2  \
  -m 8G  \
  -object rng-random,filename=/dev/urandom,id=rng0  \
  -device virtio-rng-device,rng=rng0  \
  -append "console=ttyS0 selinux=0 apparmor=0 loglevel=7 rw
root=/dev/vda2"  \
  -device virtio-blk-device,drive=hd0  \
  -drive file=~/rv/play/debian-sid-sda.raw,format=raw,id=hd0  \
  -device virtio-net,mac=36:8c:88:13:10:d2,netdev=network0  \
  -netdev tap,id=network0,fd=3 3<>/dev/tap5

Where :
  -kernel ~/src/rv/opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
  -device 
loader,file=/home/btopel/build/rv/arch/riscv/boot/Image,addr=0x8020
\

or
  -kernel bbl \ # riscv-pk HEAD

* When riscv-pk carries the payload, the kernel boots and succeeds to
  launch init.
* Using OpenSBI commit 392749f6338a ("docs: Add documentation about
  dynamic firmware"), the kernel boots, but hangs/spins ("info
  registers" says it's "rdcycle").

Bisecting OpenSBI, it looks like commit 90cb4917b584 ("lib: Implement
sfence.vma correctly.") broke something. At least prior that, the VM
launches correctly.

I haven't looked further -- any ideas?


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

Re: [U-Boot] Please pull from u-boot-i2c

2019-05-20 Thread Tom Rini

On Mon, May 20, 2019 at 11:55:01AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3:
> 
>   Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to ca0a8f3e8c5920485e9ab2ebba30a01b901f6bb7:
> 
>   i2c: mxc: Hide kconfig based control in DM_I2C mode (2019-05-17 05:35:24 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

2019-05-20 Thread Tom Rini

On Mon, May 20, 2019 at 09:59:13AM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following Marvell related fix:
> 

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] [PATCH v5 01/13] m68k: add basic set of devicetrees

2019-05-20 Thread Tom Rini

On Mon, May 20, 2019 at 10:58:26PM +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:57 PM Jagan Teki  wrote:
> >
> > On Mon, Apr 22, 2019 at 7:36 PM Tom Rini  wrote:
> > >
> > > On Fri, Apr 19, 2019 at 12:10:39PM +0530, Jagan Teki wrote:
> > > > Hi Angelo,
> > > >
> > > > On Thu, Mar 14, 2019 at 2:17 AM Angelo Dureghello  
> > > > wrote:
> > > > >
> > > > > This patch adds a basic group of devicetrees, one for each
> > > > > cpu family, including actually just uart and dspi devices,
> > > > > since these are the drivers supporting devicetree (support
> > > > > added in this patch-set).
> > > > >
> > > > > Acked-by: Jagan Teki 
> > > > > Signed-off-by: Angelo Dureghello 
> > > > > ---
> > > >
> > > > Any chance to apply this series? I fine with spi dm conversion. merge
> > > > it asap, before MW.
> > > >
> > > > Reviewed-by: Jagan Teki 
> > >
> > > Yes, do you expect to have an m68k PR soon?  I think the series you've
> > > been working on is certainly stable enough to pull in and work on top of
> > > as needed, thanks!
> >
> > Yes it has spi changes dependency, would anyone is trying to pick?
> 
> Look like Angelo or anyone seems not responding on this thread, this
> would have spi dm conversion changes. I think I can pick this, Tom
> will that be OK?

I'll pick up the series, thanks.

-- 
Tom


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

Re: [U-Boot] [PATCH v5 01/13] m68k: add basic set of devicetrees

2019-05-20 Thread Jagan Teki

On Fri, Apr 26, 2019 at 8:57 PM Jagan Teki  wrote:
>
> On Mon, Apr 22, 2019 at 7:36 PM Tom Rini  wrote:
> >
> > On Fri, Apr 19, 2019 at 12:10:39PM +0530, Jagan Teki wrote:
> > > Hi Angelo,
> > >
> > > On Thu, Mar 14, 2019 at 2:17 AM Angelo Dureghello  wrote:
> > > >
> > > > This patch adds a basic group of devicetrees, one for each
> > > > cpu family, including actually just uart and dspi devices,
> > > > since these are the drivers supporting devicetree (support
> > > > added in this patch-set).
> > > >
> > > > Acked-by: Jagan Teki 
> > > > Signed-off-by: Angelo Dureghello 
> > > > ---
> > >
> > > Any chance to apply this series? I fine with spi dm conversion. merge
> > > it asap, before MW.
> > >
> > > Reviewed-by: Jagan Teki 
> >
> > Yes, do you expect to have an m68k PR soon?  I think the series you've
> > been working on is certainly stable enough to pull in and work on top of
> > as needed, thanks!
>
> Yes it has spi changes dependency, would anyone is trying to pick?

Look like Angelo or anyone seems not responding on this thread, this
would have spi dm conversion changes. I think I can pick this, Tom
will that be OK?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig

2019-05-20 Thread Matwey V. Kornilov

пн, 20 мая 2019 г. в 20:11, Vagrant Cascadian :
>
> On 2019-05-19, Matwey V. Kornilov wrote:
> > The ROCK64 is a credit card size SBC based on Rockchip RK3328
> > Quad-Core ARM Cortex A53.
> >
> > This series allow building u-boot SPL and u-boot.itb for Rock64
> > board. The proprietary TPL is stil required for deploy:
> >
> >   ./tools/mkimage -n rk3328 -T rksd \
> > -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img
> >   cat ./spl/u-boot-spl.bin >> idbloader.img
> >   dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
> >   dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc
>
> Could you add a patch documenting this in doc/README.rockchip or a
> board-specific README? That would be more useful than having to search
> the git commit messages or mailing list archives.
>
>
> Tested this patch series against v2019.07-rc2, and I was able to pxe
> boot fine, but unfortunately was unable to boot from microSD.
>
> I presume this is caused by some other change since v2019.07-rc1, since
> the earlier rock64 patches worked fine with microSD on v2019.07-rc1.\

Thanks for the report. This series is based on 98b3156b0df4 At least
bootefi works fine for me.
Do v1 patches works for you on v2019.07-rc2?

>
> Scanning mmc 1:6...
> Found /boot/extlinux/extlinux.conf
> Retrieving file: /boot/extlinux/extlinux.conf
> 1953 bytes read in 4 ms (476.6 KiB/s)
> U-Boot menu
> 1:  Debian GNU/Linux kernel 5.1.0-trunk-arm64
> 2:  Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target)
> 3:  Debian GNU/Linux kernel 5.0.0-trunk-arm64
> 4:  Debian GNU/Linux kernel 5.0.0-trunk-arm64 (rescue target)
> 5:  Debian GNU/Linux kernel 4.19.0-5-arm64
> 6:  Debian GNU/Linux kernel 4.19.0-5-arm64 (rescue target)
> Enter choice: 1
> 1:  Debian GNU/Linux kernel 5.1.0-trunk-arm64
> Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64
>  ** fs_devread read error - block
>  Skipping l0 for failure retrieving initrd
>  2:  Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target)
>  Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64
>  *** ERROR: Can't read GPT Entries ***
>  GPT: Failed to allocate memory for PTE
>  part_get_info_efi: *** ERROR: Invalid GPT ***
>  *** ERROR: Can't read GPT header ***
>
> I enabled CONFIG_CMD_CACHE=y and tried "dcache off" but that didn't
> appear to help anything. Any other suggestions?
>
>
> live well,
>   vagrant



-- 
With best regards,
Matwey V. Kornilov
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2019-05-20 Thread Jagan Teki

Hi Tom,

Please pull this PR.

Summary:
- mpc8xxx spi driver fixes (Mario)
- mpc8xxx spi dm conversion (Mario, Jagan)
- SPI DM Migration update (Jagan)

The following changes since commit 748198cb8d32d41bc35e6f492bac9948f339bece:

  Revert "Makefile: Prioritize external dtb if defined" (2019-05-19 18:09:35 
-0400)

are available in the Git repository at:

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

for you to fetch changes up to 93842e580cee40c9d3e70de625e4bd826a749e65:

  dm: MIGRATION: Update migration status for SPI (2019-05-20 22:18:54 +0530)


Jagan Teki (2):
  spi: mpc8xxx: Convert to DM
  dm: MIGRATION: Update migration status for SPI

Mario Six (17):
  spi: mpc8xxx: Use short type names
  spi: mpc8xxx: Fix comments
  spi: mpc8xxx: Rename camel-case variables
  spi: mpc8xxx: Fix space after cast
  spi: mpc8xxx: Fix function names in strings
  spi: mpc8xxx: Replace defines with enums
  spi: mpc8xxx: Use IO accessors
  spi: mpc8xxx: Simplify if
  spi: mpc8xxx: Get rid of is_read
  spi: mpc8xxx: Simplify logic a bit
  spi: mpc8xxx: Reduce scope of loop variables
  spi: mpc8xxx: Make code more readable
  spi: mpc8xxx: Rename variable
  spi: mpc8xxx: Document LEN setting better
  spi: mpc8xxx: Re-order transfer setup
  spi: mpc8xxx: Fix if check
  spi: mpc8xxx: Use get_timer

 doc/driver-model/MIGRATION.txt |   6 +-
 drivers/spi/Kconfig|  10 +-
 drivers/spi/mpc8xxx_spi.c  | 279 +++--
 3 files changed, 194 insertions(+), 101 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2019-05-20 Thread Jagan Teki

Hi Tom,

Please pull this PR.

Summary:
- H6 WDT reset fix (Clément)
- H6 SPL_TEXT_BASE fixes (Clément, Jonas)
- NPI-M1+ emac enablment (Emmanuel)

The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3:

  Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400)

are available in the Git repository at:

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

for you to fetch changes up to c598c4837d782f6d9481f4be07ae5d679c6df976:

  sun8i: h3: NanoPi M1 Plus: Add emac configuration (2019-05-20 22:37:35 +0530)


Clément Péron (2):
  arm: sunxi: h6: fix reset using r_wdog
  sun50i: h6: Fix Beelink GS1 board config

Emmanuel Vadot (1):
  sun8i: h3: NanoPi M1 Plus: Add emac configuration

Jonas Smedegaard (1):
  sun50i: a64: teres_i: Fix broken SPL_TEXT_BASE

 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 1 +
 arch/arm/mach-sunxi/board.c | 9 +++--
 configs/beelink_gs1_defconfig   | 1 +
 configs/nanopi_m1_plus_defconfig| 2 ++
 configs/teres_i_defconfig   | 1 +
 5 files changed, 12 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig

2019-05-20 Thread Vagrant Cascadian

On 2019-05-19, Matwey V. Kornilov wrote:
> The ROCK64 is a credit card size SBC based on Rockchip RK3328
> Quad-Core ARM Cortex A53.
>
> This series allow building u-boot SPL and u-boot.itb for Rock64
> board. The proprietary TPL is stil required for deploy:
>
>   ./tools/mkimage -n rk3328 -T rksd \
> -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img
>   cat ./spl/u-boot-spl.bin >> idbloader.img
>   dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
>   dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc

Could you add a patch documenting this in doc/README.rockchip or a
board-specific README? That would be more useful than having to search
the git commit messages or mailing list archives.

Tested this patch series against v2019.07-rc2, and I was able to pxe
boot fine, but unfortunately was unable to boot from microSD.

I presume this is caused by some other change since v2019.07-rc1, since
the earlier rock64 patches worked fine with microSD on v2019.07-rc1.

Scanning mmc 1:6...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1953 bytes read in 4 ms (476.6 KiB/s)
U-Boot menu
1:  Debian GNU/Linux kernel 5.1.0-trunk-arm64
2:  Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target)
3:  Debian GNU/Linux kernel 5.0.0-trunk-arm64
4:  Debian GNU/Linux kernel 5.0.0-trunk-arm64 (rescue target)
5:  Debian GNU/Linux kernel 4.19.0-5-arm64
6:  Debian GNU/Linux kernel 4.19.0-5-arm64 (rescue target)
Enter choice: 1
1:  Debian GNU/Linux kernel 5.1.0-trunk-arm64
Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64
 ** fs_devread read error - block
 Skipping l0 for failure retrieving initrd
 2:  Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target)
 Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64
 *** ERROR: Can't read GPT Entries ***
 GPT: Failed to allocate memory for PTE
 part_get_info_efi: *** ERROR: Invalid GPT ***
 *** ERROR: Can't read GPT header ***

I enabled CONFIG_CMD_CACHE=y and tried "dcache off" but that didn't
appear to help anything. Any other suggestions?

live well,
  vagrant

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

Re: [U-Boot] [PATCH 0/4] fs: fat: fixes for write under root directory

2019-05-20 Thread Heinrich Schuchardt

On 5/13/19 7:49 AM, AKASHI Takahiro wrote:
> This patch set contains three (independent) bug fixes relating to
> write operations to root directory. See each commit message
> for more details.
>
> Without those fixes, you may lose files that you created under root
> directory or will see the file system corrupted. This will happen
> particularly when you create (or even delete) many files repeatedly
> under root directory.
> (Non-root directory won't be affected.)
>
> I only tested my patches on limited number of file system instances,
> and hope that other people will also try them.
>
> -Takahiro Akashi
>
> AKASHI Takahiro (4):
>   fs: fat:  write to non-cluster-aligned root directory
>   fs: fat: flush a directory cluster properly
>   fs: fat: allocate a new cluster for root directory of fat32
>   test/py: test_fs: add tests for creating/deleting many files

Hello Takahiro,

I would be really happy if these patches would make it into v2019.07.
When running the SCT they make a big difference. I hope you have time to
resubmit these.

Best regards

Heinrich

>
>  fs/fat/fat.c  |  15 ++--
>  fs/fat/fat_write.c| 117 +++---
>  test/py/tests/test_fs/test_ext.py |  84 +
>  3 files changed, 165 insertions(+), 51 deletions(-)
>

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

Re: [U-Boot] [PATCH] sun50i: a64: Fix broken A64-Teres-I board config

2019-05-20 Thread Jagan Teki

On Mon, May 20, 2019 at 10:03 PM Jagan Teki  wrote:
>
> Patchwork show empty while applying, please look into that.

Anyway, I have created and applied this change.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sun50i: h6: Fix Beelink GS1 board config

2019-05-20 Thread Jagan Teki

On Mon, May 20, 2019 at 10:14 PM Clément Péron  wrote:
>
> Hi Jagan,
>
>
> On Mon, 20 May 2019 at 18:38, Jagan Teki  wrote:
> >
> > On Mon, May 20, 2019 at 10:07 PM Clément Péron  wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Mon, 20 May 2019 at 18:34, Jagan Teki  
> > > wrote:
> > > >
> > > > On Tue, May 14, 2019 at 11:56 PM  wrote:
> > > > >
> > > > > From: Clément Péron 
> > > > >
> > > > > SPL_TEXT_BASE has been moved to Kconfig with commit:
> > > > > f89d6133ee configs: move CONFIG_SPL_TEXT_BASE to Kconfig
> > > > >
> > > > > But Beelink GS1 config file has been introduced in the
> > > > > same time without this modification.
> > > > >
> > > > > Fix this by settings the CONFIG_SPL_TEXT_BASE
> > > > >
> > > > > Suggested-by: Jonas Smedegaard 
> > > > > Signed-off-by: Clément Péron 
> > > > > ---
> > > > >  configs/beelink_gs1_defconfig | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/configs/beelink_gs1_defconfig 
> > > > > b/configs/beelink_gs1_defconfig
> > > > > index ef4dd29549..f16d0fee22 100644
> > > > > --- a/configs/beelink_gs1_defconfig
> > > > > +++ b/configs/beelink_gs1_defconfig
> > > > > @@ -1,12 +1,13 @@
> > > > >  CONFIG_ARM=y
> > > > >  CONFIG_ARCH_SUNXI=y
> > > > > +CONFIG_NR_DRAM_BANKS=1
> > > > >  CONFIG_SPL=y
> > > > >  CONFIG_MACH_SUN50I_H6=y
> > > > >  CONFIG_MMC0_CD_PIN="PF6"
> > > > >  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > > >  # CONFIG_PSCI_RESET is not set
> > > > > -CONFIG_NR_DRAM_BANKS=1
> > > >
> > > > Change changes seems different
> > >
> > > This happens when I made the "make save_defconfig"
> > >
> > > Do you want to split this in two commits ?
> >
> > I can drop that while applying, if you agree?

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

Re: [U-Boot] [PATCH v2 00/19] spi: Convert MPC8XXX to DM

2019-05-20 Thread Jagan Teki

On Mon, Apr 29, 2019 at 1:59 AM Jagan Teki  wrote:
>
> This would be next version mpc8xxx dm conversion.
>
> No functional changes in v2 apart from rebase, and this would
> merge soon.
>
> Changes for v2:
> - rebase on master
> - patch for SPI MIGRATION status
>
> Any inputs?
> Jagan.
>
> Jagan Teki (2):
>   spi: mpc8xxx: Convert to DM
>   dm: MIGRATION: Update migration status for SPI
>
> Mario Six (17):
>   spi: mpc8xxx: Use short type names
>   spi: mpc8xxx: Fix comments
>   spi: mpc8xxx: Rename camel-case variables
>   spi: mpc8xxx: Fix space after cast
>   spi: mpc8xxx: Fix function names in strings
>   spi: mpc8xxx: Replace defines with enums
>   spi: mpc8xxx: Use IO accessors
>   spi: mpc8xxx: Simplify if
>   spi: mpc8xxx: Get rid of is_read
>   spi: mpc8xxx: Simplify logic a bit
>   spi: mpc8xxx: Reduce scope of loop variables
>   spi: mpc8xxx: Make code more readable
>   spi: mpc8xxx: Rename variable
>   spi: mpc8xxx: Document LEN setting better
>   spi: mpc8xxx: Re-order transfer setup
>   spi: mpc8xxx: Fix if check
>   spi: mpc8xxx: Use get_timer

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

Re: [U-Boot] [PATCH] sun50i: h6: Fix Beelink GS1 board config

2019-05-20 Thread Clément Péron

Hi Jagan,


On Mon, 20 May 2019 at 18:38, Jagan Teki  wrote:
>
> On Mon, May 20, 2019 at 10:07 PM Clément Péron  wrote:
> >
> > Hi Jagan,
> >
> > On Mon, 20 May 2019 at 18:34, Jagan Teki  wrote:
> > >
> > > On Tue, May 14, 2019 at 11:56 PM  wrote:
> > > >
> > > > From: Clément Péron 
> > > >
> > > > SPL_TEXT_BASE has been moved to Kconfig with commit:
> > > > f89d6133ee configs: move CONFIG_SPL_TEXT_BASE to Kconfig
> > > >
> > > > But Beelink GS1 config file has been introduced in the
> > > > same time without this modification.
> > > >
> > > > Fix this by settings the CONFIG_SPL_TEXT_BASE
> > > >
> > > > Suggested-by: Jonas Smedegaard 
> > > > Signed-off-by: Clément Péron 
> > > > ---
> > > >  configs/beelink_gs1_defconfig | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/configs/beelink_gs1_defconfig 
> > > > b/configs/beelink_gs1_defconfig
> > > > index ef4dd29549..f16d0fee22 100644
> > > > --- a/configs/beelink_gs1_defconfig
> > > > +++ b/configs/beelink_gs1_defconfig
> > > > @@ -1,12 +1,13 @@
> > > >  CONFIG_ARM=y
> > > >  CONFIG_ARCH_SUNXI=y
> > > > +CONFIG_NR_DRAM_BANKS=1
> > > >  CONFIG_SPL=y
> > > >  CONFIG_MACH_SUN50I_H6=y
> > > >  CONFIG_MMC0_CD_PIN="PF6"
> > > >  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > >  # CONFIG_PSCI_RESET is not set
> > > > -CONFIG_NR_DRAM_BANKS=1
> > >
> > > Change changes seems different
> >
> > This happens when I made the "make save_defconfig"
> >
> > Do you want to split this in two commits ?
>
> I can drop that while applying, if you agree?

Please do so,
Thanks,
Clément
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sun50i: h6: Fix Beelink GS1 board config

2019-05-20 Thread Jagan Teki

On Mon, May 20, 2019 at 10:07 PM Clément Péron  wrote:
>
> Hi Jagan,
>
> On Mon, 20 May 2019 at 18:34, Jagan Teki  wrote:
> >
> > On Tue, May 14, 2019 at 11:56 PM  wrote:
> > >
> > > From: Clément Péron 
> > >
> > > SPL_TEXT_BASE has been moved to Kconfig with commit:
> > > f89d6133ee configs: move CONFIG_SPL_TEXT_BASE to Kconfig
> > >
> > > But Beelink GS1 config file has been introduced in the
> > > same time without this modification.
> > >
> > > Fix this by settings the CONFIG_SPL_TEXT_BASE
> > >
> > > Suggested-by: Jonas Smedegaard 
> > > Signed-off-by: Clément Péron 
> > > ---
> > >  configs/beelink_gs1_defconfig | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/configs/beelink_gs1_defconfig b/configs/beelink_gs1_defconfig
> > > index ef4dd29549..f16d0fee22 100644
> > > --- a/configs/beelink_gs1_defconfig
> > > +++ b/configs/beelink_gs1_defconfig
> > > @@ -1,12 +1,13 @@
> > >  CONFIG_ARM=y
> > >  CONFIG_ARCH_SUNXI=y
> > > +CONFIG_NR_DRAM_BANKS=1
> > >  CONFIG_SPL=y
> > >  CONFIG_MACH_SUN50I_H6=y
> > >  CONFIG_MMC0_CD_PIN="PF6"
> > >  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > >  # CONFIG_PSCI_RESET is not set
> > > -CONFIG_NR_DRAM_BANKS=1
> >
> > Change changes seems different
>
> This happens when I made the "make save_defconfig"
>
> Do you want to split this in two commits ?

I can drop that while applying, if you agree?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH v3 3/3] arm: sunxi: h6: fix reset using r_wdog

2019-05-20 Thread Jagan Teki

On Tue, May 14, 2019 at 8:38 PM Clément Péron  wrote:
>
> Hi Jagan,
>
> On Tue, 14 May 2019 at 15:49, Jagan Teki  wrote:
> >
> > On Wed, Apr 17, 2019 at 11:11 PM Clément Péron  wrote:
> > >
> > > WDOG is broken for some H6 rev. The board is not
> > > reseted correctly.
> > >
> > > Use the R_WDOG instead.
> >
> > Can you describe the proper issue why it broken? this would really
> > help us to understand and future reference.
>
> I would like but I don't have much information on it.
> If I take the information in my 2nd email is it ok for you ?
>
> Something like this
> "
> Some H6 boards have a watchdog which didn't make the SoC reboot properly.
> Reason is still unknown but several people have test it.
> Chen-Yu Tsai :
> Pine H64 = H6 V200-AWIN H6448BA 7782 => OK
> OrangePi Lite 2 = H6 V200-AWIN H8068BA 61C2 => KO
>
> Martin Ayotte :
> Pine H64 = H8069BA 6892 => OK
> OrangePi 3 = HA047BA 69W2 => KO
> OrangePi One Plus = H7310BA 6842 => KO
> OrangePi Lite2 = H6448BA 6662 => KO
>
> Clément Péron:
> Beelink GS1 = H6 V200-AWIN H7309BA 6842 => KO
>
> After the series of result, Icenowy try to reach Allwinner about this
> issue but they seems not interested to investigate it.
>
> As we don't have the ARIS coproc to do power management and watchdogis
> the only solution to reset the board.
> Change from watchdog to R_watchdog to allow a reboot on all H6 boards.

Thanks, included this and

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

Re: [U-Boot] [PATCH] sun50i: h6: Fix Beelink GS1 board config

2019-05-20 Thread Clément Péron

Hi Jagan,

On Mon, 20 May 2019 at 18:34, Jagan Teki  wrote:
>
> On Tue, May 14, 2019 at 11:56 PM  wrote:
> >
> > From: Clément Péron 
> >
> > SPL_TEXT_BASE has been moved to Kconfig with commit:
> > f89d6133ee configs: move CONFIG_SPL_TEXT_BASE to Kconfig
> >
> > But Beelink GS1 config file has been introduced in the
> > same time without this modification.
> >
> > Fix this by settings the CONFIG_SPL_TEXT_BASE
> >
> > Suggested-by: Jonas Smedegaard 
> > Signed-off-by: Clément Péron 
> > ---
> >  configs/beelink_gs1_defconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/configs/beelink_gs1_defconfig b/configs/beelink_gs1_defconfig
> > index ef4dd29549..f16d0fee22 100644
> > --- a/configs/beelink_gs1_defconfig
> > +++ b/configs/beelink_gs1_defconfig
> > @@ -1,12 +1,13 @@
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_SUNXI=y
> > +CONFIG_NR_DRAM_BANKS=1
> >  CONFIG_SPL=y
> >  CONFIG_MACH_SUN50I_H6=y
> >  CONFIG_MMC0_CD_PIN="PF6"
> >  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> >  # CONFIG_PSCI_RESET is not set
> > -CONFIG_NR_DRAM_BANKS=1
>
> Change changes seems different

This happens when I made the "make save_defconfig"

Do you want to split this in two commits ?

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

Re: [U-Boot] [PATCH 17/17] spi: Avoid using malloc() in a critical function

2019-05-20 Thread Urja Rannikko

Hi Simon,

On Mon, May 20, 2019 at 7:09 PM Simon Glass  wrote:
>
> Hi Urja,

> Is it possible to add a build-time assert for this somewhere?
I'm not sure, you'd need to check every user of these operations - i
was going to suggest just bailing out with an error code or a runtime
assert, and going through the users of the SPI_MEM_OP macros to make
sure there's no surprises.
>
> Is VLA very large array? How large is very large?
VLA as in variable length array, the C feature you're using above.
For a reference of sorts, more on VLAs and the kernel, which got rid
of them in 4.20: https://lwn.net/Articles/749064/

> I think the stack is much better place than a fixed buffer for
> something only 8 bytes in size.
Yes.



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

Re: [U-Boot] [PATCH] sun50i: h6: Fix Beelink GS1 board config

2019-05-20 Thread Jagan Teki

On Tue, May 14, 2019 at 11:56 PM  wrote:
>
> From: Clément Péron 
>
> SPL_TEXT_BASE has been moved to Kconfig with commit:
> f89d6133ee configs: move CONFIG_SPL_TEXT_BASE to Kconfig
>
> But Beelink GS1 config file has been introduced in the
> same time without this modification.
>
> Fix this by settings the CONFIG_SPL_TEXT_BASE
>
> Suggested-by: Jonas Smedegaard 
> Signed-off-by: Clément Péron 
> ---
>  configs/beelink_gs1_defconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configs/beelink_gs1_defconfig b/configs/beelink_gs1_defconfig
> index ef4dd29549..f16d0fee22 100644
> --- a/configs/beelink_gs1_defconfig
> +++ b/configs/beelink_gs1_defconfig
> @@ -1,12 +1,13 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_SUNXI=y
> +CONFIG_NR_DRAM_BANKS=1
>  CONFIG_SPL=y
>  CONFIG_MACH_SUN50I_H6=y
>  CONFIG_MMC0_CD_PIN="PF6"
>  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>  # CONFIG_PSCI_RESET is not set
> -CONFIG_NR_DRAM_BANKS=1

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

Re: [U-Boot] [PATCH] sun50i: a64: Fix broken A64-Teres-I board config

2019-05-20 Thread Jagan Teki

Patchwork show empty while applying, please look into that.

On Mon, May 20, 2019 at 12:50 PM Jonas Smedegaard  wrote:
>
> [Adding Jagan as recipient]
>
> Anything more I can do to get below fix included?
>
>  - Jonas
>
> Quoting Jonas Smedegaard (2019-05-14 14:14:52)
> > Set CONFIG_SPL_TEXT_BASE in teres_i_defconfig
> > (see commit f89d6133ee)
> >
> > Tested-by: Jonas Smedegaard 
> > Signed-off-by: Jonas Smedegaard 
> > ---
> >
> >  configs/teres_i_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/configs/teres_i_defconfig b/configs/teres_i_defconfig
> > index 421a8d3d40..1b57a48712 100644
> > --- a/configs/teres_i_defconfig
> > +++ b/configs/teres_i_defconfig
> > @@ -7,6 +7,7 @@ CONFIG_DRAM_ZQ=3881949
> >  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> >  CONFIG_USB1_VBUS_PIN="PL7"
> >  CONFIG_I2C0_ENABLE=y
> > +CONFIG_SPL_TEXT_BASE=0x10060
> >  # CONFIG_CMD_FLASH is not set
> >  # CONFIG_SPL_DOS_PARTITION is not set
> >  # CONFIG_SPL_EFI_PARTITION is not set
> > --
> > 2.20.1
> >
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: davinci: remove leftover assembly

2019-05-20 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

There are no more users of lowlevel_init.S. Remove the file.

Suggested-by: Adam Ford 
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/Makefile|   4 -
 arch/arm/mach-davinci/lowlevel_init.S | 692 --
 2 files changed, 696 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/lowlevel_init.S

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 6887fe05dd..ed88274072 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -18,7 +18,3 @@ obj-$(CONFIG_SPL_FRAMEWORK)   += spl.o
 obj-$(CONFIG_SOC_DM365)+= dm365_lowlevel.o
 obj-$(CONFIG_SOC_DA8XX)+= da850_lowlevel.o
 endif
-
-ifndef CONFIG_SKIP_LOWLEVEL_INIT
-obj-y  += lowlevel_init.o
-endif
diff --git a/arch/arm/mach-davinci/lowlevel_init.S 
b/arch/arm/mach-davinci/lowlevel_init.S
deleted file mode 100644
index b82dafad2b..00
--- a/arch/arm/mach-davinci/lowlevel_init.S
+++ /dev/null
@@ -1,692 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Low-level board setup code for TI DaVinci SoC based boards.
- *
- * Copyright (C) 2007 Sergey Kubushyn 
- *
- * Partially based on TI sources, original copyrights follow:
- */
-
-/*
- * Board specific setup info
- *
- * (C) Copyright 2003
- * Texas Instruments, 
- * Kshitij Gupta 
- *
- * Modified for OMAP 1610 H2 board by Nishant Kamat, Jan 2004
- *
- * Modified for OMAP 5912 OSK board by Rishi Bhattacharya, Apr 2004
- *
- * Modified for DV-EVM board by Rishi Bhattacharya, Apr 2005
- *
- * Modified for DV-EVM board by Swaminathan S, Nov 2005
- */
-
-#include 
-
-#define MDSTAT_STATE   0x3f
-
-.globl lowlevel_init
-lowlevel_init:
-#ifdef CONFIG_SOC_DM644X
-
-   /*---*
-* Mask all IRQs by setting all bits in the EINT default *
-*---*/
-   mov r1, $0
-   ldr r0, =EINT_ENABLE0
-   str r1, [r0]
-   ldr r0, =EINT_ENABLE1
-   str r1, [r0]
-
-   /*--*
-* Put the GEM in reset *
-*--*/
-
-   /* Put the GEM in reset */
-   ldr r8, PSC_GEM_FLAG_CLEAR
-   ldr r6, MDCTL_GEM
-   ldr r7, [r6]
-   and r7, r7, r8
-   str r7, [r6]
-
-   /* Enable the Power Domain Transition Command */
-   ldr r6, PTCMD
-   ldr r7, [r6]
-   orr r7, r7, $0x02
-   str r7, [r6]
-
-   /* Check for Transition Complete(PTSTAT) */
-checkStatClkStopGem:
-   ldr r6, PTSTAT
-   ldr r7, [r6]
-   andsr7, r7, $0x02
-   bne checkStatClkStopGem
-
-   /* Check for GEM Reset Completion */
-checkGemStatClkStop:
-   ldr r6, MDSTAT_GEM
-   ldr r7, [r6]
-   andsr7, r7, $0x100
-   bne checkGemStatClkStop
-
-   /* Do this for enabling a WDT initiated reset this is a workaround
-  for a chip bug.  Not required under normal situations */
-   ldr r6, P1394
-   mov r10, $0
-   str r10, [r6]
-
-   /*--*
-* Enable L1 & L2 Memories in Fast mode *
-*--*/
-   ldr r6, DFT_ENABLE
-   mov r10, $0x01
-   str r10, [r6]
-
-   ldr r6, MMARG_BRF0
-   ldr r10, MMARG_BRF0_VAL
-   str r10, [r6]
-
-   ldr r6, DFT_ENABLE
-   mov r10, $0
-   str r10, [r6]
-
-   /*--*
-* DDR2 PLL Initialization  *
-*--*/
-
-   /* Select the Clock Mode Depending on the Value written in the Boot 
Table by the run script */
-   mov r10, $0
-   ldr r6, PLL2_CTL
-   ldr r7, PLL_CLKSRC_MASK
-   ldr r8, [r6]
-   and r8, r8, r7
-   mov r9, r10, lsl $8
-   orr r8, r8, r9
-   str r8, [r6]
-
-   /* Select the PLLEN source */
-   ldr r7, PLL_ENSRC_MASK
-   and r8, r8, r7
-   str r8, [r6]
-
-   /* Bypass the PLL */
-   ldr r7, PLL_BYPASS_MASK
-   and r8, r8, r7
-   str r8, [r6]
-
-   /* Wait for few cycles to allow PLLEN Mux switch properly to bypass 
Clock */
-   mov r10, $0x20
-WaitPPL2Loop:
-   subsr10, r10, $1
-   bne WaitPPL2Loop
-
-   /* Reset the PLL */
-   ldr r7, PLL_RESET_MASK
-   and r8, r8, r7
-   str r8, [r6]
-
-   /* Power up the PLL */
-   ldr r7, PLL_PWRUP_MASK
-   and r8, r8, r7
-   str r8, [r6]
-
-   /* Enable the PLL from Disable Mode */
-   ldr r7, PLL_DISABLE_ENABLE_MASK
-

Re: [U-Boot] [PATCH 0/5] arm: remove leftover code for dm* SoCs

2019-05-20 Thread Bartosz Golaszewski

pon., 20 maj 2019 o 17:39 Adam Ford  napisał(a):
>
> On Mon, Apr 29, 2019 at 11:37 AM Bartosz Golaszewski  wrote:
> >
> > From: Bartosz Golaszewski 
> >
> > Commit 6761946fb716 ("arm: Remove unmaintained davinci boards") removed
> > support for certain DaVinci platforms. We still want to support the
> > da850 chips though and I'm currently working on converting all remaining
> > drivers to using the driver model (please don't remove it yet :)).
> >
> > This series is the first step: let's remove all leftover dead code. This
> > will make things easier when adding support for driver model to NAND and
> > EMAC drivers.
> >
> > Bartosz Golaszewski (5):
> >   net: davinci_emac: drop support for unused PHYs
> >   arm: davinci: remove dead code for PHYs used by DaVinci DM* boards
> >   nand: davinci: remove dead code for dm644x
> >   usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
> >   arm: davinci: remove leftover code for dm* SoCs
> >
> >  arch/arm/mach-davinci/Makefile|   1 -
> >  arch/arm/mach-davinci/cpu.c   | 116 -
> >  arch/arm/mach-davinci/dm355.c |  29 --
> >  arch/arm/mach-davinci/dm365.c |  19 -
> >  arch/arm/mach-davinci/dm365_lowlevel.c| 459 --
> >  arch/arm/mach-davinci/dm644x.c|  80 ---
> >  arch/arm/mach-davinci/dm646x.c|  25 -
> >  arch/arm/mach-davinci/dp83848.c   | 127 -
> >  arch/arm/mach-davinci/et1011c.c   |  41 --
> >  .../mach-davinci/include/mach/davinci_misc.h  |   4 +-
> >  .../arm/mach-davinci/include/mach/emac_defs.h |  56 ---
> >  arch/arm/mach-davinci/include/mach/gpio.h |  14 +-
> >  arch/arm/mach-davinci/include/mach/hardware.h | 216 -
> >  arch/arm/mach-davinci/include/mach/i2c_defs.h |   4 -
> >  .../mach-davinci/include/mach/syscfg_defs.h   |  49 --
> >  arch/arm/mach-davinci/ksz8873.c   |  52 --
> >  arch/arm/mach-davinci/lxt972.c| 112 -
> >  arch/arm/mach-davinci/misc.c  |   5 +-
> >  arch/arm/mach-davinci/psc.c   |  76 ---
> >  arch/arm/mach-davinci/spl.c   |   5 -
> >  drivers/mtd/nand/raw/davinci_nand.c   |  39 --
> >  drivers/net/ti/davinci_emac.c |  55 +--
> >  drivers/usb/musb/musb_hcd.c   |   6 -
> >  23 files changed, 9 insertions(+), 1581 deletions(-)
> >  delete mode 100644 arch/arm/mach-davinci/dm355.c
> >  delete mode 100644 arch/arm/mach-davinci/dm365.c
> >  delete mode 100644 arch/arm/mach-davinci/dm365_lowlevel.c
> >  delete mode 100644 arch/arm/mach-davinci/dm644x.c
> >  delete mode 100644 arch/arm/mach-davinci/dm646x.c
> >  delete mode 100644 arch/arm/mach-davinci/dp83848.c
> >  delete mode 100644 arch/arm/mach-davinci/et1011c.c
> >  delete mode 100644 arch/arm/mach-davinci/include/mach/syscfg_defs.h
> >  delete mode 100644 arch/arm/mach-davinci/ksz8873.c
> >  delete mode 100644 arch/arm/mach-davinci/lxt972.c
>
> What about the references to CONFIG_SOC_DM644X inside lowlevel_init.S?
>
> I am not even sure anyone calls this.
> >
> > --
> > 2.21.0
> >

Right, seems like nobody uses it anymore. I'll send a follow-up.

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

Re: [U-Boot] [PATCH 5/5] configs: nitrogen6x: Add DM_SPI/DM_SPI_FLASH support

2019-05-20 Thread Troy Kisky

No rush, but any comment on this series ?
I still need to take care of CONFIG_DM_SCSI/CONFIG_DM_VIDEO before July.

Thanks
Troy

On 5/8/2019 3:23 PM, Troy Kisky wrote:
> Add CONFIG_DM_SPI/CONFIG_DM_SPI_FLASH to all defconfigs whose board is
> nitrogen6x.
> 
> mx6qsabrelite_defconfig
> nitrogen6dl2g_defconfig
> nitrogen6dl_defconfig
> nitrogen6q2g_defconfig
> nitrogen6q_defconfig
> nitrogen6s1g_defconfig
> 
> Signed-off-by: Troy Kisky 
> ---
>  configs/mx6qsabrelite_defconfig | 2 ++
>  configs/nitrogen6dl2g_defconfig | 2 ++
>  configs/nitrogen6dl_defconfig   | 2 ++
>  configs/nitrogen6q2g_defconfig  | 2 ++
>  configs/nitrogen6q_defconfig| 2 ++
>  configs/nitrogen6s1g_defconfig  | 2 ++
>  configs/nitrogen6s_defconfig| 2 ++
>  7 files changed, 14 insertions(+)
> 
> diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
> index f7d6e22438..8a98004bce 100644
> --- a/configs/mx6qsabrelite_defconfig
> +++ b/configs/mx6qsabrelite_defconfig
> @@ -41,6 +41,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -50,6 +51,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_DM_THERMAL=y
>  CONFIG_USB=y
> diff --git a/configs/nitrogen6dl2g_defconfig b/configs/nitrogen6dl2g_defconfig
> index 36fe642b57..40a68bad2a 100644
> --- a/configs/nitrogen6dl2g_defconfig
> +++ b/configs/nitrogen6dl2g_defconfig
> @@ -44,6 +44,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -53,6 +54,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/nitrogen6dl_defconfig b/configs/nitrogen6dl_defconfig
> index aa308abb9b..8a5d52209c 100644
> --- a/configs/nitrogen6dl_defconfig
> +++ b/configs/nitrogen6dl_defconfig
> @@ -44,6 +44,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -53,6 +54,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/nitrogen6q2g_defconfig b/configs/nitrogen6q2g_defconfig
> index 18fae5b3f5..a3c087e7ff 100644
> --- a/configs/nitrogen6q2g_defconfig
> +++ b/configs/nitrogen6q2g_defconfig
> @@ -46,6 +46,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -55,6 +56,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/nitrogen6q_defconfig b/configs/nitrogen6q_defconfig
> index 609247dfe2..ad7e9830a9 100644
> --- a/configs/nitrogen6q_defconfig
> +++ b/configs/nitrogen6q_defconfig
> @@ -46,6 +46,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -55,6 +56,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/nitrogen6s1g_defconfig b/configs/nitrogen6s1g_defconfig
> index 4ad9cb37c6..c602a362cb 100644
> --- a/configs/nitrogen6s1g_defconfig
> +++ b/configs/nitrogen6s1g_defconfig
> @@ -44,6 +44,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -53,6 +54,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/nitrogen6s_defconfig b/configs/nitrogen6s_defconfig
> index f531858f6d..8e812d09f4 100644
> --- a/configs/nitrogen6s_defconfig
> +++ b/configs/nitrogen6s_defconfig
> @@ -44,6 +44,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x1200
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
> +CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SF_DEFAULT_MODE=0
>  CONFIG_SF_DEFAULT_SPEED=2500
> @@ -53,6 +54,7 @@ CONFIG_PHY_MICREL=y
>  CONFIG_PHY_MICREL_KSZ90X1=y
>  CONFIG_MII=y
>  CONFIG_SPI=y
> +CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y

Re: [U-Boot] [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to U-boot (tag: 5.0-rc3)

2019-05-20 Thread Simon Glass

Hi Lukasz,

On Sun, 19 May 2019 at 15:03, Lukasz Majewski  wrote:
>
> Hi Simon,
>
> > Hi Lukasz,
> >
> > On Sat, 18 May 2019 at 15:28, Lukasz Majewski  wrote:
> > >
> > > Hi Simon,
> > >
> > > This is not the newest patch set version of CCF (v3 vs. v4), but the
> > > comments/issues apply.
> > >
> > > > Hi Lukasz,
> > > >
> > > > On Thu, 25 Apr 2019 at 04:30, Lukasz Majewski 
> > > > wrote:
> > > > >
> > > > > This patch series brings the files from Linux kernel to provide
> > > > > clocks support as it is used on the Linux kernel with common
> > > > > clock framework [CCF] setup.
> > > > >
> > > > > This series also fixes several problems with current clocks and
> > > > > provides sandbox tests for functions addded to clk-uclass.c
> > > > > file.
> > > > >
> > > > > Design decisions/issues:
> > > > > =
> > > > >
> > > > > - U-boot's DM for clk differs from Linux CCF. The most notably
> > > > > difference is the lack of support for hierarchical clocks and
> > > > > "clock as a manager driver" (single clock DTS node acts as a
> > > > > starting point for all other clocks).
> > > > >
> > > > > - The clk_get_rate() now caches the previously read data (no
> > > > > need for recursive access.
> > > > >
> > > > > - On purpose the "manager" clk driver (clk-imx6q.c) is not using
> > > > > large table to store pointers to clocks - e.g.
> > > > > clk[IMX6QDL_CLK_USDHC2_SEL] =  Instead we use udevice's
> > > > > linked list for the same class (UCLASS_CLK). The rationale -
> > > > > when porting the code as is from Linux, one would need ~1KiB of
> > > > > RAM to store it. This is way too much if we do plan to use this
> > > > > driver in SPL.
> > > > >
> > > > > - The "central" structure of this patch series is struct udevice
> > > > > and its driver_data field contains the struct clk pointer (to
> > > > > the originally created one).
> > > > >
> > > > > - Up till now U-boot's driver model's CLK operates on udevice
> > > > > (main access to clock is by udevice ops)
> > > > >   In the CCF the access to struct clk (comprising pointer to
> > > > > *dev) is possible via dev_get_driver_data()
> > > > >
> > > > >   Storing back pointer (from udevice to struct clk) as
> > > > > driver_data is a convention for CCF.
> > > >
> > > > Ick. Why not use uclass-private data to store this, since every
> > > > UCLASS_CLK device can have a parent.
> > >
> > > The "private_data" field would be also a good place to store the
> > > back pointer from udevice to struct clk [*]. The problem with CCF
> > > and udevice's priv pointer is explained just below:
> > >
> > > >
> > > > >
> > > > > - I could use *private_alloc_size to allocate driver's 'private"
> > > > >   structures (dev->priv) for e.g. divider (struct clk_divider
> > > > > *divider) for IMX6Q clock, but this would change the original
> > > > > structure of the CCF code.
> > >
> > > The original Linux's CCF code for iMX relies on using kmalloc
> > > internally:
> > >
> > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/imx/clk-gate2.c#L139
> > > https://elixir.bootlin.com/linux/v5.1.2/source/drivers/clk/clk-divider.c#L471
> > >
> > > By using driver_data I've avoided the need to make more changes to
> > > the original Linux code.
> > >
> > > I could use udevice's priv with automatic data allocation but then
> > > the CCF ported code would require more changes and considering the
> > > (from the outset) need to "fit" this code into U-Boot's DM, it
> > > drives away from the original Linux code.
> >
> > Is the main change the need to cast driver_data?
>
> The main change would be to remove the per clock device memory
> allocation code (with exit paths) from the original CCF code.
>
> This shall not be so difficult.
>
> > Perhaps that could be
> > hidden in a helper function/macro, so that in U-Boot it can hide the
> > use of (struct clk_uc_priv *)dev_get_uclass_priv(clk->dev))>parent  ?
>
> Helper function would help to some extend as we operate on structures
> similar to:
>
> struct clk_gate2 {
> struct clk clk;
> void __iomem*reg;
> u8  bit_idx;
> u8  cgr_val;
> u8  flags;
> };
>
> The helper would return struct clk's address which is the same as
> struct's clk_gate2 (this is assured by C standard).
>
> >
> > >
> > >
> > > > >
> > > > > The question is if it would be better to use private_alloc_size
> > > > > (and dev->private) or stay with driver_data.
> > > > > The former requires some rewritting in CCF original code (to
> > > > > remove (c)malloc, etc), but comply with u-boot DM. The latter
> > > > > allows re-using the CCF code as is, but introduces some
> > > > > convention special for CCF (I'm not sure thought if dev->priv
> > > > > is NOT another convention as well).
> > > >
> > > > Yes I would like to avoid malloc() calls in drivers and use the
> > > > in-built mechanism.
> > >
> > > I see your point.
> > >
> > > If the community agrees - I can rewrite

Re: [U-Boot] [PATCH v1 04/10] Makefile: allow dm_mmc without of_control

2019-05-20 Thread Simon Glass

Hi Marcel,

On Sun, 19 May 2019 at 18:45, Marcel Ziswiler  wrote:
>
> Allow for CONFIG_DM_MMC with platform data rather than
> CONFIG_OF_CONTROL.

I don't think we want this.

Or put it another way, why do we want this? Can you add a motivation here?

Can you use OF_PLATDATA instead?

>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v1 05/10] dm: core: gracefully handle alias seq without of

2019-05-20 Thread Simon Glass

Hi Marcel,

On Sun, 19 May 2019 at 18:45, Marcel Ziswiler  wrote:
>
> Gracefully handle alias seq in the platform data rather than OF case.

I don't understand why this is needed or what it does.

Also if this is changing behaviour, then there should be a test for it.

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

Re: [U-Boot] [PATCH 17/17] spi: Avoid using malloc() in a critical function

2019-05-20 Thread Simon Glass

Hi Urja,

On Sun, 19 May 2019 at 11:04, Urja Rannikko  wrote:
>
> Hi,
>
> On Sat, May 18, 2019 at 6:05 PM Simon Glass  wrote:
> >
> > In general we should avoid calling malloc() and free() repeatedly in
> > U-Boot lest we turn it into tianocore. In SPL this can make SPI flash
> > unusable since free() is often a nop and allocation space is limited.
> >
> > In any case, these seems no need for malloc() since the number of bytes
> > is very small, perhaps less than 8.
> >
> > Signed-off-by: Simon Glass 
> > Fixes: d13f5b254a (spi: Extend the core to ease integration of SPI
> > memory controllers)
> >
> > ---
> >
> >  drivers/spi/spi-mem.c | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> > index b86eee75bcb..7aabebeff5f 100644
> > --- a/drivers/spi/spi-mem.c
> > +++ b/drivers/spi/spi-mem.c
> > @@ -201,7 +201,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const 
> > struct spi_mem_op *op)
> > unsigned int pos = 0;
> > const u8 *tx_buf = NULL;
> > u8 *rx_buf = NULL;
> > -   u8 *op_buf;
> > int op_len;
> > u32 flag;
> > int ret;
> > @@ -338,7 +337,17 @@ int spi_mem_exec_op(struct spi_slave *slave, const 
> > struct spi_mem_op *op)
> > }
> >
> > op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + 
> > op->dummy.nbytes;
> > -   op_buf = calloc(1, op_len);
> > +
> > +   /*
> > +* Avoid using malloc() here so that we can use this code in SPL 
> > where
> > +* simple malloc may be used. That implementation does not allow 
> > free()
> > +* so repeated calls to this code can exhaust the space.
> > +*
> > +* The value of op_len is small, since it does not include the 
> > actual
> > +* data being sent, only the op-code and address. In fact, it 
> > should be
> > +* possible to just use a small fixed value here instead of op_len.
> > +*/
> > +   u8 op_buf[op_len];
>
> I'd say just make this a fixed buffer instead of a VLA - less code
> space bloat and potential stack problems in case of nonsensical
> inputs.
>
> As for the size, 8 bytes would be fine and actually leave some margin:
> the most i would expect for op_len is 1 + 4 + 1 = 6 bytes (the lowest
> would be 1+3+0 and the usual 1+3+1).

Is it possible to add a build-time assert for this somewhere?

Is VLA very large array? How large is very large?

I think the stack is much better place than a fixed buffer for
something only 8 bytes in size.

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

Re: [U-Boot] [PATCH v1 06/10] kconfig: mmc: move pxa_mmc_generic to kconfig

2019-05-20 Thread Simon Glass

On Sun, 19 May 2019 at 18:45, Marcel Ziswiler  wrote:
>
> Move CONFIG_PXA_MMC_GENERIC to Kconfig.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  configs/colibri_pxa270_defconfig | 1 +
>  configs/zipitz2_defconfig| 1 +
>  drivers/mmc/Kconfig  | 8 
>  include/configs/pxa-common.h | 7 ---
>  include/configs/zipitz2.h| 8 
>  scripts/config_whitelist.txt | 1 -
>  6 files changed, 10 insertions(+), 16 deletions(-)

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

Re: [U-Boot] [PATCH v2 8/8] dm: doc: add documentation for pre-reloc properties in SPL and TPL

2019-05-20 Thread Simon Glass

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> Add documentation for the pre-reloc property in SPL and TPL device-tree:
> - u-boot,dm-pre-proper
> - u-boot,dm-pre-reloc
> - u-boot,dm-spl
> - u-boot,dm-tpl
>
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 
> ---
>
> Changes in v2:
> - rebase on master
>
>  doc/README.SPL  | 16 
>  doc/README.TPL  |  4 
>  doc/driver-model/README.txt |  4 
>  include/dm/ofnode.h |  6 --
>  include/dm/util.h   |  6 --
>  5 files changed, 32 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v3 1/7] cmd: part: Add 'number' sub-command

2019-05-20 Thread Roman Stratiienko

Are there any updates of this patch?

We need this functionality to retrieve UUID of the partition using it's name.
But there are lot of commands that supports only partition index as an
argument, so I assume it could be very useful there.
This command can be also used alone can be used to find root partition, e.g.:
gpt index mmc 0 system system_index
setenv bootargs="... root=/dev/mmcblk0p$system_index"

On Mon, May 20, 2019 at 4:27 PM Igor Opaniuk  wrote:
>
> + Roman
>
>
> On Thu, Mar 21, 2019 at 5:42 PM Igor Opaniuk  wrote:
> >
> > Hi Eugeniu,
> >
> >
> > On Mon, Mar 11, 2019 at 12:42 AM Eugeniu Rosca  
> > wrote:
> > >
> > >
> > > Hi Igor,
> > >
> > > On Mon, Feb 18, 2019 at 06:21:51PM +0200, Igor Opaniuk wrote:
> > > > From: Ruslan Trofymenko 
> > > >
> > > > This sub-command serves for getting the partition index from
> > > > partition name.
> > >
> > > [..]
> > >
> > > >   CMD_PART_INFO_SIZE,
> > > > + CMD_PART_INFO_NUMBER
> > >
> > > IMHO 's/number/index/' (when referring to the id of a partition) would
> > > make code and documentation more clear since 'number' can be confused
> > > with 'count' while 'index' is unequivocal.
> > >
> > > Feel free to ignore it though, as the terms seem to be intermixed in
> > > various places of Linux/U-Boot (my opinion still stands).
> >
> > Agree, will be fixed in v4.
> >
> > > The review comment also applies to other patches from this series:
> > >  - https://patchwork.ozlabs.org/patch/1044153/ ("[U-Boot,v3,2/7] disk:
> > >part: Extend API to get partition info")
> > >  - https://patchwork.ozlabs.org/patch/1044162/ ("[U-Boot,v3,6/7] doc:
> > >android: Add simple guide for A/B updates")
> > >  - https://patchwork.ozlabs.org/patch/1044160/ ("[U-Boot,v3,7/7] env:
> > >am57xx: Implement A/B boot process")
> > >
> > > Best regards,
> > > Eugeniu.
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
>
>
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk



-- 
Best regards,
Roman Stratiienko
Global Logic
ADIT Team
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] fdtdec: Remove fdt_{addr,size}_unpack()

2019-05-20 Thread Thierry Reding

From: Thierry Reding 

U-Boot already defines the {upper,lower}_32_bits() macros that have the
same purpose. Use the existing macros instead of defining new APIs.

Signed-off-by: Thierry Reding 
---
 include/fdtdec.h  | 24 
 lib/fdtdec.c  |  8 ++--
 lib/fdtdec_test.c |  8 ++--
 3 files changed, 12 insertions(+), 28 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 110aa6ab6dea..fa8e34f6f960 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -24,30 +24,6 @@
 typedef phys_addr_t fdt_addr_t;
 typedef phys_size_t fdt_size_t;
 
-static inline fdt32_t fdt_addr_unpack(fdt_addr_t addr, fdt32_t *upper)
-{
-   if (upper)
-#ifdef CONFIG_PHYS_64BIT
-   *upper = addr >> 32;
-#else
-   *upper = 0;
-#endif
-
-   return addr;
-}
-
-static inline fdt32_t fdt_size_unpack(fdt_size_t size, fdt32_t *upper)
-{
-   if (upper)
-#ifdef CONFIG_PHYS_64BIT
-   *upper = size >> 32;
-#else
-   *upper = 0;
-#endif
-
-   return size;
-}
-
 #ifdef CONFIG_PHYS_64BIT
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fea44a9a8c65..d0ba88897335 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1300,6 +1300,7 @@ int fdtdec_add_reserved_memory(void *blob, const char 
*basename,
fdt32_t cells[4] = {}, *ptr = cells;
uint32_t upper, lower, phandle;
int parent, node, na, ns, err;
+   fdt_size_t size;
char name[64];
 
/* create an empty /reserved-memory node if one doesn't exist */
@@ -1340,7 +1341,8 @@ int fdtdec_add_reserved_memory(void *blob, const char 
*basename,
 * Unpack the start address and generate the name of the new node
 * base on the basename and the unit-address.
 */
-   lower = fdt_addr_unpack(carveout->start, );
+   upper = upper_32_bits(carveout->start);
+   lower = lower_32_bits(carveout->start);
 
if (na > 1 && upper > 0)
snprintf(name, sizeof(name), "%s@%x,%x", basename, upper,
@@ -1374,7 +1376,9 @@ int fdtdec_add_reserved_memory(void *blob, const char 
*basename,
*ptr++ = cpu_to_fdt32(lower);
 
/* store one or two size cells */
-   lower = fdt_size_unpack(carveout->end - carveout->start + 1, );
+   size = carveout->end - carveout->start + 1;
+   upper = upper_32_bits(size);
+   lower = lower_32_bits(size);
 
if (ns > 1)
*ptr++ = cpu_to_fdt32(upper);
diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
index 54efcc3d46ac..e8bfd1fb1ec3 100644
--- a/lib/fdtdec_test.c
+++ b/lib/fdtdec_test.c
@@ -156,11 +156,13 @@ static int make_fdt_carveout_device(void *fdt, uint32_t 
na, uint32_t ns)
};
fdt32_t cells[4], *ptr = cells;
uint32_t upper, lower;
+   fdt_size_t size;
char name[32];
int offset;
 
/* store one or two address cells */
-   lower = fdt_addr_unpack(carveout.start, );
+   upper = upper_32_bits(carveout.start);
+   lower = lower_32_bits(carveout.start);
 
if (na > 1 && upper > 0)
snprintf(name, sizeof(name), "%s@%x,%x", basename, upper,
@@ -174,7 +176,9 @@ static int make_fdt_carveout_device(void *fdt, uint32_t na, 
uint32_t ns)
*ptr++ = cpu_to_fdt32(lower);
 
/* store one or two size cells */
-   lower = fdt_size_unpack(carveout.end - carveout.start + 1, );
+   size = carveout.end - carveout.start + 1;
+   upper = upper_32_bits(size);
+   lower = lower_32_bits(size);
 
if (ns > 1)
*ptr++ = cpu_to_fdt32(upper);
-- 
2.21.0

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

[U-Boot] [PATCH 1/2] fdtdec: test: Fix memory leak

2019-05-20 Thread Thierry Reding

From: Thierry Reding 

Free the memory allocated to store the test FDT upon test completion to
avoid leaking the memory. We don't bother cleaning up on test failure
since the code is broken in that case and should be fixed, in which case
the leak would also go away.

Reported-by: Tom Rini 
Suggested-by: Heinrich Schuchardt 
Signed-off-by: Thierry Reding 
---
 lib/fdtdec_test.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
index f6defe16c5a6..54efcc3d46ac 100644
--- a/lib/fdtdec_test.c
+++ b/lib/fdtdec_test.c
@@ -138,6 +138,7 @@ static int run_test(const char *aliases, const char *nodes, 
const char *expect)
}
 
printf("pass\n");
+   free(blob);
return 0;
 }
 
@@ -288,6 +289,7 @@ static int check_carveout(void)
CHECKVAL(make_fdt_carveout(fdt, FDT_SIZE, 2, 2), 0);
CHECKOK(check_fdt_carveout(fdt, 2, 2));
 
+   free(fdt);
return 0;
 }
 
-- 
2.21.0

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

[U-Boot] [PATCH v4 2/2] net: eth-uclass: Support device tree MAC addresses

2019-05-20 Thread Thierry Reding

From: Thierry Reding 

Add the standard Ethernet device tree bindings (imported from v5.0 of
the Linux kernel) and implement support for reading the MAC address for
Ethernet devices in the Ethernet uclass. If the "mac-address" property
exists, the MAC address will be parsed from that. If that property does
not exist, the "local-mac-address" property will be tried as fallback.

MAC addresses from device tree take precedence over the ones stored in
a network interface card's ROM.

Acked-by: Joe Hershberger 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Thierry Reding 
---
Changes in v4:
- do not clear MAC address on failure to avoid overwriting existing MAC
- fix build on xtensa (missing CONFIG_OF_CONTROL)

Changes in v3:
- add additional check to make sure the MAC address read from device
  tree is a valid MAC address

Changes in v2:
- use dev_read_u8_array_ptr()
---
 .../devicetree/bindings/net/ethernet.txt  | 66 +++
 net/eth-uclass.c  | 30 -
 2 files changed, 93 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ethernet.txt

diff --git a/Documentation/devicetree/bindings/net/ethernet.txt 
b/Documentation/devicetree/bindings/net/ethernet.txt
new file mode 100644
index ..cfc376bc977a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -0,0 +1,66 @@
+The following properties are common to the Ethernet controllers:
+
+NOTE: All 'phy*' properties documented below are Ethernet specific. For the
+generic PHY 'phys' property, see
+Documentation/devicetree/bindings/phy/phy-bindings.txt.
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+  assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last used 
by
+  the boot program; should be used in cases where the MAC address assigned to
+  the device by the boot program is different from the "local-mac-address"
+  property;
+- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
+- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
+- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
+  the maximum frame size (there's contradiction in the Devicetree
+  Specification).
+- phy-mode: string, operation mode of the PHY interface. This is now a de-facto
+  standard property; supported values are:
+  * "internal"
+  * "mii"
+  * "gmii"
+  * "sgmii"
+  * "qsgmii"
+  * "tbi"
+  * "rev-mii"
+  * "rmii"
+  * "rgmii" (RX and TX delays are added by the MAC when required)
+  * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the
+ MAC should not add the RX or TX delays in this case)
+  * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
+ should not add an RX delay in this case)
+  * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
+ should not add an TX delay in this case)
+  * "rtbi"
+  * "smii"
+  * "xgmii"
+  * "trgmii"
+  * "2000base-x",
+  * "2500base-x",
+  * "rxaui"
+  * "xaui"
+  * "10gbase-kr" (10GBASE-KR, XFI, SFI)
+- phy-connection-type: the same as "phy-mode" property but described in the
+  Devicetree Specification;
+- phy-handle: phandle, specifies a reference to a node representing a PHY
+  device; this property is described in the Devicetree Specification and so
+  preferred;
+- phy: the same as "phy-handle" property, not recommended for new bindings.
+- phy-device: the same as "phy-handle" property, not recommended for new
+  bindings.
+- rx-fifo-depth: the size of the controller's receive fifo in bytes. This
+  is used for components that can have configurable receive fifo sizes,
+  and is useful for determining certain configuration settings such as
+  flow control thresholds.
+- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
+  is used for components that can have configurable fifo sizes.
+- managed: string, specifies the PHY management type. Supported values are:
+  "auto", "in-band-status". "auto" is the default, it usess MDIO for
+  management if fixed-link is not specified.
+
+Child nodes of the Ethernet controller are typically the individual PHY devices
+connected via the MDIO bus (sometimes the MDIO bus controller is separate).
+They are described in the phy.txt file in this same directory.
+For non-MDIO PHY management see fixed-link.txt.
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 4225aabf1fa1..031d55862583 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -455,6 +455,26 @@ static int eth_pre_unbind(struct udevice *dev)
return 0;
 }
 
+static bool eth_dev_get_mac_address(struct udevice *dev, u8 mac[ARP_HLEN])
+{
+#if IS_ENABLED(CONFIG_OF_CONTROL)
+   const uint8_t *p;
+
+   p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
+   if (!p)
+   p =

[U-Boot] [PATCH v4 1/2] net: eth-uclass: Write MAC address to hardware after probe

2019-05-20 Thread Thierry Reding

From: Thierry Reding 

In order for the device to use the proper MAC address, which can have
been configured in the environment prior to the device being registered,
ensure that the MAC address is written after the device has been probed.
For devices that are registered before the network stack is initialized,
this is already done during eth_initialize(). If the Ethernet device is
on a bus that is not initialized on early boot, such as PCI, the device
is not available at the time eth_initialize() is called, so we need the
MAC address programming to also happen after probe.

Acked-by: Joe Hershberger 
Signed-off-by: Thierry Reding 
---
 net/eth-uclass.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 2ef20df19203..4225aabf1fa1 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -524,6 +524,8 @@ static int eth_post_probe(struct udevice *dev)
 #endif
}
 
+   eth_write_hwaddr(dev);
+
return 0;
 }
 
-- 
2.21.0

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

Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

2019-05-20 Thread Andre Przywara

On Mon, 20 May 2019 14:34:01 +0800
Andy Yan  wrote:

Hi,

> On 2019/5/19 上午12:26, Simon Glass wrote:
> > Hi Andy,
> >
> > Instead of this could you:
> >
> > - move ATF?  
> 
> All rockchip based arm64 ATF run from the start 64KB of dram as this 
> will give convenient for kernel manage the memory.

This is just BL31 of ATF, right?
ATF recently gained PIE support for BL31 [1], so by just enabling this in 
platform.mk you will get a relocatable BL31 image, with a very minimal runtime 
linker. Worked out of the box on Allwinner for me, but YMMV.
So you could load newer ATF builds everywhere.

Does that help you?

> On the other hand, change the ATF load address will break the 
> compatibility of the exiting firmware.

I am not sure what you mean with "compatibility of existing firmware"? Surely 
you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) into one 
image? And there would be no real mix and match, with older pre-compiled 
builds? So by changing the ATF base address and the load address in TPL at the 
same time you won't have issues?

Cheers,
Andre.

[1] 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=fc922ca87cc6af8277dc0eb710fc63a2957f0194

> > - change the SPL load address so it is not in the way (since TPL can
> > load to any address)  
> 
> The SPL is loaded by bootrom after TPL back to bootrom, so the load 
> address if fixed by bootrom code.
> 
> I know we can build mmc or other storage driver into TPL so we can use 
> tpl load spl on some platform that sram is big enough, but there are 
> also many rockchip soc has very small sram, so we tend to only do dram  
> initialization in tpl, and let bootrom load next stage .
> 
> > - (in extremis) create a function which does a memmove() and a jump,
> > copy it somewhere and run it (I think x86 does this)
> >
> > Regards,
> > Simon
> >
> > On Thu, 16 May 2019 at 06:22, Andy Yan  wrote:  
> >> Some times we want to relocate spl code to dram after dram
> >> initialization or relocate spl code to a high memory to avoid
> >> code overid.
> >>
> >> For example on Rockchip armv8 platform, we run with boot flow
> >> TPL->SPL->ATF->U-Boot.
> >> TPL run in sram and is responsible for dram initialization.
> >> SPL run from the start address of dram and is responsible for
> >> loading ATF and U-Boot.
> >>
> >> The case here is that the ATF load address is from 64KB of dram,
> >> which overlaps with spl code itself.
> >>
> >> So we want to relocate spl itself to high memory to aovid this.
> >>
> >> Signed-off-by: Andy Yan 
> >> ---
> >>
> >> Changes in v2:
> >> - Move Kconfig modification to PATCH 1/3
> >>
> >>   common/spl/spl.c | 55 
> >>   1 file changed, 55 insertions(+)
> >>
> >> diff --git a/common/spl/spl.c b/common/spl/spl.c
> >> index 88d4b8a9bf..affb65ccbd 100644
> >> --- a/common/spl/spl.c
> >> +++ b/common/spl/spl.c
> >> @@ -12,6 +12,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc)
> >>  return 0;
> >>   }
> >>
> >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD)
> >> +static void spl_setup_relocate(void)
> >> +{
> >> +   gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE;
> >> +   gd->new_gd = (gd_t *)gd;
> >> +   gd->start_addr_sp = gd->relocaddr;
> >> +   gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
> >> +
> >> +   gd->start_addr_sp -= gd->fdt_size;
> >> +   gd->new_fdt = (void *)gd->start_addr_sp;
> >> +   memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
> >> +   gd->fdt_blob = gd->new_fdt;
> >> +
> >> +   gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start;
> >> +}
> >> +#else
> >> +static void spl_setup_relocate(void)
> >> +{
> >> +
> >> +}
> >> +#endif
> >> +
> >>   void spl_set_bd(void)
> >>   {
> >>  /*
> >> @@ -460,6 +483,8 @@ int spl_early_init(void)
> >>  return ret;
> >>  gd->flags |= GD_FLG_SPL_EARLY_INIT;
> >>
> >> +   spl_setup_relocate();
> >> +
> >>  return 0;
> >>   }
> >>
> >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info 
> >> *spl_image,
> >>  return -ENODEV;
> >>   }
> >>
> >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && 
> >> !defined(CONFIG_TPL_BUILD)
> >> +static int spl_initr_dm(void)
> >> +{
> >> +   int ret;
> >> +
> >> +   /* Save the pre-reloc driver model and start a new one */
> >> +   gd->dm_root_f = gd->dm_root;
> >> +   gd->dm_root = NULL;
> >> +   bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r");
> >> +   ret = dm_init_and_scan(false);
> >> +   bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R);
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +#if defined(CONFIG_TIMER)
> >> +   gd->timer = NULL;
> >> +#endif
> >> +   serial_init();
> >> +
> >> +

[U-Boot] [PATCH 2/2] arm: dts: ficus: Enable booting from eMMC when using SPL

2019-05-20 Thread Manivannan Sadhasivam

This commits enables booting from eMMC when using SPL on 96Boards
Ficus board by adding SDHCI to boot order. Since the SDHCI driver
already has the reloc flag, this works straightaway.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/dts/rk3399-ficus-u-boot.dtsi | 1 +
 arch/arm/dts/rk3399-ficus.dts | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi 
b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
index eab86bdb30..67b63a8352 100644
--- a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
@@ -3,4 +3,5 @@
  * Copyright (C) 2019 Jagan Teki 
  */
 
+#include "rk3399-u-boot.dtsi"
 #include "rk3399-sdram-ddr3-1600.dtsi"
diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
index 4b2dd82b67..0f219f4a9c 100644
--- a/arch/arm/dts/rk3399-ficus.dts
+++ b/arch/arm/dts/rk3399-ficus.dts
@@ -15,6 +15,8 @@
 
chosen {
stdout-path = "serial2:150n8";
+   u-boot,spl-boot-order = \
+   , 
};
 
clkin_gmac: external-gmac-clock {
-- 
2.17.1

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

[U-Boot] [PATCH 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL

2019-05-20 Thread Manivannan Sadhasivam

This commits enables booting from eMMC when using SPL on 96Boards
Rock960 board by adding SDHCI to boot order. Since the SDHCI driver
already has the reloc flag, this works straightaway.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/dts/rk3399-rock960-u-boot.dtsi | 1 +
 arch/arm/dts/rk3399-rock960.dts | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/dts/rk3399-rock960-u-boot.dtsi 
b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
index 5256f6d3f2..7fb5072a9b 100644
--- a/arch/arm/dts/rk3399-rock960-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
@@ -3,4 +3,5 @@
  * Copyright (C) 2019 Jagan Teki 
  */
 
+#include "rk3399-u-boot.dtsi"
 #include "rk3399-sdram-lpddr3-2GB-1600.dtsi"
diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
index 7e06bc97e5..c8b9075c73 100644
--- a/arch/arm/dts/rk3399-rock960.dts
+++ b/arch/arm/dts/rk3399-rock960.dts
@@ -12,6 +12,8 @@
 
chosen {
stdout-path = "serial2:150n8";
+   u-boot,spl-boot-order = \
+   , 
};
 };
 
-- 
2.17.1

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

Re: [U-Boot] [PATCH 0/5] arm: remove leftover code for dm* SoCs

2019-05-20 Thread Adam Ford

On Mon, Apr 29, 2019 at 11:37 AM Bartosz Golaszewski  wrote:
>
> From: Bartosz Golaszewski 
>
> Commit 6761946fb716 ("arm: Remove unmaintained davinci boards") removed
> support for certain DaVinci platforms. We still want to support the
> da850 chips though and I'm currently working on converting all remaining
> drivers to using the driver model (please don't remove it yet :)).
>
> This series is the first step: let's remove all leftover dead code. This
> will make things easier when adding support for driver model to NAND and
> EMAC drivers.
>
> Bartosz Golaszewski (5):
>   net: davinci_emac: drop support for unused PHYs
>   arm: davinci: remove dead code for PHYs used by DaVinci DM* boards
>   nand: davinci: remove dead code for dm644x
>   usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
>   arm: davinci: remove leftover code for dm* SoCs
>
>  arch/arm/mach-davinci/Makefile|   1 -
>  arch/arm/mach-davinci/cpu.c   | 116 -
>  arch/arm/mach-davinci/dm355.c |  29 --
>  arch/arm/mach-davinci/dm365.c |  19 -
>  arch/arm/mach-davinci/dm365_lowlevel.c| 459 --
>  arch/arm/mach-davinci/dm644x.c|  80 ---
>  arch/arm/mach-davinci/dm646x.c|  25 -
>  arch/arm/mach-davinci/dp83848.c   | 127 -
>  arch/arm/mach-davinci/et1011c.c   |  41 --
>  .../mach-davinci/include/mach/davinci_misc.h  |   4 +-
>  .../arm/mach-davinci/include/mach/emac_defs.h |  56 ---
>  arch/arm/mach-davinci/include/mach/gpio.h |  14 +-
>  arch/arm/mach-davinci/include/mach/hardware.h | 216 -
>  arch/arm/mach-davinci/include/mach/i2c_defs.h |   4 -
>  .../mach-davinci/include/mach/syscfg_defs.h   |  49 --
>  arch/arm/mach-davinci/ksz8873.c   |  52 --
>  arch/arm/mach-davinci/lxt972.c| 112 -
>  arch/arm/mach-davinci/misc.c  |   5 +-
>  arch/arm/mach-davinci/psc.c   |  76 ---
>  arch/arm/mach-davinci/spl.c   |   5 -
>  drivers/mtd/nand/raw/davinci_nand.c   |  39 --
>  drivers/net/ti/davinci_emac.c |  55 +--
>  drivers/usb/musb/musb_hcd.c   |   6 -
>  23 files changed, 9 insertions(+), 1581 deletions(-)
>  delete mode 100644 arch/arm/mach-davinci/dm355.c
>  delete mode 100644 arch/arm/mach-davinci/dm365.c
>  delete mode 100644 arch/arm/mach-davinci/dm365_lowlevel.c
>  delete mode 100644 arch/arm/mach-davinci/dm644x.c
>  delete mode 100644 arch/arm/mach-davinci/dm646x.c
>  delete mode 100644 arch/arm/mach-davinci/dp83848.c
>  delete mode 100644 arch/arm/mach-davinci/et1011c.c
>  delete mode 100644 arch/arm/mach-davinci/include/mach/syscfg_defs.h
>  delete mode 100644 arch/arm/mach-davinci/ksz8873.c
>  delete mode 100644 arch/arm/mach-davinci/lxt972.c

What about the references to CONFIG_SOC_DM644X inside lowlevel_init.S?

I am not even sure anyone calls this.
>
> --
> 2.21.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/8] test: check u-boot properties in SPL device tree

2019-05-20 Thread Simon Glass

Hi Patrick,

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> Add a test to check the management of the u-boot relocation properties
> (fdtgrep result) for platdata generation or device tree SPL generation:
> - 'dm-pre-proper' and 'dm-tpl' not included in SPL
> - 'dm-pre-reloc' and 'dm-spl' included in SPL
>
> This patch also executes the version test (test_000_version) to check
> the correct start of the U-Boot after SPL execution.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - add some test for SPL with device tree
>
>  arch/sandbox/dts/test.dts| 18 ++
>  test/py/tests/test_ofplatdata.py | 53 
> 
>  test/run |  5 
>  3 files changed, 76 insertions(+)

I am starting to understand a bit now.

But I don't think we need to execute sandbox to check that fdtgrep is
doing the right thing. We can check the spl/u-boot-spl/tpl.dtb file
against what is expected, but running fdtdump over it, or by opening
the file with pylibfdt (see dtco//fdt.py) and looking for things we
expect.

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

Re: [U-Boot] [PATCH v2 5/8] test: move SPL test nodes in test device tree

2019-05-20 Thread Simon Glass

Hi Patrick.

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> Moves spl-test nodes in test device tree, selected by
> the new build option '--device-tree'.

Where is this build option?

>
> This patch also executes the version test (test_000_version) to check
> the correct start of the U-Boot after SPL execution.

What is test_000_version?

Again this patch needs  motivation. It is very hard for me to
understand what you are trying to do.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - move all spl test nodes in test dtb
>
>  arch/sandbox/dts/sandbox.dts   | 36 
>  arch/sandbox/dts/sandbox64.dts | 36 
>  arch/sandbox/dts/test.dts  | 36 
>  test/run   |  3 ++-
>  4 files changed, 38 insertions(+), 73 deletions(-)

Can you please check this series which creates a comment DT:

http://patchwork.ozlabs.org/project/uboot/list/?series=108546

Could you rebase on top of it? - u-boot-dm/sandbox-working

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

Re: [U-Boot] [PATCH v2 0/8] fdt: Allow indicating a node is for U-Boot proper only

2019-05-20 Thread Simon Glass

Hi Patrick,

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
>
> Hi,
>
> I create this v2 serie with:
>
> 1/ documentation update for previous patch
>[U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
>http://patchwork.ozlabs.org/patch/1081155/
>
>PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
>pre reloc properties in SPL and TPL device tree")
>but not the documentation.
>
> 2/ missing part for (patch 1/2)
>http://patchwork.ozlabs.org/project/uboot/list/?series=89846
>
> 3/ new tests for pre-reloc propertie in SPL as suggested by Simon
>(http://patchwork.ozlabs.org/patch/1081155/#2156621)
>
> Tell me if is better to split the serie.

Somehow this cover letter appears in a patch, hence some of my
confusion. I see what you are doing and it is a comprehensive
approach.

But please see my comments about comparing the .dtb file instead of
making sandbox print it out.

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

Re: [U-Boot] [PATCH v2 2/8] fdt: Allow to use EMBEDDED device tree for SPL

2019-05-20 Thread Simon Glass

Hi Patrick,

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> U-boot continue to use load DT from file system, this patch avoid

U-Boot

> an error when U-Boot "Error: Out of memory" when it try to map
> gd->fdt_blob (EMBEDDED pointer __dtb_dt_begin is not managed).

What is EMBEDDED? Do you mean CONFIG_OF_EMBED?

I don't think we should be using OF_EMBED for sandbox.

>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - solve issue for spl sandbox with dtb
>
>  lib/fdtdec.c | 6 ++
>  1 file changed, 6 insertions(+)

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

Re: [U-Boot] [PATCH v2 1/8] sandbox: add config for SPL boot with devicetree

2019-05-20 Thread Simon Glass

Hi Patrick,

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> Creates defconfig sandbox_spl_dtb_defconfig, same than
> sandbox_spl_defconfig but without CONFIG_SPL_OF_PLATDATA;
> to allow SPL compilation:
> - OF_HOSTFILE is changed to OF_EMBED.

What is this for? Each patch should have a motivation.

Is there are cover-letter for this series?

>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - add sandbox_spl_dtb_defconfig for test
>
>  board/sandbox/MAINTAINERS |   1 +
>  configs/sandbox_spl_dtb_defconfig | 199 
> ++
>  2 files changed, 200 insertions(+)
>  create mode 100644 configs/sandbox_spl_dtb_defconfig

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

Re: [U-Boot] [PATCH v4 00/13] clk: Port Linux common clock framework [CCF] to U-boot (tag: 5.0-rc3)

2019-05-20 Thread Simon Glass

Hi Lukasz,

On Sun, 19 May 2019 at 08:35, Lukasz Majewski  wrote:
>
> Hi Simon,
>
> > Hi Lukasz,
> >
> > On Sat, 18 May 2019 at 14:49, Lukasz Majewski  wrote:
> > >
> > > Hi Simon,
> > >
> > > > kHi Lukasz,
> > > >
> > > > On Thu, 16 May 2019 at 16:11, Lukasz Majewski 
> > > > wrote:
> > > > >
> > > > > This patch series brings the files from Linux kernel to provide
> > > > > clocks support as it is used on the Linux kernel with common
> > > > > clock framework [CCF] setup.
> > > > >
> > > > > This series also fixes several problems with current clocks and
> > > > > provides sandbox tests for functions addded to clk-uclass.c
> > > > > file.
> > > > >
> > > > > Repository:
> > > > > https://github.com/lmajewski/u-boot-dfu/commits/CCF-v4
> > > > >
> > > > >
> > > > > Changes in v4:
> > > > > - New patch
> > > > > - None
> > > > > - None
> > > > > - None
> > > > > - New patch
> > > > > - None
> > > > > - Port some more Linux code to facilitate imx8 code porting
> > > > > (most notably flags)
> > > > > - Explicitly use container_of() based macro to provide struct
> > > > > clk in various places (e.g. gate2, mux, etc)
> > > > >   Following patches has been squashed:
> > > > >   http://patchwork.ozlabs.org/patch/1093141/
> > > > >   http://patchwork.ozlabs.org/patch/1093142/
> > > > >   http://patchwork.ozlabs.org/patch/1093146/
> > > > > - New patch
> > > > >
> > > > > Changes in v3:
> > > > > - New patch
> > > > > - The rate information is now cached into struct clk field
> > > > > - The clk_get_parent() is used to get pointer to the parent
> > > > > struct clk
> > > > > - Replace -ENODEV with -ENOENT
> > > > > - Use **clkp instead of **c
> > > > > - New patch
> > > > > - New patch
> > > > >
> > > > > Lukasz Majewski (13):
> > > > >   clk: doc: Add documentation entry for Common Clock Framework
> > > > > [CCF] (i.MX)
> > > > >   dm: Fix documentation entry as there is no UCLASS_CLOCK uclass
> > > > >   clk: Remove clock ID check in .get_rate() of clk_fixed_*
> > > > >   clk: Extend struct clk to provide information regarding clock
> > > > > rate clk: Extend struct clk to provide clock type agnostic flags
> > > > >   clk: Provide struct clk for fixed rate clock
> > > > > (clk_fixed_rate.c) dm: clk: Define clk_get_parent() for clk
> > > > > operations dm: clk: Define clk_get_parent_rate() for clk
> > > > > operations dm: clk: Define clk_get_by_id() for clk operations
> > > > >   clk: test: Provide unit test for clk_get_by_id() method
> > > > >   clk: test: Provide unit test for clk_get_parent_rate() method
> > > > >   clk: Port Linux common clock framework [CCF] for imx6q to
> > > > > U-boot (tag: 5.0-rc3)
> > > > >   dm: clk: Extend clk_get_parent_rate() to support
> > > > > CLK_GET_RATE_NOCACHE flag
> > > > >
> > > > >  arch/sandbox/include/asm/clk.h |  16 
> > > > >  doc/imx/clk/ccf.txt|  83 +++
> > > > >  drivers/clk/Kconfig|  14 
> > > > >  drivers/clk/Makefile   |   2 +
> > > > >  drivers/clk/clk-divider.c  | 148
> > > > > ++
> > > > > drivers/clk/clk-fixed-factor.c |  87 
> > > > > drivers/clk/clk-mux.c  | 164
> > > > > +
> > > > > drivers/clk/clk-uclass.c   |  60 ++
> > > > > drivers/clk/clk.c  |  56 +
> > > > > drivers/clk/clk_fixed_factor.c |   3 -
> > > > > drivers/clk/clk_fixed_rate.c   |   8 +-
> > > > > drivers/clk/clk_sandbox_test.c |  49 +++
> > > > > drivers/clk/imx/Kconfig|   9 +++
> > > > > drivers/clk/imx/Makefile   |   2 +
> > > > > drivers/clk/imx/clk-gate2.c| 113 ++
> > > > > drivers/clk/imx/clk-imx6q.c| 179
> > > > > +
> > > > > drivers/clk/imx/clk-pfd.c  |  91 +
> > > > > drivers/clk/imx/clk-pllv3.c|  83 +++
> > > > > drivers/clk/imx/clk.h  |  75 +
> > > > > include/clk.h  |  37 -
> > > > > include/linux/clk-provider.h   | 115 ++
> > > > > test/dm/clk.c  |   4 +- 22 files changed, 1390
> > > > > insertions(+), 8 deletions(-) create mode 100644
> > > > > doc/imx/clk/ccf.txt create mode 100644
> > > > > drivers/clk/clk-divider.c create mode 100644
> > > > > drivers/clk/clk-fixed-factor.c create mode 100644
> > > > > drivers/clk/clk-mux.c create mode 100644 drivers/clk/clk.c
> > > > > create mode 100644 drivers/clk/imx/clk-gate2.c create mode
> > > > > 100644 drivers/clk/imx/clk-imx6q.c create mode 100644
> > > > > drivers/clk/imx/clk-pfd.c create mode 100644
> > > > > drivers/clk/imx/clk-pllv3.c create mode 100644
> > > > > drivers/clk/imx/clk.h create mode 100644
> > > > > include/linux/clk-provider.h
> > > >
> > > > I don't see any new tests here other a trivial change in
> > > > test/dm/clk.c
> > > >
> > > > When adding new functionality to the generic clock code, tests
> >

Re: [U-Boot] [PATCH v2 3/8] sandbox: add option show_of_embedded for spl test

2019-05-20 Thread Simon Glass

Hi Patrick,

On Mon, 20 May 2019 at 07:00, Patrick Delaunay  wrote:
>
> Add an option show_of_embedded used in SPL to dump the used device tree.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - add new option for spl test: show embedded dtb
>
>  arch/sandbox/cpu/spl.c   | 188 
> +++
>  arch/sandbox/cpu/start.c |   9 ++
>  arch/sandbox/include/asm/state.h |   1 +
>  3 files changed, 198 insertions(+)

Why not use fdtdump on spl/u-boot-spl.dtb ?

Failing that, can we use the existing code for printing a DT?

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

Re: [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由s...@google.com代发】

2019-05-20 Thread Simon Glass

Hi Andy,

On Mon, 20 May 2019 at 00:34, Andy Yan  wrote:
>
> Hi Simon:
>
> On 2019/5/19 上午12:26, Simon Glass wrote:
> > Hi Andy,
> >
> > Instead of this could you:
> >
> > - move ATF?
>
> All rockchip based arm64 ATF run from the start 64KB of dram as this
> will give convenient for kernel manage the memory.
>
> On the other hand, change the ATF load address will break the
> compatibility of the exiting firmware.
>
> > - change the SPL load address so it is not in the way (since TPL can
> > load to any address)
>
> The SPL is loaded by bootrom after TPL back to bootrom, so the load
> address if fixed by bootrom code.

I think you are creating a nightmare here. If you have to do things
like this for older and smaller SoCs, OK. But it should not be used
for newer ones that can do things properly.

The bootrom has so many limitations that it just creates pain.

>
> I know we can build mmc or other storage driver into TPL so we can use
> tpl load spl on some platform that sram is big enough, but there are
> also many rockchip soc has very small sram, so we tend to only do dram
> initialization in tpl, and let bootrom load next stage .

See above

>
> > - (in extremis) create a function which does a memmove() and a jump,
> > copy it somewhere and run it (I think x86 does this)

?


- Simon

> >
> > Regards,
> > Simon
> >
> > On Thu, 16 May 2019 at 06:22, Andy Yan  wrote:
> >> Some times we want to relocate spl code to dram after dram
> >> initialization or relocate spl code to a high memory to avoid
> >> code overid.
> >>
> >> For example on Rockchip armv8 platform, we run with boot flow
> >> TPL->SPL->ATF->U-Boot.
> >> TPL run in sram and is responsible for dram initialization.
> >> SPL run from the start address of dram and is responsible for
> >> loading ATF and U-Boot.
> >>
> >> The case here is that the ATF load address is from 64KB of dram,
> >> which overlaps with spl code itself.
> >>
> >> So we want to relocate spl itself to high memory to aovid this.
> >>
> >> Signed-off-by: Andy Yan 
> >> ---
> >>
> >> Changes in v2:
> >> - Move Kconfig modification to PATCH 1/3
> >>
> >>   common/spl/spl.c | 55 
> >>   1 file changed, 55 insertions(+)
> >>
> >> diff --git a/common/spl/spl.c b/common/spl/spl.c
> >> index 88d4b8a9bf..affb65ccbd 100644
> >> --- a/common/spl/spl.c
> >> +++ b/common/spl/spl.c
> >> @@ -12,6 +12,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc)
> >>  return 0;
> >>   }
> >>
> >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD)
> >> +static void spl_setup_relocate(void)
> >> +{
> >> +   gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE;
> >> +   gd->new_gd = (gd_t *)gd;
> >> +   gd->start_addr_sp = gd->relocaddr;
> >> +   gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
> >> +
> >> +   gd->start_addr_sp -= gd->fdt_size;
> >> +   gd->new_fdt = (void *)gd->start_addr_sp;
> >> +   memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
> >> +   gd->fdt_blob = gd->new_fdt;
> >> +
> >> +   gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start;
> >> +}
> >> +#else
> >> +static void spl_setup_relocate(void)
> >> +{
> >> +
> >> +}
> >> +#endif
> >> +
> >>   void spl_set_bd(void)
> >>   {
> >>  /*
> >> @@ -460,6 +483,8 @@ int spl_early_init(void)
> >>  return ret;
> >>  gd->flags |= GD_FLG_SPL_EARLY_INIT;
> >>
> >> +   spl_setup_relocate();
> >> +
> >>  return 0;
> >>   }
> >>
> >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info 
> >> *spl_image,
> >>  return -ENODEV;
> >>   }
> >>
> >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && 
> >> !defined(CONFIG_TPL_BUILD)
> >> +static int spl_initr_dm(void)
> >> +{
> >> +   int ret;
> >> +
> >> +   /* Save the pre-reloc driver model and start a new one */
> >> +   gd->dm_root_f = gd->dm_root;
> >> +   gd->dm_root = NULL;
> >> +   bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r");
> >> +   ret = dm_init_and_scan(false);
> >> +   bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R);
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +#if defined(CONFIG_TIMER)
> >> +   gd->timer = NULL;
> >> +#endif
> >> +   serial_init();
> >> +
> >> +   return 0;
> >> +}
> >> +#else
> >> +static int spl_initr_dm(void)
> >> +{
> >> +   return 0;
> >> +}
> >> +#endif
> >> +
> >>   void board_init_r(gd_t *dummy1, ulong dummy2)
> >>   {
> >>  u32 spl_boot_list[] = {
> >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> >>
> >>  debug(">>" SPL_TPL_PROMPT "board_init_r()\n");
> >>
> >> +   spl_initr_dm();
> >> +
> >>  spl_set_bd();
> >>
> >>   #if defined(CONFIG_SYS_SPL_MALLOC_START)
> >> --
> >> 2.17.1
> >>
> >>
> >>
> >
> >
>

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

2019-05-20 Thread Sam Protsenko

Anyway, from my side:

Reviewed-by: Sam Protsenko 

On Mon, May 20, 2019 at 6:16 PM Sam Protsenko
 wrote:
>
> Hi Eugeniu,
>
>
> On Mon, May 20, 2019 at 10:23 AM Eugeniu Rosca  wrote:
> >
> > Hi Simon
> > cc: Sam, Igor, feel free to correct/augment anything of below
> >
> > On Sat, May 18, 2019 at 10:33:02AM -0600, Simon Glass wrote:
> > > Hi Eugeniu,
> > >
> > > On Fri, 17 May 2019 at 08:46, Eugeniu Rosca  wrote:
> > > >
> > > > 'Bootloader Control Block' (BCB) is a well established term/acronym in
> > > > the Android namespace which refers to a location in a dedicated raw
> > > > (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> > > > which is used as media for exchanging messages between Android userspace
> > > > (particularly recovery [1]) and an Android-capable bootloader.
> > > >
> > [..]
> > >
> > > Where is this documented? Perhaps it should go in README.avb2?
> >
> > README.avb2 is solely about the "verified/secure" booting of Android,
> > while the 'bcb' command proposed in this patch can be useful both in
> > verified boot scenarios (e.g. full-featured U-Boot builds), as well
> > as in non-avb ones (e.g. development, PoC, demos, custom
> > configurations). Thus, I think that README.avb2 is not the best
> > place for 'bcb'.
> >
> > More generally, as somebody who uses git as an extension of himself, I
> > am quite happy with commit-only documentation. OTOH, for those who
> > receive U-Boot in tarballs or expect source-level docs/tutorials, I
> > agree that having the 'bcb' described in a README might be helpful.
> >
> > I can identify two Android-dedicated README files, but none of them
> > seems to be suitable for the new command:
> >  - doc/README.android-fastboot
> >  - doc/README.avb2
> >
> > Igor, Sam, what's your view on the above? Would you suggest creating
> > a doc/README.android-bcb or there is a more elegant solution to it?
> >
>
> Documentation would be nice. Although you already provided a generic
> description of 'bcb' command in 'help bcb', the user often wants to
> read more high-level documentation. I'd say, you can copy the
> description from commit message to doc/README.android-bcb, extending
> it with usual use-cases, and how this command can be used in those
> use-cases. For example, your pseudo-code for reboot reason you
> provided to me earlier, etc. Also, it can be useful to mention if
> Google have any requirements (mandatory or optional) for the
> bootloader (misc partition, reboot reason, recovery, etc), and how
> this 'bcb' command can help in those requirements implementation.
>
> All that said, IMHO documentation/test wise: it's not critical in this
> case, you can add that later, just to speed-up the whole development
> process and divide it into iterations. But that's for maintainers to
> decide, of course.
>
> Also, I've a feeling that we have another problem, more common than
> just a documentation. At the moment we have a bunch of Android related
> features, which don't have namespace separation on several levels:
>  - file/directories: we may want to move all Android related commands
> to sub-directory
>  - commands: we may want to add main command called "android" for all
> Android-related commands, or maybe just a prefix
>  - Kconfig: we may want to have some generic naming scheme for all
> Android-related commands
>  - Documentation, tests: the same here
>
> So at some point we will probably need to discuss and fix that
> somehow. Not here, of course :)
>
> > >
> > > Should it default to enabled if avb is used?
> >
> > I think at this specific moment in time, 'bcb' is orthogonal (meaning it
> > is neither a direct, nor a reverse dependency) to any other Android
> > feature in U-Boot. This could be re-assessed, if platform maintainers
> > start to rely on 'bcb' in their U-Boot environments on regular basis.
> >
> > --
> > Best Regards,
> > Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] mips: mt76xx: Implement new d-cache fix in last_stage_init()

2019-05-20 Thread Stefan Roese

With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
version") the init sequence has changed in arch_misc_init(), resulting
in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
When this happens, the first (or sometimes later ones as well) TFTP
command hangs and does not complete correctly. This leads to the
assumption that the d-cache is not in a clean state once the ethernet
driver is called (d-cache is used here for the buffers). The old work-
around with the cache flush somehow does not work any more now with
the new code change.

Testing has shown, that copying a 64KiB area in DDR at a very late
bootup time, directly before calling into the prompt, fixes this issue.
Flushing of the complete d-cache does not seem to necessary, as this
copy alone seems to fix this problem.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
 arch/mips/Kconfig   |  2 +-
 arch/mips/mach-mtmips/cpu.c | 21 -
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9cf8e9800d..e3e7945567 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -84,7 +84,7 @@ config ARCH_MTMIPS
select DM_SERIAL
imply DM_SPI
imply DM_SPI_FLASH
-   select ARCH_MISC_INIT
+   select LAST_STAGE_INIT
select MIPS_TUNE_24KC
select OF_CONTROL
select ROM_EXCEPTION_VECTORS
diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
index fcd0484a6d..7afc2c5940 100644
--- a/arch/mips/mach-mtmips/cpu.c
+++ b/arch/mips/mach-mtmips/cpu.c
@@ -69,17 +69,28 @@ int print_cpuinfo(void)
return 0;
 }
 
-int arch_misc_init(void)
+int last_stage_init(void)
 {
+   void *src, *dst;
+
+   src = malloc(SZ_64K);
+   dst = malloc(SZ_64K);
+   if (!src || !dst) {
+   printf("Can't allocate buffer for cache cleanup copy!\n");
+   return 0;
+   }
+
/*
 * It has been noticed, that sometimes the d-cache is not in a
 * "clean-state" when U-Boot is running on MT7688. This was
 * detected when using the ethernet driver (which uses d-cache)
-* and a TFTP command does not complete. Flushing the complete
-* d-cache (again?) here seems to fix this issue.
+* and a TFTP command does not complete. Copying an area of 64KiB
+* in DDR at a very late bootup time in U-Boot, directly before
+* calling into the prompt, seems to fix this issue.
 */
-   flush_dcache_range(gd->bd->bi_memstart,
-  gd->bd->bi_memstart + gd->ram_size - 1);
+   memcpy(dst, src, SZ_64K);
+   free(src);
+   free(dst);
 
return 0;
 }
-- 
2.21.0

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

[U-Boot] [PATCH 2/2] mips: mt76xx: gardena-smart-gateway: Enable CONFIG_USE_PREBOOT

2019-05-20 Thread Stefan Roese

Enable CONFIG_USE_PREBOOT on for the gardena mt7688 platforms, so that
this feature can be used here.

Signed-off-by: Stefan Roese 
Cc: Daniel Schwierzeck 
---
 configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 +
 configs/gardena-smart-gateway-mt7688_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig 
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index e09950637f..ec47beaf1d 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -12,6 +12,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env 
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig 
b/configs/gardena-smart-gateway-mt7688_defconfig
index ad0db2e723..cdc5221d6a 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -15,6 +15,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env 
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
-- 
2.21.0

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

Re: [U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

2019-05-20 Thread Sam Protsenko

Hi Eugeniu,


On Mon, May 20, 2019 at 10:23 AM Eugeniu Rosca  wrote:
>
> Hi Simon
> cc: Sam, Igor, feel free to correct/augment anything of below
>
> On Sat, May 18, 2019 at 10:33:02AM -0600, Simon Glass wrote:
> > Hi Eugeniu,
> >
> > On Fri, 17 May 2019 at 08:46, Eugeniu Rosca  wrote:
> > >
> > > 'Bootloader Control Block' (BCB) is a well established term/acronym in
> > > the Android namespace which refers to a location in a dedicated raw
> > > (i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
> > > which is used as media for exchanging messages between Android userspace
> > > (particularly recovery [1]) and an Android-capable bootloader.
> > >
> [..]
> >
> > Where is this documented? Perhaps it should go in README.avb2?
>
> README.avb2 is solely about the "verified/secure" booting of Android,
> while the 'bcb' command proposed in this patch can be useful both in
> verified boot scenarios (e.g. full-featured U-Boot builds), as well
> as in non-avb ones (e.g. development, PoC, demos, custom
> configurations). Thus, I think that README.avb2 is not the best
> place for 'bcb'.
>
> More generally, as somebody who uses git as an extension of himself, I
> am quite happy with commit-only documentation. OTOH, for those who
> receive U-Boot in tarballs or expect source-level docs/tutorials, I
> agree that having the 'bcb' described in a README might be helpful.
>
> I can identify two Android-dedicated README files, but none of them
> seems to be suitable for the new command:
>  - doc/README.android-fastboot
>  - doc/README.avb2
>
> Igor, Sam, what's your view on the above? Would you suggest creating
> a doc/README.android-bcb or there is a more elegant solution to it?
>

Documentation would be nice. Although you already provided a generic
description of 'bcb' command in 'help bcb', the user often wants to
read more high-level documentation. I'd say, you can copy the
description from commit message to doc/README.android-bcb, extending
it with usual use-cases, and how this command can be used in those
use-cases. For example, your pseudo-code for reboot reason you
provided to me earlier, etc. Also, it can be useful to mention if
Google have any requirements (mandatory or optional) for the
bootloader (misc partition, reboot reason, recovery, etc), and how
this 'bcb' command can help in those requirements implementation.

All that said, IMHO documentation/test wise: it's not critical in this
case, you can add that later, just to speed-up the whole development
process and divide it into iterations. But that's for maintainers to
decide, of course.

Also, I've a feeling that we have another problem, more common than
just a documentation. At the moment we have a bunch of Android related
features, which don't have namespace separation on several levels:
 - file/directories: we may want to move all Android related commands
to sub-directory
 - commands: we may want to add main command called "android" for all
Android-related commands, or maybe just a prefix
 - Kconfig: we may want to have some generic naming scheme for all
Android-related commands
 - Documentation, tests: the same here

So at some point we will probably need to discuss and fix that
somehow. Not here, of course :)

> >
> > Should it default to enabled if avb is used?
>
> I think at this specific moment in time, 'bcb' is orthogonal (meaning it
> is neither a direct, nor a reverse dependency) to any other Android
> feature in U-Boot. This could be re-assessed, if platform maintainers
> start to rely on 'bcb' in their U-Boot environments on regular basis.
>
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] include: android_bootloader_message.h: Minimize the diff to AOSP

2019-05-20 Thread Sam Protsenko

Reviewed-by: Sam Protsenko 

On Fri, May 17, 2019 at 5:46 PM Eugeniu Rosca  wrote:
>
> Perform the following updates:
>  - Relocate the commit id from the file to the description of U-Boot
>commit. The AOSP commit is c784ce50e8c10eaf70e1f97e24e8324aef45faf5.
>This is done to avoid stale references in the file itself. The
>reasoning is in https://patchwork.ozlabs.org/patch/1098056/#2170209.
>  - Minimize the diff to AOSP, to decrease the effort of the next AOSP
>backports. The background can be found in:
>https://patchwork.ozlabs.org/patch/1080394/#2168454.
>  - Guard the static_assert() calls by #ifndef __UBOOT__ ... #endif,
>to avoid compilation failures of files including the header.
>
> Signed-off-by: Eugeniu Rosca 
> ---
> v2:
>  - Newly pushed. No changes.
> ---
>  include/android_bootloader_message.h | 126 +++
>  1 file changed, 68 insertions(+), 58 deletions(-)
>
> diff --git a/include/android_bootloader_message.h 
> b/include/android_bootloader_message.h
> index b84789f02227..286d7ab0f31e 100644
> --- a/include/android_bootloader_message.h
> +++ b/include/android_bootloader_message.h
> @@ -2,7 +2,7 @@
>   * This is from the Android Project,
>   * Repository: https://android.googlesource.com/platform/bootable/recovery
>   * File: bootloader_message/include/bootloader_message/bootloader_message.h
> - * Commit: c784ce50e8c10eaf70e1f97e24e8324aef45faf5
> + * Commit: See U-Boot commit description
>   *
>   * Copyright (C) 2008 The Android Open Source Project
>   *
> @@ -12,18 +12,24 @@
>  #ifndef __ANDROID_BOOTLOADER_MESSAGE_H
>  #define __ANDROID_BOOTLOADER_MESSAGE_H
>
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#include 
> +#else
>  /* compiler.h defines the types that otherwise are included from stdint.h and
>   * stddef.h
>   */
>  #include 
> +#endif
>
> -/* Spaces used by misc partition are as below:
> - * 0   - 2K For bootloader_message
> - * 2K  - 16KUsed by Vendor's bootloader (the 2K - 4K range may be 
> optionally used
> - *  as bootloader_message_ab struct)
> - * 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B 
> devices
> - * Note that these offsets are admitted by bootloader,recovery and uncrypt, 
> so they
> - * are not configurable without changing all of them. */
> +// Spaces used by misc partition are as below:
> +// 0   - 2K For bootloader_message
> +// 2K  - 16KUsed by Vendor's bootloader (the 2K - 4K range may be 
> optionally used
> +//  as bootloader_message_ab struct)
> +// 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B 
> devices
> +// Note that these offsets are admitted by bootloader,recovery and uncrypt, 
> so they
> +// are not configurable without changing all of them.
>  static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0;
>  static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024;
>
> @@ -61,17 +67,17 @@ struct bootloader_message {
>  char status[32];
>  char recovery[768];
>
> -/* The 'recovery' field used to be 1024 bytes.  It has only ever
> - * been used to store the recovery command line, so 768 bytes
> - * should be plenty.  We carve off the last 256 bytes to store the
> - * stage string (for multistage packages) and possible future
> - * expansion. */
> +// The 'recovery' field used to be 1024 bytes.  It has only ever
> +// been used to store the recovery command line, so 768 bytes
> +// should be plenty.  We carve off the last 256 bytes to store the
> +// stage string (for multistage packages) and possible future
> +// expansion.
>  char stage[32];
>
> -/* The 'reserved' field used to be 224 bytes when it was initially
> - * carved off from the 1024-byte recovery field. Bump it up to
> - * 1184-byte so that the entire bootloader_message struct rounds up
> - * to 2048-byte. */
> +// The 'reserved' field used to be 224 bytes when it was initially
> +// carved off from the 1024-byte recovery field. Bump it up to
> +// 1184-byte so that the entire bootloader_message struct rounds up
> +// to 2048-byte.
>  char reserved[1184];
>  };
>
> @@ -79,10 +85,12 @@ struct bootloader_message {
>   * We must be cautious when changing the bootloader_message struct size,
>   * because A/B-specific fields may end up with different offsets.
>   */
> +#ifndef __UBOOT__
>  #if (__STDC_VERSION__ >= 201112L) || defined(__cplusplus)
>  static_assert(sizeof(struct bootloader_message) == 2048,
>"struct bootloader_message size changes, which may break A/B 
> devices");
>  #endif
> +#endif /* __UBOOT__ */
>
>  /**
>   * The A/B-specific bootloader message structure (4-KiB).
> @@ -108,7 +116,7 @@ struct bootloader_message_ab {
>  char slot_suffix[32];
>  char update_channel[128];
>
> -/* Round up the entire struct to 4096-byte. */
> +// Round up the entire struct to 4096-byte.
>  char reserved[1888];
>  };
>
> @@ -116,26

Re: [U-Boot] MMC boot broken on OMAP-L138 LCDK

2019-05-20 Thread Adam Ford

On Mon, May 20, 2019 at 7:38 AM Sekhar Nori  wrote:
>
> On 20/05/19 5:55 PM, Adam Ford wrote:
> > What about adding a memset function to the end of spl_board_init() so
> > after arch_cpu_init() is called,and after preloader_consol_init() is
> > called, we clear BSS?  I ran some preliminary tests on da850evm and it
> > didn't see to break anything.  There are a few boards that appear to
> > do things in this order.
>
> This will work, but, looks like there is a desire to maintain some
> "standard" around this. Ie board_init_r() can assume BSS is available
> (see README -> Board Initialisation Flow:).
>
> Doing BSS init in in spl_board_init() called from board_init_r() will
> violate that.

Based on your previous comment about board_init_f and your comment
above, I read through the readme and I agree with your assessment that
the current setup appears to already violate the startup flow.

Looking at board_f.c, there is a board_init_f which calls
arch_cpu_init(), so I thought I might try to remove the call from
spl_board_init.  This didn't work.  I then I attempted to rename
spl_board_init to board_init_f to move these function calls earlier in
the startup sequence. I also undefined SPL_BOARD_INIT from menuconfig,
so the call to spl_board_init() wouldn't happen. Unfortunately, now
the da850 doesn't start with that either.  If you have any
suggestions, I'm willing to try them.

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

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

2019-05-20 Thread Anatolij Gustschin

Hi Tom,

please pull video updates for v2019.07-rc3. cx9020 DM_VIDEO migration and
splash source patches have been submitted to the list before merge window
for v2019.07 closed, so I'm including them with some video fixes here.

Travis CI: https://travis-ci.org/vdsao/u-boot-video/builds/534729949

Thanks,
Anatolij

The following changes since commit 98b3156b0df4b0df9cb3a0bbfc240d0c4edd2638:

  Merge branch 'master' of git://git.denx.de/u-boot-samsung (2019-05-16 
07:09:59 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-video.git tags/video-for-2019.07-rc3

for you to fetch changes up to e63168a9ffae18f807f59925bb5d9d4623633e46:

  video: Factor out vidconsole_put_string() (2019-05-20 12:00:05 +0200)


- update for using splashfile instead of location->name
  when loading the splash image from a FIT
- updates for loading internal and external splash data from FIT
- DM_GPIO/DM_VIDEO migration for mx53 cx9020 board
- fix boot issue on mx6sabresd board after DM_VIDEO migration
- increase the max preallocated framebuffer BPP to 32 in ipuv3
  driver to prepare for configurations with higher color depth
- allow to use vidconsole_put_string() in board code for text
  output on LCD displays


Leo Ruan (2):
  splash: Use splashfile instead of location->name
  splash: Load internal and external data from FIT

Marek Vasut (2):
  video: ipuv3: Set max display bpp to 32
  video: Factor out vidconsole_put_string()

Peng Fan (1):
  imx: mx6sabresd: fix boot hang with video

Steffen Dirkwinkel (6):
  dm: arm: imx: cx9020: enable DM_GPIO
  dm: arm: imx: video: add compatible for imx53-ipu
  arm: imx: add ipu to imx53.dts and set dm-pre-reloc
  dm: arm: imx: cx9020: migrate to dm_video
  dm: arm: imx: cx9020: remove unused mmc functions
  arm: imx: cx9020: remove unnecessary includes

 arch/arm/dts/imx53.dtsi  | 137 +++
 arch/arm/dts/imx6q.dtsi  |   1 +
 arch/arm/dts/imx6qdl.dtsi|   1 +
 board/beckhoff/mx53cx9020/Makefile   |   2 +-
 board/beckhoff/mx53cx9020/mx53cx9020.c   |  95 ---
 board/beckhoff/mx53cx9020/mx53cx9020_video.c |  52 +-
 common/splash_source.c   |  65 -
 configs/mx53cx9020_defconfig |   5 +-
 configs/mx6sabresd_defconfig |   3 +-
 doc/README.splashprepare |   9 +-
 drivers/video/imx/mxc_ipuv3_fb.c |   3 +-
 drivers/video/vidconsole-uclass.c|  17 +++-
 include/configs/mx53cx9020.h |   6 +-
 include/video_console.h  |  16 
 test/dm/video.c  |   8 --
 15 files changed, 271 insertions(+), 149 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

2019-05-20 Thread Jagan Teki

On Mon, May 20, 2019 at 7:37 PM Fabio Estevam  wrote:
>
> Hi Lukasz,
>
> On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski  wrote:
>
> > I had similar issue on imx53 (hsc). The problem was with not properly
> > set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card
> > detect, so the SPL code after checking this got the impression that the
> > card is missing -> hence the -19 error.
> >
> > Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9
>
> I have also tried passing  the 'non-removable' property and still get
> the -19 error.

Look very strange, I have checked sabresd which has similar configs
and dts changes as icorem6. Thought that it would be another issue wrt
spl changes on this board, bisect might help?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

2019-05-20 Thread Fabio Estevam

Hi Lukasz,

On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski  wrote:

> I had similar issue on imx53 (hsc). The problem was with not properly
> set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card
> detect, so the SPL code after checking this got the impression that the
> card is missing -> hence the -19 error.
>
> Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9

I have also tried passing  the 'non-removable' property and still get
the -19 error.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Makefile: Prioritize external dtb if defined

2019-05-20 Thread Tom Rini

On Sun, May 19, 2019 at 11:07:03AM -0700, Michal Simek wrote:
> On 19. 05. 19 15:15, Marek Vasut wrote:
> > On 5/20/19 12:08 AM, Tom Rini wrote:
> >> On Mon, May 20, 2019 at 12:03:45AM +0200, Marek Vasut wrote:
> >>> On 5/19/19 10:44 PM, Tom Rini wrote:
>  On Mon, Mar 25, 2019 at 03:55:16PM +0100, Michal Simek wrote:
> 
> > Prioritize external dtb if its passed via EXT_DTB
> > than the dtb that was built in the tree. With this
> > patch it appends the specified external dtb to
> > the u-boot image.
> >
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Siva Durga Prasad Paladugu 
> > 
> > Reviewed-by: Simon Glass 
> 
>  Applied to u-boot/master, thanks!
> >>>
> >>> The R-Car Gen3 boards (r8a779{5,6}*_salvator-x_defconfig) u-boot.bin
> >>> size grew from 986 kiB to 1240 kiB with this patch, rendering the boards
> >>> unbootable. I expect there to be more such cases, so please revert until
> >>> there's new version which has this fixed.
> >>
> >> I must have messed something up when re-adjusting this to apply to top
> >> of tree.  I'll revert this, thanks for reporting.  Michal, please rebase
> >> the original patch and resend, thanks!
> > 
> > My guess is that it has to do with the LZO compression of the DTBs on
> > Gen3 , that fit-blob.itb is probably appended uncompressed or something.
> > 
> 
> This patch is already applied to the tree (commit below). It means you
> please revert what was added by: 3eaf6dcd9362b56e3217559401287dd8fa35b5b2
> 
> Thanks,
> Michal
> 
> commit c8c5e2b84d5d928472b68a51854b727ee90295b2
> Author: Michal Simek 
> AuthorDate: Sat Mar 23 11:13:00 2019 +0530
> Commit: Michal Simek 
> CommitDate: Tue Apr 16 11:52:02 2019 +0200
> 
> Makefile: Prioritize external dtb if defined
> 
> Prioritize external dtb if its passed via EXT_DTB
> than the dtb that was built in the tree. With this
> patch it appends the specified external dtb to
> the u-boot image.
> 
> Signed-off-by: Michal Simek 
> Signed-off-by: Siva Durga Prasad Paladugu
> 
> Reviewed-by: Simon Glass 

So I really did step in it, sigh.  Revert pushed this morning.

-- 
Tom


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

Re: [U-Boot] [PATCH v1 10/10] colibri_pxa270_defconfig: enable dm_mmc

2019-05-20 Thread Igor Opaniuk

On Mon, May 20, 2019 at 3:48 AM Marcel Ziswiler  wrote:
>
> Enable CONFIG_DM_MMC.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  configs/colibri_pxa270_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/colibri_pxa270_defconfig 
> b/configs/colibri_pxa270_defconfig
> index c9d7e4e7ce..609855fe7d 100644
> --- a/configs/colibri_pxa270_defconfig
> +++ b/configs/colibri_pxa270_defconfig
> @@ -28,6 +28,7 @@ CONFIG_CMD_FAT=y
>  CONFIG_ENV_IS_IN_FLASH=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> +CONFIG_DM_MMC=y
>  CONFIG_PXA_MMC_GENERIC=y
>  CONFIG_MTD_NOR_FLASH=y
>  CONFIG_FLASH_CFI_DRIVER=y
> --
> 2.21.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 01/10] mmc: add missing space before comment delimiter

2019-05-20 Thread Igor Opaniuk

On Mon, May 20, 2019 at 3:45 AM Marcel Ziswiler  wrote:
>
> Add missing space before a comment delimiter.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  drivers/mmc/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 456c1b4cc9..ede528dc5a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2672,7 +2672,7 @@ retry:
> if (err)
> return err;
>
> -   /* The internal partition reset to user partition(0) at every CMD0*/
> +   /* The internal partition reset to user partition(0) at every CMD0 */
> mmc_get_blk_desc(mmc)->hwpart = 0;
>
> /* Test for SD version 2 */
> --
> 2.21.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Senior Development Engineer,
Igor Opaniuk

Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 48
00 (main line)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 02/10] mmc: fsl_esdhc: annotate endifs

2019-05-20 Thread Igor Opaniuk

On Mon, May 20, 2019 at 3:46 AM Marcel Ziswiler  wrote:
>
> Annotate endifs to make CONFIG_IS_ENABLED(DM_MMC) or not more obvious.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  drivers/mmc/fsl_esdhc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 1b7de74a72..0742cd64e1 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -1372,7 +1372,7 @@ int fsl_esdhc_mmc_init(bd_t *bis)
> cfg->sdhc_clk = gd->arch.sdhc_clk;
> return fsl_esdhc_initialize(bis, cfg);
>  }
> -#endif
> +#endif /* !CONFIG_IS_ENABLED(DM_MMC) */
>
>  #ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
>  void mmc_adapter_card_type_ident(void)
> @@ -1635,7 +1635,7 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
> .execute_tuning = fsl_esdhc_execute_tuning,
>  #endif
>  };
> -#endif
> +#endif /* CONFIG_IS_ENABLED(DM_MMC) */
>
>  static struct esdhc_soc_data usdhc_imx7d_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> --
> 2.21.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Senior Development Engineer,
Igor Opaniuk

Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 48
00 (main line)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff

2019-05-20 Thread Patrick DELAUNAY

Hi Urja,

> 
> Hi,
> 
> On Thu, May 16, 2019 at 7:44 AM Patrick DELAUNAY
>  wrote:
> >
> > Hi Urja,
> >
> > > - if (type != SYSRESET_POWER)
> > > + if (type != SYSRESET_POWER_OFF)
> > >   return -EPROTONOSUPPORT;
> >
> > In fact in the next part of the code, we are supporting only
> > SYSRESET_POWER (reset with PMIC1 switch OFF and restart) and not
> > SYSRESET_POWER_OFF
> >
> > because Power Cycle if RREQ_EN=1
> >
> > I think you need to remove the update on this file for your patch and
> > I will modified this function is to support both mode
> Okay I will drop this part, but just to confirm... this means that currently 
> you have
> a configuration where using the poweroff command causes a power-cycle? Neat.

Yes and it was stange.

I choose it at the beginning of the project because for some hardware
configuration with STPMIC1, the VDD continue to be provided by the cell even 
if the power supply is still present in power off mode; HW team ask me to avoid 
this case,
to avoid the cell usage.

But it is more a workaround for the bad HW configuration, and I forget this 
point when I upstream the driver...

Your patch allow me to correct this point now (with 
http://patchwork.ozlabs.org/patch/1101856/) and
I come back to a normal behavior in the driver : driver execute the requested 
command.

Regards
Patrick

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

Re: [U-Boot] DM for ci_udc

2019-05-20 Thread Adam Ford

On Mon, May 20, 2019 at 7:13 AM Schrempf Frieder
 wrote:
>
> Hi Sven,
>
> On 06.05.19 12:12, Sven Schwermer wrote:
> > Hi,
> >
> > I’m running into linking issues when enabling CONFIG_DM_USB_GADGET with 
> > CONFIG_CI_UDC because dm_usb_gadget_handle_interrupts is not available. 
> > That made me look into what’s required to port ci_udc to driver model. I 
> > have a few conceptual questions about this:
> >
> > 1. Some other USB gadget drivers (dwc3-generic, ti-musb) seem to create a 
> > wrapper driver that binds either the gadget or the host-mode driver to the 
> > USB device, depending on the configured mode. Is this the desired approach?
> >
> > 2. I’m working with a i.MX6 (7) device so the host-mode driver is ehci-mx6, 
> > but I’ve seen that ci_udc is also used with other host-mode drivers. How 
> > would a wrapper work in this case where there are multiple possible 
> > host-mode drivers but one gadget driver?
> >
> > 3. Any tips and hints are welcome :)

I started a wrapper a while ago.  I posted an RFC to the mailing list,
but i never heard anything.  As of right now, my wrapper only supports
the host side, but it could easily be adapter to add the gadget.

https://patchwork.ozlabs.org/patch/1076080/

adam
>
> Did you make any progress with getting ci_udc to work with DM in SPL on
> i.MX?
> The reason I'm asking is, that I need the SDP feature and I also want to
> use DM for USB.
>
> Thanks,
> Frieder
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/7] cmd: part: Add 'number' sub-command

2019-05-20 Thread Igor Opaniuk

+ Roman


On Thu, Mar 21, 2019 at 5:42 PM Igor Opaniuk  wrote:
>
> Hi Eugeniu,
>
>
> On Mon, Mar 11, 2019 at 12:42 AM Eugeniu Rosca  wrote:
> >
> >
> > Hi Igor,
> >
> > On Mon, Feb 18, 2019 at 06:21:51PM +0200, Igor Opaniuk wrote:
> > > From: Ruslan Trofymenko 
> > >
> > > This sub-command serves for getting the partition index from
> > > partition name.
> >
> > [..]
> >
> > >   CMD_PART_INFO_SIZE,
> > > + CMD_PART_INFO_NUMBER
> >
> > IMHO 's/number/index/' (when referring to the id of a partition) would
> > make code and documentation more clear since 'number' can be confused
> > with 'count' while 'index' is unequivocal.
> >
> > Feel free to ignore it though, as the terms seem to be intermixed in
> > various places of Linux/U-Boot (my opinion still stands).
>
> Agree, will be fixed in v4.
>
> > The review comment also applies to other patches from this series:
> >  - https://patchwork.ozlabs.org/patch/1044153/ ("[U-Boot,v3,2/7] disk:
> >part: Extend API to get partition info")
> >  - https://patchwork.ozlabs.org/patch/1044162/ ("[U-Boot,v3,6/7] doc:
> >android: Add simple guide for A/B updates")
> >  - https://patchwork.ozlabs.org/patch/1044160/ ("[U-Boot,v3,7/7] env:
> >am57xx: Implement A/B boot process")
> >
> > Best regards,
> > Eugeniu.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot



--
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass

2019-05-20 Thread Patrick DELAUNAY

Hi Urja, 

> 
> This is a generic implementation. Add CONFIG_SYSRESET_CMD_POWEROFF
> to signal when we need it. Enable it from the STPMIC1 config and in sandbox.
> 
> The config flag is transitionary, that is it can be removed after all poweroff
> implementations use sysreset, and just have CMD_POWEROFF depend on
> sysreset.
> 
> Signed-off-by: Urja Rannikko 

Reviewed-by: Patrick Delaunay 

Tested on stm32mp1-ev1 with 2 other corrections:
 [U-Boot] pmic: stpmic1: add support for SYSRESET_POWER_OFF
http://patchwork.ozlabs.org/patch/1101856/

[U-Boot] sysreset: syscon: add support for power off
http://patchwork.ozlabs.org/patch/1101905/

Tested-by: Patrick Delaunay 

> ---
> v2: Fixup STPMIC1 config selection of CONFIG_SYSRESET_CMD_POWEROFF
> ---
>  arch/Kconfig |  1 +
>  arch/arm/mach-stm32mp/Makefile   |  3 ---
>  arch/arm/mach-stm32mp/cmd_poweroff.c | 24 
>  drivers/power/pmic/Kconfig   |  1 +
>  drivers/sysreset/Kconfig | 10 ++
>  drivers/sysreset/sysreset-uclass.c   | 18 ++
>  6 files changed, 30 insertions(+), 27 deletions(-)  delete mode 100644
> arch/arm/mach-stm32mp/cmd_poweroff.c
> 
> diff --git a/arch/Kconfig b/arch/Kconfig index 239289b885..83ff21dfd7 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -91,6 +91,7 @@ config SANDBOX
>   select LZO
>   select SPI
>   select SUPPORT_OF_CONTROL
> + select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
>   imply BITREVERSE
>   select BLOBLIST
>   imply CMD_DM
> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
> index 1493914a11..f59ced5ee1 100644
> --- a/arch/arm/mach-stm32mp/Makefile
> +++ b/arch/arm/mach-stm32mp/Makefile
> @@ -11,9 +11,6 @@ ifdef CONFIG_SPL_BUILD  obj-y += spl.o  else  obj-y +=
> bsec.o -ifndef CONFIG_STM32MP1_TRUSTED
> -obj-$(CONFIG_SYSRESET) += cmd_poweroff.o -endif  endif
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
>  obj-$(CONFIG_$(SPL_)DM_REGULATOR) += pwr_regulator.o diff --git
> a/arch/arm/mach-stm32mp/cmd_poweroff.c b/arch/arm/mach-
> stm32mp/cmd_poweroff.c
> deleted file mode 100644
> index 62347425a0..00
> --- a/arch/arm/mach-stm32mp/cmd_poweroff.c
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> -/*
> - * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) -{
> - int ret;
> -
> - puts("poweroff ...\n");
> - mdelay(100);
> -
> - ret = sysreset_walk(SYSRESET_POWER_OFF);
> -
> - if (ret == -EINPROGRESS)
> - mdelay(1000);
> -
> - /*NOTREACHED when power off*/
> - return CMD_RET_FAILURE;
> -}
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index
> b0cd260354..52edb29b48 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -234,6 +234,7 @@ config DM_PMIC_TPS65910  config PMIC_STPMIC1
>   bool "Enable support for STMicroelectronics STPMIC1 PMIC"
>   depends on DM_PMIC && DM_I2C
> + select SYSRESET_CMD_POWEROFF if CMD_POWEROFF &&
> !ARM_PSCI_FW
>   ---help---
>   The STPMIC1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF and 2 power
> switches.
>   It is accessed via an I2C interface. The device is used with STM32MP1
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig index
> 30aed2c4c1..4c883923bf 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -33,6 +33,16 @@ config TPL_SYSRESET
> 
>  if SYSRESET
> 
> +if CMD_POWEROFF
> +
> +config SYSRESET_CMD_POWEROFF
> + bool "sysreset implementation of the poweroff command"
> + help
> +   This should be selected by the appropriate PMIC driver if
> +   the poweroff command is enabled.
> +
> +endif
> +
>  config SYSRESET_GPIO
>   bool "Enable support for GPIO reset driver"
>   select DM_GPIO
> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-
> uclass.c
> index ad831c703a..39202588ae 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -118,6 +118,24 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
>   return 0;
>  }
> 
> +#if IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
> +int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> +argv[]) {
> + int ret;
> +
> + puts("poweroff ...\n");
> + mdelay(100);
> +
> + ret = sysreset_walk(SYSRESET_POWER_OFF);
> +
> + if (ret == -EINPROGRESS)
> + mdelay(1000);
> +
> + /*NOTREACHED when power off*/
> + return CMD_RET_FAILURE;
> +}
> +#endif
> +
>  static int sysreset_post_bind(struct udevice *dev)  {  #if
> defined(CONFIG_NEEDS_MANUAL_RELOC)
> --
> 2.21.0

Regards

Patrick Delaunay
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH v2 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff

2019-05-20 Thread Patrick DELAUNAY

Hi Urja,

> 
> It seems that SYSRESET_POWER_OFF was added recently, and all previous
> code used SYSRESET_POWER for poweroff. SYSRESET_POWER is supposed
> to be a PMIC-level power cycle, not a poweroff.
> 
> Signed-off-by: Urja Rannikko 

Reviewed-by: Patrick Delaunay 

For information: complete support of booth POWER sysreset case for stmpic1 is 
added by 
  
http://patchwork.ozlabs.org/project/uboot/list/?series=108685

> ---
> v2: Do not change STPMIC1 driver (thats actually SYSRESET_POWER)
> 
> Note: I didnt touch the test/dm/sysreset.c code yet, mostly because I wanted 
> to
> get feedback on this first and that i'd need to understand the tests properly 
> to do
> that (and i havent used them before at all).
> ---
>  arch/arm/mach-stm32mp/cmd_poweroff.c | 2 +-
>  arch/sandbox/cpu/state.c | 2 +-
>  drivers/sysreset/sysreset_psci.c | 2 +-
>  drivers/sysreset/sysreset_sandbox.c  | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cmd_poweroff.c b/arch/arm/mach-
> stm32mp/cmd_poweroff.c
> index f54dd1daf2..62347425a0 100644
> --- a/arch/arm/mach-stm32mp/cmd_poweroff.c
> +++ b/arch/arm/mach-stm32mp/cmd_poweroff.c
> @@ -14,7 +14,7 @@ int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
>   puts("poweroff ...\n");
>   mdelay(100);
> 
> - ret = sysreset_walk(SYSRESET_POWER);
> + ret = sysreset_walk(SYSRESET_POWER_OFF);
> 
>   if (ret == -EINPROGRESS)
>   mdelay(1000);
> diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c index
> d3b9c05985..dee5fde4f7 100644
> --- a/arch/sandbox/cpu/state.c
> +++ b/arch/sandbox/cpu/state.c
> @@ -355,7 +355,7 @@ void state_reset_for_test(struct sandbox_state *state)  {
>   /* No reset yet, so mark it as such. Always allow power reset */
>   state->last_sysreset = SYSRESET_COUNT;
> - state->sysreset_allowed[SYSRESET_POWER] = true;
> + state->sysreset_allowed[SYSRESET_POWER_OFF] = true;
> 
>   memset(>wdt, '\0', sizeof(state->wdt));
>   memset(state->spi, '\0', sizeof(state->spi)); diff --git
> a/drivers/sysreset/sysreset_psci.c b/drivers/sysreset/sysreset_psci.c
> index de2ec8aeb1..c7907b3226 100644
> --- a/drivers/sysreset/sysreset_psci.c
> +++ b/drivers/sysreset/sysreset_psci.c
> @@ -18,7 +18,7 @@ static int psci_sysreset_request(struct udevice *dev, enum
> sysreset_t type)
>   case SYSRESET_COLD:
>   function_id = PSCI_0_2_FN_SYSTEM_RESET;
>   break;
> - case SYSRESET_POWER:
> + case SYSRESET_POWER_OFF:
>   function_id = PSCI_0_2_FN_SYSTEM_OFF;
>   break;
>   default:
> diff --git a/drivers/sysreset/sysreset_sandbox.c
> b/drivers/sysreset/sysreset_sandbox.c
> index 38e2a7e241..8bc9f4b4cc 100644
> --- a/drivers/sysreset/sysreset_sandbox.c
> +++ b/drivers/sysreset/sysreset_sandbox.c
> @@ -57,13 +57,13 @@ static int sandbox_sysreset_request(struct udevice *dev,
> enum sysreset_t type)
>   case SYSRESET_COLD:
>   state->last_sysreset = type;
>   break;
> - case SYSRESET_POWER:
> + case SYSRESET_POWER_OFF:
>   state->last_sysreset = type;
>   if (!state->sysreset_allowed[type])
>   return -EACCES;
>   sandbox_exit();
>   break;
> - case SYSRESET_POWER_OFF:
> + case SYSRESET_POWER:
>   if (!state->sysreset_allowed[type])
>   return -EACCES;
>   default:
> --
> 2.21.0

Regards 

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

[U-Boot] [PATCH v2 0/8] fdt: Allow indicating a node is for U-Boot proper only

2019-05-20 Thread Patrick Delaunay


Hi,

I create this v2 serie with:

1/ documentation update for previous patch
   [U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
   http://patchwork.ozlabs.org/patch/1081155/

   PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
   pre reloc properties in SPL and TPL device tree")
   but not the documentation.

2/ missing part for (patch 1/2)
   http://patchwork.ozlabs.org/project/uboot/list/?series=89846

3/ new tests for pre-reloc propertie in SPL as suggested by Simon
   (http://patchwork.ozlabs.org/patch/1081155/#2156621)

Tell me if is better to split the serie.

Regards
Patrick


Changes in v2:
- add sandbox_spl_dtb_defconfig for test
- solve issue for spl sandbox with dtb
- add new option for spl test: show embedded dtb
- add a new test option: device tree used for compilation
- move all spl test nodes in test dtb
- add some test for SPL with device tree
- rebase on master

Patrick Delaunay (8):
  sandbox: add config for SPL boot with devicetree
  fdt: Allow to use EMBEDDED device tree for SPL
  sandbox: add option show_of_embedded for spl test
  test: py: add option to select device tree used during compilation
  test: move SPL test nodes in test device tree
  test: check u-boot properties in SPL device tree
  fdt: Allow indicating a node is for U-Boot proper only
  dm: doc: add documentation for pre-reloc properties in SPL and TPL

 arch/sandbox/cpu/spl.c| 188 +++
 arch/sandbox/cpu/start.c  |   9 ++
 arch/sandbox/dts/sandbox.dts  |  36 ---
 arch/sandbox/dts/sandbox64.dts|  36 ---
 arch/sandbox/dts/test.dts |  54 +++
 arch/sandbox/include/asm/state.h  |   1 +
 board/sandbox/MAINTAINERS |   1 +
 configs/sandbox_spl_dtb_defconfig | 199 ++
 doc/README.SPL|  16 +++
 doc/README.TPL|   4 +
 doc/driver-model/README.txt   |   4 +
 drivers/core/util.c   |   2 +
 drivers/video/video-uclass.c  |   4 +-
 include/dm/ofnode.h   |   6 +-
 include/dm/util.h |   6 +-
 lib/fdtdec.c  |   6 ++
 test/py/conftest.py   |  12 ++-
 test/py/tests/test_ofplatdata.py  |  53 ++
 test/run  |   8 +-
 19 files changed, 566 insertions(+), 79 deletions(-)
 create mode 100644 configs/sandbox_spl_dtb_defconfig

-- 
2.7.4

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

[U-Boot] [PATCH v2 6/8] test: check u-boot properties in SPL device tree

2019-05-20 Thread Patrick Delaunay

Add a test to check the management of the u-boot relocation properties
(fdtgrep result) for platdata generation or device tree SPL generation:
- 'dm-pre-proper' and 'dm-tpl' not included in SPL
- 'dm-pre-reloc' and 'dm-spl' included in SPL

This patch also executes the version test (test_000_version) to check
the correct start of the U-Boot after SPL execution.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- add some test for SPL with device tree

 arch/sandbox/dts/test.dts| 18 ++
 test/py/tests/test_ofplatdata.py | 53 
 test/run |  5 
 3 files changed, 76 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 1ac86d7..2d5bea3 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -621,6 +621,24 @@
compatible = "sandbox,spl-test.2";
};
 
+   spl-test5 {
+   u-boot,dm-tpl;
+   compatible = "sandbox,spl-test";
+   stringarray = "tpl";
+   };
+
+   spl-test6 {
+   u-boot,dm-pre-proper;
+   compatible = "sandbox,spl-test";
+   stringarray = "pre-proper";
+   };
+
+   spl-test7 {
+   u-boot,dm-spl;
+   compatible = "sandbox,spl-test";
+   stringarray = "spl";
+   };
+
syscon0: syscon@0 {
compatible = "sandbox,syscon0";
reg = <0x10 16>;
diff --git a/test/py/tests/test_ofplatdata.py b/test/py/tests/test_ofplatdata.py
index 98103ee..bdabc5a 100644
--- a/test/py/tests/test_ofplatdata.py
+++ b/test/py/tests/test_ofplatdata.py
@@ -31,6 +31,50 @@ intarray 0 0 0 0
 longbytearray 00 00 00 00 00 00 00 00 00
 string 
 stringarray "one" "" ""
+of-platdata probe:
+bool 0
+byte 00
+bytearray 00 00 00
+int 0
+intarray 0 0 0 0
+longbytearray 00 00 00 00 00 00 00 00 00
+string 
+stringarray "spl" "" ""
+'''
+
+OF_EMBEDDED_OUTPUT = '''
+   spl-test {
+   compatible = "sandbox,spl-test";
+   boolval;
+   intval = <0x0001>;
+   intarray = <0x0002 0x0003 0x0004>;
+   byteval = [05];
+   bytearray = [06];
+   longbytearray = [09 0a 0b 0c 0d 0e 0f 10 11];
+   stringval = "message";
+   stringarray = "multi-word", "message";
+   };
+   spl-test2 {
+   compatible = "sandbox,spl-test";
+   intval = <0x0003>;
+   intarray = <0x0005>;
+   byteval = [08];
+   bytearray = [01 23 34];
+   longbytearray = <0x090a0b0c>;
+   stringval = "message2";
+   stringarray = "another", "multi-word", "message";
+   };
+   spl-test3 {
+   compatible = "sandbox,spl-test";
+   stringarray = "one";
+   };
+   spl-test4 {
+   compatible = "sandbox,spl-test.2";
+   };
+   spl-test7 {
+   compatible = "sandbox,spl-test";
+   stringarray = "spl";
+   };
 '''
 
 @pytest.mark.buildconfigspec('spl_of_platdata')
@@ -40,3 +84,12 @@ def test_ofplatdata(u_boot_console):
 cons.restart_uboot_with_flags(['--show_of_platdata'])
 output = cons.get_spawn_output().replace('\r', '')
 assert OF_PLATDATA_OUTPUT in output
+
+@pytest.mark.buildconfigspec('of_embed')
+@pytest.mark.buildconfigspec('spl_of_libfdt')
+def test_ofembed(u_boot_console):
+"""Test that device-tree can be generated and used in sandbox spl"""
+cons = u_boot_console
+cons.restart_uboot_with_flags(['--show_of_embedded'])
+output = cons.get_spawn_output().replace('\r', '')
+assert OF_EMBEDDED_OUTPUT in output
diff --git a/test/run b/test/run
index 5aceed7..4702c4d 100755
--- a/test/run
+++ b/test/run
@@ -26,6 +26,11 @@ run_test "sandbox_spl" ./test/py/test.py --bd sandbox_spl 
--build \
--device-tree test \
-k 'test_000_version or test_ofplatdata or test_handoff'
 
+# Run tests which require sandbox_spl_dtb , with test.dtb device tree
+run_test "sandbox_spl_dtb" ./test/py/test.py --bd sandbox_spl_dtb --build \
+   --device-tree test \
+   -k 'test_000_version or test_ofplatdata'
+
 # Run tests for the flat-device-tree version of sandbox. This is a special
 # build which does not enable CONFIG_OF_LIVE for the live device tree, so we 
can
 # check that functionality is the same. The standard sandbox build (above) uses
-- 
2.7.4

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

[U-Boot] [PATCH v2 5/8] test: move SPL test nodes in test device tree

2019-05-20 Thread Patrick Delaunay

Moves spl-test nodes in test device tree, selected by
the new build option '--device-tree'.

This patch also executes the version test (test_000_version) to check
the correct start of the U-Boot after SPL execution.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- move all spl test nodes in test dtb

 arch/sandbox/dts/sandbox.dts   | 36 
 arch/sandbox/dts/sandbox64.dts | 36 
 arch/sandbox/dts/test.dts  | 36 
 test/run   |  3 ++-
 4 files changed, 38 insertions(+), 73 deletions(-)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index a41b5f0..b5bc27b 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -225,42 +225,6 @@
};
};
 
-   spl-test {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   boolval;
-   intval = <1>;
-   intarray = <2 3 4>;
-   byteval = [05];
-   bytearray = [06];
-   longbytearray = [09 0a 0b 0c 0d 0e 0f 10 11];
-   stringval = "message";
-   stringarray = "multi-word", "message";
-   };
-
-   spl-test2 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   intval = <3>;
-   intarray = <5>;
-   byteval = [08];
-   bytearray = [01 23 34];
-   longbytearray = [09 0a 0b 0c];
-   stringval = "message2";
-   stringarray = "another", "multi-word", "message";
-   };
-
-   spl-test3 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   stringarray = "one";
-   };
-
-   spl-test4 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test.2";
-   };
-
square {
compatible = "demo-shape";
colour = "blue";
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index a3c95f2..766d020 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -190,42 +190,6 @@
};
};
 
-   spl-test {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   boolval;
-   intval = <1>;
-   intarray = <2 3 4>;
-   byteval = [05];
-   bytearray = [06];
-   longbytearray = [09 0a 0b 0c 0d 0e 0f 10 11];
-   stringval = "message";
-   stringarray = "multi-word", "message";
-   };
-
-   spl-test2 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   intval = <3>;
-   intarray = <5>;
-   byteval = [08];
-   bytearray = [01 23 34];
-   longbytearray = [09 0a 0b 0c];
-   stringval = "message2";
-   stringarray = "another", "multi-word", "message";
-   };
-
-   spl-test3 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test";
-   stringarray = "one";
-   };
-
-   spl-test4 {
-   u-boot,dm-pre-reloc;
-   compatible = "sandbox,spl-test.2";
-   };
-
square {
compatible = "demo-shape";
colour = "blue";
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d645..1ac86d7 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -585,6 +585,42 @@
};
};
 
+   spl-test {
+   u-boot,dm-pre-reloc;
+   compatible = "sandbox,spl-test";
+   boolval;
+   intval = <1>;
+   intarray = <2 3 4>;
+   byteval = [05];
+   bytearray = [06];
+   longbytearray = [09 0a 0b 0c 0d 0e 0f 10 11];
+   stringval = "message";
+   stringarray = "multi-word", "message";
+   };
+
+   spl-test2 {
+   u-boot,dm-pre-reloc;
+   compatible = "sandbox,spl-test";
+   intval = <3>;
+   intarray = <5>;
+   byteval = [08];
+   bytearray = [01 23 34];
+   longbytearray = [09 0a 0b 0c];
+   stringval = "message2";
+   stringarray = "another", "multi-word", "message";
+   };
+
+   spl-test3 {
+   u-boot,dm-pre-reloc;
+   compatible = "sandbox,spl-test";
+   stringarray = "one";
+   };
+
+   spl-test4 {
+   u-boot,dm-pre-reloc;
+   compatible = "sandbox,spl-test.2";
+   };
+
syscon0: syscon@0 {
compatible = "sandbox,syscon0";
reg = <0x10 16>;
diff --git a/test/run b/test/run
index 55a6649..5aceed7 100755

[U-Boot] [PATCH v2 8/8] dm: doc: add documentation for pre-reloc properties in SPL and TPL

2019-05-20 Thread Patrick Delaunay

Add documentation for the pre-reloc property in SPL and TPL device-tree:
- u-boot,dm-pre-proper
- u-boot,dm-pre-reloc
- u-boot,dm-spl
- u-boot,dm-tpl

Signed-off-by: Patrick Delaunay 
Reviewed-by: Simon Glass 
---

Changes in v2:
- rebase on master

 doc/README.SPL  | 16 
 doc/README.TPL  |  4 
 doc/driver-model/README.txt |  4 
 include/dm/ofnode.h |  6 --
 include/dm/util.h   |  6 --
 5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/doc/README.SPL b/doc/README.SPL
index 7a30fef..6eed83f 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -66,6 +66,22 @@ CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
 CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
 CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
 
+Device tree
+---
+The U-Boot device tree is filtered by the fdtgrep tools during the build
+process to generate a much smaller device tree used in SPL (spl/u-boot-spl.dtb)
+with:
+- the mandatory nodes (/alias, /chosen, /config)
+- the nodes with one pre-relocation property:
+  'u-boot,dm-pre-reloc' or 'u-boot,dm-spl'
+
+ftgrep is also used to remove:
+- the properties defined in CONFIG_OF_SPL_REMOVE_PROPS
+- all the pre-relocation properties
+  ('u-boot,dm-pre-reloc', 'u-boot,dm-spl' and 'u-boot,dm-tpl')
+
+All the nodes remaining in the SPL devicetree are bound
+(see driver-model/README.txt).
 
 Debugging
 -
diff --git a/doc/README.TPL b/doc/README.TPL
index 980debe..c94129f 100644
--- a/doc/README.TPL
+++ b/doc/README.TPL
@@ -34,6 +34,10 @@ determine which SPL options to choose based on whether 
CONFIG_TPL_BUILD
 is set. Source files can be compiled for TPL with options choosed in the
 board config file.
 
+TPL use a small device tree (u-boot-tpl.dtb), containing only the nodes with
+the pre-relocation properties: 'u-boot,dm-pre-reloc' and 'u-boot,dm-tpl'
+(see README.SPL for details).
+
 For example:
 
 spl/Makefile:
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 07b120d..532a771 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -849,6 +849,10 @@ in the device tree node. For U-Boot proper you can use 
'u-boot,dm-pre-proper'
 which means that it will be processed (and a driver bound) in U-Boot proper
 prior to relocation, but will not be available in SPL or TPL.
 
+To reduce the size of SPL and TPL, only the nodes with pre-relocation 
properties
+('u-boot,dm-pre-reloc', 'u-boot,dm-spl' or 'u-boot,dm-tpl') are keept in their
+device trees (see README.SPL for details); the remaining nodes are always 
bound.
+
 Then post relocation we throw that away and re-init driver model again.
 For drivers which require some sort of continuity between pre- and
 post-relocation devices, we can provide access to the pre-relocation
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index d206ee2..b45da5e 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -662,12 +662,14 @@ int ofnode_read_simple_size_cells(ofnode node);
  * After relocation and jumping into the real U-Boot binary it is possible to
  * determine if a node was bound in one of SPL/TPL stages.
  *
- * There are 3 settings currently in use
- * -
+ * There are 4 settings currently in use
+ * - u-boot,dm-pre-proper: U-Boot proper pre-relocation only
  * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
  *   Existing platforms only use it to indicate nodes needed in
  *   SPL. Should probably be replaced by u-boot,dm-spl for
  *   new platforms.
+ * - u-boot,dm-spl: SPL and U-Boot pre-relocation
+ * - u-boot,dm-tpl: TPL and U-Boot pre-relocation
  *
  * @node: node to check
  * @return true if node is needed in SPL/TL, false otherwise
diff --git a/include/dm/util.h b/include/dm/util.h
index 60d3b93..348c2ac 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -52,12 +52,14 @@ static inline void dm_dump_devres(void)
  * it is possible to determine if a node was bound in one of
  * SPL/TPL stages.
  *
- * There are 3 settings currently in use
- * -
+ * There are 4 settings currently in use
+ * - u-boot,dm-pre-proper: U-Boot proper pre-relocation only
  * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
  *   Existing platforms only use it to indicate nodes needed in
  *   SPL. Should probably be replaced by u-boot,dm-spl for
  *   existing platforms.
+ * - u-boot,dm-spl: SPL and U-Boot pre-relocation
+ * - u-boot,dm-tpl: TPL and U-Boot pre-relocation
  * @node: of node
  *
  * Returns true if node is needed in SPL/TL, false otherwise.
-- 
2.7.4

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

[U-Boot] [PATCH v2 4/8] test: py: add option to select device tree used during compilation

2019-05-20 Thread Patrick Delaunay

Only used for spl compilation which include the device tree
(with platdata or embedded device tree).
For U-boot, test use config.dtb, by default :
   "build_dir + '/arch/sandbox/dts/test.dtb'"

Signed-off-by: Patrick Delaunay 
---
I need to force o_dt = 'all' to avoid make error:

make: *** empty string invalid as file name.  Stop.

But, I don't sure that it is the better solution for pytest.


Changes in v2:
- add a new test option: device tree used for compilation

 test/py/conftest.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 00d8ef8..c1fe2a8 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -74,6 +74,8 @@ def pytest_addoption(parser):
 help='U-Boot board identity/instance')
 parser.addoption('--build', default=False, action='store_true',
 help='Compile U-Boot before running tests')
+parser.addoption('--device-tree', default=None,
+help='Device tree used to compile U-Boot')
 parser.addoption('--gdbserver', default=None,
 help='Run sandbox under gdbserver. The argument is the channel '+
 'over which gdbserver should communicate, e.g. localhost:1234')
@@ -101,6 +103,8 @@ def pytest_configure(config):
 board_identity = config.getoption('board_identity')
 board_identity_filename = board_identity.replace('-', '_')
 
+device_tree = config.getoption('device_tree')
+
 build_dir = config.getoption('build_dir')
 if not build_dir:
 build_dir = source_dir + '/build-' + board_type
@@ -128,9 +132,15 @@ def pytest_configure(config):
 o_opt = 'O=%s' % build_dir
 else:
 o_opt = ''
+
+if device_tree:
+o_dt = 'DEVICE_TREE=%s' % device_tree
+else:
+o_dt = 'all'
+
 cmds = (
 ['make', o_opt, '-s', board_type + '_defconfig'],
-['make', o_opt, '-s', '-j8'],
+['make', o_opt, o_dt, '-s', '-j8'],
 )
 with log.section('make'):
 runner = log.get_runner('make', sys.stdout)
-- 
2.7.4

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

[U-Boot] [PATCH v2 7/8] fdt: Allow indicating a node is for U-Boot proper only

2019-05-20 Thread Patrick Delaunay

This add missing parts for previous commit 06f94461a9f4
("fdt: Allow indicating a node is for U-Boot proper only")

At present it is not possible to specify that a node should be used before
relocation (in U-Boot proper) without it also ending up in SPL and TPL
device trees. Add a new "u-boot,dm-pre-proper" boolean property for this.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Simon Glass 
---

Changes in v2: None

 drivers/core/util.c  | 2 ++
 drivers/video/video-uclass.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/core/util.c b/drivers/core/util.c
index 96e47dc..60b939a 100644
--- a/drivers/core/util.c
+++ b/drivers/core/util.c
@@ -42,6 +42,8 @@ bool dm_ofnode_pre_reloc(ofnode node)
 #else
if (ofnode_read_bool(node, "u-boot,dm-pre-reloc"))
return true;
+   if (ofnode_read_bool(node, "u-boot,dm-pre-proper"))
+   return true;
 
/*
 * In regular builds individual spl and tpl handling both
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index b19bfb4..d4071c0 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -291,7 +291,9 @@ static int video_post_bind(struct udevice *dev)
return 0;
size = alloc_fb(dev, );
if (addr < gd->video_bottom) {
-   /* Device tree node may need the 'u-boot,dm-pre-reloc' tag */
+   /* Device tree node may need the 'u-boot,dm-pre-reloc' or
+* 'u-boot,dm-pre-proper' tag
+*/
printf("Video device '%s' cannot allocate frame buffer memory 
-ensure the device is set up before relocation\n",
   dev->name);
return -ENOSPC;
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/8] sandbox: add option show_of_embedded for spl test

2019-05-20 Thread Patrick Delaunay

Add an option show_of_embedded used in SPL to dump the used device tree.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- add new option for spl test: show embedded dtb

 arch/sandbox/cpu/spl.c   | 188 +++
 arch/sandbox/cpu/start.c |   9 ++
 arch/sandbox/include/asm/state.h |   1 +
 3 files changed, 198 insertions(+)

diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index 2ca4cd6..d3d9b08 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -46,6 +46,190 @@ static int spl_board_load_image(struct spl_image_info 
*spl_image,
 }
 SPL_LOAD_IMAGE_METHOD("sandbox", 0, BOOT_DEVICE_BOARD, spl_board_load_image);
 
+#ifdef CONFIG_OF_EMBED
+//
+/* the next functions mainly copyied from cmd fdt for SPL sandbox test */
+
+#include 
+
+#define CMD_FDT_MAX_DUMP 64
+#define MAX_LEVEL  32  /* how deeply nested we will go */
+
+/*
+ * Heuristic to guess if this is a string or concatenated strings.
+ */
+
+static int is_printable_string(const void *data, int len)
+{
+   const char *s = data;
+
+   /* zero length is not */
+   if (len == 0)
+   return 0;
+
+   /* must terminate with zero or '\n' */
+   if (s[len - 1] != '\0' && s[len - 1] != '\n')
+   return 0;
+
+   /* printable or a null byte (concatenated strings) */
+   while (((*s == '\0') || isprint(*s) || isspace(*s)) && (len > 0)) {
+   /*
+* If we see a null, there are three possibilities:
+* 1) If len == 1, it is the end of the string, printable
+* 2) Next character also a null, not printable.
+* 3) Next character not a null, continue to check.
+*/
+   if (s[0] == '\0') {
+   if (len == 1)
+   return 1;
+   if (s[1] == '\0')
+   return 0;
+   }
+   s++;
+   len--;
+   }
+
+   /* Not the null termination, or not done yet: not printable */
+   if (*s != '\0' || len != 0)
+   return 0;
+
+   return 1;
+}
+
+/*
+ * Print the property in the best format, a heuristic guess.  Print as
+ * a string, concatenated strings, a byte, word, double word, or (if all
+ * else fails) it is printed as a stream of bytes.
+ */
+static void print_data(const void *data, int len)
+{
+   int j;
+
+   /* no data, don't print */
+   if (len == 0)
+   return;
+
+   /*
+* It is a string, but it may have multiple strings (embedded '\0's).
+*/
+   if (is_printable_string(data, len)) {
+   puts("\"");
+   j = 0;
+   while (j < len) {
+   if (j > 0)
+   puts("\", \"");
+   puts(data);
+   j+= strlen(data) + 1;
+   data += strlen(data) + 1;
+   }
+   puts("\"");
+   return;
+   }
+
+   if ((len % 4) == 0) {
+   if (len > CMD_FDT_MAX_DUMP) {
+   printf("* 0x%p [0x%08x]", data, len);
+   } else {
+   const __be32 *p;
+
+   printf("<");
+   for (j = 0, p = data; j < len / 4; j++)
+   printf("0x%08x%s", fdt32_to_cpu(p[j]),
+  j < (len / 4 - 1) ? " " : "");
+   printf(">");
+   }
+   } else { /* anything else... hexdump */
+   if (len > CMD_FDT_MAX_DUMP) {
+   printf("* 0x%p [0x%08x]", data, len);
+   } else {
+   const u8 *s;
+
+   printf("[");
+   for (j = 0, s = data; j < len; j++)
+   printf("%02x%s", s[j], j < len - 1 ? " " : "");
+   printf("]");
+   }
+   }
+}
+
+/*
+ * Recursively print the working_fdt.
+ */
+static int fdt_print(const struct fdt_header *working_fdt)
+{
+   static char tabs[MAX_LEVEL + 1] =
+   "\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t"
+   "\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t";
+   const void *nodep;  /* property node pointer */
+   int  nodeoffset = 0;/* node offset from libfdt */
+   int  nextoffset;/* next node offset from libfdt */
+   u32  tag;   /* tag */
+   int  len;   /* length of the property */
+   int  level = 0; /* keep track of nesting level */
+   const struct fdt_property *fdt_prop;
+   const char *pathp;
+
+   /* print the node and all subnodes. */
+   while (level >= 0) {
+   tag = fdt_next_tag(working_fdt, nodeoffset, );
+   switch (tag) {
+

[U-Boot] [PATCH v2 2/8] fdt: Allow to use EMBEDDED device tree for SPL

2019-05-20 Thread Patrick Delaunay

U-boot continue to use load DT from file system, this patch avoid
an error when U-Boot "Error: Out of memory" when it try to map
gd->fdt_blob (EMBEDDED pointer __dtb_dt_begin is not managed).

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- solve issue for spl sandbox with dtb

 lib/fdtdec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fea44a9..d25cfd6 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1491,6 +1491,12 @@ int fdtdec_setup(void)
gd->fdt_blob = __dtb_dt_spl_begin;
 #  else
gd->fdt_blob = __dtb_dt_begin;
+#ifdef CONFIG_SANDBOX
+   if (sandbox_read_fdt_from_file()) {
+   puts("Failed to read control FDT\n");
+   return -1;
+   }
+#endif
 #  endif
 # elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/* Allow the board to override the fdt address. */
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/8] sandbox: add config for SPL boot with devicetree

2019-05-20 Thread Patrick Delaunay

Creates defconfig sandbox_spl_dtb_defconfig, same than
sandbox_spl_defconfig but without CONFIG_SPL_OF_PLATDATA;
to allow SPL compilation:
- OF_HOSTFILE is changed to OF_EMBED.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- add sandbox_spl_dtb_defconfig for test

 board/sandbox/MAINTAINERS |   1 +
 configs/sandbox_spl_dtb_defconfig | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 configs/sandbox_spl_dtb_defconfig

diff --git a/board/sandbox/MAINTAINERS b/board/sandbox/MAINTAINERS
index df29abe..1582a60 100644
--- a/board/sandbox/MAINTAINERS
+++ b/board/sandbox/MAINTAINERS
@@ -26,6 +26,7 @@ S:Maintained
 F: board/sandbox/
 F: include/configs/sandbox_spl.h
 F: configs/sandbox_spl_defconfig
+F: configs/sandbox_spl_dtb_defconfig
 
 SANDBOX FLAT TREE BOARD
 M: Simon Glass 
diff --git a/configs/sandbox_spl_dtb_defconfig 
b/configs/sandbox_spl_dtb_defconfig
new file mode 100644
index 000..895af0a
--- /dev/null
+++ b/configs/sandbox_spl_dtb_defconfig
@@ -0,0 +1,199 @@
+CONFIG_SYS_TEXT_BASE=0
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_SANDBOX_SPL=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_BOOTSTAGE=y
+CONFIG_BOOTSTAGE_REPORT=y
+CONFIG_BOOTSTAGE_FDT=y
+CONFIG_BOOTSTAGE_STASH=y
+CONFIG_BOOTSTAGE_STASH_ADDR=0x0
+CONFIG_BOOTSTAGE_STASH_SIZE=0x4096
+CONFIG_CONSOLE_RECORD=y
+CONFIG_CONSOLE_RECORD_OUT_SIZE=0x1000
+CONFIG_SILENT_CONSOLE=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_HANDOFF=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_CMD_CPU=y
+CONFIG_CMD_LICENSE=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_ELF is not set
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_ENV_CALLBACK=y
+CONFIG_CMD_ENV_FLAGS=y
+CONFIG_LOOPW=y
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MX_CYCLIC=y
+CONFIG_CMD_DEMO=y
+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
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_TFTPSRV=y
+CONFIG_CMD_RARP=y
+CONFIG_CMD_CDP=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SOUND=y
+CONFIG_CMD_QFW=y
+CONFIG_CMD_BOOTSTAGE=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_TPM=y
+CONFIG_CMD_TPM_TEST=y
+CONFIG_CMD_CBFS=y
+CONFIG_CMD_CRAMFS=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_MAC_PARTITION=y
+CONFIG_AMIGA_PARTITION=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_EMBED=y
+CONFIG_DEFAULT_DEVICE_TREE="sandbox"
+CONFIG_NETCONSOLE=y
+CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_DEVRES=y
+CONFIG_DEBUG_DEVRES=y
+# CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_ADC=y
+CONFIG_ADC_SANDBOX=y
+CONFIG_CLK=y
+CONFIG_CPU=y
+CONFIG_DM_DEMO=y
+CONFIG_DM_DEMO_SIMPLE=y
+CONFIG_DM_DEMO_SHAPE=y
+CONFIG_BOARD=y
+CONFIG_BOARD_SANDBOX=y
+CONFIG_PM8916_GPIO=y
+CONFIG_SANDBOX_GPIO=y
+CONFIG_DM_I2C_COMPAT=y
+CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I2C_CROS_EC_LDO=y
+CONFIG_DM_I2C_GPIO=y
+CONFIG_SYS_I2C_SANDBOX=y
+CONFIG_I2C_MUX=y
+CONFIG_SPL_I2C_MUX=y
+CONFIG_I2C_ARB_GPIO_CHALLENGE=y
+CONFIG_CROS_EC_KEYB=y
+CONFIG_I8042_KEYB=y
+CONFIG_LED=y
+CONFIG_LED_BLINK=y
+CONFIG_LED_GPIO=y
+CONFIG_DM_MAILBOX=y
+CONFIG_SANDBOX_MBOX=y
+CONFIG_MISC=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_I2C=y
+CONFIG_CROS_EC_LPC=y
+CONFIG_CROS_EC_SANDBOX=y
+CONFIG_CROS_EC_SPI=y
+CONFIG_PWRSEQ=y
+CONFIG_SPL_PWRSEQ=y
+CONFIG_MMC_SANDBOX=y
+CONFIG_SPI_FLASH_SANDBOX=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_DM_ETH=y
+CONFIG_NVME=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCI_SANDBOX=y
+CONFIG_PHY=y
+CONFIG_PHY_SANDBOX=y
+CONFIG_PINCTRL=y
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_SANDBOX=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_ACT8846=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_PMIC_MAX77686=y
+CONFIG_DM_PMIC_MC34708=y
+CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_PMIC_S2MPS11=y
+CONFIG_DM_PMIC_SANDBOX=y
+CONFIG_PMIC_S5M8767=y
+CONFIG_PMIC_TPS65090=y
+CONFIG_DM_REGULATOR=y
+CONFIG_REGULATOR_ACT8846=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_DM_REGULATOR_MAX77686=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_REGULATOR_S5M8767=y
+CONFIG_DM_REGULATOR_SANDBOX=y
+CONFIG_REGULATOR_TPS65090=y
+CONFIG_DM_PWM=y
+CONFIG_PWM_SANDBOX=y
+CONFIG_RAM=y
+CONFIG_REMOTEPROC_SANDBOX=y
+CONFIG_DM_RESET=y
+CONFIG_SANDBOX_RESET=y
+CONFIG_DM_RTC=y
+CONFIG_SANDBOX_SERIAL=y
+CONFIG_SOUND=y
+CONFIG_SOUND_SANDBOX=y
+CONFIG_SANDBOX_SPI=y
+CONFIG_SPMI=y

Re: [U-Boot] [PATCH 16/16] mpc83xx: Add gazerbeam board

2019-05-20 Thread Mario Six

On Fri, Mar 29, 2019 at 10:18 AM Mario Six  wrote:
>
> From: Dirk Eibach 
>
> The gdsys gazerbeam board is based on a Freescale MPC8308 SOC.
> It boots from NOR-Flash, kernel and rootfs are stored on
> SD-Card.
>
> On board peripherals include:
> - 2x 10/100 Mbit/s Ethernet (optional)
>
> Signed-off-by: Dirk Eibach 
> Signed-off-by: Mario Six 
> ---
>  arch/powerpc/cpu/mpc83xx/Kconfig |  19 +++
>  arch/powerpc/dts/gazerbeam.dts   |   2 +-
>  board/gdsys/common/Makefile  |   1 +
>  board/gdsys/mpc8308/Kconfig  |  29 -
>  board/gdsys/mpc8308/MAINTAINERS  |   2 +
>  board/gdsys/mpc8308/Makefile |   1 +
>  board/gdsys/mpc8308/gazerbeam.c  | 179 
>  configs/gazerbeam_defconfig  | 196 +++
>  include/configs/gazerbeam.h  | 137 +
>  9 files changed, 564 insertions(+), 2 deletions(-)
>  create mode 100644 board/gdsys/mpc8308/gazerbeam.c
>  create mode 100644 configs/gazerbeam_defconfig
>  create mode 100644 include/configs/gazerbeam.h
>
> diff --git a/arch/powerpc/cpu/mpc83xx/Kconfig 
> b/arch/powerpc/cpu/mpc83xx/Kconfig
> index fe20e85086b..b99288aa836 100644
> --- a/arch/powerpc/cpu/mpc83xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc83xx/Kconfig
> @@ -175,6 +175,25 @@ config TARGET_STRIDER
> select SYS_FSL_ERRATUM_ESDHC111
> imply CMD_PCA953X
>
> +config TARGET_GAZERBEAM
> +   bool "Support gazerbeam"
> +   select ARCH_MPC8308
> +   select SYS_FSL_ERRATUM_ESDHC111
> +   imply ENV_IS_IN_FLASH
> +   help
> + The "Gazerbeam" is a modular system by Guntermann & Drunck GmbH
> + Systementwicklung based on the NXP MPC8308 SoC for usage in KVM
> + appliances.
> +
> + Features include:
> + * Two gigabit ethernet ports
> + * Multiple USB ports (depending on variant)
> + * Several gigabit ethernet or optical fiber ports (depending on
> +   variant)
> + * Several display port inputs and outputs, and supporting redrivers
> +   (depending on variant)
> + * Several FPGAs with custom logic (depending on variant)
> +
>  endchoice
>
>  config MPC83XX_QUICC_ENGINE
> diff --git a/arch/powerpc/dts/gazerbeam.dts b/arch/powerpc/dts/gazerbeam.dts
> index 5d171519e01..96c03c77ae8 100644
> --- a/arch/powerpc/dts/gazerbeam.dts
> +++ b/arch/powerpc/dts/gazerbeam.dts
> @@ -10,7 +10,7 @@
>   * option) any later version.
>   */
>
> -/include/ "gdsys/mpc8308.dtsi"
> +#include "gdsys/mpc8308.dtsi"
>
>  /include/ "gdsys/gazerbeam-base.dtsi"
>
> diff --git a/board/gdsys/common/Makefile b/board/gdsys/common/Makefile
> index ff8d6f49665..7dfe104561a 100644
> --- a/board/gdsys/common/Makefile
> +++ b/board/gdsys/common/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_TARGET_STRIDER) += mclink.o dp501.o phy.o 
> ioep-fpga.o adv7611.o ch7
>  obj-$(CONFIG_TARGET_STRIDER) += fanctrl.o
>  obj-$(CONFIG_STRIDER_CON) += osd.o
>  obj-$(CONFIG_STRIDER_CON_DP) += osd.o
> +obj-$(CONFIG_TARGET_GAZERBEAM) += osd.o ihs_mdio.o ioep-fpga.o
>
>  ifdef CONFIG_OSD
>  obj-$(CONFIG_GDSYS_LEGACY_OSD_CMDS) += osd_cmd.o
> diff --git a/board/gdsys/mpc8308/Kconfig b/board/gdsys/mpc8308/Kconfig
> index e6a47960547..30811889fbf 100644
> --- a/board/gdsys/mpc8308/Kconfig
> +++ b/board/gdsys/mpc8308/Kconfig
> @@ -71,7 +71,28 @@ config GDSYS_LEGACY_DRIVERS
>
>  endif
>
> -if TARGET_HRCON || TARGET_STRIDER
> +if TARGET_GAZERBEAM
> +
> +config SYS_BOARD
> +   default "mpc8308"
> +
> +config SYS_VENDOR
> +   default "gdsys"
> +
> +config SYS_CONFIG_NAME
> +   default "gazerbeam"
> +
> +config SYS_FPGA1_BASE
> +   default E070
> +
> +config SYS_FPGA1_SIZE
> +   default 1
> +
> +config GDSYS_LEGACY_OSD_CMDS
> +   default y
> +endif
> +
> +if TARGET_HRCON || TARGET_STRIDER || TARGET_GAZERBEAM
>
>  choice
> prompt "FPGA flavor selection"
> @@ -89,6 +110,12 @@ config SYS_FPGA_FLAVOR_GAZERBEAM
>
>  endchoice
>
> +config EXTENDED_FEATURES
> +   bool "FPGA extended features"
> +   depends on GDSYS_LEGACY_DRIVERS
> +   help
> + Enable support for the extended features field of the IHS FPGA.
> +
>  config CMD_IOLOOP
> bool "Enable 'ioloop' and 'ioreflect' commands"
> help
> diff --git a/board/gdsys/mpc8308/MAINTAINERS b/board/gdsys/mpc8308/MAINTAINERS
> index 755b9a23858..ed1b6fa1062 100644
> --- a/board/gdsys/mpc8308/MAINTAINERS
> +++ b/board/gdsys/mpc8308/MAINTAINERS
> @@ -6,7 +6,9 @@ F:  include/configs/hrcon.h
>  F: configs/hrcon_defconfig
>  F: configs/hrcon_dh_defconfig
>  F: include/configs/strider.h
> +F: configs/strider_defconfig
>  F: configs/strider_cpu_defconfig
>  F: configs/strider_cpu_dp_defconfig
>  F: configs/strider_con_defconfig
>  F: configs/strider_con_dp_defconfig
> +F: configs/gazerbeam_defconfig
> diff --git a/board/gdsys/mpc8308/Makefile b/board/gdsys/mpc8308/Makefile
> index dc579479f95..9af5fe04d18 100644
> --- a/board/gdsys/mpc8308/Makefile
> +++

Re: [U-Boot] MMC boot broken on OMAP-L138 LCDK

2019-05-20 Thread Sekhar Nori

On 20/05/19 5:55 PM, Adam Ford wrote:
> What about adding a memset function to the end of spl_board_init() so
> after arch_cpu_init() is called,and after preloader_consol_init() is
> called, we clear BSS?  I ran some preliminary tests on da850evm and it
> didn't see to break anything.  There are a few boards that appear to
> do things in this order.

This will work, but, looks like there is a desire to maintain some
"standard" around this. Ie board_init_r() can assume BSS is available
(see README -> Board Initialisation Flow:).

Doing BSS init in in spl_board_init() called from board_init_r() will
violate that.

Thanks,
Sekhar

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

Re: [U-Boot] MMC boot broken on OMAP-L138 LCDK

2019-05-20 Thread Adam Ford

On Mon, May 20, 2019 at 4:09 AM Sekhar Nori  wrote:
>
> On 17/05/19 6:34 PM, Adam Ford wrote:
> > On Fri, May 17, 2019 at 7:36 AM Sekhar Nori  wrote:
> >>
> >> Hi Adam,
> >>
> >> MMC/SD boot is broken on OMAP-L138 LCDK. This is since v2018.11.
> >> v2018.09 is fine.
> >>
> >> The first breakage occurred with commit 21af33ed0319 ("ARM: davinci:
> >> omapl138_lcdk: Enable DM_MMC"). This commit moved to DM_MMC for U-Boot
> >> while keeping legacy mode for SPL.
> >
> > I am going to preface this by stating I don't have the LCDK.  Peter
> > Howard (added in CC) asked me to submit this on his behalf, so I
> > reviewed his patch and submitted it which is why both our names are on
> > the s-o-b.
> >
> >>
> >> The "#ifndef CONFIG_DM_MMC" introduced by this commit is incorrect I
> >> think because CONFIG_DM_MMC is defined in SPL build too and because of
> >> this board_mmc_init() never gets defined. I think the intent was to
> >> define board_mmc_init() for SPL case, and for that the following diff
> >> should do:
> >>
> >> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
> >> b/board/davinci/da8xxevm/omapl138_lcdk.c
> >> index 2c2f885d43e4..fe1bf4410145 100644
> >> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> >> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> >> @@ -353,7 +353,7 @@ int misc_init_r(void)
> >> return 0;
> >>  }
> >>
> >> -#ifndef CONFIG_DM_MMC
> >> +#if !CONFIG_IS_ENABLED(DM_MMC)
> >>  #ifdef CONFIG_MMC_DAVINCI
> >>  static struct davinci_mmc mmc_sd0 = {
> >> .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
> >>
> >
> > I would agree that the #ifndef should be replaced with if
> > !CONFIG_IS_ENABLED(DM_MMC), but I would recomend checking into
> > migrating the LCDK to DM. and DM_MMC.
>
> Okay. For now, I will submit a fix changing the #ifndef.
>
> >> With this fixed, MMC/SD boot is still broken after commit 15b8c7505819
> >> ("davinci: da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is
> >> full").
> >>
> >> After this commit, mmc_initialize() in drivers/mmc/mmc.c fails because
> >> the static variable 'initialized' does not get initialized to 0 as
> >> intended in code and gets set to a random value because of which no
> >> MMC/SD device gets registered. I did notice that 'initialized' is in
> >> BSS, so I believe after this commit BSS is not getting set to 0.
> >
> > I sent Peter H a list of patches to consider because I spent a lot of
> > time trying to modernize the da850_evm using DM, and DM_SPL and
> > eventually SPL_OF_CONTROL which ultimately eliminated a lot of the
> > manual initializing of the various drivers.
> >
> > See:
> > commit a4670f8ebb5b4df6afeb5155fb5b44c1d1d154b9 Enable DM and device
> > tree support for da850-evm
> > commit c4fa049a121457ff38b74daac32e18d7afbd4538 shrunk SPL by 6.5k
> > commit 391328dc30b78be6f0d1181088eda0fd7febd5f3 removed DM_I2C_COMPAT
> > commit cb19c29398cb84e72236ab6bae3763028fce5d44 board: da8xxevm: Add
> > SPL DM for serial, spi (with platdata)
> > commit 591353d011b5ff6dbc8511b7a839cddf5b610495 ARM: da850evm:
> > Increase Malloc Size
> > commit 15b8c7505819fa48dd99fb51e91b9536f341fde1 moved BSS to SDRAM
> > because SRAM is full
> > commit f7c1d53605d9ec528abacda9ba1763c67221fc88 ARM: davinci:
> > da850evm: Enable SPL_OF_CONTROL without PLATDATA
> > commit fd3c26f3f921ad7addf95857cdb99a883c6e497a ARM: da850evm: Fix
> > broken SPI Flash
> >
> > Having said that, the hardware I have for the da850 EVM doesn't
> > support MMC booting, so I cannot verify whether or not MMC initializes
> > properly in SPL.  I know the MMC initializes in U-Boot once it's
> > booted from SPI flash.
>
> MMC/SD boot can be simulated on any board by hacking spl_boot_device()
> in arch/arm/mach-davinci/spl.c

That's a good idea.  I never thought of that.  I'll have to add the
mmc entry to the device tree and enable MMC in SPL, but I'll try to
run some tests this week.  I'm out of town Friday-Tuesday, so if I'll
try to get to it by Wednesday.

>
> >
> > If someone wants to send me an LCDK, I'd be happy to look at
> > attempting to modernize the U-Boot for it.  Otherwise, we may want to
>
> I will try to get you a board.

thanks.

>
> > consider splitting the linker scripts between  LCDK and da850 evm so
> > da850evm can use SPL_OF_CONTROL with enough memory and LCDK can keep
> > it's legacy code status in SPL.
>
> I think this is not an LCDK specific problem. Looking at
> arch/arm/lib/crt0.S, BSS is cleared before board_init_r() is called.
>
> In case of DA850, DDR is initialized in
> board_init_r()->spl_board_init()->arch_cpu_init()->da850_ddr_setup()
>
> So, after you moved BSS to use SDRAM, the BSS clearing code was working
> on uninitialized DDR. I think the right fix may be to call
> arch_cpu_init() in board_init_f()?

What about adding a memset function to the end of spl_board_init() so
after arch_cpu_init() is called,and after preloader_consol_init() is
called, we clear BSS?  I ran some preliminary tests on da850evm and it
didn't see

Re: [U-Boot] [PATCH] drivers: core: use strcmp when find device by name

2019-05-20 Thread Simon Glass

Hi Peng,

On Wed, 15 May 2019 at 05:57, Peng Fan  wrote:
>
> Hi Simon,
>
> > Subject: Re: [PATCH] drivers: core: use strcmp when find device by name
> >
> > On Sun, 28 Apr 2019 at 03:43, Peng Fan  wrote:
> > >
> > > `if (!strncmp(dev->name, name, strlen(name)))` might find out the
> > > wrong device, it might find out `dram_pll_ref_sel`, when name is
> > > `dram_pll`. So use strcmp to avoid such issue.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  drivers/core/uclass.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > This seems to match the function description in the header file, too.
>
> Will you pick up this patch? Not see this patch in your tree.

I found that this causes a test failure - can you try 'make qcheck'
and see if you can figure out what is going on?

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

1 2 >

1 - 100 of 140 matches

Mail list logo