Re: [U-Boot] [PATCH] configs: at91: add CONFIG_OF_EMBED=y in all defconfigs

[Eugen.Hristev]

On 13.11.2018 17:04, Radu Pirea wrote:
> U-boot must have dtb built in because at91bootstrap can not load it.

Hello,

The DTB is already appended in the image with the current defconfigs.
This has been in place for our boards for a long time, and I do not see 
any reason for change.
Anyway, not because our proprietary bootstrap cannot load it - the 
u-boot DTB is inside the bin as it is configured now, single file with a 
both (binary+DTB) (there is a u-boot-nodtb.bin without the DTB if required).
Perhaps you have other reason for this change ?

Thanks,
Eugen

> 
> Signed-off-by: Radu Pirea 
> ---
>   configs/at91rm9200ek_defconfig | 1 +
>   configs/at91rm9200ek_ram_defconfig | 1 +
>   configs/at91sam9260ek_dataflash_cs0_defconfig  | 1 +
>   configs/at91sam9260ek_dataflash_cs1_defconfig  | 1 +
>   configs/at91sam9260ek_nandflash_defconfig  | 1 +
>   configs/at91sam9261ek_dataflash_cs0_defconfig  | 1 +
>   configs/at91sam9261ek_dataflash_cs3_defconfig  | 1 +
>   configs/at91sam9261ek_nandflash_defconfig  | 1 +
>   configs/at91sam9263ek_dataflash_cs0_defconfig  | 1 +
>   configs/at91sam9263ek_dataflash_defconfig  | 1 +
>   configs/at91sam9263ek_nandflash_defconfig  | 1 +
>   configs/at91sam9263ek_norflash_boot_defconfig  | 1 +
>   configs/at91sam9263ek_norflash_defconfig   | 1 +
>   configs/at91sam9g10ek_dataflash_cs0_defconfig  | 1 +
>   configs/at91sam9g10ek_dataflash_cs3_defconfig  | 1 +
>   configs/at91sam9g10ek_nandflash_defconfig  | 1 +
>   configs/at91sam9g20ek_2mmc_defconfig   | 1 +
>   configs/at91sam9g20ek_2mmc_nandflash_defconfig | 1 +
>   configs/at91sam9g20ek_dataflash_cs0_defconfig  | 1 +
>   configs/at91sam9g20ek_dataflash_cs1_defconfig  | 1 +
>   configs/at91sam9g20ek_nandflash_defconfig  | 1 +
>   configs/at91sam9m10g45ek_mmc_defconfig | 1 +
>   configs/at91sam9m10g45ek_nandflash_defconfig   | 1 +
>   configs/at91sam9n12ek_mmc_defconfig| 1 +
>   configs/at91sam9n12ek_nandflash_defconfig  | 1 +
>   configs/at91sam9n12ek_spiflash_defconfig   | 1 +
>   configs/at91sam9rlek_dataflash_defconfig   | 1 +
>   configs/at91sam9rlek_mmc_defconfig | 1 +
>   configs/at91sam9rlek_nandflash_defconfig   | 1 +
>   configs/at91sam9x5ek_dataflash_defconfig   | 1 +
>   configs/at91sam9x5ek_mmc_defconfig | 1 +
>   configs/at91sam9x5ek_nandflash_defconfig   | 1 +
>   configs/at91sam9x5ek_spiflash_defconfig| 1 +
>   configs/at91sam9xeek_dataflash_cs0_defconfig   | 1 +
>   configs/at91sam9xeek_dataflash_cs1_defconfig   | 1 +
>   configs/at91sam9xeek_nandflash_defconfig   | 1 +
>   configs/sama5d27_som1_ek_mmc_defconfig | 1 +
>   configs/sama5d2_ptc_ek_mmc_defconfig   | 1 +
>   configs/sama5d2_ptc_ek_nandflash_defconfig | 1 +
>   configs/sama5d2_xplained_mmc_defconfig | 1 +
>   configs/sama5d2_xplained_spiflash_defconfig| 1 +
>   configs/sama5d36ek_cmp_mmc_defconfig   | 1 +
>   configs/sama5d36ek_cmp_nandflash_defconfig | 1 +
>   configs/sama5d36ek_cmp_spiflash_defconfig  | 1 +
>   configs/sama5d3_xplained_mmc_defconfig | 1 +
>   configs/sama5d3_xplained_nandflash_defconfig   | 1 +
>   configs/sama5d3xek_mmc_defconfig   | 1 +
>   configs/sama5d3xek_nandflash_defconfig | 1 +
>   configs/sama5d3xek_spiflash_defconfig  | 1 +
>   configs/sama5d4_xplained_mmc_defconfig | 1 +
>   configs/sama5d4_xplained_nandflash_defconfig   | 1 +
>   configs/sama5d4_xplained_spiflash_defconfig| 1 +
>   configs/sama5d4ek_mmc_defconfig| 1 +
>   configs/sama5d4ek_nandflash_defconfig  | 1 +
>   configs/sama5d4ek_spiflash_defconfig   | 1 +
>   55 files changed, 55 insertions(+)
> 
> diff --git a/configs/at91rm9200ek_defconfig b/configs/at91rm9200ek_defconfig
> index 6af0118cf5..a2387801f7 100644
> --- a/configs/at91rm9200ek_defconfig
> +++ b/configs/at91rm9200ek_defconfig
> @@ -25,3 +25,4 @@ CONFIG_USB=y
>   CONFIG_USB_STORAGE=y
>   CONFIG_USB_KEYBOARD=y
>   CONFIG_OF_LIBFDT=y
> +CONFIG_OF_EMBED=y
> diff --git a/configs/at91rm9200ek_ram_defconfig 
> b/configs/at91rm9200ek_ram_defconfig
> index 2688299db1..4889a8da52 100644
> --- a/configs/at91rm9200ek_ram_defconfig
> +++ b/configs/at91rm9200ek_ram_defconfig
> @@ -26,3 +26,4 @@ CONFIG_USB=y
>   CONFIG_USB_STORAGE=y
>   CONFIG_USB_KEYBOARD=y
>   CONFIG_OF_LIBFDT=y
> +CONFIG_OF_EMBED=y
> diff --git a/configs/at91sam9260ek_dataflash_cs0_defconfig 
> b/configs/at91sam9260ek_dataflash_cs0_defconfig
> index 7fd844c94b..f756f47fc4 100644
> --- a/configs/at91sam9260ek_dataflash_cs0_defconfig
> +++ b/configs/at91sam9260ek_dataflash_cs0_defconfig
> @@ -55,3 +55,4 @@ CONFIG_TIMER=y
>   CONFIG_ATMEL_PIT_TIMER=y
>   CONFIG_USB=y
>   CONFIG_USB_STORAGE=y
> +CONFIG_OF_EMBED=y
> diff --git a/configs/at91sam9260ek_dataflash_cs1_defconfig 
> b/configs/at91sam9260ek_dataflash_cs1_defconfig
> index c2fc77d78c..ea844f3cc9 100644
> --- a/config

[U-Boot] [PATCH] efi_loader: correct a function prototype of QueryCapsuleCapabilities()

[AKASHI Takahiro]

See UEFI specification v2.7, section 8.5.3.

Signed-off-by: AKASHI Takahiro 
---
 include/efi_api.h| 4 ++--
 lib/efi_loader/efi_runtime.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index f0c23a28e3d6..10917bad43a7 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -242,8 +242,8 @@ struct efi_runtime_services {
efi_status_t (EFIAPI *query_capsule_caps)(
struct efi_capsule_header **capsule_header_array,
efi_uintn_t capsule_count,
-   u64 maximum_capsule_size,
-   u32 reset_type);
+   u64 *maximum_capsule_size,
+   u32 *reset_type);
efi_status_t (EFIAPI *query_variable_info)(
u32 attributes,
u64 *maximum_variable_storage_size,
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 2c8bbb4eba4d..ae750f5371ff 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -625,8 +625,8 @@ efi_status_t __efi_runtime EFIAPI efi_update_capsule(
 efi_status_t __efi_runtime EFIAPI efi_query_capsule_caps(
struct efi_capsule_header **capsule_header_array,
efi_uintn_t capsule_count,
-   u64 maximum_capsule_size,
-   u32 reset_type)
+   u64 *maximum_capsule_size,
+   u32 *reset_type)
 {
return EFI_UNSUPPORTED;
 }
-- 
2.19.0

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

[U-Boot] [PATCH] efi_loader: SetVirtualAddressMap() should return EFI_UNSUPPORTED

[AKASHI Takahiro]

See UEFI specification 2.7, section 8.4.

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_runtime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index abcf03c5a42e..2c8bbb4eba4d 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -284,7 +284,7 @@ static const struct efi_runtime_detach_list_struct 
efi_runtime_detach_list[] = {
}, {
/* invalidate_*cache_all are gone */
.ptr = &efi_runtime_services.set_virtual_address_map,
-   .patchto = &efi_invalid_parameter,
+   .patchto = &efi_unimplemented,
}, {
/* RTC accessors are gone */
.ptr = &efi_runtime_services.get_time,
-- 
2.19.0

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

Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table

[Ang, Chee Hong]

On Thu, 2018-10-11 at 10:03 +, Marek Vasut wrote:
> On 10/11/2018 08:21 AM, Ang, Chee Hong wrote:
> > 
> > On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
> > > 
> > > On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
> > > > 
> > > > 
> > > > On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: "Ang, Chee Hong" 
> > > > > > > > > > 
> > > > > > > > > > Enable 'fpga' command in u-boot. User will be able
> > > > > > > > > > to
> > > > > > > > > > use
> > > > > > > > > > the
> > > > > > > > > > fpga
> > > > > > > > > > command to program the FPGA on Stratix10 SoC.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Ang, Chee Hong  > > > > > > > > > com>
> > > > > > > > > > ---
> > > > > > > > > >  arch/arm/mach-socfpga/misc.c | 29
> > > > > > > > > > +
> > > > > > > > > >  arch/arm/mach-socfpga/misc_s10.c |  2 ++
> > > > > > > > > >  drivers/fpga/altera.c|  6 ++
> > > > > > > > > >  include/altera.h |  4 
> > > > > > > > > >  4 files changed, 41 insertions(+)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > socfpga/misc.c
> > > > > > > > > > index a4f6d5c..7986b58 100644
> > > > > > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > > > > > > >  #endif
> > > > > > > > > >  
> > > > > > > > > >  #ifdef CONFIG_FPGA
> > > > > > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > > > > > > +/*
> > > > > > > > > > + * FPGA programming support for SoC FPGA Stratix
> > > > > > > > > > 10
> > > > > > > > > > + */
> > > > > > > > > > +static Altera_desc altera_fpga[] = {
> > > > > > > > > > +   {
> > > > > > > > > > +   /* Family */
> > > > > > > > > > +   Intel_FPGA_Stratix10,
> > > > > > > > > > +   /* Interface type */
> > > > > > > > > > +   secure_device_manager_mailbox,
> > > > > > > > > > +   /* No limitation as additional
> > > > > > > > > > data
> > > > > > > > > > will
> > > > > > > > > > be
> > > > > > > > > > ignored */
> > > > > > > > > > +   -1,
> > > > > > > > > > +   /* No device function table */
> > > > > > > > > > +   NULL,
> > > > > > > > > > +   /* Base interface address
> > > > > > > > > > specified in
> > > > > > > > > > driver
> > > > > > > > > > */
> > > > > > > > > > +   NULL,
> > > > > > > > > > +   /* No cookie implementation */
> > > > > > > > > > +   0
> > > > > > > > > > +   },
> > > > > > > > > > +};
> > > > > > > > > > +#else
> > > > > > > > > >  /*
> > > > > > > > > >   * FPGA programming support for SoC FPGA Cyclone V
> > > > > > > > > >   */
> > > > > > > > > > @@ -107,6 +128,7 @@ static Altera_desc
> > > > > > > > > > altera_fpga[] =
> > > > > > > > > > {
> > > > > > > > > >     0
> > > > > > > > > >     },
> > > > > > > > > >  };
> > > > > > > > > > +#endif
> > > > > > > > > >  
> > > > > > > > > >  /* add device descriptor to FPGA device table */
> > > > > > > > > >  void socfpga_fpga_add(void)
> > > > > > > > > > @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
> > > > > > > > > >     for (i = 0; i < ARRAY_SIZE(altera_fpga);
> > > > > > > > > > i++)
> > > > > > > > > >     fpga_add(fpga_altera,
> > > > > > > > > > &altera_fpga[i]);
> > > > > > > > > >  }
> > > > > > > > > > +
> > > > > > > > > > +#else
> > > > > > > > > > +
> > > > > > > > > > +__weak void socfpga_fpga_add(void)
> > > > > > > > > > +{
> > > > > > > > > > +}
> > > > > > > > > Why is a __weak function defined only in else-
> > > > > > > > > statement ?
> > > > > > > > > 
> > > > > > > > > It should be defined always, with a sane default
> > > > > > > > > implementation.
> > > > > > > > I will remove the empty function in #else-statement and
> > > > > > > > define
> > > > > > > > the
> > > > > > > > default function like this :
> > > > > > > > 
> > > > > > > > /* add device descriptor to FPGA device table */
> > > > > > > > void socfpga_fpga_add(void)
> > > > > > > > {
> > > > > > > > #ifdef CONFIG_FPGA
> > > > > > > > int i;
> > > > > > > > fpga_init();
> > > > > > > > for (i = 0; i < AR

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Baruch Siach]

Hi Ricardo,

On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
> On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam  wrote:
> > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach  wrote:
> >
> > > I tested current master successfully on Hummingboard2 with i.MX6 Solo
> > > (SOM rev 1.5):
> >
> > Thanks for testing.
> >
> > It seems we need more information from Peter about the regression he 
> > reported.
> >
> > It would be helpful if Peter could run a bisect so that we could
> > understand where the regression is coming from.
> 
> Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I
> can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM
> i2eX iMX6D - rev 1.3).
> 
> The patch set that introduced this regression was part of another pull
> request, the one that introduces eMMC booting support (from Jon
> Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more
> testing it seems that the hang happens when trying to verify if the
> board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)),
> which is not the case for this SOM in particular (and probably why it
> works fine on most rev 1.5-based SOMs, as eMMC is usually available
> there).
> 
> Tested with current u-boot master and the issue is still valid.
> 
> Jon, did you have any issue when testing that patch set on SOMs
> without eMMC support?

I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as 
shown in my previous message on this thread.

What toolchain are you using?

What do you see on the serial console?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v13 2/4] efi: Split out test init/uninit into functions

[Simon Glass]

The functions in bootefi are very long because they mix high-level code
and control with the low-level implementation. To help with this, create
functions which handle preparing for running the test and cleaning up
afterwards.

Also shorten the awfully long variable names here.

Signed-off-by: Simon Glass 
---

Changes in v13: None
Changes in v12:
- Rename image to image_prot

Changes in v11: None
Changes in v9:
- Add comments to bootefi_test_prepare() about the memset()s

Changes in v7: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()

Changes in v4: None
Changes in v3:
- Add new patch to split out test init/uninit into functions

 cmd/bootefi.c | 85 +++
 1 file changed, 65 insertions(+), 20 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3e37805ea13..91e6046cf5f 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -453,6 +453,64 @@ exit:
return ret;
 }
 
+#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
+/**
+ * bootefi_test_prepare() - prepare to run an EFI test
+ *
+ * This sets things up so we can call EFI functions. This involves preparing
+ * the 'gd' pointer and setting up the load ed image data structures.
+ *
+ * @image: Pointer to a struct which will hold the loaded image info.
+ *This struct will be inited by this function before use.
+ * @obj: Pointer to a struct which will hold the loaded image object
+ *This struct will be inited by this function before use.
+ * @path: File path to the test being run (often just the test name with a
+ *backslash before it
+ * @test_func: Address of the test function that is being run
+ * @return 0 if OK, -ve on error
+ */
+static efi_status_t bootefi_test_prepare(struct efi_loaded_image **imagep,
+struct efi_loaded_image_obj **objp,
+const char *path, ulong test_func)
+{
+   efi_status_t r;
+
+   /* Construct a dummy device path */
+   bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
+ (uintptr_t)test_func,
+ (uintptr_t)test_func);
+   bootefi_image_path = efi_dp_from_file(NULL, 0, path);
+   r = efi_setup_loaded_image(bootefi_device_path, bootefi_image_path,
+  objp, imagep);
+   if (r)
+   return r;
+   /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+   efi_save_gd();
+
+   /* Transfer environment variable efi_selftest as load options */
+   set_load_options(*imagep, "efi_selftest");
+
+   return 0;
+}
+
+/**
+ * bootefi_test_finish() - finish up after running an EFI test
+ *
+ * @image_prot: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_test_finish(struct efi_loaded_image *image_prot,
+   struct efi_loaded_image_obj *obj)
+{
+   efi_restore_gd();
+   free(image_prot->load_options);
+   efi_delete_handle(&obj->header);
+}
+#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
+
 static int do_bootefi_bootmgr_exec(void)
 {
struct efi_device_path *device_path, *file_path;
@@ -525,29 +583,16 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
 #endif
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
-   struct efi_loaded_image_obj *image_obj;
-   struct efi_loaded_image *loaded_image_info;
-
-   /* Construct a dummy device path. */
-   bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
- (uintptr_t)&efi_selftest,
- (uintptr_t)&efi_selftest);
-   bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
-
-   r = efi_setup_loaded_image(bootefi_device_path,
-  bootefi_image_path, &image_obj,
-  &loaded_image_info);
-   if (r != EFI_SUCCESS)
+   struct efi_loaded_image *image_prot;
+   struct efi_loaded_image_obj *obj;
+
+   if (bootefi_test_prepare(&image_prot, &obj, "\\selftest",
+(uintptr_t)&efi_selftest))
return CMD_RET_FAILURE;
 
-   efi_save_gd();
-   /* Transfer environment variable efi_selftest as load options */
-   set_load_options(loaded_image_info, "efi_selftest");
/* Execute the test */
-   r = efi_selftest(&image_obj->header, &systab);
-   efi_restore_gd();
-   free(loaded_image_info->load_optio

[U-Boot] [PATCH v13 3/4] efi: Create a function to set up for running EFI code

[Simon Glass]

There is still duplicated code in efi_loader for tests and normal
operation.

Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().

Also shorten a few variable names.

Signed-off-by: Simon Glass 
---

Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v9: None
Changes in v7: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path

Changes in v4:
- Rebase to master

Changes in v3:
- Add patch to create a function to set up for running EFI code

 cmd/bootefi.c | 85 +--
 1 file changed, 48 insertions(+), 37 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 91e6046cf5f..492052d827a 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -325,6 +325,30 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
return ret;
 }
 
+static efi_status_t bootefi_run_prepare(const char *load_options_path,
+   struct efi_device_path *device_path,
+   struct efi_device_path *image_path,
+   struct efi_loaded_image **imagep,
+   struct efi_loaded_image_obj **objp)
+{
+   efi_status_t ret;
+
+   ret = efi_setup_loaded_image(device_path, image_path, objp, imagep);
+   if (ret != EFI_SUCCESS)
+   return ret;
+
+   /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+   efi_save_gd();
+
+   /* Transfer environment variable as load options */
+   set_load_options(*imagep, load_options_path);
+
+   return 0;
+}
+
 /**
  * do_bootefi_exec() - execute EFI binary
  *
@@ -343,8 +367,8 @@ static efi_status_t do_bootefi_exec(void *efi,
efi_handle_t mem_handle = NULL;
struct efi_device_path *memdp = NULL;
efi_status_t ret;
-   struct efi_loaded_image_obj *image_obj = NULL;
-   struct efi_loaded_image *loaded_image_info = NULL;
+   struct efi_loaded_image_obj *obj = NULL;
+   struct efi_loaded_image *image_prot = NULL;
 
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
 struct efi_system_table *st);
@@ -374,15 +398,13 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
 
-   ret = efi_setup_loaded_image(device_path, image_path, &image_obj,
-&loaded_image_info);
-   if (ret != EFI_SUCCESS)
-   goto exit;
+   ret = bootefi_run_prepare("bootargs", device_path, image_path,
+ &image_prot, &obj);
+   if (ret)
+   return ret;
 
-   /* Transfer environment variable bootargs as load options */
-   set_load_options(loaded_image_info, "bootargs");
/* Load the EFI payload */
-   entry = efi_load_pe(image_obj, efi, loaded_image_info);
+   entry = efi_load_pe(obj, efi, image_prot);
if (!entry) {
ret = EFI_LOAD_ERROR;
goto exit;
@@ -390,10 +412,9 @@ static efi_status_t do_bootefi_exec(void *efi,
 
if (memdp) {
struct efi_device_path_memory *mdp = (void *)memdp;
-   mdp->memory_type = loaded_image_info->image_code_type;
-   mdp->start_address = (uintptr_t)loaded_image_info->image_base;
-   mdp->end_address = mdp->start_address +
-   loaded_image_info->image_size;
+   mdp->memory_type = image_prot->image_code_type;
+   mdp->start_address = (uintptr_t)image_prot->image_base;
+   mdp->end_address = mdp->start_address + image_prot->image_size;
}
 
/* we don't support much: */
@@ -403,8 +424,8 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
 
-   if (setjmp(&image_obj->exit_jmp)) {
-   ret = image_obj->exit_status;
+   if (setjmp(&obj->exit_jmp)) {
+   ret = obj->exit_status;
goto exit;
}
 
@@ -416,7 +437,7 @@ static efi_status_t do_bootefi_exec(void *efi,
 
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
-   (ulong)&image_obj->header,
+   (ulong)&obj->header,
(ulong)&systab, 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
 
@@ -433,7 +454,7 @@ static efi_status_t do_bootefi_exec(void *efi,
secur

[U-Boot] [PATCH v13 4/4] efi: Rename bootefi_test_finish() to bootefi_run_finish()

[Simon Glass]

This function can be used from do_bootefi_exec() so that we use mostly the
same code for a normal EFI application and an EFI test.

Rename the function and use it in both places.

Signed-off-by: Simon Glass 
---

Changes in v13:
- Drop 'efi_loader: Drop setup_ok' as we have an existing patch for that
- Drop patches previously applied

Changes in v12: None
Changes in v11:
- Drop patches previously applied

Changes in v9: None
Changes in v7:
- Drop patch "efi: Init the 'rows' and 'cols' variables"
- Drop patches previous applied

Changes in v5:
- Rebase to master

Changes in v4:
- Rebase to master

Changes in v3:
- Add new patch to rename bootefi_test_finish() to bootefi_run_finish()

 cmd/bootefi.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 492052d827a..317c7feb0a5 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -349,6 +349,20 @@ static efi_status_t bootefi_run_prepare(const char 
*load_options_path,
return 0;
 }
 
+/**
+ * bootefi_run_finish() - finish up after running an EFI test
+ *
+ * @image: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_run_finish(struct efi_loaded_image *image,
+  struct efi_loaded_image_obj *obj)
+{
+   efi_restore_gd();
+   free(image->load_options);
+   efi_delete_handle(&obj->header);
+}
+
 /**
  * do_bootefi_exec() - execute EFI binary
  *
@@ -466,8 +480,7 @@ static efi_status_t do_bootefi_exec(void *efi,
 
 exit:
/* image has returned, loaded-image obj goes *poof*: */
-   if (obj)
-   efi_delete_handle(&obj->header);
+   bootefi_run_finish(image_prot, obj);
if (mem_handle)
efi_delete_handle(mem_handle);
 
@@ -506,19 +519,6 @@ static efi_status_t bootefi_test_prepare(struct 
efi_loaded_image **imagep,
   bootefi_image_path, imagep, objp);
 }
 
-/**
- * bootefi_test_finish() - finish up after running an EFI test
- *
- * @image_prot: Pointer to a struct which holds the loaded image info
- * @obj: Pointer to a struct which holds the loaded image object
- */
-static void bootefi_test_finish(struct efi_loaded_image *image_prot,
-   struct efi_loaded_image_obj *obj)
-{
-   efi_restore_gd();
-   free(image_prot->load_options);
-   efi_delete_handle(&obj->header);
-}
 #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
 
 static int do_bootefi_bootmgr_exec(void)
@@ -603,7 +603,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
/* Execute the test */
r = efi_selftest(&obj->header, &systab);
-   bootefi_test_finish(image_prot, obj);
+   bootefi_run_finish(image_prot, obj);
return r != EFI_SUCCESS;
} else
 #endif
-- 
2.19.1.930.g4563a0d9d0-goog

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

[U-Boot] [PATCH v13 1/4] sandbox: smbios: Update to support sandbox

[Simon Glass]

At present this code casts addresses to pointers so cannot be used with
sandbox. Update it to use mapmem instead.

Signed-off-by: Simon Glass 
---

Changes in v13:
- Update code to deal with the struct_table_address member

Changes in v12: None
Changes in v11:
- Fix the EFI code that has since been added and relies on broken behaviour

Changes in v9: None
Changes in v7: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Drop incorrect map_sysmem() in write_smbios_table()

 lib/efi_loader/efi_smbios.c | 20 +-
 lib/smbios.c| 52 ++---
 2 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 38e42fa2432..a81488495e2 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
@@ -19,17 +20,19 @@ static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 efi_status_t efi_smbios_register(void)
 {
/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
-   u64 dmi = U32_MAX;
+   u64 dmi_addr = U32_MAX;
efi_status_t ret;
+   void *dmi;
 
/* Reserve 4kiB page for SMBIOS */
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr);
 
if (ret != EFI_SUCCESS) {
/* Could not find space in lowmem, use highmem instead */
ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
-EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+EFI_RUNTIME_SERVICES_DATA, 1,
+&dmi_addr);
 
if (ret != EFI_SUCCESS)
return ret;
@@ -39,11 +42,14 @@ efi_status_t efi_smbios_register(void)
 * Generate SMBIOS tables - we know that efi_allocate_pages() returns
 * a 4k-aligned address, so it is safe to assume that
 * write_smbios_table() will write the table at that address.
+*
+* Note that on sandbox, efi_allocate_pages() unfortunately returns a
+* pointer even though it uses a uint64_t type. Convert it.
 */
-   assert(!(dmi & 0xf));
-   write_smbios_table(dmi);
+   assert(!(dmi_addr & 0xf));
+   dmi = (void *)(uintptr_t)dmi_addr;
+   write_smbios_table(map_to_sysmem(dmi));
 
/* And expose them to our EFI payload */
-   return efi_install_configuration_table(&smbios_guid,
-  (void *)(uintptr_t)dmi);
+   return efi_install_configuration_table(&smbios_guid, dmi);
 }
diff --git a/lib/smbios.c b/lib/smbios.c
index 326eb00230d..2cd08b5e16f 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start)
 
 static int smbios_write_type0(ulong *current, int handle)
 {
-   struct smbios_type0 *t = (struct smbios_type0 *)*current;
+   struct smbios_type0 *t;
int len = sizeof(struct smbios_type0);
 
+   t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type0));
fill_smbios_header(t, SMBIOS_BIOS_INFORMATION, len, handle);
t->vendor = smbios_add_string(t->eos, "U-Boot");
@@ -101,16 +103,18 @@ static int smbios_write_type0(ulong *current, int handle)
 
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+   unmap_sysmem(t);
 
return len;
 }
 
 static int smbios_write_type1(ulong *current, int handle)
 {
-   struct smbios_type1 *t = (struct smbios_type1 *)*current;
+   struct smbios_type1 *t;
int len = sizeof(struct smbios_type1);
char *serial_str = env_get("serial#");
 
+   t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type1));
fill_smbios_header(t, SMBIOS_SYSTEM_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -122,15 +126,17 @@ static int smbios_write_type1(ulong *current, int handle)
 
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+   unmap_sysmem(t);
 
return len;
 }
 
 static int smbios_write_type2(ulong *current, int handle)
 {
-   struct smbios_type2 *t = (struct smbios_type2 *)*current;
+   struct smbios_type2 *t;
int len = sizeof(struct smbios_type2);
 
+   t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type2));
fill_smbios_header(t, SMBIOS_BOARD_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -140,15 +146,17 @@ static int smbios_write_type2(ulong *current, int handle)
 

[U-Boot] [PATCH v13 0/4] efi_loader: Code refactoring and improvement

[Simon Glass]

This collects the patches previously sent to break up the very large
functions in efi_loader into smaller pieces. Now that the other sandbox
stuff is applied, perhaps it is time to apply these patches.

This also adds a few new patches to fix more recent breakages.
Unfortunately we still cannot enable the efi loader tests since one of
the tests fails. Thus we should expect additional failures to appear
until that is resolved.

Changes in v13:
- Drop 'efi_loader: Drop setup_ok' as we have an existing patch for that
- Drop patches previously applied
- Update code to deal with the struct_table_address member

Changes in v12:
- Rename image to image_prot

Changes in v11:
- Drop patches previously applied
- Fix the EFI code that has since been added and relies on broken behaviour

Changes in v9:
- Add comments to bootefi_test_prepare() about the memset()s

Changes in v7:
- Drop patch "efi: Init the 'rows' and 'cols' variables"
- Drop patches previous applied

Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path
- Rebase to master

Changes in v4:
- Rebase to master

Changes in v3:
- Add new patch to rename bootefi_test_finish() to bootefi_run_finish()
- Add new patch to split out test init/uninit into functions
- Add patch to create a function to set up for running EFI code
- Drop incorrect map_sysmem() in write_smbios_table()

Simon Glass (4):
  sandbox: smbios: Update to support sandbox
  efi: Split out test init/uninit into functions
  efi: Create a function to set up for running EFI code
  efi: Rename bootefi_test_finish() to bootefi_run_finish()

 cmd/bootefi.c   | 136 +---
 lib/efi_loader/efi_smbios.c |  20 --
 lib/smbios.c|  52 +++---
 3 files changed, 152 insertions(+), 56 deletions(-)

-- 
2.19.1.930.g4563a0d9d0-goog

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

Re: [U-Boot] [PATCH] mmc: Parse HS400 DT properties

[Peng Fan]

> -Original Message-
> From: Marek Vasut [mailto:marek.va...@gmail.com]
> Sent: 2018年11月14日 7:39
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tom Rini
> ; Jaehoon Chung ;
> Jean-Jacques Hiblot ; Kishon Vijay Abraham I
> ; Peng Fan ; Simon Glass
> 
> Subject: [PATCH] mmc: Parse HS400 DT properties
> 
> Add HS400 properties parsing support to mmc_of_parse().
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Jaehoon Chung 
> Cc: Jean-Jacques Hiblot 
> Cc: Kishon Vijay Abraham I 
> Cc: Peng Fan 
> Cc: Simon Glass 
> ---
>  drivers/mmc/mmc-uclass.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index
> f73f07254b..76225b7939 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -166,6 +166,10 @@ int mmc_of_parse(struct udevice *dev, struct
> mmc_config *cfg)
>   cfg->host_caps |= MMC_CAP(MMC_HS_200);
>   if (dev_read_bool(dev, "mmc-hs200-1_2v"))
>   cfg->host_caps |= MMC_CAP(MMC_HS_200);
> + if (dev_read_bool(dev, "mmc-hs400-1_8v"))
> + cfg->host_caps |= MMC_CAP(MMC_HS_400);
> + if (dev_read_bool(dev, "mmc-hs400-1_2v"))
> + cfg->host_caps |= MMC_CAP(MMC_HS_400);
> 
>   return 0;
>  }

Reviewed-by: Peng Fan 

> --
> 2.18.0

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

Re: [U-Boot] [PATCH 15/15] imx: add i.MX8MQ EVK support

[Peng Fan]

> -Original Message-
> From: Jon Nettleton [mailto:j...@solid-run.com]
> Sent: 2018年11月13日 15:53
> To: Troy Kisky 
> Cc: Peng Fan ; sba...@denx.de; Fabio Estevam
> ; U-Boot Mailing List ;
> dl-linux-imx 
> Subject: Re: [U-Boot] [PATCH 15/15] imx: add i.MX8MQ EVK support
> 
> On Fri, Nov 9, 2018 at 8:06 PM Troy Kisky 
> wrote:
> >
> > On 11/9/2018 1:17 AM, Peng Fan wrote:
> > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > DRAM
> >
> >
> > > +
> > > +static struct dram_cfg_param lpddr4_ddrc_cfg[] = {
> > > + /* Start to config, default 3200mbps */
> > > + /* dis_dq=1, indicates no reads or writes are issued to SDRAM */
> > > + { DDRC_DBG1(0), 0x0001 },
> >
> >
> > Just a little elaboration on how a structure might work here
> >
> > #define DDRC_ADDR(reg, x) &((struct ddrc
> > *)(DDRC_IPS_BASE_ADDR(x))->reg)
> >
> > { DDRC_ADDR(dbg1, 0), 0x0001 },
> >
> >
> >
> > Thanks for working on this Peng!
> >
> >
> > BR
> > Troy
> 
> Yes thanks for working on this Peng.  Just to clarify one thing.  Do you have 
> a
> script that is generating the structures from output of the mx8m_ddr_tool, or
> is the mx8m_ddr_tool being changed to output the structures?

Currently the i.MX8MQ ddr is still original format, not the format used in this 
patch.
When NXP GA software release, I think the ddr tool will support this new 
format. 

Regards,
Peng.


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

[U-Boot] using contents from https://www.denx.de/wiki/U-Boot or git repo

[Prabhakar Kushwaha]

Hi,

I am trying to use some content from https://www.denx.de/wiki/U-Boot and 
http://git.denx.de/?p=u-boot.git;a=summary in one publication.
I am trying to provide details about u-boot boot-loader and its feature list. 

I am not sure, if I can use content without any permission.
or
 I need to get special permission from someone (not sure whom). 

Please suggest..

Regards,
Prabhakar

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

Re: [U-Boot] [PATCH u-boot v2] spi: Add Amlogic Meson SPI Flash Controller driver

[Jagan Teki]

On Tue, Nov 13, 2018 at 4:20 PM Neil Armstrong  wrote:
>
> The Amlogic Meson SoCs embeds a Flash oriented SPI Controller name SPIFC.
> This driver, ported from the Linux meson-spi-spifc driver, add support
> for this controller on the Amlogic Meson GX SoCs in U-Boot.
>
> [ported from linux version commit 2f58ea64bd8931bd7709732fe0a96e0bfb44a00b]
>
> Signed-off-by: Neil Armstrong 
> ---
> Changes since v1 :
> - removed the meson_spifc_claim_bus/meson_spifc_release_bus enabling disabling
>   the clock and making register access with the clock disabled
>
>  drivers/spi/Kconfig   |   8 +
>  drivers/spi/Makefile  |   1 +
>  drivers/spi/meson_spifc.c | 335 ++
>  3 files changed, 344 insertions(+)
>  create mode 100644 drivers/spi/meson_spifc.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 516188ea88..6085788481 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -116,6 +116,14 @@ config ICH_SPI
>   access the SPI NOR flash on platforms embedding this Intel
>   ICH IP core.
>
> +config MESON_SPIFC
> +   bool "Amlogic Meson SPI Flash Controller driver"
> +   depends on ARCH_MESON
> +   help
> + Enable the Amlogic Meson SPI Flash Controller SPIFC) driver.
> + This driver can be used to access the SPI NOR flash chips on
> + Amlogic Meson SoCs.
> +
>  config MT7621_SPI
> bool "MediaTek MT7621 SPI driver"
> depends on ARCH_MT7620
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 7242ea7e40..67b42daf4e 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
>  obj-$(CONFIG_ICH_SPI) +=  ich.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
> +obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> diff --git a/drivers/spi/meson_spifc.c b/drivers/spi/meson_spifc.c
> new file mode 100644
> index 00..df516d3e4c
> --- /dev/null
> +++ b/drivers/spi/meson_spifc.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2014 Beniamino Galvani 
> + * Copyright (C) 2018 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * Amlogic Meson SPI Flash Controller driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* register map */
> +#define REG_CMD0x00
> +#define REG_ADDR   0x04
> +#define REG_CTRL   0x08
> +#define REG_CTRL1  0x0c
> +#define REG_STATUS 0x10
> +#define REG_CTRL2  0x14
> +#define REG_CLOCK  0x18
> +#define REG_USER   0x1c
> +#define REG_USER1  0x20
> +#define REG_USER2  0x24
> +#define REG_USER3  0x28
> +#define REG_USER4  0x2c
> +#define REG_SLAVE  0x30
> +#define REG_SLAVE1 0x34
> +#define REG_SLAVE2 0x38
> +#define REG_SLAVE3 0x3c
> +#define REG_C0 0x40
> +#define REG_B8 0x60
> +#define REG_MAX0x7c
> +
> +/* register fields */
> +#define CMD_USER   BIT(18)
> +#define CTRL_ENABLE_AHBBIT(17)
> +#define CLOCK_SOURCE   BIT(31)
> +#define CLOCK_DIV_SHIFT12
> +#define CLOCK_DIV_MASK (0x3f << CLOCK_DIV_SHIFT)
> +#define CLOCK_CNT_HIGH_SHIFT   6
> +#define CLOCK_CNT_HIGH_MASK(0x3f << CLOCK_CNT_HIGH_SHIFT)
> +#define CLOCK_CNT_LOW_SHIFT0
> +#define CLOCK_CNT_LOW_MASK (0x3f << CLOCK_CNT_LOW_SHIFT)
> +#define USER_DIN_EN_MS BIT(0)
> +#define USER_CMP_MODE  BIT(2)
> +#define USER_CLK_NOT_INV   BIT(7)
> +#define USER_UC_DOUT_SEL   BIT(27)
> +#define USER_UC_DIN_SELBIT(28)
> +#define USER_UC_MASK   ((BIT(5) - 1) << 27)
> +#define USER1_BN_UC_DOUT_SHIFT 17
> +#define USER1_BN_UC_DOUT_MASK  (0xff << 16)
> +#define USER1_BN_UC_DIN_SHIFT  8
> +#define USER1_BN_UC_DIN_MASK   (0xff << 8)
> +#define USER4_CS_POL_HIGH  BIT(23)
> +#define USER4_IDLE_CLK_HIGHBIT(29)
> +#define USER4_CS_ACT   BIT(30)
> +#define SLAVE_TRST_DONEBIT(4)
> +#define SLAVE_OP_MODE  BIT(30)
> +#define SLAVE_SW_RST   BIT(31)
> +
> +#define SPIFC_BUFFER_SIZE  64
> +
> +struct meson_spifc_priv {
> +   struct regmap   *regmap;
> +   struct clk  clk;
> +};
> +
> +/**
> + * meson_spifc_wait_ready() - wait for the current operation to terminate
> + * @spifc: the Meson SPI device
> + * Return: 0 on success, a negative value on error
> + */
> +static int meson_spifc_wait_ready(struct meson_spifc_priv *spifc)
> +{
> +   u32 data;
> +   ulong tbase = get_timer(0);
> +
> +   do {

Re: [U-Boot] [PATCH 05/19] riscv: Add a SYSCON driver for Core Local Interruptor

[Bin Meng]

Hi Lukas,

On Tue, Nov 13, 2018 at 10:45 PM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> > This adds U-Boot syscon driver for RISC-V Core Local Interruptor
> > (CLINT). The CLINT block holds memory-mapped control and status
> > registers associated with software and timer interrupts.
> >
> > 3 APIs are provided for U-Boot to implement Supervisor Binary
> > Interface (SBI) as defined by the RISC-V privileged architecture
> > spec v1.10.
> >
> > Signed-off-by: Bin Meng 
> > ---
>
> Would it make sense to also abstract the functions provided by the
> CLINT more? The reason why I am asking is because the CLINT is
> (unfortunately) not specified as part of RISC-V. It is developing into
> a de facto standard since other platforms are following SiFive's
> implementation, but there is nothing that would prevent them from
> implementing something else.
>

I think your observation is correct about CLINT. Rick, does Andes's
RISC-V processor also follow SiFive's CLINT model?

> Two immediate examples I can think of would be mtime and the IPI
> implementation. Many SoC vendors will likely already have a suitable
> timer IP block for mtime. I can imagine that they would choose to re-
> use their memory map instead of following that of the CLINT.
> For the IPI implementation there is already an alternative, the SBI. If
> U-Boot should be able to run in supervisor mode, it would be helpful to
> support both the SBI and the CLINT interface.
>

I am not sure I followed you here. This driver provides 3 APIs:
riscv_send_ipi() is for IPI, and the other 2 are for mtime/mtimecmp.

> So what we would need is some kind of API for the functionality
> provided by the CLINT. For the multi-core support (I will try to send
> out a series soon) I am re-using the IRQ uclass ID (it is only used in
> arch code) to define a irq-uclass for RISC-V, which handles everything
> with IPIs. The CLINT0 and SBI are then just different driver
> implementing the uclass.
>
> This is just an idea right now, what do you think?
>

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

Re: [U-Boot] [PATCH v4 14/18] serial: 16550: allow the driver to support MediaTek serial

[Ryder Lee]

On Tue, 2018-11-13 at 11:53 -0800, Simon Glass wrote:
> Hi Ryder,
> 
> On 6 November 2018 at 01:47, Ryder Lee  wrote:
> > This patch adds an extra operation in ns16550.c to suuport MediaTek
> > SoCs as we have a highspeed register which influences the calcualtion
> > of the divisor.
> >
> > Note that we don't support the baudrate greater than 115200 currently.
> >
> > Signed-off-by: Ryder Lee 
> > Tested-by: Matthias Brugger 
> > Reviewed-by: Simon Glass 
> > ---
> > Changes since v4: None
> >
> > @Simon
> > We have tried the compatible string, but it made the ns16550 driver more 
> > complicated.
> > To use the compatible string we have to add a new field in 
> > ns16550_platdata, and change
> > the flow of ns16550_serial_probe().
> >
> > Moreover, it's totally useless for debug uart. At present using a macro is 
> > the easiest way here.
> >
> > What do you think?
> > ---
> >  drivers/serial/ns16550.c | 10 ++
> >  1 file changed, 10 insertions(+)
> 
> Please see my reply to the other thread. We should not have
> arch-specific code in generic drivers.
> 
> Sorry for not replying earlier on that.
> 

OK. 

BTW, can you (or Tom) please take the other patches through your tree? 

Ryder


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

Re: [U-Boot] [PATCH 02/19] dm: cpu: Add timebase frequency to the platdata

[Bin Meng]

Hi Simon,

On Wed, Nov 14, 2018 at 4:02 AM Simon Glass  wrote:
>
> On 13 November 2018 at 00:21, Bin Meng  wrote:
> > This adds a timebase_freq member to the 'struct cpu_platdata', to
> > hold the "timebase-frequency" value in the cpu or /cpus node.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  include/cpu.h | 3 +++
> >  1 file changed, 3 insertions(+)
>
> Reviewed-by: Simon Glass 
>
> Could we have comments for the struct members?

There are already comments added for the struct members. I am not sure
what additional comments do you want to add?

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

Re: [U-Boot] [PATCH] Makefile: Only build dtc if needed

[Marek Vasut]

On 11/13/2018 11:43 PM, Simon Glass wrote:
> At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined. This
> is wasteful when the system already has a suitable version available.
> 
> Update the Makefile logic to build dtc only if the version available is
> too old.
> 
> This saves about 3 seconds of CPU time on a clean build for me.

Nice !

> Signed-off-by: Simon Glass 

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] [PATCH 5/5] ARM: rmobile: Enable MMC HS400 on Salvator-X, ULCB, Ebisu

[Marek Vasut]

Enable the HS400 support code on H3, M3W, M3N Salvator-X(S)
and ULCB boards as well as E3 Ebisu board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a7795_salvator-x_defconfig  | 1 +
 configs/r8a7795_ulcb_defconfig| 1 +
 configs/r8a77965_salvator-x_defconfig | 1 +
 configs/r8a7796_salvator-x_defconfig  | 1 +
 configs/r8a7796_ulcb_defconfig| 1 +
 configs/r8a77990_ebisu_defconfig  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/configs/r8a7795_salvator-x_defconfig 
b/configs/r8a7795_salvator-x_defconfig
index 55c3f800a0..6e9444a5ee 100644
--- a/configs/r8a7795_salvator-x_defconfig
+++ b/configs/r8a7795_salvator-x_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/r8a7795_ulcb_defconfig b/configs/r8a7795_ulcb_defconfig
index c2adf9e01a..0eec903472 100644
--- a/configs/r8a7795_ulcb_defconfig
+++ b/configs/r8a7795_ulcb_defconfig
@@ -49,6 +49,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/r8a77965_salvator-x_defconfig 
b/configs/r8a77965_salvator-x_defconfig
index fbc22dd1af..f2b5ca320c 100644
--- a/configs/r8a77965_salvator-x_defconfig
+++ b/configs/r8a77965_salvator-x_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/r8a7796_salvator-x_defconfig 
b/configs/r8a7796_salvator-x_defconfig
index f5809bea8e..055f8d72b5 100644
--- a/configs/r8a7796_salvator-x_defconfig
+++ b/configs/r8a7796_salvator-x_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig
index fe60382c05..46563d5b3b 100644
--- a/configs/r8a7796_ulcb_defconfig
+++ b/configs/r8a7796_ulcb_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/r8a77990_ebisu_defconfig b/configs/r8a77990_ebisu_defconfig
index aebace40ee..9a462fe979 100644
--- a/configs/r8a77990_ebisu_defconfig
+++ b/configs/r8a77990_ebisu_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
-- 
2.18.0

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

[U-Boot] [PATCH 2/5] ARM: dts: rmobile: Enable SDR104 on Salvator-X and ULCB

[Marek Vasut]

Enable SDR104 modes on M3W and H3 boards. With the SDHI fixes
in place, it is now possible to use SDR104.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/salvator-common.dtsi | 10 ++
 arch/arm/dts/ulcb.dtsi|  5 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/dts/salvator-common.dtsi 
b/arch/arm/dts/salvator-common.dtsi
index 826a02c333..d2d667bb01 100644
--- a/arch/arm/dts/salvator-common.dtsi
+++ b/arch/arm/dts/salvator-common.dtsi
@@ -623,8 +623,13 @@
cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
+
+   max-frequency = <20800>;
 };
 
 &sdhi2 {
@@ -640,6 +645,7 @@
non-removable;
fixed-emmc-driver-type = <1>;
status = "okay";
+   max-frequency = <2>;
 };
 
 &sdhi3 {
@@ -652,8 +658,12 @@
cd-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
+   max-frequency = <20800>;
 };
 
 &ssi1 {
diff --git a/arch/arm/dts/ulcb.dtsi b/arch/arm/dts/ulcb.dtsi
index b61e2656d5..44dd84179f 100644
--- a/arch/arm/dts/ulcb.dtsi
+++ b/arch/arm/dts/ulcb.dtsi
@@ -401,8 +401,12 @@
vqmmc-supply = <&vccq_sdhi0>;
cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
bus-width = <4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
+   max-frequency = <20800>;
 };
 
 &sdhi2 {
@@ -417,6 +421,7 @@
mmc-hs200-1_8v;
non-removable;
status = "okay";
+   max-frequency = <2>;
 };
 
 &ssi1 {
-- 
2.18.0

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

[U-Boot] [PATCH 4/5] ARM: dts: rmobile: Enable HS400 on Salvator-X, ULCB, Ebisu

[Marek Vasut]

Enable the HS400 support in DT on H3, M3W, M3N Salvator-X(S)
and ULCB boards as well as E3 Ebisu board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77990-ebisu.dts   | 5 +++--
 arch/arm/dts/salvator-common.dtsi | 1 +
 arch/arm/dts/ulcb.dtsi| 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/r8a77990-ebisu.dts b/arch/arm/dts/r8a77990-ebisu.dts
index 6fcf0013b9..edd020cec1 100644
--- a/arch/arm/dts/r8a77990-ebisu.dts
+++ b/arch/arm/dts/r8a77990-ebisu.dts
@@ -167,13 +167,13 @@
};
 
sdhi3_pins: sd2 {
-   groups = "sdhi3_data8", "sdhi3_ctrl";
+   groups = "sdhi3_data8", "sdhi3_ctrl", "sdhi3_ds";
function = "sdhi3";
power-source = <1800>;
};
 
sdhi3_pins_uhs: sd2_uhs {
-   groups = "sdhi3_data8", "sdhi3_ctrl";
+   groups = "sdhi3_data8", "sdhi3_ctrl", "sdhi3_ds";
function = "sdhi3";
power-source = <1800>;
};
@@ -238,6 +238,7 @@
vqmmc-supply = <®_1p8v>;
bus-width = <8>;
mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
non-removable;
status = "okay";
 };
diff --git a/arch/arm/dts/salvator-common.dtsi 
b/arch/arm/dts/salvator-common.dtsi
index d2d667bb01..e54f28ad0b 100644
--- a/arch/arm/dts/salvator-common.dtsi
+++ b/arch/arm/dts/salvator-common.dtsi
@@ -642,6 +642,7 @@
vqmmc-supply = <®_1p8v>;
bus-width = <8>;
mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
non-removable;
fixed-emmc-driver-type = <1>;
status = "okay";
diff --git a/arch/arm/dts/ulcb.dtsi b/arch/arm/dts/ulcb.dtsi
index 44dd84179f..4ad22adeca 100644
--- a/arch/arm/dts/ulcb.dtsi
+++ b/arch/arm/dts/ulcb.dtsi
@@ -419,6 +419,7 @@
vqmmc-supply = <®_1p8v>;
bus-width = <8>;
mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
non-removable;
status = "okay";
max-frequency = <2>;
-- 
2.18.0

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

[U-Boot] [PATCH 3/5] ARM: dts: rmobile: Enable SDR modes on E3 Ebisu

[Marek Vasut]

Add regulators and pinmuxes for SDHI0 and SDHI1 SD and microSD
slots on E3 Ebisu and mark them as capable of up to SDR104 mode
of operation. With the SDHI fixes in place, it is now possible
to use SDR104.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77990-ebisu.dts | 101 
 1 file changed, 101 insertions(+)

diff --git a/arch/arm/dts/r8a77990-ebisu.dts b/arch/arm/dts/r8a77990-ebisu.dts
index f9f949..6fcf0013b9 100644
--- a/arch/arm/dts/r8a77990-ebisu.dts
+++ b/arch/arm/dts/r8a77990-ebisu.dts
@@ -46,6 +46,54 @@
regulator-boot-on;
regulator-always-on;
};
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = <&gpio5 17 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi0: regulator-vccq-sdhi0 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
+   vcc_sdhi1: regulator-vcc-sdhi1 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI1 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi1: regulator-vccq-sdhi1 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI1 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
 };
 
 &avb {
@@ -94,6 +142,30 @@
function = "scif_clk";
};
 
+   sdhi0_pins: sd0 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
+   };
+
+   sdhi1_pins: sd1 {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
+   };
+
sdhi3_pins: sd2 {
groups = "sdhi3_data8", "sdhi3_ctrl";
function = "sdhi3";
@@ -120,11 +192,40 @@
 };
 
 &sdhi0 {
+   /* full size SD */
+   pinctrl-0 = <&sdhi0_pins>;
+   pinctrl-1 = <&sdhi0_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <&vcc_sdhi0>;
+   vqmmc-supply = <&vccq_sdhi0>;
+   cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+   wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+   bus-width = <4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
+   max-frequency = <20800>;
 };
 
 &sdhi1 {
+   /* microSD */
+   pinctrl-0 = <&sdhi1_pins>;
+   pinctrl-1 = <&sdhi1_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <&vcc_sdhi1>;
+   vqmmc-supply = <&vccq_sdhi1>;
+   cd-gpios = <&gpio3 14 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
+   max-frequency = <20800>;
 };
 
 &sdhi3 {
-- 
2.18.0

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

[U-Boot] [PATCH V3 6/6] mmc: tmio: sdhi: Add HS400 support

[Marek Vasut]

Add support for the HS400 mode to SDHI driver. This uses the up-tune
mechanism from already supported HS200 tuning.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
V3: New patch
---
 drivers/mmc/renesas-sdhi.c | 103 ++---
 drivers/mmc/tmio-common.h  |   1 +
 2 files changed, 96 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 1ed50d6292..259b4f71ed 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -17,7 +17,9 @@
 
 #include "tmio-common.h"
 
-#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
 
 /* SCC registers */
 #define RENESAS_SDHI_SCC_DTCNTL0x800
@@ -107,6 +109,56 @@ static void renesas_sdhi_reset_tuning(struct tmio_sd_priv 
*priv)
tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
 }
 
+static int renesas_sdhi_hs400(struct udevice *dev)
+{
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+   bool hs400 = (mmc->selected_mode == MMC_HS_400);
+   int ret, taps = hs400 ? priv->nrtaps : 8;
+   u32 reg;
+
+   if (taps == 4)  /* HS400 on 4tap SoC needs different clock */
+   ret = clk_set_rate(&priv->clk, 4);
+   else
+   ret = clk_set_rate(&priv->clk, 2);
+   if (ret < 0)
+   return ret;
+
+   tmio_sd_writel(priv, 0, RENESAS_SDHI_SCC_RVSREQ);
+
+   reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_TMPPORT2);
+   if (hs400) {
+   reg |= RENESAS_SDHI_SCC_TMPPORT2_HS400EN |
+  RENESAS_SDHI_SCC_TMPPORT2_HS400OSEL;
+   } else {
+   reg &= ~(RENESAS_SDHI_SCC_TMPPORT2_HS400EN |
+  RENESAS_SDHI_SCC_TMPPORT2_HS400OSEL);
+   }
+
+   tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_TMPPORT2);
+
+   tmio_sd_writel(priv, (taps << RENESAS_SDHI_SCC_DTCNTL_TAPNUM_SHIFT) |
+RENESAS_SDHI_SCC_DTCNTL_TAPEN,
+RENESAS_SDHI_SCC_DTCNTL);
+
+   if (taps == 4) {
+   tmio_sd_writel(priv, priv->tap_set >> 1,
+  RENESAS_SDHI_SCC_TAPSET);
+   } else {
+   tmio_sd_writel(priv, priv->tap_set, RENESAS_SDHI_SCC_TAPSET);
+   }
+
+   reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_CKSEL);
+   reg |= RENESAS_SDHI_SCC_CKSEL_DTSEL;
+   tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_CKSEL);
+
+   reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
+   reg |= RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+   tmio_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
+
+   return 0;
+}
+
 static void renesas_sdhi_prepare_tuning(struct tmio_sd_priv *priv,
   unsigned long tap)
 {
@@ -239,6 +291,7 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint 
opcode)
 
/* clock tuning is not needed for upto 52MHz */
if (!((mmc->selected_mode == MMC_HS_200) ||
+ (mmc->selected_mode == MMC_HS_400) ||
  (mmc->selected_mode == UHS_SDR104) ||
  (mmc->selected_mode == UHS_SDR50)))
return 0;
@@ -286,19 +339,42 @@ out:
 
return ret;
 }
+#else
+static int renesas_sdhi_hs400(struct udevice *dev)
+{
+   return 0;
+}
 #endif
 
 static int renesas_sdhi_set_ios(struct udevice *dev)
 {
-   int ret = tmio_sd_set_ios(dev);
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+   u32 tmp;
+   int ret;
 
-   mdelay(10);
+   /* Stop the clock before changing its rate to avoid a glitch signal */
+   tmp = tmio_sd_readl(priv, TMIO_SD_CLKCTL);
+   tmp &= ~TMIO_SD_CLKCTL_SCLKEN;
+   tmio_sd_writel(priv, tmp, TMIO_SD_CLKCTL);
 
-#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
-   struct tmio_sd_priv *priv = dev_get_priv(dev);
+   ret = renesas_sdhi_hs400(dev);
+   if (ret)
+   return ret;
+
+   ret = tmio_sd_set_ios(dev);
 
-   if (priv->caps & TMIO_SD_CAP_RCAR_UHS)
+   mdelay(10);
+
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   if ((priv->caps & TMIO_SD_CAP_RCAR_UHS) &&
+   (mmc->selected_mode != UHS_SDR104) &&
+   (mmc->selected_mode != MMC_HS_200) &&
+   (mmc->selected_mode != MMC_HS_400)) {
renesas_sdhi_reset_tuning(priv);
+   }
 #endif
 
return ret;
@@ -330,7 +406,9 @@ static const struct dm_mmc_ops renesas_sdhi_ops = {
.send_cmd = tmio_sd_send_cmd,
.set_ios = renesas_sdhi_set_ios,
.get_cd = tmio_sd_get_cd,
-#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+

[U-Boot] [PATCH 1/5] ARM: dts: rmobile: Add eMMC DS pinmux

[Marek Vasut]

Add pinmux entry for the eMMC DS line, as it is connected on these boards.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/salvator-common.dtsi | 4 ++--
 arch/arm/dts/ulcb.dtsi| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/salvator-common.dtsi 
b/arch/arm/dts/salvator-common.dtsi
index 514c57b2c8..826a02c333 100644
--- a/arch/arm/dts/salvator-common.dtsi
+++ b/arch/arm/dts/salvator-common.dtsi
@@ -480,13 +480,13 @@
};
 
sdhi2_pins: sd2 {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
 
sdhi2_pins_uhs: sd2_uhs {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
diff --git a/arch/arm/dts/ulcb.dtsi b/arch/arm/dts/ulcb.dtsi
index 4b00db8970..b61e2656d5 100644
--- a/arch/arm/dts/ulcb.dtsi
+++ b/arch/arm/dts/ulcb.dtsi
@@ -308,13 +308,13 @@
};
 
sdhi2_pins: sd2 {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
 
sdhi2_pins_uhs: sd2_uhs {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
-- 
2.18.0

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

[U-Boot] [PATCH V3 5/6] mmc: tmio: sdhi: Move tap_pos to private data

[Marek Vasut]

Move the tap_pos variable, which is the HS200/HS400/SDR104 calibration
offset, into private data, so it can be passed around. This is done in
preparation for the HS400 mode, which needs to adjust this value.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
V3: New patch
---
 drivers/mmc/renesas-sdhi.c | 5 ++---
 drivers/mmc/tmio-common.h  | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 0cc6f27279..1ed50d6292 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -125,7 +125,6 @@ static int renesas_sdhi_select_tuning(struct tmio_sd_priv 
*priv,
 unsigned int smpcmp)
 {
unsigned long tap_cnt;  /* counter of tuning success */
-   unsigned long tap_set;  /* tap position */
unsigned long tap_start;/* start position of tuning success */
unsigned long tap_end;  /* end position of tuning success */
unsigned long ntap; /* temporary counter of tuning success */
@@ -209,12 +208,12 @@ static int renesas_sdhi_select_tuning(struct tmio_sd_priv 
*priv,
select = true;
 
if (select)
-   tap_set = ((tap_start + tap_end) / 2) % tap_num;
+   priv->tap_set = ((tap_start + tap_end) / 2) % tap_num;
else
return -EIO;
 
/* Set SCC */
-   tmio_sd_writel(priv, tap_set, RENESAS_SDHI_SCC_TAPSET);
+   tmio_sd_writel(priv, priv->tap_set, RENESAS_SDHI_SCC_TAPSET);
 
/* Enable auto re-tuning */
reg = tmio_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
diff --git a/drivers/mmc/tmio-common.h b/drivers/mmc/tmio-common.h
index 6591c61c3c..9a427b5311 100644
--- a/drivers/mmc/tmio-common.h
+++ b/drivers/mmc/tmio-common.h
@@ -134,6 +134,9 @@ struct tmio_sd_priv {
 #endif
 #if CONFIG_IS_ENABLED(CLK)
struct clk  clk;
+#endif
+#if CONFIG_IS_ENABLED(RENESAS_SDHI)
+   u8  tap_set;
 #endif
ulong (*clk_get_rate)(struct tmio_sd_priv *);
 };
-- 
2.18.0

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

[U-Boot] [PATCH V3 4/6] mmc: tmio: sdhi: Filter out HS400 on certain SoCs

[Marek Vasut]

Filter out HS400 support on SoCs where HS400 is not supported yet.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
V3: New patch
---
 drivers/mmc/renesas-sdhi.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index f4283d055f..0cc6f27279 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -363,6 +363,23 @@ static ulong renesas_sdhi_clk_get_rate(struct tmio_sd_priv 
*priv)
return clk_get_rate(&priv->clk);
 }
 
+static void renesas_sdhi_filter_caps(struct udevice *dev)
+{
+   struct tmio_sd_plat *plat = dev_get_platdata(dev);
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
+
+   if (!(priv->caps & TMIO_SD_CAP_RCAR_GEN3))
+   return;
+
+   /* HS400 is not supported on H3 ES1.x and M3W ES1.0,ES1.1 */
+   if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
+   (rmobile_get_cpu_rev_integer() <= 1)) ||
+   ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+   (rmobile_get_cpu_rev_integer() == 1) &&
+   (rmobile_get_cpu_rev_fraction() <= 1)))
+   plat->cfg.host_caps &= ~MMC_MODE_HS400;
+}
+
 static int renesas_sdhi_probe(struct udevice *dev)
 {
struct tmio_sd_priv *priv = dev_get_priv(dev);
@@ -407,6 +424,9 @@ static int renesas_sdhi_probe(struct udevice *dev)
}
 
ret = tmio_sd_probe(dev, quirks);
+
+   renesas_sdhi_filter_caps(dev);
+
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
if (!ret && (priv->caps & TMIO_SD_CAP_RCAR_UHS))
renesas_sdhi_reset_tuning(priv);
-- 
2.18.0

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

[U-Boot] [PATCH V3 3/6] mmc: tmio: Keep generating clock when clock are enabled

[Marek Vasut]

The TMIO core has a feature where it can automatically disable clock output
when the bus is not in use. While this is useful, it also interferes with
switching the bus to 1.8V and other background tasks of the SD/MMC cards,
which require clock to be enabled.

This patch respects the mmc->clk_disable and only disables the clock when
the MMC core requests it. Otherwise the clock are continuously generated
on the bus.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
 drivers/mmc/tmio-common.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
index 424b60ce52..fad2816ca5 100644
--- a/drivers/mmc/tmio-common.c
+++ b/drivers/mmc/tmio-common.c
@@ -612,10 +612,16 @@ static void tmio_sd_set_clk_rate(struct tmio_sd_priv 
*priv,
tmio_sd_writel(priv, tmp, TMIO_SD_CLKCTL);
 
tmp &= ~TMIO_SD_CLKCTL_DIV_MASK;
-   tmp |= val | TMIO_SD_CLKCTL_OFFEN;
+   tmp |= val;
tmio_sd_writel(priv, tmp, TMIO_SD_CLKCTL);
 
-   tmp |= TMIO_SD_CLKCTL_SCLKEN;
+   if (!mmc->clk_disable) {
+   tmp &= ~TMIO_SD_CLKCTL_OFFEN;
+   tmp |= TMIO_SD_CLKCTL_SCLKEN;
+   } else {
+   tmp |= TMIO_SD_CLKCTL_OFFEN;
+   tmp &= ~TMIO_SD_CLKCTL_SCLKEN;
+   }
tmio_sd_writel(priv, tmp, TMIO_SD_CLKCTL);
 
udelay(1000);
-- 
2.18.0

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

[U-Boot] [PATCH V3 2/6] mmc: tmio: Do not set divider to 1 in DDR mode

[Marek Vasut]

The TMIO core has a quirk where divider == 1 must not be set in DDR modes.
Handle this by setting divider to 2, as suggested in the documentation.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
 drivers/mmc/tmio-common.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
index 3ba2f07460..424b60ce52 100644
--- a/drivers/mmc/tmio-common.c
+++ b/drivers/mmc/tmio-common.c
@@ -574,6 +574,10 @@ static void tmio_sd_set_clk_rate(struct tmio_sd_priv *priv,
 
divisor = DIV_ROUND_UP(mclk, mmc->clock);
 
+   /* Do not set divider to 0xff in DDR mode */
+   if (mmc->ddr_mode && (divisor == 1))
+   divisor = 2;
+
if (divisor <= 1)
val = (priv->caps & TMIO_SD_CAP_RCAR) ?
  TMIO_SD_CLKCTL_RCAR_DIV1 : TMIO_SD_CLKCTL_DIV1;
-- 
2.18.0

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

[U-Boot] [PATCH V3 1/6] mmc: tmio: Switch to clock framework

[Marek Vasut]

Switch the driver to using clk_get_rate()/clk_set_rate() instead of
caching the mclk frequency in it's private data. This is required on
the SDHI variant of the controller, where the upstream mclk need to
be adjusted when using UHS modes.

Platforms which do not support clock framework or do not support it
in eg. SPL default to 100 MHz clock.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
V2: - Fix build on certain platforms using SPL without clock framework
V3: - Turn clk_get_rate into a callback and fill it as needed on both
  renesas and socionext platforms
---
 drivers/mmc/renesas-sdhi.c | 21 +
 drivers/mmc/tmio-common.c  | 17 ++---
 drivers/mmc/tmio-common.h  |  5 -
 drivers/mmc/uniphier-sd.c  | 30 --
 4 files changed, 51 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index e7f96f8bf2..f4283d055f 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -358,15 +358,21 @@ static const struct udevice_id renesas_sdhi_match[] = {
{ /* sentinel */ }
 };
 
+static ulong renesas_sdhi_clk_get_rate(struct tmio_sd_priv *priv)
+{
+   return clk_get_rate(&priv->clk);
+}
+
 static int renesas_sdhi_probe(struct udevice *dev)
 {
struct tmio_sd_priv *priv = dev_get_priv(dev);
u32 quirks = dev_get_driver_data(dev);
struct fdt_resource reg_res;
-   struct clk clk;
DECLARE_GLOBAL_DATA_PTR;
int ret;
 
+   priv->clk_get_rate = renesas_sdhi_clk_get_rate;
+
if (quirks == RENESAS_GEN2_QUIRKS) {
ret = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev),
   "reg", 0, ®_res);
@@ -380,22 +386,21 @@ static int renesas_sdhi_probe(struct udevice *dev)
quirks |= TMIO_SD_CAP_16BIT;
}
 
-   ret = clk_get_by_index(dev, 0, &clk);
+   ret = clk_get_by_index(dev, 0, &priv->clk);
if (ret < 0) {
dev_err(dev, "failed to get host clock\n");
return ret;
}
 
/* set to max rate */
-   priv->mclk = clk_set_rate(&clk, ULONG_MAX);
-   if (IS_ERR_VALUE(priv->mclk)) {
+   ret = clk_set_rate(&priv->clk, 2);
+   if (ret < 0) {
dev_err(dev, "failed to set rate for host clock\n");
-   clk_free(&clk);
-   return priv->mclk;
+   clk_free(&priv->clk);
+   return ret;
}
 
-   ret = clk_enable(&clk);
-   clk_free(&clk);
+   ret = clk_enable(&priv->clk);
if (ret) {
dev_err(dev, "failed to enable host clock\n");
return ret;
diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
index 0eca83a0f4..3ba2f07460 100644
--- a/drivers/mmc/tmio-common.c
+++ b/drivers/mmc/tmio-common.c
@@ -555,16 +555,24 @@ static void tmio_sd_set_ddr_mode(struct tmio_sd_priv 
*priv,
tmio_sd_writel(priv, tmp, TMIO_SD_IF_MODE);
 }
 
+static ulong tmio_sd_clk_get_rate(struct tmio_sd_priv *priv)
+{
+   return priv->clk_get_rate(priv);
+}
+
 static void tmio_sd_set_clk_rate(struct tmio_sd_priv *priv,
 struct mmc *mmc)
 {
unsigned int divisor;
u32 val, tmp;
+   ulong mclk;
 
if (!mmc->clock)
return;
 
-   divisor = DIV_ROUND_UP(priv->mclk, mmc->clock);
+   mclk = tmio_sd_clk_get_rate(priv);
+
+   divisor = DIV_ROUND_UP(mclk, mmc->clock);
 
if (divisor <= 1)
val = (priv->caps & TMIO_SD_CAP_RCAR) ?
@@ -708,6 +716,7 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
struct tmio_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
fdt_addr_t base;
+   ulong mclk;
int ret;
 
base = devfdt_get_addr(dev);
@@ -750,10 +759,12 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
 
tmio_sd_host_init(priv);
 
+   mclk = tmio_sd_clk_get_rate(priv);
+
plat->cfg.voltages = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34;
-   plat->cfg.f_min = priv->mclk /
+   plat->cfg.f_min = mclk /
(priv->caps & TMIO_SD_CAP_DIV1024 ? 1024 : 512);
-   plat->cfg.f_max = priv->mclk;
+   plat->cfg.f_max = mclk;
plat->cfg.b_max = U32_MAX; /* max value of TMIO_SD_SECCNT */
 
upriv->mmc = &plat->mmc;
diff --git a/drivers/mmc/tmio-common.h b/drivers/mmc/tmio-common.h
index 792b1ba5ae..6591c61c3c 100644
--- a/drivers/mmc/tmio-common.h
+++ b/drivers/mmc/tmio-common.h
@@ -117,7 +117,6 @@ struct tmio_sd_plat {
 
 struct tmio_sd_priv {
void __iomem*regbase;
-   unsigned long   mclk;
unsigned intversion;
u32 caps;
 #define TMIO_SD_CAP_NONREMOVABLE   BIT(0)  /* Nonremovable e.g. eMMC */
@@ -133,6 +132,10 @@ struct tmio_sd_pr

[U-Boot] [PATCH] mmc: Parse HS400 DT properties

[Marek Vasut]

Add HS400 properties parsing support to mmc_of_parse().

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Jaehoon Chung 
Cc: Jean-Jacques Hiblot 
Cc: Kishon Vijay Abraham I 
Cc: Peng Fan 
Cc: Simon Glass 
---
 drivers/mmc/mmc-uclass.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index f73f07254b..76225b7939 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -166,6 +166,10 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config 
*cfg)
cfg->host_caps |= MMC_CAP(MMC_HS_200);
if (dev_read_bool(dev, "mmc-hs200-1_2v"))
cfg->host_caps |= MMC_CAP(MMC_HS_200);
+   if (dev_read_bool(dev, "mmc-hs400-1_8v"))
+   cfg->host_caps |= MMC_CAP(MMC_HS_400);
+   if (dev_read_bool(dev, "mmc-hs400-1_2v"))
+   cfg->host_caps |= MMC_CAP(MMC_HS_400);
 
return 0;
 }
-- 
2.18.0

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

[U-Boot] [PATCH] clk: renesas: Allow reconfiguring SDHI clock on Gen3

[Marek Vasut]

The SDHI clock must be configured differently for HS200/HS400/SDR104
modes. Add support for reconfiguring the SDHI clock settings into the
clock driver.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/clk/renesas/clk-rcar-gen3.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/renesas/clk-rcar-gen3.c 
b/drivers/clk/renesas/clk-rcar-gen3.c
index 99698b1f46..0529fc8763 100644
--- a/drivers/clk/renesas/clk-rcar-gen3.c
+++ b/drivers/clk/renesas/clk-rcar-gen3.c
@@ -107,7 +107,7 @@ static int gen3_clk_get_parent(struct gen3_clk_priv *priv, 
struct clk *clk,
return renesas_clk_get_parent(clk, info, parent);
 }
 
-static int gen3_clk_setup_sdif_div(struct clk *clk)
+static int gen3_clk_setup_sdif_div(struct clk *clk, ulong rate)
 {
struct gen3_clk_priv *priv = dev_get_priv(clk->dev);
struct cpg_mssr_info *info = priv->info;
@@ -133,7 +133,7 @@ static int gen3_clk_setup_sdif_div(struct clk *clk)
 
debug("%s[%i] SDIF offset=%x\n", __func__, __LINE__, core->offset);
 
-   writel(1, priv->base + core->offset);
+   writel((rate == 4) ? 0x4 : 0x1, priv->base + core->offset);
 
return 0;
 }
@@ -141,10 +141,6 @@ static int gen3_clk_setup_sdif_div(struct clk *clk)
 static int gen3_clk_enable(struct clk *clk)
 {
struct gen3_clk_priv *priv = dev_get_priv(clk->dev);
-   int ret = gen3_clk_setup_sdif_div(clk);
-
-   if (ret)
-   return ret;
 
return renesas_clk_endisable(clk, priv->base, true);
 }
@@ -328,7 +324,7 @@ static ulong gen3_clk_get_rate(struct clk *clk)
 static ulong gen3_clk_set_rate(struct clk *clk, ulong rate)
 {
/* Force correct SD-IF divider configuration if applicable */
-   gen3_clk_setup_sdif_div(clk);
+   gen3_clk_setup_sdif_div(clk, rate);
return gen3_clk_get_rate64(clk);
 }
 
-- 
2.18.0

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

Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

[Heinrich Schuchardt]

On 11/13/18 10:47 PM, Simon Goldschmidt wrote:
> 
> 
> Am Di., 13. Nov. 2018, 22:37 hat Heinrich Schuchardt  > geschrieben:
> 
> On 11/13/18 9:01 PM, Simon Goldschmidt wrote:
> > On 13.11.2018 20:42, Heinrich Schuchardt wrote:
> >> On 11/13/18 6:47 AM, Simon Goldschmidt wrote:
> >>> On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam
> mailto:feste...@gmail.com>>
> >>> wrote:
>  Hi Simon,
> 
>  On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
>   > wrote:
> 
> > diff --git a/fs/fs.c b/fs/fs.c
> > index adae98d021..4baf6b1c39 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t
> *size)
> >  return ret;
> >   }
> >
> > -int fs_read(const char *filename, ulong addr, loff_t offset,
> > loff_t len,
> > -   loff_t *actread)
> > +#ifdef CONFIG_LMB
>  Unrelated to your series, but I was wondering if we could get
> rid of
>  the CONFIG_LMB option.
> 
>  As far as I can see all the architectures define it, the only
>  exception being arch/sh.
> 
>  If you agree I can send a patch after your series gets applied that
>  removes CONFIG_LMB.
> >>> Sure, that would clean things up.
> >>>
> >>> Simon
> >>>
> >> NAK
> >>
> >> This patch-series does not provide what is needed. With
> >> odroid-c2_defconfig I get
> >>
> >> fdt list /reserved-memory/secmon@1000
> >> reserved-memory {
> >>  secmon@1000 {
> >>  reg = <0x 0x1000 0x 0x0020>;
> >>  no-map;
> >>  };
> >> };
> >>
> >> => load mmc 0:1 0x1000 dtb
> >> 22925 bytes read in 8 ms (2.7 MiB/s)
> >>
> >> So now I have successfully overwritten the secure monitor. Urrgh.
> >>
> >> As you have observed load is still writing into a memory area that is
> >> reserved by the device-tree.
> >>
> >> Please, iterate over the device tree to ensure that nothing is loaded
> >> into a reserved memory area. Do not expect board files to do anything
> >> but create the reserve-memory entry in the device tree.
> >
> > First of all, thanks for testing. I must admit I haven't tested this
> > case, I just had the impression the existing function
> > 'boot_fdt_add_mem_rsv_regions()' (in image-fdt.c) would do that. I'll
> > have to dig into why it doesn't.
> >
> > Or do you have CONFIG_OF_LIBFDT disabled?
> 
> `make odroid-c2_defconfig` sets
> CONFIG_OF_LIBFDT=y
> 
> CONFIG_CMD_FDT depends on it. So without I would not have had the fdt
> command used above.
> 
> The device-tree I was looking at was the one provided by U-Boot at
> ${fdtcontroladdr}.
> 
> 
> That might be an explanation. I used 'gd->fdt_blob' only in my patch.

For the Odroid C2 the relevant memory reservations are created in
arch/arm/mach-meson/board.c:61:
void meson_gx_init_reserved_memory(void *fdt)

According to /README ${fdtcontroladdr} and gd->fdt_blob should be the same:

lib/fdtdec.c:1255:
gd->fdt_blob = (void *)env_get_ulong("fdtcontroladdr", 16,
(uintptr_t)gd->fdt_blob);

The boards with CONFIG_OF_PRIOR_STAGE=y set fdtcontroladdr in the board
file (board/broadcom/bcmstb/bcmstb.c).

You should use gd->fdt_blob. Just make sure it is already set.

Best regards

Heinrich

> Are there any more device tree locations to care about?
> 
> We should also think about making this testable. I would be happy if we
> had a test on a QEMU board.
> 
> 
> I tried to build the tests but I only got build errors. Is there any
> documentation about what I could be missing? I think my Ubuntu should be
> up to date, so maybe I am missing some dependencies...?
> 
> Simon
> 
> 
> Best regards
> 
> Heinrich
> 
> >
> > In any case, it *was* my intention to include the dts memory
> > reservation! I'll make sure I test that for a v2.
> >
> > Simon
> >
> 

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

[U-Boot] [PATCH v3] sandbox: Use memmove() to move overlapping regions

[Simon Glass]

The use of strcpy() to remove characters at the start of a string is safe
in U-Boot, since we know the implementation. But in os.c we are using the
C library's strcpy() function, where this behaviour is not permitted.

Update the code to use memmove() instead.

Reported-by: Coverity (CID: 173279)
Signed-off-by: Simon Glass 
---

Changes in v3:
- Fix commit message to say memmove() instead of memcpy()

Changes in v2:
- Also remove the leading / from the "/spl" path
- Correct the string calculation

 arch/sandbox/cpu/os.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 07e46471fe5..04669bfc177 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -641,9 +641,10 @@ int os_find_u_boot(char *fname, int maxlen)
}
 
/* Look for 'u-boot' in the parent directory of spl/ */
-   p = strstr(fname, "/spl/");
+   p = strstr(fname, "spl/");
if (p) {
-   strcpy(p, p + 4);
+   /* Remove the "spl" characters */
+   memmove(p, p + 4, strlen(p + 4) + 1);
fd = os_open(fname, O_RDONLY);
if (fd >= 0) {
close(fd);
-- 
2.19.1.930.g4563a0d9d0-goog

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

[U-Boot] [PATCH] Makefile: Only build dtc if needed

[Simon Glass]

At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined. This
is wasteful when the system already has a suitable version available.

Update the Makefile logic to build dtc only if the version available is
too old.

This saves about 3 seconds of CPU time on a clean build for me.

Signed-off-by: Simon Glass 
---

 Makefile   | 17 +++--
 dts/Kconfig|  4 
 scripts/Kbuild.include |  4 +++-
 scripts/Makefile   |  1 -
 scripts/dtc-version.sh | 25 -
 5 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 250eb6c3c39..fec2b2d8fb5 100644
--- a/Makefile
+++ b/Makefile
@@ -361,7 +361,12 @@ PERL   = perl
 PYTHON ?= python
 PYTHON2= python2
 PYTHON3= python3
-DTC?= $(objtree)/scripts/dtc/dtc
+
+# DTC is automatically built if the version of $(DTC) is older that needed.
+# Use the system dtc if it is new enough.
+DTC?= dtc
+DTC_MIN_VERSION:= 010406
+
 CHECK  = sparse
 
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
@@ -926,7 +931,7 @@ endif
 PHONY += dtbs
 dtbs: dts/dt.dtb
@:
-dts/dt.dtb: u-boot
+dts/dt.dtb: checkdtc u-boot
$(Q)$(MAKE) $(build)=dts dtbs
 
 quiet_cmd_copy = COPY$@
@@ -1579,6 +1584,14 @@ SYSTEM_MAP = \
 System.map:u-boot
@$(call SYSTEM_MAP,$<) > $@
 
+build_dtc  := $(objtree)/scripts/dtc/dtc
+
+checkdtc:
+   $(eval DTC := $(call dtc-version,010406,$(build_dtc)))
+   if test "$(DTC)" = "$(build_dtc)"; then \
+   $(MAKE) $(build)=scripts/dtc; \
+   fi
+
 #
 
 # ARM relocations should all be R_ARM_RELATIVE (32-bit) or
diff --git a/dts/Kconfig b/dts/Kconfig
index 8917f424445..7e600e28f6c 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -5,9 +5,6 @@
 config SUPPORT_OF_CONTROL
bool
 
-config DTC
-   bool
-
 config PYLIBFDT
bool
 
@@ -24,7 +21,6 @@ menu "Device Tree Control"
 
 config OF_CONTROL
bool "Run-time configuration via Device Tree"
-   select DTC
help
  This feature provides for run-time configuration of U-Boot
  via a flattened device tree.
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 13ebddda65c..82be40cbe78 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -147,8 +147,10 @@ cc-fullversion = $(shell $(CONFIG_SHELL) \
 cc-ifversion = $(shell [ $(cc-version) $(1) $(2) ] && echo $(3) || echo $(4))
 
 # added for U-Boot
+# $1: min_version
+# #2: build_dtc
 binutils-version = $(shell $(CONFIG_SHELL) 
$(srctree)/scripts/binutils-version.sh $(AS))
-dtc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/dtc-version.sh $(DTC))
+dtc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/dtc-version.sh $(DTC) 
$1 $2)
 
 # cc-ldoption
 # Usage: ldflags += $(call cc-ldoption, -Wl$(comma)--hash-style=both)
diff --git a/scripts/Makefile b/scripts/Makefile
index e7b353f77f4..cfe9fef8044 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -10,4 +10,3 @@ always:= $(hostprogs-y)
 
 # Let clean descend into subdirs
 subdir-+= basic kconfig
-subdir-$(CONFIG_DTC)   += dtc
diff --git a/scripts/dtc-version.sh b/scripts/dtc-version.sh
index 0744c39eb04..ec988e18daf 100755
--- a/scripts/dtc-version.sh
+++ b/scripts/dtc-version.sh
@@ -1,12 +1,22 @@
 #!/bin/sh
 #
-# dtc-version dtc-command
+# dtc-version dtc_command min_version build_dtc
 #
-# Prints the dtc version of `dtc-command' in a canonical 6-digit form
-# such as `010404'  for dtc 1.4.4
+# Selects which version of dtc to use
+#
+# If the version of dtc_command is < min_version, prints build_dtc else
+# prints dtc_command. The min_version is in the format MMmmpp where:
+#
+#   MM is the major version
+#   mm is the minor version
+#   pp is the patch level
+#
+# For example 010406 means 1.4.6
 #
 
-dtc="$*"
+dtc="$1"
+min_version="$2"
+build_dtc="$3"
 
 if [ ${#dtc} -eq 0 ]; then
echo "Error: No dtc command specified."
@@ -18,4 +28,9 @@ MAJOR=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 1)
 MINOR=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 2)
 PATCH=$($dtc -v | head -1 | awk '{print $NF}' | cut -d . -f 3 | cut -d - -f 1)
 
-printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCH
+version="$(printf "%02d%02d%02d" $MAJOR $MINOR $PATCH)"
+if test $version -lt $min_version; then \
+   echo $build_dtc
+else
+   echo $dtc
+fi
-- 
2.19.1.930.g4563a0d9d0-goog

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

Re: [U-Boot] [U-Boot, v12, 1/6] sandbox: Put CPUs under a cpu-bus node

[Alexander Graf]

> The CPU uclass expects that all CPUs have a parent device which is a
> cpu-bus. Fix up the sandbox test DT to follow this convention. This allow
> the code in smbios_write_type4_dm() to work, since it calls
> dev_get_parent_platdata() on each CPU.
> 
> Signed-off-by: Simon Glass 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [PATCH v2 8/9] efi_loader: do not use magic address for fdt

[Alexander Graf]

On 13.11.18 22:31, Heinrich Schuchardt wrote:
> On 11/13/18 10:21 PM, Alexander Graf wrote:
>>
>>
>> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>>> We currently place the flattened device tree 127 MiB from the start of the
>>> first memory bank. This may be in a reserved memory area.
>>>
>>> So let's change the sequence: first create memory reservations and then
>>> copy the device tree.
>>>
>>> Do not use any magic address.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>
>> This would be a regression over commit
>> ad0c1a3d2cea03011091b07e9e066bf261d1556e no?
> 
> From your commit in ad0c1a3d2cea03011091b07e9e066bf261d1556e message I
> cannot infer which address would pose a problem and why.

Yeah, I was pretty disappointed with my commit message too :(.

It does mention Andreas. Maybe he remembers something?

> 
> You only mentioned it should be a place where the fdt can stay. Isn't
> this any address in a reserved memory area?
> 
> You did not provide any reference to a document recommending that an
> address around 128 MB should be favorable. Was the memory reservation
> missing at that time?

I really don't remember the details. It was something pretty dumb,
that's as far as my memory goes.

My point is that this is an explicit workaround for a real world problem
that existed. I see little reason to remove the workaround at this point
without proper validation that it's no longer needed. Unfortunately at
least for us ARMv7 is completely busted right now, because our kernel
binary became too big. So I don't have a good playground to do any
verification on.


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

Re: [U-Boot] [PATCH v2 1/9] fdt_support: fdt reservations on the sandbox

[Alexander Graf]

On 13.11.18 22:45, Heinrich Schuchardt wrote:
> On 11/13/18 10:35 PM, Simon Glass wrote:
>> Hi,
>>
>> On 13 November 2018 at 12:39, Alexander Graf  wrote:
>>>
>>>
>>> On 12.11.18 18:55, Heinrich Schuchardt wrote:
 On the sandbox the memory addresses in the device tree refer to the virtual
 address space of the sandbox. This implies that the memory reservations for
 the fdt also have to be converted to this address space.

 Signed-off-by: Heinrich Schuchardt 
 ---
 v2:
   no change
 ---
  common/fdt_support.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/common/fdt_support.c b/common/fdt_support.c
 index e6daa67990d..ec6af92dbba 100644
 --- a/common/fdt_support.c
 +++ b/common/fdt_support.c
 @@ -7,6 +7,7 @@
   */

  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
 initrd_end)
   }
   }

 - err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
 + err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt),
>>>
>>> This sounds like an API bug to me. Either fdt_add_mem_rsv() takes an
>>> address (ulong) or a pointer (void*). But taking void * while expecting
>>> an address to get passed in sounds pretty broken to me.
>>
>> Yes that can't be right. If it, we need to change the first param of
>> fdt_initrd() to a ulong and adjust.
> 
> Why? The first parameter is where address where the fdt lives. For any
> board but sandbox the current API is fine. And the sandbox is not the
> world but the playground.
> 
>>
>> We should use addresses in U-Boot code, not pointers.
>> We should use addresses in U-Boot code, not pointers.
>> We should use addresses in U-Boot code, not pointers.
> 
> Your repetitive poetry does not catch. A pointer holds an address in
> memory. Usage of different C types for the same content is just a way to
> confuse ones mind.

The way I managed to wrap my head around Simon's "address" and "pointer"
logic is:

  U-Boot address is what you would usually consider "physical address"
  Pointer is what you would usually consider "virtual address"

So a pointer is what you use to access memory from code. An address is
the location that an arbitrary virt/phys conversion mechanism points to.

I think the best analogy is Linux's PAE code. When you run on a 32bit
system, Linux can not fit more than 2 (or 3) GB of RAM into its linear
map. But hardware supports page table entries that point to addresses
>4GB. So Linux has something called HIGHMEM which allows you to
dynamically add/remove page table entries for regions that are in "high"
memory.

This is similar in concept. You have a physical address (U-Boot address
in Simon's speak), but you can't access it, because it may not be mapped
yet. To actually have a mapping, you have to go through the mapping
function.

The framework he borrowed from (map_sysmem and friends) was actually
created for exactly the PAE use case. So it is not a complete waste of
time to support it :).


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

Re: [U-Boot] [PATCH v3 27/28] riscv: qemu: detect and boot the kernel passed by QEMU

[Auer, Lukas]

On Tue, 2018-11-13 at 10:01 +0100, Alexander Graf wrote:
> 
> On 09.11.18 13:59, Lukas Auer wrote:
> > QEMU embeds the location of the kernel image in the device tree.
> > Store
> > this address in the environment as variable kernel_start. It is
> > used in
> > the board-local distro boot command QEMU to boot the kernel with
> > the
> > U-Boot device tree. The QEMU boot command is added as the first
> > boot
> > target device.
> > 
> > Signed-off-by: Lukas Auer 
> 
> That is a very elegant solution to the problem :). Awesome. Maybe we
> should consider to move to board specific distro targets for things
> like
> the NXP LS legacy flash boot as well?
> 

Thank you! I am not the only one using board-specific boot commands
however, I saw it used on sunxi with the FEL boot command. :)
Yes, I think that would make sense, even if it is just to move shared
targets into a common file and make them more reusable. There seems to
also be a lot of code duplication from config_distro_common.h in the
NXP LS board files, which can probably be removed.

Lukas

> Reviewed-by: Alexander Graf 
> 
> 
> Alex
> 
> > ---
> > 
> > Changes in v3:
> > - Adapt code and commit message to distro boot
> > - Replace printf with debug
> > - Clarify debug messages if no chosen node is found
> > 
> > Changes in v2:
> > - Rebase onto u-boot-dm/next
> > - Boot Linux with the device tree provided by the prior boot stage
> > 
> >  board/emulation/qemu-riscv/Kconfig  |  1 +
> >  board/emulation/qemu-riscv/qemu-riscv.c | 29
> > +
> >  include/configs/qemu-riscv.h| 10 +
> >  3 files changed, 40 insertions(+)
> > 
> > diff --git a/board/emulation/qemu-riscv/Kconfig
> > b/board/emulation/qemu-riscv/Kconfig
> > index 37a80db6a9..be5839b7db 100644
> > --- a/board/emulation/qemu-riscv/Kconfig
> > +++ b/board/emulation/qemu-riscv/Kconfig
> > @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > imply CMD_EXT2
> > imply CMD_EXT4
> > imply CMD_FAT
> > +   imply BOARD_LATE_INIT
> >  
> >  endif
> > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> > b/board/emulation/qemu-riscv/qemu-riscv.c
> > index 2ce093e19a..587f2c4909 100644
> > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > @@ -19,3 +19,32 @@ int board_init(void)
> >  
> > return 0;
> >  }
> > +
> > +int board_late_init(void)
> > +{
> > +   ulong kernel_start;
> > +   ofnode chosen_node;
> > +   int ret;
> > +
> > +   chosen_node = ofnode_path("/chosen");
> > +   if (!ofnode_valid(chosen_node)) {
> > +   debug("No chosen node found, can't get kernel start
> > address\n");
> > +   return 0;
> > +   }
> > +
> > +#ifdef CONFIG_ARCH_RV64I
> > +   ret = ofnode_read_u64(chosen_node, "riscv,kernel-start",
> > + (u64 *)&kernel_start);
> > +#else
> > +   ret = ofnode_read_u32(chosen_node, "riscv,kernel-start",
> > + (u32 *)&kernel_start);
> > +#endif
> > +   if (ret) {
> > +   debug("Can't find kernel start address in device
> > tree\n");
> > +   return 0;
> > +   }
> > +
> > +   env_set_hex("kernel_start", kernel_start);
> > +
> > +   return 0;
> > +}
> > diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-
> > riscv.h
> > index 66d61bd896..b29d155d09 100644
> > --- a/include/configs/qemu-riscv.h
> > +++ b/include/configs/qemu-riscv.h
> > @@ -21,11 +21,21 @@
> >  #define CONFIG_ENV_SIZESZ_4K
> >  
> >  #define BOOT_TARGET_DEVICES(func) \
> > +   func(QEMU, qemu, na) \
> > func(VIRTIO, virtio, 0) \
> > func(DHCP, dhcp, na)
> >  
> >  #include 
> >  
> > +#define BOOTENV_DEV_QEMU(devtypeu, devtypel, instance) \
> > +   "bootcmd_qemu=" \
> > +   "if env exists kernel_start; then " \
> > +   "bootm ${kernel_start} - ${fdtcontroladdr};" \
> > +   "fi;\0"
> > +
> > +#define BOOTENV_DEV_NAME_QEMU(devtypeu, devtypel, instance) \
> > +   "qemu "
> > +
> >  #define CONFIG_EXTRA_ENV_SETTINGS \
> > "fdt_high=0x\0" \
> > "initrd_high=0x\0" \
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

[Simon Goldschmidt]

Am Di., 13. Nov. 2018, 22:37 hat Heinrich Schuchardt 
geschrieben:

> On 11/13/18 9:01 PM, Simon Goldschmidt wrote:
> > On 13.11.2018 20:42, Heinrich Schuchardt wrote:
> >> On 11/13/18 6:47 AM, Simon Goldschmidt wrote:
> >>> On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam 
> >>> wrote:
>  Hi Simon,
> 
>  On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
>   wrote:
> 
> > diff --git a/fs/fs.c b/fs/fs.c
> > index adae98d021..4baf6b1c39 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
> >  return ret;
> >   }
> >
> > -int fs_read(const char *filename, ulong addr, loff_t offset,
> > loff_t len,
> > -   loff_t *actread)
> > +#ifdef CONFIG_LMB
>  Unrelated to your series, but I was wondering if we could get rid of
>  the CONFIG_LMB option.
> 
>  As far as I can see all the architectures define it, the only
>  exception being arch/sh.
> 
>  If you agree I can send a patch after your series gets applied that
>  removes CONFIG_LMB.
> >>> Sure, that would clean things up.
> >>>
> >>> Simon
> >>>
> >> NAK
> >>
> >> This patch-series does not provide what is needed. With
> >> odroid-c2_defconfig I get
> >>
> >> fdt list /reserved-memory/secmon@1000
> >> reserved-memory {
> >>  secmon@1000 {
> >>  reg = <0x 0x1000 0x 0x0020>;
> >>  no-map;
> >>  };
> >> };
> >>
> >> => load mmc 0:1 0x1000 dtb
> >> 22925 bytes read in 8 ms (2.7 MiB/s)
> >>
> >> So now I have successfully overwritten the secure monitor. Urrgh.
> >>
> >> As you have observed load is still writing into a memory area that is
> >> reserved by the device-tree.
> >>
> >> Please, iterate over the device tree to ensure that nothing is loaded
> >> into a reserved memory area. Do not expect board files to do anything
> >> but create the reserve-memory entry in the device tree.
> >
> > First of all, thanks for testing. I must admit I haven't tested this
> > case, I just had the impression the existing function
> > 'boot_fdt_add_mem_rsv_regions()' (in image-fdt.c) would do that. I'll
> > have to dig into why it doesn't.
> >
> > Or do you have CONFIG_OF_LIBFDT disabled?
>
> `make odroid-c2_defconfig` sets
> CONFIG_OF_LIBFDT=y
>
> CONFIG_CMD_FDT depends on it. So without I would not have had the fdt
> command used above.
>
> The device-tree I was looking at was the one provided by U-Boot at
> ${fdtcontroladdr}.
>

That might be an explanation. I used 'gd->fdt_blob' only in my patch. Are
there any more device tree locations to care about?

We should also think about making this testable. I would be happy if we
> had a test on a QEMU board.
>

I tried to build the tests but I only got build errors. Is there any
documentation about what I could be missing? I think my Ubuntu should be up
to date, so maybe I am missing some dependencies...?

Simon


> Best regards
>
> Heinrich
>
> >
> > In any case, it *was* my intention to include the dts memory
> > reservation! I'll make sure I test that for a v2.
> >
> > Simon
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/9] fdt_support: fdt reservations on the sandbox

[Heinrich Schuchardt]

On 11/13/18 10:35 PM, Simon Glass wrote:
> Hi,
> 
> On 13 November 2018 at 12:39, Alexander Graf  wrote:
>>
>>
>> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>>> On the sandbox the memory addresses in the device tree refer to the virtual
>>> address space of the sandbox. This implies that the memory reservations for
>>> the fdt also have to be converted to this address space.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> v2:
>>>   no change
>>> ---
>>>  common/fdt_support.c | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>>> index e6daa67990d..ec6af92dbba 100644
>>> --- a/common/fdt_support.c
>>> +++ b/common/fdt_support.c
>>> @@ -7,6 +7,7 @@
>>>   */
>>>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
>>> initrd_end)
>>>   }
>>>   }
>>>
>>> - err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
>>> + err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt),
>>
>> This sounds like an API bug to me. Either fdt_add_mem_rsv() takes an
>> address (ulong) or a pointer (void*). But taking void * while expecting
>> an address to get passed in sounds pretty broken to me.
> 
> Yes that can't be right. If it, we need to change the first param of
> fdt_initrd() to a ulong and adjust.

Why? The first parameter is where address where the fdt lives. For any
board but sandbox the current API is fine. And the sandbox is not the
world but the playground.

> 
> We should use addresses in U-Boot code, not pointers.
> We should use addresses in U-Boot code, not pointers.
> We should use addresses in U-Boot code, not pointers.

Your repetitive poetry does not catch. A pointer holds an address in
memory. Usage of different C types for the same content is just a way to
confuse ones mind.

Regards

Heinrich

> 
> It avoids so much confusion.
> 
> Regards,
> Simon
> 
>>
>> Simon?
>>
>>
>> Alex
>>
>>> +   initrd_start, initrd_end - initrd_start);
>>>   if (err < 0) {
>>>   printf("fdt_initrd: %s\n", fdt_strerror(err));
>>>   return err;
>>> @@ -633,7 +635,8 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
>>>   fdt_set_totalsize(blob, actualsize);
>>>
>>>   /* Add the new reservation */
>>> - ret = fdt_add_mem_rsv(blob, (uintptr_t)blob, actualsize);
>>> + ret = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(blob),
>>> +   (uintptr_t)blob, actualsize);
>>>   if (ret < 0)
>>>   return ret;
>>>
>>>
> 

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

Re: [U-Boot] [PATCH v2 2/9] efi_loader: fix efi_find_free_memory()

[Alexander Graf]

On 13.11.18 22:21, Heinrich Schuchardt wrote:
> On 11/13/18 9:56 PM, Alexander Graf wrote:
>>
>>
>> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>>> In efi_find_free_memory() the sandbox uses its virtual address space.
>>> Add the missing mapping.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>
>> The real bug here is much worse. According to 2.3.4 "x64 Platforms" of
>> the UEFI spec:
>>
>> ===
>> Paging mode is enabled and any memory space defined by the UEFI memory
>> map is identity mapped (virtual address equals physical address),
>> although the attributes of certain regions may not have all read, write,
>> and execute attributes or be unmarked for purposes of platform
>> protection. The mappings to other regions are undefined and may vary
>> from implementation to implementation.
>> ===
>>
>> This means we can't have virtual != physical. We need to go with all
>> physical (pointers) instead. Anything else violates the spec.
>>
>>
>> Alex
> 
> The sandbox runs inside of Linux. In user space we will never have
> access to physical memory addresses (see the mmap() man page).

All APIs refer to "physical address" as pointers they use. So
AllocatePages() for example returns an EFI_PHYSICAL_ADDRESS. That means
in the sandbox case, a Linux poionter is our EFI physical address.

On top of that, the UEFI spec says that an application may expect that
virtual == physical.

So in other words, we can not assume that anything may use sandbox
addresses anywhere in the EFI layer.


Today we have the following mapping:

physical -> pointer
virtual  -> sandbox address

What your patch is trying to fix is that some payload (not sure what,
probably just an internal user?) is passing max_addr as virtual
(sandbox) address. But the UEFI spec doesn't explicitly state whether
max_addr is a virtual (sandbox) or a physical (pointer) address. It
simply assumes they're equal during boot time.

So any conversion is wrong :).

> 
> My understanding is that for sandbox testing to run smoothly all
> addresses seen on the sandbox in the user interface are neither physical
> nor virtual addresses in the CPU sense but exist in a 3rd address space
> only known to the sandbox.
> 
> Without implementing a virtual machine we will never implement
> SetVirtualAddressMap() on the sandbox. And with a virtual machine we
> would loose all the advantages of the sandbox.
> 
> With the current setup we should be able to run the EFI shell and even
> SCT on the sandbox as long as SetVirtualAddressMap() is not reached. But
> we will never boot an operating system on the sandbox.

Yes, but before SetVirtualAddressMap the spec mandates that phys == virt
and that means phys == virt == pointer.


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

Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

[Heinrich Schuchardt]

On 11/13/18 9:01 PM, Simon Goldschmidt wrote:
> On 13.11.2018 20:42, Heinrich Schuchardt wrote:
>> On 11/13/18 6:47 AM, Simon Goldschmidt wrote:
>>> On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam 
>>> wrote:
 Hi Simon,

 On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
  wrote:

> diff --git a/fs/fs.c b/fs/fs.c
> index adae98d021..4baf6b1c39 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
>  return ret;
>   }
>
> -int fs_read(const char *filename, ulong addr, loff_t offset,
> loff_t len,
> -   loff_t *actread)
> +#ifdef CONFIG_LMB
 Unrelated to your series, but I was wondering if we could get rid of
 the CONFIG_LMB option.

 As far as I can see all the architectures define it, the only
 exception being arch/sh.

 If you agree I can send a patch after your series gets applied that
 removes CONFIG_LMB.
>>> Sure, that would clean things up.
>>>
>>> Simon
>>>
>> NAK
>>
>> This patch-series does not provide what is needed. With
>> odroid-c2_defconfig I get
>>
>> fdt list /reserved-memory/secmon@1000
>> reserved-memory {
>>  secmon@1000 {
>>  reg = <0x 0x1000 0x 0x0020>;
>>  no-map;
>>  };
>> };
>>
>> => load mmc 0:1 0x1000 dtb
>> 22925 bytes read in 8 ms (2.7 MiB/s)
>>
>> So now I have successfully overwritten the secure monitor. Urrgh.
>>
>> As you have observed load is still writing into a memory area that is
>> reserved by the device-tree.
>>
>> Please, iterate over the device tree to ensure that nothing is loaded
>> into a reserved memory area. Do not expect board files to do anything
>> but create the reserve-memory entry in the device tree.
> 
> First of all, thanks for testing. I must admit I haven't tested this
> case, I just had the impression the existing function
> 'boot_fdt_add_mem_rsv_regions()' (in image-fdt.c) would do that. I'll
> have to dig into why it doesn't.
> 
> Or do you have CONFIG_OF_LIBFDT disabled?

`make odroid-c2_defconfig` sets
CONFIG_OF_LIBFDT=y

CONFIG_CMD_FDT depends on it. So without I would not have had the fdt
command used above.

The device-tree I was looking at was the one provided by U-Boot at
${fdtcontroladdr}.

We should also think about making this testable. I would be happy if we
had a test on a QEMU board.

Best regards

Heinrich

> 
> In any case, it *was* my intention to include the dts memory
> reservation! I'll make sure I test that for a v2.
> 
> Simon
> 

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

Re: [U-Boot] [PATCH v2 1/9] fdt_support: fdt reservations on the sandbox

[Simon Glass]

Hi,

On 13 November 2018 at 12:39, Alexander Graf  wrote:
>
>
> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>> On the sandbox the memory addresses in the device tree refer to the virtual
>> address space of the sandbox. This implies that the memory reservations for
>> the fdt also have to be converted to this address space.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> v2:
>>   no change
>> ---
>>  common/fdt_support.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index e6daa67990d..ec6af92dbba 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -7,6 +7,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
>> initrd_end)
>>   }
>>   }
>>
>> - err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
>> + err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt),
>
> This sounds like an API bug to me. Either fdt_add_mem_rsv() takes an
> address (ulong) or a pointer (void*). But taking void * while expecting
> an address to get passed in sounds pretty broken to me.

Yes that can't be right. If it, we need to change the first param of
fdt_initrd() to a ulong and adjust.

We should use addresses in U-Boot code, not pointers.
We should use addresses in U-Boot code, not pointers.
We should use addresses in U-Boot code, not pointers.

It avoids so much confusion.

Regards,
Simon

>
> Simon?
>
>
> Alex
>
>> +   initrd_start, initrd_end - initrd_start);
>>   if (err < 0) {
>>   printf("fdt_initrd: %s\n", fdt_strerror(err));
>>   return err;
>> @@ -633,7 +635,8 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
>>   fdt_set_totalsize(blob, actualsize);
>>
>>   /* Add the new reservation */
>> - ret = fdt_add_mem_rsv(blob, (uintptr_t)blob, actualsize);
>> + ret = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(blob),
>> +   (uintptr_t)blob, actualsize);
>>   if (ret < 0)
>>   return ret;
>>
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: eliminate sandbox addresses

[Simon Glass]

Hi Alex,

On 13 November 2018 at 11:58, Alexander Graf  wrote:
>
>
> On 13.11.18 20:53, Simon Glass wrote:
>> Hi Heinrich,
>>
>> On 10 November 2018 at 14:30, Heinrich Schuchardt  wrote:
>>> Do not use the sandbox's virtual address space for the internal structures
>>> of the memory map. This way we can eliminate a whole lot of unnecessary
>>> conversions.
>>>
>>> The only conversion remaining is the one when adding known memory.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  lib/efi_loader/efi_memory.c | 17 -
>>>  1 file changed, 4 insertions(+), 13 deletions(-)
>>
>> I much prefer this, but Alex was not too keen.
>
> Uh, I thought you were the one who wanted to only expose fake addresses?
> I think the patch is great as is :). It definitely simplifies the code.

Ah funny! Well good that Heinrich sent this patch.

My original patch used U-Boot addresses internally and then only dealt
with real pointers in the API functions themselves. Anything that gets
us closed to that is good with me.

I don't want to rehash this, but I would much prefer to use
ulong/uin64 for addresses and void * for pointers, where possible. Of
course it isn't possible in the EFI API itself :-)

>
>> Also please can you add detailed comments to efi_mem_desc about what
>> the addresses are for sandbox?
>
> I'll wait for v2 then.
>
>
> Alex

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

Re: [U-Boot] [PATCH v12 2/6] efi_loader: Drop setup_ok

[Simon Glass]

Hi Alex,

On 13 November 2018 at 11:59, Alexander Graf  wrote:
>
>
> On 06.11.18 23:57, Simon Glass wrote:
>> This value is stored in data which appears to be read-only with sandbox on
>> my Ubuntu 18.04 machine. In any case it is not good practice to store
>> run-time data in a build-time linker list.
>>
>> The value does not seem to be that useful, since tests that fail to setup
>> are likely to fail to run also. Let's drop it for now.
>>
>> Signed-off-by: Simon Glass 
>
> I think I already have this as "efi_selftest: do not write to linker
> generated array" in my queue?

Yes that's right, we can drop this.

I still don't really understand why we have this write-to-rwdata problem.

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

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

[Simon Glass]

Hi,

On 13 November 2018 at 11:58, Vagrant Cascadian  wrote:
> On 2018-09-13, Marty E. Plummer wrote:
>> This adds support for the ASUS C201, a RK3288-based clamshell
>> device. The device tree comes from linus's linux tree at
>> 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters
>> are for 4GB Samsung LPDDR3, decoded from coreboot's
>> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
>
> Any outstanding blockers on getting this patch series merged?

Not that I know of.

The version history should be included with v2 patch so we know what
changes were made from v1.

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

Re: [U-Boot] UBoot running UBoot - is it possible?

[Simon Glass]

Hi Simon,

On 13 November 2018 at 12:17, Simon Goldschmidt
 wrote:
> On 13.11.2018 20:53, Simon Glass wrote:
>>
>> Hi Allan,
>>
>> On 12 November 2018 at 18:38, Allan Chandler 
>> wrote:
>>>
>>> Hello, bods.
>>>
>>> We're trying to architect a relatively safe solution for updating UBoot
>>> in the field. What we have at the moment is an iMX6-based board with two
>>> UBoot partitions and two system partitions but we only use the first UBoot
>>> one. Switching system partitions is covered well by UBoot since we use what
>>> seems like a fairly standard method involving upgrade_available, bootlimit
>>> and bootcount variables, along with bootcmd/altbootcmd scripts to try and
>>> load a new system partition while falling back if it fails.
>>>
>>> However, I'm wondering how people handle the need to update UBoot itself.
>>> Although this will happen FAR less often than normal software updates, these
>>> product have a multi-decade lifespan and it's hard to imagine we'll get
>>> through that without some update being needed. Especially since we need one
>>> now (three years in) due to a bug (with our added stuff, not UBoot
>>> baseline). With the iMX6 boards we have, once we tell it to start using the
>>> second UBoot partition, there's no UBoot/watchdog combo that will revert
>>> that change and reprogramming requires a rather expensive RTB (return to
>>> base) to fix via the serial interface.
>>>
>>> What we had hoped to do was to be able to soft-boot an alternate UBoot
>>> (i.e., without first telling the iMX6 board to commit to the change). The
>>> scenario would go like this:
>>>
>>> 1/ Have an installer package (it runs under control of the system
>>> partition) that just writes the new UBoot image into the alternate UBoot
>>> partition then soft-boots it somehow (so now running same system partition
>>> but started from the new UBoot image).
>>>
>>> 2/ While running from the system partition started from that alternate
>>> UBoot partition, have an updater package that tells the iMX6 board to commit
>>> to the changeover. This updater package would only run if it detected that
>>> the bootable UBoot and currently-used UBoot were different.
>>>
>>> The advantage of this is that, unless the new UBoot is FULLY capable of
>>> running our system partition (and also running an installer from there), no
>>> commit is possible, hence a simple power cycle would return to the previous
>>> working state.
>>>
>>> We originally tried kexec from the system partition but it seemed to want
>>> to run a Linux kernel rather than loading and executing some arbitrary boot
>>> code.
>>>
>>> So we then turned to the UBoot scripts themselves and thought we'd found
>>> a way we could do it.
>>>
>>> 1/ We changed the mmcboot script by prefixing a special check and
>>> introduced a variable for handling soft-boot:
>>>  mmcboot=run check_uboot; 
>>>  other_uboot=0
>>>
>>> 2/ We extracted the boot image uboot.bootimg from the IMX file by
>>> stripping off the first 0xc00 bytes (we had to put this into the /boot file
>>> system since I don't yet know how to get at raw partition data from UBoot
>>> scripts.
>>>
>>> 3/ We defined check_uboot as:
>>>  if test ${other_uboot} -eq 1; then
>>>  setenv other_uboot 0
>>>  saveenv
>>>  ext4load mmc ${mmcdev}:${mmcpart} 0x1780
>>> /boot/uboot.bootimg
>>>  go 0x1780
>>>  fi
>>> The way this should work is that, if alternate boot is flagged, it
>>> immediately unflags it (for recovery if the alternate fails) then loads and
>>> executes the other UBoot image. If it's not flagged, check_uboot will return
>>> without trying to soft-boot the alternate.
>>>
>>> 4/ After installing the new UBoot to the alternate partition, we set a
>>> UBoot variable (other_uboot) to 1 and rebooted.
>>>
>>> Now this seemed to work inasmuch as the alternate UBoot program started
>>> pumping out console messages but, unfortunately, it seemed to hang partway
>>> through the boot process.
>>>
>>> I suspect this is because, having already been through a portion of that
>>> boot process in the primary UBoot, it's not keen on having to do it again.
>>
>> You may need to flush the cache area that you read into, or use
>> 'dcache off' before jumping to the second U-Boot.
>>
>>> So I guess my questions are as follows:
>>>
>>> a/ How do people currently handle (if they do) the requirement that UBoot
>>> be safely updatable in the field?
>>> b/ Does anyone have any ideas on how I could achieve this?
>>>
>>> I've been told that Google does something like this for Android booting
>>> but had to heavily modify UBoot to do it. I haven't yet investigated this
>>> possibility.
>>
>> Chromium OS and Android verified boot (which is in mainline - see avb)
>> use an A/B system. You can have SPL chosen whether to boot from A or
>> B.
>>
>> I'm actually working on integrating Chromium OS vboot 

Re: [U-Boot] [PATCH v2 8/9] efi_loader: do not use magic address for fdt

[Heinrich Schuchardt]

On 11/13/18 10:21 PM, Alexander Graf wrote:
> 
> 
> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>> We currently place the flattened device tree 127 MiB from the start of the
>> first memory bank. This may be in a reserved memory area.
>>
>> So let's change the sequence: first create memory reservations and then
>> copy the device tree.
>>
>> Do not use any magic address.
>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> This would be a regression over commit
> ad0c1a3d2cea03011091b07e9e066bf261d1556e no?

From your commit in ad0c1a3d2cea03011091b07e9e066bf261d1556e message I
cannot infer which address would pose a problem and why.

You only mentioned it should be a place where the fdt can stay. Isn't
this any address in a reserved memory area?

You did not provide any reference to a document recommending that an
address around 128 MB should be favorable. Was the memory reservation
missing at that time?

Best regards

Heinrich

> 
> 
> Alex
> 
>> ---
>> v2:
>>  Remove code handling memory reservation for the fdt.
>> ---
>>  cmd/bootefi.c | 32 +++-
>>  1 file changed, 7 insertions(+), 25 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 50253ea1859..251d8403bcc 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -189,32 +189,20 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
>>  fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
>>  fdt_size = fdt_pages << EFI_PAGE_SHIFT;
>>  
>> -/*
>> - * Safe fdt location is at 127 MiB. On the sandbox convert from the
>> - * virtual address space.
>> - */
>> -new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
>> - fdt_size, 0);
>> +new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
>>  ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>>   EFI_RUNTIME_SERVICES_DATA, fdt_pages,
>>   &new_fdt_addr);
>>  if (ret != EFI_SUCCESS) {
>> -/* If we can't put it there, put it somewhere */
>> -new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
>> -ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>> - EFI_RUNTIME_SERVICES_DATA, fdt_pages,
>> - &new_fdt_addr);
>> -if (ret != EFI_SUCCESS) {
>> -printf("ERROR: Failed to reserve space for FDT\n");
>> -goto done;
>> -}
>> +printf("ERROR: Failed to allocate memory for FDT\n");
>> +return ret;
>>  }
>>  new_fdt = (void *)(uintptr_t)new_fdt_addr;
>>  memcpy(new_fdt, fdt, fdt_totalsize(fdt));
>>  fdt_set_totalsize(new_fdt, fdt_size);
>>  
>>  *fdt_addrp = new_fdt_addr;
>> -done:
>> +
>>  return ret;
>>  }
>>  
>> @@ -284,13 +272,6 @@ static void efi_carve_out_dt_rsv(void *fdt)
>>  /* Convert from sandbox address space. */
>>  addr = (uintptr_t)map_sysmem(addr, 0);
>>  
>> -/*
>> - * Do not carve out the device tree. It is already marked as
>> - * EFI_RUNTIME_SERVICES_DATA
>> - */
>> -if (addr == (uintptr_t)fdt)
>> -continue;
>> -
>>  pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
>>  addr &= ~EFI_PAGE_MASK;
>>  if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
>> @@ -310,6 +291,9 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>>  return EFI_INVALID_PARAMETER;
>>  }
>>  
>> +/* Create memory reservation as indicated by the device tree */
>> +efi_carve_out_dt_rsv(fdt);
>> +
>>  /* Prepare fdt for payload */
>>  ret = copy_fdt(&fdt_addr);
>>  if (ret)
>> @@ -321,8 +305,6 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>>  return EFI_LOAD_ERROR;
>>  }
>>  
>> -efi_carve_out_dt_rsv(fdt);
>> -
>>  /* Link to it in the efi tables */
>>  ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
>>  if (ret != EFI_SUCCESS)
>>
> 

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

Re: [U-Boot] [PATCH v2 8/9] efi_loader: do not use magic address for fdt

[Alexander Graf]

On 12.11.18 18:55, Heinrich Schuchardt wrote:
> We currently place the flattened device tree 127 MiB from the start of the
> first memory bank. This may be in a reserved memory area.
> 
> So let's change the sequence: first create memory reservations and then
> copy the device tree.
> 
> Do not use any magic address.
> 
> Signed-off-by: Heinrich Schuchardt 

This would be a regression over commit
ad0c1a3d2cea03011091b07e9e066bf261d1556e no?


Alex

> ---
> v2:
>   Remove code handling memory reservation for the fdt.
> ---
>  cmd/bootefi.c | 32 +++-
>  1 file changed, 7 insertions(+), 25 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 50253ea1859..251d8403bcc 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -189,32 +189,20 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
>   fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
>   fdt_size = fdt_pages << EFI_PAGE_SHIFT;
>  
> - /*
> -  * Safe fdt location is at 127 MiB. On the sandbox convert from the
> -  * virtual address space.
> -  */
> - new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
> -  fdt_size, 0);
> + new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
>   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>EFI_RUNTIME_SERVICES_DATA, fdt_pages,
>&new_fdt_addr);
>   if (ret != EFI_SUCCESS) {
> - /* If we can't put it there, put it somewhere */
> - new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
> - ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> -  EFI_RUNTIME_SERVICES_DATA, fdt_pages,
> -  &new_fdt_addr);
> - if (ret != EFI_SUCCESS) {
> - printf("ERROR: Failed to reserve space for FDT\n");
> - goto done;
> - }
> + printf("ERROR: Failed to allocate memory for FDT\n");
> + return ret;
>   }
>   new_fdt = (void *)(uintptr_t)new_fdt_addr;
>   memcpy(new_fdt, fdt, fdt_totalsize(fdt));
>   fdt_set_totalsize(new_fdt, fdt_size);
>  
>   *fdt_addrp = new_fdt_addr;
> -done:
> +
>   return ret;
>  }
>  
> @@ -284,13 +272,6 @@ static void efi_carve_out_dt_rsv(void *fdt)
>   /* Convert from sandbox address space. */
>   addr = (uintptr_t)map_sysmem(addr, 0);
>  
> - /*
> -  * Do not carve out the device tree. It is already marked as
> -  * EFI_RUNTIME_SERVICES_DATA
> -  */
> - if (addr == (uintptr_t)fdt)
> - continue;
> -
>   pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
>   addr &= ~EFI_PAGE_MASK;
>   if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> @@ -310,6 +291,9 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>   return EFI_INVALID_PARAMETER;
>   }
>  
> + /* Create memory reservation as indicated by the device tree */
> + efi_carve_out_dt_rsv(fdt);
> +
>   /* Prepare fdt for payload */
>   ret = copy_fdt(&fdt_addr);
>   if (ret)
> @@ -321,8 +305,6 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>   return EFI_LOAD_ERROR;
>   }
>  
> - efi_carve_out_dt_rsv(fdt);
> -
>   /* Link to it in the efi tables */
>   ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
>   if (ret != EFI_SUCCESS)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/9] efi_loader: fix efi_find_free_memory()

[Heinrich Schuchardt]

On 11/13/18 9:56 PM, Alexander Graf wrote:
> 
> 
> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>> In efi_find_free_memory() the sandbox uses its virtual address space.
>> Add the missing mapping.
>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> The real bug here is much worse. According to 2.3.4 "x64 Platforms" of
> the UEFI spec:
> 
> ===
> Paging mode is enabled and any memory space defined by the UEFI memory
> map is identity mapped (virtual address equals physical address),
> although the attributes of certain regions may not have all read, write,
> and execute attributes or be unmarked for purposes of platform
> protection. The mappings to other regions are undefined and may vary
> from implementation to implementation.
> ===
> 
> This means we can't have virtual != physical. We need to go with all
> physical (pointers) instead. Anything else violates the spec.
> 
> 
> Alex

The sandbox runs inside of Linux. In user space we will never have
access to physical memory addresses (see the mmap() man page).

My understanding is that for sandbox testing to run smoothly all
addresses seen on the sandbox in the user interface are neither physical
nor virtual addresses in the CPU sense but exist in a 3rd address space
only known to the sandbox.

Without implementing a virtual machine we will never implement
SetVirtualAddressMap() on the sandbox. And with a virtual machine we
would loose all the advantages of the sandbox.

With the current setup we should be able to run the EFI shell and even
SCT on the sandbox as long as SetVirtualAddressMap() is not reached. But
we will never boot an operating system on the sandbox.

Best regards

Heinrich

> 
>> ---
>> v2:
>>  no change
>> ---
>>  lib/efi_loader/efi_memory.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index dc282fe249f..c0277355056 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -294,6 +294,9 @@ static uint64_t efi_find_free_memory(uint64_t len, 
>> uint64_t max_addr)
>>  {
>>  struct list_head *lhandle;
>>  
>> +/* Map to virtual address on sandbox */
>> +max_addr = map_to_sysmem((void *)(uintptr_t)max_addr);
>> +
>>  /*
>>   * Prealign input max address, so we simplify our matching
>>   * logic below and can just reuse it as return pointer.
>>
> 

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

Re: [U-Boot] [PATCH v2 7/9] efi_loader: fix memory mapping for sandbox

[Alexander Graf]

On 12.11.18 18:55, Heinrich Schuchardt wrote:
> The sandbox is using a virtual address space. The addresses used insided
> the flattened device tree use the virtual address space. The EFI subsystem
> uses the addressable address space and this is where the fdt is stored.
> 
> Fix all incorrect addresses for the fdt.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   use copy of fdt not the original fdt
> ---
>  cmd/bootefi.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 2c9b2eb8b6f..50253ea1859 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -185,12 +185,16 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
>* Give us at least 12 KiB of breathing room in case the device tree
>* needs to be expanded later.
>*/
> - fdt = map_sysmem(*fdt_addrp, 0);
> + fdt = (void *)*fdt_addrp;
>   fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
>   fdt_size = fdt_pages << EFI_PAGE_SHIFT;
>  
> - /* Safe fdt location is at 127MB */
> - new_fdt_addr = fdt_ram_start + (127 * 1024 * 1024) + fdt_size;
> + /*
> +  * Safe fdt location is at 127 MiB. On the sandbox convert from the
> +  * virtual address space.
> +  */
> + new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
> +  fdt_size, 0);

Yes.

>   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>EFI_RUNTIME_SERVICES_DATA, fdt_pages,
>&new_fdt_addr);
> @@ -205,8 +209,7 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
>   goto done;
>   }
>   }
> -
> - new_fdt = map_sysmem(new_fdt_addr, fdt_size);
> + new_fdt = (void *)(uintptr_t)new_fdt_addr;
>   memcpy(new_fdt, fdt, fdt_totalsize(fdt));
>   fdt_set_totalsize(new_fdt, fdt_size);
>  
> @@ -278,6 +281,9 @@ static void efi_carve_out_dt_rsv(void *fdt)
>   if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
>   continue;
>  
> + /* Convert from sandbox address space. */
> + addr = (uintptr_t)map_sysmem(addr, 0);

The comment needs to be more explanatory here. You should mention that
reservations in the DT are within sandbox virtual address space
("addresses") and thus we need to convert them to our efi linear map
(pointer based).

> +
>   /*
>* Do not carve out the device tree. It is already marked as
>* EFI_RUNTIME_SERVICES_DATA
> @@ -297,9 +303,8 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>  {
>   bootm_headers_t img = { 0 };
>   efi_status_t ret;
> - void *fdt;
> + void *fdt = (void *)fdt_addr;

Please change the parameter type throughout the call stack to void *
instead. That way we should get rid of most casts I hope.


Alex

>  
> - fdt = map_sysmem(fdt_addr, 0);
>   if (fdt_check_header(fdt)) {
>   printf("ERROR: invalid device tree\n");
>   return EFI_INVALID_PARAMETER;
> @@ -309,9 +314,8 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>   ret = copy_fdt(&fdt_addr);
>   if (ret)
>   return ret;
> + fdt = (void *)fdt_addr;
>  
> - unmap_sysmem(fdt);
> - fdt = map_sysmem(fdt_addr, 0);
>   if (image_setup_libfdt(&img, fdt, 0, NULL)) {
>   printf("ERROR: failed to process device tree\n");
>   return EFI_LOAD_ERROR;
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/9] efi_loader: macro efi_size_in_pages()

[Alexander Graf]

On 12.11.18 18:55, Heinrich Schuchardt wrote:
> When allocating EFI memory pages the size in bytes has to be converted to
> pages.
> 
> Provide a macro efi_size_in_pages() for this conversion.
> Use it in the EFI subsystem and correct related comments.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   no change
> ---
>  cmd/bootefi.c   | 15 ++-
>  include/efi_loader.h| 11 ++-
>  lib/efi_loader/efi_memory.c |  6 +++---
>  3 files changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index c73e6228d3e..2c9b2eb8b6f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -154,7 +154,7 @@ static void set_load_options(struct efi_loaded_image 
> *loaded_image_info,
>   * copy_fdt() - Copy the device tree to a new location available to EFI
>   *
>   * The FDT is relocated into a suitable location within the EFI memory map.
> - * An additional 12KB is added to the space in case the device tree needs to 
> be
> + * Additional 12 KiB are added to the space in case the device tree needs to 
> be
>   * expanded later with fdt_open_into().
>   *
>   * @fdt_addr:On entry, address of start of FDT. On exit, address of 
> relocated
> @@ -182,14 +182,12 @@ static efi_status_t copy_fdt(ulong *fdt_addrp)
>   }
>  
>   /*
> -  * Give us at least 4KB of breathing room in case the device tree needs
> -  * to be expanded later. Round up to the nearest EFI page boundary.
> +  * Give us at least 12 KiB of breathing room in case the device tree
> +  * needs to be expanded later.
>*/
>   fdt = map_sysmem(*fdt_addrp, 0);
> - fdt_size = fdt_totalsize(fdt);
> - fdt_size += 4096 * 3;
> - fdt_size = ALIGN(fdt_size + EFI_PAGE_SIZE - 1, EFI_PAGE_SIZE);
> - fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
> + fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
> + fdt_size = fdt_pages << EFI_PAGE_SHIFT;
>  
>   /* Safe fdt location is at 127MB */
>   new_fdt_addr = fdt_ram_start + (127 * 1024 * 1024) + fdt_size;
> @@ -287,8 +285,7 @@ static void efi_carve_out_dt_rsv(void *fdt)
>   if (addr == (uintptr_t)fdt)
>   continue;
>  
> - pages = ALIGN(size + (addr & EFI_PAGE_MASK), EFI_PAGE_SIZE) >>
> - EFI_PAGE_SHIFT;
> + pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
>   addr &= ~EFI_PAGE_MASK;
>   if (!efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
>   false))
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index bdb806cfce4..244e754e8fd 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -350,7 +350,16 @@ struct efi_simple_file_system_protocol 
> *efi_simple_file_system(
>  /* open file from device-path: */
>  struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp);
>  
> -
> +/**
> + * efi_size_in_pages() - convert size in bytes to size in pages
> + *
> + * This macro returns the number of EFI memory pages required to hold 'size'
> + * bytes.
> + *
> + * @size:size in bytes
> + * Return:   size in pages
> + */
> +#define efi_size_in_pages(size) ((size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT)

Please make this a static inline function instead so we preserve type
checks.


Alex

>  /* Generic EFI memory allocator, call this to get memory */
>  void *efi_alloc(uint64_t len, int memory_type);
>  /* More specific EFI memory allocator, called by EFI payloads */
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 490e4921cce..5c387fa8024 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -400,7 +400,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
>  void *efi_alloc(uint64_t len, int memory_type)
>  {
>   uint64_t ret = 0;
> - uint64_t pages = (len + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
> + uint64_t pages = efi_size_in_pages(len);
>   efi_status_t r;
>  
>   r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, memory_type, pages,
> @@ -444,8 +444,8 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t 
> size, void **buffer)
>  {
>   efi_status_t r;
>   struct efi_pool_allocation *alloc;
> - u64 num_pages = (size + sizeof(struct efi_pool_allocation) +
> -  EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
> + u64 num_pages = efi_size_in_pages(size +
> +   sizeof(struct efi_pool_allocation));
>  
>   if (!buffer)
>   return EFI_INVALID_PARAMETER;
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities

[Simon Goldschmidt]

On 06.11.2018 15:51, Andrea Barisani wrote:

[..]
The issue can be exploited by several means:

   - An excessively large crafted boot image file is parsed by the
 `tftp_handler` function which lacks any size checks, allowing the memory
 overwrite.

   - A malicious server can manipulate TFTP packet sequence numbers to store
 downloaded file chunks at arbitrary memory locations, given that the
 sequence number is directly used by the `tftp_handler` function to 
calculate
 the destination address for downloaded file chunks.

 Additionally the `store_block` function, used to store downloaded file
 chunks in memory, when invoked by `tftp_handler` with a `tftp_cur_block`
 value of 0, triggers an unchecked integer underflow.

 This allows to potentially erase memory located before the `loadAddr` when
 a packet is sent with a null, following at least one valid packet.


Do you happen to have more details on this suggested integer underflow? 
I have tried to reproduce it, but I failed to get a memory write address 
before 'load_addr'. This is because the 'store_block' function does not 
directly use the underflowed integer as a block counter, but adds 
'tcp_block_wrap_offset' to this offset.


To me it seems like alternating between '0' and 'not 0' for the block 
counter could increase memory overwrites, but I fail to see how you can 
use this to store chunks at arbitrary memory locations. All you can do 
is subtract one block size from 'tftp_block_wrap_offset'...


Simon

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

Re: [U-Boot] [PATCH v2 2/9] efi_loader: fix efi_find_free_memory()

[Alexander Graf]

On 12.11.18 18:55, Heinrich Schuchardt wrote:
> In efi_find_free_memory() the sandbox uses its virtual address space.
> Add the missing mapping.
> 
> Signed-off-by: Heinrich Schuchardt 

The real bug here is much worse. According to 2.3.4 "x64 Platforms" of
the UEFI spec:

===
Paging mode is enabled and any memory space defined by the UEFI memory
map is identity mapped (virtual address equals physical address),
although the attributes of certain regions may not have all read, write,
and execute attributes or be unmarked for purposes of platform
protection. The mappings to other regions are undefined and may vary
from implementation to implementation.
===

This means we can't have virtual != physical. We need to go with all
physical (pointers) instead. Anything else violates the spec.


Alex

> ---
> v2:
>   no change
> ---
>  lib/efi_loader/efi_memory.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index dc282fe249f..c0277355056 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -294,6 +294,9 @@ static uint64_t efi_find_free_memory(uint64_t len, 
> uint64_t max_addr)
>  {
>   struct list_head *lhandle;
>  
> + /* Map to virtual address on sandbox */
> + max_addr = map_to_sysmem((void *)(uintptr_t)max_addr);
> +
>   /*
>* Prealign input max address, so we simplify our matching
>* logic below and can just reuse it as return pointer.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/9] fdt_support: fdt reservations on the sandbox

[Alexander Graf]

On 12.11.18 18:55, Heinrich Schuchardt wrote:
> On the sandbox the memory addresses in the device tree refer to the virtual
> address space of the sandbox. This implies that the memory reservations for
> the fdt also have to be converted to this address space.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   no change
> ---
>  common/fdt_support.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index e6daa67990d..ec6af92dbba 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -7,6 +7,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
> initrd_end)
>   }
>   }
>  
> - err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
> + err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt),

This sounds like an API bug to me. Either fdt_add_mem_rsv() takes an
address (ulong) or a pointer (void*). But taking void * while expecting
an address to get passed in sounds pretty broken to me.

Simon?


Alex

> +   initrd_start, initrd_end - initrd_start);
>   if (err < 0) {
>   printf("fdt_initrd: %s\n", fdt_strerror(err));
>   return err;
> @@ -633,7 +635,8 @@ int fdt_shrink_to_minimum(void *blob, uint extrasize)
>   fdt_set_totalsize(blob, actualsize);
>  
>   /* Add the new reservation */
> - ret = fdt_add_mem_rsv(blob, (uintptr_t)blob, actualsize);
> + ret = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(blob),
> +   (uintptr_t)blob, actualsize);
>   if (ret < 0)
>   return ret;
>  
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v12 5/6] efi: Create a function to set up for running EFI code

[Alexander Graf]

On 06.11.18 23:57, Simon Glass wrote:
> There is still duplicated code in efi_loader for tests and normal
> operation.
> 
> Add a new bootefi_run_prepare() function which holds common code used to
> set up U-Boot to run EFI code. Make use of this from the existing
> bootefi_test_prepare() function, as well as do_bootefi_exec().
> 
> Also shorten a few variable names.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v12: None
> Changes in v11: None
> Changes in v9: None
> Changes in v7: None
> Changes in v5:
> - Drop call to efi_init_obj_list() which is now done in do_bootefi()
> - Introduce load_options_path to specifyc U-Boot env var for load_options_path
> 
> Changes in v4:
> - Rebase to master
> 
> Changes in v3:
> - Add patch to create a function to set up for running EFI code
> 
>  cmd/bootefi.c | 85 +--
>  1 file changed, 48 insertions(+), 37 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 0dd18d594d5..779c1f63fa8 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -327,6 +327,30 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
>   return ret;
>  }
>  
> +static efi_status_t bootefi_run_prepare(const char *load_options_path,
> + struct efi_device_path *device_path,
> + struct efi_device_path *image_path,
> + struct efi_loaded_image **imagep,
> + struct efi_loaded_image_obj **objp)
> +{
> + efi_status_t ret;
> +
> + ret = efi_setup_loaded_image(device_path, image_path, objp, imagep);
> + if (ret != EFI_SUCCESS)
> + return ret;
> +
> + /*
> +  * gd lives in a fixed register which may get clobbered while we execute
> +  * the payload. So save it here and restore it on every callback entry
> +  */
> + efi_save_gd();
> +
> + /* Transfer environment variable as load options */
> + set_load_options(*imagep, load_options_path);
> +
> + return 0;
> +}
> +
>  /**
>   * do_bootefi_exec() - execute EFI binary
>   *
> @@ -345,8 +369,8 @@ static efi_status_t do_bootefi_exec(void *efi,
>   efi_handle_t mem_handle = NULL;
>   struct efi_device_path *memdp = NULL;
>   efi_status_t ret;
> - struct efi_loaded_image_obj *image_handle = NULL;

This is called image handle in the UEFI spec, so I'd prefer we keep that
name.

> - struct efi_loaded_image *loaded_image_info = NULL;

Same here.

Also, as a general rule of thumb, it's not good practice to do renames
(something you could for example reproduce with sed or coccinelle) in
the same patch as something else - code movement in your case. It makes
review pretty hard and makes life harder on you to rebase the patch.

In a nutshell: I like the code movement into a function, that's a nice
cleanup. I don't like the variable renames :). They make it confusing
for people that want to know what these variables mean in context of an
executed application.


Alex

> + struct efi_loaded_image_obj *obj = NULL;
> + struct efi_loaded_image *image = NULL;
>  
>   EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
>struct efi_system_table *st);
> @@ -376,15 +400,13 @@ static efi_status_t do_bootefi_exec(void *efi,
>   assert(device_path && image_path);
>   }
>  
> - ret = efi_setup_loaded_image(device_path, image_path, &image_handle,
> -  &loaded_image_info);
> - if (ret != EFI_SUCCESS)
> - goto exit;
> + ret = bootefi_run_prepare("bootargs", device_path, image_path,
> +   &image, &obj);
> + if (ret)
> + return ret;
>  
> - /* Transfer environment variable bootargs as load options */
> - set_load_options(loaded_image_info, "bootargs");
>   /* Load the EFI payload */
> - entry = efi_load_pe(image_handle, efi, loaded_image_info);
> + entry = efi_load_pe(obj, efi, image);
>   if (!entry) {
>   ret = EFI_LOAD_ERROR;
>   goto exit;
> @@ -392,10 +414,9 @@ static efi_status_t do_bootefi_exec(void *efi,
>  
>   if (memdp) {
>   struct efi_device_path_memory *mdp = (void *)memdp;
> - mdp->memory_type = loaded_image_info->image_code_type;
> - mdp->start_address = (uintptr_t)loaded_image_info->image_base;
> - mdp->end_address = mdp->start_address +
> - loaded_image_info->image_size;
> + mdp->memory_type = image->image_code_type;
> + mdp->start_address = (uintptr_t)image->image_base;
> + mdp->end_address = mdp->start_address + image->image_size;
>   }
>  
>   /* we don't support much: */
> @@ -405,8 +426,8 @@ static efi_status_t do_bootefi_exec(void *efi,
>   /* Call our payload! */
>   debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry

Re: [U-Boot] UBoot running UBoot - is it possible?

[Simon Goldschmidt]

On 13.11.2018 20:53, Simon Glass wrote:

Hi Allan,

On 12 November 2018 at 18:38, Allan Chandler  wrote:

Hello, bods.

We're trying to architect a relatively safe solution for updating UBoot in the 
field. What we have at the moment is an iMX6-based board with two UBoot 
partitions and two system partitions but we only use the first UBoot one. 
Switching system partitions is covered well by UBoot since we use what seems 
like a fairly standard method involving upgrade_available, bootlimit and 
bootcount variables, along with bootcmd/altbootcmd scripts to try and load a 
new system partition while falling back if it fails.

However, I'm wondering how people handle the need to update UBoot itself. 
Although this will happen FAR less often than normal software updates, these 
product have a multi-decade lifespan and it's hard to imagine we'll get through 
that without some update being needed. Especially since we need one now (three 
years in) due to a bug (with our added stuff, not UBoot baseline). With the 
iMX6 boards we have, once we tell it to start using the second UBoot partition, 
there's no UBoot/watchdog combo that will revert that change and reprogramming 
requires a rather expensive RTB (return to base) to fix via the serial 
interface.

What we had hoped to do was to be able to soft-boot an alternate UBoot (i.e., 
without first telling the iMX6 board to commit to the change). The scenario 
would go like this:

1/ Have an installer package (it runs under control of the system partition) 
that just writes the new UBoot image into the alternate UBoot partition then 
soft-boots it somehow (so now running same system partition but started from 
the new UBoot image).

2/ While running from the system partition started from that alternate UBoot 
partition, have an updater package that tells the iMX6 board to commit to the 
changeover. This updater package would only run if it detected that the 
bootable UBoot and currently-used UBoot were different.

The advantage of this is that, unless the new UBoot is FULLY capable of running 
our system partition (and also running an installer from there), no commit is 
possible, hence a simple power cycle would return to the previous working state.

We originally tried kexec from the system partition but it seemed to want to 
run a Linux kernel rather than loading and executing some arbitrary boot code.

So we then turned to the UBoot scripts themselves and thought we'd found a way 
we could do it.

1/ We changed the mmcboot script by prefixing a special check and introduced a 
variable for handling soft-boot:
 mmcboot=run check_uboot; 
 other_uboot=0

2/ We extracted the boot image uboot.bootimg from the IMX file by stripping off 
the first 0xc00 bytes (we had to put this into the /boot file system since I 
don't yet know how to get at raw partition data from UBoot scripts.

3/ We defined check_uboot as:
 if test ${other_uboot} -eq 1; then
 setenv other_uboot 0
 saveenv
 ext4load mmc ${mmcdev}:${mmcpart} 0x1780 
/boot/uboot.bootimg
 go 0x1780
 fi
The way this should work is that, if alternate boot is flagged, it immediately 
unflags it (for recovery if the alternate fails) then loads and executes the 
other UBoot image. If it's not flagged, check_uboot will return without trying 
to soft-boot the alternate.

4/ After installing the new UBoot to the alternate partition, we set a UBoot 
variable (other_uboot) to 1 and rebooted.

Now this seemed to work inasmuch as the alternate UBoot program started pumping 
out console messages but, unfortunately, it seemed to hang partway through the 
boot process.

I suspect this is because, having already been through a portion of that boot 
process in the primary UBoot, it's not keen on having to do it again.

You may need to flush the cache area that you read into, or use
'dcache off' before jumping to the second U-Boot.


So I guess my questions are as follows:

a/ How do people currently handle (if they do) the requirement that UBoot be 
safely updatable in the field?
b/ Does anyone have any ideas on how I could achieve this?

I've been told that Google does something like this for Android booting but had 
to heavily modify UBoot to do it. I haven't yet investigated this possibility.

Chromium OS and Android verified boot (which is in mainline - see avb)
use an A/B system. You can have SPL chosen whether to boot from A or
B.

I'm actually working on integrating Chromium OS vboot into U-Boot
again. It uses TPL to select the SPL to use, which then boots into
UBoot proper. This is so we can update the SDRAM code. Am hoping to
have something going in January although a lot of the required patches
have been sent.


That sounds interesting, but would it be safe to use TPL from 2019 and 
letting it boot a, say, 2025 SPL + U-Boot? I don't have experience with 
TPL, can it check sig

Re: [U-Boot] [PATCH v12 4/6] efi: Split out test init/uninit into functions

[Alexander Graf]

On 06.11.18 23:57, Simon Glass wrote:
> The functions in bootefi are very long because they mix high-level code
> and control with the low-level implementation. To help with this, create
> functions which handle preparing for running the test and cleaning up
> afterwards.
> 
> Also shorten the awfully long variable names here.
> 
> Signed-off-by: Simon Glass 

This touches selftest, so I'd like to see at least an ack from Heinrich.

I personally would just extract all of the if (selftest) part into a
function and then run your later cleanup over it. The end result should
still be quite readable.


Alex

> ---
> 
> Changes in v12:
> - Rename image to image_prot
> 
> Changes in v11: None
> Changes in v9:
> - Add comments to bootefi_test_prepare() about the memset()s
> 
> Changes in v7: None
> Changes in v5:
> - Drop call to efi_init_obj_list() which is now done in do_bootefi()
> 
> Changes in v4: None
> Changes in v3:
> - Add new patch to split out test init/uninit into functions
> 
>  cmd/bootefi.c | 85 +++
>  1 file changed, 65 insertions(+), 20 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 4d68d807480..0dd18d594d5 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -455,6 +455,64 @@ exit:
>   return ret;
>  }
>  
> +#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> +/**
> + * bootefi_test_prepare() - prepare to run an EFI test
> + *
> + * This sets things up so we can call EFI functions. This involves preparing
> + * the 'gd' pointer and setting up the load ed image data structures.
> + *
> + * @image: Pointer to a struct which will hold the loaded image info.
> + *This struct will be inited by this function before use.
> + * @obj: Pointer to a struct which will hold the loaded image object
> + *This struct will be inited by this function before use.
> + * @path: File path to the test being run (often just the test name with a
> + *backslash before it
> + * @test_func: Address of the test function that is being run
> + * @return 0 if OK, -ve on error
> + */
> +static efi_status_t bootefi_test_prepare(struct efi_loaded_image **imagep,
> +  struct efi_loaded_image_obj **objp,
> +  const char *path, ulong test_func)
> +{
> + efi_status_t r;
> +
> + /* Construct a dummy device path */
> + bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> +   (uintptr_t)test_func,
> +   (uintptr_t)test_func);
> + bootefi_image_path = efi_dp_from_file(NULL, 0, path);
> + r = efi_setup_loaded_image(bootefi_device_path, bootefi_image_path,
> +objp, imagep);
> + if (r)
> + return r;
> + /*
> +  * gd lives in a fixed register which may get clobbered while we execute
> +  * the payload. So save it here and restore it on every callback entry
> +  */
> + efi_save_gd();
> +
> + /* Transfer environment variable efi_selftest as load options */
> + set_load_options(*imagep, "efi_selftest");
> +
> + return 0;
> +}
> +
> +/**
> + * bootefi_test_finish() - finish up after running an EFI test
> + *
> + * @image: Pointer to a struct which holds the loaded image info
> + * @obj: Pointer to a struct which holds the loaded image object
> + */
> +static void bootefi_test_finish(struct efi_loaded_image *image,
> + struct efi_loaded_image_obj *obj)
> +{
> + efi_restore_gd();
> + free(image->load_options);
> + efi_delete_handle(&obj->parent);
> +}
> +#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> +
>  static int do_bootefi_bootmgr_exec(void)
>  {
>   struct efi_device_path *device_path, *file_path;
> @@ -527,29 +585,16 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>  #endif
>  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
>   if (!strcmp(argv[1], "selftest")) {
> - struct efi_loaded_image_obj *image_handle;
> - struct efi_loaded_image *loaded_image_info;
> -
> - /* Construct a dummy device path. */
> - bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> -   (uintptr_t)&efi_selftest,
> -   (uintptr_t)&efi_selftest);
> - bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
> -
> - r = efi_setup_loaded_image(bootefi_device_path,
> -bootefi_image_path, &image_handle,
> -&loaded_image_info);
> - if (r != EFI_SUCCESS)
> + struct efi_loaded_image_obj *obj;
> + struct efi_loaded_image *image_prot;
> +
> + if (bootefi_test_prepare(&image_prot, &obj, "\\selftest",
> +  (uintptr_t)&efi_selftest))
> 

Re: [U-Boot] [PATCH v12 3/6] sandbox: smbios: Update to support sandbox

[Alexander Graf]

On 06.11.18 23:57, Simon Glass wrote:
> At present this code casts addresses to pointers so cannot be used with
> sandbox. Update it to use mapmem instead.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v12: None
> Changes in v11:
> - Fix the EFI code that has since been added and relies on broken behaviour
> 
> Changes in v9: None
> Changes in v7: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Drop incorrect map_sysmem() in write_smbios_table()
> 
>  lib/efi_loader/efi_smbios.c | 20 +---
>  lib/smbios.c| 32 
>  2 files changed, 37 insertions(+), 15 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
> index 38e42fa2432..a81488495e2 100644
> --- a/lib/efi_loader/efi_smbios.c
> +++ b/lib/efi_loader/efi_smbios.c
> @@ -7,6 +7,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
> @@ -19,17 +20,19 @@ static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
>  efi_status_t efi_smbios_register(void)
>  {
>   /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
> - u64 dmi = U32_MAX;
> + u64 dmi_addr = U32_MAX;
>   efi_status_t ret;
> + void *dmi;
>  
>   /* Reserve 4kiB page for SMBIOS */
>   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> -  EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
> +  EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr);
>  
>   if (ret != EFI_SUCCESS) {
>   /* Could not find space in lowmem, use highmem instead */
>   ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
> -  EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
> +  EFI_RUNTIME_SERVICES_DATA, 1,
> +  &dmi_addr);
>  
>   if (ret != EFI_SUCCESS)
>   return ret;
> @@ -39,11 +42,14 @@ efi_status_t efi_smbios_register(void)
>* Generate SMBIOS tables - we know that efi_allocate_pages() returns
>* a 4k-aligned address, so it is safe to assume that
>* write_smbios_table() will write the table at that address.
> +  *
> +  * Note that on sandbox, efi_allocate_pages() unfortunately returns a
> +  * pointer even though it uses a uint64_t type. Convert it.
>*/
> - assert(!(dmi & 0xf));
> - write_smbios_table(dmi);
> + assert(!(dmi_addr & 0xf));
> + dmi = (void *)(uintptr_t)dmi_addr;
> + write_smbios_table(map_to_sysmem(dmi));
>  
>   /* And expose them to our EFI payload */
> - return efi_install_configuration_table(&smbios_guid,
> -(void *)(uintptr_t)dmi);
> + return efi_install_configuration_table(&smbios_guid, dmi);
>  }
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 326eb00230d..87109d431a2 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start)
>  
>  static int smbios_write_type0(ulong *current, int handle)
>  {
> - struct smbios_type0 *t = (struct smbios_type0 *)*current;
> + struct smbios_type0 *t;
>   int len = sizeof(struct smbios_type0);
>  
> + t = map_sysmem(*current, len);
>   memset(t, 0, sizeof(struct smbios_type0));
>   fill_smbios_header(t, SMBIOS_BIOS_INFORMATION, len, handle);
>   t->vendor = smbios_add_string(t->eos, "U-Boot");
> @@ -101,16 +103,18 @@ static int smbios_write_type0(ulong *current, int 
> handle)
>  
>   len = t->length + smbios_string_table_len(t->eos);
>   *current += len;
> + unmap_sysmem(t);
>  
>   return len;
>  }
>  
>  static int smbios_write_type1(ulong *current, int handle)
>  {
> - struct smbios_type1 *t = (struct smbios_type1 *)*current;
> + struct smbios_type1 *t;
>   int len = sizeof(struct smbios_type1);
>   char *serial_str = env_get("serial#");
>  
> + t = map_sysmem(*current, len);
>   memset(t, 0, sizeof(struct smbios_type1));
>   fill_smbios_header(t, SMBIOS_SYSTEM_INFORMATION, len, handle);
>   t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
> @@ -122,15 +126,17 @@ static int smbios_write_type1(ulong *current, int 
> handle)
>  
>   len = t->length + smbios_string_table_len(t->eos);
>   *current += len;
> + unmap_sysmem(t);
>  
>   return len;
>  }
>  
>  static int smbios_write_type2(ulong *current, int handle)
>  {
> - struct smbios_type2 *t = (struct smbios_type2 *)*current;
> + struct smbios_type2 *t;
>   int len = sizeof(struct smbios_type2);
>  
> + t = map_sysmem(*current, len);
>   memset(t, 0, sizeof(struct smbios_type2));
>   fill_smbios_header(t, SMBIOS_BOARD_INFORMATION, len, handle);
>   t->manufacturer = smbios_add_stri

Re: [U-Boot] [PATCH 1/1] efi_loader: eliminate sandbox addresses

[Alexander Graf]

On 13.11.18 20:53, Simon Glass wrote:
> Hi Heinrich,
> 
> On 10 November 2018 at 14:30, Heinrich Schuchardt  wrote:
>> Do not use the sandbox's virtual address space for the internal structures
>> of the memory map. This way we can eliminate a whole lot of unnecessary
>> conversions.
>>
>> The only conversion remaining is the one when adding known memory.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  lib/efi_loader/efi_memory.c | 17 -
>>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> I much prefer this, but Alex was not too keen.

Uh, I thought you were the one who wanted to only expose fake addresses?
I think the patch is great as is :). It definitely simplifies the code.

> Also please can you add detailed comments to efi_mem_desc about what
> the addresses are for sandbox?

I'll wait for v2 then.


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

Re: [U-Boot] [PATCH v12 2/6] efi_loader: Drop setup_ok

[Alexander Graf]

On 06.11.18 23:57, Simon Glass wrote:
> This value is stored in data which appears to be read-only with sandbox on
> my Ubuntu 18.04 machine. In any case it is not good practice to store
> run-time data in a build-time linker list.
> 
> The value does not seem to be that useful, since tests that fail to setup
> are likely to fail to run also. Let's drop it for now.
> 
> Signed-off-by: Simon Glass 

I think I already have this as "efi_selftest: do not write to linker
generated array" in my queue?


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

Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

[Simon Goldschmidt]

On 13.11.2018 20:42, Heinrich Schuchardt wrote:

On 11/13/18 6:47 AM, Simon Goldschmidt wrote:

On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam  wrote:

Hi Simon,

On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
 wrote:


diff --git a/fs/fs.c b/fs/fs.c
index adae98d021..4baf6b1c39 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
 return ret;
  }

-int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
-   loff_t *actread)
+#ifdef CONFIG_LMB

Unrelated to your series, but I was wondering if we could get rid of
the CONFIG_LMB option.

As far as I can see all the architectures define it, the only
exception being arch/sh.

If you agree I can send a patch after your series gets applied that
removes CONFIG_LMB.

Sure, that would clean things up.

Simon


NAK

This patch-series does not provide what is needed. With
odroid-c2_defconfig I get

fdt list /reserved-memory/secmon@1000
reserved-memory {
 secmon@1000 {
 reg = <0x 0x1000 0x 0x0020>;
 no-map;
 };
};

=> load mmc 0:1 0x1000 dtb
22925 bytes read in 8 ms (2.7 MiB/s)

So now I have successfully overwritten the secure monitor. Urrgh.

As you have observed load is still writing into a memory area that is
reserved by the device-tree.

Please, iterate over the device tree to ensure that nothing is loaded
into a reserved memory area. Do not expect board files to do anything
but create the reserve-memory entry in the device tree.


First of all, thanks for testing. I must admit I haven't tested this 
case, I just had the impression the existing function 
'boot_fdt_add_mem_rsv_regions()' (in image-fdt.c) would do that. I'll 
have to dig into why it doesn't.


Or do you have CONFIG_OF_LIBFDT disabled?

In any case, it *was* my intention to include the dts memory 
reservation! I'll make sure I test that for a v2.


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

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

[Vagrant Cascadian]

On 2018-09-13, Marty E. Plummer wrote:
> This adds support for the ASUS C201, a RK3288-based clamshell
> device. The device tree comes from linus's linux tree at
> 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters
> are for 4GB Samsung LPDDR3, decoded from coreboot's
> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc

Any outstanding blockers on getting this patch series merged?

live well,
  vagrant

> Signed-off-by: Marty E. Plummer 
> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi |  31 
>  arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++
>  arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig |  11 ++
>  board/google/veyron/Kconfig   |  16 ++
>  configs/chromebook_speedy_defconfig   |  98 
>  7 files changed, 302 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
>  create mode 100644 configs/chromebook_speedy_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 44ebc50bfa..eab90216f0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -40,6 +40,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-veyron-jerry.dtb \
>   rk3288-veyron-mickey.dtb \
>   rk3288-veyron-minnie.dtb \
> + rk3288-veyron-speedy.dtb \
>   rk3288-vyasa.dtb \
>   rk3328-evb.dtb \
>   rk3368-lion.dtb \
> diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi 
> b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> new file mode 100644
> index 00..22ba3490f2
> --- /dev/null
> +++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2015 Google, Inc
> + */
> +
> +&dmc {
> + rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
> + 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
> + 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
> + 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
> + 0x8 0x1f4>;
> + rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
> + 0x0 0xc3 0x6 0x1>;
> + rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
> +};
> +
> +&sdmmc {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&emmc {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart2 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&pinctrl {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts 
> b/arch/arm/dts/rk3288-veyron-speedy.dts
> new file mode 100644
> index 00..20100bbdee
> --- /dev/null
> +++ b/arch/arm/dts/rk3288-veyron-speedy.dts
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Veyron Speedy Rev 1+ board device tree source
> + *
> + * Copyright 2015 Google, Inc
> + */
> +
> +/dts-v1/;
> +#include "rk3288-veyron-chromebook.dtsi"
> +#include "cros-ec-sbs.dtsi"
> +#include "rk3288-veyron-speedy-u-boot.dtsi"
> +
> +/ {
> + model = "Google Speedy";
> + compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
> +  "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> +
> + panel_regulator: panel-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_enable_h>;
> + regulator-name = "panel_regulator";
> + startup-delay-us = <10>;
> + vin-supply = <&vcc33_sys>;
> + };
> +
> + vcc18_lcd: vcc18-lcd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&avdd_1v8_disp_en>;
> + regulator-name = "vcc18_lcd";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc18_wl>;
> + };
> +
> + backlight_regulator: backlight-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bl_pwr_en>;
> + regulator-name = "backlight_regulator";
> + vin-supply = <&vcc33_sys>;
> + startup-delay-us = <15000>;
> + };
> +};
> +
> +&backlight {
> + power-supply = <&backlight_regulator>;
> +};
> +
> +&cpu_alert0 {
> + temperature = <65000>;
> +};
> +
> +&cpu_ale

Re: [U-Boot] [PATCH v7 2/5] dma: add channels support

[Simon Glass]

On 10 November 2018 at 13:06, Grygorii Strashko
 wrote:
> From: Álvaro Fernández Rojas 
>
> This adds channels support for dma controllers that have multiple channels
> which can transfer data to/from different devices (enet, usb...).
>
> DMA channle API:
>  dma_get_by_index()
>  dma_get_by_name()
>  dma_request()
>  dma_free()
>  dma_enable()
>  dma_disable()
>  dma_prepare_rcv_buf()
>  dma_receive()
>  dma_send()
>
> Reviewed-by: Tom Rini 
> Signed-off-by: Álvaro Fernández Rojas 
> [grygorii.stras...@ti.com: drop unused dma_get_by_index_platdata(),
>  add metadata to send/receive ops, add dma_prepare_rcv_buf(),
>  minor clean up]
> Signed-off-by: Grygorii Strashko 
> ---
>  drivers/dma/Kconfig  |   7 ++
>  drivers/dma/dma-uclass.c | 181 -
>  include/dma-uclass.h |  91 -
>  include/dma.h| 260 
> ++-
>  4 files changed, 532 insertions(+), 7 deletions(-)

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

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

[Jagan Teki]

On Wed 14 Nov, 2018, 1:12 AM Tom Rini  On Wed, Nov 14, 2018 at 12:49:45AM +0530, Jagan Teki wrote:
>
> > Hi Tom,
> >
> > Please pull this PR.
> >
> > thanks,
> > Jagan.
> >
> > The following changes since commit
> 454cf76184c65426b68033a23da086e73663f2fc:
> >
> >   Prepare v2018.11-rc3 (2018-10-29 16:04:26 -0400)
> >
> > are available in the Git repository at:
> >
> >   git://git.denx.de/u-boot-sunxi.git master
> >
> > for you to fetch changes up to 7d121a8ea4e0dbf0d7e105b57c3dbd7d8bd2e729:
> >
> >   sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD
> (2018-11-13 22:17:06 +0530)
> >
> > 
> > Andre Przywara (4):
> >   sunxi: A64: Update .dts/.dtsi files
> >   sunxi: A64: Re-add syscon to DT node
> >   sunxi: H3/H5: Update .dts files
> >   sunxi: A64: Add Pine64-LTS board
> >
> > Icenowy Zheng (1):
> >   sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD
> >
> > Jagan Teki (2):
> >   arm64: allwinner: h6: Add common orangepi nodes into dtsi
> >   board: allwinner: sun50i-h6: Add Orangepi Lite2 support
> >
> > Jun Nie (1):
> >   sunxi: add support for Banana Pi M2 Zero board
> >
> > Marek Vasut (1):
> >   sunxi: Imply fitImage support
> >
> > Vasily Khoruzhick (4):
> >   mmc: sunxi: add support for automatic delay calibration
> >   dm: video: bridge: don't fail to activate bridge if reset or sleep
> GPIO is missing
> >   sun50i: A64: add support for R_I2C controller
> >   sunxi: DT: add support for Pinebook
> >
> >  arch/arm/Kconfig|   1 +
> >  arch/arm/dts/Makefile   |   3 +
> >  arch/arm/dts/sun50i-a64-amarula-relic.dts   | 168 -
> >  arch/arm/dts/sun50i-a64-bananapi-m64.dts|  34 ++-
> >  arch/arm/dts/sun50i-a64-nanopi-a64.dts  |  89 ++-
> >  arch/arm/dts/sun50i-a64-olinuxino.dts   | 103 +++-
> >  arch/arm/dts/sun50i-a64-orangepi-win.dts| 179 +-
> >  arch/arm/dts/sun50i-a64-pine64-lts.dts  |  13 +
> >  arch/arm/dts/sun50i-a64-pine64.dts  |  32 ++-
> >  arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi|  15 ++
> >  arch/arm/dts/sun50i-a64-pinebook.dts| 294
> ++
> >  arch/arm/dts/sun50i-a64-sopine-baseboard.dts|  32 ++-
> >  arch/arm/dts/sun50i-a64-sopine.dtsi |  15 ++
> >  arch/arm/dts/sun50i-a64.dtsi| 312
> ++--
> >  arch/arm/dts/sun50i-h5-orangepi-pc2.dts |  12 +
> >  arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts   |   2 -
> >  arch/arm/dts/sun50i-h6-orangepi-lite2.dts   |  11 +
> >  arch/arm/dts/sun50i-h6-orangepi-one-plus.dts| 140 +--
> >  arch/arm/dts/sun50i-h6-orangepi.dtsi| 150 
> >  arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 121 +
> >  arch/arm/dts/sun8i-h3.dtsi  |  31 +++
> >  arch/arm/dts/sunxi-h3-h5.dtsi   |   2 -
> >  arch/arm/include/asm/arch-sunxi/gpio.h  |   1 +
> >  arch/arm/include/asm/arch-sunxi/mmc.h   |   6 +-
> >  arch/arm/mach-sunxi/Kconfig |   1 +
> >  arch/arm/mach-sunxi/clock_sun6i.c   |   4 +
> >  board/sunxi/MAINTAINERS |  10 +
> >  board/sunxi/board.c |   6 +
> >  configs/bananapi_m2_zero_defconfig  |  13 +
> >  configs/orangepi_lite2_defconfig|  12 +
> >  configs/pine64-lts_defconfig|  19 ++
> >  configs/pinebook_defconfig  |  22 ++
> >  drivers/mmc/sunxi_mmc.c |  21 +-
> >  drivers/video/bridge/video-bridge-uclass.c  |  16 +-
> >  drivers/video/sunxi/lcdc.c  |  22 +-
> >  35 files changed, 1710 insertions(+), 202 deletions(-)
> >  create mode 100644 arch/arm/dts/sun50i-a64-pine64-lts.dts
> >  create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
> >  create mode 100644 arch/arm/dts/sun50i-h6-orangepi-lite2.dts
> >  create mode 100644 arch/arm/dts/sun50i-h6-orangepi.dtsi
> >  create mode 100644 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> >  create mode 100644 configs/bananapi_m2_zero_defconfig
> >  create mode 100644 configs/orangepi_lite2_defconfig
> >  create mode 100644 configs/pine64-lts_defconfig
> >  create mode 100644 configs/pinebook_defconfig
>
> This seems to be somewhat the opposite of the SPI PR in that it's not
> just fixing up a few corner cases and so forth, so I assume you intend
> me to pull this after the release.
>

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

Re: [U-Boot] [PATCH 1/2] Revert "imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO"

[Simon Glass]

On 12 November 2018 at 19:32, Simon Glass  wrote:
> On 12 November 2018 at 08:02, Bin Meng  wrote:
>>
>> This reverts commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b.
>>
>> Disabling CONFIG_DISPLAY_CPUINFO was a temporary solution to get
>> the v2018.11 release out. Now the merge window opens, revert it.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  configs/imx8qxp_mek_defconfig | 1 -
>>  1 file changed, 1 deletion(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 3/5] test: dma: add dma-uclass test

[Simon Glass]

On 10 November 2018 at 13:06, Grygorii Strashko
 wrote:
> Add a sandbox DMA driver implementation (provider) and corresponding DM
> test.
>
> Reviewed-by: Tom Rini 
> Signed-off-by: Grygorii Strashko 
> ---
>  arch/sandbox/dts/test.dts  |   8 ++
>  configs/sandbox_defconfig  |   3 +
>  drivers/dma/Kconfig|   7 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/sandbox-dma-test.c | 282 
> +
>  test/dm/Makefile   |   1 +
>  test/dm/dma.c  | 123 ++
>  7 files changed, 425 insertions(+)
>  create mode 100644 drivers/dma/sandbox-dma-test.c
>  create mode 100644 test/dm/dma.c

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

Re: [U-Boot] [PATCH 02/19] dm: cpu: Add timebase frequency to the platdata

[Simon Glass]

On 13 November 2018 at 00:21, Bin Meng  wrote:
> This adds a timebase_freq member to the 'struct cpu_platdata', to
> hold the "timebase-frequency" value in the cpu or /cpus node.
>
> Signed-off-by: Bin Meng 
> ---
>
>  include/cpu.h | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass 

Could we have comments for the struct members?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fdt_region: Ensure that depth never goes below -1

[Simon Glass]

On 7 November 2018 at 11:51, Tom Rini  wrote:
> From: Konrad Beckmann 
>
> A specially crafted FIT image makes it possible to overflow the stack
> with controlled values when using the verified boot feature. Depending
> on the memory layout, this could be used to overwrite configuration
> variables on the heap and setting them to 0, e.g. disable signature
> verification, thus bypassing it.
>
> This change fixes a bug in fdt_find_regions where the fdt structure is
> parsed. A lower value than -1 of depth can lead to a buffer underflow
> write on the stack.
>
> Signed-off-by: Konrad Beckmann 
> ---
>  lib/libfdt/fdt_region.c | 3 +++
>  1 file changed, 3 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] SPL: Add HAB image authentication to FIT

[Simon Glass]

Hi Peng,

On 9 November 2018 at 01:14, Peng Fan  wrote:
> From: Ye Li 
>
> Introduce two board level callback functions to FIT image loading process, and
> a SPL_FIT_FOUND flag to differentiate FIT image or RAW image.
>
> Implement functions in imx common SPL codes to call HAB function
> to authenticate the FIT image. Generally, we have to sign multiple regions
> in FIT image:
> 1. Sign FIT FDT data (configuration)
> 2. Sign FIT external data (Sub-images)
>
> Because the CSF supports to sign multiple memory blocks, so that we can use 
> one
> signature to cover all regions in FIT image and only authenticate once.
> The authentication should be done after the entire FIT image is loaded into
> memory including all sub-images.
> We use "-p" option to generate FIT image to reserve a space for FIT IVT
> and FIT CSF, also this help to fix the offset of the external data 
> (u-boot-nodtb.bin,
> ATF, u-boot DTB).
>
> The signed FIT image layout is as below:
> --
> | | | |   |   | ||
> | FIT | FIT | FIT |   | U-BOOT| ATF | U-BOOT |
> | FDT | IVT | CSF |   | nodtb.bin | |   DTB  |
> | | | |   |   | ||
> --
>
> Signed-off-by: Ye Li 
> Reviewed-by: Peng Fan 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/spl.c | 44 ++--
>  common/spl/spl_fit.c| 21 +++--
>  include/spl.h   |  1 +
>  3 files changed, 58 insertions(+), 8 deletions(-)

Can you please add function prototypes to spl.h along with comments?

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

Re: [U-Boot] [PATCH 1/2] image-sig: Ensure that hashed-nodes is null-terminated

[Simon Glass]

On 7 November 2018 at 11:51, Tom Rini  wrote:
> From: Konrad Beckmann 
>
> A specially crafted FIT image leads to memory corruption in the stack
> when using the verified boot feature. The function fit_config_check_sig
> has a logic error that makes it possible to write past the end of the
> stack allocated array node_inc. This could potentially be used to bypass
> the signature check when using verified boot.
>
> This change ensures that the number of strings is correct when counted.
>
> Signed-off-by: Konrad Beckmann 
> ---
>  common/image-sig.c | 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 v3 14/18] serial: 16550: allow the driver to support MediaTek serial

[Simon Glass]

Hi Weijie,

On 5 November 2018 at 19:48, Weijie Gao  wrote:
> On Mon, 2018-11-05 at 16:37 +0800, Ryder Lee wrote:
>> On Mon, 2018-11-05 at 10:20 +0800, Ryder Lee wrote:
>> > On Sat, 2018-11-03 at 00:09 -0600, Simon Glass wrote:
>> > > Hi Ryder,
>> > >
>> > > On 2 November 2018 at 09:15, Ryder Lee  wrote:
>> > > > This patch adds an extra operation in ns16550.c to suuport MediaTek
>> > > > SoCs as we have a highspeed register which influences the calcualtion
>> > > > of the divisor.
>> > > >
>> > > > Note that we don't support the baudrate greater than 115200 currently.
>> > > >
>> > > > Signed-off-by: Ryder Lee 
>> > > > Tested-by: Matthias Brugger 
>> > > > Reviewed-by: Simon Glass 
>> > > > ---
>> > > >  drivers/serial/ns16550.c | 10 ++
>> > > >  1 file changed, 10 insertions(+)
>> > >
>> > > Actually it seems to me that we should have a compatible string for
>> > > this and deal with this at run-time?
>> > >
>> > > Is that easy to do here?
>> > >
>> >
>> > How about this:
>> >
>> > uart0: serial@11002000 {
>> > compatible = "ns16550a";
>> > 
>> > mediatek,highspeed = <0>;
>> > 
>> >
>> > Ryder
>> >
>>
>> Sorry, I didn't get it right. I will add a compatible string in
>> ns16550_serial_ids[] for MTK chips.
>>
>> Ryder
>>
>>
>
> Hi Simon,
>
> We have tried the compatible string, but it made the ns16550 driver more
> complicated.
>
> To use the compatible string we have to add a new field in
> ns16550_platdata, and change the flow of ns16550_serial_probe.
> Moreover, it's totally useless for debug uart.
>
> At present using a macro is the easiest way here.

It might be easier but it is not correct. We should not have
platform-specific #ifdefs in a common driver.

Here's what I think you should do:

1. Create your own separate driver which calls into the code of this one
2. Add a 'quirks' flag word to the platform data and refactor the code
to deal with your quirk, or add a separate field like you say
3. For the debug uart, put it in your separate driver, if you cannot
easily change _debug_uart_init(). I suppose we could have a
CONFIG_DEBUG_UART_QUIRKS flag wod?

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

Re: [U-Boot] [PATCH 2/2] imx8: scu: Update call to lists_bind_fdt()

[Simon Glass]

On 12 November 2018 at 19:32, Simon Glass  wrote:
> On 12 November 2018 at 08:02, Bin Meng  wrote:
>> This commit should be squashed into
>>
>> commit 2bba642dbaa4 ("dm: core: Respect drivers with the
>> DM_FLAG_PRE_RELOC flag in lists_bind_fdt()")
>>
>> on u-boot-dm/master branch.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/misc/imx8/scu.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass '

Applied (merged in) to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/1] dm: video: correctly set the cursor position

[Simon Glass]

On 10 November 2018 at 10:55, Heinrich Schuchardt  wrote:
> The terminal escape sequence ESC [  ;  H is used to set the cursor
> position. According to the ECMA 48 standard the upper left corner in the
> escape sequences is [1, 1]. The video uclass uses [0, 0] as upper left
> corner.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v3:
> update unit test
> v2
> remove trailing whitespace
> ---
>  drivers/video/vidconsole-uclass.c | 8 
>  test/dm/video.c   | 4 ++--
>  2 files changed, 10 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v4 14/18] serial: 16550: allow the driver to support MediaTek serial

[Simon Glass]

Hi Ryder,

On 6 November 2018 at 01:47, Ryder Lee  wrote:
> This patch adds an extra operation in ns16550.c to suuport MediaTek
> SoCs as we have a highspeed register which influences the calcualtion
> of the divisor.
>
> Note that we don't support the baudrate greater than 115200 currently.
>
> Signed-off-by: Ryder Lee 
> Tested-by: Matthias Brugger 
> Reviewed-by: Simon Glass 
> ---
> Changes since v4: None
>
> @Simon
> We have tried the compatible string, but it made the ns16550 driver more 
> complicated.
> To use the compatible string we have to add a new field in ns16550_platdata, 
> and change
> the flow of ns16550_serial_probe().
>
> Moreover, it's totally useless for debug uart. At present using a macro is 
> the easiest way here.
>
> What do you think?
> ---
>  drivers/serial/ns16550.c | 10 ++
>  1 file changed, 10 insertions(+)

Please see my reply to the other thread. We should not have
arch-specific code in generic drivers.

Sorry for not replying earlier on that.

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

Re: [U-Boot] UBoot running UBoot - is it possible?

[Simon Glass]

Hi Allan,

On 12 November 2018 at 18:38, Allan Chandler  wrote:
> Hello, bods.
>
> We're trying to architect a relatively safe solution for updating UBoot in 
> the field. What we have at the moment is an iMX6-based board with two UBoot 
> partitions and two system partitions but we only use the first UBoot one. 
> Switching system partitions is covered well by UBoot since we use what seems 
> like a fairly standard method involving upgrade_available, bootlimit and 
> bootcount variables, along with bootcmd/altbootcmd scripts to try and load a 
> new system partition while falling back if it fails.
>
> However, I'm wondering how people handle the need to update UBoot itself. 
> Although this will happen FAR less often than normal software updates, these 
> product have a multi-decade lifespan and it's hard to imagine we'll get 
> through that without some update being needed. Especially since we need one 
> now (three years in) due to a bug (with our added stuff, not UBoot baseline). 
> With the iMX6 boards we have, once we tell it to start using the second UBoot 
> partition, there's no UBoot/watchdog combo that will revert that change and 
> reprogramming requires a rather expensive RTB (return to base) to fix via the 
> serial interface.
>
> What we had hoped to do was to be able to soft-boot an alternate UBoot (i.e., 
> without first telling the iMX6 board to commit to the change). The scenario 
> would go like this:
>
> 1/ Have an installer package (it runs under control of the system partition) 
> that just writes the new UBoot image into the alternate UBoot partition then 
> soft-boots it somehow (so now running same system partition but started from 
> the new UBoot image).
>
> 2/ While running from the system partition started from that alternate UBoot 
> partition, have an updater package that tells the iMX6 board to commit to the 
> changeover. This updater package would only run if it detected that the 
> bootable UBoot and currently-used UBoot were different.
>
> The advantage of this is that, unless the new UBoot is FULLY capable of 
> running our system partition (and also running an installer from there), no 
> commit is possible, hence a simple power cycle would return to the previous 
> working state.
>
> We originally tried kexec from the system partition but it seemed to want to 
> run a Linux kernel rather than loading and executing some arbitrary boot code.
>
> So we then turned to the UBoot scripts themselves and thought we'd found a 
> way we could do it.
>
> 1/ We changed the mmcboot script by prefixing a special check and introduced 
> a variable for handling soft-boot:
> mmcboot=run check_uboot; 
> other_uboot=0
>
> 2/ We extracted the boot image uboot.bootimg from the IMX file by stripping 
> off the first 0xc00 bytes (we had to put this into the /boot file system 
> since I don't yet know how to get at raw partition data from UBoot scripts.
>
> 3/ We defined check_uboot as:
> if test ${other_uboot} -eq 1; then
> setenv other_uboot 0
> saveenv
> ext4load mmc ${mmcdev}:${mmcpart} 0x1780 
> /boot/uboot.bootimg
> go 0x1780
> fi
> The way this should work is that, if alternate boot is flagged, it 
> immediately unflags it (for recovery if the alternate fails) then loads and 
> executes the other UBoot image. If it's not flagged, check_uboot will return 
> without trying to soft-boot the alternate.
>
> 4/ After installing the new UBoot to the alternate partition, we set a UBoot 
> variable (other_uboot) to 1 and rebooted.
>
> Now this seemed to work inasmuch as the alternate UBoot program started 
> pumping out console messages but, unfortunately, it seemed to hang partway 
> through the boot process.
>
> I suspect this is because, having already been through a portion of that boot 
> process in the primary UBoot, it's not keen on having to do it again.

You may need to flush the cache area that you read into, or use
'dcache off' before jumping to the second U-Boot.

>
> So I guess my questions are as follows:
>
> a/ How do people currently handle (if they do) the requirement that UBoot be 
> safely updatable in the field?
> b/ Does anyone have any ideas on how I could achieve this?
>
> I've been told that Google does something like this for Android booting but 
> had to heavily modify UBoot to do it. I haven't yet investigated this 
> possibility.

Chromium OS and Android verified boot (which is in mainline - see avb)
use an A/B system. You can have SPL chosen whether to boot from A or
B.

I'm actually working on integrating Chromium OS vboot into U-Boot
again. It uses TPL to select the SPL to use, which then boots into
UBoot proper. This is so we can update the SDRAM code. Am hoping to
have something going in January although a lot of the required patches
have been sent.

>
> Also, we actually do quite a bit of checking to ensure th

Re: [U-Boot] [PATCH 1/1] efi_loader: eliminate sandbox addresses

[Simon Glass]

Hi Heinrich,

On 10 November 2018 at 14:30, Heinrich Schuchardt  wrote:
> Do not use the sandbox's virtual address space for the internal structures
> of the memory map. This way we can eliminate a whole lot of unnecessary
> conversions.
>
> The only conversion remaining is the one when adding known memory.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_memory.c | 17 -
>  1 file changed, 4 insertions(+), 13 deletions(-)

I much prefer this, but Alex was not too keen.

Also please can you add detailed comments to efi_mem_desc about what
the addresses are for sandbox?

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

Re: [U-Boot] [PATCH v12 0/6] efi_loader: Code refactoring and improvement

[Simon Glass]

Hi,

On 6 November 2018 at 14:57, Simon Glass  wrote:
> This collects the patches previously sent to break up the very large
> functions in efi_loader into smaller pieces. Now that the other sandbox
> stuff is applied, perhaps it is time to apply these patches.
>
> This also adds a few new patches to fix more recent breakages.
> Unfortunately we still cannot enable the efi loader tests since one of
> the tests fails. Thus we should expect additional failures to appear
> until that is resolved.
>
> Changes in v12:
> - Rename image to image_prot
> - Update CPU nodes to comply with the DT spec

Any comments / reviews on this please?

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

Re: [U-Boot] [PATCH 3/3] misc: fs_loader: Fix compiler warning

[Simon Glass]

On 4 November 2018 at 23:04, Keerthy  wrote:
> Fix compiler warning
>
> drivers/misc/fs_loader.c:193:9: warning: format ‘%d’ expects
> argument of type ‘int’, but argument 5 has type ‘size_t
> {aka long unsigned int}’ [-Wformat=]
>
> Signed-off-by: Keerthy 
> ---
>  drivers/misc/fs_loader.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 v2 2/2] core: ofnode: Add ofnode_get_addr_size_index

[Simon Glass]

On 4 November 2018 at 22:55, Keerthy  wrote:
> Add ofnode_get_addr_size_index function to fetch the address
> and size of the reg space based on index.
>
> Signed-off-by: Keerthy 
> ---
>
> Changes in v2:
>
>   * Added the missing header file declaration of the new function.
>
>  drivers/core/ofnode.c | 14 ++
>  include/dm/ofnode.h   | 13 +
>  2 files changed, 23 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH 4/4] pinctrl: stm32: make pinctrl use hwspinlock

[Simon Glass]

Hi Benjamin,

On 13 November 2018 at 01:51, Benjamin Gaignard
 wrote:
> From: Benjamin Gaignard 
>
> Protect configuration registers with a hardware spinlock

Can you please add a bit more detail about what problem this fixes?

>
> Signed-off-by: Benjamin Gaignard 
> ---
>  arch/arm/dts/stm32mp157c-ed1.dts |  4 
>  drivers/pinctrl/pinctrl_stm32.c  | 22 ++
>  2 files changed, 26 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts 
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index fc277dd7d2..7a9b742d36 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -369,6 +369,10 @@
> status = "okay";
>  };
>
> +&pinctrl {
> +   hwlocks = <&hwspinlock 0>;
> +};
> +
>  &usbphyc_port0 {
> phy-supply = <&vdd_usb>;
> vdda1v1-supply = <®11>;
> diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
> index 31285cdd57..469cc0c543 100644
> --- a/drivers/pinctrl/pinctrl_stm32.c
> +++ b/drivers/pinctrl/pinctrl_stm32.c
> @@ -1,6 +1,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -19,12 +20,20 @@ static int stm32_gpio_config(struct gpio_desc *desc,
>  {
> struct stm32_gpio_priv *priv = dev_get_priv(desc->dev);
> struct stm32_gpio_regs *regs = priv->regs;
> +   struct hwspinlock *hws = dev_get_priv(desc->dev->parent);
> u32 index;
> +   int ret;
>
> if (!ctl || ctl->af > 15 || ctl->mode > 3 || ctl->otype > 1 ||
> ctl->pupd > 2 || ctl->speed > 3)
> return -EINVAL;
>
> +   ret = hwspinlock_lock_timeout(hws, 1);
> +   if (ret == -ETIME) {
> +   dev_err(desc->dev, "HWSpinlock timeout\n");
> +   return ret;
> +   }
> +
> index = (desc->offset & 0x07) * 4;
> clrsetbits_le32(®s->afr[desc->offset >> 3], AFR_MASK << index,
> ctl->af << index);
> @@ -39,6 +48,8 @@ static int stm32_gpio_config(struct gpio_desc *desc,
> index = desc->offset;
> clrsetbits_le32(®s->otyper, OTYPE_MSK << index, ctl->otype << 
> index);
>
> +   hwspinlock_unlock(hws);
> +
> return 0;
>  }
>
> @@ -176,6 +187,15 @@ static int stm32_pinctrl_set_state_simple(struct udevice 
> *dev,
>  }
>  #endif /* PINCTRL_FULL */
>
> +static int stm32_pinctrl_probe(struct udevice *dev)
> +{
> +   struct hwspinlock *hws = dev_get_priv(dev);
> +
> +   hwspinlock_get_by_index(dev, 0, hws);

Need to check return value

> +
> +   return 0;
> +}
> +
>  static struct pinctrl_ops stm32_pinctrl_ops = {
>  #if CONFIG_IS_ENABLED(PINCTRL_FULL)
> .set_state  = stm32_pinctrl_set_state,
> @@ -200,4 +220,6 @@ U_BOOT_DRIVER(pinctrl_stm32) = {
> .of_match   = stm32_pinctrl_ids,
> .ops= &stm32_pinctrl_ops,
> .bind   = dm_scan_fdt_dev,
> +   .probe  = stm32_pinctrl_probe,
> +   .priv_auto_alloc_size = sizeof(struct hwspinlock),
>  };
> --
> 2.15.0
>

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

Re: [U-Boot] [PATCH 1/2] core: ofnode: Fix ofnode_get_addr_size_index function

[Simon Glass]

On 4 November 2018 at 22:47, Keerthy  wrote:
> Currently the else part of ofnode_get_addr_size_index function
> does not fetch addresses based on the index but rather just
> returns the base address. Fix that.
>
> Signed-off-by: Keerthy 
> ---
>  drivers/core/ofnode.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 

This should really have a sandbox test, e.g. see
dm_test_fdt_remap_addr_flat,() for a test that relies on flagtree.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] misc: fs_loader: Use device_get_global_by_ofnode to get to node

[Simon Glass]

On 4 November 2018 at 23:04, Keerthy  wrote:
> Instead of two staged ofnode_to_offset followed by
> device_get_global_by_of_offset approach, direcly use the
> device_get_global_by_ofnode to fetch the device.
>
> Signed-off-by: Keerthy 
> ---
>  drivers/misc/fs_loader.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

with change below

>
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index b7bb96a..5afc941 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -55,11 +55,9 @@ static int select_fs_dev(struct device_platdata *plat)
>
> node = ofnode_get_by_phandle(plat->phandlepart.phandle);
>
> -   int of_offset = ofnode_to_offset(node);
> -
> struct udevice *dev;
>
> -   ret = device_get_global_by_of_offset(of_offset, &dev);
> +   ret = device_get_global_by_ofnode(node, &dev);
> if (!ret) {
> struct blk_desc *desc = blk_get_by_device(dev);
> if (desc) {
> @@ -190,6 +188,7 @@ static int fw_get_filesystem_firmware(struct 
> device_platdata *plat,
>
> ret = fs_read(fw_priv->name, (ulong)map_to_sysmem(firmware->data),
> fw_priv->offset, firmware->size, &actread);
> +

Please drop this blank line.

> if (ret) {
> debug("Error: %d Failed to read %s from flash %lld != %d.\n",
>   ret, fw_priv->name, actread, firmware->size);
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/19] dm: i2c: Make i2c_get_chip_for_busnum() fail if the chip is not detected

[Simon Glass]

Hi Jean-Jacques,

On 5 November 2018 at 02:38, Jean-Jacques Hiblot  wrote:
> Hi Simon,
>
>
> On 03/11/2018 07:07, Simon Glass wrote:
>>
>> Hi Jean-Jacques,
>>
>> On 22 October 2018 at 08:12, Jean-Jacques Hiblot  wrote:
>>>
>>> i2c_get_chip_for_busnum() really should check the presence of the chip on
>>> the bus. Most of the users of this function assume that this is done.
>>>
>>> Signed-off-by: Jean-Jacques Hiblot 
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - removed commit introducing dm_i2c_probe_device(). Instead probe the
>>>presence of the chip on the I2C bus in i2c_get_chip_for_busnum().
>>>
>>> Changes in v2: None
>>>
>>>   drivers/i2c/i2c-uclass.c | 11 +++
>>>   1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
>>> index c5a3c4e..975318e 100644
>>> --- a/drivers/i2c/i2c-uclass.c
>>> +++ b/drivers/i2c/i2c-uclass.c
>>> @@ -347,6 +347,17 @@ int i2c_get_chip_for_busnum(int busnum, int
>>> chip_addr, uint offset_len,
>>>  debug("Cannot find I2C bus %d\n", busnum);
>>>  return ret;
>>>  }
>>> +
>>> +   /* detect the presence of the chip on the bus */
>>> +   ret = i2c_probe_chip(bus, chip_addr, 0);
>>> +   debug("%s: bus='%s', address %02x, ret=%d\n", __func__,
>>> bus->name,
>>> + chip_addr, ret);
>>> +   if (ret) {
>>> +   debug("Cannot detect I2C chip %02x on bus %d\n",
>>> chip_addr,
>>> + busnum);
>>> +   return ret;
>>> +   }
>>> +
>>
>> I really don't like to keep going on about this, but I think this is
>> still not quite right.
>
>
> That is the development model of many open source projects that made their
> success. So I don't mind.

OK good :-)

>
>>
>> If the chip is not present that is generally an error, or at least it
>> is assumed to be by the callers.
>
> agreed. That is the purpose of the modification
>>
>>
>> i2c_get_chip() is called just above the code you add. This normally
>> probes an existing device at that i2c address, which presumably checks
>> that it is present. However if there is no device at the given
>> address, it calls device_bind():
>>
>> debug("%s: Searching bus '%s' for address %02x: ", __func__,
>>bus->name, chip_addr);
>> for (device_find_first_child(bus, &dev); dev;
>>  device_find_next_child(&dev)) {
>>  struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
>>  int ret;
>>
>>  if (chip->chip_addr == chip_addr) {
>>  ret = device_probe(dev);
>>  debug("found, ret=%d\n", ret);
>>  f (ret)
>>  return ret;
>>  *devp = dev;
>>  return 0;
>>  }
>>  }
>> debug("not found\n");
>> return i2c_bind_driver(bus, chip_addr, offset_len, devp);
>>
>> So I think your new code below should only be used in the case where
>> device_bind() was called.
>
>
> I don't think it hurts to probe the presence of the chip after the
> device_probe() is called.

It costs time and is pointless if the chip is present. On the other
hand, this function is presumably only used when there is nothing int
the DT, so perhaps people don't care.

>
> And I am not sure that the all drivers detect the chip in their probe()
> functions.

Agreed, I suspect that many don't, although I have not looked.

>
>>
>> What is the case where you:
>>
>> a) Don't put the I2C device in the device tree
>> b) Expect it to be bound
>> c) Want to know if it is not present
>
>
> This is exactly the use case I'm trying to address. There are several
> possible cases:
>
> - Some platforms haven't gone full DM yet and don't put the I2C device in
> the DT.
>
> - Other just don't have a DM I2C driver for the chip and only send a few
> commands to initialize it. Adding a real I2C-driver may be overkill.
>
> - Other platforms rely on the detection of external devices to further
> identify the platform with no need to actually use the external chip.

OK that all sounds fine to me. For the last case I think it makes
sense to have a function that the platform has to call.

>
>
>>
>> Looking at it closely, i2c_get_chip() is not consistent. It probes the
>> device it is is already bound, but if not, it binds a device and then
>> fails to probe it. I think it should call device_prove() after binding
>> it.
>
> Calling device_probe() would work only if a DM I2C driver exists for the
> chip and if a description exists in the DT. So I don't think it would work
> for the cases I mentioned above.

OK I see. Your patch is for the other case.

>>
>>
>> Would that be good enough?
>>
>> Otherwise, perhaps we just need a function like:
>>
>> i2c_probe_device(struct udevice *dev)
>>
>> which calls i2c_probe_chip() on the appropriate address?
>
>
> That works, it was what was done in the first version. But I think this
> version is better as it doesn't introduce a new function and make
> i2c_get_chip_for_busnum() behave as people expect it to behave: 

Re: [U-Boot] [PATCH 1/3] fs: Makefile: Add fs.c under SPL as well as it is needed for fs_loader

[Simon Glass]

On 4 November 2018 at 23:04, Keerthy  wrote:
> Add fs.c under SPL as well as it is needed for fs_loader
>
> Signed-off-by: Keerthy 
> ---
>  fs/Makefile | 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 3/4] hwspinlock: add stm32 hardware spinlock support

[Simon Glass]

Hi Benjamin,

On 13 November 2018 at 01:51, Benjamin Gaignard
 wrote:
> Implement hardware spinlock support for STM32MP1.
>
> Signed-off-by: Benjamin Gaignard 
> ---
>  arch/arm/dts/stm32mp157c-ed1.dts  |  4 ++
>  arch/arm/dts/stm32mp157c.dtsi |  9 
>  configs/stm32mp15_basic_defconfig |  2 +
>  drivers/hwspinlock/Kconfig|  6 +++
>  drivers/hwspinlock/Makefile   |  1 +
>  drivers/hwspinlock/stm32_hwspinlock.c | 90 
> +++
>  6 files changed, 112 insertions(+)
>  create mode 100644 drivers/hwspinlock/stm32_hwspinlock.c
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts 
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index f8b7701167..fc277dd7d2 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -365,6 +365,10 @@
> usb33d-supply = <&usb33>;
>  };
>
> +&hwspinlock {
> +   status = "okay";
> +};
> +
>  &usbphyc_port0 {
> phy-supply = <&vdd_usb>;
> vdda1v1-supply = <®11>;
> diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
> index 33c5981869..37cadfa30c 100644
> --- a/arch/arm/dts/stm32mp157c.dtsi
> +++ b/arch/arm/dts/stm32mp157c.dtsi
> @@ -690,6 +690,15 @@
> status = "disabled";
> };
>
> +   hwspinlock: hwspinlock@4c00 {
> +   compatible = "st,stm32-hwspinlock";
> +   #hwlock-cells = <1>;
> +   reg = <0x4c00 0x400>;
> +   clocks = <&rcc HSEM>;
> +   clock-names = "hwspinlock";
> +   status = "disabled";
> +   };
> +
> rcc: rcc@5000 {
> compatible = "st,stm32mp1-rcc", "syscon";
> reg = <0x5000 0x1000>;
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 3bf7538089..c8409fd04e 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -32,6 +32,8 @@ CONFIG_CMD_EXT4_WRITE=y
>  # CONFIG_SPL_DOS_PARTITION is not set
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_STM32_ADC=y
> +CONFIG_DM_HWSPINLOCK=y
> +CONFIG_HWSPINLOCK_STM32=y
>  CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_STM32F7=y
>  CONFIG_LED=y
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index de367fd2a9..f28d582bb2 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -13,4 +13,10 @@ config HWSPINLOCK_SANDBOX
>   can be probed and support all the methods of HWSPINLOCK, but does 
> not
>   really do anything.
>
> +config HWSPINLOCK_STM32
> +   bool "Enable Hardware Spinlock support for STM32"
> +   depends on ARCH_STM32MP && DM_HWSPINLOCK
> +   help
> + Enable hardware spinlock support in STM32MP.

Please add more detail here - what is it used for and how does it work?

> +
>  endmenu
> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> index 2704d6814f..289b12a256 100644
> --- a/drivers/hwspinlock/Makefile
> +++ b/drivers/hwspinlock/Makefile
> @@ -4,3 +4,4 @@
>
>  obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock-uclass.o
>  obj-$(CONFIG_HWSPINLOCK_SANDBOX) += sandbox_hwspinlock.o
> +obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o
> diff --git a/drivers/hwspinlock/stm32_hwspinlock.c 
> b/drivers/hwspinlock/stm32_hwspinlock.c
> new file mode 100644
> index 00..b8f3b1632f
> --- /dev/null
> +++ b/drivers/hwspinlock/stm32_hwspinlock.c
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Do you need this?

> +#include 

Or this?

> +#include 
> +#include 
> +
> +#define STM32_MUTEX_COREID BIT(8)
> +#define STM32_MUTEX_LOCK_BIT   BIT(31)
> +#define STM32_MUTEX_NUM_LOCKS  32
> +
> +static int stm32mp1_lock(struct udevice *dev, int index)
> +{
> +   fdt_addr_t *base = dev_get_priv(dev);
> +   u32 status;
> +
> +   if (index >= STM32_MUTEX_NUM_LOCKS)
> +   return -EINVAL;
> +
> +   status = readl(*base + index * sizeof(u32));
> +   if (status == (STM32_MUTEX_LOCK_BIT | STM32_MUTEX_COREID))
> +   return -EBUSY;
> +
> +   writel(STM32_MUTEX_LOCK_BIT | STM32_MUTEX_COREID,
> +  *base + index * sizeof(u32));
> +
> +   status = readl(*base + index * sizeof(u32));
> +   if (status != (STM32_MUTEX_LOCK_BIT | STM32_MUTEX_COREID))
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
> +static int stm32mp1_unlock(struct udevice *dev, int index)
> +{
> +   fdt_addr_t *base = dev_get_priv(dev);
> +
> +   if (index >= STM32_MUTEX_NUM_LOCKS)
> +   return -EINVAL;
> +
> +   writel(STM32_MUTEX_COREID, *base + index * sizeof(u32));
> +
> +   return 0;
> +}
> +
> +static int stm32mp1_hwspinlock_probe(struct

Re: [U-Boot] [PATCH 1/4] dm: Add Hardware Spinlock class

[Simon Glass]

Hi Benjamin,

On 13 November 2018 at 01:51, Benjamin Gaignard
 wrote:
>
> From: Benjamin Gaignard 
>
> This is uclass for Hardware Spinlocks.
> It implements two mandatory operations: lock and unlock
> and one optional relax operation.
>
> Signed-off-by: Benjamin Gaignard 
> ---
>  arch/sandbox/dts/test.dts   |   4 +
>  arch/sandbox/include/asm/state.h|   1 +
>  configs/sandbox_defconfig   |   2 +
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/hwspinlock/Kconfig  |  16 
>  drivers/hwspinlock/Makefile |   6 ++
>  drivers/hwspinlock/hwspinlock-uclass.c  | 145 
> 
>  drivers/hwspinlock/sandbox_hwspinlock.c |  56 
>  include/dm/uclass-id.h  |   1 +
>  include/hwspinlock.h| 140 ++
>  test/dm/Makefile|   1 +
>  test/dm/hwspinlock.c|  40 +
>  13 files changed, 415 insertions(+)
>  create mode 100644 drivers/hwspinlock/Kconfig
>  create mode 100644 drivers/hwspinlock/Makefile
>  create mode 100644 drivers/hwspinlock/hwspinlock-uclass.c
>  create mode 100644 drivers/hwspinlock/sandbox_hwspinlock.c
>  create mode 100644 include/hwspinlock.h
>  create mode 100644 test/dm/hwspinlock.c
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 57e0dd7663..50cd2f89e0 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -712,6 +712,10 @@
> sandbox_tee {
> compatible = "sandbox,tee";
> };
> +
> +   hwspinlock@0 {
> +   compatible = "sandbox,hwspinlock";
> +   };
>  };
>
>  #include "sandbox_pmic.dtsi"
> diff --git a/arch/sandbox/include/asm/state.h 
> b/arch/sandbox/include/asm/state.h
> index dcb6d5f568..a5d7c6aaf3 100644
> --- a/arch/sandbox/include/asm/state.h
> +++ b/arch/sandbox/include/asm/state.h
> @@ -99,6 +99,7 @@ struct sandbox_state {
>
> ulong next_tag; /* Next address tag to allocate */
> struct list_head mapmem_head;   /* struct sandbox_mapmem_entry */
> +   bool hwspinlock;/* Hardware Spinlock status */
>  };
>
>  /* Minimum space we guarantee in the state FDT when calling read/write*/
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 2ce336fc81..36b67be2df 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -97,6 +97,8 @@ CONFIG_BOARD=y
>  CONFIG_BOARD_SANDBOX=y
>  CONFIG_PM8916_GPIO=y
>  CONFIG_SANDBOX_GPIO=y
> +CONFIG_DM_HWSPINLOCK=y
> +CONFIG_HWSPINLOCK_SANDBOX=y
>  CONFIG_DM_I2C_COMPAT=y
>  CONFIG_I2C_CROS_EC_TUNNEL=y
>  CONFIG_I2C_CROS_EC_LDO=y
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 927a2b87f6..7e6ca7cd3e 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -40,6 +40,8 @@ source "drivers/fpga/Kconfig"
>
>  source "drivers/gpio/Kconfig"
>
> +source "drivers/hwspinlock/Kconfig"
> +
>  source "drivers/i2c/Kconfig"
>
>  source "drivers/input/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index fb38b67541..0ef56fb416 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -111,4 +111,5 @@ obj-$(CONFIG_W1) += w1/
>  obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
>
>  obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
> +obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock/
>  endif
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> new file mode 100644
> index 00..de367fd2a9
> --- /dev/null
> +++ b/drivers/hwspinlock/Kconfig
> @@ -0,0 +1,16 @@
> +menu "Hardware Spinlock Support"
> +
> +config DM_HWSPINLOCK
> +   bool "Enable U-Boot hardware spinlock support"
> +   help
> + This option enables U-Boot hardware spinlock support
> +
> +config HWSPINLOCK_SANDBOX
> +   bool "Enable Hardware Spinlock support for Sandbox"
> +   depends on SANDBOX && DM_HWSPINLOCK
> +   help
> + Enable hardware spinlock support in Sandbox. This is a dummy device 
> that
> + can be probed and support all the methods of HWSPINLOCK, but does 
> not
> + really do anything.
> +
> +endmenu
> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> new file mode 100644
> index 00..2704d6814f
> --- /dev/null
> +++ b/drivers/hwspinlock/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +#
> +# Copyright (C) 2018, STMicroelectronics - All Rights Reserved
> +
> +obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock-uclass.o
> +obj-$(CONFIG_HWSPINLOCK_SANDBOX) += sandbox_hwspinlock.o
> diff --git a/drivers/hwspinlock/hwspinlock-uclass.c 
> b/drivers/hwspinlock/hwspinlock-uclass.c
> new file mode 100644
> index 00..1fed24228c
> --- /dev/null
> +++ b/drivers/hwspinlock/hwspinlock-uclass.c
> @@ -0,0 +1,145 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2018, STMicroelectronics 

Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support

[Alexander Graf]

On 03.11.18 12:28, Akash Gajjar wrote:
> Rockpro64 is rk3399 based board from pine64.org. add initial board support for
> Rockpro64. complete board support will be added later in upcoming patchsets.
> 
> Signed-off-by: Akash Gajjar 
> ---

[...]

> diff --git a/board/rockchip/rockpro64/rockpro64.c 
> b/board/rockchip/rockpro64/rockpro64.c
> new file mode 100644
> index 00..74c7a56bd5
> --- /dev/null
> +++ b/board/rockchip/rockpro64/rockpro64.c
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2018 Akash Gajjar 

Given the file is copied from another copyrighted file, you can not just
go and replace the (c) with yours.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int board_init(void)
> +{
> + struct udevice *pinctrl, *regulator;
> + int ret;
> +
> + /*
> +  * The PWM do not have decicated interrupt number in dts and can

dedicated?

This whole file seems to just be a copy of
board/rockchip/evb_rk3399/evb-rk3399.c. Maybe you can abstract and share
code?

But please double check if what they do is actually necessary on
RockPro64 first.


Alex

> +  * not get periph_id by pinctrl framework, so let's init them here.
> +  * The PWM2 and PWM3 are for pwm regulater.
> +  */
> + ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> + if (ret) {
> + debug("%s: Cannot find pinctrl device\n", __func__);
> + goto out;
> + }
> +
> + /* Enable pwm0 for panel backlight */
> + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0);
> + if (ret) {
> + debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret);
> + goto out;
> + }
> +
> + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM2);
> + if (ret) {
> + debug("%s PWM2 pinctrl init fail!\n", __func__);
> + goto out;
> + }
> +
> + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM3);
> + if (ret) {
> + debug("%s PWM3 pinctrl init fail!\n", __func__);
> + goto out;
> + }
> +
> + ret = regulators_enable_boot_on(false);
> + if (ret)
> + debug("%s: Cannot enable boot on regulator\n", __func__);
> +
> + ret = regulator_get_by_platname("vcc5v0_host", ®ulator);
> + if (ret) {
> + debug("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
> + goto out;
> + }
> +
> + ret = regulator_set_enable(regulator, true);
> + if (ret) {
> + debug("%s vcc5v0-host-en set fail!\n", __func__);
> + goto out;
> + }
> +
> +out:
> + return 0;
> +}
> +
> +void spl_board_init(void)
> +{
> + struct udevice *pinctrl;
> + int ret;
> +
> + ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> + if (ret) {
> + debug("%s: Cannot find pinctrl device\n", __func__);
> + goto err;
> + }
> +
> + /* Enable debug UART */
> + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
> + if (ret) {
> + debug("%s: Failed to set up console UART\n", __func__);
> + goto err;
> + }
> +
> + preloader_console_init();
> + return;
> +err:
> + printf("%s: Error %d\n", __func__, ret);
> +
> + /* No way to report error here */
> + hang();
> +}
> diff --git a/configs/rockpro64-rk3399_defconfig 
> b/configs/rockpro64-rk3399_defconfig
> new file mode 100644
> index 00..88422f2db4
> --- /dev/null
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -0,0 +1,78 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_TARGET_ROCKPRO64_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_STACK_R_ADDR=0x8
> +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-rockpro64.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_SPL_ATF=y
> +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_REGMAP=y
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SYSCON=y
> +CONFIG_SPL_SYSCON=y
> +CONFIG_CLK=y
> +CONFIG_SPL_CLK=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +

Re: [U-Boot] [PATCH 3/4] fs: prevent overwriting reserved memory

[Heinrich Schuchardt]

On 11/13/18 6:47 AM, Simon Goldschmidt wrote:
> On Tue, Nov 13, 2018 at 3:23 AM Fabio Estevam  wrote:
>>
>> Hi Simon,
>>
>> On Mon, Nov 12, 2018 at 7:25 PM Simon Goldschmidt
>>  wrote:
>>
>>> diff --git a/fs/fs.c b/fs/fs.c
>>> index adae98d021..4baf6b1c39 100644
>>> --- a/fs/fs.c
>>> +++ b/fs/fs.c
>>> @@ -428,13 +428,57 @@ int fs_size(const char *filename, loff_t *size)
>>> return ret;
>>>  }
>>>
>>> -int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
>>> -   loff_t *actread)
>>> +#ifdef CONFIG_LMB
>>
>> Unrelated to your series, but I was wondering if we could get rid of
>> the CONFIG_LMB option.
>>
>> As far as I can see all the architectures define it, the only
>> exception being arch/sh.
>>
>> If you agree I can send a patch after your series gets applied that
>> removes CONFIG_LMB.
> 
> Sure, that would clean things up.
> 
> Simon
> 

NAK

This patch-series does not provide what is needed. With
odroid-c2_defconfig I get

fdt list /reserved-memory/secmon@1000
reserved-memory {
secmon@1000 {
reg = <0x 0x1000 0x 0x0020>;
no-map;
};
};

=> load mmc 0:1 0x1000 dtb
22925 bytes read in 8 ms (2.7 MiB/s)

So now I have successfully overwritten the secure monitor. Urrgh.

As you have observed load is still writing into a memory area that is
reserved by the device-tree.

Please, iterate over the device tree to ensure that nothing is loaded
into a reserved memory area. Do not expect board files to do anything
but create the reserve-memory entry in the device tree.

Best regards

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

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

[Tom Rini]

On Wed, Nov 14, 2018 at 12:49:45AM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks,
> Jagan.
> 
> The following changes since commit 454cf76184c65426b68033a23da086e73663f2fc:
> 
>   Prepare v2018.11-rc3 (2018-10-29 16:04:26 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 7d121a8ea4e0dbf0d7e105b57c3dbd7d8bd2e729:
> 
>   sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD 
> (2018-11-13 22:17:06 +0530)
> 
> 
> Andre Przywara (4):
>   sunxi: A64: Update .dts/.dtsi files
>   sunxi: A64: Re-add syscon to DT node
>   sunxi: H3/H5: Update .dts files
>   sunxi: A64: Add Pine64-LTS board
> 
> Icenowy Zheng (1):
>   sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD
> 
> Jagan Teki (2):
>   arm64: allwinner: h6: Add common orangepi nodes into dtsi
>   board: allwinner: sun50i-h6: Add Orangepi Lite2 support
> 
> Jun Nie (1):
>   sunxi: add support for Banana Pi M2 Zero board
> 
> Marek Vasut (1):
>   sunxi: Imply fitImage support
> 
> Vasily Khoruzhick (4):
>   mmc: sunxi: add support for automatic delay calibration
>   dm: video: bridge: don't fail to activate bridge if reset or sleep GPIO 
> is missing
>   sun50i: A64: add support for R_I2C controller
>   sunxi: DT: add support for Pinebook
> 
>  arch/arm/Kconfig|   1 +
>  arch/arm/dts/Makefile   |   3 +
>  arch/arm/dts/sun50i-a64-amarula-relic.dts   | 168 -
>  arch/arm/dts/sun50i-a64-bananapi-m64.dts|  34 ++-
>  arch/arm/dts/sun50i-a64-nanopi-a64.dts  |  89 ++-
>  arch/arm/dts/sun50i-a64-olinuxino.dts   | 103 +++-
>  arch/arm/dts/sun50i-a64-orangepi-win.dts| 179 +-
>  arch/arm/dts/sun50i-a64-pine64-lts.dts  |  13 +
>  arch/arm/dts/sun50i-a64-pine64.dts  |  32 ++-
>  arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi|  15 ++
>  arch/arm/dts/sun50i-a64-pinebook.dts| 294 ++
>  arch/arm/dts/sun50i-a64-sopine-baseboard.dts|  32 ++-
>  arch/arm/dts/sun50i-a64-sopine.dtsi |  15 ++
>  arch/arm/dts/sun50i-a64.dtsi| 312 
> ++--
>  arch/arm/dts/sun50i-h5-orangepi-pc2.dts |  12 +
>  arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts   |   2 -
>  arch/arm/dts/sun50i-h6-orangepi-lite2.dts   |  11 +
>  arch/arm/dts/sun50i-h6-orangepi-one-plus.dts| 140 +--
>  arch/arm/dts/sun50i-h6-orangepi.dtsi| 150 
>  arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 121 +
>  arch/arm/dts/sun8i-h3.dtsi  |  31 +++
>  arch/arm/dts/sunxi-h3-h5.dtsi   |   2 -
>  arch/arm/include/asm/arch-sunxi/gpio.h  |   1 +
>  arch/arm/include/asm/arch-sunxi/mmc.h   |   6 +-
>  arch/arm/mach-sunxi/Kconfig |   1 +
>  arch/arm/mach-sunxi/clock_sun6i.c   |   4 +
>  board/sunxi/MAINTAINERS |  10 +
>  board/sunxi/board.c |   6 +
>  configs/bananapi_m2_zero_defconfig  |  13 +
>  configs/orangepi_lite2_defconfig|  12 +
>  configs/pine64-lts_defconfig|  19 ++
>  configs/pinebook_defconfig  |  22 ++
>  drivers/mmc/sunxi_mmc.c |  21 +-
>  drivers/video/bridge/video-bridge-uclass.c  |  16 +-
>  drivers/video/sunxi/lcdc.c  |  22 +-
>  35 files changed, 1710 insertions(+), 202 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-a64-pine64-lts.dts
>  create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
>  create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
>  create mode 100644 arch/arm/dts/sun50i-h6-orangepi-lite2.dts
>  create mode 100644 arch/arm/dts/sun50i-h6-orangepi.dtsi
>  create mode 100644 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
>  create mode 100644 configs/bananapi_m2_zero_defconfig
>  create mode 100644 configs/orangepi_lite2_defconfig
>  create mode 100644 configs/pine64-lts_defconfig
>  create mode 100644 configs/pinebook_defconfig

This seems to be somewhat the opposite of the SPI PR in that it's not
just fixing up a few corner cases and so forth, so I assume you intend
me to pull this after the release.

-- 
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] board: rockchip: rk3399: add Rockpro64 board support

[Alexander Graf]

On 05.11.18 08:42, akash wrote:
> Hi Jagan,
> 
> On 05/11/18 12:40 PM, Jagan Teki wrote:
>> On 03/11/18 4:58 PM, Akash Gajjar wrote:
>>> Rockpro64 is rk3399 based board from pine64.org. add initial board
>>> support for
>>> Rockpro64. complete board support will be added later in upcoming
>>> patchsets.
>>>
>>> Signed-off-by: Akash Gajjar 
>>> ---
>>>   arch/arm/dts/Makefile  |    1 +
>>>   arch/arm/dts/rk3399-rockpro64.dts  |  519 +++
>>
>> Does it pure Linux sync file? if yes mention the commit id details on
>> commit message.
> Nope, it is not pure Linux sync file. though dts support is queued for
> Linux 4.20.

Please make sure to reuse the Linux dts. That way we can in the distro
boot path just not load yet another DT and simply reuse the U-Boot one.
For stable SoCs (and rk3399 should be one of them) this has worked quite
well in the past.

>>
>>> arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi | 1535 
>>
>> Send this separately, more convenient to review ddr changes separately.
> Will do this in v2 changes.
>>
>>> arch/arm/mach-rockchip/rk3399/Kconfig  |   10 +
>>>   board/rockchip/rockpro64/Kconfig   |   15 +
>>>   board/rockchip/rockpro64/MAINTAINERS   |    6 +
>>>   board/rockchip/rockpro64/Makefile  |    7 +
>>>   board/rockchip/rockpro64/rockpro64.c   |   94 ++
>>>   configs/rockpro64-rk3399_defconfig |   78 +
>>>   include/configs/rockpro64.h    |   15 +
>>>   10 files changed, 2280 insertions(+)
>>>   create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
>>>   create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-1600.dtsi
>>>   create mode 100644 board/rockchip/rockpro64/Kconfig
>>>   create mode 100644 board/rockchip/rockpro64/MAINTAINERS
>>>   create mode 100644 board/rockchip/rockpro64/Makefile
>>>   create mode 100644 board/rockchip/rockpro64/rockpro64.c
>>>   create mode 100644 configs/rockpro64-rk3399_defconfig
>>>   create mode 100644 include/configs/rockpro64.h
>>>
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index d36447d18d..8a84cf55a3 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>>   rk3399-puma-ddr1333.dtb \
>>>   rk3399-puma-ddr1600.dtb \
>>>   rk3399-puma-ddr1866.dtb \
>>> +    rk3399-rockpro64.dtb \
>>>   rv1108-evb.dtb
>>>   dtb-$(CONFIG_ARCH_MESON) += \
>>>   meson-gxbb-nanopi-k2.dtb \
>>> diff --git a/arch/arm/dts/rk3399-rockpro64.dts
>>> b/arch/arm/dts/rk3399-rockpro64.dts
>>> new file mode 100644
>>> index 00..8497a1124b
>>> --- /dev/null
>>> +++ b/arch/arm/dts/rk3399-rockpro64.dts
>>> @@ -0,0 +1,519 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2018 Akash Gajjar 
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include 
>>> +#include 
>>> +#include "rk3399.dtsi"
>>> +#include "rk3399-sdram-lpddr4-1600.dtsi"
>>
>> if this change related to u-boot, just sync Linux dts file and create
>> -u-boot.dtsi and include this on that.
>>
>> Just to understand, what has been tested with this support?
> This initial phase patchsets are just to notify community that board
> support is in progress.
> 
> In V2 changes will add complete support of u-boot for Rockpro64.

When can we expect v2? The merge window is opening :)


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

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

[Jagan Teki]

Hi Tom,

Please pull this PR.

thanks,
Jagan.

The following changes since commit 454cf76184c65426b68033a23da086e73663f2fc:

  Prepare v2018.11-rc3 (2018-10-29 16:04:26 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 7d121a8ea4e0dbf0d7e105b57c3dbd7d8bd2e729:

  sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD (2018-11-13 
22:17:06 +0530)


Andre Przywara (4):
  sunxi: A64: Update .dts/.dtsi files
  sunxi: A64: Re-add syscon to DT node
  sunxi: H3/H5: Update .dts files
  sunxi: A64: Add Pine64-LTS board

Icenowy Zheng (1):
  sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD

Jagan Teki (2):
  arm64: allwinner: h6: Add common orangepi nodes into dtsi
  board: allwinner: sun50i-h6: Add Orangepi Lite2 support

Jun Nie (1):
  sunxi: add support for Banana Pi M2 Zero board

Marek Vasut (1):
  sunxi: Imply fitImage support

Vasily Khoruzhick (4):
  mmc: sunxi: add support for automatic delay calibration
  dm: video: bridge: don't fail to activate bridge if reset or sleep GPIO 
is missing
  sun50i: A64: add support for R_I2C controller
  sunxi: DT: add support for Pinebook

 arch/arm/Kconfig|   1 +
 arch/arm/dts/Makefile   |   3 +
 arch/arm/dts/sun50i-a64-amarula-relic.dts   | 168 -
 arch/arm/dts/sun50i-a64-bananapi-m64.dts|  34 ++-
 arch/arm/dts/sun50i-a64-nanopi-a64.dts  |  89 ++-
 arch/arm/dts/sun50i-a64-olinuxino.dts   | 103 +++-
 arch/arm/dts/sun50i-a64-orangepi-win.dts| 179 +-
 arch/arm/dts/sun50i-a64-pine64-lts.dts  |  13 +
 arch/arm/dts/sun50i-a64-pine64.dts  |  32 ++-
 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi|  15 ++
 arch/arm/dts/sun50i-a64-pinebook.dts| 294 ++
 arch/arm/dts/sun50i-a64-sopine-baseboard.dts|  32 ++-
 arch/arm/dts/sun50i-a64-sopine.dtsi |  15 ++
 arch/arm/dts/sun50i-a64.dtsi| 312 ++--
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts |  12 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts   |   2 -
 arch/arm/dts/sun50i-h6-orangepi-lite2.dts   |  11 +
 arch/arm/dts/sun50i-h6-orangepi-one-plus.dts| 140 +--
 arch/arm/dts/sun50i-h6-orangepi.dtsi| 150 
 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 121 +
 arch/arm/dts/sun8i-h3.dtsi  |  31 +++
 arch/arm/dts/sunxi-h3-h5.dtsi   |   2 -
 arch/arm/include/asm/arch-sunxi/gpio.h  |   1 +
 arch/arm/include/asm/arch-sunxi/mmc.h   |   6 +-
 arch/arm/mach-sunxi/Kconfig |   1 +
 arch/arm/mach-sunxi/clock_sun6i.c   |   4 +
 board/sunxi/MAINTAINERS |  10 +
 board/sunxi/board.c |   6 +
 configs/bananapi_m2_zero_defconfig  |  13 +
 configs/orangepi_lite2_defconfig|  12 +
 configs/pine64-lts_defconfig|  19 ++
 configs/pinebook_defconfig  |  22 ++
 drivers/mmc/sunxi_mmc.c |  21 +-
 drivers/video/bridge/video-bridge-uclass.c  |  16 +-
 drivers/video/sunxi/lcdc.c  |  22 +-
 35 files changed, 1710 insertions(+), 202 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-a64-pine64-lts.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
 create mode 100644 arch/arm/dts/sun50i-h6-orangepi-lite2.dts
 create mode 100644 arch/arm/dts/sun50i-h6-orangepi.dtsi
 create mode 100644 arch/arm/dts/sun8i-h2-plus-bananapi-m2-zero.dts
 create mode 100644 configs/bananapi_m2_zero_defconfig
 create mode 100644 configs/orangepi_lite2_defconfig
 create mode 100644 configs/pine64-lts_defconfig
 create mode 100644 configs/pinebook_defconfig
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Pull request, v2018.11, v2: u-boot-spi/master

[Jagan Teki]

Hi Tom,

Here is v2 PR MTD, DFU fixes, please pull the same.

Change for v2:
- Fixed patches for travis-ci build

The following changes since commit c80cc3df3d196302c401e45c92d8a769c55e78e9:

  Merge tag 'u-boot-imx-20181112' of git://git.denx.de/u-boot-imx (2018-11-12 
08:06:34 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 1f758b793649a18b76252bf507312465310637ad:

  mtd: Drop duplicate MTD_PARTITIONS Kconfig option (2018-11-13 18:53:10 +0530)


Boris Brezillon (5):
  mtd: Use default mtdparts/mtids when not defined in the environment
  dfu: nand: Add missing dependency on CMD_MTDPARTS
  mtd: Make {MTDIDS, MTDPARTS}_DEFAULT visible when MTD_PARTITIONS is 
selected
  cmd: ubi: Remove useless call to mtdparts_init()
  mtd: Drop duplicate MTD_PARTITIONS Kconfig option

 cmd/Kconfig |  5 ++--
 cmd/ubi.c   |  5 
 drivers/dfu/Kconfig |  1 +
 drivers/mtd/Kconfig |  6 -
 drivers/mtd/mtd_uboot.c | 62 +++--
 5 files changed, 63 insertions(+), 16 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Rockchip RV1108 eMMC initialization fail

[Otavio Salvador]

On Tue, Nov 13, 2018 at 1:47 PM alex94
 wrote:
> I tried that, but the same error happens.
>
> I saw that here in the first post:
>
> http://u-boot.10912.n7.nabble.com/Rockchip-RV1108-eMMC-support-not-working-td343843.html#a343866
>
> in the U-boot log, GPLL is 38400, where in my log is 118800.
>
>
> Also, in the same post from above, what kind of MMC card is used?

Our board has a very minimal dts, we removed a lot of the nodes while
adding support for it. Something like this: http://termbin.com/gqyd

Give this a go and see if it helps.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] efi disks in u-boot

[Simon Glass]

Hi Akahsi,

On 5 November 2018 at 20:15, AKASHI Takahiro  wrote:
> Hello Simon,
>
> You said, in efi/lib_loader/efi_disk.c,
>
> ===8<===
>  * TODO(s...@chromium.org): Actually with CONFIG_BLK, U-Boot does have this.
>  * Consider converting the code to look up devices as needed. The EFI device
>  * could be a child of the UCLASS_BLK block device, perhaps.
>  *
>  * This gets called from do_bootefi_exec().
>  */
> efi_status_t efi_disk_register(void)
> {
> ===>8===
>
> What do you mean by this statement?
> Is it different from the code under "#if CONFIG_BLK"?
>
> I guess that you would suggest that some hook function be called
> in blk_create_device() and blk_unbind_all(). No?

I would actually like EFI to use the U-Boot DM devices directly, with
just the minimal amount of plumbing. Perhaps an EFI child device that
gets created for each block device?

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

Re: [U-Boot] UBoot running UBoot - is it possible?

[Stefano Babic]

Hi Simon,

On 13/11/18 18:43, Simon Goldschmidt wrote:
> 
> 
> Am Di., 13. Nov. 2018, 17:53 hat Stefano Babic  > geschrieben:
> 
> On 13/11/18 17:07, Simon Goldschmidt wrote:
> > On 13.11.2018 17:00, Wolfgang Denk wrote:
> >> Dear Simon,
> >>
> >> In message
> >>
>  >
> >> you wrote:
> >>> My idea was to let SPL implement a dedicated boot counter/watchdog
> >>> that detects problems starting U-Boot and using a backup copy if it
> >>> fails multiple times. Of course you need an SPL on your board to do
> >>> this. Plus you end up with the same problem for updating SPL,
> but I'm
> >>> lucky here that my platform (socfpga gen5) has redundant storage for
> >>> SPL and implements a startup watchdog mechanism for the SPL.
> >> In other words, you are just adding enough additional complexity to
> >> SPL to make it reasonably likely that there will be bugs that need
> >> to be fixed later, i. e. you have to update the SPL.
> >>
> >> And then?
> >>
> >> You are just moving the problem, not solving it.
> >
> > That's not how I see it. As I see it, I have to implement an upgrade
> > option for SPL. This is partly due to bad design of the socfpga_gen5
> > platform. But also I have read multiple times on this list that you
> > should use SPL from the same version as U-Boot as they might work
> > combined and U-Boot might depend on SPL to do things that might change
> > over time.
> 
> Right. It is not guaranteed that mixing versions works.
> 
> > So is it really a good idea to upgrade U-Boot without
> > upgrading SPL at the same time?
> 
> IMHO it is a bad idea, and it forgets that the bootloader is really SPL
> + u-boot.img else just u-boot.img. It is also questionable if it makes
> sense to provide an update mechanism for u-boot when most of critical
> parts like clocks, DDR initialisation, etc. are in SPL.
> 
> > It seems to me this would require
> > thorough testing of different version mixes...
> >
> 
> Agree, and this becomes a mess.
> 
> > So given that SPL must be upgradable, how is it more complex to detect
> > U-Boot failure from SPL than from U-Boot itself?
> 
> I do not get the question - if SPL fails, it can be at any time before
> you get the control. There sould be a mechanism to switch to a previous
> copy of SPL, generally this is not available in hw.
> 
> 
> Unless I'm mistaken, the socfpga gen5 bootrom implements a timer and
> loads SPL from secondary storage of it does not register as successful
> after some time.

That means you *have* hardware support, then.

I am not aware there is such as feature on i.MX6.

> 
> That's my arch only, of course...

Regards,
Stefano


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

Re: [U-Boot] UBoot running UBoot - is it possible?

[Simon Goldschmidt]

Am Di., 13. Nov. 2018, 17:53 hat Stefano Babic  geschrieben:

> On 13/11/18 17:07, Simon Goldschmidt wrote:
> > On 13.11.2018 17:00, Wolfgang Denk wrote:
> >> Dear Simon,
> >>
> >> In message
> >> 
> >> you wrote:
> >>> My idea was to let SPL implement a dedicated boot counter/watchdog
> >>> that detects problems starting U-Boot and using a backup copy if it
> >>> fails multiple times. Of course you need an SPL on your board to do
> >>> this. Plus you end up with the same problem for updating SPL, but I'm
> >>> lucky here that my platform (socfpga gen5) has redundant storage for
> >>> SPL and implements a startup watchdog mechanism for the SPL.
> >> In other words, you are just adding enough additional complexity to
> >> SPL to make it reasonably likely that there will be bugs that need
> >> to be fixed later, i. e. you have to update the SPL.
> >>
> >> And then?
> >>
> >> You are just moving the problem, not solving it.
> >
> > That's not how I see it. As I see it, I have to implement an upgrade
> > option for SPL. This is partly due to bad design of the socfpga_gen5
> > platform. But also I have read multiple times on this list that you
> > should use SPL from the same version as U-Boot as they might work
> > combined and U-Boot might depend on SPL to do things that might change
> > over time.
>
> Right. It is not guaranteed that mixing versions works.
>
> > So is it really a good idea to upgrade U-Boot without
> > upgrading SPL at the same time?
>
> IMHO it is a bad idea, and it forgets that the bootloader is really SPL
> + u-boot.img else just u-boot.img. It is also questionable if it makes
> sense to provide an update mechanism for u-boot when most of critical
> parts like clocks, DDR initialisation, etc. are in SPL.
>
> > It seems to me this would require
> > thorough testing of different version mixes...
> >
>
> Agree, and this becomes a mess.
>
> > So given that SPL must be upgradable, how is it more complex to detect
> > U-Boot failure from SPL than from U-Boot itself?
>
> I do not get the question - if SPL fails, it can be at any time before
> you get the control. There sould be a mechanism to switch to a previous
> copy of SPL, generally this is not available in hw.
>

Unless I'm mistaken, the socfpga gen5 bootrom implements a timer and loads
SPL from secondary storage of it does not register as successful after some
time.

That's my arch only, of course...

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

Re: [U-Boot] UBoot running UBoot - is it possible?

[Stefano Babic]

On 13/11/18 17:07, Simon Goldschmidt wrote:
> On 13.11.2018 17:00, Wolfgang Denk wrote:
>> Dear Simon,
>>
>> In message
>> 
>> you wrote:
>>> My idea was to let SPL implement a dedicated boot counter/watchdog
>>> that detects problems starting U-Boot and using a backup copy if it
>>> fails multiple times. Of course you need an SPL on your board to do
>>> this. Plus you end up with the same problem for updating SPL, but I'm
>>> lucky here that my platform (socfpga gen5) has redundant storage for
>>> SPL and implements a startup watchdog mechanism for the SPL.
>> In other words, you are just adding enough additional complexity to
>> SPL to make it reasonably likely that there will be bugs that need
>> to be fixed later, i. e. you have to update the SPL.
>>
>> And then?
>>
>> You are just moving the problem, not solving it.
> 
> That's not how I see it. As I see it, I have to implement an upgrade
> option for SPL. This is partly due to bad design of the socfpga_gen5
> platform. But also I have read multiple times on this list that you
> should use SPL from the same version as U-Boot as they might work
> combined and U-Boot might depend on SPL to do things that might change
> over time.

Right. It is not guaranteed that mixing versions works.

> So is it really a good idea to upgrade U-Boot without
> upgrading SPL at the same time?

IMHO it is a bad idea, and it forgets that the bootloader is really SPL
+ u-boot.img else just u-boot.img. It is also questionable if it makes
sense to provide an update mechanism for u-boot when most of critical
parts like clocks, DDR initialisation, etc. are in SPL.

> It seems to me this would require
> thorough testing of different version mixes...
> 

Agree, and this becomes a mess.

> So given that SPL must be upgradable, how is it more complex to detect
> U-Boot failure from SPL than from U-Boot itself?

I do not get the question - if SPL fails, it can be at any time before
you get the control. There sould be a mechanism to switch to a previous
copy of SPL, generally this is not available in hw.

Best regards,
Stefano

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

Re: [U-Boot] [PATCH] sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCD

[Jagan Teki]

On Tue, Nov 13, 2018 at 10:11 PM Vasily Khoruzhick  wrote:
>
> On Tue, Nov 13, 2018 at 8:32 AM Jagan Teki  wrote:
> >
> > On Mon, Oct 29, 2018 at 2:08 PM Maxime Ripard  
> > wrote:
> > >
> > > On Sun, Oct 28, 2018 at 02:26:12PM -0700, Vasily Khoruzhick wrote:
> > > > From: Icenowy Zheng 
> > > >
> > > > DE2 SoCs can support LCDs up to 1080p (e.g. A64), and 3MHz step won't
> > > > let PLL_VIDEO be high enough for them.
> > > >
> > > > Use 6MHz step for PLL_VIDEO when using DE2, to satisfy 1080p LCD.
> > > >
> > > > Signed-off-by: Icenowy Zheng 
> > > > Signed-off-by: Vasily Khoruzhick 
> > > > Tested-by: Vasily Khoruzhick 
> > >
> > > I wonder if this will cause any issues with panels and lower
> > > resolutions that will have a smaller tolerancy.
> >
> > Does it impact lower resolution panels? is it tested?
>
> It works fine with 1366x768 panel, and I don't have any other panels
> that work in u-boot to test. And correct me if I'm wrong but I don't
> think that we have any boards with DE2 and low-res panel supported in
> u-boot.

ie what I wonder too, if we have any thing similar for DE2. anyway

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

Re: [U-Boot] [PATCH 2/2] board: allwinner: sun50i-h6: Add Orangepi Lite2 support

[Jagan Teki]

On Mon, Nov 5, 2018 at 8:57 PM Maxime Ripard  wrote:
>
> On Mon, Nov 05, 2018 at 01:20:40PM +0530, Jagan Teki wrote:
> > OrangePi Lite2 is Allwinner H6 based open-source SBC,
> > which support:
> > - Allwinner H6 Quad-core 64-bit ARM Cortex-A53
> > - GPU Mali-T720
> > - 1GB LPDDR3 RAM
> > - AXP805 PMIC
> > - AP6356S Wifi/BT
> > - USB 2.0, USB 3.0 Host, OTG
> > - HDMI port
> > - 5V/2A DC power supply
> >
> > Signed-off-by: Jagan Teki 
>
> For both patches,
> Acked-by: Maxime Ripard 

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