Re: [U-Boot] [PATCH 1/4] efi_loader: mark started images

[Takahiro Akashi]

On Tue, May 07, 2019 at 07:53:41AM +0200, Heinrich Schuchardt wrote:
> On 5/7/19 7:44 AM, Takahiro Akashi wrote:
> >On Tue, May 07, 2019 at 07:26:46AM +0200, Heinrich Schuchardt wrote:
> >>On 5/7/19 5:02 AM, Takahiro Akashi wrote:
> >>>On Sat, May 04, 2019 at 10:36:33AM +0200, Heinrich Schuchardt wrote:
> In UnloadImage() we need to know if an image is already started.
> 
> Add a field to the handle structure identifying loaded and started images.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>   include/efi_loader.h  | 13 +
>   lib/efi_loader/efi_boottime.c |  2 ++
>   2 files changed, 15 insertions(+)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3fd9901d66..c2a449e5b6 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -182,6 +182,18 @@ struct efi_handler {
>   struct list_head open_infos;
>   };
> 
> +/**
> + * enum efi_object_type - type of EFI object
> + *
> + * In UnloadImage we must be able to identify if the handle relates to a
> + * started image.
> + */
> +enum efi_object_type {
> + EFI_OBJECT_TYPE_UNDEFINED = 0,
> + EFI_OBJECT_TYPE_LOADED_IMAGE,
> + EFI_OBJECT_TYPE_STARTED_IMAGE,
> +};
> >>>
> >>>It sounds *status*, not *type*.
> >>>In a separate patch, you added U_BOOT_FIRMWARE.
> >>>We should distinguish status and type for future enhancement and
> >>>to avoid any confusion.
> >>
> >>Having both information in the same field makes the evaluation easier.
> >>
> >>Currently I see not necessity for more handle types to be
> >>differentiated. Let's change it when the need arises.
> >
> >I don't think we need U_BOOT_FIRMWARE if we use STARTED_IMAGE
> >for root node. Then we can rename efi_object_type to efi_image_status.
> 
> This would allow calling UnloadImage() for the root node.

Who knows the address of root node?
For safe guard, you can add
if (handle == root_node)
return EFI_INVALID_PARAMETER;
at the beginning of unload_image.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> >-Takahiro Akashi
> >
> >
> >>Best regards
> >>
> >>Heinrich
> >>
> >>>
> >>>Thanks,
> >>>-Takahiro Akashi
> >>>
> >>>
>   /**
>    * struct efi_object - dereferenced EFI handle
>    *
> @@ -204,6 +216,7 @@ struct efi_object {
>   struct list_head link;
>   /* The list of protocols */
>   struct list_head protocols;
> + enum efi_object_type type;
>   };
> 
>   /**
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 3ed08e7c37..dc444fccf6 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1554,6 +1554,7 @@ efi_status_t efi_setup_loaded_image(struct 
> efi_device_path *device_path,
>   free(info);
>   return EFI_OUT_OF_RESOURCES;
>   }
> + obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;
> 
>   /* Add internal object to object list */
>   efi_add_handle(>header);
> @@ -2678,6 +2679,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
> image_handle,
>   }
> 
>   current_image = image_handle;
> + image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
>   EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
>   ret = EFI_CALL(image_obj->entry(image_handle, ));
> 
> --
> 2.20.1
> 
> >>>
> >>
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] efi_loader: mark started images

[Heinrich Schuchardt]

On 5/7/19 7:44 AM, Takahiro Akashi wrote:

On Tue, May 07, 2019 at 07:26:46AM +0200, Heinrich Schuchardt wrote:

On 5/7/19 5:02 AM, Takahiro Akashi wrote:

On Sat, May 04, 2019 at 10:36:33AM +0200, Heinrich Schuchardt wrote:

In UnloadImage() we need to know if an image is already started.

Add a field to the handle structure identifying loaded and started images.

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h  | 13 +
  lib/efi_loader/efi_boottime.c |  2 ++
  2 files changed, 15 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3fd9901d66..c2a449e5b6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -182,6 +182,18 @@ struct efi_handler {
struct list_head open_infos;
  };

+/**
+ * enum efi_object_type - type of EFI object
+ *
+ * In UnloadImage we must be able to identify if the handle relates to a
+ * started image.
+ */
+enum efi_object_type {
+   EFI_OBJECT_TYPE_UNDEFINED = 0,
+   EFI_OBJECT_TYPE_LOADED_IMAGE,
+   EFI_OBJECT_TYPE_STARTED_IMAGE,
+};


It sounds *status*, not *type*.
In a separate patch, you added U_BOOT_FIRMWARE.
We should distinguish status and type for future enhancement and
to avoid any confusion.


Having both information in the same field makes the evaluation easier.

Currently I see not necessity for more handle types to be
differentiated. Let's change it when the need arises.


I don't think we need U_BOOT_FIRMWARE if we use STARTED_IMAGE
for root node. Then we can rename efi_object_type to efi_image_status.


This would allow calling UnloadImage() for the root node.

Best regards

Heinrich



-Takahiro Akashi



Best regards

Heinrich



Thanks,
-Takahiro Akashi



  /**
   * struct efi_object - dereferenced EFI handle
   *
@@ -204,6 +216,7 @@ struct efi_object {
struct list_head link;
/* The list of protocols */
struct list_head protocols;
+   enum efi_object_type type;
  };

  /**
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 3ed08e7c37..dc444fccf6 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1554,6 +1554,7 @@ efi_status_t efi_setup_loaded_image(struct 
efi_device_path *device_path,
free(info);
return EFI_OUT_OF_RESOURCES;
}
+   obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;

/* Add internal object to object list */
efi_add_handle(>header);
@@ -2678,6 +2679,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
}

current_image = image_handle;
+   image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
ret = EFI_CALL(image_obj->entry(image_handle, ));

--
2.20.1









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

Re: [U-Boot] [PATCH 4/4] efi_loader: unload applications upon Exit()

[Heinrich Schuchardt]

On 5/7/19 6:39 AM, Takahiro Akashi wrote:

On Sat, May 04, 2019 at 10:36:36AM +0200, Heinrich Schuchardt wrote:

Implement unloading of images in the Exit() boot services:

* unload images that are not yet started,
* unload started applications,
* unload drivers returning an error.

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h  |  1 +
  lib/efi_loader/efi_boottime.c | 34 ++-
  lib/efi_loader/efi_image_loader.c |  2 ++
  3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index c2a449e5b6..d73c89ac26 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -237,6 +237,7 @@ struct efi_loaded_image_obj {
struct jmp_buf_data exit_jmp;
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
 struct efi_system_table *st);
+   u16 image_type;
  };

  /**
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index bbcd66caa6..51e0bb2fd5 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  DECLARE_GLOBAL_DATA_PTR;
@@ -2798,7 +2799,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
image_handle,
 *   image protocol.
 */
efi_status_t ret;
-   void *info;
+   struct efi_loaded_image *loaded_image_protocol;
struct efi_loaded_image_obj *image_obj =
(struct efi_loaded_image_obj *)image_handle;

@@ -2806,13 +2807,33 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
image_handle,
  exit_data_size, exit_data);

/* Check parameters */
-   if (image_handle != current_image)
+   if (image_handle != current_image) {


Does this check make sense even for a driver?


The check is prescribed in the UEFI specification. See the heading
"Status Codes Returned".

Multiple binaries may be in status started. If a child image (which may
be a driver) calls Exit() with the parent image handle this might cause
fancy problems.

The lifetime of a driver is LoadImage(), StartImage(), Exit(),
UnloadImage(). Typically between StartImage() and Exit() it will install
its protocols and between Exit() and UnloadImage() wait for other
binaries to call the protocols.




+   ret = EFI_INVALID_PARAMETER;
goto out;
+   }
ret = EFI_CALL(efi_open_protocol(image_handle, _guid_loaded_image,
-, NULL, NULL,
+(void **)_image_protocol,
+NULL, NULL,
 EFI_OPEN_PROTOCOL_GET_PROTOCOL));
-   if (ret != EFI_SUCCESS)
+   if (ret != EFI_SUCCESS) {


Is this check necessary even when 'header.type' is introduced?


I am passing the loaded image protocol to efi_delete_handle(). In
principal a binary might have uninstalled its own loaded image protocol
so this call may fail.




+   ret = EFI_INVALID_PARAMETER;
goto out;
+   }
+
+   /* Unloading of unstarted images */


'Unload' sounds odd when we call efi_delete_image(), doesn't it?


+   switch (image_obj->header.type) {
+   case EFI_OBJECT_TYPE_STARTED_IMAGE:
+   break;
+   case EFI_OBJECT_TYPE_LOADED_IMAGE:
+   efi_delete_image(image_obj, loaded_image_protocol);
+   ret = EFI_SUCCESS;
+   goto out;
+   default:
+   /* Handle does not refer to loaded image */
+   ret = EFI_INVALID_PARAMETER;
+   goto out;
+   }
+   image_obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;

/* Exit data is only foreseen in case of failure. */
if (exit_status != EFI_SUCCESS) {
@@ -2822,6 +2843,9 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
image_handle,
if (ret != EFI_SUCCESS)
EFI_PRINT("%s: out of memory\n", __func__);
}
+   if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION ||
+   exit_status != EFI_SUCCESS)
+   efi_delete_image(image_obj, loaded_image_protocol);


Why not merge those two efi_delete_image()?


I went for readable code. The if statement catching all cases was
unreadable to me.

Best regards

Heinrich



-Takahiro Akashi



/* Make sure entry/exit counts for EFI world cross-overs match */
EFI_EXIT(exit_status);
@@ -2837,7 +2861,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
image_handle,

panic("EFI application exited");
  out:
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_EXIT(ret);
  }

  /**
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index f8092b6202..13541cfa7a 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -273,6 +273,7 @@ efi_status_t 

Re: [U-Boot] [PATCH 1/4] efi_loader: mark started images

[Takahiro Akashi]

On Tue, May 07, 2019 at 07:26:46AM +0200, Heinrich Schuchardt wrote:
> On 5/7/19 5:02 AM, Takahiro Akashi wrote:
> >On Sat, May 04, 2019 at 10:36:33AM +0200, Heinrich Schuchardt wrote:
> >>In UnloadImage() we need to know if an image is already started.
> >>
> >>Add a field to the handle structure identifying loaded and started images.
> >>
> >>Signed-off-by: Heinrich Schuchardt 
> >>---
> >>  include/efi_loader.h  | 13 +
> >>  lib/efi_loader/efi_boottime.c |  2 ++
> >>  2 files changed, 15 insertions(+)
> >>
> >>diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>index 3fd9901d66..c2a449e5b6 100644
> >>--- a/include/efi_loader.h
> >>+++ b/include/efi_loader.h
> >>@@ -182,6 +182,18 @@ struct efi_handler {
> >>struct list_head open_infos;
> >>  };
> >>
> >>+/**
> >>+ * enum efi_object_type - type of EFI object
> >>+ *
> >>+ * In UnloadImage we must be able to identify if the handle relates to a
> >>+ * started image.
> >>+ */
> >>+enum efi_object_type {
> >>+   EFI_OBJECT_TYPE_UNDEFINED = 0,
> >>+   EFI_OBJECT_TYPE_LOADED_IMAGE,
> >>+   EFI_OBJECT_TYPE_STARTED_IMAGE,
> >>+};
> >
> >It sounds *status*, not *type*.
> >In a separate patch, you added U_BOOT_FIRMWARE.
> >We should distinguish status and type for future enhancement and
> >to avoid any confusion.
> 
> Having both information in the same field makes the evaluation easier.
> 
> Currently I see not necessity for more handle types to be
> differentiated. Let's change it when the need arises.

I don't think we need U_BOOT_FIRMWARE if we use STARTED_IMAGE
for root node. Then we can rename efi_object_type to efi_image_status.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> >Thanks,
> >-Takahiro Akashi
> >
> >
> >>  /**
> >>   * struct efi_object - dereferenced EFI handle
> >>   *
> >>@@ -204,6 +216,7 @@ struct efi_object {
> >>struct list_head link;
> >>/* The list of protocols */
> >>struct list_head protocols;
> >>+   enum efi_object_type type;
> >>  };
> >>
> >>  /**
> >>diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> >>index 3ed08e7c37..dc444fccf6 100644
> >>--- a/lib/efi_loader/efi_boottime.c
> >>+++ b/lib/efi_loader/efi_boottime.c
> >>@@ -1554,6 +1554,7 @@ efi_status_t efi_setup_loaded_image(struct 
> >>efi_device_path *device_path,
> >>free(info);
> >>return EFI_OUT_OF_RESOURCES;
> >>}
> >>+   obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;
> >>
> >>/* Add internal object to object list */
> >>efi_add_handle(>header);
> >>@@ -2678,6 +2679,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
> >>image_handle,
> >>}
> >>
> >>current_image = image_handle;
> >>+   image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
> >>EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
> >>ret = EFI_CALL(image_obj->entry(image_handle, ));
> >>
> >>--
> >>2.20.1
> >>
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1 v3] arm: mvebu: Add CRS305-1G-4S board

[Stefan Roese]

On 06.05.19 18:35, Luka Kovacic wrote:

CRS305-1G-4S has a switch chip with an integrated CPU (98DX3236) and
like some of the other similar boards requires bin_hdr.
bin_hdr (DDR3 init stage) is currently retrieved from the stock
bootloader and compiled into the kwb image.

Adds support for U-Boot, enable UART, SPI, Winbond SPI flash chip
support and writing env to SPI flash.

Signed-off-by: Luka Kovacic 
---
v1:
- arch/arm/dts: Remove unused parameters in DTS for crs305-1g-4s
- arch/arm/mach-mvebu: Set the proper processor for crs305-1g-4s
  (98DX3236)

Changes for v2:
- board/mikrotik/crs305-1g-4s: Enable CONFIG_DISPLAY_BOARDINFO

Changes for v3:
- board/mikrotik/crs305-1g-4s: Remove GPIO1 (Reset Button)


Thanks, nearly ready to go in. checkpatch reports a few minor issues
though:

WARNING: line over 80 characters
#341: FILE: board/mikrotik/crs305-1g-4s/crs305-1g-4s.c:20:
+#define DB_DX_AC3_GPP_OUT_ENA_LOW  (~(BIT(0) | BIT(2) | BIT(3) | BIT(4) | 
BIT(6) | BIT(12) \

WARNING: line over 80 characters
#342: FILE: board/mikrotik/crs305-1g-4s/crs305-1g-4s.c:21:
+   | BIT(13) | BIT(16) | BIT(17) | BIT(20) 
| BIT(29)  | BIT(30)))

WARNING: line over 80 characters
#344: FILE: board/mikrotik/crs305-1g-4s/crs305-1g-4s.c:23:
+#define DB_DX_AC3_GPP_OUT_VAL_LOW  (BIT(0) | BIT(2) | BIT(3) | BIT(4) | 
BIT(6) | BIT(12) \

WARNING: line over 80 characters
#345: FILE: board/mikrotik/crs305-1g-4s/crs305-1g-4s.c:24:
+   | BIT(13) | BIT(16) | BIT(17) | BIT(20) 
| BIT(29)  | BIT(30))

WARNING: Block comments should align the * on each line
#360: FILE: board/mikrotik/crs305-1g-4s/crs305-1g-4s.c:39:
+   /*
+   * MVEBU_GPIO0_BASE is the User LED

Please fix these issues in the next version.

Thanks,
Stefan

  
  arch/arm/dts/Makefile |   3 +-

  .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi|  13 +++
  arch/arm/dts/armada-xp-crs305-1g-4s.dts   | 110 ++
  arch/arm/mach-mvebu/Kconfig   |   7 ++
  board/mikrotik/crs305-1g-4s/.gitignore|   1 +
  board/mikrotik/crs305-1g-4s/MAINTAINERS   |   7 ++
  board/mikrotik/crs305-1g-4s/Makefile  |  14 +++
  board/mikrotik/crs305-1g-4s/README|  23 
  board/mikrotik/crs305-1g-4s/binary.0  |  11 ++
  board/mikrotik/crs305-1g-4s/crs305-1g-4s.c|  71 +++
  board/mikrotik/crs305-1g-4s/kwbimage.cfg.in   |  12 ++
  configs/crs305-1g-4s_defconfig|  52 +
  include/configs/crs305-1g-4s.h|  37 ++
  13 files changed, 360 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
  create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts
  create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore
  create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS
  create mode 100644 board/mikrotik/crs305-1g-4s/Makefile
  create mode 100644 board/mikrotik/crs305-1g-4s/README
  create mode 100644 board/mikrotik/crs305-1g-4s/binary.0
  create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c
  create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in
  create mode 100644 configs/crs305-1g-4s_defconfig
  create mode 100644 include/configs/crs305-1g-4s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8e082f2840..8d73bcb57f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -162,7 +162,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb   \
-   armada-xp-db-xc3-24g4xg.dtb
+   armada-xp-db-xc3-24g4xg.dtb \
+   armada-xp-crs305-1g-4s.dtb
  
  dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \

uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi 
b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
new file mode 100644
index 00..8576a02730
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s.dts 
b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
new file mode 100644
index 00..1116f5c96c
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS305-1G-4S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf100 (instead of the default
+ * 0xd000). The 0xf100 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some 

Re: [U-Boot] [PATCH 1/4] efi_loader: mark started images

[Heinrich Schuchardt]

On 5/7/19 5:02 AM, Takahiro Akashi wrote:

On Sat, May 04, 2019 at 10:36:33AM +0200, Heinrich Schuchardt wrote:

In UnloadImage() we need to know if an image is already started.

Add a field to the handle structure identifying loaded and started images.

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h  | 13 +
  lib/efi_loader/efi_boottime.c |  2 ++
  2 files changed, 15 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3fd9901d66..c2a449e5b6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -182,6 +182,18 @@ struct efi_handler {
struct list_head open_infos;
  };

+/**
+ * enum efi_object_type - type of EFI object
+ *
+ * In UnloadImage we must be able to identify if the handle relates to a
+ * started image.
+ */
+enum efi_object_type {
+   EFI_OBJECT_TYPE_UNDEFINED = 0,
+   EFI_OBJECT_TYPE_LOADED_IMAGE,
+   EFI_OBJECT_TYPE_STARTED_IMAGE,
+};


It sounds *status*, not *type*.
In a separate patch, you added U_BOOT_FIRMWARE.
We should distinguish status and type for future enhancement and
to avoid any confusion.


Having both information in the same field makes the evaluation easier.

Currently I see not necessity for more handle types to be
differentiated. Let's change it when the need arises.

Best regards

Heinrich



Thanks,
-Takahiro Akashi



  /**
   * struct efi_object - dereferenced EFI handle
   *
@@ -204,6 +216,7 @@ struct efi_object {
struct list_head link;
/* The list of protocols */
struct list_head protocols;
+   enum efi_object_type type;
  };

  /**
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 3ed08e7c37..dc444fccf6 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1554,6 +1554,7 @@ efi_status_t efi_setup_loaded_image(struct 
efi_device_path *device_path,
free(info);
return EFI_OUT_OF_RESOURCES;
}
+   obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;

/* Add internal object to object list */
efi_add_handle(>header);
@@ -2678,6 +2679,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
}

current_image = image_handle;
+   image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
ret = EFI_CALL(image_obj->entry(image_handle, ));

--
2.20.1





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

[U-Boot] [PATCH v1 3/3] ARM: socfpga: stratix10: Enable PSCI support for Stratix 10

[chee . hong . ang]

From: "Ang, Chee Hong" 

The address of PSCI text, data and stack sections start at
0x1000 (SDRAM).

Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/Kconfig | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 8f7b79f..6fb508e 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -12,6 +12,12 @@ config SPL_SYS_MALLOC_F_LEN
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
default 0xa2
 
+config ARMV8_SECURE_BASE
+   default 0x1000 if TARGET_SOCFPGA_STRATIX10
+
+config SYS_HAS_ARMV8_SECURE_BASE
+   default y if TARGET_SOCFPGA_STRATIX10
+
 config SYS_MALLOC_F_LEN
default 0x2000 if TARGET_SOCFPGA_ARRIA10
default 0x2000 if TARGET_SOCFPGA_GEN5
@@ -56,8 +62,9 @@ config TARGET_SOCFPGA_GEN5
 config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
+   select ARMV8_PSCI
+   select ARMV8_SEC_FIRMWARE_SUPPORT
select ARMV8_SET_SMPEN
-   select ARMV8_SPIN_TABLE
select FPGA_STRATIX10
 
 choice
-- 
2.7.4

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

[U-Boot] [PATCH v1 2/3] ARM: socfpga: stratix10: Enable PSCI CPU_ON

[chee . hong . ang]

From: "Ang, Chee Hong" 

Enable psci_cpu_on support for Stratix10. This PSCI function
will pass the cpu release address for CPU1-CPU3. Then send event
signal shall be triggered to get these CPUs running Linux code.

Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/psci.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mach-socfpga/psci.c b/arch/arm/mach-socfpga/psci.c
index 9ef3931..0af3eb1 100644
--- a/arch/arm/mach-socfpga/psci.c
+++ b/arch/arm/mach-socfpga/psci.c
@@ -11,6 +11,9 @@
 #include 
 #include 
 
+static u64 psci_cpu_on_64_cpuid __secure_data;
+static u64 psci_cpu_on_64_entry_point __secure_data;
+
 void __noreturn __secure psci_system_reset(void)
 {
mbox_send_cmd_psci(MBOX_ID_UBOOT, MBOX_REBOOT_HPS,
@@ -19,3 +22,35 @@ void __noreturn __secure psci_system_reset(void)
while (1)
;
 }
+
+/* This function will handle multiple core release based PSCI */
+void __secure psci_cpu_on_64_mpidr(void)
+{
+   asm volatile(
+   ".align 5   \n"
+   "1: wfe \n"
+   "   ldr x0, [%0]\n"
+   "   ldr x1, [%1]\n"
+   "   mrs x2, mpidr_el1   \n"
+   "   and x2, x2, #0xff   \n"
+   "   cmp x0, x2  \n"
+   "   b.ne1b  \n"
+   "   br  x1  \n"
+   : : "r"(_cpu_on_64_cpuid), "r"(_cpu_on_64_entry_point)
+   : "x0", "x1", "x2", "memory", "cc");
+}
+
+int __secure psci_cpu_on_64(u32 function_id, u64 cpuid, u64 entry_point)
+{
+   /* Releases all secondary CPUs to jump into psci_cpu_on_64_mpidr */
+   writeq(0, _cpu_on_64_cpuid);
+   writeq(0, _cpu_on_64_entry_point);
+   writeq((u64)_cpu_on_64_mpidr, CPU_RELEASE_ADDR);
+
+   /* to store in global so psci_cpu_on_64_mpidr function can refer */
+   writeq(entry_point, _cpu_on_64_entry_point);
+   writeq(cpuid, _cpu_on_64_cpuid);
+   asm volatile("sev");
+
+   return ARM_PSCI_RET_SUCCESS;
+}
-- 
2.7.4

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

[U-Boot] [PATCH v1 1/3] ARM: socfpga: stratix10: Enable PSCI system reset

[chee . hong . ang]

From: "Ang, Chee Hong" 

Enable psci_system_reset support for Stratix10. This PSCI function
will eventually trigger the mailbox HPS_REBOOT to SDM.

Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/Makefile |  3 +++
 arch/arm/mach-socfpga/psci.c   | 21 +
 2 files changed, 24 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/psci.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e667204..f77b229 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -38,6 +38,9 @@ obj-y += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
 obj-y  += wrap_pll_config_s10.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_ARMV8_PSCI)   += psci.o
+endif
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/mach-socfpga/psci.c b/arch/arm/mach-socfpga/psci.c
new file mode 100644
index 000..9ef3931
--- /dev/null
+++ b/arch/arm/mach-socfpga/psci.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2017 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void __noreturn __secure psci_system_reset(void)
+{
+   mbox_send_cmd_psci(MBOX_ID_UBOOT, MBOX_REBOOT_HPS,
+  MBOX_CMD_DIRECT, 0, NULL, 0, 0, NULL);
+
+   while (1)
+   ;
+}
-- 
2.7.4

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

[U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux

[chee . hong . ang]

From: "Ang, Chee Hong" 

Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support
for booting Linux on Stratix 10 platform.

Ang, Chee Hong (3):
  ARM: socfpga: stratix10: Enable PSCI system reset
  ARM: socfpga: stratix10: Enable PSCI CPU_ON
  ARM: socfpga: stratix10: Enable PSCI support for Stratix 10

 arch/arm/mach-socfpga/Kconfig  |  9 ++-
 arch/arm/mach-socfpga/Makefile |  3 +++
 arch/arm/mach-socfpga/psci.c   | 56 ++
 3 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-socfpga/psci.c

-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 1/1] efi_loader: optional data in load options are binary

[Heinrich Schuchardt]

On 5/7/19 3:53 AM, Takahiro Akashi wrote:

On Tue, Apr 30, 2019 at 08:11:15AM +0200, Heinrich Schuchardt wrote:

The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.

When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the Boot variable.


While optional_data holds u8 string in calling efi_serialize_load_option(),
it holds u16 string in leaving from efi_deserialize_load_option().
We should handle it in a consistent way if you want to keep optional_data
as "const u8."


The patch is already merged so I will have to create a follow up patch.

The UEFI spec has EFI_LOAD_OPTION.OptionalData as UINT8. So an odd
number of bytes is a possibility.

Best regards

Heinrich



Thanks,
-Takahiro Akashi


When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.

Here is an example session protocol:

=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
   attributes: A-- (0x0001)
   label: label1
   file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
   data:
 : 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00  m.y. .o.p.t.i.o.
 0010: 6e 00 00 00  n...
Boot00A1:
   attributes: A-- (0x0001)
   label: label2
   file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
   data:

Signed-off-by: Heinrich Schuchardt 
---
v2:
remove statement without effect in efi_serialize_load_option()
---
  cmd/efidebug.c   | 27 +--
  include/efi_loader.h |  2 +-
  lib/efi_loader/efi_bootmgr.c | 15 ---
  3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index efe4ea873e..c4ac9dd634 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -545,7 +546,10 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
+ sizeof(struct efi_device_path); /* for END */

/* optional data */
-   lo.optional_data = (u8 *)(argc == 6 ? "" : argv[6]);
+   if (argc < 6)
+   lo.optional_data = NULL;
+   else
+   lo.optional_data = (const u8 *)argv[6];

size = efi_serialize_load_option(, (u8 **));
if (!size) {
@@ -615,12 +619,13 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
  /**
   * show_efi_boot_opt_data() - dump UEFI load option
   *
- * @id:Load option number
- * @data:  Value of UEFI load option variable
+ * @id:load option number
+ * @data:  value of UEFI load option variable
+ * @size:  size of the boot option
   *
   * Decode the value of UEFI load option variable and print information.
   */
-static void show_efi_boot_opt_data(int id, void *data)
+static void show_efi_boot_opt_data(int id, void *data, size_t size)
  {
struct efi_load_option lo;
char *label, *p;
@@ -638,7 +643,7 @@ static void show_efi_boot_opt_data(int id, void *data)
utf16_utf8_strncpy(, lo.label, label_len16);

printf("Boot%04X:\n", id);
-   printf("\tattributes: %c%c%c (0x%08x)\n",
+   printf("  attributes: %c%c%c (0x%08x)\n",
   /* ACTIVE */
   lo.attributes & LOAD_OPTION_ACTIVE ? 'A' : '-',
   /* FORCE RECONNECT */
@@ -646,14 +651,16 @@ static void show_efi_boot_opt_data(int id, void *data)
   /* HIDDEN */
   lo.attributes & LOAD_OPTION_HIDDEN ? 'H' : '-',
   lo.attributes);
-   printf("\tlabel: %s\n", label);
+   printf("  label: %s\n", label);

dp_str = efi_dp_str(lo.file_path);
-   printf("\tfile_path: %ls\n", dp_str);
+   printf("  file_path: %ls\n", dp_str);
efi_free_pool(dp_str);

-   printf("\tdata: %s\n", lo.optional_data);
-
+   printf("  data:\n");
+   print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
+  lo.optional_data, size + (u8 *)data -
+  (u8 *)lo.optional_data, true);
free(label);
  }

@@ -686,7 +693,7 @@ static void show_efi_boot_opt(int id)
data));
}
if (ret == EFI_SUCCESS)
-   show_efi_boot_opt_data(id, data);
+   show_efi_boot_opt_data(id, data, size);
else if (ret == EFI_NOT_FOUND)
printf("Boot%04X: not found\n", id);

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 39ed8a6fa5..07b913d256 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -560,7 +560,7 @@ struct efi_load_option {
u16 file_path_length;
u16 *label;
struct efi_device_path *file_path;
-   u8 *optional_data;
+   const u8 *optional_data;
 

[U-Boot] [PATCH v1 3/3] ARM: socfpga: stratix10: To notify SDM when U-Boot pass control to Linux

[chee . hong . ang]

From: "Ang, Chee Hong" 

Prior U-Boot pass control to Linux, U-Boot will send a mailbox command
"HPS_STAGE_NOTIFY" to notify Secure Device Manager (SDM) on HPS SW
transition.

Signed-off-by: Chin Liang See 
Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/misc_s10.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 0e4133f..5ae6ed2 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -166,3 +166,8 @@ void do_bridge_reset(int enable)
 
socfpga_bridges_reset(enable);
 }
+
+void arch_preboot_os(void)
+{
+   mbox_hps_stage_notify(HPS_EXECUTION_STATE_OS);
+}
-- 
2.7.4

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

[U-Boot] [PATCH v1 1/3] ARM: socfpga: stratix10: Add HPS execution stage notification function

[chee . hong . ang]

From: "Ang, Chee Hong" 

Add a new mailbox command "HPS_STAGE_NOTIFY" to notify Secure Device
Manager (SDM) on the stage of HPS code execution. In general, there
are three main code execution stages: First Stage Boot Loader (FSBL)
which is U-Boot SPL, Second Stage Boot Loader (SSBL) which is U-Boot,
and the Operating System which is Linux.

Signed-off-by: Chin Liang See 
Signed-off-by: Ley Foon Tan 
Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 7 +++
 arch/arm/mach-socfpga/mailbox_s10.c  | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h 
b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index ae728a5..e815bdf 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -87,6 +87,12 @@ enum ALT_SDM_MBOX_RESP_CODE {
 #define MBOX_QSPI_CLOSE51
 #define MBOX_QSPI_DIRECT   59
 #define MBOX_REBOOT_HPS71
+#define MBOX_HPS_STAGE_NOTIFY  93
+
+/* Defines for HPS_STAGE_NOTIFY */
+#define HPS_EXECUTION_STATE_FSBL   0
+#define HPS_EXECUTION_STATE_SSBL   1
+#define HPS_EXECUTION_STATE_OS 2
 
 /* Mailbox registers */
 #define MBOX_CIN   0   /* command valid offset */
@@ -146,6 +152,7 @@ int mbox_qspi_open(void);
 #endif
 
 int mbox_reset_cold(void);
+int mbox_hps_stage_notify(u32 execution_stage);
 int mbox_get_fpga_config_status(u32 cmd);
 int mbox_get_fpga_config_status_psci(u32 cmd);
 #endif /* _MAILBOX_S10_H_ */
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c 
b/arch/arm/mach-socfpga/mailbox_s10.c
index 4498ab5..250df84 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -390,6 +390,12 @@ int __secure mbox_get_fpga_config_status_psci(u32 cmd)
return mbox_get_fpga_config_status_common(cmd);
 }
 
+int mbox_hps_stage_notify(u32 execution_stage)
+{
+   return mbox_send_cmd(MBOX_ID_UBOOT, MBOX_HPS_STAGE_NOTIFY,
+MBOX_CMD_DIRECT, 1, _stage, 0, 0, NULL);
+}
+
 int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
  u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
 {
-- 
2.7.4

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

[U-Boot] [PATCH v1 0/3] Enable HPS execution stage notification

[chee . hong . ang]

From: "Ang, Chee Hong" 

Notify Secure Device Manager (SDM) on the stage of HPS code execution.
In general, there are three main code execution stages:
(1) First Stage Boot Loader (FSBL) which is U-Boot SPL.
(2) Second Stage Boot Loader (SSBL) which is U-Boot.
(3) Operating System which is Linux.

Ang, Chee Hong (3):
  ARM: socfpga: stratix10: Add HPS execution stage notification function
  ARM: socfpga: stratix10: To notify SDM when SPL pass control to U-Boot
  ARM: socfpga: stratix10: To notify SDM when U-Boot pass control to
Linux

 arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 7 +++
 arch/arm/mach-socfpga/mailbox_s10.c  | 6 ++
 arch/arm/mach-socfpga/misc_s10.c | 5 +
 arch/arm/mach-socfpga/spl_s10.c  | 6 ++
 4 files changed, 24 insertions(+)

-- 
2.7.4

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

[U-Boot] [PATCH v1 2/3] ARM: socfpga: stratix10: To notify SDM when SPL pass control to U-Boot

[chee . hong . ang]

From: "Ang, Chee Hong" 

Prior SPL pass control to U-Boot, SPL will send a mailbox command
"HPS_STAGE_NOTIFY" to notify Secure Device Manager (SDM) on HPS SW
transition.

This is for debug purpose as user can query SDM on HPS error
details when HPS enters a warm reset due to error such as watchdog.

Signed-off-by: Chin Liang See 
Signed-off-by: Ang, Chee Hong 
---
 arch/arm/mach-socfpga/spl_s10.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
index e063229..0721415 100644
--- a/arch/arm/mach-socfpga/spl_s10.c
+++ b/arch/arm/mach-socfpga/spl_s10.c
@@ -191,3 +191,9 @@ void board_init_f(ulong dummy)
mbox_qspi_open();
 #endif
 }
+
+/* board specific function prior loading SSBL / U-Boot */
+void spl_board_prepare_for_boot(void)
+{
+   mbox_hps_stage_notify(HPS_EXECUTION_STATE_SSBL);
+}
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 5/9] board: puma: Get bl31.bin via BL31 and rk3399m0.bin via PMUM0

[Kever Yang]

Hi Philipp and Klaus,

    Does this patch OK for your boards?

Thanks,
-Kever
On 04/28/2019 05:09 PM, Jagan Teki wrote:
> Right now puma rk3399 board need to copy bl31-rk3399.bin and
> rk3399m0.bin into u-boot source directory to make use of building
> u-boot.itb.
>
> So, add environment variable
> - BL31 for bl31.bin (instead of bl31-rk3399.bin to compatible with other
>   platform BL31 env)
> - PMUM0 for rk3399m0.bin
>
> If the builds are not exporting BL31, PMUM0 env, the fit_spl_atf.sh will
> notify with warning about which document to refer for more information
> like this:
>
>  WARNING: BL31 file bl31.bin NOT found, resulting binary is non-functional
>  Please read Building section in doc/README.rockchip
>  WARNING: PMUM0 file rk3399m0.bin NOT found, resulting binary is 
> non-functional
>  Please read Building section in doc/README.rockchip
>
> Signed-off-by: Jagan Teki 
> ---
>  .../{fit_spl_atf.its => fit_spl_atf.sh}   | 46 ---
>  configs/puma-rk3399_defconfig |  2 +-
>  doc/README.rockchip   |  8 ++--
>  3 files changed, 45 insertions(+), 11 deletions(-)
>  rename board/theobroma-systems/puma_rk3399/{fit_spl_atf.its => 
> fit_spl_atf.sh} (50%)
>  mode change 100644 => 100755
>
> diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its 
> b/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> old mode 100644
> new mode 100755
> similarity index 50%
> rename from board/theobroma-systems/puma_rk3399/fit_spl_atf.its
> rename to board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> index 530f059f3d..517fad40a1
> --- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
> +++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> @@ -1,3 +1,31 @@
> +#!/bin/sh
> +#
> +# Copyright (C) 2019 Jagan Teki 
> +#
> +# Based on the board/sunxi/mksunxi_fit_atf.sh
> +#
> +# Script to generate FIT image source for 64-bit puma boards with
> +# U-Boot proper, ATF, PMU firmware and devicetree.
> +#
> +# usage: $0  [ [ +
> +[ -z "$BL31" ] && BL31="bl31.bin"
> +
> +if [ ! -f $BL31 ]; then
> + echo "WARNING: BL31 file $BL31 NOT found, resulting binary is 
> non-functional" >&2
> + echo "Please read Building section in doc/README.rockchip" >&2
> + BL31=/dev/null
> +fi
> +
> +[ -z "$PMUM0" ] && PMUM0="rk3399m0.bin"
> +
> +if [ ! -f $PMUM0 ]; then
> + echo "WARNING: PMUM0 file $PMUM0 NOT found, resulting binary is 
> non-functional" >&2
> + echo "Please read Building section in doc/README.rockchip" >&2
> + PMUM0=/dev/null
> +fi
> +
> +cat << __HEADER_EOF
>  /* SPDX-License-Identifier: GPL-2.0+ OR X11 */
>  /*
>   * Copyright (C) 2017 Theobroma Systems Design und Consulting GmbH
> @@ -14,16 +42,15 @@
>   images {
>   uboot {
>   description = "U-Boot (64-bit)";
> - data = /incbin/("../../../u-boot-nodtb.bin");
> + data = /incbin/("u-boot-nodtb.bin");
>   type = "standalone";
> - os = "U-Boot";
>   arch = "arm64";
>   compression = "none";
> - load = <0x0020>;
> + load = <0x4a00>;
>   };
>   atf {
>   description = "ARM Trusted Firmware";
> - data = /incbin/("../../../bl31-rk3399.bin");
> + data = /incbin/("$BL31");
>   type = "firmware";
>   arch = "arm64";
>   os = "arm-trusted-firmware";
> @@ -33,17 +60,20 @@
>   };
>   pmu {
>   description = "Cortex-M0 firmware";
> - data = /incbin/("../../../rk3399m0.bin");
> + data = /incbin/("$PMUM0");
>   type = "pmu-firmware";
>   compression = "none";
>   load = <0x18>;
>  };
>   fdt {
>   description = "RK3399-Q7 (Puma) flat device-tree";
> - data = /incbin/("../../../u-boot.dtb");
> + data = /incbin/("u-boot.dtb");
>   type = "flat_dt";
>   compression = "none";
>   };
> +__HEADER_EOF
> +
> +cat << __CONF_HEADER_EOF
>   };
>  
>   configurations {
> @@ -54,5 +84,9 @@
>   loadables = "uboot", "pmu";
>   fdt = "fdt";
>   };
> +__CONF_HEADER_EOF
> +
> +cat << __ITS_EOF
>   };
>  };
> +__ITS_EOF
> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
> index e5ea2fe0b3..98b2dd6f02 100644
> --- a/configs/puma-rk3399_defconfig
> +++ b/configs/puma-rk3399_defconfig
> @@ -15,7 +15,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
> -CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
> 

Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

[Andreas Dannenberg]

Hi Simon,

On Mon, May 06, 2019 at 09:51:56PM -0600, Simon Glass wrote:
> Hi Andreas,
> 
> On Fri, 3 May 2019 at 14:25, Andreas Dannenberg  wrote:
> >
> > Simon,
> >
> > On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote:
> > > Simon Glass  schrieb am Sa., 30. März 2019, 21:06:
> > >
> > > > Hi Simon,
> > > >
> > > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
> > > >  wrote:
> > > > >
> > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
> > > > clears
> > > > > the bss before calling board_init_f() instead of clearing it before
> > > > calling
> > > > > board_init_r().
> > > > >
> > > > > This also ensures that variables placed in BSS can be shared between
> > > > > board_init_f() and board_init_r() in SPL.
> > > > >
> > > > > Such global variables are used, for example, when loading things from 
> > > > > FAT
> > > > > before SDRAM is available: the full heap required for FAT uses global
> > > > > variables and clearing BSS after board_init_f() would reset the heap
> > > > state.
> > > > > An example for such a usage is socfpa_arria10 where an FPGA 
> > > > > configuration
> > > > > is required before SDRAM can be used.
> > > > >
> > > > > Make the new option depend on ARM for now until more implementations
> > > > follow.
> > > > >
> > > >
> > > > I still have objections to this series and I think we should discuss
> > > > other ways of solving this problem.
> > > >
> > > > Does socfgpa have SRAM that could be used before SDRAM is available?
> > > > If so, can we not use that for the configuration? What various are
> > > > actually in BSS that are needed before board_init_r() is called? Can
> > > > they not be in a struct created from malloc()?
> > > >
> > >
> > > The problem is the board needs to load an FPGA configuration from FAT
> > > before SDRAM is available. Yes, this is loaded into SRAM of course, but 
> > > the
> > > whole code until that is done uses so many malloc/free iterations that The
> > > simple mall of implementation would require too much memory.
> > >
> > > And it's the full malloc state variables only that use BSS, not the FAT
> > > code.
> >
> > I've actually faced very similar issues working on our TI AM654x "System
> > Firmware Loader" implementation (will post upstream soon), where I need
> > to load this firmware and other files from media such as MMC/FAT in a very
> > memory-constrained SPL pre-relocation environment *before* I can bring up
> > DDR.
> >
> > Initially, I modified the fat.c driver to re-use memory so it is not as
> > wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1]
> > this allowed us to get going, allowing to load multiple files without
> > issues in pre-relocation SPL.
> 
> That seems to point the way to a useful solution I think. We could
> have a struct containing allocated pointers which is private to FAT,
> and just allocate them the first time.

The board_init_f()-based loader solution we use extends beyond MMC/FAT,
but also for OSPI, X/Y-Modem, and (later) USB, network, etc.

Background:
On our "TI K3" devices we need to do a whole bunch of stuff before
DDR is up with limited memory, namely loading and installing a firmware
that controls the entire SoC called "System Firmware". It is only after
this FW is loaded from boot media and successfully started that I can
bring up DDR. So all this is done in SPL board_init_f(), which as the
last step brings up DDR.

Not having BSS available to carry over certain state to the
board_init_r() world would lead to a bunch of hacky changes across
the board I'm afraid, more below.

> I wonder if that would be enough for
> 
> >
> > In the quest of creating something more upstream-friendly I had then
> > switched to using full malloc in pre-relocation SPL so that I didn't
> > have to hack the FAT driver, encountering similar issues like you
> > brought up and got this working, but ultimately abandoned this
> > approach after bundling all files needed to get loaded into a single
> > image tree blob which no longer required any of those solutions.
> >
> > What remained till today however is a need to preserve specific BSS
> > state from pre-relocation SPL over to post-relocation SPL environment,
> > namely flags set to avoid the (expensive) re-probing of peripheral
> > drivers by the SPL loader. For that I introduced a Kconfig option that
> > allows skipping the automatic clearing of BSS during relocation [2].
> >
> > Seeing this very related discussion here got me thinking about how else
> > I can carry over this "state" from pre- to post relocation but that's
> > probably a discussion to be had once I post my "System Firmware Loader
> > Series", probably next week.
> 
> Since this is SPL I don't you mean 'relocation' here. I think you mean
> board_init_f() to board_init_r()?

Yes that's what I mean. AFAIK relocation in SPL is still called relocation
from what I have seen working on U-boot, it just relocates gd and stack
but not the actual code 

Re: [U-Boot] [PATCH 4/4] efi_loader: unload applications upon Exit()

[Takahiro Akashi]

On Sat, May 04, 2019 at 10:36:36AM +0200, Heinrich Schuchardt wrote:
> Implement unloading of images in the Exit() boot services:
> 
> * unload images that are not yet started,
> * unload started applications,
> * unload drivers returning an error.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  |  1 +
>  lib/efi_loader/efi_boottime.c | 34 ++-
>  lib/efi_loader/efi_image_loader.c |  2 ++
>  3 files changed, 32 insertions(+), 5 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c2a449e5b6..d73c89ac26 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -237,6 +237,7 @@ struct efi_loaded_image_obj {
>   struct jmp_buf_data exit_jmp;
>   EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
>struct efi_system_table *st);
> + u16 image_type;
>  };
> 
>  /**
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index bbcd66caa6..51e0bb2fd5 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -2798,7 +2799,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
> image_handle,
>*   image protocol.
>*/
>   efi_status_t ret;
> - void *info;
> + struct efi_loaded_image *loaded_image_protocol;
>   struct efi_loaded_image_obj *image_obj =
>   (struct efi_loaded_image_obj *)image_handle;
> 
> @@ -2806,13 +2807,33 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
> image_handle,
> exit_data_size, exit_data);
> 
>   /* Check parameters */
> - if (image_handle != current_image)
> + if (image_handle != current_image) {

Does this check make sense even for a driver?

> + ret = EFI_INVALID_PARAMETER;
>   goto out;
> + }
>   ret = EFI_CALL(efi_open_protocol(image_handle, _guid_loaded_image,
> -  , NULL, NULL,
> +  (void **)_image_protocol,
> +  NULL, NULL,
>EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> - if (ret != EFI_SUCCESS)
> + if (ret != EFI_SUCCESS) {

Is this check necessary even when 'header.type' is introduced?

> + ret = EFI_INVALID_PARAMETER;
>   goto out;
> + }
> +
> + /* Unloading of unstarted images */

'Unload' sounds odd when we call efi_delete_image(), doesn't it?

> + switch (image_obj->header.type) {
> + case EFI_OBJECT_TYPE_STARTED_IMAGE:
> + break;
> + case EFI_OBJECT_TYPE_LOADED_IMAGE:
> + efi_delete_image(image_obj, loaded_image_protocol);
> + ret = EFI_SUCCESS;
> + goto out;
> + default:
> + /* Handle does not refer to loaded image */
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> + image_obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;
> 
>   /* Exit data is only foreseen in case of failure. */
>   if (exit_status != EFI_SUCCESS) {
> @@ -2822,6 +2843,9 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
> image_handle,
>   if (ret != EFI_SUCCESS)
>   EFI_PRINT("%s: out of memory\n", __func__);
>   }
> + if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION ||
> + exit_status != EFI_SUCCESS)
> + efi_delete_image(image_obj, loaded_image_protocol);

Why not merge those two efi_delete_image()?

-Takahiro Akashi


>   /* Make sure entry/exit counts for EFI world cross-overs match */
>   EFI_EXIT(exit_status);
> @@ -2837,7 +2861,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
> image_handle,
> 
>   panic("EFI application exited");
>  out:
> - return EFI_EXIT(EFI_INVALID_PARAMETER);
> + return EFI_EXIT(ret);
>  }
> 
>  /**
> diff --git a/lib/efi_loader/efi_image_loader.c 
> b/lib/efi_loader/efi_image_loader.c
> index f8092b6202..13541cfa7a 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -273,6 +273,7 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj 
> *handle, void *efi,
>   IMAGE_OPTIONAL_HEADER64 *opt = >OptionalHeader;
>   image_base = opt->ImageBase;
>   efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> + handle->image_type = opt->Subsystem;
>   efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
>   if (!efi_reloc) {
> @@ -288,6 +289,7 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj 
> *handle, void *efi,
>   IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
>   image_base = opt->ImageBase;
>   

Re: [U-Boot] [PATCH v3 2/2] regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs

[Vaittinen, Matti]

On Mon, 2019-05-06 at 21:51 -0600, Simon Glass wrote:
> Hi Matti,
> 
> On Thu, 25 Apr 2019 at 03:51, Matti Vaittinen
>  wrote:
> > 
> > BD71837 and BD71847 is PMIC intended for powering single-core,
> > dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
> > is used for example on NXP imx8mm EVK.
> > 
> > Add regulator driver for ROHM BD71837 and BD71847 PMICs.
> > BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
> > version containing 6 bucks and 6 LDOs. Voltages for DVS
> > bucks (1-4 on BD71837, 1 and 2 on BD71847) can be adjusted
> > when regulators are enabled. For other bucks and LDOs we may
> > have over- or undershooting if voltage is adjusted when
> > regulator is enabled. Thus this is prevented by default.
> > 
> > BD718x7 has a quirk which may leave power output disabled
> > after reset if enable/disable state was controlled by SW.
> > Thus the SW control is only allowed for BD71837  bucks
> > 3 and 4 by default. The impact of this limitation must be
> > evaluated board-by board and restrictions may need to be
> > modified. (Linux driver get's these limitations from DT and we
> > may want to implement same on u-Boot driver).
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> > 
> > Changelog v2 => v3:
> > - remove unnecessary include
> > - use uint8_t instead of u8
> 
> Sorry I did not reply in time. I meant that you should use uint
> instead of u8. There is no need for the arg to be 8 bits and it may
> make the machine code larger. So try to use native times for function
> args (int, uint).

Right. I'll craft a v4 then. What comes to 8bit types, which one is
preferred - u8 or uint8_t?

Br,
Matti Vaittinen

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

Re: [U-Boot] [PATCH v6 03/13] Kconfig: Add default SPL_FIT_GENERATOR for rockchip

[Kever Yang]

Hi Jagan,


On 04/27/2019 07:48 PM, Jagan Teki wrote:
> Add default SPL_FIT_GENERATOR py script for rockchip platforms if
> specific target enabled SPL_LOAD_FIT.
>
> So, this would help get rid of explicitly mentioning the default
> SPL FIT generator in defconfigs. however some targets, like puma_rk3399
> still require their own FIT generator so in those cases the default will
> override with defconfig defined generator.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Paul Kocialkowski 
> ---
>  Kconfig  | 1 +
>  configs/chromebook_bob_defconfig | 1 -
>  configs/evb-rk3399_defconfig | 1 -
>  configs/ficus-rk3399_defconfig   | 1 -
>  configs/firefly-rk3399_defconfig | 1 -
>  configs/rock960-rk3399_defconfig | 1 -
>  6 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/Kconfig b/Kconfig
> index 305b265ed7..5679a288ec 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -424,6 +424,7 @@ config SPL_FIT_GENERATOR
>   string ".its file generator script for U-Boot FIT image"
>   depends on SPL_FIT
>   default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
> + default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && 
> ARCH_ROCKCHIP

What happens to puma-rk3399 board with this patch? For it use dedicate
its file now.
configs/puma-rk3399_defconfig
CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"

Thanks,
- Kever
>   help
> Specifies a (platform specific) script file to generate the FIT
> source file used to build the U-Boot FIT image file. This gets
> diff --git a/configs/chromebook_bob_defconfig 
> b/configs/chromebook_bob_defconfig
> index ce3deccb8a..04e25e1d4f 100644
> --- a/configs/chromebook_bob_defconfig
> +++ b/configs/chromebook_bob_defconfig
> @@ -19,7 +19,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index d98535357a..49b2e2e089 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
> index 94c565efc2..fe3b9964e8 100644
> --- a/configs/ficus-rk3399_defconfig
> +++ b/configs/ficus-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEBUG_UART=y
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_STACK_R=y
> diff --git a/configs/firefly-rk3399_defconfig 
> b/configs/firefly-rk3399_defconfig
> index 6725b48970..914304bb43 100644
> --- a/configs/firefly-rk3399_defconfig
> +++ b/configs/firefly-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> diff --git a/configs/rock960-rk3399_defconfig 
> b/configs/rock960-rk3399_defconfig
> index cb5a35f4f5..5e6778ea20 100644
> --- a/configs/rock960-rk3399_defconfig
> +++ b/configs/rock960-rk3399_defconfig
> @@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEBUG_UART=y
>  CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
> -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y



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

Re: [U-Boot] [PATCH v3 1/2] regulator: bd71837: copy the bd71837 pmic driver from NXP imx u-boot

[Simon Glass]

On Thu, 25 Apr 2019 at 03:48, Matti Vaittinen
 wrote:
>
> https://source.codeaurora.org/external/imx/uboot-imx
>
> cherry picked, styled and merged commits:
> - MLK-18387 pmic: Add pmic driver for BD71837: e9a3bec2e95a
> - MLK-18590 pmic: bd71837: Change to use new fdt API: acdc5c297a96
>
> Signed-off-by: Ye Li 
> Signed-off-by: Matti Vaittinen 
> ---
> Changelog v2 => v3
> - use pmic_clrsetbits() instead of reg_read and reg_write
> - remove unnecessary include
>
>  drivers/power/pmic/Kconfig   |  7 +++
>  drivers/power/pmic/Makefile  |  1 +
>  drivers/power/pmic/bd71837.c | 89 
>  include/power/bd71837.h  | 62 +
>  4 files changed, 159 insertions(+)
>  create mode 100644 drivers/power/pmic/bd71837.c
>  create mode 100644 include/power/bd71837.h

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

Re: [U-Boot] [PATCH 1/2] fdtdec: Use fdt_setprop_u32() for fdtdec_set_phandle()

[Simon Glass]

Hi Thierry,

On Thu, 25 Apr 2019 at 07:25, Thierry Reding  wrote:
>
> On Mon, Apr 15, 2019 at 10:08:20AM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> >
> > The fdt_setprop_u32() function does everything that we need, so we
> > really only use the function as a convenience wrapper, in which case it
> > can simply be a static inline function.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  include/fdtdec.h | 5 -
> >  lib/fdtdec.c | 7 ---
> >  2 files changed, 4 insertions(+), 8 deletions(-)
>
> Hi Simon,
>
> gentle reminder on these. These are the two follow-up patches that you
> had suggested I make on top of the other fdtdec series that you applied
> a couple of weeks ago.

I think this is applied now?

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

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

[Simon Glass]

Hi Thierry,

On Fri, 26 Apr 2019 at 06:01, Thierry Reding  wrote:
>
> On Mon, Apr 15, 2019 at 10:08:21AM +0200, Thierry Reding wrote:
> > 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(-)
>
> Hi Simon,
>
> you picked up patch 1/2 of this set. Did you have any comments on v2, or
> did you overlook it?

I marked it as superseded.

http://patchwork.ozlabs.org/patch/1085480/

Is that incorrect?

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

Re: [U-Boot] [PATCH v1 03/18] dm: Add a No-op uclass

[Simon Glass]

Hi Jean-Jacques,

On Fri, 5 Apr 2019 at 06:56, Jean-Jacques Hiblot  wrote:
>
> This uclass is intended for devices that do not need any features from the
> uclass, including binding children.
> This will typically be used by devices that are used to bind child devices
> but do not use dm_scan_fdt_dev() to do it. That is for example the case of
> several USB wrappers that have 2 child devices (1 for device and 1 for
> host) but bind only one at a any given time.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
>  drivers/core/uclass.c  | 5 +
>  include/dm/uclass-id.h | 1 +
>  2 files changed, 6 insertions(+)

Is there a test for this somewhere?


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

Re: [U-Boot] [PATCH v3 2/2] regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs

[Simon Glass]

Hi Matti,

On Thu, 25 Apr 2019 at 03:51, Matti Vaittinen
 wrote:
>
> BD71837 and BD71847 is PMIC intended for powering single-core,
> dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
> is used for example on NXP imx8mm EVK.
>
> Add regulator driver for ROHM BD71837 and BD71847 PMICs.
> BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
> version containing 6 bucks and 6 LDOs. Voltages for DVS
> bucks (1-4 on BD71837, 1 and 2 on BD71847) can be adjusted
> when regulators are enabled. For other bucks and LDOs we may
> have over- or undershooting if voltage is adjusted when
> regulator is enabled. Thus this is prevented by default.
>
> BD718x7 has a quirk which may leave power output disabled
> after reset if enable/disable state was controlled by SW.
> Thus the SW control is only allowed for BD71837  bucks
> 3 and 4 by default. The impact of this limitation must be
> evaluated board-by board and restrictions may need to be
> modified. (Linux driver get's these limitations from DT and we
> may want to implement same on u-Boot driver).
>
> Signed-off-by: Matti Vaittinen 
> ---
>
> Changelog v2 => v3:
> - remove unnecessary include
> - use uint8_t instead of u8

Sorry I did not reply in time. I meant that you should use uint
instead of u8. There is no need for the arg to be 8 bits and it may
make the machine code larger. So try to use native times for function
args (int, uint).

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

Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

[Simon Glass]

Hi Andreas,

On Fri, 3 May 2019 at 14:25, Andreas Dannenberg  wrote:
>
> Simon,
>
> On Sat, Mar 30, 2019 at 09:18:08PM +0100, Simon Goldschmidt wrote:
> > Simon Glass  schrieb am Sa., 30. März 2019, 21:06:
> >
> > > Hi Simon,
> > >
> > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
> > >  wrote:
> > > >
> > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
> > > clears
> > > > the bss before calling board_init_f() instead of clearing it before
> > > calling
> > > > board_init_r().
> > > >
> > > > This also ensures that variables placed in BSS can be shared between
> > > > board_init_f() and board_init_r() in SPL.
> > > >
> > > > Such global variables are used, for example, when loading things from 
> > > > FAT
> > > > before SDRAM is available: the full heap required for FAT uses global
> > > > variables and clearing BSS after board_init_f() would reset the heap
> > > state.
> > > > An example for such a usage is socfpa_arria10 where an FPGA 
> > > > configuration
> > > > is required before SDRAM can be used.
> > > >
> > > > Make the new option depend on ARM for now until more implementations
> > > follow.
> > > >
> > >
> > > I still have objections to this series and I think we should discuss
> > > other ways of solving this problem.
> > >
> > > Does socfgpa have SRAM that could be used before SDRAM is available?
> > > If so, can we not use that for the configuration? What various are
> > > actually in BSS that are needed before board_init_r() is called? Can
> > > they not be in a struct created from malloc()?
> > >
> >
> > The problem is the board needs to load an FPGA configuration from FAT
> > before SDRAM is available. Yes, this is loaded into SRAM of course, but the
> > whole code until that is done uses so many malloc/free iterations that The
> > simple mall of implementation would require too much memory.
> >
> > And it's the full malloc state variables only that use BSS, not the FAT
> > code.
>
> I've actually faced very similar issues working on our TI AM654x "System
> Firmware Loader" implementation (will post upstream soon), where I need
> to load this firmware and other files from media such as MMC/FAT in a very
> memory-constrained SPL pre-relocation environment *before* I can bring up
> DDR.
>
> Initially, I modified the fat.c driver to re-use memory so it is not as
> wasteful during SYS_MALLOC_SIMPLE. While I'm not proud of this solution [1]
> this allowed us to get going, allowing to load multiple files without
> issues in pre-relocation SPL.

That seems to point the way to a useful solution I think. We could
have a struct containing allocated pointers which is private to FAT,
and just allocate them the first time.

I wonder if that would be enough for

>
> In the quest of creating something more upstream-friendly I had then
> switched to using full malloc in pre-relocation SPL so that I didn't
> have to hack the FAT driver, encountering similar issues like you
> brought up and got this working, but ultimately abandoned this
> approach after bundling all files needed to get loaded into a single
> image tree blob which no longer required any of those solutions.
>
> What remained till today however is a need to preserve specific BSS
> state from pre-relocation SPL over to post-relocation SPL environment,
> namely flags set to avoid the (expensive) re-probing of peripheral
> drivers by the SPL loader. For that I introduced a Kconfig option that
> allows skipping the automatic clearing of BSS during relocation [2].
>
> Seeing this very related discussion here got me thinking about how else
> I can carry over this "state" from pre- to post relocation but that's
> probably a discussion to be had once I post my "System Firmware Loader
> Series", probably next week.

Since this is SPL I don't you mean 'relocation' here. I think you mean
board_init_f() to board_init_r()?

You can use global_data to store state, or malloc() to allocate memory
and put things there. But using BSS seems wrong to me. If you are
doing something in board_init_f() in SPL that needs BSS, can you not
just move that code to board_init_r()?

>
> PS: If you want to save a ton of memory during FAT loading you can
> try something like CONFIG_FS_FAT_MAX_CLUSTSIZE=16384, I argue the
> default is overkill for all practical scenarios.
>
> --
> Andreas Dannenberg
> Texas Instruments Inc
>
> [1] 
> http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=3de26c27d232425e6a3b337dc402d73fe22ea88c
> [2] 
> http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commitdiff;h=9ab4a405c98e966a59c7c3005c08cb95ed87eea8
>
> >
> > One way out could be to move the full mall of state variables into 'gd'...
> >
> > Another way would be to continue into board_init_f without SDRAM enabled
> > and in it it later...
> >
> > Regards,
> > Simon
> >
> >
> > > If this is a limitation of FAT, then I think we should fix that, instead.
> > >
> > > Regards,
> > > Simon
> > >
> > > > Signed-off-by: Simon Goldschmidt 
> > > > 

Re: [U-Boot] [PATCH 6/6] configs: T2080QDS: Enable PCIe driver

[Simon Glass]

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 

Needs a commit message.

>
> Signed-off-by: Hou Zhiqiang 
> ---
>  configs/T2080QDS_defconfig | 5 +
>  1 file changed, 5 insertions(+)

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

Re: [U-Boot] [PATCH 3/6] t2080: dts: Added PCIe DT nodes

[Simon Glass]

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> T2080 integrated 4 PCIe controllers, which is compatible with
> the PCI Express™ Base Specification, Revision 3.0, and this
> patch is to add DT node for each PCIe controller.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  arch/powerpc/dts/t2080.dtsi | 48 +
>  1 file changed, 48 insertions(+)

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

Re: [U-Boot] [PATCH 5/6] powerpc: T208xQDS: Disable legacy PCIe driver

[Simon Glass]

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> Disable legacy PCIe driver and remove unused PCIe macros.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  include/configs/T208xQDS.h | 18 --
>  1 file changed, 18 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] drivers: core: use strcmp when find device by name

[Simon Glass]

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

Re: [U-Boot] [PATCH 2/6] powerpc: T208xQDS: Compile the legacy PCIe routines conditionally

[Simon Glass]

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> Compile the legacy PCIe initialization reoutines only when DM_PCI
> is not enabled.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  board/freescale/t208xqds/pci.c | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH 1/6] powerpc: mpc85xx: Update the condition to compile PCI routines

[Simon Glass]

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> Compile the routines of mpc85xx/pci.c when both FSL_PCI_INIT
> and DM_PCI are not enabled.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  arch/powerpc/cpu/mpc85xx/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v3 07/10] pinctrl: rockchip: Split the common set_pull() func into per Soc

[Kever Yang]

On 04/16/2019 09:57 PM, David Wu wrote:
> As the common set_mux func(), implement the feature at the own file
> for each Soc.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3036.c | 23 -
>  drivers/pinctrl/rockchip/pinctrl-rk3128.c | 23 -
>  drivers/pinctrl/rockchip/pinctrl-rk3188.c | 29 +-
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c | 29 +-
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 40 ++--
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 29 +-
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c | 40 ++--
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c | 40 ++--
>  .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 97 ---
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h   |  7 +-
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c | 30 +-
>  11 files changed, 275 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3036.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> index 8969aea2e3..498b633f22 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> @@ -53,6 +53,27 @@ static void rk3036_calc_pull_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   *bit = pin_num % RK3036_PULL_PINS_PER_REG;
>  };
>  
> +static int rk3036_set_pull(struct rockchip_pin_bank *bank,
> +int pin_num, int pull)
> +{
> + struct regmap *regmap;
> + int reg, ret;
> + u8 bit;
> + u32 data;
> +
> + if (pull != PIN_CONFIG_BIAS_PULL_PIN_DEFAULT &&
> + pull != PIN_CONFIG_BIAS_DISABLE)
> + return -ENOTSUPP;
> +
> + rk3036_calc_pull_reg_and_bit(bank, pin_num, , , );
> + data = BIT(bit + 16);
> + if (pull == PIN_CONFIG_BIAS_DISABLE)
> + data |= BIT(bit);
> + ret = regmap_write(regmap, reg, data);
> +
> + return ret;
> +}
> +
>  static struct rockchip_pin_bank rk3036_pin_banks[] = {
>   PIN_BANK(0, 32, "gpio0"),
>   PIN_BANK(1, 32, "gpio1"),
> @@ -66,7 +87,7 @@ static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
>   .type   = RK3036,
>   .grf_mux_offset = 0xa8,
>   .set_mux= rk3036_set_mux,
> - .pull_calc_reg  = rk3036_calc_pull_reg_and_bit,
> + .set_pull   = rk3036_set_pull,
>  };
>  
>  static const struct udevice_id rk3036_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3128.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> index de203334c7..104b76c19e 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> @@ -152,6 +152,27 @@ static void rk3128_calc_pull_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   *bit = pin_num % RK3128_PULL_PINS_PER_REG;
>  }
>  
> +static int rk3128_set_pull(struct rockchip_pin_bank *bank,
> +int pin_num, int pull)
> +{
> + struct regmap *regmap;
> + int reg, ret;
> + u8 bit;
> + u32 data;
> +
> + if (pull != PIN_CONFIG_BIAS_PULL_PIN_DEFAULT &&
> + pull != PIN_CONFIG_BIAS_DISABLE)
> + return -ENOTSUPP;
> +
> + rk3128_calc_pull_reg_and_bit(bank, pin_num, , , );
> + data = BIT(bit + 16);
> + if (pull == PIN_CONFIG_BIAS_DISABLE)
> + data |= BIT(bit);
> + ret = regmap_write(regmap, reg, data);
> +
> + return ret;
> +}
> +
>  static struct rockchip_pin_bank rk3128_pin_banks[] = {
>   PIN_BANK(0, 32, "gpio0"),
>   PIN_BANK(1, 32, "gpio1"),
> @@ -170,7 +191,7 @@ static struct rockchip_pin_ctrl rk3128_pin_ctrl = {
>   .iomux_routes   = rk3128_mux_route_data,
>   .niomux_routes  = ARRAY_SIZE(rk3128_mux_route_data),
>   .set_mux= rk3128_set_mux,
> - .pull_calc_reg  = rk3128_calc_pull_reg_and_bit,
> + .set_pull   = rk3128_set_pull,
>  };
>  
>  static const struct udevice_id rk3128_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3188.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> index 617ae28ac8..e09c799e72 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> @@ -71,6 +71,33 @@ static void rk3188_calc_pull_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   }
>  }
>  
> +static int rk3188_set_pull(struct rockchip_pin_bank *bank,
> +int pin_num, int pull)
> +{
> + struct regmap *regmap;
> + int reg, ret;
> + u8 bit, type;
> + u32 data;
> +
> + if (pull == PIN_CONFIG_BIAS_PULL_PIN_DEFAULT)
> + return -ENOTSUPP;
> +
> + rk3188_calc_pull_reg_and_bit(bank, pin_num, , , );
> + type = bank->pull_type[pin_num / 8];
> + ret = rockchip_translate_pull_value(type, pull);
> + if (ret < 0) {
> + debug("unsupported pull setting %d\n", pull);
> + return ret;
> + }
> +
> + 

Re: [U-Boot] [PATCH v3 09/10] pinctrl: rockchip: Clean the unused type and label

[Kever Yang]

On 04/16/2019 09:57 PM, David Wu wrote:
> As the mux/pull/drive feature implement at own file,
> the type and label are not necessary.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3036.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3128.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3188.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c   |  2 --
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h | 12 
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c   |  2 --
>  10 files changed, 30 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3036.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> index 498b633f22..28c905129b 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> @@ -83,8 +83,6 @@ static struct rockchip_pin_bank rk3036_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
>   .pin_banks  = rk3036_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3036_pin_banks),
> - .label  = "RK3036-GPIO",
> - .type   = RK3036,
>   .grf_mux_offset = 0xa8,
>   .set_mux= rk3036_set_mux,
>   .set_pull   = rk3036_set_pull,
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3128.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> index 104b76c19e..3eb4d952bb 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> @@ -183,8 +183,6 @@ static struct rockchip_pin_bank rk3128_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3128_pin_ctrl = {
>   .pin_banks  = rk3128_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3128_pin_banks),
> - .label  = "RK3128-GPIO",
> - .type   = RK3128,
>   .grf_mux_offset = 0xa8,
>   .iomux_recalced = rk3128_mux_recalced_data,
>   .niomux_recalced= ARRAY_SIZE(rk3128_mux_recalced_data),
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3188.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> index e09c799e72..043764fc92 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> @@ -108,8 +108,6 @@ static struct rockchip_pin_bank rk3188_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
>   .pin_banks  = rk3188_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3188_pin_banks),
> - .label  = "RK3188-GPIO",
> - .type   = RK3188,
>   .grf_mux_offset = 0x60,
>   .set_mux= rk3188_set_mux,
>   .set_pull   = rk3188_set_pull,
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk322x.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> index b69d9795bb..c5e4fe30a7 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> @@ -268,8 +268,6 @@ static struct rockchip_pin_bank rk3228_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
>   .pin_banks  = rk3228_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3228_pin_banks),
> - .label  = "RK3228-GPIO",
> - .type   = RK3288,
>   .grf_mux_offset = 0x0,
>   .iomux_routes   = rk3228_mux_route_data,
>   .niomux_routes  = ARRAY_SIZE(rk3228_mux_route_data),
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 24af3597ec..7ae147f304 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -223,8 +223,6 @@ static struct rockchip_pin_bank rk3288_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3288_pin_ctrl = {
>   .pin_banks  = rk3288_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3288_pin_banks),
> - .label  = "RK3288-GPIO",
> - .type   = RK3288,
>   .grf_mux_offset = 0x0,
>   .pmu_mux_offset = 0x84,
>   .iomux_routes   = rk3288_mux_route_data,
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3328.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> index 7ac5c0226e..d4d37af206 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> @@ -281,8 +281,6 @@ static struct rockchip_pin_bank rk3328_pin_banks[] = {
>  static struct rockchip_pin_ctrl rk3328_pin_ctrl = {
>   .pin_banks  = rk3328_pin_banks,
>   .nr_banks   = ARRAY_SIZE(rk3328_pin_banks),
> - 

Re: [U-Boot] [PATCH v3 10/10] pinctrl: rockchip: Also move common set_schmitter func into per Soc file

[Kever Yang]

On 04/16/2019 09:58 PM, David Wu wrote:
> Only some Soc need Schmitter feature, so move the
> implementation into their own files.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 17 -
>  .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 19 +++
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h   |  5 ++---
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c | 17 -
>  4 files changed, 37 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3328.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> index d4d37af206..8d37a6f945 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3328.c
> @@ -264,6 +264,21 @@ static int rk3328_calc_schmitt_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   return 0;
>  }
>  
> +static int rk3328_set_schmitt(struct rockchip_pin_bank *bank,
> +   int pin_num, int enable)
> +{
> + struct regmap *regmap;
> + int reg;
> + u8 bit;
> + u32 data;
> +
> + rk3328_calc_schmitt_reg_and_bit(bank, pin_num, , , );
> + /* enable the write to the equivalent lower bits */
> + data = BIT(bit + 16) | (enable << bit);
> +
> + return regmap_write(regmap, reg, data);
> +}
> +
>  static struct rockchip_pin_bank rk3328_pin_banks[] = {
>   PIN_BANK_IOMUX_FLAGS(0, 32, "gpio0", 0, 0, 0, 0),
>   PIN_BANK_IOMUX_FLAGS(1, 32, "gpio1", 0, 0, 0, 0),
> @@ -289,7 +304,7 @@ static struct rockchip_pin_ctrl rk3328_pin_ctrl = {
>   .set_mux= rk3328_set_mux,
>   .set_pull   = rk3328_set_pull,
>   .set_drive  = rk3328_set_drive,
> - .schmitt_calc_reg   = rk3328_calc_schmitt_reg_and_bit,
> + .set_schmitt= rk3328_set_schmitt,
>  };
>  
>  static const struct udevice_id rk3328_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
> b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> index b3379a0d3f..80dc431d20 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> @@ -306,30 +306,20 @@ static int rockchip_set_schmitt(struct 
> rockchip_pin_bank *bank,
>  {
>   struct rockchip_pinctrl_priv *priv = bank->priv;
>   struct rockchip_pin_ctrl *ctrl = priv->ctrl;
> - struct regmap *regmap;
> - int reg, ret;
> - u8 bit;
> - u32 data;
>  
>   debug("setting input schmitt of GPIO%d-%d to %d\n", bank->bank_num,
> pin_num, enable);
>  
> - ret = ctrl->schmitt_calc_reg(bank, pin_num, , , );
> - if (ret)
> - return ret;
> -
> - /* enable the write to the equivalent lower bits */
> - data = BIT(bit + 16) | (enable << bit);
> + if (!ctrl->set_schmitt)
> + return -ENOTSUPP;
>  
> - return regmap_write(regmap, reg, data);
> + return ctrl->set_schmitt(bank, pin_num, enable);
>  }
>  
>  /* set the pin config settings for a specified pin */
>  static int rockchip_pinconf_set(struct rockchip_pin_bank *bank,
>   u32 pin, u32 param, u32 arg)
>  {
> - struct rockchip_pinctrl_priv *priv = bank->priv;
> - struct rockchip_pin_ctrl *ctrl = priv->ctrl;
>   int rc;
>  
>   switch (param) {
> @@ -350,9 +340,6 @@ static int rockchip_pinconf_set(struct rockchip_pin_bank 
> *bank,
>   break;
>  
>   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> - if (!ctrl->schmitt_calc_reg)
> - return -ENOTSUPP;
> -
>   rc = rockchip_set_schmitt(bank, pin, arg);
>   if (rc < 0)
>   return rc;
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip.h 
> b/drivers/pinctrl/rockchip/pinctrl-rockchip.h
> index 1c6fc2c5b2..9651e9c7a6 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rockchip.h
> +++ b/drivers/pinctrl/rockchip/pinctrl-rockchip.h
> @@ -271,9 +271,8 @@ struct rockchip_pin_ctrl {
>   int pin_num, int pull);
>   int (*set_drive)(struct rockchip_pin_bank *bank,
>int pin_num, int strength);
> - int (*schmitt_calc_reg)(struct rockchip_pin_bank *bank,
> - int pin_num, struct regmap **regmap,
> - int *reg, u8 *bit);
> + int (*set_schmitt)(struct rockchip_pin_bank *bank,
> +int pin_num, int enable);
>  };
>  
>  /**
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rv1108.c 
> b/drivers/pinctrl/rockchip/pinctrl-rv1108.c
> index 0bcf11bb41..54610a3e90 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rv1108.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rv1108.c
> @@ -237,6 +237,21 @@ static int rv1108_calc_schmitt_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   return 0;
>  }
>  
> +static int rv1108_set_schmitt(struct 

Re: [U-Boot] [PATCH v3 04/10] pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' iomux

[Kever Yang]

On 04/16/2019 09:50 PM, David Wu wrote:
> RK3288 pmu_gpio0 iomux setting have no higher 16 writing corresponding
> bits, need to read before write the register.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - Add some comment
>
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 1fa601d954..5040cd8f48 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -54,7 +54,15 @@ static int rk3288_set_mux(struct rockchip_pin_bank *bank, 
> int pin, int mux)
>   }
>   }
>  
> - data = (mask << (bit + 16));
> + /* bank0 is special, there are no higher 16 bit writing bits. */
> + if (bank->bank_num == 0) {
> + regmap_read(regmap, reg, );
> + data &= ~(mask << bit);
> + } else {
> + /* enable the write to the equivalent lower bits */
> + data = (mask << (bit + 16));
> + }
> +
>   data |= (mux & mask) << bit;
>   ret = regmap_write(regmap, reg, data);
>  



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

Re: [U-Boot] [PATCH v3 08/10] pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' pull

[Kever Yang]

On 04/16/2019 09:57 PM, David Wu wrote:
> RK3288 pmu_gpio0 pull setting have no higher 16 writing corresponding
> bits, need to read before write the register.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 9192aa3949..24af3597ec 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -116,8 +116,15 @@ static int rk3288_set_pull(struct rockchip_pin_bank 
> *bank,
>   return ret;
>   }
>  
> - /* enable the write to the equivalent lower bits */
> - data = ((1 << ROCKCHIP_PULL_BITS_PER_PIN) - 1) << (bit + 16);
> + /* bank0 is special, there are no higher 16 bit writing bits */
> + if (bank->bank_num == 0) {
> + regmap_read(regmap, reg, );
> + data &= ~(((1 << ROCKCHIP_PULL_BITS_PER_PIN) - 1) << bit);
> + } else {
> + /* enable the write to the equivalent lower bits */
> + data = ((1 << ROCKCHIP_PULL_BITS_PER_PIN) - 1) << (bit + 16);
> + }
> +
>   data |= (ret << bit);
>   ret = regmap_write(regmap, reg, data);
>  



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

Re: [U-Boot] [PATCH v3 06/10] pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' drive strength

[Kever Yang]

On 04/16/2019 09:56 PM, David Wu wrote:
> RK3288 pmu_gpio0 drive strength setting have no higher 16 writing
> corresponding bits, need to read before write the register.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - Add some comment
>
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 6ae9f1c76e..d1b9aeb3d9 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -143,8 +143,15 @@ static int rk3288_set_drive(struct rockchip_pin_bank 
> *bank,
>   return ret;
>   }
>  
> - /* enable the write to the equivalent lower bits */
> - data = ((1 << ROCKCHIP_DRV_BITS_PER_PIN) - 1) << (bit + 16);
> + /* bank0 is special, there are no higher 16 bit writing bits. */
> + if (bank->bank_num == 0) {
> + regmap_read(regmap, reg, );
> + data &= ~(((1 << ROCKCHIP_DRV_BITS_PER_PIN) - 1) << bit);
> + } else {
> + /* enable the write to the equivalent lower bits */
> + data = ((1 << ROCKCHIP_DRV_BITS_PER_PIN) - 1) << (bit + 16);
> + }
> +
>   data |= (ret << bit);
>   ret = regmap_write(regmap, reg, data);
>   return ret;



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

Re: [U-Boot] [PATCH v3 05/10] pinctrl: rockchip: Split the common set_drive() func into per Soc

[Kever Yang]

On 04/16/2019 09:55 PM, David Wu wrote:
> As the common set_mux func(), implement the feature at the own file
> for each Soc.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c | 25 -
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 35 +--
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 26 -
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c | 36 +--
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c | 75 ++-
>  .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 95 ---
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h   |  6 +-
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c | 26 -
>  8 files changed, 224 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk322x.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> index 442c40ce0b..10200ff3c8 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> @@ -208,6 +208,29 @@ static void rk3228_calc_drv_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   *bit *= ROCKCHIP_DRV_BITS_PER_PIN;
>  }
>  
> +static int rk3228_set_drive(struct rockchip_pin_bank *bank,
> + int pin_num, int strength)
> +{
> + struct regmap *regmap;
> + int reg, ret;
> + u32 data;
> + u8 bit;
> + int type = bank->drv[pin_num / 8].drv_type;
> +
> + rk3228_calc_drv_reg_and_bit(bank, pin_num, , , );
> + ret = rockchip_translate_drive_value(type, strength);
> + if (ret < 0) {
> + debug("unsupported driver strength %d\n", strength);
> + return ret;
> + }
> +
> + /* enable the write to the equivalent lower bits */
> + data = ((1 << ROCKCHIP_DRV_BITS_PER_PIN) - 1) << (bit + 16);
> + data |= (ret << bit);
> + ret = regmap_write(regmap, reg, data);
> + return ret;
> +}
> +
>  static struct rockchip_pin_bank rk3228_pin_banks[] = {
>   PIN_BANK(0, 32, "gpio0"),
>   PIN_BANK(1, 32, "gpio1"),
> @@ -225,7 +248,7 @@ static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
>   .niomux_routes  = ARRAY_SIZE(rk3228_mux_route_data),
>   .set_mux= rk3228_set_mux,
>   .pull_calc_reg  = rk3228_calc_pull_reg_and_bit,
> - .drv_calc_reg   = rk3228_calc_drv_reg_and_bit,
> + .set_drive  = rk3228_set_drive,
>  };
>  
>  static const struct udevice_id rk3228_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 5040cd8f48..6ae9f1c76e 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -113,10 +113,6 @@ static void rk3288_calc_drv_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   if (bank->bank_num == 0) {
>   *regmap = priv->regmap_pmu;
>   *reg = RK3288_DRV_PMU_OFFSET;
> -
> - *reg += ((pin_num / ROCKCHIP_DRV_PINS_PER_REG) * 4);
> - *bit = pin_num % ROCKCHIP_DRV_PINS_PER_REG;
> - *bit *= ROCKCHIP_DRV_BITS_PER_PIN;
>   } else {
>   *regmap = priv->regmap_base;
>   *reg = RK3288_DRV_GRF_OFFSET;
> @@ -124,11 +120,34 @@ static void rk3288_calc_drv_reg_and_bit(struct 
> rockchip_pin_bank *bank,
>   /* correct the offset, as we're starting with the 2nd bank */
>   *reg -= 0x10;
>   *reg += bank->bank_num * ROCKCHIP_DRV_BANK_STRIDE;
> - *reg += ((pin_num / ROCKCHIP_DRV_PINS_PER_REG) * 4);
> + }
> +
> + *reg += ((pin_num / ROCKCHIP_DRV_PINS_PER_REG) * 4);
> + *bit = (pin_num % ROCKCHIP_DRV_PINS_PER_REG);
> + *bit *= ROCKCHIP_DRV_BITS_PER_PIN;
> +}
>  
> - *bit = (pin_num % ROCKCHIP_DRV_PINS_PER_REG);
> - *bit *= ROCKCHIP_DRV_BITS_PER_PIN;
> +static int rk3288_set_drive(struct rockchip_pin_bank *bank,
> + int pin_num, int strength)
> +{
> + struct regmap *regmap;
> + int reg, ret;
> + u32 data;
> + u8 bit;
> + int type = bank->drv[pin_num / 8].drv_type;
> +
> + rk3288_calc_drv_reg_and_bit(bank, pin_num, , , );
> + ret = rockchip_translate_drive_value(type, strength);
> + if (ret < 0) {
> + debug("unsupported driver strength %d\n", strength);
> + return ret;
>   }
> +
> + /* enable the write to the equivalent lower bits */
> + data = ((1 << ROCKCHIP_DRV_BITS_PER_PIN) - 1) << (bit + 16);
> + data |= (ret << bit);
> + ret = regmap_write(regmap, reg, data);
> + return ret;
>  }
>  
>  static struct rockchip_pin_bank rk3288_pin_banks[] = {
> @@ -174,7 +193,7 @@ static struct rockchip_pin_ctrl rk3288_pin_ctrl = {
>   .niomux_routes  = ARRAY_SIZE(rk3288_mux_route_data),
>   .set_mux= rk3288_set_mux,
>   .pull_calc_reg  = rk3288_calc_pull_reg_and_bit,
> - .drv_calc_reg  

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

[Marek Vasut]

The following changes since commit 86f578ee85a697afb980233312f9aac1d98816df:

  Merge tag 'mips-pull-2019-05-03' of git://git.denx.de/u-boot-mips
(2019-05-04 20:02:42 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 32e308dd796f34f85d1c088e3218fa3403a9080f:

  ARM: socfpga: stratix10: Probe FPGA status before bridge enable
(2019-05-06 12:44:45 +0200)


Ang, Chee Hong (2):
  ARM: socfpga: stratix10: Disable FPGA2SOC reset
  ARM: socfpga: stratix10: Probe FPGA status before bridge enable

Ley Foon Tan (3):
  ddr: altera: Compile ALTERA SDRAM in SPL only
  arm: dts: Stratix10: Add SDRAM node
  arm: socfpga: Move Stratix 10 SDRAM driver to DM

 Makefile
|   2 +-
 arch/arm/dts/socfpga_stratix10.dtsi
|   9 +
 arch/arm/mach-socfpga/Kconfig
|   4 +-
 arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
|   2 +
 arch/arm/mach-socfpga/misc_s10.c
|  12 ++
 arch/arm/mach-socfpga/reset_manager_s10.c
|   7 ++--
 arch/arm/mach-socfpga/spl_s10.c
|  16 +---
 configs/socfpga_stratix10_defconfig
|   1 +
 drivers/Makefile
|   2 +-
 drivers/ddr/altera/Kconfig
|  11 +++---
 drivers/ddr/altera/Makefile
|   2 +-
 drivers/ddr/altera/sdram_s10.c
| 243

 {arch/arm/mach-socfpga/include/mach => drivers/ddr/altera}/sdram_s10.h
|   4 --
 include/configs/socfpga_stratix10_socdk.h
|   5 ---
 14 files changed, 218 insertions(+), 102 deletions(-)
 rename {arch/arm/mach-socfpga/include/mach =>
drivers/ddr/altera}/sdram_s10.h (97%)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/10] pinctrl: rockchip: Split the common set_mux() into per Soc

[Kever Yang]

On 04/16/2019 09:50 PM, David Wu wrote:
> Such as rk3288's pins of pmu_gpio0 are a special feature, which have no
> higher 16 writing corresponding bits, use common set_mux() func would
> introduce more code, so implement their set_mux() in each Soc's own
> file to reduce the size of code.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3036.c | 25 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3128.c | 37 +
>  drivers/pinctrl/rockchip/pinctrl-rk3188.c | 25 +++
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c | 34 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 35 +++-
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 37 +
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c | 25 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c | 34 +++
>  .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 41 +--
>  drivers/pinctrl/rockchip/pinctrl-rockchip.h   |  8 
>  drivers/pinctrl/rockchip/pinctrl-rv1108.c | 28 +
>  11 files changed, 297 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3036.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> index 2a651cd9b8..8969aea2e3 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> @@ -11,6 +11,30 @@
>  
>  #include "pinctrl-rockchip.h"
>  
> +static int rk3036_set_mux(struct rockchip_pin_bank *bank, int pin, int mux)
> +{
> + struct rockchip_pinctrl_priv *priv = bank->priv;
> + int iomux_num = (pin / 8);
> + struct regmap *regmap;
> + int reg, ret, mask, mux_type;
> + u8 bit;
> + u32 data;
> +
> + regmap = (bank->iomux[iomux_num].type & IOMUX_SOURCE_PMU)
> + ? priv->regmap_pmu : priv->regmap_base;
> +
> + /* get basic quadrupel of mux registers and the correct reg inside */
> + mux_type = bank->iomux[iomux_num].type;
> + reg = bank->iomux[iomux_num].offset;
> + reg += rockchip_get_mux_data(mux_type, pin, , );
> +
> + data = (mask << (bit + 16));
> + data |= (mux & mask) << bit;
> + ret = regmap_write(regmap, reg, data);
> +
> + return ret;
> +}
> +
>  #define RK3036_PULL_OFFSET   0x118
>  #define RK3036_PULL_PINS_PER_REG 16
>  #define RK3036_PULL_BANK_STRIDE  8
> @@ -41,6 +65,7 @@ static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
>   .label  = "RK3036-GPIO",
>   .type   = RK3036,
>   .grf_mux_offset = 0xa8,
> + .set_mux= rk3036_set_mux,
>   .pull_calc_reg  = rk3036_calc_pull_reg_and_bit,
>  };
>  
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3128.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> index 43a6c173a0..de203334c7 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3128.c
> @@ -98,6 +98,42 @@ static struct rockchip_mux_route_data 
> rk3128_mux_route_data[] = {
>   },
>  };
>  
> +static int rk3128_set_mux(struct rockchip_pin_bank *bank, int pin, int mux)
> +{
> + struct rockchip_pinctrl_priv *priv = bank->priv;
> + int iomux_num = (pin / 8);
> + struct regmap *regmap;
> + int reg, ret, mask, mux_type;
> + u8 bit;
> + u32 data, route_reg, route_val;
> +
> + regmap = (bank->iomux[iomux_num].type & IOMUX_SOURCE_PMU)
> + ? priv->regmap_pmu : priv->regmap_base;
> +
> + /* get basic quadrupel of mux registers and the correct reg inside */
> + mux_type = bank->iomux[iomux_num].type;
> + reg = bank->iomux[iomux_num].offset;
> + reg += rockchip_get_mux_data(mux_type, pin, , );
> +
> + if (bank->recalced_mask & BIT(pin))
> + rockchip_get_recalced_mux(bank, pin, , , );
> +
> + if (bank->route_mask & BIT(pin)) {
> + if (rockchip_get_mux_route(bank, pin, mux, _reg,
> +_val)) {
> + ret = regmap_write(regmap, route_reg, route_val);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + data = (mask << (bit + 16));
> + data |= (mux & mask) << bit;
> + ret = regmap_write(regmap, reg, data);
> +
> + return ret;
> +}
> +
>  #define RK3128_PULL_OFFSET   0x118
>  #define RK3128_PULL_PINS_PER_REG 16
>  #define RK3128_PULL_BANK_STRIDE  8
> @@ -133,6 +169,7 @@ static struct rockchip_pin_ctrl rk3128_pin_ctrl = {
>   .niomux_recalced= ARRAY_SIZE(rk3128_mux_recalced_data),
>   .iomux_routes   = rk3128_mux_route_data,
>   .niomux_routes  = ARRAY_SIZE(rk3128_mux_route_data),
> + .set_mux= rk3128_set_mux,
>   .pull_calc_reg  = rk3128_calc_pull_reg_and_bit,
>  };
>  
> diff --git 

Re: [U-Boot] [PATCH v3 02/10] pinctrl: rockchip: Remove redundant spaces

[Kever Yang]

On 04/16/2019 09:50 PM, David Wu wrote:
> Some files have the redundant spaces, remove them.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - None
>
>  drivers/pinctrl/rockchip/pinctrl-rk3036.c | 12 ++--
>  drivers/pinctrl/rockchip/pinctrl-rk3188.c | 12 ++--
>  drivers/pinctrl/rockchip/pinctrl-rk322x.c | 18 -
>  drivers/pinctrl/rockchip/pinctrl-rk3288.c | 20 +--
>  drivers/pinctrl/rockchip/pinctrl-rk3328.c | 24 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3368.c | 16 +++
>  drivers/pinctrl/rockchip/pinctrl-rk3399.c | 24 +++
>  7 files changed, 63 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3036.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> index 2729b03443..2a651cd9b8 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3036.c
> @@ -36,12 +36,12 @@ static struct rockchip_pin_bank rk3036_pin_banks[] = {
>  };
>  
>  static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
> - .pin_banks  = rk3036_pin_banks,
> - .nr_banks   = ARRAY_SIZE(rk3036_pin_banks),
> - .label  = "RK3036-GPIO",
> - .type   = RK3036,
> - .grf_mux_offset = 0xa8,
> - .pull_calc_reg  = rk3036_calc_pull_reg_and_bit,
> + .pin_banks  = rk3036_pin_banks,
> + .nr_banks   = ARRAY_SIZE(rk3036_pin_banks),
> + .label  = "RK3036-GPIO",
> + .type   = RK3036,
> + .grf_mux_offset = 0xa8,
> + .pull_calc_reg  = rk3036_calc_pull_reg_and_bit,
>  };
>  
>  static const struct udevice_id rk3036_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3188.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> index 5ed9aec938..7cc52c0075 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3188.c
> @@ -55,12 +55,12 @@ static struct rockchip_pin_bank rk3188_pin_banks[] = {
>  };
>  
>  static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
> - .pin_banks  = rk3188_pin_banks,
> - .nr_banks   = ARRAY_SIZE(rk3188_pin_banks),
> - .label  = "RK3188-GPIO",
> - .type   = RK3188,
> - .grf_mux_offset = 0x60,
> - .pull_calc_reg  = rk3188_calc_pull_reg_and_bit,
> + .pin_banks  = rk3188_pin_banks,
> + .nr_banks   = ARRAY_SIZE(rk3188_pin_banks),
> + .label  = "RK3188-GPIO",
> + .type   = RK3188,
> + .grf_mux_offset = 0x60,
> + .pull_calc_reg  = rk3188_calc_pull_reg_and_bit,
>  };
>  
>  static const struct udevice_id rk3188_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk322x.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> index d2a6cd7055..d67b48a06a 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk322x.c
> @@ -183,15 +183,15 @@ static struct rockchip_pin_bank rk3228_pin_banks[] = {
>  };
>  
>  static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
> - .pin_banks  = rk3228_pin_banks,
> - .nr_banks   = ARRAY_SIZE(rk3228_pin_banks),
> - .label  = "RK3228-GPIO",
> - .type   = RK3288,
> - .grf_mux_offset = 0x0,
> - .iomux_routes   = rk3228_mux_route_data,
> - .niomux_routes  = ARRAY_SIZE(rk3228_mux_route_data),
> - .pull_calc_reg  = rk3228_calc_pull_reg_and_bit,
> - .drv_calc_reg   = rk3228_calc_drv_reg_and_bit,
> + .pin_banks  = rk3228_pin_banks,
> + .nr_banks   = ARRAY_SIZE(rk3228_pin_banks),
> + .label  = "RK3228-GPIO",
> + .type   = RK3288,
> + .grf_mux_offset = 0x0,
> + .iomux_routes   = rk3228_mux_route_data,
> + .niomux_routes  = ARRAY_SIZE(rk3228_mux_route_data),
> + .pull_calc_reg  = rk3228_calc_pull_reg_and_bit,
> + .drv_calc_reg   = rk3228_calc_drv_reg_and_bit,
>  };
>  
>  static const struct udevice_id rk3228_pinctrl_ids[] = {
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 60585f3208..3648f37207 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -124,16 +124,16 @@ static struct rockchip_pin_bank rk3288_pin_banks[] = {
>  };
>  
>  static struct rockchip_pin_ctrl rk3288_pin_ctrl = {
> - .pin_banks  = rk3288_pin_banks,
> - .nr_banks   = 

Re: [U-Boot] [PATCH v3 01/10] pinctrl: rockchip: Add pull-pin-default param and remove unused param

[Kever Yang]

On 04/16/2019 09:50 PM, David Wu wrote:
> Some Socs use the pull-pin-default config param, need to add it.
> And input-enable/disable config params are not necessary, remove it.
>
> Signed-off-by: David Wu 

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>
> Change in v3:
> - Add some commit message
>
>  drivers/pinctrl/rockchip/pinctrl-rockchip-core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
> b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> index b84b079064..77ac981c40 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> @@ -509,9 +509,8 @@ static const struct pinconf_param rockchip_conf_params[] 
> = {
>   { "bias-bus-hold", PIN_CONFIG_BIAS_BUS_HOLD, 0 },
>   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
>   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
> + { "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 1 },
>   { "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
> - { "input-enable", PIN_CONFIG_INPUT_ENABLE, 1 },
> - { "input-disable", PIN_CONFIG_INPUT_ENABLE, 0 },
>   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
>   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
>  };



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

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Marek Vasut]

On 5/7/19 5:28 AM, Ang, Chee Hong wrote:
> On Fri, 2019-05-03 at 21:31 +0200, Marek Vasut wrote:
>> On 5/3/19 7:56 PM, Ang, Chee Hong wrote:
>>>
>>> On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:

 On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
>
>
> On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
>>
>>
>> On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
>>>
>>>
>>>
>>> From: "Ang, Chee Hong" 
>> Commit message is missing -- why do you need to enable the
>> DMA330
>> ?
>>
>> Don't you have a reset driver, like A10 and Gen5 ?
> DMA driver for S10 is still missing in u-boot. I need to enable
> this
> for booting Linux which is required by Linux's DMA driver.
> I will add the reason to enable DMA330 in the commit message.
 Can you also answer my question regarding the reset driver ?
>>> Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.
>> So why don't you use it ? :-)
> Since our u-boot don't have DMA330 driver, I am going to drop this
> patch and let Linux DMA driver take care of the reset. Thanks.

That sounds like a good idea -- only enable peripherals when they are
really needed.

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

Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller

[Ang, Chee Hong]

On Fri, 2019-05-03 at 21:31 +0200, Marek Vasut wrote:
> On 5/3/19 7:56 PM, Ang, Chee Hong wrote:
> > 
> > On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:
> > > 
> > > On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
> > > > 
> > > > 
> > > > On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: "Ang, Chee Hong" 
> > > > > Commit message is missing -- why do you need to enable the
> > > > > DMA330
> > > > > ?
> > > > > 
> > > > > Don't you have a reset driver, like A10 and Gen5 ?
> > > > DMA driver for S10 is still missing in u-boot. I need to enable
> > > > this
> > > > for booting Linux which is required by Linux's DMA driver.
> > > > I will add the reason to enable DMA330 in the commit message.
> > > Can you also answer my question regarding the reset driver ?
> > Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.
> So why don't you use it ? :-)
Since our u-boot don't have DMA330 driver, I am going to drop this
patch and let Linux DMA driver take care of the reset. Thanks.
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Signed-off-by: Ang, Chee Hong 
> > > > > > ---
> > > > > >  arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1
> > > > > > +
> > > > > >  arch/arm/mach-socfpga/spl_s10.c| 4
> > > > > > 
> > > > > >  2 files changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h 
> > > > > > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > > > index e186296..3ac46c3 100644
> > > > > > --- a/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h
> > > > > > +++ b/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h
> > > > > > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> > > > > >  #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> > > > > >  #define RSTMGR_SPIM0   RSTMGR_DEFINE(1, 17)
> > > > > >  #define RSTMGR_SPIM1   RSTMGR_DEFINE(1, 18)
> > > > > > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> > > > > >  #define RSTMGR_L4WD0   RSTMGR_DEFINE(2, 0)
> > > > > >  #define RSTMGR_L4WD1   RSTMGR_DEFINE(2, 1)
> > > > > >  #define RSTMGR_L4WD2   RSTMGR_DEFINE(2, 2)
> > > > > > diff --git a/arch/arm/mach-socfpga/spl_s10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/spl_s10.c
> > > > > > index a141ffe..e063229 100644
> > > > > > --- a/arch/arm/mach-socfpga/spl_s10.c
> > > > > > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > > > > > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> > > > > >     writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > > > > > _regs->dma);
> > > > > >     writel(SYSMGR_DMAPERIPH_ALL_NS, _regs-
> > > > > > > 
> > > > > > > dma_periph);
> > > > > >  
> > > > > > +   /* enable DMA330 DMA */
> > > > > > +   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > > > > > +   socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > > > > > +
> > > > > >     spl_disable_firewall_l4_per();
> > > > > >  
> > > > > >     spl_disable_firewall_l4_sys();
> > > > > > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [patch v3 3/3] defconfig: ls1028ardb: enable wdt

[Qiang Zhao]

Enable watchdog which is sp805, can be found on some NXP
Layerscape SoC.

Signed-off-by: Zhao Qiang 
---
 configs/ls1028ardb_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/ls1028ardb_defconfig b/configs/ls1028ardb_defconfig
index e3ff21f10c..5edcaae24b 100644
--- a/configs/ls1028ardb_defconfig
+++ b/configs/ls1028ardb_defconfig
@@ -70,3 +70,6 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCI_PNP=y
 CONFIG_DM_MMC=y
+CONFIG_WDT_SP805=y
+CONFIG_WDT=y
+CONFIG_CMD_WDT=y
-- 
2.17.1

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

[U-Boot] [patch v3 1/3] watchdog: add sp805 watchdog support

[Qiang Zhao]

sp805 is watchdog on some NXP layerscape SoCs, Now add its driver in uboot.
To add
CONFIG_WDT_SP805=y
CONFIG_WDT=y
CONFIG_CMD_WDT=y
in defconfig to use it.

Signed-off-by: Zhao Qiang 
---
 MAINTAINERS  |   1 +
 drivers/watchdog/Kconfig |   7 ++
 drivers/watchdog/Makefile|   1 +
 drivers/watchdog/sp805_wdt.c | 127 +++
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/watchdog/sp805_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8f237128b2..e8e7a92802 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -410,6 +410,7 @@ FREESCALE QORIQ
 M: York Sun 
 S: Maintained
 T: git git://git.denx.de/u-boot-fsl-qoriq.git
+F: drivers/watchdog/sp805_wdt.c
 
 I2C
 M: Heiko Schocher 
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b06c5447f6..29e04630d2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config WDT_ORION
   Select this to enable Orion watchdog timer, which can be found on 
some
   Marvell Armada chips.
 
+config WDT_SP805
+   bool "SP805 watchdog timer support"
+   depends on WDT
+   help
+  Select this to enable SP805 watchdog timer, which can be found on 
some
+  nxp layerscape chips.
+
 config WDT_CDNS
bool "Cadence watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 19c631bb58..eb285bde24 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_BCM2835_WDT)   += bcm2835_wdt.o
 obj-$(CONFIG_WDT_ORION) += orion_wdt.o
 obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
 obj-$(CONFIG_MPC8xx_WATCHDOG) += mpc8xx_wdt.o
+obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
new file mode 100644
index 00..966128216f
--- /dev/null
+++ b/drivers/watchdog/sp805_wdt.c
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Watchdog driver for SP805 on some Layerscape SoC
+ *
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDTLOAD0x000
+#define WDTCONTROL 0x008
+#define WDTINTCLR  0x00C
+#define WDTLOCK0xC00
+
+#define TIME_OUT_MIN_MSECS 1
+#define TIME_OUT_MAX_MSECS 12
+#define SYS_FSL_WDT_CLK_DIV16
+#define INT_ENABLE BIT(0)
+#define RESET_ENABLE   BIT(1)
+#define DISABLE0
+#define UNLOCK 0x1ACCE551
+#define LOCK   0x0001
+#define INT_MASK   BIT(0)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sp805_wdt_priv {
+   void __iomem *reg;
+};
+
+static int sp805_wdt_reset(struct udevice *dev)
+{
+   struct sp805_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(UNLOCK, priv->reg + WDTLOCK);
+   writel(INT_MASK, priv->reg + WDTINTCLR);
+   writel(LOCK, priv->reg + WDTLOCK);
+   readl(priv->reg + WDTLOCK);
+
+   return 0;
+}
+
+static int sp805_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   u32 load_value;
+   u32 load_time;
+   struct sp805_wdt_priv *priv = dev_get_priv(dev);
+
+   load_time = (u32)timeout;
+   if (timeout < TIME_OUT_MIN_MSECS)
+   load_time = TIME_OUT_MIN_MSECS;
+   else if (timeout > TIME_OUT_MAX_MSECS)
+   load_time = TIME_OUT_MAX_MSECS;
+   /* sp805 runs counter with given value twice, so when the max timeout is
+* set 120s, the gd->bus_clk is less than 1145MHz, the load_value will
+* not overflow.
+*/
+   load_value = (gd->bus_clk) /
+   (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
+
+   writel(UNLOCK, priv->reg + WDTLOCK);
+   writel(load_value, priv->reg + WDTLOAD);
+   writel(INT_MASK, priv->reg + WDTINTCLR);
+   writel(INT_ENABLE | RESET_ENABLE, priv->reg + WDTCONTROL);
+   writel(LOCK, priv->reg + WDTLOCK);
+   readl(priv->reg + WDTLOCK);
+
+   return 0;
+}
+
+static int sp805_wdt_stop(struct udevice *dev)
+{
+   struct sp805_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(UNLOCK, priv->reg + WDTLOCK);
+   writel(DISABLE, priv->reg + WDTCONTROL);
+   writel(LOCK, priv->reg + WDTLOCK);
+   readl(priv->reg + WDTLOCK);
+
+   return 0;
+}
+
+static int sp805_wdt_probe(struct udevice *dev)
+{
+   debug("%s: Probing wdt%u\n", __func__, dev->seq);
+
+   return 0;
+}
+
+static int sp805_wdt_ofdata_to_platdata(struct udevice *dev)
+{
+   struct sp805_wdt_priv *priv = dev_get_priv(dev);
+
+   priv->reg = (void __iomem *)dev_read_addr(dev);
+   if (IS_ERR(priv->reg))
+   return PTR_ERR(priv->reg);
+
+   return 0;
+}
+
+static const struct wdt_ops sp805_wdt_ops = {
+   .start = sp805_wdt_start,
+   .reset = sp805_wdt_reset,
+   

[U-Boot] [patch v3 2/3] dts: fsl-ls1028a: add sp805 node which is a watchdog

[Qiang Zhao]

add sp805 nodes in fsl-ls1028a.dtsi

Signed-off-by: Zhao Qiang 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 35382eb3b4..30fb20cd3e 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -338,4 +338,8 @@
status = "disabled";
  };
 
+   cluster1_core0_watchdog: wdt@c00 {
+   compatible = "arm,sp805-wdt";
+   reg = <0x0 0xc00 0x0 0x1000>;
+   };
 };
-- 
2.17.1

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

[U-Boot] [PATCH 0/3] add new wdt driver for sp805

[Qiang Zhao]

changes for v2:
- modify the driver to DM
changes for v3:
- drop member "timeout" of struct "sp805_wat_priv", it is not
  needed

Zhao Qiang (3):
  watchdog: add sp805 watchdog support
  dts: fsl-ls1028a: add sp805 node which is a watchdog
  defconfig: ls1028ardb: enable wdt

 MAINTAINERS   |   1 +
 arch/arm/dts/fsl-ls1028a.dtsi |   4 ++
 configs/ls1028ardb_defconfig  |   3 +
 drivers/watchdog/Kconfig  |   7 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/sp805_wdt.c  | 126 ++
 6 files changed, 142 insertions(+)
 create mode 100644 drivers/watchdog/sp805_wdt.c

-- 
2.17.1

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

Re: [U-Boot] [PATCH 1/4] efi_loader: mark started images

[Takahiro Akashi]

On Sat, May 04, 2019 at 10:36:33AM +0200, Heinrich Schuchardt wrote:
> In UnloadImage() we need to know if an image is already started.
> 
> Add a field to the handle structure identifying loaded and started images.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  | 13 +
>  lib/efi_loader/efi_boottime.c |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3fd9901d66..c2a449e5b6 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -182,6 +182,18 @@ struct efi_handler {
>   struct list_head open_infos;
>  };
> 
> +/**
> + * enum efi_object_type - type of EFI object
> + *
> + * In UnloadImage we must be able to identify if the handle relates to a
> + * started image.
> + */
> +enum efi_object_type {
> + EFI_OBJECT_TYPE_UNDEFINED = 0,
> + EFI_OBJECT_TYPE_LOADED_IMAGE,
> + EFI_OBJECT_TYPE_STARTED_IMAGE,
> +};

It sounds *status*, not *type*.
In a separate patch, you added U_BOOT_FIRMWARE.
We should distinguish status and type for future enhancement and
to avoid any confusion.

Thanks,
-Takahiro Akashi


>  /**
>   * struct efi_object - dereferenced EFI handle
>   *
> @@ -204,6 +216,7 @@ struct efi_object {
>   struct list_head link;
>   /* The list of protocols */
>   struct list_head protocols;
> + enum efi_object_type type;
>  };
> 
>  /**
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 3ed08e7c37..dc444fccf6 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1554,6 +1554,7 @@ efi_status_t efi_setup_loaded_image(struct 
> efi_device_path *device_path,
>   free(info);
>   return EFI_OUT_OF_RESOURCES;
>   }
> + obj->header.type = EFI_OBJECT_TYPE_LOADED_IMAGE;
> 
>   /* Add internal object to object list */
>   efi_add_handle(>header);
> @@ -2678,6 +2679,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
> image_handle,
>   }
> 
>   current_image = image_handle;
> + image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
>   EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
>   ret = EFI_CALL(image_obj->entry(image_handle, ));
> 
> --
> 2.20.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: [ARMv8] kernel entry point

[Pankaj Bansal]

Hi Tom,

In order to determine whether linux entry point has been called or not, I put a 
loop in kernel:

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 261f3f88364c..dea6cb8baa6a 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -80,6 +80,7 @@ _head:
 * its opcode forms the magic "MZ" signature required by UEFI.
 */
add x13, x18, #0x16
+   b   .
b   stext
 #else
b   stext   // branch to kernel start, magic

This loop is being executed when I boot the kernel, but after I jump over this 
loop there is no log.
Does it mean that bootloader is working fine, it's the linux that is not able 
to boot from 0x8100 (0x8000 being the RAM starting address) ?

Regards,
Pankaj Bansal

> -Original Message-
> From: Pankaj Bansal
> Sent: Monday, 6 May, 2019 07:04 PM
> To: Tom Rini 
> Cc: u-boot@lists.denx.de; Prabhakar Kushwaha
> ; Varun Sethi 
> Subject: RE: [EXT] Re: [ARMv8] kernel entry point
> 
> 
> 
> > -Original Message-
> > From: Tom Rini 
> > Sent: Monday, 6 May, 2019 06:59 PM
> > To: Pankaj Bansal 
> > Cc: u-boot@lists.denx.de; Prabhakar Kushwaha
> > ; Varun Sethi 
> > Subject: [EXT] Re: [ARMv8] kernel entry point
> >
> > On Mon, May 06, 2019 at 01:06:45PM +, Pankaj Bansal wrote:
> >
> > > Hi Tom et. Al,
> > >
> > > I am facing an issue while booting linux on our ARMv8 based platform.
> > > In our platform DDR address starts from 0x8000.
> > > If I make the linux kernel entry point 0x8008 in mkimage, then
> > > linux boots
> > fine.
> > > BUT, if I make the linux image entry point as 0x8100 in mkimage,
> > > the
> > kernel doesn't boot.
> > >
> > > => bootm 0xa000 - 0xa100
> > > ## Current stack ends at 0xfbb24400 ## Booting kernel from Legacy
> > > Image at
> > a000 ...
> > >Image Name:   linux
> > >Image Type:   AArch64 Linux Kernel Image (gzip compressed)
> > >Data Size:9110442 Bytes = 8.7 MiB
> > >Load Address: 8100
> > >Entry Point:  8100
> > >Verifying Checksum ... OK
> > > ## Flattened Device Tree blob at a100
> > >Booting using the fdt blob at 0xa100
> > >Uncompressing Kernel Image ... OK
> > > using: FDT
> > >reserving fdt memory region: addr=8000 size=1
> > >Loading Device Tree to 9fff6000, end 92f8 ...
> > > OK ## Transferring control to Linux (at address 8100)...
> > >
> > > Starting kernel ...
> > >
> > > I get no kernel logs after this. I am failing to understand why.
> > > Can you please help me in debugging this issue?
> >
> > Why are you using a legacy image on AArch64 at all?  You should be
> > using either the kernel Image (and booti) or a FIT image.
> 
> This issue is coming even if I use FIT image.
> 
> => bootm 0xa000#lx2160ardb
> ## Current stack ends at 0xfbb24400 ## Loading kernel from FIT Image at
> a000 ...
>Using 'lx2160ardb' configuration
>Trying 'kernel' kernel subimage
>  Description:  ARM64 Kernel
>  Type: Kernel Image
>  Compression:  gzip compressed
>  Data Start:   0xa0d0
>  Data Size:9110442 Bytes = 8.7 MiB
>  Architecture: AArch64
>  OS:   Linux
>  Load Address: 0x8100
>  Entry Point:  0x8100
>  Hash algo:crc32
>  Hash value:   39f59891
>Verifying Hash Integrity ... crc32+ OK ## Loading ramdisk from FIT Image at
> a000 ...
>Using 'lx2160ardb' configuration
>Trying 'initrd' ramdisk subimage
>  Description:  initrd for arm64
>  Type: RAMDisk Image
>  Compression:  uncompressed
>  Data Start:   0xa08b055c
>  Data Size:29171975 Bytes = 27.8 MiB
>  Architecture: AArch64
>  OS:   Linux
>  Load Address: 0x
>  Entry Point:  0x
>  Hash algo:crc32
>  Hash value:   23038325
>Verifying Hash Integrity ... crc32+ OK ## Loading fdt from FIT Image at
> a000 ...
>Using 'lx2160ardb' configuration
>Trying 'lx2160ardb-dtb' fdt subimage
>  Description:  lx2160ardb-dtb
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0xa249071c
>  Data Size:25337 Bytes = 24.7 KiB
>  Architecture: AArch64
>  Load Address: 0x9000
>  Hash algo:crc32
>  Hash value:   8e4d595f
>Verifying Hash Integrity ... crc32+ OK
>Loading fdt from 0xa249071c to 0x9000
>Booting using the fdt blob at 0x9000
>Uncompressing Kernel Image ... OK
> using: FDT
>reserving fdt memory region: addr=8000 size=1
>Loading Device Tree to 9fff6000, end 92f8 ... OK ##
> Transferring control to Linux (at address 8100)...
> 
> Starting kernel ...
> 
> 
> >
> > --
> > Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Tom Rini]

On Sun, May 05, 2019 at 10:12:24PM +0530, Jagan Teki wrote:

> Hi Tom, 
> 
> Please pull this spi-mem fix.
> 
> thanks,
> Jagan.
> 
> The following changes since commit b4ee6daad7a2604ca9466b2ba48de86cc27d381f:
> 
>   Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx (2019-05-01 
> 07:25:51 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 60e2bf46784ebbd30ff29b3d3c7c97e56b11e86a:
> 
>   mtd: spi-nor: fix page program issue when using spi-mem driver (2019-05-03 
> 15:26:12 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Sun, May 05, 2019 at 09:18:04PM +0200, Marek Vasut wrote:

> The following changes since commit 4862830b696a6d0750e19d32a82553cdb41a85f8:
> 
>   Merge git://git.denx.de/u-boot-socfpga (2019-05-03 14:23:01 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 41e30dcf87962e4bcc8d4197b3d808af14f71e92:
> 
>   cmd: mmc: Make Mode: printout consistent (2019-05-04 19:26:49 +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] [PATCH 7/8] rockchip: rk3288: convert rk3288-evb to use tpl

[Kever Yang]

Heiko,


On 04/05/2019 04:30 PM, Heiko Stuebner wrote:
> We want to use ATF loaded by the SPL, so need support for the itb FIT
> in SPL which therefore needs real mmc reading capabilities making it
> too big for the sram. So convert to use TPL for memory init beforehand
> similar to rk3288-vyasa.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/mach-rockchip/Kconfig | 1 +
>  arch/arm/mach-rockchip/rk3288/Kconfig  | 1 +
>  board/rockchip/evb_rk3288/evb-rk3288.c | 4 
>  configs/evb-rk3288-act8846_defconfig   | 3 +--
>  configs/evb-rk3288-rk808_defconfig | 3 +--
>  5 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index ba11e8a497..bfcf12d1ab 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -188,6 +188,7 @@ config SPL_ROCKCHIP_BACK_TO_BROM
>  
>  config TPL_ROCKCHIP_BACK_TO_BROM
>   bool "TPL returns to bootrom"
> + default y if ROCKCHIP_RK3288

This TPL_ROCKCHIP_BACK_TO_BROM should be default y to all SoCs,
has apply in another patch from me, please rebase this patch.

Thanks,
- Kever
>   default y if ROCKCHIP_RK3368
>   select ROCKCHIP_BROM_HELPER
>   depends on TPL
> diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig 
> b/arch/arm/mach-rockchip/rk3288/Kconfig
> index 936faf75ca..800902a683 100644
> --- a/arch/arm/mach-rockchip/rk3288/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3288/Kconfig
> @@ -44,6 +44,7 @@ config TARGET_CHROMEBOOK_SPEEDY
>  config TARGET_EVB_RK3288
>   bool "Evb-RK3288"
>   select BOARD_LATE_INIT
> + select TPL
>   help
> EVB-RK3288 is a RK3288-based development board with 2 USB ports,
> HDMI, VGA, micro-SD card, audio, WiFi  and Gigabit Ethernet, It
> diff --git a/board/rockchip/evb_rk3288/evb-rk3288.c 
> b/board/rockchip/evb_rk3288/evb-rk3288.c
> index d6992a26ca..ec1d03c86c 100644
> --- a/board/rockchip/evb_rk3288/evb-rk3288.c
> +++ b/board/rockchip/evb_rk3288/evb-rk3288.c
> @@ -3,6 +3,8 @@
>   * (C) Copyright 2016 Rockchip Electronics Co., Ltd
>   */
>  
> +#ifndef CONFIG_TPL_BUILD
> +
>  #include 
>  #include 
>  
> @@ -12,3 +14,5 @@ void board_boot_order(u32 *spl_boot_list)
>   spl_boot_list[0] = BOOT_DEVICE_MMC2;
>   spl_boot_list[1] = BOOT_DEVICE_MMC1;
>  }
> +
> +#endif
> \ No newline at end of file
> diff --git a/configs/evb-rk3288-act8846_defconfig 
> b/configs/evb-rk3288-act8846_defconfig
> index 878367dea9..9c7be78ad7 100644
> --- a/configs/evb-rk3288-act8846_defconfig
> +++ b/configs/evb-rk3288-act8846_defconfig
> @@ -1,9 +1,8 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_ROCKCHIP=y
> -CONFIG_SYS_TEXT_BASE=0x
> +CONFIG_SYS_TEXT_BASE=0x0010
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_ROCKCHIP_RK3288=y
> -CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
>  CONFIG_TARGET_EVB_RK3288=y
>  CONFIG_DEBUG_UART_BASE=0xff69
>  CONFIG_DEBUG_UART_CLOCK=2400
> diff --git a/configs/evb-rk3288-rk808_defconfig 
> b/configs/evb-rk3288-rk808_defconfig
> index 0cc1b2f601..73d30c9958 100644
> --- a/configs/evb-rk3288-rk808_defconfig
> +++ b/configs/evb-rk3288-rk808_defconfig
> @@ -1,9 +1,8 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_ROCKCHIP=y
> -CONFIG_SYS_TEXT_BASE=0x
> +CONFIG_SYS_TEXT_BASE=0x0010
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_ROCKCHIP_RK3288=y
> -CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
>  CONFIG_TARGET_EVB_RK3288=y
>  CONFIG_DEBUG_UART_BASE=0xff69
>  CONFIG_DEBUG_UART_CLOCK=2400



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

Re: [U-Boot] [PATCH 5/8] rockchip: rk3288: reserve first 2MB when build with ATF support

[Kever Yang]

Heiko,


On 04/05/2019 04:30 PM, Heiko Stuebner wrote:
> ATF resides in the first 2MB of ram and will also protect this
> area from non-secure access.
>
> So similar to other Rockchip socs keep this area from the usable ram.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/mach-rockchip/rk3288/rk3288.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
> b/arch/arm/mach-rockchip/rk3288/rk3288.c
> index a725abc5a5..678ab0de65 100644
> --- a/arch/arm/mach-rockchip/rk3288/rk3288.c
> +++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
> @@ -2,11 +2,27 @@
>  /*
>   * Copyright (c) 2016 Rockchip Electronics Co., Ltd
>   */
> +#include 
>  #include 
>  #include 
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  #define GRF_SOC_CON2 0xff77024c
>  
> +int dram_init_banksize(void)

This break the build for vyasa-rk3288 board:
arm:  +   vyasa-rk3288+spl/arch/arm/mach-rockchip/rk3288-board-spl.o: In
function
`dram_init_banksize':+arch/arm/mach-rockchip/rk3288-board-spl.c:208:
multiple definition of
`dram_init_banksize'+spl/arch/arm/mach-rockchip/rk3288/built-in.o:arch/arm/mach-rockchip/rk3288/rk3288.c:25:
first defined here

Thanks,
- Kever
> +{
> +#ifdef CONFIG_SPL_ATF
> + size_t max_size = min((unsigned long)gd->ram_size, gd->ram_top);
> +
> + /* Reserve 0x20 for ATF bl32 */
> + gd->bd->bi_dram[0].start = 0x020;
> + gd->bd->bi_dram[0].size = max_size - gd->bd->bi_dram[0].start;
> +#endif
> +
> + return 0;
> +}
> +
>  int arch_cpu_init(void)
>  {
>   /* We do some SoC one time setting here. */



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

Re: [U-Boot] [PATCH 8/8] rockchip: rk3288: make both evb variants use atf

[Kever Yang]

Hi Heiko,


On 04/05/2019 04:30 PM, Heiko Stuebner wrote:
> Enable both rk3288-evb variants to load an ATF binary between
> spl and u-boot proper.

Does this the same as aarch64 boot/load flow?
tpl->spl->atf->u-boot

>
> Doing the regular spl->u-boot load of course still stays possible
> with this change.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  board/rockchip/evb_rk3288/evb-rk3288.c| 12 +-
>  board/rockchip/evb_rk3288/fit_spl_atf.its | 52 +++

Is it possible to re-use arch/arm/mach-rockchip/make_fit_atf.py?

>  configs/evb-rk3288-act8846_defconfig  |  9 +++-
>  configs/evb-rk3288-rk808_defconfig|  9 +++-
>  4 files changed, 77 insertions(+), 5 deletions(-)
>  create mode 100644 board/rockchip/evb_rk3288/fit_spl_atf.its
>
> diff --git a/board/rockchip/evb_rk3288/evb-rk3288.c 
> b/board/rockchip/evb_rk3288/evb-rk3288.c
> index ec1d03c86c..05aea66db6 100644
> --- a/board/rockchip/evb_rk3288/evb-rk3288.c
> +++ b/board/rockchip/evb_rk3288/evb-rk3288.c
> @@ -15,4 +15,14 @@ void board_boot_order(u32 *spl_boot_list)
>   spl_boot_list[1] = BOOT_DEVICE_MMC1;
>  }
>  
> -#endif
> \ No newline at end of file
> +#endif
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + /* Just empty function now - can't decide what to choose */
> + debug("%s: %s\n", __func__, name);
> +
> + return 0;
> +}
> +#endif
> diff --git a/board/rockchip/evb_rk3288/fit_spl_atf.its 
> b/board/rockchip/evb_rk3288/fit_spl_atf.its
> new file mode 100644
> index 00..67aff095d6
> --- /dev/null
> +++ b/board/rockchip/evb_rk3288/fit_spl_atf.its
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0+ OR X11 */
> +/*
> + * Copyright (C) 2017 Theobroma Systems Design und Consulting GmbH
> + *
> + * Minimal dts for a SPL FIT image payload.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + description = "FIT image with U-Boot proper, ATF bl32, DTB";

Why you name the ATF bl32, isn't it bl31?

Thanks,
- Kever
> + #address-cells = <1>;
> +
> + images {
> + uboot {
> + description = "U-Boot (64-bit)";
> + data = /incbin/("../../../u-boot-nodtb.bin");
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = <0x0020>;
> + };
> + atf {
> + description = "ARM Trusted Firmware";
> + data = /incbin/("../../../bl32-rk3288.bin");
> + type = "firmware";
> + os = "arm-trusted-firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <0x0010>;
> + entry = <0x0010>;
> + };
> +
> + fdt {
> + description = "RK3288-EVB flat device-tree";
> + data = /incbin/("../../../u-boot.dtb");
> + type = "flat_dt";
> + compression = "none";
> + };
> + };
> +
> + configurations {
> + default = "conf";
> + conf {
> + description = "Rockchip RK3288-EVB";
> + firmware = "atf";
> + loadables = "uboot";
> + fdt = "fdt";
> + };
> + };
> +};
> diff --git a/configs/evb-rk3288-act8846_defconfig 
> b/configs/evb-rk3288-act8846_defconfig
> index 9c7be78ad7..0fcdaaa697 100644
> --- a/configs/evb-rk3288-act8846_defconfig
> +++ b/configs/evb-rk3288-act8846_defconfig
> @@ -1,21 +1,26 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_ROCKCHIP=y
> -CONFIG_SYS_TEXT_BASE=0x0010
> +CONFIG_SYS_TEXT_BASE=0x0020
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_ROCKCHIP_RK3288=y
>  CONFIG_TARGET_EVB_RK3288=y
>  CONFIG_DEBUG_UART_BASE=0xff69
>  CONFIG_DEBUG_UART_CLOCK=2400
> -CONFIG_SPL_STACK_R_ADDR=0x8
> +CONFIG_SPL_STACK_R_ADDR=0x60
>  CONFIG_DEBUG_UART=y
>  CONFIG_NR_DRAM_BANKS=1
>  # CONFIG_ANDROID_BOOT_IMAGE is not set
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_FIT_SOURCE="board/rockchip/evb_rk3288/fit_spl_atf.its"
>  CONFIG_SILENT_CONSOLE=y
>  CONFIG_DEFAULT_FDT_FILE="rk3288-evb-act8846.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
> +CONFIG_SPL_ATF=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_GPT=y
>  CONFIG_CMD_I2C=y
> diff --git a/configs/evb-rk3288-rk808_defconfig 
> b/configs/evb-rk3288-rk808_defconfig
> index 73d30c9958..f6b9ce12a1 100644
> --- a/configs/evb-rk3288-rk808_defconfig
> +++ b/configs/evb-rk3288-rk808_defconfig
> @@ -1,21 +1,26 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_ROCKCHIP=y
> -CONFIG_SYS_TEXT_BASE=0x0010
> +CONFIG_SYS_TEXT_BASE=0x0020
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_ROCKCHIP_RK3288=y
>  

Re: [U-Boot] [PATCH v2 1/1] efi_loader: optional data in load options are binary

[Takahiro Akashi]

On Tue, Apr 30, 2019 at 08:11:15AM +0200, Heinrich Schuchardt wrote:
> The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
> data.
> 
> When we use `efidebug boot add` we should convert the 5th argument from
> UTF-8 to UTF-16 before putting it into the Boot variable.

While optional_data holds u8 string in calling efi_serialize_load_option(),
it holds u16 string in leaving from efi_deserialize_load_option().
We should handle it in a consistent way if you want to keep optional_data
as "const u8."

Thanks,
-Takahiro Akashi

> When printing boot variables with `efidebug boot dump` we should support
> the OptionalData being arbitrary binary data. So let's dump the data as
> hexadecimal values.
> 
> Here is an example session protocol:
> 
> => efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
> => efidebug boot add 00a2 label2 scsi 0:1 doit2
> => efidebug boot dump
> Boot00A0:
>   attributes: A-- (0x0001)
>   label: label1
>   file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
>   data:
> : 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00  m.y. 
> .o.p.t.i.o.
> 0010: 6e 00 00 00  n...
> Boot00A1:
>   attributes: A-- (0x0001)
>   label: label2
>   file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
>   data:
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   remove statement without effect in efi_serialize_load_option()
> ---
>  cmd/efidebug.c   | 27 +--
>  include/efi_loader.h |  2 +-
>  lib/efi_loader/efi_bootmgr.c | 15 ---
>  3 files changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index efe4ea873e..c4ac9dd634 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -545,7 +546,10 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
>   + sizeof(struct efi_device_path); /* for END */
> 
>   /* optional data */
> - lo.optional_data = (u8 *)(argc == 6 ? "" : argv[6]);
> + if (argc < 6)
> + lo.optional_data = NULL;
> + else
> + lo.optional_data = (const u8 *)argv[6];
> 
>   size = efi_serialize_load_option(, (u8 **));
>   if (!size) {
> @@ -615,12 +619,13 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
>  /**
>   * show_efi_boot_opt_data() - dump UEFI load option
>   *
> - * @id:  Load option number
> - * @data:Value of UEFI load option variable
> + * @id:  load option number
> + * @data:value of UEFI load option variable
> + * @size:size of the boot option
>   *
>   * Decode the value of UEFI load option variable and print information.
>   */
> -static void show_efi_boot_opt_data(int id, void *data)
> +static void show_efi_boot_opt_data(int id, void *data, size_t size)
>  {
>   struct efi_load_option lo;
>   char *label, *p;
> @@ -638,7 +643,7 @@ static void show_efi_boot_opt_data(int id, void *data)
>   utf16_utf8_strncpy(, lo.label, label_len16);
> 
>   printf("Boot%04X:\n", id);
> - printf("\tattributes: %c%c%c (0x%08x)\n",
> + printf("  attributes: %c%c%c (0x%08x)\n",
>  /* ACTIVE */
>  lo.attributes & LOAD_OPTION_ACTIVE ? 'A' : '-',
>  /* FORCE RECONNECT */
> @@ -646,14 +651,16 @@ static void show_efi_boot_opt_data(int id, void *data)
>  /* HIDDEN */
>  lo.attributes & LOAD_OPTION_HIDDEN ? 'H' : '-',
>  lo.attributes);
> - printf("\tlabel: %s\n", label);
> + printf("  label: %s\n", label);
> 
>   dp_str = efi_dp_str(lo.file_path);
> - printf("\tfile_path: %ls\n", dp_str);
> + printf("  file_path: %ls\n", dp_str);
>   efi_free_pool(dp_str);
> 
> - printf("\tdata: %s\n", lo.optional_data);
> -
> + printf("  data:\n");
> + print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
> +lo.optional_data, size + (u8 *)data -
> +(u8 *)lo.optional_data, true);
>   free(label);
>  }
> 
> @@ -686,7 +693,7 @@ static void show_efi_boot_opt(int id)
>   data));
>   }
>   if (ret == EFI_SUCCESS)
> - show_efi_boot_opt_data(id, data);
> + show_efi_boot_opt_data(id, data, size);
>   else if (ret == EFI_NOT_FOUND)
>   printf("Boot%04X: not found\n", id);
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 39ed8a6fa5..07b913d256 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -560,7 +560,7 @@ struct efi_load_option {
>   u16 file_path_length;
>   u16 *label;
>   struct efi_device_path *file_path;
> - u8 *optional_data;
> + const u8 *optional_data;
>  };
> 
>  void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
> diff --git 

Re: [U-Boot] [v5 PATCH] RISCV: image: Add booti support

[Marek Vasut]

On 5/7/19 2:49 AM, Atish Patra wrote:
> This patch adds booti support for RISC-V Linux kernel. The existing
> bootm method will also continue to work as it is.
> 
> It depends on the following kernel patch which adds the header to the
> flat Image. Gzip compressed Image (Image.gz) support is not enabled with
> this patch.
> 
> https://patchwork.kernel.org/patch/10925543/
> 
> Tested on HiFive Unleashed and QEMU.
> 
> Signed-off-by: Atish Patra 
> Reviewed-by: Tom Rini 
> Tested-by: Karsten Merker 

Reviewed-by: Marek Vasut 

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

[U-Boot] [v5 PATCH] RISCV: image: Add booti support

[Atish Patra]

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.

https://patchwork.kernel.org/patch/10925543/

Tested on HiFive Unleashed and QEMU.

Signed-off-by: Atish Patra 
Reviewed-by: Tom Rini 
Tested-by: Karsten Merker 
---
Changes from v4->v5
1. Update help text for booti.

Changes from v3->v4
1. Rebased on top of master to avoid git am errors.

Changes from v2->v3
1. Updated the image header structure as per kernel patch.
2. Removed Image.gz support as it will be added as separate RFC patch.
---
 arch/riscv/lib/Makefile |  1 +
 arch/riscv/lib/image.c  | 55 +
 cmd/Kconfig |  2 +-
 cmd/booti.c |  8 --
 4 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv/lib/image.c

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 1c332db436a9..6ae6ebbeafda 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -7,6 +7,7 @@
 # Rick Chen, Andes Technology Corporation 
 
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
 obj-$(CONFIG_CMD_GO) += boot.o
 obj-y  += cache.o
 obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
new file mode 100644
index ..d063beb7dfbe
--- /dev/null
+++ b/arch/riscv/lib/image.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ * Authors:
+ * Atish Patra 
+ * Based on arm/lib/image.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* ASCII version of "RISCV" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+
+struct linux_image_h {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset */
+   uint64_timage_size; /* Effective Image size */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tmagic;  /* Magic number */
+   uint32_tres4;   /* reserved */
+   uint32_tres5;   /* reserved */
+};
+
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+   bool force_reloc)
+{
+   struct linux_image_h *lhdr;
+
+   lhdr = (struct linux_image_h *)map_sysmem(image, 0);
+
+   if (lhdr->magic != LINUX_RISCV_IMAGE_MAGIC) {
+   puts("Bad Linux RISCV Image magic!\n");
+   return -EINVAL;
+   }
+
+   if (lhdr->image_size == 0) {
+   puts("Image lacks image_size field, error!\n");
+   return -EINVAL;
+   }
+   *size = lhdr->image_size;
+   *relocated_addr = gd->ram_base + lhdr->text_offset;
+
+   unmap_sysmem(lhdr);
+
+   return 0;
+}
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 069e0ea7300b..4e11e0f404c8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -223,7 +223,7 @@ config CMD_BOOTZ
 
 config CMD_BOOTI
bool "booti"
-   depends on ARM64
+   depends on ARM64 || RISCV
default y
help
  Boot an AArch64 Linux Kernel image from memory.
diff --git a/cmd/booti.c b/cmd/booti.c
index 04353b68eccc..c36b0235df8c 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -77,7 +77,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
bootm_disable_interrupts();
 
images.os.os = IH_OS_LINUX;
+#ifdef CONFIG_RISCV_SMODE
+   images.os.arch = IH_ARCH_RISCV;
+#elif CONFIG_ARM64
images.os.arch = IH_ARCH_ARM64;
+#endif
ret = do_bootm_states(cmdtp, flag, argc, argv,
 #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
  BOOTM_STATE_RAMDISK |
@@ -92,7 +96,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 #ifdef CONFIG_SYS_LONGHELP
 static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-   "- boot arm64 Linux Image stored in memory\n"
+   "- boot Linux 'Image' stored at 'addr'\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
@@ -107,5 +111,5 @@ static char booti_help_text[] =
 
 U_BOOT_CMD(
booti,  CONFIG_SYS_MAXARGS, 1,  do_booti,
-   "boot arm64 Linux Image image from memory", booti_help_text
+   "boot Linux kernel 'Image' format from memory", booti_help_text
 );
-- 
2.21.0

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

Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Atish Patra]

On 5/6/19 2:27 PM, Tom Rini wrote:

On Mon, May 06, 2019 at 11:10:57PM +0200, Heinrich Schuchardt wrote:

On 5/6/19 10:39 PM, Karsten Merker wrote:

On Mon, May 06, 2019 at 10:06:39PM +0200, Heinrich Schuchardt wrote:

On 5/6/19 8:11 PM, Atish Patra wrote:

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

[...]

+   "boot arm64/riscv Linux Image image from memory", booti_help_text


%s/Image image/image/

"arm64/riscv" is distracting. If I am on RISC-V I cannot boot an ARM64
image here. Remove the reference to the architecture, please.


Hello,

I'm not sure about the last point - ISTR (please correct me if my
memory betrays me here) that an arm64 U-Boot can in principle be
used to boot either an arm64 or an armv7 kernel, but the commands
are different in those cases (booti for an arm64 "Image" format
kernel and bootz for an armv7 "zImage" format kernel), so having
the information which kernel format is supported by the
respective commands appears useful to me.  If the arm64 kernel
image format would have a distinctive name (like "zImage" on
armv7 or "bzImage" on x86) that would be less problematic, but
with the confusion potential of "boot a Linux Image" (as in the
arm64/riscv-specific "Image" format) vs "boot a Linux image" (as
in generally some form of kernel image), I think explicitly
mentioning the supported architectures makes sense.


In this case you have to ensure that only the *supported* architectures
are mentioned. RISC-V is not supported on ARM64.


The help should be re-worded to be both architecture agnostic and clear
that it is for the Linux Kernel 'Image' format images.


Done.

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

Re: [U-Boot] [i.MX8MM+CCF 12/41] clk: fixed_rate: add pre reloc flag

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:18:12 +
Peng Fan  wrote:

> Add pre reloc flag to use this driver before relocation
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk_fixed_rate.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/clk_fixed_rate.c
> b/drivers/clk/clk_fixed_rate.c index 069e643fbc..debada1463 100644
> --- a/drivers/clk/clk_fixed_rate.c
> +++ b/drivers/clk/clk_fixed_rate.c
> @@ -45,4 +45,5 @@ U_BOOT_DRIVER(clk_fixed_rate) = {
>   .ofdata_to_platdata = clk_fixed_rate_ofdata_to_platdata,
>   .platdata_auto_alloc_size = sizeof(struct clk_fixed_rate),
>   .ops = _fixed_rate_ops,
> + .flags = DM_FLAG_PRE_RELOC,
>  };

This probably shall be done with proper dts file (from TPC70 - imx6q
conversion code):

+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+   clocks {
+   u-boot,dm-spl;
+   osc {
+   u-boot,dm-spl;
+   };
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgperh6MKVSbT.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 13/41] clk: imx: import clk heplers

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:18:15 +
Peng Fan  wrote:

> Import some clk helpers from Linux Kernel for i.MX8MM usage
> 

Please globally provide SHA1 and tag of ported code from Linux kernel.

> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/imx/clk.h | 81
> +++ 1 file changed,
> 81 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
> index 864a215a22..aa6e81ff13 100644
> --- a/drivers/clk/imx/clk.h
> +++ b/drivers/clk/imx/clk.h
> @@ -42,6 +42,23 @@ static inline struct clk *imx_clk_gate2(const char
> *name, const char *parent, shift, 0x3, 0);
>  }
>  
> +static inline struct clk *imx_clk_gate4(const char *name, const char
> *parent,
> + void __iomem *reg, u8 shift)
> +{
> + return clk_register_gate2(NULL, name, parent,
> + CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
> + reg, shift, 0x3, 0);
> +}
> +
> +static inline struct clk *imx_clk_gate4_flags(const char *name,
> + const char *parent, void __iomem *reg, u8 shift,
> + unsigned long flags)
> +{
> + return clk_register_gate2(NULL, name, parent,
> + flags | CLK_SET_RATE_PARENT |
> CLK_OPS_PARENT_ENABLE,
> + reg, shift, 0x3, 0);
> +}
> +
>  static inline struct clk *imx_clk_fixed_factor(const char *name,
>   const char *parent, unsigned int mult, unsigned int
> div) {
> @@ -56,6 +73,14 @@ static inline struct clk *imx_clk_divider(const
> char *name, const char *parent, reg, shift, width, 0);
>  }
>  
> +static inline struct clk *imx_clk_divider2(const char *name, const
> char *parent,
> + void __iomem *reg, u8 shift, u8 width)
> +{
> + return clk_register_divider(NULL, name, parent,
> + CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
> + reg, shift, width, 0);
> +}
> +
>  struct clk *imx_clk_pfd(const char *name, const char *parent_name,
>   void __iomem *reg, u8 idx);
>  
> @@ -63,6 +88,16 @@ struct clk *imx_clk_fixup_mux(const char *name,
> void __iomem *reg, u8 shift, u8 width, const char * const *parents,
> int num_parents, void (*fixup)(u32
> *val)); 
> +static inline struct clk *imx_clk_mux_flags(const char *name,
> + void __iomem *reg, u8 shift, u8 width,
> + const char * const *parents, int num_parents,
> + unsigned long flags)
> +{
> + return clk_register_mux(NULL, name, parents, num_parents,
> + flags | CLK_SET_RATE_NO_REPARENT,
> reg, shift,
> + width, 0);
> +}
> +
>  static inline struct clk *imx_clk_mux(const char *name, void __iomem
> *reg, u8 shift, u8 width, const char * const *parents,
>   int num_parents)
> @@ -72,4 +107,50 @@ static inline struct clk *imx_clk_mux(const char
> *name, void __iomem *reg, width, 0);
>  }
>  
> +static inline struct clk *imx_clk_mux2(const char *name, void
> __iomem *reg,
> + u8 shift, u8 width, const char * const
> *parents,
> + int num_parents)
> +{
> + return clk_register_mux(NULL, name, parents, num_parents,
> + CLK_SET_RATE_NO_REPARENT |
> CLK_OPS_PARENT_ENABLE,
> + reg, shift, width, 0);
> +}
> +
> +static inline struct clk *imx_clk_gate(const char *name, const char
> *parent,
> + void __iomem *reg, u8 shift)
> +{
> + return clk_register_gate(NULL, name, parent,
> CLK_SET_RATE_PARENT, reg,
> + shift, 0, NULL);
> +}
> +
> +static inline struct clk *imx_clk_gate_flags(const char *name, const
> char *parent,
> + void __iomem *reg, u8 shift, unsigned long flags)
> +{
> + return clk_register_gate(NULL, name, parent, flags |
> CLK_SET_RATE_PARENT, reg,
> + shift, 0, NULL);
> +}
> +
> +static inline struct clk *imx_clk_gate3(const char *name, const char
> *parent,
> + void __iomem *reg, u8 shift)
> +{
> + return clk_register_gate(NULL, name, parent,
> + CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
> + reg, shift, 0, NULL);
> +}
> +
> +struct clk *imx8m_clk_composite_flags(const char *name,
> + const char * const *parent_names,
> + int num_parents, void __iomem *reg, unsigned long
> flags); +
> +#define __imx8m_clk_composite(name, parent_names, reg, flags) \
> + imx8m_clk_composite_flags(name, parent_names, \
> + ARRAY_SIZE(parent_names), reg, \
> + flags | CLK_SET_RATE_NO_REPARENT |
> CLK_OPS_PARENT_ENABLE) +
> +#define imx8m_clk_composite(name, parent_names, reg) \
> + __imx8m_clk_composite(name, parent_names, reg, 0)
> +
> +#define imx8m_clk_composite_critical(name, parent_names, reg) \
> + __imx8m_clk_composite(name, parent_names, reg,
> CLK_IS_CRITICAL) +
>  #endif /* __MACH_IMX_CLK_H */




Best 

Re: [U-Boot] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate

[Lukasz Majewski]

Hi Peng,

> Export the structure for others to use.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk_fixed_rate.c | 8 +---
>  include/linux/clk-provider.h | 7 +++
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/clk/clk_fixed_rate.c
> b/drivers/clk/clk_fixed_rate.c index 089f060a23..069e643fbc 100644
> --- a/drivers/clk/clk_fixed_rate.c
> +++ b/drivers/clk/clk_fixed_rate.c
> @@ -6,13 +6,7 @@
>  #include 
>  #include 
>  #include 
> -
> -struct clk_fixed_rate {
> - struct clk clk;
> - unsigned long fixed_rate;
> -};
> -
> -#define to_clk_fixed_rate(dev)   ((struct clk_fixed_rate
> *)dev_get_platdata(dev)) +#include 
>  
>  static ulong clk_fixed_rate_get_rate(struct clk *clk)
>  {
> diff --git a/include/linux/clk-provider.h
> b/include/linux/clk-provider.h index 3ed0db86d2..b2bed768b6 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -112,6 +112,13 @@ struct clk_fixed_factor {
>  #define to_clk_fixed_factor(_clk) container_of(_clk, struct
> clk_fixed_factor,\ clk)
>  
> +struct clk_fixed_rate {
> + struct clk clk;
> + unsigned long fixed_rate;
> +};

I think that this struct shall stay where it was. Moreover, the
clk-provider.h is not the API to be used by other parts of the clock
API.

The clk_fixed_rate shall be accessed via get_rate() only and in IMX6Q
it is available in early SPL (parsed from dts /clocks property - the
24MHz OSC)

> +
> +#define to_clk_fixed_rate(dev)   ((struct clk_fixed_rate
> *)dev_get_platdata(dev)) +
>  int clk_register(struct clk *clk, const char *drv_name,
>ulong drv_data, const char *name,
>const char *parent_name);

Please explain why iMX8MM needs such global export?


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpm2og1WOGdC.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 07/41] clk: mux: add set parent support

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:54 +
Peng Fan  wrote:

> Add set parent support for clk mux
> 

I suppose that it was ported from Linux kernel directly?

If yes, please state the SHA1 of Linux master (or exact tag).

> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk-mux.c| 70
> ++--
> include/linux/clk-provider.h |  2 ++ 2 files changed, 70
> insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 55fc97367a..1a937bf923 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -60,7 +60,24 @@ int clk_mux_val_to_index(struct clk *clk, u32
> *table, unsigned int flags, return val;
>  }
>  
> -static u8 clk_mux_get_parent(struct clk *clk)
> +unsigned int clk_mux_index_to_val(u32 *table, unsigned int flags, u8
> index) +{
> + unsigned int val = index;
> +
> + if (table) {
> + val = table[index];
> + } else {
> + if (flags & CLK_MUX_INDEX_BIT)
> + val = 1 << index;
> +
> + if (flags & CLK_MUX_INDEX_ONE)
> + val++;
> + }
> +
> + return val;
> +}
> +
> +u8 clk_mux_get_parent(struct clk *clk)
>  {
>   struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
>   (struct clk
> *)dev_get_driver_data(clk->dev) : clk); @@ -72,8 +89,57 @@ static u8
> clk_mux_get_parent(struct clk *clk) return clk_mux_val_to_index(clk,
> mux->table, mux->flags, val); }
>  
> +static int clk_fetch_parent_index(struct clk *clk,
> +   struct clk *parent)
> +{
> + struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
> + (struct clk
> *)dev_get_driver_data(clk->dev) : clk); +
> + int i;
> +
> + if (!parent)
> + return -EINVAL;
> +
> + for (i = 0; i < mux->num_parents; i++) {
> + if (!strcmp(parent->dev->name, mux->parent_names[i]))
> + return i;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int clk_mux_set_parent(struct clk *clk, struct clk *parent)
> +{
> + struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
> + (struct clk
> *)dev_get_driver_data(clk->dev) : clk);
> + int index;
> + u32 val;
> + u32 reg;
> +
> + index = clk_fetch_parent_index(clk, parent);
> + if (index < 0) {
> + printf("Could not fetch index\n");
> + return index;
> + }
> +
> + val = clk_mux_index_to_val(mux->table, mux->flags, index);
> +
> + if (mux->flags & CLK_MUX_HIWORD_MASK) {
> + reg = mux->mask << (mux->shift + 16);
> + } else {
> + reg = readl(mux->reg);
> + reg &= ~(mux->mask << mux->shift);
> + }
> + val = val << mux->shift;
> + reg |= val;
> + writel(reg, mux->reg);
> +
> + return 0;
> +}
> +
>  const struct clk_ops clk_mux_ops = {
> - .get_rate = clk_generic_get_rate,
> + .get_rate = clk_generic_get_rate,
> + .set_parent = clk_mux_set_parent,
>  };
>  
>  struct clk *clk_hw_register_mux_table(struct device *dev, const char
> *name, diff --git a/include/linux/clk-provider.h
> b/include/linux/clk-provider.h index 3458746a60..216095d28c 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -56,6 +56,8 @@ struct clk_mux {
>  };
>  
>  #define to_clk_mux(_clk) container_of(_clk, struct clk_mux, clk)
> +extern const struct clk_ops clk_mux_ops;
> +u8 clk_mux_get_parent(struct clk *clk);
>  
>  struct clk_div_table {
>   unsigned intval;




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp1MTc8LKrFS.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 08/41] clk: export mux/divider ops

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:58 +
Peng Fan  wrote:

> Export mux/divider ops for composite usage
> 
> Signed-off-by: Peng Fan 
> ---
>  include/linux/clk-provider.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/clk-provider.h
> b/include/linux/clk-provider.h index 216095d28c..a60cf6e833 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -83,6 +83,7 @@ struct clk_divider {
>  #define CLK_DIVIDER_ROUND_CLOSESTBIT(4)
>  #define CLK_DIVIDER_READ_ONLYBIT(5)
>  #define CLK_DIVIDER_MAX_AT_ZERO  BIT(6)
> +extern const struct clk_ops clk_divider_ops;
>  

Why do we need to export clk_divider_ops? Why iMX8MM requires it?

>  struct clk_fixed_factor {
>   struct clk  clk;




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp9RDMflKahU.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 10/41] divider set rate supporrt

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:18:05 +
Peng Fan  wrote:

Please state the exact SHA1 or tag when porting the code from Linux
kernel.

> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk-divider.c | 88
> +++ 1 file changed, 88
> insertions(+)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 2f09e0bb58..8615f9815d 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "clk.h"
> @@ -81,8 +82,95 @@ static ulong clk_divider_recalc_rate(struct clk
> *clk) divider->flags, divider->width);
>  }
>  
> +static bool _is_valid_table_div(const struct clk_div_table *table,
> + unsigned int div)
> +{
> + const struct clk_div_table *clkt;
> +
> + for (clkt = table; clkt->div; clkt++)
> + if (clkt->div == div)
> + return true;
> + return false;
> +}
> +
> +static bool _is_valid_div(const struct clk_div_table *table,
> unsigned int div,
> +   unsigned long flags)
> +{
> + if (flags & CLK_DIVIDER_POWER_OF_TWO)
> + return is_power_of_2(div);
> + if (table)
> + return _is_valid_table_div(table, div);
> + return true;
> +}
> +
> +static unsigned int _get_table_val(const struct clk_div_table *table,
> +unsigned int div)
> +{
> + const struct clk_div_table *clkt;
> +
> + for (clkt = table; clkt->div; clkt++)
> + if (clkt->div == div)
> + return clkt->val;
> + return 0;
> +}
> +
> +static unsigned int _get_val(const struct clk_div_table *table,
> +  unsigned int div, unsigned long flags,
> u8 width) +{
> + if (flags & CLK_DIVIDER_ONE_BASED)
> + return div;
> + if (flags & CLK_DIVIDER_POWER_OF_TWO)
> + return __ffs(div);
> + if (flags & CLK_DIVIDER_MAX_AT_ZERO)
> + return (div == clk_div_mask(width) + 1) ? 0 : div;
> + if (table)
> + return  _get_table_val(table, div);
> + return div - 1;
> +}
> +int divider_get_val(unsigned long rate, unsigned long parent_rate,
> + const struct clk_div_table *table, u8 width,
> + unsigned long flags)
> +{
> + unsigned int div, value;
> +
> + div = DIV_ROUND_UP_ULL((u64)parent_rate, rate);
> +
> + if (!_is_valid_div(table, div, flags))
> + return -EINVAL;
> +
> + value = _get_val(table, div, flags, width);
> +
> + return min_t(unsigned int, value, clk_div_mask(width));
> +}
> +
> +static ulong clk_divider_set_rate(struct clk *clk, unsigned long
> rate) +{
> + struct clk_divider *divider =
> to_clk_divider(clk_dev_binded(clk) ?
> + (struct clk
> *)dev_get_driver_data(clk->dev) : clk);
> + unsigned long parent_rate = clk_get_parent_rate(clk);
> + int value;
> + u32 val;
> +
> + value = divider_get_val(rate, parent_rate, divider->table,
> + divider->width, divider->flags);
> + if (value < 0)
> + return value;
> +
> + if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
> + val = clk_div_mask(divider->width) <<
> (divider->shift + 16);
> + } else {
> + val = readl(divider->reg);
> + val &= ~(clk_div_mask(divider->width) <<
> divider->shift);
> + }
> + val |= (u32)value << divider->shift;
> + writel(val, divider->reg);
> +
> + return clk_get_rate(clk);
> +}
> +
>  const struct clk_ops clk_divider_ops = {
>   .get_rate = clk_divider_recalc_rate,
> + .set_rate = clk_divider_set_rate,
>  };
>  
>  static struct clk *_register_divider(struct device *dev, const char
> *name,




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpMvsM4bBshb.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 06/41] cmd: clk: print err value when clk_get_rate failed

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:50 +
Peng Fan  wrote:

> Print err value when clk_get_rate failed
> 
> Signed-off-by: Peng Fan 
> ---
>  cmd/clk.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/cmd/clk.c b/cmd/clk.c
> index 2ea82176aa..73d963184d 100644
> --- a/cmd/clk.c
> +++ b/cmd/clk.c
> @@ -41,6 +41,8 @@ int __weak soc_clk_dump(void)
>   rate = clk_get_rate();
>   if (!IS_ERR_VALUE(rate))
>   printf("%-30.30s : %lu Hz\n", dev->name,
> rate);
> + else
> + printf("%-30.30s : err=%ld\n", dev->name,
> rate); 
>   clk_free();
>   }

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpYxiAPPmVMV.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 05/41] clk-provider: sync more clk flags from Linux Kernel

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:47 +
Peng Fan  wrote:

> Sync more clk flags that might be used in U-Boot CCF.
> 
> Signed-off-by: Peng Fan 
> ---
>  include/linux/clk-provider.h | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/include/linux/clk-provider.h
> b/include/linux/clk-provider.h index eac045c5f8..3458746a60 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -9,8 +9,29 @@
>  #ifndef __LINUX_CLK_PROVIDER_H
>  #define __LINUX_CLK_PROVIDER_H
>  
> +/*
> + * flags used across common struct clk.  these flags should only
> affect the
> + * top-level framework.  custom flags for dealing with hardware
> specifics
> + * belong in struct clk_foo
> + *
> + * Please update clk_flags[] in drivers/clk/clk.c when making
> changes here!
> + */
> +#define CLK_SET_RATE_GATEBIT(0) /* must be gated across rate
> change */ +#define CLK_SET_PARENT_GATEBIT(1) /* must be gated
> across re-parent */ #define CLK_SET_RATE_PARENT   BIT(2) /*
> propagate rate change up one level */ +#define
> CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */
> + /* unused */
> +#define CLK_IS_BASIC BIT(5) /* Basic clk, can't do a
> to_clk_foo() */ 

> +#define CLK_GET_RATE_NOCACHE BIT(6) /* do not
> use the cached clk rate */ 

I guess that this is what your requested for the NOCACHE (to always
recalculate the rate).

> #define CLK_SET_RATE_NO_REPARENT BIT(7) /*
> don't re-parent on rate change */ +#define CLK_GET_ACCURACY_NOCACHE
> BIT(8) /* do not use the cached clk accuracy */ +#define
> CLK_RECALC_NEW_RATES  BIT(9) /* recalc rates after
> notifications */ +#define CLK_SET_RATE_UNGATE BIT(10) /* clock
> needs to run to set rate */ +#define CLK_IS_CRITICAL
> BIT(11) /* do not gate, ever */ +/* parents need enable during
> gate/ungate, set rate and re-parent */ +#define
> CLK_OPS_PARENT_ENABLE BIT(12) +/* duty cycle call may be
> forwarded to the parent clock */ +#define
> CLK_DUTY_CYCLE_PARENT BIT(13) #define
> CLK_MUX_INDEX_ONE BIT(0) #define
> CLK_MUX_INDEX_BIT BIT(1)

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpWjDVA53UR1.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 04/41] clk: use clk_dev_binded

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:43 +
Peng Fan  wrote:

> Preparing to support composite clk.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk-divider.c | 4 ++--
>  drivers/clk/clk-mux.c | 6 --
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 1d2c1b1ec4..2f09e0bb58 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -69,8 +69,8 @@ unsigned long divider_recalc_rate(struct clk *hw,
> unsigned long parent_rate, 
>  static ulong clk_divider_recalc_rate(struct clk *clk)
>  {
> - struct clk_divider *divider =
> - to_clk_divider((struct clk
> *)dev_get_driver_data(clk->dev));
> + struct clk_divider *divider =
> to_clk_divider(clk_dev_binded(clk) ?
> + (struct clk

As I've wrote in the previous mail - in iMX6Q there was no issues.
Could you provide an explanation in what respect the iMX8MM is
different ?

What exactly is missing?

> *)dev_get_driver_data(clk->dev) : clk); unsigned long parent_rate =
> clk_get_parent_rate(clk); unsigned int val;
>  
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 2c85f2052c..55fc97367a 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -35,7 +35,8 @@
>  int clk_mux_val_to_index(struct clk *clk, u32 *table, unsigned int
> flags, unsigned int val)
>  {
> - struct clk_mux *mux = to_clk_mux(clk);
> + struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
> + (struct clk
> *)dev_get_driver_data(clk->dev) : clk); int num_parents =
> mux->num_parents; 
>   if (table) {
> @@ -61,7 +62,8 @@ int clk_mux_val_to_index(struct clk *clk, u32
> *table, unsigned int flags, 
>  static u8 clk_mux_get_parent(struct clk *clk)
>  {
> - struct clk_mux *mux = to_clk_mux(clk);
> + struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
> + (struct clk
> *)dev_get_driver_data(clk->dev) : clk); u32 val;
>  
>   val = readl(mux->reg) >> mux->shift;




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp1IYIzKre1S.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 03/41] clk: introduce clk_dev_binded

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:40 +
Peng Fan  wrote:

> When support Clock Common Framework, U-Boot use dev for
> clk tree information, there is no clk->parent.

There is a function in clk uclass named:
clk_get_parent() to provide parent of the clock.

> When
> support composite clk, it contains mux/gate/divider,
> but the mux/gate/divider is not binded with device.

There is a binding:
struct clk_pllv3 {
struct clk  clk;
...
};

The clk.dev points to corresponding device.

In the opposite direction we do have dev->driver_data, which points to
struct clk embedded in for example struct clk_pllv3.
(as struct clk_pllv3 and struct clk share the same address it is up to
us to cast it properly).

I've written my thoughts and considerations about using dev->private
and dev->driver_data in the patch cover letter [1]


> So we could not use dev_get_driver_data to get the correct
> clk_mux/gate/divider. 

Maybe I've overlooked something, but dev_get_driver_data() shall
provide correct reference to udevice.

> So add clk_dev_binded to let
> choose the correct method.
> 

[1] - http://patchwork.ozlabs.org/cover/1090669/

> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk.c | 8 
>  include/clk.h | 9 +
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0a0fffb50b..025bb99ecc 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -54,3 +54,11 @@ const char *clk_hw_get_name(const struct clk *hw)
>  {
>   return hw->dev->name;
>  }
> +
> +bool clk_dev_binded(struct clk *clk)
> +{
> + if (clk->dev && (clk->dev->flags & DM_FLAG_BOUND))
> + return true;
> +
> + return false;
> +}
> diff --git a/include/clk.h b/include/clk.h
> index a4ecca9fbc..8199119d01 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -337,4 +337,13 @@ static inline bool clk_valid(struct clk *clk)
>   * @return zero on success, or -ENOENT on error
>   */
>  int clk_get_by_id(ulong id, struct clk **clkp);
> +
> +/**
> + * clk_dev_binded() - Check whether the clk has a device binded
> + *
> + * @clk  A pointer to the clk
> + *
> + * @return true on binded, or false on no
> + */
> +bool clk_dev_binded(struct clk *clk);
>  #endif




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpjqZ1bB5vKD.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 02/41] clk: fixed-factor: fix get clk_fixed_factor

[Lukasz Majewski]

On Tue, 30 Apr 2019 10:17:36 +
Peng Fan  wrote:

> driver data is not clk, not clk_fixed_factor, fix it.

This description is a bit misleading, IMHO.

The dev->driver_data holds pointer to corresponding struct clk clk
element (as described [1]).
 
This patch resembles changes from PATCH [1/42].

> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk-fixed-factor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-fixed-factor.c
> b/drivers/clk/clk-fixed-factor.c index acbc0909b4..c535aadc48 100644
> --- a/drivers/clk/clk-fixed-factor.c
> +++ b/drivers/clk/clk-fixed-factor.c
> @@ -19,7 +19,7 @@
>  static ulong clk_factor_recalc_rate(struct clk *clk)
>  {
>   struct clk_fixed_factor *fix =
> - (struct clk_fixed_factor
> *)dev_get_driver_data(clk->dev);
> + to_clk_fixed_factor((struct clk
> *)dev_get_driver_data(clk->dev)); unsigned long parent_rate =
> clk_get_parent_rate(clk); unsigned long long int rate;
>  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp0Ilf4GlVX_.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 01/41] clk: correct get clk_x pointer

[Lukasz Majewski]

Hi Peng,

> Directly use driver data is wrong, need to the helper to get
> the correct clk_divider and etc

I just followed the kernel approach.

This works as the address of first element of struct clk_XXX is always
struct clk clk address;

But yes, this may be the preferred (more readable) approach.

> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/clk/clk-divider.c   | 2 +-
>  drivers/clk/imx/clk-gate2.c | 4 ++--
>  drivers/clk/imx/clk-pfd.c   | 2 +-
>  drivers/clk/imx/clk-pllv3.c | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 3841d8bfbb..1d2c1b1ec4 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -70,7 +70,7 @@ unsigned long divider_recalc_rate(struct clk *hw,
> unsigned long parent_rate, static ulong
> clk_divider_recalc_rate(struct clk *clk) {
>   struct clk_divider *divider =
> - (struct clk_divider *)dev_get_driver_data(clk->dev);
> + to_clk_divider((struct clk
> *)dev_get_driver_data(clk->dev)); unsigned long parent_rate =
> clk_get_parent_rate(clk); unsigned int val;
>  
> diff --git a/drivers/clk/imx/clk-gate2.c b/drivers/clk/imx/clk-gate2.c
> index 1e53e4f9db..83589b9206 100644
> --- a/drivers/clk/imx/clk-gate2.c
> +++ b/drivers/clk/imx/clk-gate2.c
> @@ -38,7 +38,7 @@ struct clk_gate2 {
>  static int clk_gate2_enable(struct clk *clk)
>  {
>   struct clk_gate2 *gate =
> - (struct clk_gate2 *)dev_get_driver_data(clk->dev);
> + to_clk_gate2((struct clk
> *)dev_get_driver_data(clk->dev)); u32 reg;
>  
>   reg = readl(gate->reg);
> @@ -52,7 +52,7 @@ static int clk_gate2_enable(struct clk *clk)
>  static int clk_gate2_disable(struct clk *clk)
>  {
>   struct clk_gate2 *gate =
> - (struct clk_gate2 *)dev_get_driver_data(clk->dev);
> + to_clk_gate2((struct clk
> *)dev_get_driver_data(clk->dev)); u32 reg;
>  
>   reg = readl(gate->reg);
> diff --git a/drivers/clk/imx/clk-pfd.c b/drivers/clk/imx/clk-pfd.c
> index 2293d481d4..51521ccee6 100644
> --- a/drivers/clk/imx/clk-pfd.c
> +++ b/drivers/clk/imx/clk-pfd.c
> @@ -41,7 +41,7 @@ struct clk_pfd {
>  static unsigned long clk_pfd_recalc_rate(struct clk *clk)
>  {
>   struct clk_pfd *pfd =
> - (struct clk_pfd *)dev_get_driver_data(clk->dev);
> + to_clk_pfd((struct clk
> *)dev_get_driver_data(clk->dev)); unsigned long parent_rate =
> clk_get_parent_rate(clk); u64 tmp = parent_rate;
>   u8 frac = (readl(pfd->reg) >> (pfd->idx * 8)) & 0x3f;
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 3fe9b7c03d..28c0439878 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -27,7 +27,7 @@ struct clk_pllv3 {
>  static ulong clk_pllv3_get_rate(struct clk *clk)
>  {
>   struct clk_pllv3 *pll =
> - (struct clk_pllv3 *)dev_get_driver_data(clk->dev);
> + to_clk_pllv3((struct clk
> *)dev_get_driver_data(clk->dev)); unsigned long parent_rate =
> clk_get_parent_rate(clk); 
>   u32 div = (readl(pll->base) >> pll->div_shift) &
> pll->div_mask;


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpkOCQzxtPQE.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [i.MX8MM+CCF 00/41] i.MX8MM + CCF

[Lukasz Majewski]

Hi Peng,

> This patch set is based Lukasz V3 CCF patchset,
> [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to
> U-boot (tag: 5.0-rc3)
> https://github.com/lmajewski/u-boot-dfu/commits/CCF-v3
> 
> Added a few fixes to Lukasz's v3 patchset.
> Introduced clk-gate/composite
> Added set rate support
> Per my understanding, U-Boot CCF will not support mux reparent, and
> support rate prograte setting to parent automatically. 

I think that we shall keep the code as small as possible and hence add
only necessary features (that is why my code only supports gating and
muxing for 'downstream' settings).

> So new clk
> feature added follow this rule.
> 
> There are many warnings when importing linux ccf code, I did not
> modify them all.

I've removed some not needed arguments (like spinlocks) when porting
the code.

> 
> The rest patches are for i.MX8MM, part of legacy clk code are still
> kept, because we are hard to enable CCF at very early stage,

Yes, CCF in SPL is a challenging task.

> we set
> malloc space to DRAM when dram initialized in spl stage, so we have
> limited SRAM for uclass dm and dm clk,

I'm puzzled about this sentence. The malloc is set to be in DRAM, but
also SRAM is used for uclass dm and CCF.

As fair as I remember on iMX6Q it is possible to setup early malloc to
be in SRAM (OCRAM). Having it in DRAM is a bit late, IMHO as clocks
are already setup in this moment.

> so keep the DRAM PLL related
> setting with legacy clk code which use small ram.

What is the 'ram' ? I suppose that the legacy clk code uses OCRAM to
allocate variables ? 

> 
> The u-boot-spl.bin now is about 100KB without ddr firmware,usb stack
> and hab, so really large..

I think that 100KiB is too much (without DDR, USB stack and HAB). For
one IMX6Q setup (before DM/DTS conversion) I had SPL size ~30 KiB.

After the conversion it is 55 KiB ...

> I am thinking what we could do to shrink the size, welcome any
> suggestions.

Please consider using:

- TINY_PRINTF
- TINY_FIT support (just support for single image in FIT)
- OF_PLATDATA (the in-device-tree code is compiled in as C
  structures) - no need to include DTS parsing / handling code in SPL.
  Also the *.dts file is not needed.

  Drawback is that you need to extend drivers to support OF_PLATDATA
  (RK3399 have some examples of such approach).

- Check if thumb2 is uses for SPL compilation 
- I simply do find *.o files and sort them regarding the size. Then I
  do know where to start with optimisations.

> 
> Not expect this patchset could be merged, because of the CCF/clock
> code change, but since the clock part blocks i.MX8MM upstream, just
> would like to speed up the development with community and move on.
> 
> Peng Fan (40):
>   clk: correct get clk_x pointer
>   clk: fixed-factor: fix get clk_fixed_factor
>   clk: introduce clk_dev_binded
>   clk: use clk_dev_binded
>   clk-provider: sync more clk flags from Linux Kernel
>   cmd: clk: print err value when clk_get_rate failed
>   clk: mux: add set parent support
>   clk: export mux/divider ops
>   clk: add clk-gate support
>   divider set rate supporrt
>   clk: fixed_rate: export clk_fixed_rate
>   clk: fixed_rate: add pre reloc flag
>   clk: imx: import clk heplers
>   clk: imx: gate2 add set rate
>   linux: compat: guard PAGE_SIZE
>   drivers: core: use strcmp when find device by name
>   ddr: imx8m: fix ddr firmware location when enable SPL OF
>   imx: add IMX8MQ kconfig entry
>   imx: add IMX8MM kconfig entry
>   imx: imx8mm: add clock bindings header
>   imx: add i.MX8MM cpu type
>   imx: spl: add spl_board_boot_device for i.MX8MM
>   imx8m: update imx-regs for i.MX8MM
>   imx: add get_cpu_rev support for i.MX8MM
>   imx8m: rename clock to clock_imx8mq
>   imx8m: restructure clock.h
>   imx8m: add clk support for i.MX8MM
>   imx8m: soc: probe clk before relocation
>   imx8m: add pin header for i.MX8MM
>   imx: add i.MX8MM PE property
>   imx8m: Fix MMU table issue for OPTEE memory
>   imx8m: set BYPASS ID SWAP to avoid AXI bus errors
>   imx8m: soc: enable SCTR clock before timer init
>   serial: Kconfig: make MXC_UART usable for MX7 and IMX8M
>   clk: imx: add Kconfig entry for i.MX8MM
>   clk: imx: add pll14xx driver
>   clk: add composite clk support
>   clk: imx: add i.MX8MM composite clk support
>   clk: imx: add i.MX8MM clk driver
>   imx: add i.MX8MM EVK board support
> 
> Ye Li (1):
>   imx8m: Configure trustzone region 0 for non-secure access
> 
>  arch/arm/dts/Makefile  |3 +-
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi|   92 +
>  arch/arm/dts/imx8mm-evk.dts|  235 +++
>  arch/arm/dts/imx8mm-pinfunc.h  |  629 +++
>  arch/arm/dts/imx8mm.dtsi   |  733 
>  arch/arm/include/asm/arch-imx/cpu.h|6 +
>  arch/arm/include/asm/arch-imx8m/clock.h|  493 +
>  arch/arm/include/asm/arch-imx8m/clock_imx8mm.h |  387 
>  

[U-Boot] [PATCH v3 2/2] efi_loader: LoadImage() check source size

[Heinrich Schuchardt]

If the size of the source buffer is 0, return EFI_LOAD_ERROR.
(UEFI SCT II 2017: 3.4.1 LoadImage() - 5.1.4.1.6)

Signed-off-by: Heinrich Schuchardt 
---
v3
put change into separate patch
---
 lib/efi_loader/efi_boottime.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index bf560c6234..bc70018946 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1781,6 +1781,10 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
if (ret != EFI_SUCCESS)
goto error;
} else {
+   if (!source_size) {
+   ret = EFI_LOAD_ERROR;
+   goto error;
+   }
dest_buffer = source_buffer;
}
/* split file_path which contains both the device and file parts */
--
2.20.1

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

Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Tom Rini]

On Mon, May 06, 2019 at 11:10:57PM +0200, Heinrich Schuchardt wrote:
> On 5/6/19 10:39 PM, Karsten Merker wrote:
> >On Mon, May 06, 2019 at 10:06:39PM +0200, Heinrich Schuchardt wrote:
> >>On 5/6/19 8:11 PM, Atish Patra wrote:
> >>>This patch adds booti support for RISC-V Linux kernel. The existing
> >>>bootm method will also continue to work as it is.
> >[...]
> >>>+  "boot arm64/riscv Linux Image image from memory", booti_help_text
> >>
> >>%s/Image image/image/
> >>
> >>"arm64/riscv" is distracting. If I am on RISC-V I cannot boot an ARM64
> >>image here. Remove the reference to the architecture, please.
> >
> >Hello,
> >
> >I'm not sure about the last point - ISTR (please correct me if my
> >memory betrays me here) that an arm64 U-Boot can in principle be
> >used to boot either an arm64 or an armv7 kernel, but the commands
> >are different in those cases (booti for an arm64 "Image" format
> >kernel and bootz for an armv7 "zImage" format kernel), so having
> >the information which kernel format is supported by the
> >respective commands appears useful to me.  If the arm64 kernel
> >image format would have a distinctive name (like "zImage" on
> >armv7 or "bzImage" on x86) that would be less problematic, but
> >with the confusion potential of "boot a Linux Image" (as in the
> >arm64/riscv-specific "Image" format) vs "boot a Linux image" (as
> >in generally some form of kernel image), I think explicitly
> >mentioning the supported architectures makes sense.
> 
> In this case you have to ensure that only the *supported* architectures
> are mentioned. RISC-V is not supported on ARM64.

The help should be re-worded to be both architecture agnostic and clear
that it is for the Linux Kernel 'Image' format images.

-- 
Tom


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

[U-Boot] [PATCH v3 1/2] efi_loader: LoadImage() check parent image

[Heinrich Schuchardt]

If the parent image handle does not refer to a loaded image return
EFI_INVALID_PARAMETER.
(UEFI SCT II 2017: 3.4.1 LoadImage() - 5.1.4.1.1)

Mark our root node as a loaded image to avoid an error when using it as
parent image.

Signed-off-by: Heinrich Schuchardt 
---
v3
put change into separate patch
---
 include/efi_loader.h   |  1 +
 lib/efi_loader/efi_boottime.c  |  7 -
 lib/efi_loader/efi_root_node.c | 48 ++
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index d3a1d4c465..07ef14ba1c 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -187,6 +187,7 @@ struct efi_handler {
  */
 enum efi_object_type {
EFI_OBJECT_TYPE_UNDEFINED = 0,
+   EFI_OBJECT_TYPE_U_BOOT_FIRMWARE,
EFI_OBJECT_TYPE_LOADED_IMAGE,
EFI_OBJECT_TYPE_STARTED_IMAGE,
 };
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 78a4063949..bf560c6234 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1760,7 +1760,7 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
EFI_ENTRY("%d, %p, %pD, %p, %zd, %p", boot_policy, parent_image,
  file_path, source_buffer, source_size, image_handle);

-   if (!image_handle || !parent_image) {
+   if (!image_handle || !efi_search_obj(parent_image)) {
ret = EFI_INVALID_PARAMETER;
goto error;
}
@@ -1769,6 +1769,11 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
ret = EFI_NOT_FOUND;
goto error;
}
+   /* The parent image handle must refer to a loaded image */
+   if (!parent_image->type) {
+   ret = EFI_INVALID_PARAMETER;
+   goto error;
+   }

if (!source_buffer) {
ret = efi_load_image_from_path(file_path, _buffer,
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index e0fcbb85a4..38514e0820 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -28,6 +28,7 @@ struct efi_root_dp {
  */
 efi_status_t efi_root_node_register(void)
 {
+   efi_status_t ret;
struct efi_root_dp *dp;

/* Create device path protocol */
@@ -47,28 +48,31 @@ efi_status_t efi_root_node_register(void)
dp->end.length = sizeof(struct efi_device_path);

/* Create root node and install protocols */
-   return EFI_CALL(efi_install_multiple_protocol_interfaces(_root,
-  /* Device path protocol */
-  _guid_device_path, dp,
-  /* Device path to text protocol */
-  _guid_device_path_to_text_protocol,
-  (void *)_device_path_to_text,
-  /* Device path utilities protocol */
-  _guid_device_path_utilities_protocol,
-  (void *)_device_path_utilities,
-  /* Unicode collation protocol */
-  _guid_unicode_collation_protocol,
-  (void *)_unicode_collation_protocol,
+   ret = EFI_CALL(efi_install_multiple_protocol_interfaces
+   (_root,
+/* Device path protocol */
+_guid_device_path, dp,
+/* Device path to text protocol */
+_guid_device_path_to_text_protocol,
+(void *)_device_path_to_text,
+/* Device path utilities protocol */
+_guid_device_path_utilities_protocol,
+(void *)_device_path_utilities,
+/* Unicode collation protocol */
+_guid_unicode_collation_protocol,
+(void *)_unicode_collation_protocol,
 #if CONFIG_IS_ENABLED(EFI_LOADER_HII)
-  /* HII string protocol */
-  _guid_hii_string_protocol,
-  (void *)_hii_string,
-  /* HII database protocol */
-  _guid_hii_database_protocol,
-  (void *)_hii_database,
-  /* HII configuration routing protocol */
-  _guid_hii_config_routing_protocol,
-  (void *)_hii_config_routing,
+/* HII string protocol */
+_guid_hii_string_protocol,
+(void *)_hii_string,
+/* HII database protocol */
+_guid_hii_database_protocol,
+(void *)_hii_database,
+/* HII configuration routing protocol */
+_guid_hii_config_routing_protocol,
+(void *)_hii_config_routing,
 #endif
-  NULL));
+NULL));
+   efi_root->type = 

[U-Boot] [PATCH v3 0/2] efi_loader: LoadImage() parameter checks

[Heinrich Schuchardt]

If the parent image handle does not refer to a loaded image return
EFI_INVALID_PARAMETER.
(UEFI SCT II 2017: 3.4.1 LoadImage() - 5.1.4.1.1)

If the size of the source buffer is 0, return EFI_LOAD_ERROR.
(UEFI SCT II 2017: 3.4.1 LoadImage() - 5.1.4.1.6)

v3
Put each change into a separate patch

Remove the following changes due to a conflict between UEFI
and UEFI SCT:
* If the file path is NULL, return EFI_INVALID_PARAMETER.
* If the file path is invalid, return EFI_NOT_FOUND.

Heinrich Schuchardt (2):
  efi_loader: LoadImage() check parent image
  efi_loader: LoadImage() check source size

 include/efi_loader.h   |  1 +
 lib/efi_loader/efi_boottime.c  | 11 +++-
 lib/efi_loader/efi_root_node.c | 48 ++
 3 files changed, 37 insertions(+), 23 deletions(-)

--
2.20.1

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

Re: [U-Boot] [PATCH v2 2/2] sysreset: add support for socfpga sysreset

[Marek Vasut]

On 5/6/19 10:13 PM, Simon Goldschmidt wrote:
[...]

> +static int socfpga_reset_bind(struct udevice *dev)
> +{
> + int ret;
> + struct udevice *sys_child;
> +
> + /*
> +  * The sysreset driver does not have a device node, so bind it here.
> +  * Bind it to the node, too, so that it can get its base address.
> +  */
> + ret = device_bind_driver_to_node(dev, "socfpga_sysreset", "sysreset",
> +  dev->node, _child);
> + if (ret)
> + debug("Warning: No sysreset driver: ret=%d\n", ret);

Can't we just fail here ? (return ret;) ?

> +
> + return 0;
> +}
> +
>  static const struct udevice_id socfpga_reset_match[] = {
>   { .compatible = "altr,rst-mgr" },
>   { /* sentinel */ },
> @@ -141,6 +159,7 @@ U_BOOT_DRIVER(socfpga_reset) = {
>   .name = "socfpga-reset",
>   .id = UCLASS_RESET,
>   .of_match = socfpga_reset_match,
> + .bind = socfpga_reset_bind,
>   .probe = socfpga_reset_probe,
>   .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
>   .ops = _reset_ops,
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index 8ce3e2e207..5b8402ccae 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -36,6 +36,20 @@ config SYSRESET_PSCI
> Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
> must be running on your system.
>  
> +config SYSRESET_SOCFPGA
> + bool "Enable support for Intel SOCFPGA family"
> + depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 || 
> TARGET_SOCFPGA_ARRIA10)
> + help
> +   This enables the system reset driver support for Intel SOCFPGA SoCs
> +   (Cyclone 5, Arria 5 and Arria 10).
> +
> +config SYSRESET_SOCFPGA_S10
> + bool "Enable support for Intel SOCFPGA Stratix 10"
> + depends on ARCH_SOCFPGA && TARGET_SOCFPGA_STRATIX10
> + help
> +   This enables the system reset driver support for Intel SOCFPGA
> +   Stratix SoCs.
> +

That sounds like two drivers => separate patch please.

[...]

> +static int socfpga_sysreset_request(struct udevice *dev,
> + enum sysreset_t type)
> +{
> + struct socfpga_sysreset_data *data = dev_get_priv(dev);
> +
> + switch (type) {
> + case SYSRESET_WARM:
> + writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
> +>rstmgr_base->ctrl);
> + break;
> + case SYSRESET_COLD:
> + writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
> +>rstmgr_base->ctrl);


Use BIT() macro.

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

Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Heinrich Schuchardt]

On 5/6/19 10:39 PM, Karsten Merker wrote:

On Mon, May 06, 2019 at 10:06:39PM +0200, Heinrich Schuchardt wrote:

On 5/6/19 8:11 PM, Atish Patra wrote:

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

[...]

+   "boot arm64/riscv Linux Image image from memory", booti_help_text


%s/Image image/image/

"arm64/riscv" is distracting. If I am on RISC-V I cannot boot an ARM64
image here. Remove the reference to the architecture, please.


Hello,

I'm not sure about the last point - ISTR (please correct me if my
memory betrays me here) that an arm64 U-Boot can in principle be
used to boot either an arm64 or an armv7 kernel, but the commands
are different in those cases (booti for an arm64 "Image" format
kernel and bootz for an armv7 "zImage" format kernel), so having
the information which kernel format is supported by the
respective commands appears useful to me.  If the arm64 kernel
image format would have a distinctive name (like "zImage" on
armv7 or "bzImage" on x86) that would be less problematic, but
with the confusion potential of "boot a Linux Image" (as in the
arm64/riscv-specific "Image" format) vs "boot a Linux image" (as
in generally some form of kernel image), I think explicitly
mentioning the supported architectures makes sense.


In this case you have to ensure that only the *supported* architectures
are mentioned. RISC-V is not supported on ARM64.

Best regards

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

Re: [U-Boot] [PATCH v2 3/3] mach-meson: g12a: add DWC2 peripheral mode support

[Lukasz Majewski]

Hi Neil,

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi Lukasw,
> 
> Le 19/04/2019 08:17, Lukasz Majewski a écrit :
> > Hi Neil,
> >   
> >> Adds support for Amlogic G12A USB Device mode.
> >>
> >> The DWC2 Controller behind the Glue can be connected to an OTG
> >> capable PHY. The Glue setups the PHY mode.
> >>
> >> This patch implements Device mode support by adding a
> >> board_usb_init/cleanup setting up the DWC2 controller and switch
> >> the OTG capable port to Device before starting the DWC2 controller
> >> in Device mode.
> >>
> >> Signed-off-by: Neil Armstrong   
> > 
> > I wanted to apply this series, but it turned out that it depends on:
> > [U-Boot] [PATCH v2 0/6] ARM: meson: Add support for G12A based U200
> > board
> > 
> > Let's wait till the above one is pulled to master.  
> 
> Do you want me to resend the serie rebased on master ?

Yes, please. That would speed up the process considerably.

Thanks in advance for help.

> 
> Neil
> 
> >   
> >> ---
> >>  arch/arm/include/asm/arch-meson/usb.h |  12 +++
> >>  arch/arm/mach-meson/board-g12a.c  | 126
> >> ++ 2 files changed, 138 insertions(+)
> >>  create mode 100644 arch/arm/include/asm/arch-meson/usb.h
> >>
> >> diff --git a/arch/arm/include/asm/arch-meson/usb.h
> >> b/arch/arm/include/asm/arch-meson/usb.h new file mode 100644
> >> index 00..b794b5ce77
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-meson/usb.h
> >> @@ -0,0 +1,12 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> +/*
> >> + * Copyright (C) 2019 BayLibre, SAS
> >> + * Author: Neil Armstrong 
> >> + */
> >> +
> >> +#ifndef __MESON_USB_H__
> >> +#define __MESON_USB_H__
> >> +
> >> +int dwc3_meson_g12a_force_mode(struct udevice *dev, enum
> >> usb_dr_mode mode); +
> >> +#endif /* __MESON_USB_H__ */
> >> diff --git a/arch/arm/mach-meson/board-g12a.c
> >> b/arch/arm/mach-meson/board-g12a.c index fc3764b960..1652970fbd
> >> 100644 --- a/arch/arm/mach-meson/board-g12a.c
> >> +++ b/arch/arm/mach-meson/board-g12a.c
> >> @@ -12,7 +12,12 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >>  #include 
> >> +#include 
> >>  
> >>  DECLARE_GLOBAL_DATA_PTR;
> >>  
> >> @@ -148,3 +153,124 @@ void meson_eth_init(phy_interface_t mode,
> >> unsigned int flags) /* Enable power gate */
> >>clrbits_le32(G12A_MEM_PD_REG_0,
> >> G12A_MEM_PD_REG_0_ETH_MASK); }
> >> +
> >> +#if CONFIG_IS_ENABLED(USB_DWC3_MESON_G12A) && \
> >> +  CONFIG_IS_ENABLED(USB_GADGET_DWC2_OTG)
> >> +static struct dwc2_plat_otg_data meson_g12a_dwc2_data;
> >> +
> >> +int board_usb_init(int index, enum usb_init_type init)
> >> +{
> >> +  struct fdtdec_phandle_args args;
> >> +  const void *blob = gd->fdt_blob;
> >> +  int node, dwc2_node;
> >> +  struct udevice *dev, *clk_dev;
> >> +  struct clk clk;
> >> +  int ret;
> >> +
> >> +  /* find the usb glue node */
> >> +  node = fdt_node_offset_by_compatible(blob, -1,
> >> +
> >> "amlogic,meson-g12a-usb-ctrl");
> >> +  if (node < 0) {
> >> +  debug("Not found usb-control node\n");
> >> +  return -ENODEV;
> >> +  }
> >> +
> >> +  if (!fdtdec_get_is_enabled(blob, node)) {
> >> +  debug("usb is disabled in the device tree\n");
> >> +  return -ENODEV;
> >> +  }
> >> +
> >> +  ret = uclass_get_device_by_of_offset(UCLASS_SIMPLE_BUS,
> >> node, );
> >> +  if (ret) {
> >> +  debug("Not found usb-control device\n");
> >> +  return ret;
> >> +  }
> >> +
> >> +  /* find the dwc2 node */
> >> +  dwc2_node = fdt_node_offset_by_compatible(blob, node,
> >> +
> >> "amlogic,meson-g12a-usb");
> >> +  if (dwc2_node < 0) {
> >> +  debug("Not found dwc2 node\n");
> >> +  return -ENODEV;
> >> +  }
> >> +
> >> +  if (!fdtdec_get_is_enabled(blob, dwc2_node)) {
> >> +  debug("dwc2 is disabled in the device tree\n");
> >> +  return -ENODEV;
> >> +  }
> >> +
> >> +  meson_g12a_dwc2_data.regs_otg = fdtdec_get_addr(blob,
> >> dwc2_node, "reg");
> >> +  if (meson_g12a_dwc2_data.regs_otg == FDT_ADDR_T_NONE) {
> >> +  debug("usbotg: can't get base address\n");
> >> +  return -ENODATA;
> >> +  }
> >> +
> >> +  /* Enable clock */
> >> +  ret = fdtdec_parse_phandle_with_args(blob, dwc2_node,
> >> "clocks",
> >> +   "#clock-cells", 0, 0,
> >> );
> >> +  if (ret) {
> >> +  debug("usbotg has no clocks defined in the device
> >> tree\n");
> >> +  return ret;
> >> +  }
> >> +
> >> +  ret = uclass_get_device_by_of_offset(UCLASS_CLK,
> >> args.node, _dev);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  if (args.args_count != 1) {
> >> +  debug("Can't find clock ID in the device tree\n");
> >> +  return -ENODATA;
> >> +  }
> >> +
> >> +  clk.dev = clk_dev;
> >> +  clk.id = args.args[0];
> >> +
> >> +  ret = clk_enable();
> >> +  if (ret) {
> >> +  debug("Failed to enable usbotg clock\n");
> >> +  return 

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Marek Vasut]

On 5/6/19 9:50 PM, Simon Goldschmidt wrote:
> Am 06.05.2019 um 00:51 schrieb Marek Vasut:
>> On 5/5/19 10:21 PM, Simon Goldschmidt wrote:
>>> Am 05.05.2019 um 22:17 schrieb Marek Vasut:
 On 5/5/19 8:05 AM, Simon Goldschmidt wrote:
>
>
> On 05.05.19 03:42, Marek Vasut wrote:
>> On 5/4/19 9:10 PM, Simon Goldschmidt wrote:
>>> Am 04.05.2019 um 20:43 schrieb Marek Vasut:
 On 5/3/19 10:53 PM, Simon Goldschmidt wrote:
>
>
> Marek Vasut mailto:ma...@denx.de>> schrieb am
> Fr., 3.
> Mai 2019, 22:42:
>
>     On 5/3/19 10:39 PM, Simon Goldschmidt wrote:
>     >
>     >
>     > On 03.05.19 22:35, Marek Vasut wrote:
>     >> On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
>     >>>
>     >>>
>     >>> On 03.05.19 22:28, Marek Vasut wrote:
>      On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
>     > This moves the code that enables the Boot ROM to
> just jump
> to SRAM
>     > instead
>     > of loading SPL from the original boot source on warm
> reboot.
>     >
>     > Instead of always enabling this, an environment
> callback
> for the
>     > env var
>     > "socfpga_reboot_from_sram" is used. This way, the
> behaviour can be
>     > enabled
>     > at runtime and via saved environment.
>     >
>     > Signed-off-by: Simon Goldschmidt
>          >
>     
>      Would that be like a default "reset" command action ?
>      This probably shouldn't be socfpga specific then.
>     >>>
>     >>> No, it's a thing that lives on and influences even the
> soft
>     reset issued
>     >>> by linux "reboot" command. This is something *very*
> socfpga
>     specific.
>     >>
>     >> Hmmm, so isn't this a policy to be configured on the
> Linux
> end ?
>     >
>     > Might be, but it affects U-Boot's 'reset' command as
> well. And
> I guess
>     > it's set up in U-Boot this early to ensure it always
> works.
>
>     Drat, that's right. So there has to be some way to
> agree on
> how the
>     reset works between the kernel and U-Boot ?
>
>     > If it were for me, we could drop writing this magic
> altogether. I just
>     > figured some boards might require it to be written
> somewhere,
> and came
>     > up with a patch that might save those boards with the
> way
> it was
>     before.
>
>     Isn't this magic actually used by bootrom ?
>
>
> Right. It tells the boot rom to jump to ocram on next reboot
> instead of
> loading spl from qspi or mmc. But if that's required or not a good
> idea
> at all depends on many factors. Some of them board related, some
> U-Boot
> related and some Linux related (depending on the hardware and
> drivers
> used).

 Should that be runtime configurable then ?
>>>
>>> Since it might depend on Linux putting the qspi chip into a state
>>> where
>>> it's not accessible by the boot ROM. That might change without
>>> rebuilding U-Boot.
>>
>> If Linux switches the chip into some weird mode the bootrom cannot
>> cope
>> with, it's a reset routing problem. This cannot be fixed in software.
>
> No, it cannot be fixed, but currently there's a workaround for those
> boards and I thought it was worth to keep this workaround, even though
> my own boards will be fixed and not require such a workaround in the
> future :-)

 What's the workaround ?
>>>
>>> The workaround is what this patch is about: the Boot ROM just branches
>>> off to SRAM where it expectes SPL to be still working.
>>
>> But you still cannot communicate with the SPI NOR from your SPL ?
> 
> Well, in most "every day reboot" cases, you can. Just reset BAR or
> 4-byte mode.

"In most" reads as "it's unreliable".

>>> SPL can then e.g. reset 4-byte mode or whatever to still communicate
>>> with the device when Boot ROM can't.
>>
>> Unless, of course, the SPI NOR doesn't interpret the command as data and
>> corrupts something in the flash itself.
> 
> Right, in this case, you can't.
> 
> Don't get me wrong, I'm not arguing for this to be totally right, of
> course I'd rahter get the boards fixed.
> 
> I'm just trying to find a way to 

Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Karsten Merker]

On Mon, May 06, 2019 at 10:06:39PM +0200, Heinrich Schuchardt wrote:
> On 5/6/19 8:11 PM, Atish Patra wrote:
> > This patch adds booti support for RISC-V Linux kernel. The existing
> > bootm method will also continue to work as it is.
[...]
> > +   "boot arm64/riscv Linux Image image from memory", booti_help_text
> 
> %s/Image image/image/
> 
> "arm64/riscv" is distracting. If I am on RISC-V I cannot boot an ARM64
> image here. Remove the reference to the architecture, please.

Hello,

I'm not sure about the last point - ISTR (please correct me if my
memory betrays me here) that an arm64 U-Boot can in principle be
used to boot either an arm64 or an armv7 kernel, but the commands
are different in those cases (booti for an arm64 "Image" format
kernel and bootz for an armv7 "zImage" format kernel), so having
the information which kernel format is supported by the
respective commands appears useful to me.  If the arm64 kernel
image format would have a distinctive name (like "zImage" on
armv7 or "bzImage" on x86) that would be less problematic, but
with the confusion potential of "boot a Linux Image" (as in the
arm64/riscv-specific "Image" format) vs "boot a Linux image" (as
in generally some form of kernel image), I think explicitly
mentioning the supported architectures makes sense.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Re-add support for Aries MCV SoM and MCVEVK board

[Simon Goldschmidt]

Am 06.05.2019 um 17:45 schrieb Wolfgang Grandegger:

Re-add support for Aries Embedded MCV SoM, which is CycloneV based
and the associated MCVEVK baseboard. The board can boot from eMMC.
Ethernet and USB is supported.

The Aries Embedded boards have been removed with commit 03b54997d568
("board/aries: Remove"). I will now take care of them.

Signed-off-by: Wolfgang Grandegger 
CC: Marek Vasut 
CC: Simon Goldschmidt 
---
  .travis.yml  |   2 +-
  arch/arm/dts/Makefile|   1 +
  arch/arm/dts/socfpga_cyclone5_mcv.dtsi   |  22 +
  arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi |  38 ++
  arch/arm/dts/socfpga_cyclone5_mcvevk.dts |  81 +++
  arch/arm/mach-socfpga/Kconfig|   7 +
  board/aries/mcvevk/MAINTAINERS   |   6 +
  board/aries/mcvevk/Makefile  |   7 +
  board/aries/mcvevk/qts/iocsr_config.h| 659 +++
  board/aries/mcvevk/qts/pinmux_config.h   | 218 
  board/aries/mcvevk/qts/pll_config.h  |  84 +++
  board/aries/mcvevk/qts/sdram_config.h| 343 


These files are always a mystery. Would you be able to provide 
(long-lived) link to a simplistic quartus project so that everyone can 
regenerate these?


I'll try to provide such a quartus project for the socrates board, and 
I'd be very happy if the original Intel dev boards could do so as well!


Regards,
Simon


  board/aries/mcvevk/socfpga.c |   5 +
  configs/socfpga_mcvevk_defconfig |  68 +++
  include/configs/socfpga_mcvevk.h | 102 
  15 files changed, 1642 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/socfpga_cyclone5_mcv.dtsi
  create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
  create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk.dts
  create mode 100644 board/aries/mcvevk/MAINTAINERS
  create mode 100644 board/aries/mcvevk/Makefile
  create mode 100644 board/aries/mcvevk/qts/iocsr_config.h
  create mode 100644 board/aries/mcvevk/qts/pinmux_config.h
  create mode 100644 board/aries/mcvevk/qts/pll_config.h
  create mode 100644 board/aries/mcvevk/qts/sdram_config.h
  create mode 100644 board/aries/mcvevk/socfpga.c
  create mode 100644 configs/socfpga_mcvevk_defconfig
  create mode 100644 include/configs/socfpga_mcvevk.h

diff --git a/.travis.yml b/.travis.yml
index 8bd49ef..714b92e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -230,7 +230,7 @@ matrix:
  - BUILDMAN="sun50i"
  - name: "buildman catch-all ARM"
env:
-- BUILDMAN="arm -x 
arm11,arm7,arm9,aarch64,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"
+- BUILDMAN="arm -x 
arm11,arm7,arm9,aarch64,aries,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"
  - name: "buildman sandbox x86"
env:
  - BUILDMAN="sandbox x86"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..9a6c4e2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,6 +274,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
  dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_arria5_socdk.dtb\
socfpga_arria10_socdk_sdmmc.dtb \
+   socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_dbm_soc1.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_mcv.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
new file mode 100644
index 000..bd92806
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Marek Vasut 
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Aries/DENX MCV";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   memory@0 {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1 GiB */
+   };
+};
+
+ {/* On-SoM eMMC */
+   bus-width = <8>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
new file mode 100644
index 000..1afaa86
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2015 Marek Vasut 
+ * Copyright (C) 2018 Wolfgang Grandegger 
+ */
+
+/{
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   clock-frequency = <1>;
+   u-boot,dm-pre-reloc;
+};
+

[U-Boot] [PATCH v2 2/2] sysreset: add support for socfpga sysreset

[Simon Goldschmidt]

This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
to a UCLASS_SYSRESET based dm driver.

A side effect is that gen5 and a10 can now select between cold and warm
reset.

Signed-off-by: Simon Goldschmidt 
---

Changes in v2:
- adapt to patch that separates drivers/sysreset from drivers/misc
  for SPL: select SPL_SYSRESET_SUPPORT, not SPL_DRIVERS_MISC_SUPPORT
- separate gen5/a10 driver from s10 driver
- as sysreset is a function of rstmgr, bind the sysreset drivers
  from rstmgr to get the base address instead of hardcoding it

 arch/arm/Kconfig|  4 ++
 arch/arm/mach-socfpga/Makefile  |  1 -
 arch/arm/mach-socfpga/reset_manager.c   | 41 --
 drivers/reset/reset-socfpga.c   | 19 +
 drivers/sysreset/Kconfig| 14 +++
 drivers/sysreset/Makefile   |  2 +
 drivers/sysreset/sysreset_socfpga.c | 56 +
 drivers/sysreset/sysreset_socfpga_s10.c | 29 +
 8 files changed, 124 insertions(+), 42 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
 create mode 100644 drivers/sysreset/sysreset_socfpga.c
 create mode 100644 drivers/sysreset/sysreset_socfpga_s10.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49f01f1ff1..2bcec22b40 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -829,10 +829,14 @@ config ARCH_SOCFPGA
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
select SPL_SERIAL_SUPPORT
+   select SPL_SYSRESET_SUPPORT
select SPL_WATCHDOG_SUPPORT
select SUPPORT_SPL
select SYS_NS16550
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+   select SYSRESET
+   select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+   select SYSRESET_SOCFPGA_STRATIX10 if TARGET_SOCFPGA_STRATIX10
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..fc1181cb27 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -8,7 +8,6 @@
 obj-y  += board.o
 obj-y  += clock_manager.o
 obj-y  += misc.o
-obj-y  += reset_manager.o
 
 ifdef CONFIG_TARGET_SOCFPGA_GEN5
 obj-y  += clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/reset_manager.c 
b/arch/arm/mach-socfpga/reset_manager.c
deleted file mode 100644
index e0a01ed07a..00
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- *  Copyright (C) 2013 Altera Corporation 
- */
-
-
-#include 
-#include 
-#include 
-
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-#include 
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-static const struct socfpga_reset_manager *reset_manager_base =
-   (void *)SOCFPGA_RSTMGR_ADDRESS;
-#endif
-
-/*
- * Write the reset manager register to cause reset
- */
-void reset_cpu(ulong addr)
-{
-   /* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-   puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
-   mbox_reset_cold();
-#else
-   writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
-  _manager_base->ctrl);
-#endif
-   /*
-* infinite loop here as watchdog will trigger and reset
-* the processor
-*/
-   while (1)
-   ;
-}
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index cb8312619f..f49f064574 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -132,6 +133,23 @@ static int socfpga_reset_remove(struct udevice *dev)
return 0;
 }
 
+static int socfpga_reset_bind(struct udevice *dev)
+{
+   int ret;
+   struct udevice *sys_child;
+
+   /*
+* The sysreset driver does not have a device node, so bind it here.
+* Bind it to the node, too, so that it can get its base address.
+*/
+   ret = device_bind_driver_to_node(dev, "socfpga_sysreset", "sysreset",
+dev->node, _child);
+   if (ret)
+   debug("Warning: No sysreset driver: ret=%d\n", ret);
+
+   return 0;
+}
+
 static const struct udevice_id socfpga_reset_match[] = {
{ .compatible = "altr,rst-mgr" },
{ /* sentinel */ },
@@ -141,6 +159,7 @@ U_BOOT_DRIVER(socfpga_reset) = {
.name = "socfpga-reset",
.id = UCLASS_RESET,
.of_match = socfpga_reset_match,
+   .bind = socfpga_reset_bind,
.probe = socfpga_reset_probe,
.priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
.ops = _reset_ops,
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..5b8402ccae 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ 

[U-Boot] [PATCH v2 1/2] arm: socfpga: rst: add register definition for cold reset

[Simon Goldschmidt]

This adds a define for the bit in rstmgr's ctrl regiser that issues
a cold reset (we had a define for the warm reset bit only) in preparation
for a proper sysrese driver.

Signed-off-by: Simon Goldschmidt 
Series changes: 2
- separate this patch to the register descriptions from the actual
  sysreset driver patch
---

Changes in v2: None

 arch/arm/mach-socfpga/include/mach/reset_manager.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 42beaecdd6..6ad037e325 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -11,6 +11,7 @@ void reset_cpu(ulong addr);
 void socfpga_per_reset(u32 reset, int set);
 void socfpga_per_reset_all(void);
 
+#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0
 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
 
 /*
-- 
2.20.1

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

Re: [U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Heinrich Schuchardt]

On 5/6/19 8:11 PM, Atish Patra wrote:

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.

https://patchwork.kernel.org/patch/10925543/

Tested on HiFive Unleashed and QEMU.

Signed-off-by: Atish Patra 
Reviewed-by: Tom Rini 
Tested-by: Karsten Merker 
---
Changes from v3->v4
1. Rebased on top of master to avoid git am errors.

Changes from v2->v3
1. Updated the image header structure as per kernel patch.
2. Removed Image.gz support as it will be added as separate RFC patch.
---
  arch/riscv/lib/Makefile |  1 +
  arch/riscv/lib/image.c  | 55 +
  cmd/Kconfig |  2 +-
  cmd/booti.c |  8 --
  4 files changed, 63 insertions(+), 3 deletions(-)
  create mode 100644 arch/riscv/lib/image.c

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 1c332db436a9..6ae6ebbeafda 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -7,6 +7,7 @@
  # Rick Chen, Andes Technology Corporation 

  obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
  obj-$(CONFIG_CMD_GO) += boot.o
  obj-y += cache.o
  obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
new file mode 100644
index ..d063beb7dfbe
--- /dev/null
+++ b/arch/riscv/lib/image.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ * Authors:
+ * Atish Patra 
+ * Based on arm/lib/image.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* ASCII version of "RISCV" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+
+struct linux_image_h {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset */
+   uint64_timage_size; /* Effective Image size */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tmagic;  /* Magic number */
+   uint32_tres4;   /* reserved */
+   uint32_tres5;   /* reserved */
+};
+
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+   bool force_reloc)
+{
+   struct linux_image_h *lhdr;
+
+   lhdr = (struct linux_image_h *)map_sysmem(image, 0);
+
+   if (lhdr->magic != LINUX_RISCV_IMAGE_MAGIC) {
+   puts("Bad Linux RISCV Image magic!\n");
+   return -EINVAL;
+   }
+
+   if (lhdr->image_size == 0) {
+   puts("Image lacks image_size field, error!\n");
+   return -EINVAL;
+   }
+   *size = lhdr->image_size;
+   *relocated_addr = gd->ram_base + lhdr->text_offset;
+
+   unmap_sysmem(lhdr);
+
+   return 0;
+}
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 069e0ea7300b..4e11e0f404c8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -223,7 +223,7 @@ config CMD_BOOTZ

  config CMD_BOOTI
bool "booti"
-   depends on ARM64
+   depends on ARM64 || RISCV
default y
help
  Boot an AArch64 Linux Kernel image from memory.
diff --git a/cmd/booti.c b/cmd/booti.c
index 04353b68eccc..5e902993865b 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -77,7 +77,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
bootm_disable_interrupts();

images.os.os = IH_OS_LINUX;
+#ifdef CONFIG_RISCV_SMODE
+   images.os.arch = IH_ARCH_RISCV;
+#elif CONFIG_ARM64
images.os.arch = IH_ARCH_ARM64;
+#endif
ret = do_bootm_states(cmdtp, flag, argc, argv,
  #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
  BOOTM_STATE_RAMDISK |
@@ -92,7 +96,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
  #ifdef CONFIG_SYS_LONGHELP
  static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-   "- boot arm64 Linux Image stored in memory\n"
+   "- boot arm64/riscv Linux Image stored in memory\n"


Why would you repeat the short description? Just remove this line.



"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
@@ -107,5 +111,5 @@ static char booti_help_text[] =

  U_BOOT_CMD(
booti,  CONFIG_SYS_MAXARGS, 1,  do_booti,
-   "boot arm64 Linux Image image from memory", booti_help_text
+   "boot arm64/riscv Linux Image image from memory", booti_help_text


%s/Image image/image/

"arm64/riscv" is 

Re: [U-Boot] [PATCH v2 2/2] regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs

[Simon Glass]

Hi Matti,

On Wed, 24 Apr 2019 at 23:58, Vaittinen, Matti
 wrote:
>
> Hello Simon and thanks again for taking the time to check this =)
>
> On Wed, 2019-04-24 at 17:58 -0600, Simon Glass wrote:
> > HI Matti,
> >
> > On Wed, 24 Apr 2019 at 06:37, Matti Vaittinen
> >  wrote:
> > >
> > > BD71837 and BD71847 is PMIC intended for powering single-core,
> > > dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
> > > is used for example on NXP imx8mm EVK.
> > >
> > > Add regulator driver for ROHM BD71837 and BD71847 PMICs.
> > > BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
> > > version containing 6 bucks and 6 LDOs. Voltages for DVS
> >
> > This is great info and I think it should be in your Kconfig help -
> > i.e.a bit more detail in your description of the chip.
>
> Good idea. I'll do so in the next version.
>
> > > +static int bd718x7_probe(struct udevice *dev)
> > > +{
> > > +   int ret;
> > > +   u8 unlock;
> > > +
> > > +   /* Unlock the PMIC regulator control before probing the
> > > children */
> > > +   ret = pmic_reg_read(dev, BD718XX_REGLOCK);
> > > +   if (ret < 0) {
> > > +   debug("%s: %s Failed to read lock register, error
> > > %d\n",
> > > + __func__, dev->name, ret);
> > > +   return ret;
> > > +   }
> > > +
> > > +   unlock = ret;
> > > +   unlock &= ~(BD718XX_REGLOCK_PWRSEQ | BD718XX_REGLOCK_VREG);
> > > +
> > > +   ret = pmic_reg_write(dev, BD718XX_REGLOCK, unlock);
> >
> > Can you use pmic_clrsetbits() ?
>
> Sure. I'll fix this too. Makes this much nicer.
>
> > > index 00..060e6efe74
> > > --- /dev/null
> > > +++ b/drivers/power/regulator/bd71837.c
> > > @@ -0,0 +1,469 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2019 ROHM Semiconductors
> > > + *
> > > + * ROHM BD71837 regulator driver
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> >
> > Drop this?
>
> errno.h? I return -EINVAL from few of the functions. Or do you mean
> i2c.h? I think that can be dropped, thanks.

I mean that errno.h should be included already?

>
> >
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> >
> > Put above power/pmic to keep ordering
>
> I'll do that.
>
> > >
> > > +static int vrange_find_value(struct bd71837_vrange *r, u8 sel,
> >
> > Can you use uint instea of u8?
>
> I'll replace u8 with uint8_t for all occurrences in this file. I
> personally prefer uint8_t. I've got this u8 infection from the linux
> kernel code where u8 seems to be preferred =)

No, u8 is preferred over uint8_t.

I mean that you shouldn't be using u8 for arguments. You should use
uint (unsigned int).

>
> > > +
> > > +static int bd71837_set_value(struct udevice *dev, int uvolt)
> > > +{
> > > +   u8 sel;
> > > +   u8 range;
> >
> > and here
> >
> > > +   int i;
> > > +   int not_found = 1;
> >
> > I think the logic would be easier if you used 'found'
>
> I see your point =) not_found became not_found just because return
> value 0 from vrange_find_selector() (or pretty much any other function
> I write) means success. So direct assignment to variable made it
> 'not_found' :] But "double negation" (!not_) is indeed a bit
> difficult. I'll change this too.

[..]

> Simon says - in Latin please.
> "non cogito me" dixit Rene Descarte, deinde evanescavit
>
> (Thanks for the translation Simon)

I hope it is close :-)

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

Re: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

[Simon Goldschmidt]

Am 06.05.2019 um 00:51 schrieb Marek Vasut:

On 5/5/19 10:21 PM, Simon Goldschmidt wrote:

Am 05.05.2019 um 22:17 schrieb Marek Vasut:

On 5/5/19 8:05 AM, Simon Goldschmidt wrote:



On 05.05.19 03:42, Marek Vasut wrote:

On 5/4/19 9:10 PM, Simon Goldschmidt wrote:

Am 04.05.2019 um 20:43 schrieb Marek Vasut:

On 5/3/19 10:53 PM, Simon Goldschmidt wrote:



Marek Vasut mailto:ma...@denx.de>> schrieb am
Fr., 3.
Mai 2019, 22:42:

    On 5/3/19 10:39 PM, Simon Goldschmidt wrote:
    >
    >
    > On 03.05.19 22:35, Marek Vasut wrote:
    >> On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
    >>>
    >>>
    >>> On 03.05.19 22:28, Marek Vasut wrote:
     On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
    > This moves the code that enables the Boot ROM to
just jump
to SRAM
    > instead
    > of loading SPL from the original boot source on warm
reboot.
    >
    > Instead of always enabling this, an environment
callback
for the
    > env var
    > "socfpga_reboot_from_sram" is used. This way, the
behaviour can be
    > enabled
    > at runtime and via saved environment.
    >
    > Signed-off-by: Simon Goldschmidt
    mailto:simon.k.r.goldschm...@gmail.com>>
    
     Would that be like a default "reset" command action ?
     This probably shouldn't be socfpga specific then.
    >>>
    >>> No, it's a thing that lives on and influences even the
soft
    reset issued
    >>> by linux "reboot" command. This is something *very*
socfpga
    specific.
    >>
    >> Hmmm, so isn't this a policy to be configured on the Linux
end ?
    >
    > Might be, but it affects U-Boot's 'reset' command as
well. And
I guess
    > it's set up in U-Boot this early to ensure it always works.

    Drat, that's right. So there has to be some way to agree on
how the
    reset works between the kernel and U-Boot ?

    > If it were for me, we could drop writing this magic
altogether. I just
    > figured some boards might require it to be written
somewhere,
and came
    > up with a patch that might save those boards with the way
it was
    before.

    Isn't this magic actually used by bootrom ?


Right. It tells the boot rom to jump to ocram on next reboot
instead of
loading spl from qspi or mmc. But if that's required or not a good
idea
at all depends on many factors. Some of them board related, some
U-Boot
related and some Linux related (depending on the hardware and
drivers
used).


Should that be runtime configurable then ?


Since it might depend on Linux putting the qspi chip into a state
where
it's not accessible by the boot ROM. That might change without
rebuilding U-Boot.


If Linux switches the chip into some weird mode the bootrom cannot cope
with, it's a reset routing problem. This cannot be fixed in software.


No, it cannot be fixed, but currently there's a workaround for those
boards and I thought it was worth to keep this workaround, even though
my own boards will be fixed and not require such a workaround in the
future :-)


What's the workaround ?


The workaround is what this patch is about: the Boot ROM just branches
off to SRAM where it expectes SPL to be still working.


But you still cannot communicate with the SPI NOR from your SPL ?


Well, in most "every day reboot" cases, you can. Just reset BAR or 
4-byte mode.





SPL can then e.g. reset 4-byte mode or whatever to still communicate
with the device when Boot ROM can't.


Unless, of course, the SPI NOR doesn't interpret the command as data and
corrupts something in the flash itself.


Right, in this case, you can't.

Don't get me wrong, I'm not arguing for this to be totally right, of 
course I'd rahter get the boards fixed.


I'm just trying to find a way to keep this code in for people depending 
on it. I know we have some broken boards that depend on it. I could live 
with writing this magic in our private board code, but it's a bummer for 
other people upgrading if we removed it...


Regards,
Simon




Of course the downside is that SRAM might be overwritten meanwhile,
which is why it's a workaround only, not the best idea how to do things...

Regards,
Simon





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

Re: [U-Boot] [PATCH v2 3/3] mach-meson: g12a: add DWC2 peripheral mode support

[Neil Armstrong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Lukasw,

Le 19/04/2019 08:17, Lukasz Majewski a écrit :
> Hi Neil,
> 
>> Adds support for Amlogic G12A USB Device mode.
>>
>> The DWC2 Controller behind the Glue can be connected to an OTG
>> capable PHY. The Glue setups the PHY mode.
>>
>> This patch implements Device mode support by adding a
>> board_usb_init/cleanup setting up the DWC2 controller and switch the
>> OTG capable port to Device before starting the DWC2 controller in
>> Device mode.
>>
>> Signed-off-by: Neil Armstrong 
> 
> I wanted to apply this series, but it turned out that it depends on:
> [U-Boot] [PATCH v2 0/6] ARM: meson: Add support for G12A based U200
> board
> 
> Let's wait till the above one is pulled to master.

Do you want me to resend the serie rebased on master ?

Neil

> 
>> ---
>>  arch/arm/include/asm/arch-meson/usb.h |  12 +++
>>  arch/arm/mach-meson/board-g12a.c  | 126
>> ++ 2 files changed, 138 insertions(+)
>>  create mode 100644 arch/arm/include/asm/arch-meson/usb.h
>>
>> diff --git a/arch/arm/include/asm/arch-meson/usb.h
>> b/arch/arm/include/asm/arch-meson/usb.h new file mode 100644
>> index 00..b794b5ce77
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arch-meson/usb.h
>> @@ -0,0 +1,12 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * Copyright (C) 2019 BayLibre, SAS
>> + * Author: Neil Armstrong 
>> + */
>> +
>> +#ifndef __MESON_USB_H__
>> +#define __MESON_USB_H__
>> +
>> +int dwc3_meson_g12a_force_mode(struct udevice *dev, enum usb_dr_mode
>> mode); +
>> +#endif /* __MESON_USB_H__ */
>> diff --git a/arch/arm/mach-meson/board-g12a.c
>> b/arch/arm/mach-meson/board-g12a.c index fc3764b960..1652970fbd 100644
>> --- a/arch/arm/mach-meson/board-g12a.c
>> +++ b/arch/arm/mach-meson/board-g12a.c
>> @@ -12,7 +12,12 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>>  
>>  DECLARE_GLOBAL_DATA_PTR;
>>  
>> @@ -148,3 +153,124 @@ void meson_eth_init(phy_interface_t mode,
>> unsigned int flags) /* Enable power gate */
>>  clrbits_le32(G12A_MEM_PD_REG_0, G12A_MEM_PD_REG_0_ETH_MASK);
>>  }
>> +
>> +#if CONFIG_IS_ENABLED(USB_DWC3_MESON_G12A) && \
>> +CONFIG_IS_ENABLED(USB_GADGET_DWC2_OTG)
>> +static struct dwc2_plat_otg_data meson_g12a_dwc2_data;
>> +
>> +int board_usb_init(int index, enum usb_init_type init)
>> +{
>> +struct fdtdec_phandle_args args;
>> +const void *blob = gd->fdt_blob;
>> +int node, dwc2_node;
>> +struct udevice *dev, *clk_dev;
>> +struct clk clk;
>> +int ret;
>> +
>> +/* find the usb glue node */
>> +node = fdt_node_offset_by_compatible(blob, -1,
>> +
>> "amlogic,meson-g12a-usb-ctrl");
>> +if (node < 0) {
>> +debug("Not found usb-control node\n");
>> +return -ENODEV;
>> +}
>> +
>> +if (!fdtdec_get_is_enabled(blob, node)) {
>> +debug("usb is disabled in the device tree\n");
>> +return -ENODEV;
>> +}
>> +
>> +ret = uclass_get_device_by_of_offset(UCLASS_SIMPLE_BUS,
>> node, );
>> +if (ret) {
>> +debug("Not found usb-control device\n");
>> +return ret;
>> +}
>> +
>> +/* find the dwc2 node */
>> +dwc2_node = fdt_node_offset_by_compatible(blob, node,
>> +
>> "amlogic,meson-g12a-usb");
>> +if (dwc2_node < 0) {
>> +debug("Not found dwc2 node\n");
>> +return -ENODEV;
>> +}
>> +
>> +if (!fdtdec_get_is_enabled(blob, dwc2_node)) {
>> +debug("dwc2 is disabled in the device tree\n");
>> +return -ENODEV;
>> +}
>> +
>> +meson_g12a_dwc2_data.regs_otg = fdtdec_get_addr(blob,
>> dwc2_node, "reg");
>> +if (meson_g12a_dwc2_data.regs_otg == FDT_ADDR_T_NONE) {
>> +debug("usbotg: can't get base address\n");
>> +return -ENODATA;
>> +}
>> +
>> +/* Enable clock */
>> +ret = fdtdec_parse_phandle_with_args(blob, dwc2_node,
>> "clocks",
>> + "#clock-cells", 0, 0,
>> );
>> +if (ret) {
>> +debug("usbotg has no clocks defined in the device
>> tree\n");
>> +return ret;
>> +}
>> +
>> +ret = uclass_get_device_by_of_offset(UCLASS_CLK, args.node,
>> _dev);
>> +if (ret)
>> +return ret;
>> +
>> +if (args.args_count != 1) {
>> +debug("Can't find clock ID in the device tree\n");
>> +return -ENODATA;
>> +}
>> +
>> +clk.dev = clk_dev;
>> +clk.id = args.args[0];
>> +
>> +ret = clk_enable();
>> +if (ret) {
>> +debug("Failed to enable usbotg clock\n");
>> +return ret;
>> +}
>> +
>> +meson_g12a_dwc2_data.rx_fifo_sz = fdtdec_get_int(blob,
>> dwc2_node,
>> +
>> "g-rx-fifo-size", 0);
>> +meson_g12a_dwc2_data.np_tx_fifo_sz = fdtdec_get_int(blob,
>> dwc2_node,
>> +"g-np-tx-fifo-size",
>> 0);
>> +

Re: [U-Boot] [v3 PATCH] RISCV: image: Add booti support.

[Atish Patra]

On 5/5/19 4:07 AM, Karsten Merker wrote:

On Wed, May 01, 2019 at 01:07:31PM -0700, Atish Patra wrote:

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.

https://patchwork.kernel.org/patch/10925543/

Tested on HiFive Unleashed and QEMU.

Signed-off-by: Atish Patra 


Hello,

the patch (both directly from my inbox as well as from
patchwork) appears to be mangled and doesn't apply cleanly:

   Applying: RISCV: image: Add booti support.
   error: patch failed: cmd/booti.c:77
   error: cmd/booti.c: patch does not apply
   Patch failed at 0001 RISCV: image: Add booti support.



I have fixed the patch and sent a v4. That should cleanly apply on top 
of master.



I have manually applied the changes on top of 2019.07-rc1 and
run a number of tests together with the corresponding kernel
patch (https://patchwork.kernel.org/patch/10925543/). With
the patch applied I can successfully boot a kernel and an
initramfs with booti on a qemu-system-riscv64 "virt" machine:



Thanks for testing the patch.

Regards,
Atish


OpenSBI v0.3 (May  4 2019 20:32:00)
_  _
   / __ \  / |  _ \_   _|
  | |  | |_ __   ___ _ __ | (___ | |_) || |
  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
  | |__| | |_) |  __/ | | |) | |_) || |_
   \/| .__/ \___|_| |_|_/|/_|
 | |
 |_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-g6b6a8d27ea-dirty (May 05 2019 - 01:05:15 +0200)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  8 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0
=> load virtio 0:1 ${kernel_addr_r} /boot/vmlinux-5.0.0-trunk-riscv64
9073676 bytes read in 5 ms (1.7 GiB/s)
=> load virtio 0:1 ${ramdisk_addr_r} /boot/initrd.img-5.0.0-trunk-riscv64
45823535 bytes read in 14 ms (3 GiB/s)
=> booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdtcontroladdr}
## Flattened Device Tree blob at ff77bd30
Booting using the fdt blob at 0xff77bd30
Using Device Tree in place at ff77bd30, end ff77fda5

Starting kernel ...

[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] No DTB passed to the kernel
[0.00] Linux version 5.0.0-trunk-riscv64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP 
Debian 5.0.10-1~exp1 (2019-03-22)
[0.00] Initial ramdisk at: 0x(ptrval) (45823535 bytes)
[...]

Tested-by: Karsten Merker 

Regards,
Karsten



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

[U-Boot] [v4 PATCH] RISCV: image: Add booti support

[Atish Patra]

This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.

https://patchwork.kernel.org/patch/10925543/

Tested on HiFive Unleashed and QEMU.

Signed-off-by: Atish Patra 
Reviewed-by: Tom Rini 
Tested-by: Karsten Merker 
---
Changes from v3->v4
1. Rebased on top of master to avoid git am errors.

Changes from v2->v3
1. Updated the image header structure as per kernel patch.
2. Removed Image.gz support as it will be added as separate RFC patch.
---
 arch/riscv/lib/Makefile |  1 +
 arch/riscv/lib/image.c  | 55 +
 cmd/Kconfig |  2 +-
 cmd/booti.c |  8 --
 4 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv/lib/image.c

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 1c332db436a9..6ae6ebbeafda 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -7,6 +7,7 @@
 # Rick Chen, Andes Technology Corporation 
 
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
 obj-$(CONFIG_CMD_GO) += boot.o
 obj-y  += cache.o
 obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
new file mode 100644
index ..d063beb7dfbe
--- /dev/null
+++ b/arch/riscv/lib/image.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ * Authors:
+ * Atish Patra 
+ * Based on arm/lib/image.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* ASCII version of "RISCV" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+
+struct linux_image_h {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset */
+   uint64_timage_size; /* Effective Image size */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tmagic;  /* Magic number */
+   uint32_tres4;   /* reserved */
+   uint32_tres5;   /* reserved */
+};
+
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+   bool force_reloc)
+{
+   struct linux_image_h *lhdr;
+
+   lhdr = (struct linux_image_h *)map_sysmem(image, 0);
+
+   if (lhdr->magic != LINUX_RISCV_IMAGE_MAGIC) {
+   puts("Bad Linux RISCV Image magic!\n");
+   return -EINVAL;
+   }
+
+   if (lhdr->image_size == 0) {
+   puts("Image lacks image_size field, error!\n");
+   return -EINVAL;
+   }
+   *size = lhdr->image_size;
+   *relocated_addr = gd->ram_base + lhdr->text_offset;
+
+   unmap_sysmem(lhdr);
+
+   return 0;
+}
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 069e0ea7300b..4e11e0f404c8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -223,7 +223,7 @@ config CMD_BOOTZ
 
 config CMD_BOOTI
bool "booti"
-   depends on ARM64
+   depends on ARM64 || RISCV
default y
help
  Boot an AArch64 Linux Kernel image from memory.
diff --git a/cmd/booti.c b/cmd/booti.c
index 04353b68eccc..5e902993865b 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -77,7 +77,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
bootm_disable_interrupts();
 
images.os.os = IH_OS_LINUX;
+#ifdef CONFIG_RISCV_SMODE
+   images.os.arch = IH_ARCH_RISCV;
+#elif CONFIG_ARM64
images.os.arch = IH_ARCH_ARM64;
+#endif
ret = do_bootm_states(cmdtp, flag, argc, argv,
 #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
  BOOTM_STATE_RAMDISK |
@@ -92,7 +96,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 #ifdef CONFIG_SYS_LONGHELP
 static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-   "- boot arm64 Linux Image stored in memory\n"
+   "- boot arm64/riscv Linux Image stored in memory\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
@@ -107,5 +111,5 @@ static char booti_help_text[] =
 
 U_BOOT_CMD(
booti,  CONFIG_SYS_MAXARGS, 1,  do_booti,
-   "boot arm64 Linux Image image from memory", booti_help_text
+   "boot arm64/riscv Linux Image image from memory", booti_help_text
 );
-- 
2.21.0

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

Re: [U-Boot] [PATCH 5/6] ARM: imx: novena: Enable DM USB

[Vagrant Cascadian]

On 2019-05-06, Marek Vasut wrote:
> On 5/6/19 5:26 AM, Vagrant Cascadian wrote:
>> On 2019-05-06, Marek Vasut wrote:
>>> Enable DM USB support on iMX6Q Novena.
...
>> => load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image
>> data abort
>> pc : []  lr : []
>> reloc pc : [<17832f0e>]lr : [<17832991>]
>
> Where does it crash ? arm-...objdump -d u-boot and look for the reloc_pc
> value, it should tell you in which function the crash occurred .

I didn't find 17832f0e in the objdump output... I'll try a build
directly from upstream sources rather than using the debian packaging to
make sure I'm not breaking something in the packaging.

Also, interesting enough, only one of the four USB ports is triggering
this issue for me; front, internal, and "ext2" (near the corner of the
board) all work, but "ext1" doesn't (between "ext2" and the full-size
SD/hdmi/microUSB/audio ports).


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] arm: socfpga: Re-add support for Aries MCV SoM and MCVEVK board

[Marek Vasut]

On 5/6/19 5:45 PM, Wolfgang Grandegger wrote:
> Re-add support for Aries Embedded MCV SoM, which is CycloneV based
> and the associated MCVEVK baseboard. The board can boot from eMMC.
> Ethernet and USB is supported.

I thought the board is now called MCVEVP , not MCVEVK ?

> The Aries Embedded boards have been removed with commit 03b54997d568
> ("board/aries: Remove"). I will now take care of them.

If the DTs come from Linux, the exact commit should be stated here.

[...]

> diff --git a/.travis.yml b/.travis.yml
> index 8bd49ef..714b92e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -230,7 +230,7 @@ matrix:
>  - BUILDMAN="sun50i"
>  - name: "buildman catch-all ARM"
>env:
> -- BUILDMAN="arm -x 
> arm11,arm7,arm9,aarch64,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"
> +- BUILDMAN="arm -x 
> arm11,arm7,arm9,aarch64,aries,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"

What's this about ?

>  - name: "buildman sandbox x86"
>env:
>  - BUILDMAN="sandbox x86"

[...]

> diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi 
> b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
> new file mode 100644
> index 000..1afaa86
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * U-Boot additions
> + *
> + * Copyright (C) 2015 Marek Vasut 
> + * Copyright (C) 2018 Wolfgang Grandegger 

It's 2019 now .
[...]

> diff --git a/board/aries/mcvevk/MAINTAINERS b/board/aries/mcvevk/MAINTAINERS
> new file mode 100644
> index 000..0e97941
> --- /dev/null
> +++ b/board/aries/mcvevk/MAINTAINERS
> @@ -0,0 +1,6 @@
> +Aries MCVEVK BOARD
> +M:   Wolfgang Grandegger 
> +S:   Maintained
> +F:   board/aries/mcvevk/
> +F:   include/configs/socfpga_mcvevk.h
> +F:   configs/socfpga_mcvevk_defconfig

DTs are missing in the list

[...]

> +/* Extra Environment */
> +#define CONFIG_EXTRA_ENV_SETTINGS\
> + "consdev=ttyS0\0"   \
> + "baudrate=115200\0" \
> + "bootscript=boot.scr\0" \
> + "bootdev=/dev/mmcblk0p2\0"  \
> + "rootdev=/dev/mmcblk0p3\0"  \

Can you switch this to UUID/PARTUUID instead of ad-hoc hard-coded eMMC
partitions ?

[...]

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

Re: [U-Boot] [PATCH v5] ARM: am335x: Add phyCORE AM335x R2 support

[Tom Rini]

On Mon, May 06, 2019 at 06:44:48PM +0200, Niel Fourie wrote:
> Hi Tom,
> 
> On 5/6/19 4:18 PM, Tom Rini wrote:
> >On Mon, May 06, 2019 at 04:02:53PM +0200, Niel Fourie wrote:
> >
> >>Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
> >>phyBOARD-Wega AM335x.
> >>
> >>CPU  : AM335X-GP rev 2.1
> >>Model: Phytec AM335x phyBOARD-WEGA
> >>DRAM:  256 MiB
> >>NAND:  256 MiB
> >>MMC:   OMAP SD/MMC: 0
> >>eth0: ethernet@4a10
> >>
> >>Working:
> >>  - Eth0
> >>  - i2C
> >>  - MMC/SD
> >>  - NAND
> >>  - UART
> >>  - USB (host)
> >>
> >>Device trees were taken from Linux mainline:
> >>commit 37624b58542f ("Linux 5.1-rc7")
> >>
> >>Signed-off-by: Niel Fourie 
> >>+void sdram_init(void)
> >>+{
> >>+   int ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
> >>+
> >>+   if (fdtdec_setup_mem_size_base())
> >>+   gd->ram_size = SZ_256M;
> >>+
> >>+   switch (gd->ram_size) {
> >>+   case SZ_1G:
> >>+   ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
> >>+   break;
> >>+   case SZ_512M:
> >>+   ram_type_index = PHYCORE_R2_MT41K256M16TW107IT_512MB;
> >>+   break;
> >>+   case SZ_256M:
> >>+   default:
> >>+   ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
> >>+   break;
> >>+   }
> >>+
> >>+   config_ddr(DDR_CLK_MHZ, ,
> >>+  _timings[ram_type_index].ddr3_data,
> >>+  _cmd_ctrl_data,
> >>+  _timings[ram_type_index].ddr3_emif_reg_data, 0);
> >>+}
> >
> >This is wrong.  sdram_init() is called by
> >arch/arm/mach-omap2/am33xx/board.c::dram_init() which then sets
> >gd->ram_size based on what get_ram_size() determines.  So this is all
> >just a wrapper around how the various parts of the am33xx generations
> >call some form of config_ddr().  And what you have here is a lot of
> >unused code about which module provides how much memory.  I assume
> >there's some run-time method to determine which module you're on and
> >thus determine that correct parameters to pass in for the chip that's in
> >use.  If you're not there yet then just make sdram_init() call
> >config_ddr(...) with the correct enum for the 256M chip and then update
> >this when you have real detection.
> 
> Thanks for that input, you are right. I could not find any documented way to
> detect the exact module we are running on, but as you pointed out we can use
> get_ram_size() to find the size of the installed RAM. This is in fact
> exactly what barebox did, I just missed it. How is this for a replacement of
> the above?
> 
> void sdram_init(void)
> {
>   /* Configure memory to maximum supported size for detection */
>   int ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
>   config_ddr(DDR_CLK_MHZ, ,
>  _timings[ram_type_index].ddr3_data,
>  _cmd_ctrl_data,
>  _timings[ram_type_index].ddr3_emif_reg_data,
>  0);
> 
>   /* Detect memory physically present */
>   gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
>   CONFIG_MAX_RAM_BANK_SIZE);
> 
>   /* Reconfigure memory for actual detected size */
>   switch (gd->ram_size) {
>   case SZ_1G:
>   ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
>   break;
>   case SZ_512M:
>   ram_type_index = PHYCORE_R2_MT41K256M16TW107IT_512MB;
>   break;
>   case SZ_256M:
>   default:
>   ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
>   break;
>   }
>   config_ddr(DDR_CLK_MHZ, ,
>  _timings[ram_type_index].ddr3_data,
>  _cmd_ctrl_data,
>  _timings[ram_type_index].ddr3_emif_reg_data,
>  0);
> }
> 
> The ugliest part of this is, as you pointed out, that directly after this is
> called, get_ram_size() will be called again from sdram_init(). But it at
> least noninvasive, and no longer requires the device tree.

I don't think it's safe to call config_ddr twice, especially with the
possibly wrong parameters.  What's barebox doing in this case, being
told the presumably correct DDR size in the device tree?

-- 
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] ata: ahci: fix memory leak

[Simon Glass]

On Mon, 6 May 2019 at 07:18, Christian Gmeiner
 wrote:
>
> malloc(..) and memalign(..) are both allocating memory and as a result
> we leak the memory allocated with malloc(..).
>
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/ata/ahci.c | 5 +
>  1 file changed, 1 insertion(+), 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 4/6] dm: pci: add Freescale PowerPC PCIe driver

[Simon Glass]

Hi,

On Fri, 3 May 2019 at 20:03, Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> Add PCIe DM driver for Freescale PowerPC PCIe controllers.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  drivers/pci/Kconfig  |   7 +
>  drivers/pci/Makefile |   1 +
>  drivers/pci/pcie_fsl.c   | 612 +++
>  drivers/pci/pcie_fsl.h   |  60 
>  drivers/pci/pcie_fsl_fixup.c |  40 +++
>  5 files changed, 720 insertions(+)
>  create mode 100644 drivers/pci/pcie_fsl.c
>  create mode 100644 drivers/pci/pcie_fsl.h
>  create mode 100644 drivers/pci/pcie_fsl_fixup.c
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 1521885bde..36674db6c1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -60,6 +60,13 @@ config PCIE_DW_MVEBU
>   Armada-8K SoCs. The PCIe controller on Armada-8K is based on
>   DesignWare hardware.
>
> +config PCIE_FSL
> +   bool "FSL PowerPC PCIe support"
> +   depends on DM_PCI
> +   help
> + Say Y here if you want to enable PCIe controller support on
> + FSL PowerPC series SoCs.

Please add a bit more detail here. Which SoCs are supported? Which
hardware features are supported, and which not supported?

> +
>  config PCI_RCAR_GEN2
> bool "Renesas RCar Gen2 PCIe driver"
> depends on DM_PCI
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 4923641895..d984848266 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
>  obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
>  obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
>  obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
> +obj-$(CONFIG_PCIE_FSL) += pcie_fsl.o pcie_fsl_fixup.o
>  obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
>  obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
>  obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
> diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
> new file mode 100644
> index 00..95973fd8d9
> --- /dev/null
> +++ b/drivers/pci/pcie_fsl.c
> @@ -0,0 +1,612 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 NXP
> + * Copyright 2007-2012 Freescale Semiconductor, Inc.
> + *
> + * PCIe DM U-Boot driver for Freescale PowerPC SoCs
> + * Author: Hou Zhiqiang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pcie_fsl.h"

Please sort these properly:

common
clk
dm
malloc
mapmem
pci
asm/fsl
asm/io
pcie_fsl

> +
> +LIST_HEAD(fsl_pcie_list);
> +
> +static inline int fsl_pcie_link_up(struct fsl_pcie *pcie);

Why is this inline? Do you need the forward declaration?


> +
> +static int fsl_pcie_addr_valid(struct fsl_pcie *pcie, pci_dev_t bdf)
> +{
> +   struct udevice *bus = pcie->bus;
> +
> +   if (!pcie->enabled)
> +   return -ENXIO;
> +
> +   if (PCI_BUS(bdf) < bus->seq)
> +   return -EINVAL;
> +
> +   if (PCI_BUS(bdf) > bus->seq && (!fsl_pcie_link_up(pcie) || 
> pcie->mode))
> +   return -EINVAL;
> +
> +   if (PCI_BUS(bdf) == bus->seq && (PCI_DEV(bdf) > 0 || PCI_FUNC(bdf) > 
> 0))
> +   return -EINVAL;
> +
> +   if (PCI_BUS(bdf) == (bus->seq + 1) && (PCI_DEV(bdf) > 0))
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
> +static int fsl_pcie_read_config(struct udevice *bus, pci_dev_t bdf,
> +   uint offset, ulong *valuep,
> +   enum pci_size_t size)
> +{
> +   struct fsl_pcie *pcie = dev_get_priv(bus);
> +   ccsr_fsl_pci_t *regs = pcie->regs;
> +   u32 val;
> +
> +   if (fsl_pcie_addr_valid(pcie, bdf)) {
> +   *valuep = pci_get_ff(size);
> +   return 0;
> +   }
> +
> +   bdf = bdf - PCI_BDF(bus->seq, 0, 0);
> +   val = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
> +   out_be32(>cfg_addr, val);
> +
> +   sync();
> +
> +   switch (size) {
> +   case PCI_SIZE_8:
> +   *valuep = in_8((u8 *)>cfg_data + (offset & 3));
> +   break;
> +   case PCI_SIZE_16:
> +   *valuep = in_le16((u16 *)((u8 *)>cfg_data +
> + (offset & 2)));
> +   break;
> +   case PCI_SIZE_32:
> +   *valuep = in_le32(>cfg_data);
> +   break;
> +   }
> +
> +   return 0;
> +}
> +
> +static int fsl_pcie_write_config(struct udevice *bus, pci_dev_t bdf,
> +uint offset, ulong value,
> +enum pci_size_t size)
> +{
> +   struct fsl_pcie *pcie = dev_get_priv(bus);
> +   ccsr_fsl_pci_t *regs = pcie->regs;
> +   u32 val;
> +   u8 val_8;
> +   u16 val_16;
> +   u32 val_32;
> +
> +   if (fsl_pcie_addr_valid(pcie, bdf))
> +   return 0;
> +
> +   bdf = bdf - PCI_BDF(bus->seq, 0, 0);
> +   val = bdf | (offset & 0xfc) | 

Re: [U-Boot] [PATCH 6/6] ARM: imx: novena: Convert to DM VIDEO

[Vagrant Cascadian]

On 2019-05-06, Marek Vasut wrote:
> On 5/6/19 5:31 AM, Vagrant Cascadian wrote:
>> On 2019-05-06, Marek Vasut wrote:
>>> Enable DM Video support on iMX6Q Novena and fix minor details
>>> to restore previous behavior of the system.
>> 
>> Also required:
>> 
>>   "[U-Boot] video: ipuv3: Set max display bpp to 32"
>>   https://patchwork.ozlabs.org/patch/1095618/
>> 
>> Otherwise it would hang after initializing video.
>> 
>> I don't see video output though. Not sure when I last tested video
>> output from u-boot, though. But at least it boots!
>
> Try "setenv stdout serial,vidconsole" , does it help ?

Yes, that did help; thanks! So it's working on some level...


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 v5] ARM: am335x: Add phyCORE AM335x R2 support

[Niel Fourie]

Hi Tom,

On 5/6/19 4:18 PM, Tom Rini wrote:

On Mon, May 06, 2019 at 04:02:53PM +0200, Niel Fourie wrote:


Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
phyBOARD-Wega AM335x.

CPU  : AM335X-GP rev 2.1
Model: Phytec AM335x phyBOARD-WEGA
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
eth0: ethernet@4a10

Working:
  - Eth0
  - i2C
  - MMC/SD
  - NAND
  - UART
  - USB (host)

Device trees were taken from Linux mainline:
commit 37624b58542f ("Linux 5.1-rc7")

Signed-off-by: Niel Fourie 
+void sdram_init(void)
+{
+   int ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
+
+   if (fdtdec_setup_mem_size_base())
+   gd->ram_size = SZ_256M;
+
+   switch (gd->ram_size) {
+   case SZ_1G:
+   ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
+   break;
+   case SZ_512M:
+   ram_type_index = PHYCORE_R2_MT41K256M16TW107IT_512MB;
+   break;
+   case SZ_256M:
+   default:
+   ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
+   break;
+   }
+
+   config_ddr(DDR_CLK_MHZ, ,
+  _timings[ram_type_index].ddr3_data,
+  _cmd_ctrl_data,
+  _timings[ram_type_index].ddr3_emif_reg_data, 0);
+}


This is wrong.  sdram_init() is called by
arch/arm/mach-omap2/am33xx/board.c::dram_init() which then sets
gd->ram_size based on what get_ram_size() determines.  So this is all
just a wrapper around how the various parts of the am33xx generations
call some form of config_ddr().  And what you have here is a lot of
unused code about which module provides how much memory.  I assume
there's some run-time method to determine which module you're on and
thus determine that correct parameters to pass in for the chip that's in
use.  If you're not there yet then just make sdram_init() call
config_ddr(...) with the correct enum for the 256M chip and then update
this when you have real detection.


Thanks for that input, you are right. I could not find any documented 
way to detect the exact module we are running on, but as you pointed out 
we can use get_ram_size() to find the size of the installed RAM. This is 
in fact exactly what barebox did, I just missed it. How is this for a 
replacement of the above?


void sdram_init(void)
{
/* Configure memory to maximum supported size for detection */
int ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
config_ddr(DDR_CLK_MHZ, ,
   _timings[ram_type_index].ddr3_data,
   _cmd_ctrl_data,
   _timings[ram_type_index].ddr3_emif_reg_data,
   0);

/* Detect memory physically present */
gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
CONFIG_MAX_RAM_BANK_SIZE);

/* Reconfigure memory for actual detected size */
switch (gd->ram_size) {
case SZ_1G:
ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
break;
case SZ_512M:
ram_type_index = PHYCORE_R2_MT41K256M16TW107IT_512MB;
break;
case SZ_256M:
default:
ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
break;
}
config_ddr(DDR_CLK_MHZ, ,
   _timings[ram_type_index].ddr3_data,
   _cmd_ctrl_data,
   _timings[ram_type_index].ddr3_emif_reg_data,
   0);
}

The ugliest part of this is, as you pointed out, that directly after 
this is called, get_ram_size() will be called again from sdram_init(). 
But it at least noninvasive, and no longer requires the device tree.


Best regards,
Niel Fourie

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-21 Fax: +49-8142-66989-80  Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1 v3] arm: mvebu: Add CRS305-1G-4S board

[Luka Kovacic]

CRS305-1G-4S has a switch chip with an integrated CPU (98DX3236) and
like some of the other similar boards requires bin_hdr.
bin_hdr (DDR3 init stage) is currently retrieved from the stock
bootloader and compiled into the kwb image.

Adds support for U-Boot, enable UART, SPI, Winbond SPI flash chip
support and writing env to SPI flash.

Signed-off-by: Luka Kovacic 
---
v1:
   - arch/arm/dts: Remove unused parameters in DTS for crs305-1g-4s
   - arch/arm/mach-mvebu: Set the proper processor for crs305-1g-4s
 (98DX3236)

Changes for v2:
   - board/mikrotik/crs305-1g-4s: Enable CONFIG_DISPLAY_BOARDINFO

Changes for v3:
   - board/mikrotik/crs305-1g-4s: Remove GPIO1 (Reset Button)
 
 arch/arm/dts/Makefile |   3 +-
 .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi|  13 +++
 arch/arm/dts/armada-xp-crs305-1g-4s.dts   | 110 ++
 arch/arm/mach-mvebu/Kconfig   |   7 ++
 board/mikrotik/crs305-1g-4s/.gitignore|   1 +
 board/mikrotik/crs305-1g-4s/MAINTAINERS   |   7 ++
 board/mikrotik/crs305-1g-4s/Makefile  |  14 +++
 board/mikrotik/crs305-1g-4s/README|  23 
 board/mikrotik/crs305-1g-4s/binary.0  |  11 ++
 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c|  71 +++
 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in   |  12 ++
 configs/crs305-1g-4s_defconfig|  52 +
 include/configs/crs305-1g-4s.h|  37 ++
 13 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts
 create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore
 create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS
 create mode 100644 board/mikrotik/crs305-1g-4s/Makefile
 create mode 100644 board/mikrotik/crs305-1g-4s/README
 create mode 100644 board/mikrotik/crs305-1g-4s/binary.0
 create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c
 create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in
 create mode 100644 configs/crs305-1g-4s_defconfig
 create mode 100644 include/configs/crs305-1g-4s.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8e082f2840..8d73bcb57f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -162,7 +162,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb   \
-   armada-xp-db-xc3-24g4xg.dtb
+   armada-xp-db-xc3-24g4xg.dtb \
+   armada-xp-crs305-1g-4s.dtb
 
 dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi 
b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
new file mode 100644
index 00..8576a02730
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/armada-xp-crs305-1g-4s.dts 
b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
new file mode 100644
index 00..1116f5c96c
--- /dev/null
+++ b/arch/arm/dts/armada-xp-crs305-1g-4s.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS305-1G-4S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf100 (instead of the default
+ * 0xd000). The 0xf100 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+#include "armada-xp-crs305-1g-4s-u-boot.dtsi"
+
+/ {
+   model = "CRS305-1G-4S";
+   compatible = "marvell,armadaxp-98dx3236", "marvell,armadaxp-mv78260", 
"marvell,armadaxp", "marvell,armada-370-xp";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "console=ttyS0,115200 earlyprintk";
+   };
+
+   aliases {
+   spi0 = 
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x 0 0x2000>; /* 512 MB */
+   };
+};
+
+ {
+   arm,parity-enable;
+   marvell,ecc-enable;
+};
+
+_bootcs {
+   status = "okay";
+
+   /* Device Bus parameters are required */
+
+   /* Read parameters */
+   devbus,bus-width= <16>;
+   devbus,turn-off-ps  = <6>;
+   devbus,badr-skew-ps = 

[U-Boot] [PATCH] arm: socfpga: Re-add support for Aries MCV SoM and MCVEVK board

[Wolfgang Grandegger]

Re-add support for Aries Embedded MCV SoM, which is CycloneV based
and the associated MCVEVK baseboard. The board can boot from eMMC.
Ethernet and USB is supported.

The Aries Embedded boards have been removed with commit 03b54997d568
("board/aries: Remove"). I will now take care of them.

Signed-off-by: Wolfgang Grandegger 
CC: Marek Vasut 
CC: Simon Goldschmidt 
---
 .travis.yml  |   2 +-
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/socfpga_cyclone5_mcv.dtsi   |  22 +
 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi |  38 ++
 arch/arm/dts/socfpga_cyclone5_mcvevk.dts |  81 +++
 arch/arm/mach-socfpga/Kconfig|   7 +
 board/aries/mcvevk/MAINTAINERS   |   6 +
 board/aries/mcvevk/Makefile  |   7 +
 board/aries/mcvevk/qts/iocsr_config.h| 659 +++
 board/aries/mcvevk/qts/pinmux_config.h   | 218 
 board/aries/mcvevk/qts/pll_config.h  |  84 +++
 board/aries/mcvevk/qts/sdram_config.h| 343 
 board/aries/mcvevk/socfpga.c |   5 +
 configs/socfpga_mcvevk_defconfig |  68 +++
 include/configs/socfpga_mcvevk.h | 102 
 15 files changed, 1642 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcv.dtsi
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk.dts
 create mode 100644 board/aries/mcvevk/MAINTAINERS
 create mode 100644 board/aries/mcvevk/Makefile
 create mode 100644 board/aries/mcvevk/qts/iocsr_config.h
 create mode 100644 board/aries/mcvevk/qts/pinmux_config.h
 create mode 100644 board/aries/mcvevk/qts/pll_config.h
 create mode 100644 board/aries/mcvevk/qts/sdram_config.h
 create mode 100644 board/aries/mcvevk/socfpga.c
 create mode 100644 configs/socfpga_mcvevk_defconfig
 create mode 100644 include/configs/socfpga_mcvevk.h

diff --git a/.travis.yml b/.travis.yml
index 8bd49ef..714b92e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -230,7 +230,7 @@ matrix:
 - BUILDMAN="sun50i"
 - name: "buildman catch-all ARM"
   env:
-- BUILDMAN="arm -x 
arm11,arm7,arm9,aarch64,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"
+- BUILDMAN="arm -x 
arm11,arm7,arm9,aarch64,aries,at91,freescale,kirkwood,mvebu,siemens,tegra,uniphier,mx,samsung,sunxi,am33xx,omap,pxa,rockchip,toradex,socfpga,k2,xilinx"
 - name: "buildman sandbox x86"
   env:
 - BUILDMAN="sandbox x86"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..9a6c4e2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,6 +274,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
socfpga_arria10_socdk_sdmmc.dtb \
+   socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_dbm_soc1.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_mcv.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
new file mode 100644
index 000..bd92806
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Marek Vasut 
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Aries/DENX MCV";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   memory@0 {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1 GiB */
+   };
+};
+
+ {/* On-SoM eMMC */
+   bus-width = <8>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
new file mode 100644
index 000..1afaa86
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2015 Marek Vasut 
+ * Copyright (C) 2018 Wolfgang Grandegger 
+ */
+
+/{
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   clock-frequency = <1>;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   bank-name = "porta";
+};
+
+ {
+   bank-name = "portb";
+};
+
+ {
+   bank-name = "portc";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk.dts 
b/arch/arm/dts/socfpga_cyclone5_mcvevk.dts
new file mode 100644
index 000..ceaec29
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcvevk.dts
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Marek