Re: [U-Boot] [PATCH 2/5] x86: efi_loader: Build EFI memory map per E820 table

2018-06-24 Thread Heinrich Schuchardt
On 06/23/2018 12:03 PM, Bin Meng wrote:
> On x86 traditional E820 table is used to pass the memory information
> to kernel. With EFI loader we can build the EFI memory map from it.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  arch/x86/lib/e820.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c
> index 9a9ec99..8b34f67 100644
> --- a/arch/x86/lib/e820.c
> +++ b/arch/x86/lib/e820.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -34,3 +35,41 @@ __weak unsigned int install_e820_map(unsigned int 
> max_entries,
>  
>   return 4;
>  }
> +
> +#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)
> +void efi_add_known_memory(void)
> +{
> + struct e820_entry e820[E820MAX];
> + unsigned int i, num;
> + u64 start, pages;
> + int type;
> +
> + num = install_e820_map(ARRAY_SIZE(e820), e820);

Thanks for the patch. Not handling the E820 table is a known deficiency
of our EFI implementation.

I am a bit worried about error handling here.

What guarantees that lib_sysinfo.n_memranges <= E820MAX?

install_e820_map() prints a message if max_entries is too small but it
does not return an error code.

So only if num < E820MAX we can be sure that the call returned all
information of interest.

My idea is that the interface of efi_add_known_memory() should be
changed to allow returning an error code if it fails. And
efi_memory_init() should return an eventual error to board_init_r().

Best regards

Heinrich

> +
> + for (i = 0; i < num; ++i) {
> + start = e820[i].addr;
> + pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT;
> +
> + switch (e820[i].type) {
> + case E820_RAM:
> + type = EFI_CONVENTIONAL_MEMORY;
> + break;
> + case E820_RESERVED:
> + type = EFI_RESERVED_MEMORY_TYPE;
> + break;
> + case E820_ACPI:
> + type = EFI_ACPI_RECLAIM_MEMORY;
> + break;
> + case E820_NVS:
> + type = EFI_ACPI_MEMORY_NVS;
> + break;
> + case E820_UNUSABLE:
> + default:
> + type = EFI_UNUSABLE_MEMORY;
> + break;
> + }
> +
> + efi_add_memory_map(start, pages, type, false);
> + }
> +}
> +#endif /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
> 

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


Re: [U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables

2018-06-24 Thread Heinrich Schuchardt
/On 06/23/2018 12:03 PM, Bin Meng wrote:
> ACPI tables can be passed via EFI configuration table to an EFI
> application. This is only supported on x86 so far.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  cmd/bootefi.c |  5 +
>  include/efi_api.h |  8 
>  include/efi_loader.h  |  8 
>  lib/efi_loader/Makefile   |  1 +
>  lib/efi_loader/efi_acpi.c | 42 ++
>  5 files changed, 64 insertions(+)
>  create mode 100644 lib/efi_loader/efi_acpi.c
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index f55a40d..cd755b6 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -61,6 +61,11 @@ efi_status_t efi_init_obj_list(void)
>   if (ret != EFI_SUCCESS)
>   goto out;
>  #endif
> +#ifdef CONFIG_GENERATE_ACPI_TABLE
> + ret = efi_acpi_register();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +#endif
>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>   ret = efi_smbios_register();
>   if (ret != EFI_SUCCESS)
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 094be6e..69dcbac 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -286,6 +286,14 @@ struct efi_runtime_services {
>   EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
>0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>  
> +#define ACPI_TABLE_GUID \
> + EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, \
> +  0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> +
> +#define ACPI_20_TABLE_GUID \
> + EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, \
> +  0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
> +
>  struct efi_configuration_table
>  {
>   efi_guid_t guid;
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c66252a..d837e7b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -215,6 +215,14 @@ efi_status_t efi_net_register(void);
>  efi_status_t efi_watchdog_register(void);
>  /* Called by bootefi to make SMBIOS tables available */
>  /**
> + * efi_acpi_register() - write out ACPI tables
> + *
> + * Called by bootefi to make ACPI tables available
> + *
> + * @return 0 if OK, -ENOMEM if no memory is available for the tables
> + */
> +efi_status_t efi_acpi_register(void);
> +/**
>   * efi_smbios_register() - write out SMBIOS tables
>   *
>   * Called by bootefi to make SMBIOS tables available
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index c6046e3..d6402c4 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -22,4 +22,5 @@ obj-$(CONFIG_LCD) += efi_gop.o
>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>  obj-$(CONFIG_NET) += efi_net.o
> +obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
>  obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
> diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
> new file mode 100644
> index 000..b09292c
> --- /dev/null
> +++ b/lib/efi_loader/efi_acpi.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + *  EFI application ACPI tables support
> + *
> + *  Copyright (C) 2018, Bin Meng 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +static const efi_guid_t acpi_guid = ACPI_20_TABLE_GUID;
> +
> +/*
> + * Install the ACPI table as a configuration table.
> + *
> + * @return   status code
> + */
> +efi_status_t efi_acpi_register(void)
> +{
> + /* Map within the low 32 bits, to allow for 32bit ACPI tables */
> + u64 acpi = U32_MAX;
> + efi_status_t ret;
> +
> + /* Reserve 64kiB page for ACPI */
> + ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> +  EFI_RUNTIME_SERVICES_DATA, 16, &acpi);
> + if (ret != EFI_SUCCESS)
> + return ret;
> +
> + /*
> +  * Generate ACPI tables - we know that efi_allocate_pages() returns
> +  * a 4k-aligned address, so it is safe to assume that
> +  * write_acpi_tables() will write the table at that address.
> +  */
> + assert(!(acpi & 0xf));
> + write_acpi_tables(acpi);
> +
> + /* And expose them to our EFI payload */
> + return efi_install_configuration_table(&acpi_guid,
> +(void *)(uintptr_t)acpi);

The maximum number of configuration tables is currently hard coded as 2
in efi_boottime.c. I think this limit should be raised. 16 seems
reasonable looking at which tables the Linux EFI stub or iPXE can process.

In lib/efi_loader/helloworld.c we output the installed configuration
tables. Please, add the ACPI 2.0 table there too. This will allow future
testing in Travis CI.

Best regards

Heinrich

> +}
> 

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


Re: [U-Boot] [PATCH] imx: mx6: Fix implementantion reset_misc

2018-06-24 Thread Peng Fan


> -Original Message-
> From: Michael Trimarchi [mailto:mich...@amarulasolutions.com]
> Sent: 2018年6月21日 5:28
> To: Stefano Babic 
> Cc: Fabio Estevam ; Albert Aribaud
> ; Peng Fan ; Sébastien
> Szymanski ; u-boot@lists.denx.de
> Subject: [PATCH] imx: mx6: Fix implementantion reset_misc
> 
> lcdif_power_down should not be included in spl build to avoid build failure
> introduced by commit eb111bb31d882877e75e6b8083808dcaf6493b92
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  arch/arm/mach-imx/mx6/soc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> index e8b6f77..ffc2951 100644
> --- a/arch/arm/mach-imx/mx6/soc.c
> +++ b/arch/arm/mach-imx/mx6/soc.c
> @@ -548,9 +548,11 @@ const struct boot_mode soc_boot_modes[] = {
> 
>  void reset_misc(void)
>  {
> +#ifndef CONFIG_SPL_BUILD
>  #ifdef CONFIG_VIDEO_MXS
>   lcdif_power_down();
>  #endif
> +#endif

Reviewed-by: Peng Fan 

>  }
> 
>  void s_init(void)
> --
> 2.7.4

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


Re: [U-Boot] [PATCH 2/3] spi: mxc_spi: Fix chipselect on DM_SPI driver uclass

2018-06-24 Thread Peng Fan


> -Original Message-
> From: Michael Trimarchi [mailto:mich...@amarulasolutions.com]
> Sent: 2018年6月21日 4:51
> To: Jagan Teki 
> Cc: Stefano Babic ; Peng Fan ;
> shyam.sa...@amarulasolutions.com; u-boot@lists.denx.de
> Subject: [PATCH 2/3] spi: mxc_spi: Fix chipselect on DM_SPI driver uclass
> 
> CS GPIO activation low/high is determinated by the device tree so we don't
> need to take in accoung in cs_activate and cs_deactivate

Yes.

> 
> Signed-off-by: Michael Trimarchi 
> ---
>  drivers/spi/mxc_spi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 
> fcb214a..0dccc38
> 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -60,7 +60,7 @@ static inline struct mxc_spi_slave
> *to_mxc_spi_slave(struct spi_slave *slave)  static void
> mxc_spi_cs_activate(struct mxc_spi_slave *mxcs)  {
>   if (CONFIG_IS_ENABLED(DM_SPI)) {
> - dm_gpio_set_value(&mxcs->ss, mxcs->ss_pol);
> + dm_gpio_set_value(&mxcs->ss, 1);
>   } else {
>   if (mxcs->gpio > 0)
>   gpio_set_value(mxcs->gpio, mxcs->ss_pol); @@ -70,7 
> +70,7 @@
> static void mxc_spi_cs_activate(struct mxc_spi_slave *mxcs)  static void
> mxc_spi_cs_deactivate(struct mxc_spi_slave *mxcs)  {
>   if (CONFIG_IS_ENABLED(DM_SPI)) {
> - dm_gpio_set_value(&mxcs->ss, !(mxcs->ss_pol));
> + dm_gpio_set_value(&mxcs->ss, 0);
>   } else {
>   if (mxcs->gpio > 0)
>   gpio_set_value(mxcs->gpio, !(mxcs->ss_pol)); @@ -508,7 
> +508,7
> @@ static int mxc_spi_probe(struct udevice *bus)
>   if (plat->base == FDT_ADDR_T_NONE)
>   return -ENODEV;
> 
> - ret = dm_gpio_set_value(&plat->ss, !(mxcs->ss_pol));
> + ret = dm_gpio_set_value(&plat->ss, 0);
>   if (ret) {
>   dev_err(bus, "Setting cs error\n");
>   return ret;
> --

Reviewed-by: Peng Fan 

> 2.7.4

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


Re: [U-Boot] [PATCH 1/3] spi: mxc: Fix compilation problem of DM_SPI class driver

2018-06-24 Thread Peng Fan


> -Original Message-
> From: Michael Trimarchi [mailto:mich...@amarulasolutions.com]
> Sent: 2018年6月21日 4:51
> To: Jagan Teki 
> Cc: Stefano Babic ; Peng Fan ;
> shyam.sa...@amarulasolutions.com; u-boot@lists.denx.de
> Subject: [PATCH 1/3] spi: mxc: Fix compilation problem of DM_SPI class driver
> 
> drivers/spi/mxc_spi.c:507: undefined reference to `dev_get_addr'
> linux-ld.bfd: BFD (GNU Binutils) 2.29.1 assertion fail elf32-arm.c:9509
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  drivers/spi/mxc_spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 
> b77129c..fcb214a
> 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -504,7 +504,7 @@ static int mxc_spi_probe(struct udevice *bus)
>   return -EINVAL;
>   }
> 
> - plat->base = dev_get_addr(bus);
> + plat->base = devfdt_get_addr(bus);
>   if (plat->base == FDT_ADDR_T_NONE)
>   return -ENODEV;

Reviewed-by: Peng Fan 
> 
> --
> 2.7.4

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


Re: [U-Boot] [PATCH 3/3] spi: mxc_spi: Fix spi mode communication where clock is inverted

2018-06-24 Thread Peng Fan


> -Original Message-
> From: Michael Trimarchi [mailto:mich...@amarulasolutions.com]
> Sent: 2018年6月21日 4:51
> To: Jagan Teki 
> Cc: Stefano Babic ; Peng Fan ;
> shyam.sa...@amarulasolutions.com; u-boot@lists.denx.de
> Subject: [PATCH 3/3] spi: mxc_spi: Fix spi mode communication where clock is
> inverted
> 
> During spi initialization logic creates a glitch on the clock and if this is 
> followed
> by the chip select this can be interpretated as clock. Add a delay let the 
> glitch
> out of chip select

I did not see issue. What issue do you see and which platform? Adding a delay 
here seems hacky which
forces all SoC using this driver needs a delay.
 
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  drivers/spi/mxc_spi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 
> 0dccc38..d450f16
> 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -387,6 +387,7 @@ static int mxc_spi_claim_bus_internal(struct
> mxc_spi_slave *mxcs, int cs)
>   }
>   reg_write(®s->period, MXC_CSPIPERIOD_32KHZ);
>   reg_write(®s->intr, 0);
> + udelay(50);
> 
>   return 0;
>  }
> --
> 2.7.4

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


Re: [U-Boot] [PATCH v3 0/4] rk3288: veyron: Enable SDMMC when booting from SPI

2018-06-24 Thread Carlo Caione
On Mon, 2018-06-11 at 20:00 +0100, Carlo Caione wrote:
> From: Carlo Caione 
> 
> These patches toghether with the previously submitted patch [0]
> enable
> the chromebook veyron jerry to use the SDMMC interface when U-Boot is
> not chainloaded by depthcharge but booted directly from SPI.
> 
> [0] https://marc.info/?l=u-boot&m=152836928803742&w=2

Hey Philipp,
any comment on this v3?

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


[U-Boot] [PATCH] arm: imx7d: cl-som-imx7: sf: support all SF types

2018-06-24 Thread Yaniv Levinsky
From: Uri Mashiach 

Enable the support for all SPI flash types.

Signed-off-by: Uri Mashiach 
Signed-off-by: Yaniv Levinsky 
---
 configs/cl-som-imx7_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/cl-som-imx7_defconfig b/configs/cl-som-imx7_defconfig
index 6d403eed7a..8692241029 100644
--- a/configs/cl-som-imx7_defconfig
+++ b/configs/cl-som-imx7_defconfig
@@ -47,7 +47,14 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_USB=y
-- 
2.17.1

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


[U-Boot] [PATCH 0/4] fix propagation of flags from do_env_default()

2018-06-24 Thread Yaniv Levinsky
The function do_env_default() doesn't propagate flags to himport_r(). It causes
the "-f" option to have no effect on the execution of "env default" commands.

Fix the call paths from do_env_default() to himport_r() to pass flags correctly.

Yaniv Levinsky (4):
  cmd: nvedit: rename flags in do_env_default
  cmd: nvedit: propagate envflag to set_default_vars
  cmd: nvedit: set H_INTERACTIVE in do_env_default
  env: common: accept flags on reset to default env

 arch/arm/mach-imx/mx6/opos6ul.c |  2 +-
 cmd/nvedit.c| 11 ++-
 common/board_r.c|  2 +-
 common/spl/spl_dfu.c|  2 +-
 env/common.c| 27 ---
 env/ext4.c  |  2 +-
 env/fat.c   |  2 +-
 env/mmc.c   | 12 ++--
 env/nand.c  |  6 +++---
 env/sata.c  |  2 +-
 env/sf.c| 10 +-
 env/ubi.c   |  6 +++---
 include/environment.h   |  4 ++--
 13 files changed, 43 insertions(+), 45 deletions(-)

-- 
2.17.1

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


[U-Boot] [PATCH 1/4] cmd: nvedit: rename flags in do_env_default

2018-06-24 Thread Yaniv Levinsky
The naming convention for flags in nvedit.c is:
* The hashtable flag (defined in search.h) is named "env_flag"
* The command flag argument (defined in command.h) is named "flag"

This convention is kept in functions like do_env_print(), do_env_set()
and do_env_delete(), but not in do_env_default().

Rename the hashtable flag in do_env_default() from "flag" to "env_flag".
Rename the command flag in do_env_default() from "__flag" to "flag".

No functional change.

Signed-off-by: Yaniv Levinsky 
Reviewed-by: Igor Grinberg 
---
 cmd/nvedit.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index ddc888a4fd..d456d2fc9b 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -777,10 +777,10 @@ int envmatch(uchar *s1, int i2)
 }
 
 #ifndef CONFIG_SPL_BUILD
-static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
+static int do_env_default(cmd_tbl_t *cmdtp, int flag,
  int argc, char * const argv[])
 {
-   int all = 0, flag = 0;
+   int all = 0, env_flag = 0;
 
debug("Initial value for argc=%d\n", argc);
while (--argc > 0 && **++argv == '-') {
@@ -792,7 +792,7 @@ static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
all = 1;
break;
case 'f':   /* force */
-   flag |= H_FORCE;
+   env_flag |= H_FORCE;
break;
default:
return cmd_usage(cmdtp);
-- 
2.17.1

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


[U-Boot] [PATCH 2/4] cmd: nvedit: propagate envflag to set_default_vars

2018-06-24 Thread Yaniv Levinsky
The env_flag in do_env_default() doesn't get propagated and therefore
gets ignored by himport_r(). This breaks to ability to "forcibly" reset
variables to their default values using the environment command.

Scenario example of the problem:
# setenv kernel uImage
# setenv .flags kernel:so
# env default -f kernel
## Error: Can't overwrite "kernel"
himport_r: can't insert "kernel=zImage" into hash table

Change the call path so it will pass the flag correctly.

Signed-off-by: Yaniv Levinsky 
Acked-by: Igor Grinberg 
---
 cmd/nvedit.c  | 2 +-
 env/common.c  | 5 +++--
 include/environment.h | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index d456d2fc9b..1955dee0d0 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -807,7 +807,7 @@ static int do_env_default(cmd_tbl_t *cmdtp, int flag,
}
if (!all && (argc > 0)) {
/* Reset individual variables */
-   set_default_vars(argc, argv);
+   set_default_vars(argc, argv, env_flag);
return 0;
}
 
diff --git a/env/common.c b/env/common.c
index dc8a14f519..6cf5eddaf6 100644
--- a/env/common.c
+++ b/env/common.c
@@ -91,15 +91,16 @@ void set_default_env(const char *s)
 
 
 /* [re]set individual variables to their value in the default environment */
-int set_default_vars(int nvars, char * const vars[])
+int set_default_vars(int nvars, char * const vars[], int flags)
 {
/*
 * Special use-case: import from default environment
 * (and use \0 as a separator)
 */
+   flags |= H_NOCLEAR | H_INTERACTIVE;
return himport_r(&env_htab, (const char *)default_environment,
sizeof(default_environment), '\0',
-   H_NOCLEAR | H_INTERACTIVE, 0, nvars, vars);
+   flags, 0, nvars, vars);
 }
 
 /*
diff --git a/include/environment.h b/include/environment.h
index 70b7eda428..2fe1f3eb48 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -275,7 +275,7 @@ char *env_get_default(const char *name);
 void set_default_env(const char *s);
 
 /* [re]set individual variables to their value in the default environment */
-int set_default_vars(int nvars, char * const vars[]);
+int set_default_vars(int nvars, char * const vars[], int flags);
 
 /* Import from binary representation into hash table */
 int env_import(const char *buf, int check);
-- 
2.17.1

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


[U-Boot] [PATCH 4/4] env: common: accept flags on reset to default env

2018-06-24 Thread Yaniv Levinsky
The function set_default_env() sets the hashtable flags for import_r().
Formally set_default_env() doesn't accept flags from its callers. In
practice the caller can (un)set the H_INTERACTIVE flag, but it has to be
done using the first character of the function's string argument. Other
flags like H_FORCE can't be set by the caller.

Change the function to accept flags argument. The benefits are:
1. The caller will have to explicitly set the H_INTERACTIVE flag,
   instead of un-setting it using a special char in a string.
2. Add the ability to propagate flags from the caller to himport(),
   especially the H_FORCE flag from do_env_default() in nvedit.c that
   currently gets ignored for "env default -a -f" commands.
3. Flags and messages will not be coupled together. A caller will be
   able to set flags without passing a string and vice versa.

Please note:
The propagation of H_FORCE from do_env_default() does not introduce any
functional changes, because currently himport_r() is set to destroy the
old environment regardless if H_FORCE flag is set or not. More changes
are needed to utilize the propagation of H_FORCE.

Signed-off-by: Yaniv Levinsky 
Acked-by: Igor Grinberg 
---
 arch/arm/mach-imx/mx6/opos6ul.c |  2 +-
 cmd/nvedit.c|  3 ++-
 common/board_r.c|  2 +-
 common/spl/spl_dfu.c|  2 +-
 env/common.c| 22 +-
 env/ext4.c  |  2 +-
 env/fat.c   |  2 +-
 env/mmc.c   | 12 ++--
 env/nand.c  |  6 +++---
 env/sata.c  |  2 +-
 env/sf.c| 10 +-
 env/ubi.c   |  6 +++---
 include/environment.h   |  2 +-
 13 files changed, 35 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/opos6ul.c b/arch/arm/mach-imx/mx6/opos6ul.c
index af3384d10e..94a3d71201 100644
--- a/arch/arm/mach-imx/mx6/opos6ul.c
+++ b/arch/arm/mach-imx/mx6/opos6ul.c
@@ -127,7 +127,7 @@ int board_late_init(void)
 
/* In bootstrap don't use the env vars */
if (((reg & 0x300) >> 24) == 0x1) {
-   set_default_env(NULL);
+   set_default_env(NULL, 0);
env_set("preboot", "");
}
 
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 8b73c606ca..796867c62c 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -802,7 +802,8 @@ static int do_env_default(cmd_tbl_t *cmdtp, int flag,
debug("Final value for argc=%d\n", argc);
if (all && (argc == 0)) {
/* Reset the whole environment */
-   set_default_env("## Resetting to default environment\n");
+   set_default_env("## Resetting to default environment\n",
+   env_flag);
return 0;
}
if (!all && (argc > 0)) {
diff --git a/common/board_r.c b/common/board_r.c
index 6b297068bd..8495777953 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -454,7 +454,7 @@ static int initr_env(void)
if (should_load_env())
env_relocate();
else
-   set_default_env(NULL);
+   set_default_env(NULL, 0);
 #ifdef CONFIG_OF_CONTROL
env_set_addr("fdtcontroladdr", gd->fdt_blob);
 #endif
diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c
index b8e3a6c89e..01178f611f 100644
--- a/common/spl/spl_dfu.c
+++ b/common/spl/spl_dfu.c
@@ -38,7 +38,7 @@ int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char 
*interface, char *devstr)
int ret;
 
/* set default environment */
-   set_default_env(0);
+   set_default_env(NULL, 0);
str_env = env_get(dfu_alt_info);
if (!str_env) {
pr_err("\"dfu_alt_info\" env variable not defined!\n");
diff --git a/env/common.c b/env/common.c
index 05183a4af0..1430100c85 100644
--- a/env/common.c
+++ b/env/common.c
@@ -58,22 +58,18 @@ char *env_get_default(const char *name)
return ret_val;
 }
 
-void set_default_env(const char *s)
+void set_default_env(const char *s, int flags)
 {
-   int flags = 0;
-
if (sizeof(default_environment) > ENV_SIZE) {
puts("*** Error - default environment is too large\n\n");
return;
}
 
if (s) {
-   if (*s == '!') {
+   if ((flags & H_INTERACTIVE) == 0) {
printf("*** Warning - %s, "
-   "using default environment\n\n",
-   s + 1);
+   "using default environment\n\n", s);
} else {
-   flags = H_INTERACTIVE;
puts(s);
}
} else {
@@ -117,7 +113,7 @@ int env_import(const char *buf, int check)
memcpy(&crc, &ep->crc, sizeof(crc));
 
if (crc32(0, ep->data, ENV_SIZE) != crc) {
-   set_default_env("!bad CRC");
+

[U-Boot] [PATCH 3/4] cmd: nvedit: set H_INTERACTIVE in do_env_default

2018-06-24 Thread Yaniv Levinsky
The function set_default_vars() in common.c adds H_INTERACTIVE to the
h_import() flag, but the function has no way of telling if the command
actually was user directed like this flag suggest. The flag should be
set by the calling function do_env_default() in nvedit.c instead, where
the command is certainty user directed.

Move the H_INTERACTIVE flag from set_default_vars() to do_env_default().

Signed-off-by: Yaniv Levinsky 
Acked-by: Igor Grinberg 
---
 cmd/nvedit.c | 2 +-
 env/common.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 1955dee0d0..8b73c606ca 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -780,7 +780,7 @@ int envmatch(uchar *s1, int i2)
 static int do_env_default(cmd_tbl_t *cmdtp, int flag,
  int argc, char * const argv[])
 {
-   int all = 0, env_flag = 0;
+   int all = 0, env_flag = H_INTERACTIVE;
 
debug("Initial value for argc=%d\n", argc);
while (--argc > 0 && **++argv == '-') {
diff --git a/env/common.c b/env/common.c
index 6cf5eddaf6..05183a4af0 100644
--- a/env/common.c
+++ b/env/common.c
@@ -97,7 +97,7 @@ int set_default_vars(int nvars, char * const vars[], int 
flags)
 * Special use-case: import from default environment
 * (and use \0 as a separator)
 */
-   flags |= H_NOCLEAR | H_INTERACTIVE;
+   flags |= H_NOCLEAR;
return himport_r(&env_htab, (const char *)default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
-- 
2.17.1

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


Re: [U-Boot] [PATCH 1/2] imx: imx6: Add comment to gpr_init function

2018-06-24 Thread Jagan Teki
On Sat, Jun 23, 2018 at 7:40 PM, Michael Trimarchi
 wrote:
> This function can be used only for some of the nxp SoC. Make
> it explicit in the comment. This adjust a bit commit
> 3aa4b703b483f165dd ("imx: imx6: Move gpr_init() function to soc.c")
>
> Signed-off-by: Michael Trimarchi 
> ---
>  arch/arm/mach-imx/mx6/soc.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> index e8b6f77..2c87c6e 100644
> --- a/arch/arm/mach-imx/mx6/soc.c
> +++ b/arch/arm/mach-imx/mx6/soc.c
> @@ -649,6 +649,11 @@ void imx_setup_hdmi(void)
>  }
>  #endif
>
> +
> +/*
> + * gpr_init() function is common for boards using MX6S, MX6DL, MX6D,
> + * MX6Q and MX6QP processors
> + */
>  void gpr_init(void)
>  {
> struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
> --

May be adding ifdef !imx6ul on the code also make sense.

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


Re: [U-Boot] [PATCH 2/2] i.MX6: engicam: gpr_init can be called only for some architecture

2018-06-24 Thread Jagan Teki
On Sat, Jun 23, 2018 at 7:40 PM, Michael Trimarchi
 wrote:
> Fix an invalid usage of the gpr_init function for the imx6ul
> architecture
>
> Signed-off-by: Michael Trimarchi 
> ---
>  board/engicam/common/spl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/engicam/common/spl.c b/board/engicam/common/spl.c
> index 470d96a..69d1c11 100644
> --- a/board/engicam/common/spl.c
> +++ b/board/engicam/common/spl.c
> @@ -410,7 +410,8 @@ void board_init_f(ulong dummy)
> /* setup AIPS and disable watchdog */
> arch_cpu_init();
>
> -   gpr_init();
> +   if (!(is_mx6ul()))
> +   gpr_init();

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


Re: [U-Boot] Logo for U-Boot

2018-06-24 Thread Simon Glass
Hi Heinrich,

On 11 June 2018 at 09:54, Heinrich Schuchardt  wrote:
> On 06/11/2018 03:03 PM, Tom Rini wrote:
>> On Sat, Jun 09, 2018 at 10:21:53PM +0200, Heinrich Schuchardt wrote:
>>> On 06/09/2018 07:34 PM, Simon Glass wrote:
 Hi,

 On 6 May 2018 at 12:31, Tom Rini  wrote:
> On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote:
>
>> On 06.05.18 18:02, Heinrich Schuchardt wrote:
>>> On 05/04/2018 11:18 AM, Marek Vasut wrote:
 On 05/04/2018 08:46 AM, Alexander Graf wrote:
> On 05/04/2018 01:04 AM, Marek Vasut wrote:
>> On 05/03/2018 11:57 PM, Alexander Graf wrote:
>>>
>>> On 01.05.18 04:09, Marek Vasut wrote:
 On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
> U-Boot has currently no logo that we can use in presentations.
>
> On the U-Boot IRC channel the following propositions where made:
>
> Source:
> https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
> License: GPL2+
> (Alex used this in some presentations.)
 Yellow submarine, nice.

 Maybe we should make it a bit more toward teal and orange to 
 improve
 the
 contrast ? Although, maybe just replacing the depressive gray
 background
 with a light blue one would do.
>>> How about this?
>>>
>>>http://csgraf.de/tmp2/uboot.svg
>> Lacks the teal.
>
>
> I don't want teal :)

 Without teal, the contrast of the image isn't good enough.

 And I think you might want to check with more people, since clearly 
 it's
 just the two of us discussing it now :)
>>> Find Marek's darling appended
>
> It's a little hard to quote things inline like this.  But, did you
> create your own image inspired by the wikimedia one?  I ask because the
> wikimedia one is GPLv2 or later, but an original one that we could dual
> license (for both a new framebuffer logo, and for printed materials,
> etc, where a CC license works better) would be good.
>
>> I tend to agree that it looks nice :).
>>
>> It may mean we need a new web design too though, as the colors in the
>> logo probably don't work terribly well with the current blue.
>
> We can worry about that later.

 I think the logo as here is fine:

 https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg
>>>
>>> This logo was GPLv2+. Tom, didn't you say we needed something with
>>> creative commons license?
>>
>> So, while I'm Not A Lawyer(TM), there is a reason lawyers have made
>> licenses that are still "open source" but for other things.  One of the
>> uses of a logo is to be printed.  What on earth does GPLv2 (or later)
>> compliance look like for a brochure or a t-shirt?  That's not the
>> (usual) spirit behind why you would put a license like that on a thing
>> like this.  This is why currently projects use one of the Creative
>> Commons 4.0 licenses for images, hardware design, etc.
>>
>> And further pushing my "not a lawyer", it's generally accepted that you
>> can go from CC-4.0 to GPLv3 (or later), you can't go the other
>> direction.  And I'd also really rather not put people that want to use
>> our logo in the position of worrying about what GPLv2 compliance on an
>> image looks like (as it's not clear), I'm strongly in favor of a CC'd
>> image.
>>
>> If anyone can contact the actual author of the wikimedia image (it's not
>> the person that uploaded it, I dug that far) and have them agree to
>> re-license as CC, I'd be happy to go that route.  Thanks!
>>
>
> I have raised that question on:
>
> https://commons.wikimedia.org/wiki/User_talk:CFCF#Circle-icons-submarine.svg

It looks like the answer was not what you needed, or perhaps I am
reading it incorrectly?

Here are two versions, both with 'U-Boot' text inside the logo. I
think this is important since otherwise the logo could be for
anything.

https://drive.google.com/open?id=1TdX0JS_Zr6ZGtUt6F-6y8rUv2Hq2QlOp

https://drive.google.com/open?id=1UxMY67es8OGIDMST-3G0Pc0aTjbasxTY

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


[U-Boot] Size of FDT image

2018-06-24 Thread Yousf Ateya
Dears,

I am calculating images check-sum in common/bootm.c (in function
do_bootm_states
)
for security reasons. I am using contents of images structure to do so.
Code is similar to this:

int os_cs = checksum(images.os.image_start, images.os.image_len); //Always
> consistent
> int initrd_cs = checksum(images.initrd_start, images.initrd_end -
> images.initrd_start); //Always consistent
> int ft_cs = checksum(images.ft_addr, images.ft_len); //Changes after power
> reset
>
> printf("Checksums: OS %d, initrd %d, FTD %d\n", os_cs, initrd_cs, ft_cs);
>


Both OS, and initrd images are working perfectly. FDT image checksum is the
same through software reboots, but it changes after power reset (fully
remove power, and connect power again); Which makes me suspect garbage data
at end of images.ft_addr.

I tried to do partial checksum for FTD image (only 80% of its size)

int ft_cs = checksum(images.ft_addr, images.ft_len * 0.8); //Always
> consistent
>

Then checksum worked perfectly through power resets. But it is not good
idea to check-sum part of image only.

I think there is unused area at the end of image length that changes in
power resets.

Is there a way to get actual FDT image length?

Using version v2017.11


-- 
This e-mail message is intended only for the use of the intended 
recipient(s).
The information contained therein may be confidential or 
privileged,
and its disclosure or reproduction is strictly prohibited.
If 
you are not the intended recipient, please return it immediately to its 
sender 
at the above address and destroy it. 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 4/5] imx: mx7: psci: support CPU0 on/off

2018-06-24 Thread Stefan Agner
From: Stefan Agner 

So far psci_cpu_(on|off) only worked for CPU1. Allow to control
CPU0 too. This allows to run the Linux PSCI checker successfully:
  [2.213447] psci_checker: PSCI checker started using 2 CPUs
  [2.219107] psci_checker: Starting hotplug tests
  [2.223859] psci_checker: Trying to turn off and on again all CPUs
  [2.267191] IRQ21 no longer affine to CPU0
  [2.293266] Retrying again to check for CPU kill
  [2.302269] CPU0 killed.
  [2.311648] psci_checker: Trying to turn off and on again group 0 (CPUs 
0-1)
  [2.354354] IRQ21 no longer affine to CPU0
  [2.383222] Retrying again to check for CPU kill
  [2.392148] CPU0 killed.
  [2.398063] psci_checker: Hotplug tests passed OK
  [2.402910] psci_checker: Starting suspend tests (10 cycles per state)
  [2.410019] psci_checker: cpuidle not available on CPU 0, ignoring
  [2.416452] psci_checker: cpuidle not available on CPU 1, ignoring
  [2.422757] psci_checker: Could not start suspend tests on any CPU
  [2.429370] psci_checker: PSCI checker completed

Signed-off-by: Stefan Agner 
---

 arch/arm/mach-imx/mx7/psci-mx7.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index 8b839d37a9..cd72449d9b 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -14,8 +14,10 @@
 
 #define GPC_CPU_PGC_SW_PDN_REQ 0xfc
 #define GPC_CPU_PGC_SW_PUP_REQ 0xf0
+#define GPC_PGC_C0 0x800
 #define GPC_PGC_C1 0x840
 
+#define BM_CPU_PGC_SW_PDN_PUP_REQ_CORE0_A7 0x1
 #define BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7 0x2
 
 /* below is for i.MX7D */
@@ -58,22 +60,24 @@ static inline void imx_gpcv2_set_m_core_pgc(bool enable, 
u32 offset)
writel(enable, GPC_IPS_BASE_ADDR + offset);
 }
 
-__secure void imx_gpcv2_set_core1_power(bool pdn)
+__secure void imx_gpcv2_set_core_power(int cpu, bool pdn)
 {
u32 reg = pdn ? GPC_CPU_PGC_SW_PUP_REQ : GPC_CPU_PGC_SW_PDN_REQ;
+   u32 pgc = cpu ? GPC_PGC_C1 : GPC_PGC_C0;
+   u32 pdn_pup_req = cpu ? BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7 :
+   BM_CPU_PGC_SW_PDN_PUP_REQ_CORE0_A7;
u32 val;
 
-   imx_gpcv2_set_m_core_pgc(true, GPC_PGC_C1);
+   imx_gpcv2_set_m_core_pgc(true, pgc);
 
val = readl(GPC_IPS_BASE_ADDR + reg);
-   val |= BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7;
+   val |= pdn_pup_req;
writel(val, GPC_IPS_BASE_ADDR + reg);
 
-   while ((readl(GPC_IPS_BASE_ADDR + reg) &
-  BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7) != 0)
+   while ((readl(GPC_IPS_BASE_ADDR + reg) & pdn_pup_req) != 0)
;
 
-   imx_gpcv2_set_m_core_pgc(false, GPC_PGC_C1);
+   imx_gpcv2_set_m_core_pgc(false, pgc);
 }
 
 __secure void imx_enable_cpu_ca7(int cpu, bool enable)
@@ -116,7 +120,7 @@ __secure s32 psci_cpu_on(u32 __always_unused function_id, 
u32 mpidr, u32 ep,
 
psci_set_state(cpu, PSCI_AFFINITY_LEVEL_ON_PENDING);
 
-   imx_gpcv2_set_core1_power(true);
+   imx_gpcv2_set_core_power(cpu, true);
imx_enable_cpu_ca7(cpu, true);
 
return ARM_PSCI_RET_SUCCESS;
@@ -132,7 +136,7 @@ __secure s32 psci_cpu_off(void)
psci_set_state(cpu, PSCI_AFFINITY_LEVEL_OFF);
 
imx_enable_cpu_ca7(cpu, false);
-   imx_gpcv2_set_core1_power(false);
+   imx_gpcv2_set_core_power(cpu, false);
writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
 
while (1)
-- 
2.17.1

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


[U-Boot] [PATCH v1 2/5] imx: mx7: psci: use C code exclusively

2018-06-24 Thread Stefan Agner
From: Stefan Agner 

There is no need for assembly in the platform specific part of
the PSCI implementation.

Note that this does not make it a complete PSCI 1.0 implementation
yet but aids to do so in upcoming patches.

Signed-off-by: Stefan Agner 
---

 arch/arm/mach-imx/mx7/Makefile   |  5 +--
 arch/arm/mach-imx/mx7/psci-mx7.c | 29 +++
 arch/arm/mach-imx/mx7/psci.S | 60 
 3 files changed, 24 insertions(+), 70 deletions(-)
 delete mode 100644 arch/arm/mach-imx/mx7/psci.S

diff --git a/arch/arm/mach-imx/mx7/Makefile b/arch/arm/mach-imx/mx7/Makefile
index 7a1ee7a944..94a0e6464f 100644
--- a/arch/arm/mach-imx/mx7/Makefile
+++ b/arch/arm/mach-imx/mx7/Makefile
@@ -4,7 +4,4 @@
 #
 
 obj-y  := soc.o clock.o clock_slice.o ddr.o snvs.o
-
-ifdef CONFIG_ARMV7_PSCI
-obj-y  += psci-mx7.o psci.o
-endif
+obj-$(CONFIG_ARMV7_PSCI)  += psci-mx7.o
diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index 7dc49bd444..95f8cb4def 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -67,23 +67,34 @@ __secure void imx_enable_cpu_ca7(int cpu, bool enable)
writel(val, SRC_BASE_ADDR + SRC_A7RCR1);
 }
 
-__secure int imx_cpu_on(int fn, int cpu, int pc)
+__secure s32 psci_cpu_on(u32 __always_unused function_id, u32 mpidr, u32 ep,
+u32 context_id)
 {
-   writel(pc, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
+   u32 cpu = (mpidr & 0x1);
+
+   psci_save(cpu, ep, context_id);
+
+   writel((u32)psci_cpu_entry, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
imx_gpcv2_set_core1_power(true);
imx_enable_cpu_ca7(cpu, true);
return 0;
 }
 
-__secure int imx_cpu_off(int cpu)
+__secure s32 psci_cpu_off(void)
 {
+   int cpu;
+
+   psci_cpu_off_common();
+   cpu = psci_get_cpu_id();
imx_enable_cpu_ca7(cpu, false);
imx_gpcv2_set_core1_power(false);
writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
-   return 0;
+
+   while (1)
+   wfi();
 }
 
-__secure void imx_system_reset(void)
+__secure void psci_system_reset(void)
 {
struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
 
@@ -91,9 +102,12 @@ __secure void imx_system_reset(void)
writel(0x1 << 28, CCM_BASE_ADDR + CCM_ROOT_WDOG);
writel(0x3, CCM_BASE_ADDR + CCM_CCGR_WDOG1);
writew(WCR_WDE, &wdog->wcr);
+
+   while (1)
+   wfi();
 }
 
-__secure void imx_system_off(void)
+__secure void psci_system_off(void)
 {
u32 val;
 
@@ -103,4 +117,7 @@ __secure void imx_system_off(void)
val = readl(SNVS_BASE_ADDR + SNVS_LPCR);
val |= BP_SNVS_LPCR_DP_EN | BP_SNVS_LPCR_TOP;
writel(val, SNVS_BASE_ADDR + SNVS_LPCR);
+
+   while (1)
+   wfi();
 }
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
deleted file mode 100644
index 89dcf880e8..00
--- a/arch/arm/mach-imx/mx7/psci.S
+++ /dev/null
@@ -1,60 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2015-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
- */
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-   .pushsection ._secure.text, "ax"
-
-   .arch_extension sec
-
-.globl psci_cpu_on
-psci_cpu_on:
-   push{r4, r5, lr}
-
-   mov r4, r0
-   mov r5, r1
-   mov r0, r1
-   mov r1, r2
-   mov r2, r3
-   bl  psci_save
-
-   mov r0, r4
-   mov r1, r5
-   ldr r2, =psci_cpu_entry
-   bl  imx_cpu_on
-
-   pop {r4, r5, pc}
-
-.globl psci_cpu_off
-psci_cpu_off:
-
-   bl  psci_cpu_off_common
-   bl  psci_get_cpu_id
-   bl  imx_cpu_off
-
-1: wfi
-   b 1b
-
-.globl psci_system_reset
-psci_system_reset:
-   bl  imx_system_reset
-
-2: wfi
-   b 2b
-
-.globl psci_system_off
-psci_system_off:
-   bl  imx_system_off
-
-3: wfi
-   b 3b
-
-   .popsection
-- 
2.17.1

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


[U-Boot] [PATCH v1 3/5] imx: mx7: psci: provide complete PSCI 1.0 implementation

2018-06-24 Thread Stefan Agner
From: Stefan Agner 

PSCI 1.0 require PSCI_VERSION, PSCI_FEATURES, AFFINITY_INFO and
CPU_SUSPEND to be implemented. Commit 0ec3d98f7692 ("mx7_common:
use psci 1.0 instead of 0.1") marked the i.MX 7 implementation to
be PSCI 1.0 compliant but failed to implement those functions.
Especially the missing PSCI version callback was noticeable when
booting Linux:

  [0.00] psci: probing for conduit method from DT.
  [0.00] psci: PSCIv65535.65535 detected in firmware.
  [0.00] psci: Using standard PSCI v0.2 function IDs
  [0.00] psci: MIGRATE_INFO_TYPE not supported.
  [0.00] psci: SMC Calling Convention v1.0

This patch provides a minimal implementation thereof. With this
patch applied Linux detects PSCI 1.0:

  [0.00] psci: probing for conduit method from DT.
  [0.00] psci: PSCIv1.0 detected in firmware.
  [0.00] psci: Using standard PSCI v0.2 function IDs
  [0.00] psci: MIGRATE_INFO_TYPE not supported.
  [0.00] psci: SMC Calling Convention v1.0

Fixes: 0ec3d98f7692 ("mx7_common: use psci 1.0 instead of 0.1")
Suggested-by: Mark Rutland 
Signed-off-by: Stefan Agner 
---

 arch/arm/mach-imx/mx7/psci-mx7.c | 96 +++-
 1 file changed, 93 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index 95f8cb4def..8b839d37a9 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -34,6 +35,24 @@
 #define CCM_ROOT_WDOG  0xbb80
 #define CCM_CCGR_WDOG1 0x49c0
 
+#define MPIDR_AFF0 GENMASK(7, 0)
+
+#define IMX7D_PSCI_NR_CPUS 2
+#if IMX7D_PSCI_NR_CPUS > CONFIG_ARMV7_PSCI_NR_CPUS
+#error "invalid value for CONFIG_ARMV7_PSCI_NR_CPUS"
+#endif
+
+u8 psci_state[IMX7D_PSCI_NR_CPUS] __secure_data = {
+PSCI_AFFINITY_LEVEL_ON,
+PSCI_AFFINITY_LEVEL_OFF};
+
+static inline void psci_set_state(int cpu, u8 state)
+{
+   psci_state[cpu] = state;
+   dsb();
+   isb();
+}
+
 static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset)
 {
writel(enable, GPC_IPS_BASE_ADDR + offset);
@@ -67,25 +86,51 @@ __secure void imx_enable_cpu_ca7(int cpu, bool enable)
writel(val, SRC_BASE_ADDR + SRC_A7RCR1);
 }
 
+__secure void psci_arch_cpu_entry(void)
+{
+   u32 cpu = psci_get_cpu_id();
+
+   psci_set_state(cpu, PSCI_AFFINITY_LEVEL_ON);
+}
+
 __secure s32 psci_cpu_on(u32 __always_unused function_id, u32 mpidr, u32 ep,
 u32 context_id)
 {
-   u32 cpu = (mpidr & 0x1);
+   u32 cpu = mpidr & MPIDR_AFF0;
+
+   if (mpidr & ~MPIDR_AFF0)
+   return ARM_PSCI_RET_INVAL;
+
+   if (cpu >= IMX7D_PSCI_NR_CPUS)
+   return ARM_PSCI_RET_INVAL;
+
+   if (psci_state[cpu] == PSCI_AFFINITY_LEVEL_ON)
+   return ARM_PSCI_RET_ALREADY_ON;
+
+   if (psci_state[cpu] == PSCI_AFFINITY_LEVEL_ON_PENDING)
+   return ARM_PSCI_RET_ON_PENDING;
 
psci_save(cpu, ep, context_id);
 
writel((u32)psci_cpu_entry, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
+
+   psci_set_state(cpu, PSCI_AFFINITY_LEVEL_ON_PENDING);
+
imx_gpcv2_set_core1_power(true);
imx_enable_cpu_ca7(cpu, true);
-   return 0;
+
+   return ARM_PSCI_RET_SUCCESS;
 }
 
 __secure s32 psci_cpu_off(void)
 {
int cpu;
 
-   psci_cpu_off_common();
cpu = psci_get_cpu_id();
+
+   psci_cpu_off_common();
+   psci_set_state(cpu, PSCI_AFFINITY_LEVEL_OFF);
+
imx_enable_cpu_ca7(cpu, false);
imx_gpcv2_set_core1_power(false);
writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
@@ -121,3 +166,48 @@ __secure void psci_system_off(void)
while (1)
wfi();
 }
+
+__secure u32 psci_version(void)
+{
+   return ARM_PSCI_VER_1_0;
+}
+
+__secure s32 psci_cpu_suspend(u32 __always_unused function_id, u32 power_state,
+ u32 entry_point_address,
+ u32 context_id)
+{
+   return ARM_PSCI_RET_INVAL;
+}
+
+__secure s32 psci_affinity_info(u32 __always_unused function_id,
+   u32 target_affinity,
+   u32 lowest_affinity_level)
+{
+   u32 cpu = target_affinity & MPIDR_AFF0;
+
+   if (lowest_affinity_level > 0)
+   return ARM_PSCI_RET_INVAL;
+
+   if (target_affinity & ~MPIDR_AFF0)
+   return ARM_PSCI_RET_INVAL;
+
+   if (cpu >= IMX7D_PSCI_NR_CPUS)
+   return ARM_PSCI_RET_INVAL;
+
+   return psci_state[cpu];
+}
+
+__secure s32 psci_features(u32 __always_unused function_id, u32 psci_fid)
+{
+   switch (psci_fid) {
+   case ARM_PSCI_0_2_FN_PSCI_VERSION:
+   case ARM_PSCI_0_2_FN_CPU_OFF:
+   case ARM_PSCI_0_2_FN_CPU_ON:
+   case ARM_PSCI_0_2_FN_AFFINITY_INFO:
+   case ARM_PSCI_0_2_FN_SYSTEM_OFF:
+

[U-Boot] [PATCH v1 5/5] imx: mx7: psci: implement MIGRATE_INFO_TYPE

2018-06-24 Thread Stefan Agner
From: Stefan Agner 

Implement MIGRATE_INFO_TYPE. This informs Linux that no migration
for the trusted operating system is necessary:
  [0.00] psci: Trusted OS migration not required

Signed-off-by: Stefan Agner 
---

 arch/arm/mach-imx/mx7/psci-mx7.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index cd72449d9b..aae96c553f 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -201,6 +201,12 @@ __secure s32 psci_affinity_info(u32 __always_unused 
function_id,
return psci_state[cpu];
 }
 
+__secure s32 psci_migrate_info_type(u32 function_id)
+{
+   /* Trusted OS is either not present or does not require migration */
+   return 2;
+}
+
 __secure s32 psci_features(u32 __always_unused function_id, u32 psci_fid)
 {
switch (psci_fid) {
@@ -208,6 +214,7 @@ __secure s32 psci_features(u32 __always_unused function_id, 
u32 psci_fid)
case ARM_PSCI_0_2_FN_CPU_OFF:
case ARM_PSCI_0_2_FN_CPU_ON:
case ARM_PSCI_0_2_FN_AFFINITY_INFO:
+   case ARM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
case ARM_PSCI_0_2_FN_SYSTEM_OFF:
case ARM_PSCI_0_2_FN_SYSTEM_RESET:
case ARM_PSCI_1_0_FN_PSCI_FEATURES:
-- 
2.17.1

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


[U-Boot] [PATCH v1 1/5] ARM: PSCI: initialize stack pointer on secondary CPUs

2018-06-24 Thread Stefan Agner
From: Stefan Agner 

A proper stack is required to safely use C code in psci_arch_cpu_entry.

Fixes: 486daaa618e1 ("arm: psci: add a weak function psci_arch_cpu_entry")
Cc: Patrick Delaunay 
Signed-off-by: Stefan Agner 
---

 arch/arm/cpu/armv7/psci.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 08b5088675..983cd90442 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -331,6 +331,8 @@ ENTRY(psci_cpu_entry)
 
bl  _nonsec_init
 
+   bl  psci_stack_setup
+
bl  psci_arch_cpu_entry
 
bl  psci_get_cpu_id @ CPU ID => r0
-- 
2.17.1

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


Re: [U-Boot] Fwd: Re: [PATCH v3 2/6] spi: omap3_spi: Full dm conversion

2018-06-24 Thread Jagan Teki
On Fri, Jun 22, 2018 at 7:01 PM, Hannes Schmelzer
 wrote:
>
> Hi Jagan,
>
> anything open ?
> are the patches ready to apply?

I'm waiting for the board that are using driver should ready for
dm_spi, and I hope these are not done yet and indeed waiting for board
maintainers to convert the same.

If possible can you group all you changes along with mine and send
again to ML, so-that we can force the boards to use DM_SPI

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


[U-Boot] [PATCH v12 1/3] Consolidating UDP header functions.

2018-06-24 Thread DH
From: Duncan Hare 

To make it possible to add TCP versions of the same, while reusing
IP portions. This patch should not change any behavior.

All references to TCP removed
Used most recent version of u-boot June 22 13, 2918
Series to fix patman errors over Licensing declaration
END

Series-notes
TCP with Selective Acknowledgment (SACK) is currently the protocol
with highest speed transfers, for fast multi-hop networks.
END

Signed-off-by: Duncan Hare 
Signed-off-by: Duncan Hare 
---

 include/net.h |  6 +-
 net/net.c | 34 --
 net/ping.c|  7 +--
 3 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/include/net.h b/include/net.h
index 5760685556..a54160fff6 100644
--- a/include/net.h
+++ b/include/net.h
@@ -593,7 +593,8 @@ int net_set_ether(uchar *xet, const uchar *dest_ethaddr, 
uint prot);
 int net_update_ether(struct ethernet_hdr *et, uchar *addr, uint prot);
 
 /* Set IP header */
-void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source);
+void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source,
+  u16 pkt_len, u8 proto);
 void net_set_udp_header(uchar *pkt, struct in_addr dest, int dport,
int sport, int len);
 
@@ -667,6 +668,9 @@ static inline void net_send_packet(uchar *pkt, int len)
  * @param sport Source UDP port
  * @param payload_len Length of data after the UDP header
  */
+int net_send_ip_packet(uchar *ether, struct in_addr dest, int dport, int sport,
+  int payload_len, int proto, u8 action, u32 tcp_seq_num,
+  u32 tcp_ack_num);
 int net_send_udp_packet(uchar *ether, struct in_addr dest, int dport,
int sport, int payload_len);
 
diff --git a/net/net.c b/net/net.c
index b4563a4cab..f831c34599 100644
--- a/net/net.c
+++ b/net/net.c
@@ -786,6 +786,14 @@ void net_set_timeout_handler(ulong iv, thand_f *f)
 int net_send_udp_packet(uchar *ether, struct in_addr dest, int dport, int 
sport,
int payload_len)
 {
+return net_send_ip_packet(ether, dest, dport, sport, payload_len,
+ IPPROTO_UDP, 0, 0, 0);
+}
+
+int net_send_ip_packet(uchar *ether, struct in_addr dest, int dport, int sport,
+  int payload_len, int proto, u8 action, u32 tcp_seq_num,
+  u32 tcp_ack_num)
+{
uchar *pkt;
int eth_hdr_size;
int pkt_hdr_size;
@@ -806,9 +814,15 @@ int net_send_udp_packet(uchar *ether, struct in_addr dest, 
int dport, int sport,
pkt = (uchar *)net_tx_packet;
 
eth_hdr_size = net_set_ether(pkt, ether, PROT_IP);
-   pkt += eth_hdr_size;
-   net_set_udp_header(pkt, dest, dport, sport, payload_len);
-   pkt_hdr_size = eth_hdr_size + IP_UDP_HDR_SIZE;
+
+   switch (proto) {
+   case IPPROTO_UDP:
+   net_set_udp_header(pkt + eth_hdr_size, dest,
+  dport, sport, payload_len);
+   pkt_hdr_size = eth_hdr_size + IP_UDP_HDR_SIZE;
+   break;
+   default: return -EINVAL;
+   }
 
/* if MAC address was not discovered yet, do an ARP request */
if (memcmp(ether, net_null_ethaddr, 6) == 0) {
@@ -1434,7 +1448,8 @@ int net_update_ether(struct ethernet_hdr *et, uchar 
*addr, uint prot)
}
 }
 
-void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source)
+void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source,
+  u16 pkt_len, u8 proto)
 {
struct ip_udp_hdr *ip = (struct ip_udp_hdr *)pkt;
 
@@ -1444,11 +1459,12 @@ void net_set_ip_header(uchar *pkt, struct in_addr dest, 
struct in_addr source)
/* IP_HDR_SIZE / 4 (not including UDP) */
ip->ip_hl_v  = 0x45;
ip->ip_tos   = 0;
-   ip->ip_len   = htons(IP_HDR_SIZE);
+   ip->ip_len   = htons(pkt_len);
+   ip->ip_p = proto;
ip->ip_id= htons(net_ip_id++);
ip->ip_off   = htons(IP_FLAGS_DFRAG);   /* Don't fragment */
ip->ip_ttl   = 255;
-   ip->ip_sum   = 0;
+   ip->ip_sum   = compute_ip_checksum(ip, IP_HDR_SIZE);
/* already in network byte order */
net_copy_ip((void *)&ip->ip_src, &source);
/* already in network byte order */
@@ -1468,10 +1484,8 @@ void net_set_udp_header(uchar *pkt, struct in_addr dest, 
int dport, int sport,
if (len & 1)
pkt[IP_UDP_HDR_SIZE + len] = 0;
 
-   net_set_ip_header(pkt, dest, net_ip);
-   ip->ip_len   = htons(IP_UDP_HDR_SIZE + len);
-   ip->ip_p = IPPROTO_UDP;
-   ip->ip_sum   = compute_ip_checksum(ip, IP_HDR_SIZE);
+   net_set_ip_header(pkt, dest, net_ip, IP_UDP_HDR_SIZE + len,
+ IPPROTO_UDP);
 
ip->udp_src  = htons(sport);
ip->udp_dst  = htons(dport);
diff --git a/net/ping.c b/net/ping.c
index 3e5461a36a..d5d914bf2a 100644
--- a/net/ping.c
+++ b/net/ping.c
@@ -22,1

[U-Boot] [PATCH v12 3/3] Add wget application

2018-06-24 Thread DH
From: Duncan Hare 

Commit-notes
All the code is new, and not copied from any source

Test wget

wget is a general purpose TCP/IP program. There is a Linux/unix version
of wget, which enables server verification without running u-boot.

1. The python distribution include a simple http request handler.
To use it with u-boot and Linux wget start the python server
in the directory which contains your test files.

sudo python -m SimplleHTTPServer 80

sudo becuse the port number used is lower than 1,000.
Leave this window open.

Then test the server, in a directory different from your directory
containing test file, assuming a test file named "test file.name"
at a Linux command prompt enter:

wget localhost/testfile.name

and the file should be transferred to the receiving directory.

The server verification is now complete.

2. wget in u-boot needs a load address, server ip address, an ip
address, optional file path, and file name.

The server and u-boot ip address can be 127.0.0.1. The routing is then
between the u-boot test environment and the server in the same machine.

u-boot script example

env set ipaddr 127.0.0.1; env set loadaddr 0x800;
wget 127.0.0.1 testfile.name

or

env set ipaddr 127.0.0.1; env set loadaddr 0x800;
wget 127.0.0.1 pathname/testfile.name

wget prints a progress "|" every 127 packets, and at the end of transfer
prints a message of success or fail, and bytes transferred.

When testing u-boot, we first did a large file transfer with wget
and then modified tftp to download the same file and verify wget's
transfer was both complete and correct, with a strcmp function replacing
the copy to kernel area code fragment.
END

Cover-letter
Add TCP and WGET
This is a limited implementation of a TCP, a  receiver, with
selective acknowledgment (SACK), and wget as a transfer protocol over TCP.

TCP with SACK provides maximum transfer rates over fast and fast multi-hop
networks. TCP continues stream transfer if packets are dropped, and then
recoveres dropped packed asynchronously.

WGET is a very efficient file transfer protocol running over TCP.
There is a single request for each file transferred, irrespective of file size.
END

Signed-off-by: Duncan Hare 
---

 cmd/Kconfig|   7 +
 cmd/net.c  |  13 ++
 include/net.h  |   2 +-
 include/net/wget.h |  19 +++
 net/Makefile   |   2 +-
 net/net.c  |   9 +-
 net/wget.c | 426 +
 7 files changed, 475 insertions(+), 3 deletions(-)
 create mode 100644 include/net/wget.h
 create mode 100644 net/wget.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 45c83359ad..fb9c894363 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1192,6 +1192,13 @@ config CMD_NFS
help
  Boot image via network using NFS protocol.
 
+config CMD_WGET
+   bool "wget"
+   select TCP
+   help
+ Download kernel, or other files, from a web server over TCP.
+ Fast file transfer over networks with latenc
+
 config CMD_MII
bool "mii"
help
diff --git a/cmd/net.c b/cmd/net.c
index f83839c35e..f5fde849c4 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -113,6 +113,19 @@ U_BOOT_CMD(
 );
 #endif
 
+#if defined(CONFIG_CMD_WGET)
+static int do_wget(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   return netboot_common(WGET, cmdtp, argc, argv);
+}
+
+U_BOOT_CMD(
+   wget,   3,  1,  do_wget,
+   "boot image via network using HTTP protocol",
+   "[loadAddress] [[hostIPaddr:]path and image name]"
+);
+#endif
+
 static void netboot_update_env(void)
 {
char tmp[22];
diff --git a/include/net.h b/include/net.h
index ba96267eb8..14b013083d 100644
--- a/include/net.h
+++ b/include/net.h
@@ -539,7 +539,7 @@ extern int  net_restart_wrap;   /* Tried all 
network devices */
 
 enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
-   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT
+   TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WGET
 };
 
 extern charnet_boot_file_name[1024];/* Boot File name */
diff --git a/include/net/wget.h b/include/net/wget.h
new file mode 100644
index 00..61bdd851f9
--- /dev/null
+++ b/include/net/wget.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Duncan Hare Copyright 2017
+ */
+
+void wget_start(void); /* Begin wget */
+
+enum WGET_STATE {
+   WGET_CLOSED,
+   WGET_CONNECTING,
+   WGET_CONNECTED,
+   WGET_TRANSFERRING,
+   WGET_TRANSFERRED
+};
+
+#defineDEBUG_WGET  0   /* Set to 1 for debug messges */
+#defineSERVER_PORT 80
+#defineWGET_RETRY_COUNT30
+#defineWGET_TIMEOUT2000UL
diff --git a/net/Makefile b/net/Makefile
index 237023407f..882af145aa 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,8 +23,8 @@ obj-$(CONFIG_CMD_PING) += ping.o
 obj-$(CONFIG_CMD_RARP) += rarp.o
 obj-$(CONFIG_CMD_SNTP) += sntp.o
 obj-

[U-Boot] [PATCH v12 2/3] Add TCP

2018-06-24 Thread DH
From: Duncan Hare 

Currently file transfers are done using tftp or NFS both
over udp. This requires a request to be sent from client
(u-boot) to the boot server.

The current standard is TCP with selective acknowledgment.

In our testing we have reduce kernel transmission time to
around 0.4 seconds for a 4Mbyte kernel, with a 100 Mbps
downlink.

Series-Changes 11
- Add TCP with SACK
- Clean formatting
- Remove buffer search and print routines

Series-Changes 12
- Fix License statement

Signed-off-by: Duncan Hare 
Signed-off-by: Duncan Hare 
---

 include/net.h |  11 +-
 include/net/tcp.h | 227 ++
 net/Kconfig   |   6 +
 net/Makefile  |   1 +
 net/net.c |  33 +++
 net/tcp.c | 700 ++
 6 files changed, 977 insertions(+), 1 deletion(-)
 create mode 100644 include/net/tcp.h
 create mode 100644 net/tcp.c

diff --git a/include/net.h b/include/net.h
index a54160fff6..ba96267eb8 100644
--- a/include/net.h
+++ b/include/net.h
@@ -26,6 +26,9 @@
  *
  */
 
+#if defined(CONFIG_TCP)/* Protected UDP uses less bufferes 
than TCP */
+#define CONFIG_SYS_RX_ETH_BUFFER 12
+#endif
 #ifdef CONFIG_SYS_RX_ETH_BUFFER
 # define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER
 #else
@@ -350,6 +353,7 @@ struct vlan_ethernet_hdr {
 #define PROT_PPP_SES   0x8864  /* PPPoE session messages   */
 
 #define IPPROTO_ICMP1  /* Internet Control Message Protocol*/
+#define IPPROTO_TCP 6  /* Transmission Control Protocol*/
 #define IPPROTO_UDP17  /* User Datagram Protocol   */
 
 /*
@@ -659,7 +663,7 @@ static inline void net_send_packet(uchar *pkt, int len)
 }
 
 /*
- * Transmit "net_tx_packet" as UDP packet, performing ARP request if needed
+ * Transmit "net_tx_packet" as UDP or TCPpacket, send ARP request if needed
  *  (ether will be populated)
  *
  * @param ether Raw packet buffer
@@ -667,10 +671,15 @@ static inline void net_send_packet(uchar *pkt, int len)
  * @param dport Destination UDP port
  * @param sport Source UDP port
  * @param payload_len Length of data after the UDP header
+ * @param action TCP action to be performed
+ * @param tcp_seq_num TCP sequence number of this transmission
+ * @param tcp_ack_num TCP stream acknolegement number
  */
 int net_send_ip_packet(uchar *ether, struct in_addr dest, int dport, int sport,
   int payload_len, int proto, u8 action, u32 tcp_seq_num,
   u32 tcp_ack_num);
+int net_send_tcp_packet(int payload_len, int dport, int sport, u8 action,
+   u32 tcp_seq_num, u32 tcp_ack_num);
 int net_send_udp_packet(uchar *ether, struct in_addr dest, int dport,
int sport, int payload_len);
 
diff --git a/include/net/tcp.h b/include/net/tcp.h
new file mode 100644
index 00..d0e90e07dd
--- /dev/null
+++ b/include/net/tcp.h
@@ -0,0 +1,227 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TCP Support with SACK for file transfer.
+ *
+ * Copyright 2017 Duncan Hare, All rights reserved.
+ */
+
+#define TCP_ACTIVITY 127   /* Number of packets received   */
+   /* before console progress mark */
+
+struct ip_tcp_hdr {
+   u8  ip_hl_v;/* header length and version*/
+   u8  ip_tos; /* type of service  */
+   u16 ip_len; /* total length */
+   u16 ip_id;  /* identification   */
+   u16 ip_off; /* fragment offset field*/
+   u8  ip_ttl; /* time to live */
+   u8  ip_p;   /* protocol */
+   u16 ip_sum; /* checksum */
+   struct in_addr  ip_src; /* Source IP address*/
+   struct in_addr  ip_dst; /* Destination IP address   */
+   u16 tcp_src;/* TCP source port  */
+   u16 tcp_dst;/* TCP destination port */
+   u32 tcp_seq;/* TCP sequence number  */
+   u32 tcp_ack;/* TCP Acknowledgment number*/
+   u8  tcp_hlen;   /* 4 bits TCP header Length/4   */
+   /* 4 bits Reserved  */
+   /* 2 more bits reserved */
+   u8  tcp_flags;  /* see defines  */
+   u16 tcp_win;/* TCP windows size */
+   u16 tcp_xsum;   /* Checksum */
+   u16 tcp_ugr;/* Pointer to urgent data   */
+} __packed;
+
+#define IP_TCP_HDR_SIZE(sizeof(struct ip_tcp_hdr))
+#define TCP_HDR_SIZE   (IP_TCP_HDR_SIZE  - IP_HDR_SIZE)
+
+#define T

[U-Boot] bootefi disk probe once?

2018-06-24 Thread Bin Meng
Hi Alex, Heinrich,

During testing bootefi command, I found that:

If I type 'bootefi' at first time, and forgot to probe the disk before, I got:

Found 0 disks

Later I did the disk probe (eg: usb start, or scsi scan), and re-run
'bootefi', the disk was not probed for the 2nd time by 'bootefi'.

Is this bug, or intended design?

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


[U-Boot] [PATCH V2 1/4] imx: mx7: psci: add cpu hotplug support

2018-06-24 Thread Anson Huang
This patch adds cpu hotplug support, previous
imx_cpu_off implementation is NOT safe, a CPU
can NOT power down itself in runtime, it will cause
system bus hang due to pending transaction. So
need to use other online CPU to kill it when
it is ready for killed.

Here use SRC parameter register and a magic number
of ~0 as handshake for killing a offline CPU,
when the online CPU checks the psci_affinity_info,
it will help kill the offline CPU according to
the magic number stored in SRC parameter register.

Signed-off-by: Anson Huang 
---
changes since V1:
Defining magic number for CPU handshake;
Improving SRC GPR register offset by using macros definition.
no function change.
 arch/arm/mach-imx/mx7/psci-mx7.c | 41 
 arch/arm/mach-imx/mx7/psci.S | 14 ++
 2 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index 7dc49bd..a5cccac 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -34,6 +34,14 @@
 #define CCM_ROOT_WDOG  0xbb80
 #define CCM_CCGR_WDOG1 0x49c0
 
+#define imx_cpu_gpr_entry_offset(cpu) \
+   (SRC_BASE_ADDR + SRC_GPR1_MX7D + cpu * 8)
+#define imx_cpu_gpr_para_offset(cpu) \
+   (imx_cpu_gpr_entry_offset(cpu) + 4)
+
+#define IMX_CPU_SYNC_OFF   ~0
+#define IMX_CPU_SYNC_ON0
+
 static inline void imx_gpcv2_set_m_core_pgc(bool enable, u32 offset)
 {
writel(enable, GPC_IPS_BASE_ADDR + offset);
@@ -69,7 +77,7 @@ __secure void imx_enable_cpu_ca7(int cpu, bool enable)
 
 __secure int imx_cpu_on(int fn, int cpu, int pc)
 {
-   writel(pc, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D);
+   writel(pc, imx_cpu_gpr_entry_offset(cpu));
imx_gpcv2_set_core1_power(true);
imx_enable_cpu_ca7(cpu, true);
return 0;
@@ -77,12 +85,37 @@ __secure int imx_cpu_on(int fn, int cpu, int pc)
 
 __secure int imx_cpu_off(int cpu)
 {
-   imx_enable_cpu_ca7(cpu, false);
-   imx_gpcv2_set_core1_power(false);
-   writel(0, SRC_BASE_ADDR + cpu * 8 + SRC_GPR1_MX7D + 4);
+   /*
+* We use the cpu jumping argument register to sync with
+* imx_cpu_affinity() which is running on cpu0 to kill the cpu.
+*/
+   writel(IMX_CPU_SYNC_OFF, imx_cpu_gpr_para_offset(cpu));
+
return 0;
 }
 
+__secure int imx_cpu_affinity(int cpu)
+{
+   u32 val;
+
+   /* always ON for CPU0 */
+   if (cpu == 0)
+   return PSCI_AFFINITY_LEVEL_ON;
+
+   /* CPU1 is waiting for killed */
+   if (readl(imx_cpu_gpr_para_offset(cpu)) == IMX_CPU_SYNC_OFF) {
+   imx_enable_cpu_ca7(cpu, false);
+   imx_gpcv2_set_core1_power(false);
+   writel(IMX_CPU_SYNC_ON, imx_cpu_gpr_para_offset(cpu));
+   return PSCI_AFFINITY_LEVEL_OFF;
+   }
+
+   val = readl(SRC_BASE_ADDR + SRC_A7RCR1) &
+   (1 << BP_SRC_A7RCR1_A7_CORE1_ENABLE);
+
+   return  val ? PSCI_AFFINITY_LEVEL_ON : PSCI_AFFINITY_LEVEL_OFF;
+}
+
 __secure void imx_system_reset(void)
 {
struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
index 89dcf88..d6d19d5 100644
--- a/arch/arm/mach-imx/mx7/psci.S
+++ b/arch/arm/mach-imx/mx7/psci.S
@@ -57,4 +57,18 @@ psci_system_off:
 3: wfi
b 3b
 
+.globl psci_affinity_info
+psci_affinity_info:
+   push{lr}
+
+   mov r0, #ARM_PSCI_RET_INVAL
+   cmp r2, #0
+   bne out_affinity
+
+   and r0, r1, #0xff
+   bl  imx_cpu_affinity
+
+out_affinity:
+   pop {pc}
+
.popsection
-- 
2.7.4

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


[U-Boot] [PATCH V2 2/4] imx: mx7: add gpc initialization for low power mode

2018-06-24 Thread Anson Huang
Add i.MX7D GPC initialization for low power mode
support like system suspend/resume from linux kernel:

 - Pending IOMUXC IRQ to workaround GPC state machine issue;
 - Mask all GPC interrupts for M4/C0/C1;
 - Configure SCU timing;
 - Configure time slot ack;
 - Configure C0/C1 power up/down timing;
 - Configure wakeup source mechanism;
 - Disable DSM/RBC related settings.

Signed-off-by: Anson Huang 
---
no change since V1.
 arch/arm/mach-imx/mx7/soc.c | 101 
 1 file changed, 101 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index f1dea66..fb94712 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -19,6 +19,37 @@
 #include 
 #include 
 
+#define IOMUXC_GPR10x4
+#define BM_IOMUXC_GPR1_IRQ 0x1000
+
+#define GPC_LPCR_A7_BSC0x0
+#define GPC_LPCR_M40x8
+#define GPC_SLPCR  0x14
+#define GPC_PGC_ACK_SEL_A7 0x24
+#define GPC_IMR1_CORE0 0x30
+#define GPC_IMR1_CORE1 0x40
+#define GPC_IMR1_M40x50
+#define GPC_PGC_CPU_MAPPING0xec
+#define GPC_PGC_C0_PUPSCR  0x804
+#define GPC_PGC_SCU_TIMING 0x890
+#define GPC_PGC_C1_PUPSCR  0x844
+
+#define BM_LPCR_A7_BSC_IRQ_SRC_A7_WAKEUP   0x7000
+#define BM_LPCR_A7_BSC_CPU_CLK_ON_LPM  0x4000
+#define BM_LPCR_M4_MASK_DSM_TRIGGER0x8000
+#define BM_SLPCR_EN_DSM0x8000
+#define BM_SLPCR_RBC_EN0x4000
+#define BM_SLPCR_REG_BYPASS_COUNT  0x3f00
+#define BM_SLPCR_VSTBY 0x4
+#define BM_SLPCR_SBYOS 0x2
+#define BM_SLPCR_BYPASS_PMIC_READY 0x1
+#define BM_SLPCR_EN_A7_FASTWUP_WAIT_MODE   0x1
+
+#define BM_GPC_PGC_ACK_SEL_A7_DUMMY_PUP_ACK0x8000
+#define BM_GPC_PGC_ACK_SEL_A7_DUMMY_PDN_ACK0x8000
+
+#define BM_GPC_PGC_CORE_PUPSCR 0x7fff80
+
 #if defined(CONFIG_IMX_THERMAL)
 static const struct imx_thermal_plat imx7_thermal_plat = {
.regs = (void *)ANATOP_BASE_ADDR,
@@ -160,6 +191,74 @@ static void imx_enet_mdio_fixup(void)
}
 }
 
+static void imx_gpcv2_init(void)
+{
+   u32 val, i;
+
+   /*
+* Force IOMUXC irq pending, so that the interrupt to GPC can be
+* used to deassert dsm_request signal when the signal gets
+* asserted unexpectedly.
+*/
+   val = readl(IOMUXC_GPR_BASE_ADDR + IOMUXC_GPR1);
+   val |= BM_IOMUXC_GPR1_IRQ;
+   writel(val, IOMUXC_GPR_BASE_ADDR + IOMUXC_GPR1);
+
+   /* Initially mask all interrupts */
+   for (i = 0; i < 4; i++) {
+   writel(~0, GPC_IPS_BASE_ADDR + GPC_IMR1_CORE0 + i * 4);
+   writel(~0, GPC_IPS_BASE_ADDR + GPC_IMR1_CORE1 + i * 4);
+   writel(~0, GPC_IPS_BASE_ADDR + GPC_IMR1_M4 + i * 4);
+   }
+
+   /* set SCU timing */
+   writel((0x59 << 10) | 0x5B | (0x2 << 20),
+  GPC_IPS_BASE_ADDR + GPC_PGC_SCU_TIMING);
+
+   /* only external IRQs to wake up LPM and core 0/1 */
+   val = readl(GPC_IPS_BASE_ADDR + GPC_LPCR_A7_BSC);
+   val |= BM_LPCR_A7_BSC_IRQ_SRC_A7_WAKEUP;
+   writel(val, GPC_IPS_BASE_ADDR + GPC_LPCR_A7_BSC);
+
+   /* set C0 power up timming per design requirement */
+   val = readl(GPC_IPS_BASE_ADDR + GPC_PGC_C0_PUPSCR);
+   val &= ~BM_GPC_PGC_CORE_PUPSCR;
+   val |= (0x1A << 7);
+   writel(val, GPC_IPS_BASE_ADDR + GPC_PGC_C0_PUPSCR);
+
+   /* set C1 power up timming per design requirement */
+   val = readl(GPC_IPS_BASE_ADDR + GPC_PGC_C1_PUPSCR);
+   val &= ~BM_GPC_PGC_CORE_PUPSCR;
+   val |= (0x1A << 7);
+   writel(val, GPC_IPS_BASE_ADDR + GPC_PGC_C1_PUPSCR);
+
+   /* dummy ack for time slot by default */
+   writel(BM_GPC_PGC_ACK_SEL_A7_DUMMY_PUP_ACK |
+   BM_GPC_PGC_ACK_SEL_A7_DUMMY_PDN_ACK,
+   GPC_IPS_BASE_ADDR + GPC_PGC_ACK_SEL_A7);
+
+   /* mask M4 DSM trigger */
+   writel(readl(GPC_IPS_BASE_ADDR + GPC_LPCR_M4) |
+BM_LPCR_M4_MASK_DSM_TRIGGER,
+GPC_IPS_BASE_ADDR + GPC_LPCR_M4);
+
+   /* set mega/fast mix in A7 domain */
+   writel(0x1, GPC_IPS_BASE_ADDR + GPC_PGC_CPU_MAPPING);
+   /* DSM related settings */
+   val = readl(GPC_IPS_BASE_ADDR + GPC_SLPCR);
+   val &= ~(BM_SLPCR_EN_DSM | BM_SLPCR_VSTBY | BM_SLPCR_RBC_EN |
+   BM_SLPCR_SBYOS | BM_SLPCR_BYPASS_PMIC_READY |
+   BM_SLPCR_REG_BYPASS_COUNT);
+   val |= BM_SLPCR_EN_A7_FASTWUP_WAIT_MODE;
+   writel(val, GPC_IPS_BASE_ADDR + GPC_SLPCR);
+   /*
+* disabling RBC need to delay at least 2 cycles of CKIL(32K)
+* due to hardware design requirement, which is
+* ~61us, here we use 65us for safe
+*/
+   udelay(65);
+}
+
 int arch_cpu_init(void)
 {
init_aips();
@@ -181,6 +280,8 @@ int arch_cpu_init(void)
 
init_snvs()

[U-Boot] [PATCH V2 3/4] imx: mx7: add system suspend/resume support

2018-06-24 Thread Anson Huang
This patch adds system suspend/resume support,
when linux kernel enters deep sleep mode, SoC will go
into below mode:

 - CA7 platform goes into STOP mode;
 - SoC goes into DSM mode;
 - DDR goes into self-refresh mode;
 - CPU0/SCU will be powered down.

When wake up event arrives:

 - SoC DSM mdoe exits;
 - CA7 platform exit STOP mode, SCU/CPU0 power up;
 - Invalidate L1 cache;
 - DDR exit self-refresh mode;
 - Do secure monitor mode related initialization;
 - Jump to linux kernel resume entry.

Belwo is the log of 1 iteration of system suspend/resume:

[  338.824862] PM: suspend entry (deep)
[  338.828853] PM: Syncing filesystems ... done.
[  338.834433] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  338.842939] OOM killer disabled.
[  338.846182] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[  338.869717] PM: suspend devices took 0.010 seconds
[  338.877846] Disabling non-boot CPUs ...
[  338.960301] Retrying again to check for CPU kill
[  338.964953] CPU1 killed.
[  338.968104] Enabling non-boot CPUs ...
[  338.973598] CPU1 is up
[  339.267155] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[  339.275833] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[  339.284158] mmc1: queuing unknown CIS tuple 0x80 (6 bytes)
[  339.385065] PM: resume devices took 0.400 seconds
[  339.389836] OOM killer enabled.
[  339.392986] Restarting tasks ... done.
[  339.398990] PM: suspend exit

Signed-off-by: Anson Huang 
---
no change since V1.
 arch/arm/mach-imx/mx7/psci-mx7.c | 343 ++-
 arch/arm/mach-imx/mx7/psci.S | 200 +++
 2 files changed, 541 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-mx7.c
index a5cccac..96fab22 100644
--- a/arch/arm/mach-imx/mx7/psci-mx7.c
+++ b/arch/arm/mach-imx/mx7/psci-mx7.c
@@ -8,16 +8,68 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
-#define GPC_CPU_PGC_SW_PDN_REQ 0xfc
+#define GPC_LPCR_A7_BSC0x0
+#define GPC_LPCR_A7_AD 0x4
+#define GPC_SLPCR  0x14
+#define GPC_PGC_ACK_SEL_A7 0x24
+#define GPC_IMR1_CORE0 0x30
+#define GPC_SLOT0_CFG  0xb0
 #define GPC_CPU_PGC_SW_PUP_REQ 0xf0
+#define GPC_CPU_PGC_SW_PDN_REQ 0xfc
+#define GPC_PGC_C0 0x800
 #define GPC_PGC_C1 0x840
+#define GPC_PGC_SCU0x880
+
+#define BM_LPCR_A7_BSC_CPU_CLK_ON_LPM  0x4000
+#define BM_LPCR_A7_BSC_LPM10xc
+#define BM_LPCR_A7_BSC_LPM00x3
+#define BP_LPCR_A7_BSC_LPM00
+#define BM_SLPCR_EN_DSM0x8000
+#define BM_SLPCR_RBC_EN0x4000
+#define BM_SLPCR_REG_BYPASS_COUNT  0x3f00
+#define BM_SLPCR_VSTBY 0x4
+#define BM_SLPCR_SBYOS 0x2
+#define BM_SLPCR_BYPASS_PMIC_READY 0x1
+#define BM_LPCR_A7_AD_L2PGE0x1
+#define BM_LPCR_A7_AD_EN_C1_PUP0x800
+#define BM_LPCR_A7_AD_EN_C0_PUP0x200
+#define BM_LPCR_A7_AD_EN_PLAT_PDN  0x10
+#define BM_LPCR_A7_AD_EN_C1_PDN0x8
+#define BM_LPCR_A7_AD_EN_C0_PDN0x2
 
 #define BM_CPU_PGC_SW_PDN_PUP_REQ_CORE1_A7 0x2
 
-/* below is for i.MX7D */
+#define BM_GPC_PGC_ACK_SEL_A7_PD_DUMMY_ACK 0x8000
+#define BM_GPC_PGC_ACK_SEL_A7_PU_DUMMY_ACK 0x8000
+
+#define MAX_SLOT_NUMBER10
+#define A7_LPM_WAIT0x5
+#define A7_LPM_STOP0xa
+
+#define BM_SYS_COUNTER_CNTCR_FCR1 0x200
+#define BM_SYS_COUNTER_CNTCR_FCR0 0x100
+
+#define REG_SET0x4
+#define REG_CLR0x8
+
+#define ANADIG_ARM_PLL 0x60
+#define ANADIG_DDR_PLL 0x70
+#define ANADIG_SYS_PLL 0xb0
+#define ANADIG_ENET_PLL0xe0
+#define ANADIG_AUDIO_PLL   0xf0
+#define ANADIG_VIDEO_PLL   0x130
+#defineBM_ANATOP_ARM_PLL_OVERRIDE  BIT(20)
+#defineBM_ANATOP_DDR_PLL_OVERRIDE  BIT(19)
+#defineBM_ANATOP_SYS_PLL_OVERRIDE  (0x1ff << 17)
+#defineBM_ANATOP_ENET_PLL_OVERRIDE BIT(13)
+#defineBM_ANATOP_AUDIO_PLL_OVERRIDEBIT(24)
+#defineBM_ANATOP_VIDEO_PLL_OVERRIDEBIT(24)
+
 #define SRC_GPR1_MX7D  0x074
 #define SRC_A7RCR0 0x004
 #define SRC_A7RCR1 0x008
@@ -42,6 +94,172 @@
 #define IMX_CPU_SYNC_OFF   ~0
 #define IMX_CPU_SYNC_ON0
 
+enum imx_gpc_slot {
+   CORE0_A7,
+   CORE1_A7,
+   SCU_A7,
+   FAST_MEGA_MIX,
+   MIPI_PHY,
+   PCIE_PHY,
+   USB_OTG1_PHY,
+   USB_OTG2_PHY,
+   USB_HSIC_PHY,
+   CORE0_M4,
+};
+
+enum mxc_cpu_pwr_mode {
+   RUN,
+   WAIT,
+   STOP,
+};
+
+inline void imx_pll_suspend(void)
+{
+   write

Re: [U-Boot] [PATCH] common: bootm: reserve memory bank

2018-06-24 Thread Kever Yang
Hi Jason,


On 06/14/2018 03:07 PM, Jason Zhu wrote:
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.

This commit message is not clear enough for what you have done in this
patch,
you should mention the LMB is not correctly mapped when DRAM has more
than 1 bank.
>
> Signed-off-by: Jason Zhu 
> ---
>  common/bootm.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
>  #ifdef CONFIG_LMB
>  static void boot_start_lmb(bootm_headers_t *images)
>  {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
>   ulong   mem_start;
>   phys_size_t mem_size;

For the config without CONFIG_NR_DRAM_BANKS enable, there will be a warning.

Thanks,
- Kever
>  
> - lmb_init(&images->lmb);
> -
>   mem_start = env_get_bootm_low();
>   mem_size = env_get_bootm_size();
>  
>   lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
>   arch_lmb_reserve(&images->lmb);
>   board_lmb_reserve(&images->lmb);
>  }


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


[U-Boot] [PATCH V2 4/4] imx: mx7: add psci_features support

2018-06-24 Thread Anson Huang
It is necessary to implement psci_features callback
to report supported features for linux kernel to
decide whether to proceed psci calls, for example,
linux deep sleep mode is ONLY entered when psci_features
returns TRUE when linux kernel checks whether
system suspend is supported by calling psci_features,
otherwise, s2idle will be entered instead.

Signed-off-by: Anson Huang 
---
no change since V1.
 arch/arm/mach-imx/mx7/psci.S | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
index cbe6781..694cef7 100644
--- a/arch/arm/mach-imx/mx7/psci.S
+++ b/arch/arm/mach-imx/mx7/psci.S
@@ -23,6 +23,22 @@
 
.arch_extension sec
 
+imx_psci_supported_table:
+   .word   ARM_PSCI_0_2_FN_CPU_OFF
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   ARM_PSCI_0_2_FN_CPU_ON
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   ARM_PSCI_0_2_FN_AFFINITY_INFO
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   ARM_PSCI_0_2_FN_SYSTEM_OFF
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   ARM_PSCI_0_2_FN_SYSTEM_RESET
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   ARM_PSCI_1_0_FN_SYSTEM_SUSPEND
+   .word   ARM_PSCI_RET_SUCCESS
+   .word   0
+   .word   ARM_PSCI_RET_NI
+
 .global ddrc_enter_self_refresh
 ddrc_enter_self_refresh:
/* let DDR out of self-refresh */
@@ -112,6 +128,20 @@ v7_invalidate_l1:
isb
mov pc, lr
 
+.globl psci_features
+psci_features:
+   adr r2, imx_psci_supported_table
+1: ldr r3, [r2]
+   cmp r3, #0
+   beq out_psci_features
+   cmp r1, r3
+   addne   r2, r2, #8
+   bne 1b
+
+out_psci_features:
+   ldr r0, [r2, #4]
+   bx  lr
+
 .globl psci_cpu_on
 psci_cpu_on:
push{r4, r5, lr}
-- 
2.7.4

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


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

2018-06-24 Thread Simon Glass
Hi Tom,

A few patman enhancements.


The following changes since commit 77b5ba5d2b94c5b028991c82782493f64bd4f392:

  Merge branch 'master' of git://git.denx.de/u-boot-uniphier
(2018-06-22 13:12:53 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to a60aedfd31722f835dc834f9f2f60882beb96991:

  patman: Support using a particular SMTP server (2018-06-23 08:03:43 -0600)


Chris Packham (2):
  patman: add option for limiting the Cc list
  patman: add test for SPDX license

Simon Glass (1):
  patman: Support using a particular SMTP server

 tools/patman/README   |  1 +
 tools/patman/func_test.py |  3 ++-
 tools/patman/gitutil.py   |  6 +-
 tools/patman/patman.py|  9 +++--
 tools/patman/series.py|  5 -
 tools/patman/test.py  | 18 --
 6 files changed, 35 insertions(+), 7 deletions(-)

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


Re: [U-Boot] [PATCH v4 21/21] efi_loader: Expose U-Boot addresses in memory map for sandbox

2018-06-24 Thread Simon Glass
Hi Alex,

On 23 June 2018 at 00:57, Alexander Graf  wrote:
> Hi Simon,
>
> Am 23.06.2018 um 06:01 schrieb Simon Glass :
>
> Hi Alex,
>
> On 18 June 2018 at 09:23, Alexander Graf  wrote:
>
> We currently expose host addresses in the EFI memory map. That can be
>
> bad if we ever want to use sandbox to boot strap a real kernel, because
>
> then the kernel would fetch its memory table from our host virtual address
>
> map. But to make that use case work, we would need to have full control
>
> over the address space the EFI application sees.
>
>
> So let's expose only U-Boot addresses to the guest until we get to the
>
> point of allocation. EFI's allocation functions are fun - they can take
>
> U-Boot addresses as input values for hints and return host addresses as
>
> allocation results through the same uint64_t * parameter. So we need to
>
> be extra careful on what to pass in when.
>
>
> With this patch I am successfully able to run the efi selftest suite as
>
> well as grub.efi on aarch64.
>
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> arch/sandbox/cpu/cpu.c  | 19 ---
>
> lib/efi_loader/efi_memory.c | 12 ++--
>
> 2 files changed, 6 insertions(+), 25 deletions(-)
>
>
> Can you please point me to your latest series? I think you have
> decided to work on this yourself and pick bits from my series that you
> like.
>
>
> Believe me, I also picked things that I don't like. But ultimately sandbox
> is your court while efi_loader is mine. And I'm fairly sure both of us have
> better things to do than to run in circles.
>
> This I consider unpleasant behaviour for a maintainer, but
> ultimately I'm more interested in getting things resolved than any
> procedural issues. Please don't do this to anyone else, though, in the
> U-Boot community.
>
>
> I don't see the problem - it's pretty common in the Linux world. You propose
> something, I counterpropose, we converge, maintainer decides what to pick
> up.

This is certainly not Linux and I like to think we have a kinder and
more supportive environment here. I very seldom call out people on
this list for language and behaviour.

Also you are a maintainer, not another contributor.

>
> Anyway, at present I'm not sure what state it is in, so please point
> me to your latest tree so I can take a look and figure out what has
> actually changed from my v9 series.
>
>
> The current tree with v5 applied is here:
>
> https://github.com/agraf/u-boot/tree/efi-sandbox-v5
>
> Branch efi-next at the same location is the base for v5.

OK well at this stage I'm going to leave it in your hands as I've lost
track of all the patches and have no desire to send a v10 series.

Once everything lands I'll take a look and see if I think anything is
missing. Hopefully we can get sandbox EFi support into master when the
merge window opens.

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


Re: [U-Boot] [PATCH v4 21/21] efi_loader: Expose U-Boot addresses in memory map for sandbox

2018-06-24 Thread Simon Glass
Hi Alex,

On 18 June 2018 at 09:23, Alexander Graf  wrote:
>
> We currently expose host addresses in the EFI memory map. That can be
> bad if we ever want to use sandbox to boot strap a real kernel, because
> then the kernel would fetch its memory table from our host virtual address
> map. But to make that use case work, we would need to have full control
> over the address space the EFI application sees.
>
> So let's expose only U-Boot addresses to the guest until we get to the
> point of allocation. EFI's allocation functions are fun - they can take
> U-Boot addresses as input values for hints and return host addresses as
> allocation results through the same uint64_t * parameter. So we need to
> be extra careful on what to pass in when.
>
> With this patch I am successfully able to run the efi selftest suite as
> well as grub.efi on aarch64.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/sandbox/cpu/cpu.c  | 19 ---
>  lib/efi_loader/efi_memory.c | 12 ++--
>  2 files changed, 6 insertions(+), 25 deletions(-)

This seems to compete with a patch from my series, but it's not clear
to be what the overlap is.

>
> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> index 641b66a0a7..be88ab2f1c 100644
> --- a/arch/sandbox/cpu/cpu.c
> +++ b/arch/sandbox/cpu/cpu.c
> @@ -176,25 +176,6 @@ void longjmp(jmp_buf jmp, int ret)
>
>  #if CONFIG_IS_ENABLED(EFI_LOADER)
>
> -/*
> - * In sandbox, we don't have a 1:1 map, so we need to expose
> - * process addresses instead of U-Boot addresses
> - */
> -void efi_add_known_memory(void)
> -{
> -   u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
> -   u64 ram_size = gd->ram_size;
> -   u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
> -   u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
> -
> -   efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
> -  false);
> -}
> -
> -#endif
> -
> -#if CONFIG_IS_ENABLED(EFI_LOADER)
> -
>  void allow_unaligned(void)
>  {
> int r;
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 19492df518..64d2b8f7fa 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -326,7 +326,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
> /* Reserve that map in our memory maps */
> ret = efi_add_memory_map(addr, pages, memory_type, true);
> if (ret == addr) {
> -   *memory = addr;
> +   *memory = (uintptr_t)map_sysmem(addr, pages * 
> EFI_PAGE_SIZE);

This line does not seem to correspond to the code in your efi-sandbox-v5 tree.

Also if an address is passed in then presumably it needs
map_to_sysmem() before use (e.g. replace the *memory accesses in this
function).  I suspect those code paths have no tests which is why
things work.

Given that you have efi_allocate_pages() takes (and returns) a pointer
(but stored in a uin64_t) I think you are asking for confusion. At the
least this needs a comment to explain what is being returned.

Apart from that I think it looks right.

> } else {
> /* Map would overlap, bail out */
> r = EFI_OUT_OF_RESOURCES;
> @@ -360,11 +360,12 @@ void *efi_alloc(uint64_t len, int memory_type)
>  efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t pages)
>  {
> uint64_t r = 0;
> +   uint64_t addr = map_to_sysmem((void*)(uintptr_t)memory);
>
> -   r = efi_add_memory_map(memory, pages, EFI_CONVENTIONAL_MEMORY, false);
> +   r = efi_add_memory_map(addr, pages, EFI_CONVENTIONAL_MEMORY, false);
> /* Merging of adjacent free regions is missing */
>
> -   if (r == memory)
> +   if (r == addr)
> return EFI_SUCCESS;
>
> return EFI_NOT_FOUND;
> @@ -381,9 +382,9 @@ efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t 
> pages)
>  efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t size, void 
> **buffer)
>  {
> efi_status_t r;
> -   efi_physical_addr_t t;
> u64 num_pages = (size + sizeof(struct efi_pool_allocation) +
>  EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
> +   struct efi_pool_allocation *alloc;
>
> if (size == 0) {
> *buffer = NULL;
> @@ -391,10 +392,9 @@ efi_status_t efi_allocate_pool(int pool_type, 
> efi_uintn_t size, void **buffer)
> }
>
> r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, pool_type, num_pages,
> -  &t);
> +  (uint64_t*)&alloc);
>
> if (r == EFI_SUCCESS) {
> -   struct efi_pool_allocation *alloc = (void *)(uintptr_t)t;
> alloc->num_pages = num_pages;
> *buffer = alloc->data;
> }
> --
> 2.12.3
>

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

Re: [U-Boot] [PATCH v8 12/30] sandbox: Try to start the RAM buffer at a particular address

2018-06-24 Thread Simon Glass
Hi Alex,

On 22 June 2018 at 15:29, Alexander Graf  wrote:
>
>
>> Am 22.06.2018 um 21:28 schrieb Simon Glass :
>>
>> Hi Alex,
>>
>>> On 22 June 2018 at 06:10, Alexander Graf  wrote:
 On 06/21/2018 09:45 PM, Simon Glass wrote:

 Hi Alex,

> On 21 June 2018 at 03:58, Alexander Graf  wrote:
>
>> On 06/21/2018 04:02 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>>> On 20 June 2018 at 02:51, Alexander Graf  wrote:
>>>
 On 06/20/2018 12:02 AM, Simon Glass wrote:

 Hi Alex,

> On 18 June 2018 at 08:45, Alexander Graf  wrote:
>
>> On 06/18/2018 04:08 PM, Simon Glass wrote:
>>
>> Use a starting address of 256MB which should be available. This
>> helps
>> to
>> make sandbox RAM buffers pointers more recognisable.
>>
>> Signed-off-by: Simon Glass 
>
>
> Nak, this has a non-0 chance of failing, in case something else is
> already
> mapped at that address. You don't want to have your CI blow up 1% of
> the
> time due to this.

 It's just a hint though. Everything will still work if it doesn't get
 this exact address.
>>>
>>>
>>> I don't see what it buys us then.
>>
>> These are my thoughts:
>>
>> 1. We get an address before 4GB which is needed for grub (so far as I
>> can
>> tell)
>
>
> We only need that in the memory map which you want virtual (U-Boot
> address
> space) anyway. So there's no need to also have the Linux address be <4GB.

 Grub cannot work without <4GB, right? I don't mind either way, but I
 think it that if we are picking an address, picking a smaller one is
 better.
>>>
>>>
>>> Only if you expose host pointers as memory addresses. We don't anymore, and
>>> grub doesn't care whether a pointer is >4G.
>>
>> We have to provide grub with pointers to memory with sandbox. These
>> will be pointers into the sandbox RAM buffer. If this buffer is >=4GB
>> then grub will not work, from my testing.
>
> It works just fine for me?

OK that's strange, but perhaps I am building grub wrong. I'l ltry it
again when things land.

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


Re: [U-Boot] [PATCH v8 22/30] efi: sandbox: Tidy up copy_fdt() to work with sandbox

2018-06-24 Thread Simon Glass
Hi Alex,

On 23 June 2018 at 01:24, Alexander Graf  wrote:
>
>
> On 22.06.18 21:31, Simon Glass wrote:
>> Hi Alex,
>>
>> On 22 June 2018 at 06:26, Alexander Graf  wrote:
>>> On 06/21/2018 09:45 PM, Simon Glass wrote:

 Hi Alex,

 On 21 June 2018 at 04:13, Alexander Graf  wrote:
>
> On 06/21/2018 04:01 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 18 June 2018 at 09:00, Alexander Graf  wrote:
>>>
>>> On 06/18/2018 04:08 PM, Simon Glass wrote:

 At present this function takes a pointer as its argument, then passes
 this
 to efi_allocate_pages(), which actually takes an address. It uses
 casts,
 which are not supported on sandbox.
>>>
>>>
>>> I think this is the big API misunderstanding that caused our
>>> disagreements:
>>> efi_allocate_pages(uint64_t *memory) gets a uint64_t *address as input
>>> parameter, but uses the same field to actually return a void * pointer.
>>> This
>>> is the function that really converts between virtual and physical
>>> address
>>> space.
>>>
>>> This is the explicit wording of the spec[1] page 168:
>>>
>>> The AllocatePages() function allocates the requested number of
>>> pages
>>> and
>>> returns a pointer to the base address of the page range in the location
>>> referenced by Memory.
>>
>> The code at present uses *Memory as the address on both input and
>> output. The spec is confusing, but I suspect that is what it meant.
>
>
> The spec means *Memory on IN is an address, on OUT is a pointer. It's
> quite
> clear on that. Since the functions is available to payloads, we should
> follow that semantic.
>
>>> So yes, we have to cast. There is no other way around it without
>>> completely
>>> creating a trainwreck of the API.
>>
>> efi_allocate_pages_ext() can do this though. We don't need to copy the
>> API to efi_allocate_pages().
>
>
> Yikes. There's no way we'll create a frankenstein not-really-almost EFI
> API
> inside U-Boot. Either we stick to the standard or we don't.

 The API is the _ext() function, right? We can rename the internal
 function if you like.

 In any case I think you have this confused. From the spec:

   "Pointer to a physical address. On input, the way in which the
 address is used depends on the value of Type. See “Description” for
 more information. On output the address is set to the base of the page
 range that was allocated. See “Related Definitions.”"

 The parameter does not turn into a pointer on exit. It is an address,
 just as it is on input. What am I missing?
>>>
>>>
>>> Just keep reading. A few lines further down:
>>>
>>>   The AllocatePages() function allocates the requested number of pages and
>>> returns a pointer to the base address of the page range in the location
>>> referenced by Memory.
>>>
>>> the spec explicitly says the function returns *a pointer to the base
>>> address*. It doesn't return an address. It returns a pointer.
>>
>> I think we must be talking at cross-purposes. Perhaps the spec is
>> ambiguous since I read it one way and you read it another. From my
>> side, it 'returns a pointer to the base address' says that the base
>> address is written to the pointer, but perhaps they mean what you
>> think they mean? But if so, it should be void **, not uint64_t *.
>
> The problem is that void ** is wrong for the IN path, so I assume they
> had to decide on one and went with uint64_t * because that's always
> bigger. Sizeof(void*) might be smaller than uint64_t on 32bit platforms.
>
>> In any case it doesn't matter. It returns a 64-bit value which is both
>> a pointer and an address. There is no distinction from the EFI side.
>> From the U-Boot sandbox side, we must provide a pointer (both on input
>> and output) since EFI does not understand our internal RAM buffer
>> offsets.
>
> Yes, I guess we agree by now :).
>
>>> Either way, I've applied the patch that calls map_sysmem() inside
>>> efi_allocate_pages() to efi-next.
>>
>> Which patch is that? Have I reviewed it?
>
> It's this beauty:
>
>
> https://github.com/agraf/u-boot/commit/6f2ac2061ea499c4d23f407798b96b868cb2c3b4

OK thanks, I replied on that. I do think the address handling is
confusing, but we can worry about that in separate patches.

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


Re: [U-Boot] [PATCH v8 02/30] efi: sandbox: Adjust memory usage for sandbox

2018-06-24 Thread Simon Glass
Hi Alex,

On 23 June 2018 at 01:31, Alexander Graf  wrote:
>
>
> On 22.06.18 21:28, Simon Glass wrote:
>> Hi Alex,
>>
>> On 22 June 2018 at 06:08, Alexander Graf  wrote:
>>> On 06/21/2018 09:45 PM, Simon Glass wrote:

 Hi Alex,

 On 21 June 2018 at 03:52, Alexander Graf  wrote:
>
> On 06/21/2018 04:02 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 20 June 2018 at 02:54, Alexander Graf  wrote:
>>>
>>> On 06/20/2018 08:10 AM, Heinrich Schuchardt wrote:

 On 06/18/2018 04:08 PM, Simon Glass wrote:
>
> With sandbox the U-Boot code is not mapped into the sandbox memory
> range
> so does not need to be excluded when allocating EFI memory. Update
> the
> EFI
> memory init code to take account of that.
>
> Also use mapmem instead of a cast to convert a memory address to a
> pointer.

 This is not reflected in the patch.

> Signed-off-by: Simon Glass 
> ---
>
> Changes in v8: None
> Changes in v7:
> - Move some of the code from efi_memory_init() into a separate
> function
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Update to use mapmem instead of a cast
>
> lib/efi_loader/efi_memory.c | 16 
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/lib/efi_loader/efi_memory.c
> b/lib/efi_loader/efi_memory.c
> index ec66af98ea..c6410613c7 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -9,6 +9,7 @@
> #include 
> #include 
> #include 
> +#include 

 I cannot see any use of this include in the patch.

> #include 
> #include 
> @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int pool_type,
> efi_uintn_t size, void **buffer)
>  &t);
>   if (r == EFI_SUCCESS) {
> -   struct efi_pool_allocation *alloc = (void
> *)(uintptr_t)t;
> +   struct efi_pool_allocation *alloc = map_sysmem(t,
> size);
>>>
>>>
>>> ^^^
>>>
>>> This is where mapmem.h gets used. And yes, it's the wrong place. So NAK
>>> on
>>> the patch as-is.
>>
>> What is wrong with it?
>
>
> Efi_allocate_pool calls efi_allocate_pages() which according to spec
> returns
> a pointer. So efi_allocate_pool() should not have to map anything,
> because
> it does not receive an addres.

 You are referring to efi_allocate_pages_ext() I suspect. In my series
 this does the mapping, so that efi_allocate_pages() uses addresses
 only. We could rename it if you like.
>>>
>>>
>>> I don't think we should rename things there. I really think there is a
>>> fundamental misunderstanding here on what the APIs are supposed to do.
>>> Basically:
>>>
>>>   efi_allocate_pages() is mmap() in Liunx
>>>   efi_allocate_pool() is malloc() in Linux
>>>
>>> plus a few extra features of course, but you can think of them at the same
>>> level.
>>>
>>> When a payload calls efi_allocate_pool, that really calls into a more
>>> sophisticated memory allocator usually which can allocate small chunks of
>>> memory efficiently. Given the amount of RAM modern systems have, I opted for
>>> simplicity though so I just mapped it to basically allocate pages using
>>> efi_allocate_pages().
>>>
>>> As for _ext functions, the *only* thing we want in an _ext function is to
>>> isolate the logic that EFI_CALL() would do otherwise - namely swap gd. No
>>> more.
>>
>> Well, we can move things around, but fundamentally I think the current
>> efi_allocate_pages() needs something that maps its memory. In my patch
>> I put this in the ..._ext() function. I feel that the uint64_t *
>> prarameter of efi_allocate_pages() is really confusing, since it
>> implies an address rather than a pointer.
>
> I agree that it's confusing, but it's probably the only thing that works
> when running on a 32bit platform.
>
>> My vote would be to rename the function entirely and change the API to
>> work with pointers (doing the mapping inside itself).
>
> The problem I see there is that we're trying to do a shim that is as
> tiny as possible for real efi functionality. I don't know if splitting
> the function is going to give us real improvements in readability or
> maintainability, since there will be people who will come from an EFI
> background and grasp what the EFI functions do, but not our internal layers.

I'm not sure either, but it might be worth taking a look once the dust settles.

>
> What we could do is something the other way around: An int

Re: [U-Boot] [PATCH v5 04/10] sandbox: Fix setjmp/longjmp

2018-06-24 Thread Simon Glass
Hi Alex,

On 23 June 2018 at 01:36, Alexander Graf  wrote:
>
>
> On 22.06.18 21:28, Simon Glass wrote:
>> Hi Alex,
>>
>> On 22 June 2018 at 06:44, Alexander Graf  wrote:
>>> In sandbox, longjmp returns to itself in an endless loop because
>>> os_longjmp() calls into longjmp() which is provided by U-Boot which
>>> again calls os_longjmp().
>>>
>>> Setjmp on the other hand must not return because otherwise the
>>> return freees up stack elements that we need during longjmp().
>>>
>>> The only straight forward fix that doesn't involve nasty hacks I
>>> could find is to directly link against the system setjmp/longjmp
>>> implementations. That means we just provide the compiler with
>>> hints that the symbol will be available and actually fill them
>>> out with versions from libc.
>>>
>>> This approach should be reasonably platform agnostic
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v4 -> v5:
>>>
>>>   - Use system setjmp/longjmp directly from target code
>>> ---
>>>  arch/sandbox/cpu/cpu.c| 12 
>>>  arch/sandbox/cpu/os.c | 22 --
>>>  arch/sandbox/include/asm/setjmp.h |  5 +
>>>  include/os.h  | 21 -
>>>  4 files changed, 5 insertions(+), 55 deletions(-)
>>
>> I was wondering if that would work. It seems much better to me.
>>
>> Reviewed-by: Simon Glass 
>
> Awesome ;).
>
> So the way forward that I would envision is that once the merge window
> is open, I'll send out a pull request for efi-next to Tom. Pretty much
> all the foundational work should be in upstream by then. The only
> remaining parts are x86, distro and sandbox specific.
>
> For these (basically all the patches of this patch set) I think it makes
> sense if you send them via your tree then.
>
> Beware that currently travis complains about sandbox failing with this
> patch set applied. I assume it's your mao_to_sysmem() patch though:
>
>   https://travis-ci.org/agraf/u-boot/jobs/395446382

Yes that looks like a bug although I don't see it with my series.

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


Re: [U-Boot] Logo for U-Boot

2018-06-24 Thread Stefan Roese

On 24.06.2018 20:07, Simon Glass wrote:

Hi Heinrich,

On 11 June 2018 at 09:54, Heinrich Schuchardt  wrote:

On 06/11/2018 03:03 PM, Tom Rini wrote:

On Sat, Jun 09, 2018 at 10:21:53PM +0200, Heinrich Schuchardt wrote:

On 06/09/2018 07:34 PM, Simon Glass wrote:

Hi,

On 6 May 2018 at 12:31, Tom Rini  wrote:

On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote:


On 06.05.18 18:02, Heinrich Schuchardt wrote:

On 05/04/2018 11:18 AM, Marek Vasut wrote:

On 05/04/2018 08:46 AM, Alexander Graf wrote:

On 05/04/2018 01:04 AM, Marek Vasut wrote:

On 05/03/2018 11:57 PM, Alexander Graf wrote:


On 01.05.18 04:09, Marek Vasut wrote:

On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:

U-Boot has currently no logo that we can use in presentations.

On the U-Boot IRC channel the following propositions where made:

Source:
https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
License: GPL2+
(Alex used this in some presentations.)

Yellow submarine, nice.

Maybe we should make it a bit more toward teal and orange to improve
the
contrast ? Although, maybe just replacing the depressive gray
background
with a light blue one would do.

How about this?

http://csgraf.de/tmp2/uboot.svg

Lacks the teal.



I don't want teal :)


Without teal, the contrast of the image isn't good enough.

And I think you might want to check with more people, since clearly it's
just the two of us discussing it now :)

Find Marek's darling appended


It's a little hard to quote things inline like this.  But, did you
create your own image inspired by the wikimedia one?  I ask because the
wikimedia one is GPLv2 or later, but an original one that we could dual
license (for both a new framebuffer logo, and for printed materials,
etc, where a CC license works better) would be good.


I tend to agree that it looks nice :).

It may mean we need a new web design too though, as the colors in the
logo probably don't work terribly well with the current blue.


We can worry about that later.


I think the logo as here is fine:

https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg


This logo was GPLv2+. Tom, didn't you say we needed something with
creative commons license?


So, while I'm Not A Lawyer(TM), there is a reason lawyers have made
licenses that are still "open source" but for other things.  One of the
uses of a logo is to be printed.  What on earth does GPLv2 (or later)
compliance look like for a brochure or a t-shirt?  That's not the
(usual) spirit behind why you would put a license like that on a thing
like this.  This is why currently projects use one of the Creative
Commons 4.0 licenses for images, hardware design, etc.

And further pushing my "not a lawyer", it's generally accepted that you
can go from CC-4.0 to GPLv3 (or later), you can't go the other
direction.  And I'd also really rather not put people that want to use
our logo in the position of worrying about what GPLv2 compliance on an
image looks like (as it's not clear), I'm strongly in favor of a CC'd
image.

If anyone can contact the actual author of the wikimedia image (it's not
the person that uploaded it, I dug that far) and have them agree to
re-license as CC, I'd be happy to go that route.  Thanks!



I have raised that question on:

https://commons.wikimedia.org/wiki/User_talk:CFCF#Circle-icons-submarine.svg


It looks like the answer was not what you needed, or perhaps I am
reading it incorrectly?

Here are two versions, both with 'U-Boot' text inside the logo. I
think this is important since otherwise the logo could be for
anything.


Yes, i agree. The text should be added.


https://drive.google.com/open?id=1TdX0JS_Zr6ZGtUt6F-6y8rUv2Hq2QlOp

https://drive.google.com/open?id=1UxMY67es8OGIDMST-3G0Pc0aTjbasxTY


I'm in favor of the 2nd version with the complete text.

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


Re: [U-Boot] [PATCH v3 1/4] lib: fdtdec: Add new variable ram_start to global data

2018-06-24 Thread Michal Simek
Hi,

On 22.6.2018 21:28, Simon Glass wrote:
> Hi,
> 
> On 22 June 2018 at 01:41, Michal Simek  wrote:
>> Hi Simon,
>>
>> On 18.6.2018 08:18, Siva Durga Prasad Paladugu wrote:
>>> Added new variable ram_start to global data structure for holding
>>> the start address of first bank of RAM, and then use this ram_start
>>> for calculating ram_top properly. This patch fixes the erroneous
>>> calculation of ram_top incase of non zero ram start address.
>>> This patch also renames fdtdec_setup_memory_size() to
>>> fdtdec_setup_mem_size_start() as this routine now takes care
>>> of memory size and start.
>>>
>>> Signed-off-by: Siva Durga Prasad Paladugu 
>>> Signed-off-by: Michal Simek 
>>> ---
>>> Changes from v2:
>>> - Used new varibale ram_start
>>> - Rename fdtdec_setup_memory_size
>>>
>>> Changes from v1:
>>> - None
>>> ---
>>>  arch/arm/mach-mvebu/arm64-common.c   |  2 +-
>>>  board/emulation/qemu-arm/qemu-arm.c  |  2 +-
>>>  board/renesas/alt/alt.c  |  2 +-
>>>  board/renesas/blanche/blanche.c  |  2 +-
>>>  board/renesas/draak/draak.c  |  2 +-
>>>  board/renesas/eagle/eagle.c  |  2 +-
>>>  board/renesas/gose/gose.c|  2 +-
>>>  board/renesas/koelsch/koelsch.c  |  2 +-
>>>  board/renesas/lager/lager.c  |  2 +-
>>>  board/renesas/porter/porter.c|  2 +-
>>>  board/renesas/salvator-x/salvator-x.c|  2 +-
>>>  board/renesas/silk/silk.c|  2 +-
>>>  board/renesas/stout/stout.c  |  2 +-
>>>  board/renesas/ulcb/ulcb.c|  2 +-
>>>  board/st/stm32f429-discovery/stm32f429-discovery.c   |  2 +-
>>>  board/st/stm32f429-evaluation/stm32f429-evaluation.c |  2 +-
>>>  board/st/stm32f469-discovery/stm32f469-discovery.c   |  2 +-
>>>  board/st/stm32h743-disco/stm32h743-disco.c   |  2 +-
>>>  board/st/stm32h743-eval/stm32h743-eval.c |  2 +-
>>>  board/xilinx/zynq/board.c|  2 +-
>>>  board/xilinx/zynqmp/zynqmp.c |  2 +-
>>>  board/xilinx/zynqmp_r5/board.c   |  2 +-
>>>  common/board_f.c |  4 ++--
>>>  include/asm-generic/global_data.h|  1 +
>>>  include/fdtdec.h | 16 
>>> +---
>>>  lib/fdtdec.c |  3 ++-
>>>  tools/patman/func_test.py|  2 +-
>>>  tools/patman/test/-cover-letter.patch|  2 +-
>>>  ...orrect-cast-for-sandbox-in-fdtdec_setup_memory_.patch |  4 ++--
>>>  tools/patman/test/test01.txt |  2 +-
>>>  30 files changed, 41 insertions(+), 37 deletions(-)
> 
> [...]
> 
>> sjg: Do you see any issue with this patch?
> 
> I think it is OK. Would like to get more people to look at it though.
> 
>>
>> I can't see the reason for fixing tools/patman but I will wait for you.
> 
> Changing patman tests is OK with me. Keeps thing consistent.

thanks Simon.

Tom: Do you see any issue with this change?

Marek: Can you please retest renesas boards that this patch is not
breaking your boards?

Thanks,
Michal


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


Re: [U-Boot] [PATCH v2 1/2] common: command: Use command_ret_t enum values instead of values

2018-06-24 Thread Michal Simek
On 22.6.2018 21:28, Simon Glass wrote:
> Hi Michal,
> 
> On 22 June 2018 at 00:33, Michal Simek  wrote:
>>
>> On 21.6.2018 21:45, Simon Glass wrote:
>>> On 21 June 2018 at 06:58, Michal Simek  wrote:
 Use enum command_ret_t types in cmd_process_error().

 Signed-off-by: Michal Simek 
 ---

 Changes in v2:
 - Move adding RET_USAGE to separate patch.

  common/command.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

>>>
>>> Reviewed-by: Simon Glass 
>>>
>>>
 diff --git a/common/command.c b/common/command.c
 index 52d47c133c3c..a4a8dc601acb 100644
 --- a/common/command.c
 +++ b/common/command.c
 @@ -549,8 +549,8 @@ int cmd_process_error(cmd_tbl_t *cmdtp, int err)
  {
 if (err) {
 printf("Command '%s' failed: Error %d\n", cmdtp->name, 
 err);
 -   return 1;
 +   return CMD_RET_FAILURE;
 }

 -   return 0;
 +   return CMD_RET_SUCCESS;
>>>
>>> I actually thing 0 is fine here. That is the definition of success.
>>
>> and CMD_RET_SUCCESS has this 0 value too.
>>
>> maybe would be worth to also change return type to enum command_ret_t
>> as is done for cmd_process.
>>
>> For example ubi_remove_vol() in case of failure returs +ENODEV and others.
>> I thought that commands could return only 3 values convert by enum
>> command_ret_t. Or is it ok to return also different values?
> 
> Commands should only return things from the enum. My point was that I
> find 'return CMD_RET_SUCCESS' to be a bit painful. We know the value
> is 0 and it is much shorter to read, so I prefer 'return 0' instead of
> 'return CMD_RET_SUCCESS'
> 
> Also I like this:
> 
> if (!xx)
>// we got an error
> 
> and don't like this:
> 
> if (xx != CMD_RET_SUCCESS)
>// we got an error

ok. Got what you meant.

Thanks,
Michal




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