Re: [U-Boot] [PATCH v10 20/27] mtd: spi-nor: Add 4-byte addresswidth support

2017-12-28 Thread Cyrille Pitchen
Hi Jagan,

Le 28/12/2017 à 07:12, Jagan Teki a écrit :
> Add 4-byte address supports, so-that SPI-NOR chips
> has > 16MiB should accessible.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi-nor/m25p80.c  |  1 +
>  drivers/mtd/spi-nor/spi-nor.c | 38 ++
>  include/linux/mtd/spi-nor.h   |  6 +-
>  3 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
> index 5465921..7af6f59 100644
> --- a/drivers/mtd/spi-nor/m25p80.c
> +++ b/drivers/mtd/spi-nor/m25p80.c
> @@ -35,6 +35,7 @@ static void m25p_addr2cmd(struct spi_nor *nor, unsigned int 
> addr, u8 *cmd)
>   cmd[1] = addr >> (nor->addr_width * 8 -  8);
>   cmd[2] = addr >> (nor->addr_width * 8 - 16);
>   cmd[3] = addr >> (nor->addr_width * 8 - 24);
> + cmd[4] = addr >> (nor->addr_width * 8 - 32);
>  }
>  
>  static int m25p_cmdsz(struct spi_nor *nor)
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 8bf9e67..e0085cf 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -632,6 +632,38 @@ static int stm_unlock(struct udevice *dev, loff_t ofs, 
> uint64_t len)
>  }
>  #endif
>  
> +/* Enable/disable 4-byte addressing mode. */
> +static int set_4byte(struct udevice *dev, const struct spi_nor_info *info,
> +  int enable)
> +{
> + struct spi_nor *nor = spi_nor_get_spi_nor_dev(dev);
> + const struct spi_nor_ops *ops = spi_nor_get_ops(dev);
> + int status;
> + bool need_wren = false;
> + u8 cmd;
> +
> + switch (JEDEC_MFR(info)) {
> + case SNOR_MFR_MICRON:
> + /* Some Micron need WREN command; all will accept it */
> + need_wren = true;
> + case SNOR_MFR_MACRONIX:
> + case SNOR_MFR_WINBOND:
> + if (need_wren)
> + write_enable(dev);
> +
> + cmd = enable ? SNOR_OP_EN4B : SNOR_OP_EX4B;
> + status = ops->write_reg(dev, cmd, NULL, 0);
> + if (need_wren)
> + write_disable(dev);
> +
> + return status;
> + default:
> + /* Spansion style */
> + nor->cmd_buf[0] = enable << 7;
> + return ops->write_reg(dev, SNOR_OP_BRWR, nor->cmd_buf, 1);
> + }
> +}
> +
>  #ifdef CONFIG_SPI_NOR_MACRONIX
>  static int macronix_quad_enable(struct udevice *dev)
>  {
> @@ -873,6 +905,12 @@ int spi_nor_scan(struct spi_nor *nor)
>   }
>  
>   nor->addr_width = 3;
> + if (mtd->size > SNOR_16MB_BOUN) {
> + nor->addr_width = 4;
> + ret = set_4byte(nor->dev, info, true);
> + if (ret)
> + goto err;
> + }
>

This is a bad idea: you make the SPI NOR memory enter its 4-byte address
mode, which is statefull. Then, once in Linux for instance, the memory
would still be in its 4-byte address mode but expected to be in its reset
state, hence in 3-byte address mode.

At this point, this might not be an issue yet because spi-nor under linux
is likely to use the 4-byte address instruction set if available, which is
stateless by the way, so whatever the memory is in its 3-byte or in 4-byte
address mode, the op codes of the 4-byte address instruction set are always
expected to be followed by a 4-byte address. So Linux won't notice that the
SPI NOR memory is in its 4-byte mode but not in its 3-byte mode as expected.

However, if a spurious reboot occurs at the CPU side after the SPI NOR
memory has entered its 4-byte address mode, either still in u-boot or
already in linux or whatever running code, the SPI NOR memory, likely not
reset on its side, would still be in its 4-byte address mode, whereas many
earlier boot-loaders would expect the memory to be in it's reset state, ie
in its 3-byte address mode. Hence those boot-loaders, running before u-boot,
would not be able to read data (load u-boot) from the SPI NOR memory:
the boot would fail!

Examples of those early boot-loaders are the ROM Codes of many Atmel
SAMA5Dx SoCs but I'm pretty sure this issue also applies to other
manufacturers based on patches I've seen on the linux-mtd mailing list to
add the SPI_NOR_4B_OPCODES flag to some memory parts:
https://patchwork.ozlabs.org/patch/750305/

Think about a watchdog resetting the CPU for instance.


TL;DR
You should avoid making the SPI NOR memory enter its statefull 4-byte
address mode but consider using the stateless 4-byte address instruction
set instead, when possible.

Almost all recent SPI NOR memories with sizes > 16MiB support the 4-byte
address mode.

Best regards,

Cyrille
  
>   /* Dummy cycles for read */
>   switch (nor->read_opcode) {
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index e1688e2..fc4a649 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -63,6 +63,10 @@
>  #define SNOR_OP_BP   0x02/* Byte program */
>  #define SNOR_OP_AAI_WP

Re: [U-Boot] [PATCH v10 20/27] mtd: spi-nor: Add 4-byte addresswidth support

2017-12-28 Thread Cyrille Pitchen
Le 28/12/2017 à 09:06, Cyrille Pitchen a écrit :
> Hi Jagan,
> 
> Le 28/12/2017 à 07:12, Jagan Teki a écrit :
>> Add 4-byte address supports, so-that SPI-NOR chips
>> has > 16MiB should accessible.
>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  drivers/mtd/spi-nor/m25p80.c  |  1 +
>>  drivers/mtd/spi-nor/spi-nor.c | 38 ++
>>  include/linux/mtd/spi-nor.h   |  6 +-
>>  3 files changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
>> index 5465921..7af6f59 100644
>> --- a/drivers/mtd/spi-nor/m25p80.c
>> +++ b/drivers/mtd/spi-nor/m25p80.c
>> @@ -35,6 +35,7 @@ static void m25p_addr2cmd(struct spi_nor *nor, unsigned 
>> int addr, u8 *cmd)
>>  cmd[1] = addr >> (nor->addr_width * 8 -  8);
>>  cmd[2] = addr >> (nor->addr_width * 8 - 16);
>>  cmd[3] = addr >> (nor->addr_width * 8 - 24);
>> +cmd[4] = addr >> (nor->addr_width * 8 - 32);
>>  }
>>  
>>  static int m25p_cmdsz(struct spi_nor *nor)
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index 8bf9e67..e0085cf 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -632,6 +632,38 @@ static int stm_unlock(struct udevice *dev, loff_t ofs, 
>> uint64_t len)
>>  }
>>  #endif
>>  
>> +/* Enable/disable 4-byte addressing mode. */
>> +static int set_4byte(struct udevice *dev, const struct spi_nor_info *info,
>> + int enable)
>> +{
>> +struct spi_nor *nor = spi_nor_get_spi_nor_dev(dev);
>> +const struct spi_nor_ops *ops = spi_nor_get_ops(dev);
>> +int status;
>> +bool need_wren = false;
>> +u8 cmd;
>> +
>> +switch (JEDEC_MFR(info)) {
>> +case SNOR_MFR_MICRON:
>> +/* Some Micron need WREN command; all will accept it */
>> +need_wren = true;
>> +case SNOR_MFR_MACRONIX:
>> +case SNOR_MFR_WINBOND:
>> +if (need_wren)
>> +write_enable(dev);
>> +
>> +cmd = enable ? SNOR_OP_EN4B : SNOR_OP_EX4B;
>> +status = ops->write_reg(dev, cmd, NULL, 0);
>> +if (need_wren)
>> +write_disable(dev);
>> +
>> +return status;
>> +default:
>> +/* Spansion style */
>> +nor->cmd_buf[0] = enable << 7;
>> +return ops->write_reg(dev, SNOR_OP_BRWR, nor->cmd_buf, 1);
>> +}
>> +}
>> +
>>  #ifdef CONFIG_SPI_NOR_MACRONIX
>>  static int macronix_quad_enable(struct udevice *dev)
>>  {
>> @@ -873,6 +905,12 @@ int spi_nor_scan(struct spi_nor *nor)
>>  }
>>  
>>  nor->addr_width = 3;
>> +if (mtd->size > SNOR_16MB_BOUN) {
>> +nor->addr_width = 4;
>> +ret = set_4byte(nor->dev, info, true);
>> +if (ret)
>> +goto err;
>> +}
>>
> 
> This is a bad idea: you make the SPI NOR memory enter its 4-byte address
> mode, which is statefull. Then, once in Linux for instance, the memory
> would still be in its 4-byte address mode but expected to be in its reset
> state, hence in 3-byte address mode.
> 
> At this point, this might not be an issue yet because spi-nor under linux
> is likely to use the 4-byte address instruction set if available, which is
> stateless by the way, so whatever the memory is in its 3-byte or in 4-byte
> address mode, the op codes of the 4-byte address instruction set are always
> expected to be followed by a 4-byte address. So Linux won't notice that the
> SPI NOR memory is in its 4-byte mode but not in its 3-byte mode as expected.
> 
> However, if a spurious reboot occurs at the CPU side after the SPI NOR
> memory has entered its 4-byte address mode, either still in u-boot or
> already in linux or whatever running code, the SPI NOR memory, likely not
> reset on its side, would still be in its 4-byte address mode, whereas many
> earlier boot-loaders would expect the memory to be in it's reset state, ie
> in its 3-byte address mode. Hence those boot-loaders, running before u-boot,
> would not be able to read data (load u-boot) from the SPI NOR memory:
> the boot would fail!
> 
> Examples of those early boot-loaders are the ROM Codes of many Atmel
> SAMA5Dx SoCs but I'm pretty sure this issue also applies to other
> manufacturers based on patches I've seen on the linux-mtd mailing list to
> add the SPI_NOR_4B_OPCODES flag to some memory parts:
> https://patchwork.ozlabs.org/patch/750305/
> 
> Think about a watchdog resetting the CPU for instance.
> 
> 
> TL;DR
> You should avoid making the SPI NOR memory enter its statefull 4-byte
> address mode but consider using the stateless 4-byte address instruction
> set instead, when possible.
> 
> Almost all recent SPI NOR memories with sizes > 16MiB support the 4-byte
> address mode.

I meant the 4-byte address instruction set ;)
> 
> Best regards,
> 
> Cyrille
>   
>>  /* Dummy cycles for read */
>>  switch (nor->read_opcode) {
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linu

Re: [U-Boot] rockchip: rk3399-puma: reduce env size to 8kiB

2017-12-28 Thread Philipp Tomsich
> ...even when the environment is saved to SD card.
> 
> With the default of 32kiB, the environment overwrites the SPL
> stage which lives at 16kiB.
> 
> Signed-off-by: Jakob Unterwurzacher 
> 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> Tested-by: Philipp Tomsich 
> ---
> 
>  board/theobroma-systems/puma_rk3399/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [U-Boot] rockchp: dts: rk3399-evb: support boot from sd-card

2017-12-28 Thread Philipp Tomsich
> Enable sdmmc node in SPL and add it to boot order.
> 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/dts/rk3399-evb.dts | 3 +++
>  1 file changed, 3 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v5, 1/2] drivers/reset: support rockchip reset drivers

2017-12-28 Thread Philipp Tomsich
> From: Elaine Zhang 
> 
> Create driver to support all Rockchip SoCs soft reset.
> Example of usage:
> i2c driver:
>   ret = reset_get_by_name(dev, "i2c", &reset_ctl);
>   if (ret) {
>   error("reset_get_by_name() failed: %d\n", ret);
>   }
> 
>   reset_assert(&reset_ctl);
>   udelay(50);
>   reset_deassert(&reset_ctl);
> 
> i2c dts node:
> resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>;
> reset-names = "p_i2c", "i2c";
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v5:
> - make rockchip reset driver depends on ARCH_ROCKCHIP
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - fix Kconfig more than 80 length
> - use MACRO for reset bits in one reg
> - use rkclr/set_reg for reg access
> - add rockchip_reset_bind()
> - use dev_read_addr_size() instead of fdtdec_
> 
>  drivers/reset/Kconfig  |   9 +++
>  drivers/reset/Makefile |   1 +
>  drivers/reset/reset-rockchip.c | 133 
> +
>  3 files changed, 143 insertions(+)
>  create mode 100644 drivers/reset/reset-rockchip.c
> 

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


Re: [U-Boot] [U-Boot,v5,2/2] rockchip: clk: bind reset driver

2017-12-28 Thread Philipp Tomsich
> From: Elaine Zhang 
> 
> Bind rockchip reset to clock-controller with rockchip_reset_bind().
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> ---
> 
> Changes in v5: None
> Changes in v4:
> - fix compile error if CONFIG_RESET_ROCKCHIP not defined
> 
> Changes in v3:
> - add missing offset for rk3399 pmuclk bind
> 
> Changes in v2:
> - use rockchip_reset_bind() to bind reset driver.
> 
>  arch/arm/include/asm/arch-rockchip/clock.h | 10 ++
>  drivers/clk/rockchip/clk_rk3036.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3188.c  |  7 +++
>  drivers/clk/rockchip/clk_rk322x.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3288.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3328.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3368.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3399.c  | 21 +
>  drivers/clk/rockchip/clk_rv1108.c  |  7 +++
>  9 files changed, 80 insertions(+)
> 

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


Re: [U-Boot] [U-Boot,v5,2/2] rockchip: clk: bind reset driver

2017-12-28 Thread Philipp Tomsich
> From: Elaine Zhang 
> 
> Bind rockchip reset to clock-controller with rockchip_reset_bind().
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v5: None
> Changes in v4:
> - fix compile error if CONFIG_RESET_ROCKCHIP not defined
> 
> Changes in v3:
> - add missing offset for rk3399 pmuclk bind
> 
> Changes in v2:
> - use rockchip_reset_bind() to bind reset driver.
> 
>  arch/arm/include/asm/arch-rockchip/clock.h | 10 ++
>  drivers/clk/rockchip/clk_rk3036.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3188.c  |  7 +++
>  drivers/clk/rockchip/clk_rk322x.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3288.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3328.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3368.c  |  7 +++
>  drivers/clk/rockchip/clk_rk3399.c  | 21 +
>  drivers/clk/rockchip/clk_rv1108.c  |  7 +++
>  9 files changed, 80 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v5, 1/2] drivers/reset: support rockchip reset drivers

2017-12-28 Thread Philipp Tomsich
> From: Elaine Zhang 
> 
> Create driver to support all Rockchip SoCs soft reset.
> Example of usage:
> i2c driver:
>   ret = reset_get_by_name(dev, "i2c", &reset_ctl);
>   if (ret) {
>   error("reset_get_by_name() failed: %d\n", ret);
>   }
> 
>   reset_assert(&reset_ctl);
>   udelay(50);
>   reset_deassert(&reset_ctl);
> 
> i2c dts node:
> resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>;
> reset-names = "p_i2c", "i2c";
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Kever Yang 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v5:
> - make rockchip reset driver depends on ARCH_ROCKCHIP
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - fix Kconfig more than 80 length
> - use MACRO for reset bits in one reg
> - use rkclr/set_reg for reg access
> - add rockchip_reset_bind()
> - use dev_read_addr_size() instead of fdtdec_
> 
>  drivers/reset/Kconfig  |   9 +++
>  drivers/reset/Makefile |   1 +
>  drivers/reset/reset-rockchip.c | 133 
> +
>  3 files changed, 143 insertions(+)
>  create mode 100644 drivers/reset/reset-rockchip.c
> 

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


[U-Boot] [PATCH] armv8: LS1088: Increase size of CONFIG_SYS_MONITOR_LEN

2017-12-28 Thread Ashish Kumar
Total size of relocated u-boot is greater than
current value of 512MB, increase this to 1MB.

Signed-off-by: Ashish Kumar 
---
 include/configs/ls1088a_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index c96d48d..7ac05ee 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -245,7 +245,7 @@ unsigned long long get_qixis_addr(void);
 
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
 #define CONFIG_SYS_SPL_MALLOC_START0x8020
-#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
+#define CONFIG_SYS_MONITOR_LEN (1024 * 1024)
 #endif
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-- 
2.7.4

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


[U-Boot] [PATCH 0/9] spl: Add full fit and u-boot dto support

2017-12-28 Thread Marek Vasut
Add support for using the full fitImage parsing code in SPL. This is useful
ie. if we want SPL to verify the U-Boot proper fitImage using RSA signature.
While verifying image signature can be added to the simplified fitImage
handling code in U-Boot SPL, verifying configuration signatures becomes
quite hairy. Thus, loading the entire fitImage and then applying the full
fitImage handling code on it is far less intrusive change. The size of the
SPL with full fitImage code obviously grows, so this might not be suitable
for size-constrained systems.

The remaining four patches allow applying a DTO from fitImage onto the SPL's
internal DT and restart the image loading process. The usecase here is ie. to
put a replacement public key into the DTO, patch the /signature node and load
offset node of the U-Boot SPL's DT and restart the image loading process to
load U-Boot proper signed with the replacement private key. The user is then
able to replace the DTO and sign own U-Boot fitImage without replacing the
SPL binary itself.

Marek Vasut (9):
  fit: Fix CONFIG_FIT_SPL_PRINT
  fit: Add empty fit_print_contents() and fit_image_print()
  fit: Add standalone image type handling
  fit: Verify all configuration signatures
  spl: Add full fitImage support
  spl: Add support for overlaying U-Boot DT
  spl: Restart loading if load_image returns -EAGAIN
  spl: ram: Add support for fetching image position from control DT
  spl: spi: Add support for fetching image position from control DT

 Kconfig  | 17 +++
 README   |  2 +-
 common/image-fit.c   | 36 +-
 common/spl/spl.c | 86 +++-
 common/spl/spl_ram.c | 21 ++---
 common/spl/spl_spi.c | 13 
 include/image.h  |  1 +
 7 files changed, 154 insertions(+), 22 deletions(-)

-- 
2.15.0

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


[U-Boot] [PATCH 1/9] fit: Fix CONFIG_FIT_SPL_PRINT

2017-12-28 Thread Marek Vasut
Rename CONFIG_FIT_SPL_PRINT to CONFIG_SPL_FIT_PRINT and add Kconfig
entry for it.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 Kconfig| 6 ++
 README | 2 +-
 common/image-fit.c | 4 ++--
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Kconfig b/Kconfig
index 9b8a807799..cd32096f21 100644
--- a/Kconfig
+++ b/Kconfig
@@ -270,6 +270,12 @@ config SPL_FIT
depends on SPL
select SPL_OF_LIBFDT
 
+config SPL_FIT_PRINT
+   bool "Support FIT printing within SPL"
+   depends on SPL_FIT
+   help
+ Support printing the content of the fitImage in a verbose manner in 
SPL.
+
 config SPL_FIT_SIGNATURE
bool "Enable signature verification of FIT firmware within SPL"
depends on SPL_DM
diff --git a/README b/README
index 93c7ea9665..20da964367 100644
--- a/README
+++ b/README
@@ -2848,7 +2848,7 @@ FIT uImage format:
use an arch-specific makefile fragment instead, for
example if more than one image needs to be produced.
 
-   CONFIG_FIT_SPL_PRINT
+   CONFIG_SPL_FIT_PRINT
Printing information about a FIT image adds quite a bit of
code to SPL. So this is normally disabled in SPL. Use this
option to re-enable it. This will affect the output of the
diff --git a/common/image-fit.c b/common/image-fit.c
index b785d8a36e..98334a0caa 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -143,7 +143,7 @@ int fit_get_subimage_count(const void *fit, int 
images_noffset)
return count;
 }
 
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_FIT_SPL_PRINT)
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FIT_PRINT)
 /**
  * fit_print_contents - prints out the contents of the FIT format image
  * @fit: pointer to the FIT format image header
@@ -460,7 +460,7 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
}
 }
 
-#endif /* !defined(CONFIG_SPL_BUILD) || defined(CONFIG_FIT_SPL_PRINT) */
+#endif /* !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FIT_PRINT) */
 
 /**
  * fit_get_desc - get node description property
-- 
2.15.0

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


[U-Boot] [PATCH 4/9] fit: Verify all configuration signatures

2017-12-28 Thread Marek Vasut
Rather than verifying configuration signature of the configuration node
containing the kernel image types, verify all configuration nodes, even
those that do not contain kernel images. This is useful when the nodes
contain ie. standalone OSes or U-Boot.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/image-fit.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 8871e2dcd3..f559032691 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1766,22 +1766,24 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
fit_base_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
printf("   Using '%s' configuration\n", fit_base_uname_config);
-   if (image_type == IH_TYPE_KERNEL) {
-   /* Remember (and possibly verify) this config */
+   /* Remember this config */
+   if (image_type == IH_TYPE_KERNEL)
images->fit_uname_cfg = fit_base_uname_config;
-   if (IMAGE_ENABLE_VERIFY && images->verify) {
-   puts("   Verifying Hash Integrity ... ");
-   if (fit_config_verify(fit, cfg_noffset)) {
-   puts("Bad Data Hash\n");
-   bootstage_error(bootstage_id +
-   BOOTSTAGE_SUB_HASH);
-   return -EACCES;
-   }
-   puts("OK\n");
+
+   /* Verify this config */
+   if (IMAGE_ENABLE_VERIFY && images->verify) {
+   puts("   Verifying Hash Integrity ... ");
+   if (fit_config_verify(fit, cfg_noffset)) {
+   puts("Bad Data Hash\n");
+   bootstage_error(bootstage_id +
+   BOOTSTAGE_SUB_HASH);
+   return -EACCES;
}
-   bootstage_mark(BOOTSTAGE_ID_FIT_CONFIG);
+   puts("OK\n");
}
 
+   bootstage_mark(BOOTSTAGE_ID_FIT_CONFIG);
+
noffset = fit_conf_get_prop_node(fit, cfg_noffset,
 prop_name);
fit_uname = fit_get_name(fit, noffset, NULL);
-- 
2.15.0

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


[U-Boot] [PATCH 3/9] fit: Add standalone image type handling

2017-12-28 Thread Marek Vasut
Just add IH_TYPE_STANDALONE to fit_get_image_type_property().

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/image-fit.c | 2 ++
 include/image.h| 1 +
 2 files changed, 3 insertions(+)

diff --git a/common/image-fit.c b/common/image-fit.c
index f0e713d88f..8871e2dcd3 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1699,6 +1699,8 @@ static const char *fit_get_image_type_property(int type)
return FIT_LOADABLE_PROP;
case IH_TYPE_FPGA:
return FIT_FPGA_PROP;
+   case IH_TYPE_STANDALONE:
+   return FIT_STANDALONE_PROP;
}
 
return "unknown";
diff --git a/include/image.h b/include/image.h
index a128a623e5..82799fc512 100644
--- a/include/image.h
+++ b/include/image.h
@@ -907,6 +907,7 @@ int bootz_setup(ulong image, ulong *start, ulong *end);
 #define FIT_DEFAULT_PROP   "default"
 #define FIT_SETUP_PROP "setup"
 #define FIT_FPGA_PROP  "fpga"
+#define FIT_STANDALONE_PROP"standalone"
 
 #define FIT_MAX_HASH_LEN   HASH_MAX_DIGEST_SIZE
 
-- 
2.15.0

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


[U-Boot] [PATCH 7/9] spl: Restart loading if load_image returns -EAGAIN

2017-12-28 Thread Marek Vasut
If the loader->load_image returns -EAGAIN, it is an indication
the loading process should restart the loading, possible due to
DTO being applied on the U-Boot's DT. Restart the loading until
the loader stops returning -EAGAIN.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/spl/spl.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 2444abbb08..27f44c27b0 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -413,11 +413,16 @@ static int spl_load_image(struct spl_image_info 
*spl_image,
  struct spl_image_loader *loader)
 {
struct spl_boot_device bootdev;
+   int ret;
 
bootdev.boot_device = loader->boot_device;
bootdev.boot_device_name = NULL;
 
-   return loader->load_image(spl_image, &bootdev);
+   do {
+   ret = loader->load_image(spl_image, &bootdev);
+   } while (ret == -EAGAIN);
+
+   return ret;
 }
 
 /**
-- 
2.15.0

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


[U-Boot] [PATCH 6/9] spl: Add support for overlaying U-Boot DT

2017-12-28 Thread Marek Vasut
Add support for loading fitImage with device tree overlay image, which
is applied to the U-Boot's own device tree. Once the DT is applied, the
fitImage loading process is restarted.

This patch allows a usecase where the DTO patches ie. load address in
the U-Boot's DT or patches in a new public key for authenticating the
subsequently loaded fitImages.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/spl/spl.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index d429ea2c82..2444abbb08 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -140,6 +140,38 @@ void spl_set_header_raw_uboot(struct spl_image_info 
*spl_image)
 }
 
 #ifdef CONFIG_SPL_LOAD_FIT_FULL
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+static int spl_fit_overlay_uboot_fdt_full(const struct image_header *header)
+{
+   bootm_headers_t images;
+   const char *fit_uname_config = NULL;
+   const char *fit_uname_dtbo = "u-boot-dtbo";
+   ulong dto_data = 0;
+   ulong dto_len = 0;
+   int ret;
+
+   ret = fit_image_load(&images, (ulong)header,
+&fit_uname_dtbo, &fit_uname_config,
+IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
+FIT_LOAD_OPTIONAL, &dto_data, &dto_len);
+   if (ret < 0)
+   return 0;
+
+   ret = fdt_overlay_apply_verbose((struct fdt_header *)gd->fdt_blob,
+   (void *)dto_data);
+   if (ret)
+   hang();
+
+   /* Restart the loading process to cater for the DT changes */
+   return -EAGAIN;
+}
+#else
+static int spl_fit_overlay_uboot_fdt_full(const struct image_header *header)
+{
+   return 0;
+}
+#endif
+
 /* Parse and load full fitImage in SPL */
 static int spl_load_fit_image(struct spl_image_info *spl_image,
  const struct image_header *header)
@@ -152,6 +184,10 @@ static int spl_load_fit_image(struct spl_image_info 
*spl_image,
ulong fw_len = 0, dt_len = 0;
int ret;
 
+   ret = spl_fit_overlay_uboot_fdt_full(header);
+   if (ret)
+   return ret;
+
ret = fit_image_load(&images, (ulong)header,
 NULL, &fit_uname_config,
 IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
@@ -182,7 +218,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
 {
 #ifdef CONFIG_SPL_LOAD_FIT_FULL
int ret = spl_load_fit_image(spl_image, header);
-   if (!ret)
+   if (!ret || ret == -EAGAIN)
return ret;
 #endif
if (image_get_magic(header) == IH_MAGIC) {
-- 
2.15.0

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


[U-Boot] [PATCH 2/9] fit: Add empty fit_print_contents() and fit_image_print()

2017-12-28 Thread Marek Vasut
These functions may be needed in SPL, so add empty variants of them
if CONFIG_SPL_FIT_PRINT is disabled.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/image-fit.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 98334a0caa..f0e713d88f 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -459,7 +459,9 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
}
}
 }
-
+#else
+void fit_print_contents(const void *fit) { }
+void fit_image_print(const void *fit, int image_noffset, const char *p) { }
 #endif /* !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FIT_PRINT) */
 
 /**
-- 
2.15.0

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


[U-Boot] [PATCH 5/9] spl: Add full fitImage support

2017-12-28 Thread Marek Vasut
Add support for loading U-Boot and optionally FDT from a fitImage
in SPL by using the full fitImage support from U-Boot. While we do
have limited SPL loading support in SPL with a small footprint, it
is missing a lot of important features, like checking signatures.
This support has all the fitImage features, while the footprint is
obviously larger.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 Kconfig  | 11 +++
 common/spl/spl.c | 43 +++
 2 files changed, 54 insertions(+)

diff --git a/Kconfig b/Kconfig
index cd32096f21..4d0c1a01c1 100644
--- a/Kconfig
+++ b/Kconfig
@@ -293,6 +293,17 @@ config SPL_LOAD_FIT
  particular it can handle selecting from multiple device tree
  and passing the correct one to U-Boot.
 
+config SPL_LOAD_FIT_FULL
+   bool "Enable SPL loading U-Boot as a FIT"
+   select SPL_FIT
+   help
+ Normally with the SPL framework a legacy image is generated as part
+ of the build. This contains U-Boot along with information as to
+ where it should be loaded. This option instead enables generation
+ of a FIT (Flat Image Tree) which provides more flexibility. In
+ particular it can handle selecting from multiple device tree
+ and passing the correct one to U-Boot.
+
 config SPL_FIT_IMAGE_POST_PROCESS
bool "Enable post-processing of FIT artifacts after loading by the SPL"
depends on SPL_LOAD_FIT
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963611..d429ea2c82 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -139,9 +139,52 @@ void spl_set_header_raw_uboot(struct spl_image_info 
*spl_image)
spl_image->name = "U-Boot";
 }
 
+#ifdef CONFIG_SPL_LOAD_FIT_FULL
+/* Parse and load full fitImage in SPL */
+static int spl_load_fit_image(struct spl_image_info *spl_image,
+ const struct image_header *header)
+
+{
+   bootm_headers_t images;
+   const char *fit_uname_config = NULL;
+   const char *fit_uname_fdt = FIT_FDT_PROP;
+   ulong fw_data = 0, dt_data = 0;
+   ulong fw_len = 0, dt_len = 0;
+   int ret;
+
+   ret = fit_image_load(&images, (ulong)header,
+NULL, &fit_uname_config,
+IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
+FIT_LOAD_REQUIRED, &fw_data, &fw_len);
+   if (ret < 0)
+   return ret;
+
+   spl_image->size = fw_len;
+   spl_image->entry_point = fw_data;
+   spl_image->load_addr = fw_data;
+   spl_image->os = IH_OS_U_BOOT;
+   spl_image->name = "U-Boot";
+
+   debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
+   (int)sizeof(spl_image->name), spl_image->name,
+   spl_image->load_addr, spl_image->size);
+
+   ret = fit_image_load(&images, (ulong)header,
+&fit_uname_fdt, &fit_uname_config,
+IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
+FIT_LOAD_OPTIONAL, &dt_data, &dt_len);
+   return 0;
+}
+#endif
+
 int spl_parse_image_header(struct spl_image_info *spl_image,
   const struct image_header *header)
 {
+#ifdef CONFIG_SPL_LOAD_FIT_FULL
+   int ret = spl_load_fit_image(spl_image, header);
+   if (!ret)
+   return ret;
+#endif
if (image_get_magic(header) == IH_MAGIC) {
 #ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT
u32 header_size = sizeof(struct image_header);
-- 
2.15.0

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


[U-Boot] [PATCH 9/9] spl: spi: Add support for fetching image position from control DT

2017-12-28 Thread Marek Vasut
Add support for fetching the image position in RAM from control DT
rather than hard-coding it. While doing so, return the return value
of spl_parse_header_image() to make it possible to test application
of DTOs on U-Boot's control DT.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/spl/spl_spi.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
index 42880d56b9..c2613a494b 100644
--- a/common/spl/spl_spi.c
+++ b/common/spl/spl_spi.c
@@ -75,6 +75,7 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
unsigned payload_offs = CONFIG_SYS_SPI_U_BOOT_OFFS;
struct spi_flash *flash;
struct image_header *header;
+   unsigned image_offs, image_size;
 
/*
 * Load U-Boot image from SPI flash into RAM
@@ -96,6 +97,18 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
payload_offs = fdtdec_get_config_int(gd->fdt_blob,
 "u-boot,spl-payload-offset",
 payload_offs);
+   image_offs = fdtdec_get_config_int(gd->fdt_blob,
+  "u-boot,spl-image-offset", 0);
+   image_size = fdtdec_get_config_int(gd->fdt_blob,
+  "u-boot,spl-image-size", 0);
+   if (image_size) {
+   err = spi_flash_read(flash, image_offs,
+image_size,
+(void *)CONFIG_SYS_TEXT_BASE);
+   if (err)
+   return err;
+   return spl_parse_image_header(spl_image, header);
+   }
 #endif
 
 #ifdef CONFIG_SPL_OS_BOOT
-- 
2.15.0

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


[U-Boot] [PATCH 8/9] spl: ram: Add support for fetching image position from control DT

2017-12-28 Thread Marek Vasut
Add support for fetching the image position in RAM from control DT
rather than hard-coding it. While doing so, return the return value
of spl_parse_header_image() to make it possible to test application
of DTOs on U-Boot's control DT.

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---
 common/spl/spl_ram.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
index fa8c768773..c88d09ba04 100644
--- a/common/spl/spl_ram.c
+++ b/common/spl/spl_ram.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
 # define CONFIG_SPL_LOAD_FIT_ADDRESS   0
 #endif
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
   ulong count, void *buf)
 {
@@ -33,7 +35,12 @@ static int spl_ram_load_image(struct spl_image_info 
*spl_image,
  struct spl_boot_device *bootdev)
 {
struct image_header *header;
+   unsigned image_offs;
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+   image_offs = fdtdec_get_config_int(gd->fdt_blob,
+  "u-boot,spl-image-offset", 0);
+#endif
header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
 
 #if defined(CONFIG_SPL_DFU_SUPPORT)
@@ -48,7 +55,7 @@ static int spl_ram_load_image(struct spl_image_info 
*spl_image,
debug("Found FIT\n");
load.bl_len = 1;
load.read = spl_ram_load_read;
-   spl_load_simple_fit(spl_image, &load, 0, header);
+   return spl_load_simple_fit(spl_image, &load, 0, header);
} else {
ulong u_boot_pos = binman_sym(ulong, u_boot_any, pos);
 
@@ -64,12 +71,16 @@ static int spl_ram_load_image(struct spl_image_info 
*spl_image,
 * No binman support or no information. For now, fix it
 * to the address pointed to by U-Boot.
 */
-   u_boot_pos = CONFIG_SYS_TEXT_BASE -
-   sizeof(struct image_header);
+   if (image_offs)
+   u_boot_pos = image_offs;
+   else
+   u_boot_pos = CONFIG_SYS_TEXT_BASE -
+sizeof(struct image_u_boot_pos);
}
header = (struct image_header *)map_sysmem(u_boot_pos, 0);
 
-   spl_parse_image_header(spl_image, header);
+
+   return spl_parse_image_header(spl_image, header);
}
 
return 0;
-- 
2.15.0

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


Re: [U-Boot] [PATCH] Convert CONFIG_USB_MUSB_OMAP2PLUS et al to Kconfig

2017-12-28 Thread Paul Kocialkowski
Hi,

Le mercredi 27 décembre 2017 à 20:09 -0600, Adam Ford a écrit :
> This converts the following to Kconfig:
>CONFIG_USB_MUSB_OMAP2PLUS
>CONFIG_USB_MUSB_PIO_ONLY

Thanks for the continued effort on omap platforms!

While you're at it, you might want to do the same with:
* CONFIG_USB_MUSB_AM35X
* CONFIG_USB_MUSB_DSPS

that are currently not in Kconfig either.

It looks like there is no controller out there that doesn't use
CONFIG_USB_MUSB_PIO_ONLY, so I think it makes little sense to enable it
in each defconfig.

IMO, it should be selected by default for each of the supported
controllers:
* CONFIG_USB_MUSB_PIC32
* CONFIG_USB_MUSB_OMAP2PLUS
* CONFIG_USB_MUSB_AM35X
* CONFIG_USB_MUSB_DSPS
* CONFIG_USB_MUSB_SUNXI

What do you think?

Also, here is a list of config files for each controller:
CONFIG_USB_MUSB_PIC32:
include/configs/pic32mzdask.h

CONFIG_USB_MUSB_OMAP2PLUS:
include/configs/kc1.h
include/configs/omap3_beagle.h
include/configs/omap3_evm.h
include/configs/omap3_logic.h
include/configs/sniper.h

CONFIG_USB_MUSB_AM35X:
include/configs/am3517_evm.h
include/configs/cm_t3517.h

CONFIG_USB_MUSB_DSPS:
include/configs/am335x_evm.h
include/configs/baltos.h
include/configs/bav335x.h
include/configs/brppt1.h
include/configs/brxre1.h
include/configs/chiliboard.h
include/configs/pcm051.h
include/configs/pengwyn.h
include/configs/siemens-am33x-common.h

CONFIG_USB_MUSB_SUNXI:
include/configs/sunxi-common.h

> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/am335x_baltos_defconfig
> b/configs/am335x_baltos_defconfig
> index 0ef9f42..bb7c31b 100644
> --- a/configs/am335x_baltos_defconfig
> +++ b/configs/am335x_baltos_defconfig
> @@ -55,6 +55,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_boneblack_defconfig
> b/configs/am335x_boneblack_defconfig
> index 55e0ebd..ccb5431 100644
> --- a/configs/am335x_boneblack_defconfig
> +++ b/configs/am335x_boneblack_defconfig
> @@ -32,6 +32,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_boneblack_vboot_defconfig
> b/configs/am335x_boneblack_vboot_defconfig
> index fe5b9e7..dc584d8 100644
> --- a/configs/am335x_boneblack_vboot_defconfig
> +++ b/configs/am335x_boneblack_vboot_defconfig
> @@ -42,6 +42,7 @@ CONFIG_OMAP_TIMER=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_evm_defconfig
> b/configs/am335x_evm_defconfig
> index 9c97009..9e860ce 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -47,6 +47,7 @@ CONFIG_DM_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
>  CONFIG_USB_MUSB_TI=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_evm_nor_defconfig
> b/configs/am335x_evm_nor_defconfig
> index 1813003..cfdd259 100644
> --- a/configs/am335x_evm_nor_defconfig
> +++ b/configs/am335x_evm_nor_defconfig
> @@ -34,6 +34,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_evm_norboot_defconfig
> b/configs/am335x_evm_norboot_defconfig
> index b38d7f6..862f238 100644
> --- a/configs/am335x_evm_norboot_defconfig
> +++ b/configs/am335x_evm_norboot_defconfig
> @@ -30,6 +30,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_evm_spiboot_defconfig
> b/configs/am335x_evm_spiboot_defconfig
> index 7a20576..2afdc05 100644
> --- a/configs/am335x_evm_spiboot_defconfig
> +++ b/configs/am335x_evm_spiboot_defconfig
> @@ -32,6 +32,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> diff --git a/configs/am335x_evm_usbspl_defconfig
> b/configs/am335x_evm_usbspl_defconfig
> index 1e80017..cfdb00c 100644
> --- a/configs/am335x_evm_usbspl_defconfig
> +++ b/configs/am335x_evm_usbspl_defconfig
> @@ -38,6 +38,7 @@ CONFIG_OMAP3_SPI=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
>  CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_MUSB_PIO_ONLY=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFI

[U-Boot] [PATCH v8 0/2] DW SPI: Get clock value from Device Tree

2017-12-28 Thread Eugeniy Paltsev
As discussed with Marek during the LINUX-PITER here is v* patch:

Add option to set spi controller clock frequency via device tree
using standard clock bindings.

Define dw_spi_get_clk function as 'weak' as some targets
(like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
and implement dw_spi_get_clk their own way in their clock manager.

Get rid of clock_manager.h include in designware_spi.c as we don't use
cm_get_spi_controller_clk_hz function anymore - we use redefined
dw_spi_get_clk in SOCFPGA clock managers (clock_manager_gen5.c and
clock_manager_arria10.c) instead.

Changes v7->v8:
  * Fix typo in comments.

Changes v6->v7:
  * Cleanup error handling.
  * Don't free clock after we successfully requeste it.

Changes v5->v6:
  * Put the clock handle into the private data

Changes v4->v5:
  * Get rid of usless ifdef in dw_spi_get_clk function

Eugeniy Paltsev (2):
  SOCFPGA: clock manager: implement dw_spi_get_clk function
  DW SPI: Get clock value from Device Tree

 arch/arm/mach-socfpga/clock_manager_arria10.c |  9 +
 arch/arm/mach-socfpga/clock_manager_gen5.c|  9 +
 drivers/spi/designware_spi.c  | 47 +--
 3 files changed, 63 insertions(+), 2 deletions(-)

-- 
2.9.3

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


[U-Boot] [PATCH v8 1/2] SOCFPGA: clock manager: implement dw_spi_get_clk function

2017-12-28 Thread Eugeniy Paltsev
Implement dw_spi_get_clk function to override its weak
implementation in designware_spi.c driver.

We need this change to get rid of cm_get_spi_controller_clk_hz
function and clock_manager.h include in designware_spi.c driver.

Reviewed-by: Marek Vasut 
Signed-off-by: Eugeniy Paltsev 
---
 arch/arm/mach-socfpga/clock_manager_arria10.c | 9 +
 arch/arm/mach-socfpga/clock_manager_gen5.c| 9 +
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c 
b/arch/arm/mach-socfpga/clock_manager_arria10.c
index 482b854..623a266 100644
--- a/arch/arm/mach-socfpga/clock_manager_arria10.c
+++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -1076,6 +1077,14 @@ unsigned int cm_get_qspi_controller_clk_hz(void)
return  cm_get_l4_noc_hz(CLKMGR_MAINPLL_NOCDIV_L4MAINCLK_LSB);
 }
 
+/* Override weak dw_spi_get_clk implementation in designware_spi.c driver */
+int dw_spi_get_clk(struct udevice *bus, ulong *rate)
+{
+   *rate = cm_get_spi_controller_clk_hz();
+
+   return 0;
+}
+
 void cm_print_clock_quick_summary(void)
 {
printf("MPU   %10ld kHz\n", cm_get_mpu_clk_hz() / 1000);
diff --git a/arch/arm/mach-socfpga/clock_manager_gen5.c 
b/arch/arm/mach-socfpga/clock_manager_gen5.c
index 31fd510..a371d83 100644
--- a/arch/arm/mach-socfpga/clock_manager_gen5.c
+++ b/arch/arm/mach-socfpga/clock_manager_gen5.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -509,6 +510,14 @@ unsigned int cm_get_spi_controller_clk_hz(void)
return clock;
 }
 
+/* Override weak dw_spi_get_clk implementation in designware_spi.c driver */
+int dw_spi_get_clk(struct udevice *bus, ulong *rate)
+{
+   *rate = cm_get_spi_controller_clk_hz();
+
+   return 0;
+}
+
 void cm_print_clock_quick_summary(void)
 {
printf("MPU   %10ld kHz\n", cm_get_mpu_clk_hz() / 1000);
-- 
2.9.3

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


[U-Boot] [PATCH v8 2/2] DW SPI: Get clock value from Device Tree

2017-12-28 Thread Eugeniy Paltsev
Add option to set spi controller clock frequency via device tree
using standard clock bindings.

Define dw_spi_get_clk function as 'weak' as some targets
(like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
and implement dw_spi_get_clk their own way in their clock manager.

Get rid of clock_manager.h include as we don't use
cm_get_spi_controller_clk_hz function anymore. (we use redefined
dw_spi_get_clk in SOCFPGA clock managers instead)

Reviewed-by: Marek Vasut 
Signed-off-by: Eugeniy Paltsev 
---
 drivers/spi/designware_spi.c | 45 ++--
 1 file changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 5aa507b..c501aee 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -94,6 +94,8 @@ struct dw_spi_priv {
void __iomem *regs;
unsigned int freq;  /* Default frequency */
unsigned int mode;
+   struct clk clk;
+   unsigned long bus_clk_rate;
 
int bits_per_word;
u8 cs;  /* chip select pin */
@@ -176,14 +178,53 @@ static void spi_hw_init(struct dw_spi_priv *priv)
debug("%s: fifo_len=%d\n", __func__, priv->fifo_len);
 }
 
+/*
+ * We define dw_spi_get_clk function as 'weak' as some targets
+ * (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
+ * and implement dw_spi_get_clk their own way in their clock manager.
+ */
+__weak int dw_spi_get_clk(struct udevice *bus, ulong *rate)
+{
+   struct dw_spi_priv *priv = dev_get_priv(bus);
+   int ret;
+
+   ret = clk_get_by_index(bus, 0, &priv->clk);
+   if (ret)
+   return ret;
+
+   ret = clk_enable(&priv->clk);
+   if (ret && ret != -ENOSYS && ret != -ENOTSUPP)
+   return ret;
+
+   *rate = clk_get_rate(&priv->clk);
+   if (!*rate)
+   goto err_rate;
+
+   debug("%s: get spi controller clk via device tree: %lu Hz\n",
+ __func__, *rate);
+
+   return 0;
+
+err_rate:
+   clk_disable(&priv->clk);
+   clk_free(&priv->clk);
+
+   return -EINVAL;
+}
+
 static int dw_spi_probe(struct udevice *bus)
 {
struct dw_spi_platdata *plat = dev_get_platdata(bus);
struct dw_spi_priv *priv = dev_get_priv(bus);
+   int ret;
 
priv->regs = plat->regs;
priv->freq = plat->frequency;
 
+   ret = dw_spi_get_clk(bus, &priv->bus_clk_rate);
+   if (ret)
+   return ret;
+
/* Currently only bits_per_word == 8 supported */
priv->bits_per_word = 8;
 
@@ -369,7 +410,7 @@ static int dw_spi_set_speed(struct udevice *bus, uint speed)
spi_enable_chip(priv, 0);
 
/* clk_div doesn't support odd number */
-   clk_div = cm_get_spi_controller_clk_hz() / speed;
+   clk_div = priv->bus_clk_rate / speed;
clk_div = (clk_div + 1) & 0xfffe;
dw_writel(priv, DW_SPI_BAUDR, clk_div);
 
-- 
2.9.3

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


Re: [U-Boot] [PATCH v8 0/2] DW SPI: Get clock value from Device Tree

2017-12-28 Thread Marek Vasut
On 12/28/2017 01:09 PM, Eugeniy Paltsev wrote:
> As discussed with Marek during the LINUX-PITER here is v* patch:
> 
> Add option to set spi controller clock frequency via device tree
> using standard clock bindings.
> 
> Define dw_spi_get_clk function as 'weak' as some targets
> (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
> and implement dw_spi_get_clk their own way in their clock manager.
> 
> Get rid of clock_manager.h include in designware_spi.c as we don't use
> cm_get_spi_controller_clk_hz function anymore - we use redefined
> dw_spi_get_clk in SOCFPGA clock managers (clock_manager_gen5.c and
> clock_manager_arria10.c) instead.
> 
> Changes v7->v8:
>   * Fix typo in comments.
> 
> Changes v6->v7:
>   * Cleanup error handling.
>   * Don't free clock after we successfully requeste it.
> 
> Changes v5->v6:
>   * Put the clock handle into the private data
> 
> Changes v4->v5:
>   * Get rid of usless ifdef in dw_spi_get_clk function
> 
> Eugeniy Paltsev (2):
>   SOCFPGA: clock manager: implement dw_spi_get_clk function
>   DW SPI: Get clock value from Device Tree
> 
>  arch/arm/mach-socfpga/clock_manager_arria10.c |  9 +
>  arch/arm/mach-socfpga/clock_manager_gen5.c|  9 +
>  drivers/spi/designware_spi.c  | 47 
> +--
>  3 files changed, 63 insertions(+), 2 deletions(-)
> 

Thanks for keeping it up ! And I hope this ends up in after 2018.01 :-)
Please keep an eye on these patches and poke in case these patches
aren't in after 2018.01 is out ...

btw it was nice talking during Piter, I hope to come back next year too!

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


Re: [U-Boot] [PATCH 5/9] spl: Add full fitImage support

2017-12-28 Thread Lukasz Majewski
Hi Marek,

> Add support for loading U-Boot and optionally FDT from a fitImage
> in SPL by using the full fitImage support from U-Boot. While we do
> have limited SPL loading support in SPL with a small footprint, it
> is missing a lot of important features, like checking signatures.
> This support has all the fitImage features, while the footprint is
> obviously larger.
> 
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  Kconfig  | 11 +++
>  common/spl/spl.c | 43 +++
>  2 files changed, 54 insertions(+)
> 
> diff --git a/Kconfig b/Kconfig
> index cd32096f21..4d0c1a01c1 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -293,6 +293,17 @@ config SPL_LOAD_FIT
> particular it can handle selecting from multiple device
> tree and passing the correct one to U-Boot.
>  
> +config SPL_LOAD_FIT_FULL
> + bool "Enable SPL loading U-Boot as a FIT"
> + select SPL_FIT
> + help
> +   Normally with the SPL framework a legacy image is
> generated as part
> +   of the build. This contains U-Boot along with information
> as to
> +   where it should be loaded. This option instead enables
> generation
> +   of a FIT (Flat Image Tree) which provides more
> flexibility. In
> +   particular it can handle selecting from multiple device
> tree
> +   and passing the correct one to U-Boot.
> +
>  config SPL_FIT_IMAGE_POST_PROCESS
>   bool "Enable post-processing of FIT artifacts after loading
> by the SPL" depends on SPL_LOAD_FIT
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 76c1963611..d429ea2c82 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -139,9 +139,52 @@ void spl_set_header_raw_uboot(struct
> spl_image_info *spl_image) spl_image->name = "U-Boot";
>  }
>  
> +#ifdef CONFIG_SPL_LOAD_FIT_FULL
> +/* Parse and load full fitImage in SPL */
> +static int spl_load_fit_image(struct spl_image_info *spl_image,
> +   const struct image_header *header)
> +
 ^^^ - this blank line can be removed.

> +{
> + bootm_headers_t images;
> + const char *fit_uname_config = NULL;
> + const char *fit_uname_fdt = FIT_FDT_PROP;
> + ulong fw_data = 0, dt_data = 0;
> + ulong fw_len = 0, dt_len = 0;
> + int ret;
> +
> + ret = fit_image_load(&images, (ulong)header,
> +  NULL, &fit_uname_config,
> +  IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
> +  FIT_LOAD_REQUIRED, &fw_data, &fw_len);
> + if (ret < 0)
> + return ret;
> +
> + spl_image->size = fw_len;
> + spl_image->entry_point = fw_data;
> + spl_image->load_addr = fw_data;
> + spl_image->os = IH_OS_U_BOOT;
> + spl_image->name = "U-Boot";
> +
> + debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
> + (int)sizeof(spl_image->name), spl_image->name,
> + spl_image->load_addr, spl_image->size);
> +
> + ret = fit_image_load(&images, (ulong)header,
> +  &fit_uname_fdt, &fit_uname_config,
> +  IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
> +  FIT_LOAD_OPTIONAL, &dt_data, &dt_len);
> + return 0;
> +}
> +#endif
> +
>  int spl_parse_image_header(struct spl_image_info *spl_image,
>  const struct image_header *header)
>  {
> +#ifdef CONFIG_SPL_LOAD_FIT_FULL
> + int ret = spl_load_fit_image(spl_image, header);
> + if (!ret)
> + return ret;
> +#endif
>   if (image_get_magic(header) == IH_MAGIC) {
>  #ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT
>   u32 header_size = sizeof(struct image_header);

Despite this minor thing:

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH 6/9] spl: Add support for overlaying U-Boot DT

2017-12-28 Thread Lukasz Majewski
Hi Marek,

> Add support for loading fitImage with device tree overlay image, which
> is applied to the U-Boot's own device tree. Once the DT is applied,
> the fitImage loading process is restarted.
> 
> This patch allows a usecase where the DTO patches ie. load address in
> the U-Boot's DT or patches in a new public key for authenticating the
> subsequently loaded fitImages.
> 
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl.c | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index d429ea2c82..2444abbb08 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -140,6 +140,38 @@ void spl_set_header_raw_uboot(struct
> spl_image_info *spl_image) }
>  
>  #ifdef CONFIG_SPL_LOAD_FIT_FULL
> +#ifdef CONFIG_OF_LIBFDT_OVERLAY
> +static int spl_fit_overlay_uboot_fdt_full(const struct image_header
> *header) +{
> + bootm_headers_t images;
> + const char *fit_uname_config = NULL;
> + const char *fit_uname_dtbo = "u-boot-dtbo";
> + ulong dto_data = 0;
> + ulong dto_len = 0;
> + int ret;
> +
> + ret = fit_image_load(&images, (ulong)header,
> +  &fit_uname_dtbo, &fit_uname_config,
> +  IH_ARCH_DEFAULT, IH_TYPE_FLATDT, -1,
> +  FIT_LOAD_OPTIONAL, &dto_data, &dto_len);
> + if (ret < 0)
> + return 0;
> +
> + ret = fdt_overlay_apply_verbose((struct fdt_header
> *)gd->fdt_blob,
> + (void *)dto_data);
> + if (ret)
> + hang();
> +
> + /* Restart the loading process to cater for the DT changes */
> + return -EAGAIN;
> +}
> +#else
> +static int spl_fit_overlay_uboot_fdt_full(const struct image_header
> *header) +{
> + return 0;
> +}
> +#endif
> +
>  /* Parse and load full fitImage in SPL */
>  static int spl_load_fit_image(struct spl_image_info *spl_image,
> const struct image_header *header)
> @@ -152,6 +184,10 @@ static int spl_load_fit_image(struct
> spl_image_info *spl_image, ulong fw_len = 0, dt_len = 0;
>   int ret;
>  
> + ret = spl_fit_overlay_uboot_fdt_full(header);
> + if (ret)
> + return ret;
> +
>   ret = fit_image_load(&images, (ulong)header,
>NULL, &fit_uname_config,
>IH_ARCH_DEFAULT, IH_TYPE_STANDALONE, -1,
> @@ -182,7 +218,7 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image, {
>  #ifdef CONFIG_SPL_LOAD_FIT_FULL
>   int ret = spl_load_fit_image(spl_image, header);
> - if (!ret)
> + if (!ret || ret == -EAGAIN)
>   return ret;
>  #endif
>   if (image_get_magic(header) == IH_MAGIC) {

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH 7/9] spl: Restart loading if load_image returns -EAGAIN

2017-12-28 Thread Lukasz Majewski
Hi Marek,

> If the loader->load_image returns -EAGAIN, it is an indication
> the loading process should restart the loading, possible due to
> DTO being applied on the U-Boot's DT. Restart the loading until
> the loader stops returning -EAGAIN.
> 
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 2444abbb08..27f44c27b0 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -413,11 +413,16 @@ static int spl_load_image(struct spl_image_info
> *spl_image, struct spl_image_loader *loader)
>  {
>   struct spl_boot_device bootdev;
> + int ret;
>  
>   bootdev.boot_device = loader->boot_device;
>   bootdev.boot_device_name = NULL;
>  
> - return loader->load_image(spl_image, &bootdev);
> + do {
> + ret = loader->load_image(spl_image, &bootdev);
> + } while (ret == -EAGAIN);

Maybe it would be good to have some counter or timeout (although, I
doubt if any timer is set properly so early) to give the user some
information if we fail?

> +
> + return ret;
>  }
>  
>  /**



Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH 8/9] spl: ram: Add support for fetching image position from control DT

2017-12-28 Thread Lukasz Majewski
Hi Marek,

> Add support for fetching the image position in RAM from control DT
> rather than hard-coding it. While doing so, return the return value
> of spl_parse_header_image() to make it possible to test application
> of DTOs on U-Boot's control DT.
> 
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl_ram.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
> index fa8c768773..c88d09ba04 100644
> --- a/common/spl/spl_ram.c
> +++ b/common/spl/spl_ram.c
> @@ -14,12 +14,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
>  # define CONFIG_SPL_LOAD_FIT_ADDRESS 0
>  #endif
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  static ulong spl_ram_load_read(struct spl_load_info *load, ulong
> sector, ulong count, void *buf)
>  {
> @@ -33,7 +35,12 @@ static int spl_ram_load_image(struct
> spl_image_info *spl_image, struct spl_boot_device *bootdev)
>  {
>   struct image_header *header;
> + unsigned image_offs;
>  
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> + image_offs = fdtdec_get_config_int(gd->fdt_blob,
> +
> "u-boot,spl-image-offset", 0); +#endif
>   header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
>  
>  #if defined(CONFIG_SPL_DFU_SUPPORT)
> @@ -48,7 +55,7 @@ static int spl_ram_load_image(struct spl_image_info
> *spl_image, debug("Found FIT\n");
>   load.bl_len = 1;
>   load.read = spl_ram_load_read;
> - spl_load_simple_fit(spl_image, &load, 0, header);
> + return spl_load_simple_fit(spl_image, &load, 0,
> header); } else {
>   ulong u_boot_pos = binman_sym(ulong, u_boot_any,
> pos); 
> @@ -64,12 +71,16 @@ static int spl_ram_load_image(struct
> spl_image_info *spl_image,
>* No binman support or no information. For
> now, fix it
>* to the address pointed to by U-Boot.
>*/
> - u_boot_pos = CONFIG_SYS_TEXT_BASE -
> - sizeof(struct image_header);
> + if (image_offs)
> + u_boot_pos = image_offs;
> + else
> + u_boot_pos = CONFIG_SYS_TEXT_BASE -
> +  sizeof(struct
> image_u_boot_pos); }
>   header = (struct image_header
> *)map_sysmem(u_boot_pos, 0); 
> - spl_parse_image_header(spl_image, header);
> +
> + return spl_parse_image_header(spl_image, header);
>   }
>  
>   return 0;

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH 9/9] spl: spi: Add support for fetching image position from control DT

2017-12-28 Thread Lukasz Majewski
Hi Marek,

> Add support for fetching the image position in RAM from control DT
> rather than hard-coding it. While doing so, return the return value
> of spl_parse_header_image() to make it possible to test application
> of DTOs on U-Boot's control DT.
> 
> Signed-off-by: Marek Vasut 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
>  common/spl/spl_spi.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
> index 42880d56b9..c2613a494b 100644
> --- a/common/spl/spl_spi.c
> +++ b/common/spl/spl_spi.c
> @@ -75,6 +75,7 @@ static int spl_spi_load_image(struct spl_image_info
> *spl_image, unsigned payload_offs = CONFIG_SYS_SPI_U_BOOT_OFFS;
>   struct spi_flash *flash;
>   struct image_header *header;
> + unsigned image_offs, image_size;
>  
>   /*
>* Load U-Boot image from SPI flash into RAM
> @@ -96,6 +97,18 @@ static int spl_spi_load_image(struct
> spl_image_info *spl_image, payload_offs =
> fdtdec_get_config_int(gd->fdt_blob, "u-boot,spl-payload-offset",
>payload_offs);
> + image_offs = fdtdec_get_config_int(gd->fdt_blob,
> +
> "u-boot,spl-image-offset", 0);
> + image_size = fdtdec_get_config_int(gd->fdt_blob,
> +"u-boot,spl-image-size",
> 0);
> + if (image_size) {
> + err = spi_flash_read(flash, image_offs,
> +  image_size,
> +  (void *)CONFIG_SYS_TEXT_BASE);
> + if (err)
> + return err;
> + return spl_parse_image_header(spl_image, header);
> + }
>  #endif
>  
>  #ifdef CONFIG_SPL_OS_BOOT

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

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


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


[U-Boot] [PATCH] ARM: mvebu: Allow MVNETA to be selected with Armada 3700 SoCs

2017-12-28 Thread Miquel Raynal
Until now, Armada 3700 SoCs could not enable the mvneta driver, and thus
did not benefit from Ethernet support. Add ARMADA_3700 in the
"depends on" list of the MVNETA Kconfig entry.

Signed-off-by: Miquel Raynal 
---
 drivers/net/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index d67927cd3b..4bb0201989 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -160,12 +160,12 @@ config FTMAC100
  This MAC is present in Andestech SoCs.
 
 config MVNETA
-   bool "Marvell Armada 385 network interface support"
-   depends on ARMADA_XP || ARMADA_38X
+   bool "Marvell Armada XP/385/3700 network interface support"
+   depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
select PHYLIB
help
  This driver supports the network interface units in the
- Marvell ARMADA XP and 38X SoCs
+ Marvell ARMADA XP, ARMADA 38X and ARMADA 3700 SoCs
 
 config MVPP2
bool "Marvell Armada 375/7K/8K network interface support"
-- 
2.11.0

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


Re: [U-Boot] [PATCH v10 00/27] dm: Generic MTD Subsystem, with SPI-NOR interface

2017-12-28 Thread Lukasz Majewski
Hi Jagan,

> Compared to previous series’s [1], [2], [3] and [4] this patch set
> redefined most of the implementation suitable to fit into existing
> driver-model.
> 
> MTD is generic subsystem for underlying flash devices like nand,
> parallel nor, spinor, dataflash etc. So to drive this theory with
> driver model(with an example of block layer) mtd is common device
> interaction for most of  memory technology flashes like nand,
> parallel nor, spinor, dataflash etc, these are treated as interface
> types wrt u-boot driver model.
> 
> Once the respective interface driver bind happen, the uclass driver
> will pass an 'interface type' to mtd layer to create device for it,
> for example once spinor ULASS_SPI_NOR driver bind happen,
> the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR 
> interface type to create mtd device for spinor devices.
> 
> SPI-NOR:
> ===
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> 
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver.

I must admit that I'm a bit confused

If you don't mind I would like to ask for clarification of a few things:



> 
> ===
>  cmd/spinor.c

^ - this would be a new set of commands to comply
with DM? 

What about "sf" command which we use now to get access
to SPI-NOR memory? A lot of boards already use "sf"
command... which may be tricky to replace.

> ===
>  mtd-uclass.c
^ - here we will have a generic MTD layer (as it is
in Linux)

> ===
>spi-nor-uclass.c
> ===
>   spi-nor.c
^^ - why do we need to have spi-nor.c ? Cannot we
have its functionality in the spi-nor-uclass.c ?
(I'm just curious)

> ===
> m25p80.czynq_qspinor.c
  ^ - this is the  - [*]
"generic" spi-nor
driver used in Linux. 
I suppose that it will
be reused here?

> ===
> spi-uclass.c
  ^^^ - why do we
need this uclass?

> ===
> zynq_qspi.c
 ^ - This is probably
the low-level driver for
zynq QSPI IP block - why
do we have zynq_qspinor.c file above [*]?
What is the difference/need of such division?

> ===
> #SPI NOR chip##
> ===
> 
> Changes for v10:
> - Update Simon's R-B tag
> - Add mtd dm test case
> - implemented entire code wrt MTD, with interface type
> 
> code size:
> ==
> before:
> $ arm-linux-gnueabi-size u-boot
>text  data bss dec
> hex   filename 473712   15152  222568
> 711432  adb08 u-boot $ du -hs u-boot-dtb.img 
> 488K  u-boot-dtb.img
> 
> after:
> $ arm-linux-gnueabi-size u-boot
>text  data bss dec
> hex   filename 470124   14352  222584
> 707060  ac9f4 u-boot $ du -hs u-boot-dtb.img 
> 484K  u-boot-dtb.img
> 
> approximately 4KiB but DM_SPI_FLASH still there which
> can be removed once support added in SPL
> 
> test log:
> 
> Zynq> spinor  
> spinor - SPI-NOR Sub-system
> 
> Usage:
> spinor list - show list of spinor devices
> spinor info - show current spinor device info
> spinor dev [devnum] - show or set current spinor device
> spinor erase offset len - erase 'len' bytes from 'offset'
> spinor write addr to len- write 'len' bytes to 'to' from
  I would love to see support for "mtdparts="
It would facilitate handling SPI-NOR "partitions" like
u-boot/SPI/envs/ etc.

I also suppose that "sf probe" (or any its replacement with spinor)
would be not necessary to call before using other SPI-NOR related
commands?


Maybe the biggest request - would it be possible to
add ./doc/README.spi-nor entry with good explanation of this?




> 'addr' spinor read addr from len   - read 'len' bytes from 'from'
> to 'addr' spinor protect lock/unlock sector len - protect/unprotect
> 'len' bytes starting at address 'sector'
> Zynq> spinor list  
> flash@0: 0
> spi-nor@e000d000: 1
> Zynq> spinor dev 

[U-Boot] [PATCH v3 0/6] arm: ti: misc updates and bug fixes

2017-12-28 Thread Lokesh Vutla
This series consolidates few bug fixes on TI platforms.

Changes since v2:
- Added a new patch for making in file structures static.

Lokesh Vutla (4):
  configs: k2g_evm: Allocate more space for u-boot
  tools: omapimage: Fix mismatch of image size in header
  arm: am33xx: Avoid writing into reserved DPLL divider
  board: ti: k2g: Make ddr3* declarations as static

Rex Chang (1):
  board: ti: K2G FC SoC 1GHz and DDR3 1066 MT/s support

Tomi Valkeinen (1):
  board: ti: dra76: mux wakeup2 as gpio1_2

 arch/arm/mach-keystone/include/mach/hardware.h |  3 ++
 arch/arm/mach-keystone/init.c  | 17 ++-
 arch/arm/mach-omap2/am33xx/clock_am33xx.c  | 12 ++---
 board/ti/dra7xx/mux_data.h |  2 +-
 board/ti/ks2_evm/board.h   |  4 ++
 board/ti/ks2_evm/board_k2g.c   | 32 ++---
 board/ti/ks2_evm/ddr3_k2g.c| 65 +++---
 board/ti/ks2_evm/mux-k2g.h |  2 +-
 include/configs/k2g_evm.h  |  6 ++-
 tools/omapimage.c  |  2 +-
 10 files changed, 119 insertions(+), 26 deletions(-)

-- 
2.15.1

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


[U-Boot] [PATCH v3 1/6] configs: k2g_evm: Allocate more space for u-boot

2017-12-28 Thread Lokesh Vutla
Now that we have multi dtb enabled in u-boot allocate
128K space for u-boot.

Signed-off-by: Lokesh Vutla 
---
 include/configs/k2g_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index df81c09d86..9282a22739 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -74,7 +74,7 @@
 #endif
 
 /* SPL SPI Loader Configuration */
-#define CONFIG_SPL_TEXT_BASE   0x0c08
+#define CONFIG_SPL_TEXT_BASE   0x0c0a
 
 /* NAND Configuration */
 #define CONFIG_SYS_NAND_PAGE_2K
-- 
2.15.1

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


[U-Boot] [PATCH v3 2/6] board: ti: K2G FC SoC 1GHz and DDR3 1066 MT/s support

2017-12-28 Thread Lokesh Vutla
From: Rex Chang 

Added support for K2G EVM with FlipChip SoC of which
ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
backward compatible with old revision EVM and EVM
with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.

The new SoC supports 2 different speeds at 1GHz and 600MHz.
Modyfied the CPU Name to show which SoC is used in the EVM.
Modified the DDR3 configuration to reflect New SoC supports
2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.

Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
and set the u-boot env variable board_name accordingly.

Modified findfdt script in u-boot environment variable to include new k2g board 
type.

Signed-off-by: Rex Chang 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-keystone/include/mach/hardware.h |  3 ++
 arch/arm/mach-keystone/init.c  | 17 +++-
 board/ti/ks2_evm/board.h   |  4 ++
 board/ti/ks2_evm/board_k2g.c   | 32 +++
 board/ti/ks2_evm/ddr3_k2g.c| 57 +-
 board/ti/ks2_evm/mux-k2g.h |  2 +-
 include/configs/k2g_evm.h  |  4 +-
 7 files changed, 106 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index 6629406870..5d08418eb9 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -327,6 +327,9 @@ typedef volatile unsigned int   *dv_reg_p;
 #define CPU_66AK2Lx0xb9a7
 #define CPU_66AK2Gx0xbb06
 
+/* Variant definitions */
+#define CPU_66AK2G1x   0x08
+
 /* DEVSPEED register */
 #define DEVSPEED_DEVSPEED_SHIFT16
 #define DEVSPEED_DEVSPEED_MASK (0xfff << 16)
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 6e5a1e1af1..f9c03f1dd1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -229,7 +229,19 @@ int print_cpuinfo(void)
puts("66AK2Ex SR");
break;
case CPU_66AK2Gx:
-   puts("66AK2Gx SR");
+   puts("66AK2Gx");
+#ifdef CONFIG_SOC_K2G
+   {
+   int speed = get_max_arm_speed(speeds);
+   if (speed == SPD1000)
+   puts("-100 ");
+   else if (speed == SPD600)
+   puts("-60 ");
+   else
+   puts("-xx ");
+   }
+#endif
+   puts("SR");
break;
default:
puts("Unknown\n");
@@ -241,7 +253,8 @@ int print_cpuinfo(void)
puts("1.1\n");
else if (rev == 0)
puts("1.0\n");
-
+   else if (rev == 8)
+   puts("1.0\n");
return 0;
 }
 #endif
diff --git a/board/ti/ks2_evm/board.h b/board/ti/ks2_evm/board.h
index b3ad1881fa..48d60a1c74 100644
--- a/board/ti/ks2_evm/board.h
+++ b/board/ti/ks2_evm/board.h
@@ -20,6 +20,10 @@ static inline int board_is_k2g_gp(void)
 {
return board_ti_is("66AK2GGP");
 }
+static inline int board_is_k2g_g1(void)
+{
+   return board_ti_is("66AK2GG1");
+}
 static inline int board_is_k2g_ice(void)
 {
return board_ti_is("66AK2GIC");
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 01328f1955..88df419b10 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -55,7 +55,7 @@ unsigned int get_external_clk(u32 clk)
return clk_freq;
 }
 
-static int arm_speeds[DEVSPEED_NUMSPDS] = {
+int speeds[DEVSPEED_NUMSPDS] = {
SPD400,
SPD600,
SPD800,
@@ -159,13 +159,20 @@ static struct pll_init_data nss_pll_config[MAX_SYSCLK] = {
[SYSCLK_26MHz] = {NSS_PLL, 1000, 13, 2},
 };
 
-static struct pll_init_data ddr3_pll_config[MAX_SYSCLK] = {
+static struct pll_init_data ddr3_pll_config_800[MAX_SYSCLK] = {
[SYSCLK_19MHz] = {DDR3A_PLL, 167, 1, 16},
[SYSCLK_24MHz] = {DDR3A_PLL, 133, 1, 16},
[SYSCLK_25MHz] = {DDR3A_PLL, 128, 1, 16},
[SYSCLK_26MHz] = {DDR3A_PLL, 123, 1, 16},
 };
 
+static struct pll_init_data ddr3_pll_config_1066[MAX_SYSCLK] = {
+   [SYSCLK_19MHz] = {DDR3A_PLL, 194, 1, 14},
+   [SYSCLK_24MHz] = {DDR3A_PLL, 156, 1, 14},
+   [SYSCLK_25MHz] = {DDR3A_PLL, 149, 1, 14},
+   [SYSCLK_26MHz] = {DDR3A_PLL, 144, 1, 14},
+};
+
 struct pll_init_data *get_pll_init_data(int pll)
 {
int speed;
@@ -178,7 +185,7 @@ struct pll_init_data *get_pll_init_data(int pll)
data = &main_pll_config[sysclk_index][speed];
break;
case TETRIS_PLL:
-   speed = get_max_arm_speed(arm_speeds);
+   speed = get_max_arm_speed(speeds);
data = &tetris_pll_config[sysclk_index][speed];
break;
case NSS_PLL:
@@ -188,7 +195,15 @@ struct pll_init_data *get_pll_init_data(int pll)

[U-Boot] [PATCH v3 5/6] board: ti: dra76: mux wakeup2 as gpio1_2

2017-12-28 Thread Lokesh Vutla
From: Tomi Valkeinen 

gpio1_2 is used for HPD interrupt with DRA76's DVI add-on board, so mux
the pin as gpio and PIN_INPUT.

Signed-off-by: Tomi Valkeinen 
---
 board/ti/dra7xx/mux_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 3c3a19a0e1..b5dcaa584a 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -882,7 +882,7 @@ const struct pad_conf_entry dra76x_core_padconf_array[] = {
{I2C2_SCL, (M1 | PIN_INPUT_PULLUP)},/* i2c2_scl.hdmi1_ddc_sda */
{WAKEUP0, (M14 | PIN_OUTPUT)},  /* N/A.gpio1_0 */
{WAKEUP1, (M14 | PIN_OUTPUT)},  /* N/A.gpio1_1 */
-   {WAKEUP2, (M1 | PIN_OUTPUT)},   /* N/A.sys_nirq2 */
+   {WAKEUP2, (M14 | PIN_INPUT)},   /* N/A.gpio1_2 */
{WAKEUP3, (M1 | PIN_OUTPUT)},   /* N/A.sys_nirq1 */
 };
 
-- 
2.15.1

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


[U-Boot] [PATCH v3 3/6] tools: omapimage: Fix mismatch of image size in header

2017-12-28 Thread Lokesh Vutla
The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage tool is updating size
as image size + 2 * header size. Remove this extra header size bytes.

Reported-by: Denys Dmytriyenko 
Debugged-by: Madan Srinivas 
Signed-off-by: Lokesh Vutla 
---
 tools/omapimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/omapimage.c b/tools/omapimage.c
index e7c46388f4..01e02649e1 100644
--- a/tools/omapimage.c
+++ b/tools/omapimage.c
@@ -145,7 +145,7 @@ static void omapimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
toc++;
memset(toc, 0xff, sizeof(*toc));
 
-   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE + GPIMAGE_HDR_SIZE,
+   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE,
   params->addr, 0);
 
if (strncmp(params->imagename, "byteswap", 8) == 0) {
-- 
2.15.1

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


[U-Boot] [PATCH v3 4/6] arm: am33xx: Avoid writing into reserved DPLL divider

2017-12-28 Thread Lokesh Vutla
DPLL DRR doesn't have an M4 divider. But the clock driver is trying
to configure M4 divider as 4(writing into a reserved register).
Fixing it by making M4 divider as -1.

Reported-by: Steve Kipisz 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/clock_am33xx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c 
b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
index 1780bbdb6f..2352c37822 100644
--- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
+++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
@@ -109,22 +109,22 @@ const struct dpll_params 
dpll_per_192MHz[NUM_CRYSTAL_FREQ] = {
 const struct dpll_params dpll_ddr3_303MHz[NUM_CRYSTAL_FREQ] = {
{505, 15, 2, -1, -1, -1, -1}, /*19.2*/
{101, 3, 2, -1, -1, -1, -1}, /* 24 MHz */
-   {303, 24, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {303, 12, 2, -1, 4, -1, -1}  /* 26 MHz */
+   {303, 24, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {303, 12, 2, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 const struct dpll_params dpll_ddr3_400MHz[NUM_CRYSTAL_FREQ] = {
{125, 5, 1, -1, -1, -1, -1}, /*19.2*/
{50, 2, 1, -1, -1, -1, -1}, /* 24 MHz */
-   {16, 0, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {200, 12, 1, -1, 4, -1, -1}  /* 26 MHz */
+   {16, 0, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {200, 12, 1, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 const struct dpll_params dpll_ddr2_266MHz[NUM_CRYSTAL_FREQ] = {
{665, 47, 1, -1, -1, -1, -1}, /*19.2*/
{133, 11, 1, -1, -1, -1, -1}, /* 24 MHz */
-   {266, 24, 1, -1, 4, -1, -1}, /* 25 MHz */
-   {133, 12, 1, -1, 4, -1, -1}  /* 26 MHz */
+   {266, 24, 1, -1, -1, -1, -1}, /* 25 MHz */
+   {133, 12, 1, -1, -1, -1, -1}  /* 26 MHz */
 };
 
 __weak const struct dpll_params *get_dpll_mpu_params(void)
-- 
2.15.1

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


[U-Boot] [PATCH v3 6/6] board: ti: k2g: Make ddr3* declarations as static

2017-12-28 Thread Lokesh Vutla
All ddr3_emif declarations are not used outside ddr3_k2g.c
file. So make all of them as static.

Signed-off-by: Lokesh Vutla 
---
 board/ti/ks2_evm/ddr3_k2g.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
index 6f6fce6a24..3398246e28 100644
--- a/board/ti/ks2_evm/ddr3_k2g.c
+++ b/board/ti/ks2_evm/ddr3_k2g.c
@@ -14,7 +14,7 @@
 #include "board.h"
 
 /* K2G GP EVM DDR3 Configuration */
-struct ddr3_phy_config ddr3phy_800_2g = {
+static struct ddr3_phy_config ddr3phy_800_2g = {
.pllcr  = 0x000DC000ul,
.pgcr1_mask = (IODDRM_MASK | ZCKSEL_MASK),
.pgcr1_val  = ((1 << 2) | (1 << 7) | (1 << 23)),
@@ -94,7 +94,7 @@ static struct ddr3_phy_config ddr3phy_1066_2g = {
.pir_v2 = 0x0F81ul,
 };
 
-struct ddr3_emif_config ddr3_800_2g = {
+static struct ddr3_emif_config ddr3_800_2g = {
.sdcfg  = 0x62005662ul,
.sdtim1 = 0x0A385033ul,
.sdtim2 = 0x1CA5ul,
@@ -104,7 +104,7 @@ struct ddr3_emif_config ddr3_800_2g = {
.sdrfc  = 0x0C34ul,
 };
 
-struct ddr3_emif_config ddr3_1066_2g = {
+static struct ddr3_emif_config ddr3_1066_2g = {
.sdcfg  = 0x62005662ul,
.sdtim1 = 0x0E4C6843ul,
.sdtim2 = 0x1CC6ul,
@@ -115,7 +115,7 @@ struct ddr3_emif_config ddr3_1066_2g = {
 };
 
 /* K2G ICE evm DDR3 Configuration */
-struct ddr3_phy_config ddr3phy_800_512mb = {
+static struct ddr3_phy_config ddr3phy_800_512mb = {
.pllcr  = 0x000DC000ul,
.pgcr1_mask = (IODDRM_MASK | ZCKSEL_MASK),
.pgcr1_val  = ((1 << 2) | (2 << 7) | (1 << 23)),
@@ -155,7 +155,7 @@ struct ddr3_phy_config ddr3phy_800_512mb = {
.pir_v2 = 0x0F81ul,
 };
 
-struct ddr3_emif_config ddr3_800_512mb = {
+static struct ddr3_emif_config ddr3_800_512mb = {
.sdcfg  = 0x62006662ul,
.sdtim1 = 0x0A385033ul,
.sdtim2 = 0x1CA5ul,
-- 
2.15.1

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


Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Tom Rini
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:

> This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> 
> Signed-off-by: Derald D. Woods 
> ---
>  include/configs/omap3_evm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index 629d60b961..d95ccdf035 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -127,6 +127,7 @@
>   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
>   "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
>   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> + "fdt_high=0x\0" \
>   "bootenv=uEnv.txt\0" \
>   "optargs=\0" \
>   "mmcdev=0\0" \

What's the problem this solves, and how much memory is on the system in
question?  bootm_size should be ensuring we never relocate it outside of
the first 256MB of memory.  Thanks!

-- 
Tom


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


[U-Boot] [PATCH] dt-bindings: leds: adopt Linux PCA9532 binding constants

2017-12-28 Thread Felix Brack
I'm working on a v2 patch to add support for a board named pdu001. Its
Linux DTS file uses the include file added by this patch. To keep Linux
and U-Boot DTS files in sync U-Boot requires a copy of this file,
although there is no driver for NXP's PCA9532 i2c LED driver chip (yet).

Signed-off-by: Felix Brack 
---

 include/dt-bindings/leds/leds-pca9532.h | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 include/dt-bindings/leds/leds-pca9532.h

diff --git a/include/dt-bindings/leds/leds-pca9532.h 
b/include/dt-bindings/leds/leds-pca9532.h
new file mode 100644
index 000..4d917aa
--- /dev/null
+++ b/include/dt-bindings/leds/leds-pca9532.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides constants for pca9532 LED bindings.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _DT_BINDINGS_LEDS_PCA9532_H
+#define _DT_BINDINGS_LEDS_PCA9532_H
+
+#define PCA9532_TYPE_NONE 0
+#define PCA9532_TYPE_LED  1
+#define PCA9532_TYPE_N2100_BEEP   2
+#define PCA9532_TYPE_GPIO 3
+#define PCA9532_LED_TIMER24
+
+#endif /* _DT_BINDINGS_LEDS_PCA9532_H */
-- 
2.7.4

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


Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Derald D. Woods
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> 
> > This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> > 
> > Signed-off-by: Derald D. Woods 
> > ---
> >  include/configs/omap3_evm.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> > index 629d60b961..d95ccdf035 100644
> > --- a/include/configs/omap3_evm.h
> > +++ b/include/configs/omap3_evm.h
> > @@ -127,6 +127,7 @@
> > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > +   "fdt_high=0x\0" \
> > "bootenv=uEnv.txt\0" \
> > "optargs=\0" \
> > "mmcdev=0\0" \
> 
> What's the problem this solves, and how much memory is on the system in
> question?  bootm_size should be ensuring we never relocate it outside of
> the first 256MB of memory.  Thanks!
> 

The logic within "common/image-fdt.c" lead me down this path. The
addition of this fairly common environment variable allowed my
OMAP34XX board to boot the kernel without an appended devicetree.
When I use the variable to trigger 'disable_relocation', as the code
indicates, the kernel boot behavior is what I expect. I spent a few
hours following the code path to a single line edition that works.


Without 'fdt_high'
==

U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP35XX EVM (TMDSEVM3530)
OMAP3 EVM board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
Read back SMSC id 0x9220
OMAP die ID: 265a0024040365fa1801b01f
Net:   smc911x-0
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
** Unable to read file uEnv.txt **
reading zImage
4637344 bytes read in 407 ms (10.9 MiB/s)
reading omap3-evm.dtb
62832 bytes read in 10 ms (6 MiB/s)
Booting zImage from mmc ...
*  fdt: cmdline image address = 0x8800
## Checking for 'FDT'/'FDT Image' at 8800
*  fdt: raw FDT blob
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   of_flat_tree at 0x8800 size 0xf570
## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
   Loading Device Tree to 8ffed000, end 856f ... OK

Starting kernel ...

[HANG]


Make note of the "of_flat_tree" and "Loading Device Tree" lines.


With 'fdt_high=0x'
==

U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:24:25)
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:24:25 -0600)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP35XX EVM (TMDSEVM3530)
OMAP3 EVM board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
Read back SMSC id 0x9220
OMAP die ID: 265a0024040365fa1801b01f
Net:   smc911x-0
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
** Unable to read file uEnv.txt **
reading zImage
4637344 bytes read in 407 ms (10.9 MiB/s)
reading omap3-evm.dtb
62832 bytes read in 10 ms (6 MiB/s)
Booting zImage from mmc ...
*  fdt: cmdline image address = 0x8800
## Checking for 'FDT'/'FDT Image' at 8800
*  fdt: raw FDT blob
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   of_flat_tree at 0x8800 size 0xf570
   Using Device Tree in place at 8800, end 8801256f

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc 
version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) 
#17 PREEMPT Wed Dec 27 22:59:37 CST 2017
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530)
[0.00] Memory policy: Data cache writeback
[0.00] cma: Reserved 16 MiB at 0x8e80
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp)
[0.00] random: fast init done
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 64706
[0.00] Kernel command line: console=ttyO0,115200n8 
mtdp

Re: [U-Boot] [PATCH 00/23] Fix and extend i.MX HAB layer

2017-12-28 Thread Breno Matheus Lima
Hi Bryan,

2017-12-27 10:25 GMT-02:00 Bryan O'Donoghue :
> This patchset updates the i.MX HAB layer in u-boot to fix a list of
> identified issues and then to add and extend existing functionality.
>
> The first block of patches 0001-0006 deal with fixing existing code,
>
> - Fixes indentation
> - Fixes the treatment of input parameters to hab_auth_image.
>
> The second block of patches 0007-0013 are about tidying up the HAB code
>
> - Remove reliance on hard-coding to specific offsets
> - IVT header drives locating CSF
> - Continue to support existing boards
>
> Patches 0014 onwards extend out the HAB functionality.
>
> - hab_rvt_check_target is a recommended check in the NXP documents to
>   perform prior to hab_rvt_authenticate_image
> - hab_rvt_failsafe is a useful function to set the board into BootROM
>   USB recovery mode.
>
> Bryan O'Donoghue (23):
>   arm: imx: hab: Make authenticate_image return int
>   arm: imx: hab: Fix authenticate_image result code
>   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
>   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
>   arm: imx: hab: Fix authenticate_image input parameters

After applying "[PATCH 05/23] arm: imx: hab: Fix authenticate_image
input parameters" I'm getting the following error when building
mx6sabreauto:

arch/arm/mach-imx/spl.c: In function 'jump_to_image_no_args':
arch/arm/mach-imx/spl.c:200:14: error: 'IVT_SIZE' undeclared (first
use in this function)
 offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
  ^
arch/arm/mach-imx/spl.c:200:14: note: each undeclared identifier is
reported only once for each function it appears in
arch/arm/mach-imx/spl.c:200:25: error: 'CSF_PAD_SIZE' undeclared
(first use in this function)
 offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
 ^
arch/arm/mach-imx/spl.c:206:1: warning: 'noreturn' function does return
 }
 ^
scripts/Makefile.build:280: recipe for target
'spl/arch/arm/mach-imx/spl.o' failed
make[2]: *** [spl/arch/arm/mach-imx/spl.o] Error 1
make[2]: *** Waiting for unfinished jobs

>   arm: imx: hab: Fix authenticate image lockup on MX7
>   arm: imx: hab: Move IVT_SIZE to hab.h
>   arm: imx: hab: Move CSF_PAD_SIZE to hab.h

I believe patches "[PATCH 07/23] arm: imx: hab: Move IVT_SIZE to
hab.h" and "[PATCH 08/23] arm: imx: hab: Move CSF_PAD_SIZE to hab.h"
have to be applied before the [PATCH 05/23] to avoid this build error.
Can you please check if it's possible to move these patches?

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


Re: [U-Boot] [PATCH 00/23] Fix and extend i.MX HAB layer

2017-12-28 Thread Bryan O'Donoghue



On 28/12/17 17:54, Breno Matheus Lima wrote:

Hi Bryan,

2017-12-27 10:25 GMT-02:00 Bryan O'Donoghue :

This patchset updates the i.MX HAB layer in u-boot to fix a list of
identified issues and then to add and extend existing functionality.

The first block of patches 0001-0006 deal with fixing existing code,

- Fixes indentation
- Fixes the treatment of input parameters to hab_auth_image.

The second block of patches 0007-0013 are about tidying up the HAB code

- Remove reliance on hard-coding to specific offsets
- IVT header drives locating CSF
- Continue to support existing boards

Patches 0014 onwards extend out the HAB functionality.

- hab_rvt_check_target is a recommended check in the NXP documents to
   perform prior to hab_rvt_authenticate_image
- hab_rvt_failsafe is a useful function to set the board into BootROM
   USB recovery mode.

Bryan O'Donoghue (23):
   arm: imx: hab: Make authenticate_image return int
   arm: imx: hab: Fix authenticate_image result code
   arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
   arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
   arm: imx: hab: Fix authenticate_image input parameters


After applying "[PATCH 05/23] arm: imx: hab: Fix authenticate_image
input parameters" I'm getting the following error when building
mx6sabreauto:


That's funny. I just build mx6sabreauto_config + CONFIG_SECURE_BOOT and 
it works.


I'll rebase and build each patch incrementally - obviously there's some 
breakage with your configuration.


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


Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Tom Rini
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > 
> > > This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> > > 
> > > Signed-off-by: Derald D. Woods 
> > > ---
> > >  include/configs/omap3_evm.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> > > index 629d60b961..d95ccdf035 100644
> > > --- a/include/configs/omap3_evm.h
> > > +++ b/include/configs/omap3_evm.h
> > > @@ -127,6 +127,7 @@
> > >   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > >   "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > >   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > + "fdt_high=0x\0" \
> > >   "bootenv=uEnv.txt\0" \
> > >   "optargs=\0" \
> > >   "mmcdev=0\0" \
> > 
> > What's the problem this solves, and how much memory is on the system in
> > question?  bootm_size should be ensuring we never relocate it outside of
> > the first 256MB of memory.  Thanks!
> > 
> 
> The logic within "common/image-fdt.c" lead me down this path. The
> addition of this fairly common environment variable allowed my
> OMAP34XX board to boot the kernel without an appended devicetree.
> When I use the variable to trigger 'disable_relocation', as the code
> indicates, the kernel boot behavior is what I expect. I spent a few
> hours following the code path to a single line edition that works.
> 
> 
> Without 'fdt_high'
> ==
> 
> U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> Trying to boot from MMC1
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
> 
> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> Model: TI OMAP35XX EVM (TMDSEVM3530)
> OMAP3 EVM board + LPDDR/NAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  256 MiB
> MMC:   OMAP SD/MMC: 0
> Read back SMSC id 0x9220
> OMAP die ID: 265a0024040365fa1801b01f
> Net:   smc911x-0
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> switch to partitions #0, OK
> mmc0 is current device
> ** Unable to read file uEnv.txt **
> reading zImage
> 4637344 bytes read in 407 ms (10.9 MiB/s)
> reading omap3-evm.dtb
> 62832 bytes read in 10 ms (6 MiB/s)
> Booting zImage from mmc ...
> *  fdt: cmdline image address = 0x8800
> ## Checking for 'FDT'/'FDT Image' at 8800
> *  fdt: raw FDT blob
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>of_flat_tree at 0x8800 size 0xf570
> ## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
>Loading Device Tree to 8ffed000, end 856f ... OK
> 
> Starting kernel ...
> 
> [HANG]
> 
> 
> Make note of the "of_flat_tree" and "Loading Device Tree" lines.

Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
0x0a00 ?  I wonder if, since you have 256MB of memory we're not
putting the DTB into where U-Boot is and we stomp on it a bit, causing
Linux to boot, see an invalid DTB and not have a console available to
tell us.  Thanks!

-- 
Tom


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


[U-Boot] [PATCH v2 00/23]Fix and extend i.MX HAB layer

2017-12-28 Thread Bryan O'Donoghue
v2:
- Fix compilation warnings and errors in SPL highlighted by 
  Breno Matheus Lima

- Add CC: Breno Matheus Lima  to all patches

v1:
This patchset updates the i.MX HAB layer in u-boot to fix a list of
identified issues and then to add and extend existing functionality.

The first block of patches 0001-0006 deal with fixing existing code,

- Fixes indentation
- Fixes the treatment of input parameters to hab_auth_image.

The second block of patches 0007-0013 are about tidying up the HAB code

- Remove reliance on hard-coding to specific offsets
- IVT header drives locating CSF
- Continue to support existing boards

Patches 0014 onwards extend out the HAB functionality.

- hab_rvt_check_target is a recommended check in the NXP documents to
  perform prior to hab_rvt_authenticate_image
- hab_rvt_failsafe is a useful function to set the board into BootROM
  USB recovery mode.


Bryan O'Donoghue (23):
  arm: imx: hab: Make authenticate_image return int
  arm: imx: hab: Fix authenticate_image result code
  arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
  arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
  arm: imx: hab: Move IVT_SIZE to hab.h
  arm: imx: hab: Move CSF_PAD_SIZE to hab.h
  arm: imx: hab: Fix authenticate_image input parameters
  arm: imx: hab: Fix authenticate image lockup on MX7
  arm: imx: hab: Add IVT header definitions
  arm: imx: hab: Add IVT header verification
  arm: imx: hab: Verify IVT self matches calculated address
  arm: imx: hab: Print CSF based on IVT descriptor
  arm: imx: hab: Print additional IVT elements during debug
  arm: imx: hab: Define rvt_check_target()
  arm: imx: hab: Implement hab_rvt_check_target
  arm: imx: hab: Add a hab_rvt_check_target to image auth
  arm: imx: hab: Make internal functions and data static
  arm: imx: hab: Prefix authenticate_image with imx_hab
  arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled
  arm: imx: hab: Make imx_hab_is_enabled global
  arm: imx: hab: Define rvt_failsafe()
  arm: imx: hab: Implement hab_rvt_failsafe
  arm: imx: hab: Add hab_failsafe console command

 arch/arm/include/asm/mach-imx/hab.h |  46 +++-
 arch/arm/mach-imx/hab.c | 476 ++--
 arch/arm/mach-imx/spl.c |  38 ++-
 3 files changed, 368 insertions(+), 192 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH v2 01/23] arm: imx: hab: Make authenticate_image return int

2017-12-28 Thread Bryan O'Donoghue
Both usages of authenticate_image treat the result code as a simple binary.
The command line usage of authenticate_image directly returns the result
code of authenticate_image as a success/failure code.

Right now when calling hab_auth_img and test the result code in a shell a
passing hab_auth_img will appear to the shell as a fail.

The first step in fixing this behaviour is to fix-up the result code return
by authenticate_image() itself, subsequent patches fix the interpretation
of authenticate_image so that zero will return CMD_RET_SUCCESS and non-zero
will return CMD_RET_FAILURE.

The first step is fixing the return type in authenticate_image() so do that
now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 +-
 arch/arm/mach-imx/hab.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index e0ff459..1b7a5e4 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -145,6 +145,6 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-uint32_t authenticate_image(uint32_t ddr_start, uint32_t image_size);
+int authenticate_image(uint32_t ddr_start, uint32_t image_size);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 02c7ae4..09892a6 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -410,7 +410,7 @@ static bool is_hab_enabled(void)
return (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
 }
 
-uint32_t authenticate_image(uint32_t ddr_start, uint32_t image_size)
+int authenticate_image(uint32_t ddr_start, uint32_t image_size)
 {
uint32_t load_addr = 0;
size_t bytes;
-- 
2.7.4

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


[U-Boot] [PATCH v2 07/23] arm: imx: hab: Fix authenticate_image input parameters

2017-12-28 Thread Bryan O'Donoghue
u-boot command "hab_auth_img" tells a user that it takes

- addr - image hex length
- offset - hex offset of IVT in the image

but in fact the callback hab_auth_img makes to authenticate_image treats
the second 'offset' parameter as an image length.

Furthermore existing code requires the IVT header to be appended to the end
of the image which is not actually a requirement of HABv4.

This patch fixes this situation by

1: Adding a new parameter to hab_auth_img
   - addr   : image hex address
   - length : total length of the image
   - offset : offset of IVT from addr

2: Updates the existing call into authenticate_image() in
   arch/arm/mach-imx/spl.c:jump_to_image_no_args() to pass
   addr, length and IVT offset respectively.

This allows then hab_auth_img to actually operate the way it was specified
in the help text and should still allow existing code to work.

It has the added advantage that the IVT header doesn't have to be appended
to an image given to HAB - it can be prepended for example.

Note prepending the IVT is what u-boot will do when making an IVT for the
BootROM. It should be possible for u-boot properly authenticate images
made by mkimage via HAB.

This patch is the first step in making that happen subsequent patches will
focus on removing hard-coded offsets to the IVT, which again is not
mandated to live at the end of a .imx image.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h |  3 +-
 arch/arm/mach-imx/hab.c | 73 +++--
 arch/arm/mach-imx/spl.c | 35 +-
 3 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 91dda42..b2a8031 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -148,6 +148,7 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size);
+int authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 039a017..2a40d06 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -78,37 +78,6 @@
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-/*
- * ++  0x0 (DDR_UIMAGE_START) -
- * |   Header   |  |
- * ++  0x40|
- * ||  |
- * ||  |
- * ||  |
- * ||  |
- * | Image Data |  |
- * .|  |
- * .|   > Stuff to be authenticated +
- * .|  ||
- * ||  ||
- * ||  ||
- * ++  ||
- * ||  ||
- * | Fill Data  |  ||
- * ||  ||
- * ++ Align to ALIGN_SIZE  ||
- * |IVT |  ||
- * ++ + IVT_SIZE  - |
- * ||   |
- * |  CSF DATA  | <-+
- * ||
- * ++
- * ||
- * | Fill Data  |
- * ||
- * ++ + CSF_PAD_SIZE
- */
-
 static bool is_hab_enabled(void);
 
 #if !defined(CONFIG_SPL_BUILD)
@@ -361,20 +330,22 @@ int do_hab_status(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
-   ulong   addr, ivt_offset;
+   ulong   addr, length, ivt_offset;
int rcode = 0;
 
-   if (argc < 3)
+   if (argc < 4)
return CMD_RET_USAGE;
 
addr = simple_strtoul(argv[1], NULL, 16);
-   ivt_offset = simple_strtoul(argv[2], NULL, 16);
+   length = simple_strtoul(argv[2], NULL, 16);
+   ivt_offset = simple_strtoul(argv[3], NULL, 16);
 
-   rcode = authenticate_image(addr, ivt_offset);
+   rcode = authenticate_image(addr, length, ivt_offset);
if (rcode == 

[U-Boot] [PATCH v2 02/23] arm: imx: hab: Fix authenticate_image result code

2017-12-28 Thread Bryan O'Donoghue
authenticate_image returns 1 for success and 0 for failure. That result
code is mapped directly to the result code for the command line function
hab_auth_img - which means when hab_auth_img succeeds it is returning
CMD_RET_FAILURE (1) instead of CMD_RET_SUCCESS (0).

This patch fixes this behaviour by making authenticate_image() return 0 for
success and 1 for failure. Both users of authenticate_image() as a result
have some minimal churn. The upshot is once done when hab_auth_img is
called from the command line we set $? in the standard way for scripting
functions to act on.

Fixes: 36c1ca4d46ef ("imx: Support i.MX6 High Assurance Boot
authentication")

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 9 ++---
 arch/arm/mach-imx/spl.c | 4 ++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 09892a6..9fe6d43 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -373,7 +373,10 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
ivt_offset = simple_strtoul(argv[2], NULL, 16);
 
rcode = authenticate_image(addr, ivt_offset);
-
+   if (rcode == 0)
+   rcode = CMD_RET_SUCCESS;
+   else
+   rcode = CMD_RET_FAILURE;
return rcode;
 }
 
@@ -415,7 +418,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
uint32_t load_addr = 0;
size_t bytes;
ptrdiff_t ivt_offset = 0;
-   int result = 0;
+   int result = 1;
ulong start;
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
@@ -510,7 +513,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
}
 
if ((!is_hab_enabled()) || (load_addr != 0))
-   result = 1;
+   result = 0;
 
return result;
 }
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index d0d1b73..6e930b3 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -163,8 +163,8 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
 
/* HAB looks for the CSF at the end of the authenticated data therefore,
 * we need to subtract the size of the CSF from the actual filesize */
-   if (authenticate_image(spl_image->load_addr,
-  spl_image->size - CONFIG_CSF_SIZE)) {
+   if (!authenticate_image(spl_image->load_addr,
+   spl_image->size - CONFIG_CSF_SIZE)) {
image_entry();
} else {
puts("spl: ERROR:  image authentication unsuccessful\n");
-- 
2.7.4

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


[U-Boot] [PATCH v2 08/23] arm: imx: hab: Fix authenticate image lockup on MX7

2017-12-28 Thread Bryan O'Donoghue
The i.MX6 has some pretty explicit code associated with informing the IROM
about flushing caches during authenticate_image().

Looking at various pieces of documentation its pretty clear the i.MX6 IROM
registers are not documented and absent similar documentation on the i.MX7
the next-best fix is to disabled the dcache while making an
authenticate_image() callback.

This patch therefore disables dcache temporarily while doing an IROM
authenticate_image() callback, thus resolving a lockup encountered in a
complex set of authenticate-image calls observed.

Note there is no appreciable performance impact with dcache switched off so
this fix is relatively pain-free.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 2a40d06..1d7b069 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -466,10 +466,25 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
}
}
 
+   /*
+* FIXME: Need to disable dcache on MX7 is there an IROM
+* register like on MX6 above ? Certain images called in certain
+* orders with the dcache switched on will cause
+* authenticate_image() to lockup. Switching off the dcache
+* resolves the issue.
+* https://community.nxp.com/message/953261
+*/
+   if (is_soc_type(MXC_SOC_MX7))
+   dcache_disable();
+
load_addr = (uint32_t)hab_rvt_authenticate_image(
HAB_CID_UBOOT,
ivt_offset, (void **)&start,
(size_t *)&bytes, NULL);
+
+   if (is_soc_type(MXC_SOC_MX7))
+   dcache_enable();
+
if (hab_rvt_exit() != HAB_SUCCESS) {
puts("hab exit function fail\n");
load_addr = 0;
-- 
2.7.4

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


[U-Boot] [PATCH v2 05/23] arm: imx: hab: Move IVT_SIZE to hab.h

2017-12-28 Thread Bryan O'Donoghue
The size of the IVT header should be defined in hab.h move it there now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 ++
 arch/arm/mach-imx/hab.c | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 1b7a5e4..3c19d2e 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -143,6 +143,8 @@ typedef void hapi_clock_init_t(void);
 #define HAB_CID_ROM 0 /**< ROM Caller ID */
 #define HAB_CID_UBOOT 1 /**< UBOOT Caller ID*/
 
+#define IVT_SIZE   0x20
+
 /* --- end of HAB API updates */
 
 int authenticate_image(uint32_t ddr_start, uint32_t image_size);
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index f878b7b..6367562 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,7 +70,6 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
-#define IVT_SIZE   0x20
 #define ALIGN_SIZE 0x1000
 #define CSF_PAD_SIZE   0x2000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
-- 
2.7.4

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


[U-Boot] [PATCH v2 13/23] arm: imx: hab: Print additional IVT elements during debug

2017-12-28 Thread Bryan O'Donoghue
This patch enables printout of the IVT entry, dcd and csf data fields.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index d620524..6646f81 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -461,6 +461,8 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
bytes = image_size;
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
+   printf("ivt entry = 0x%08x, dcd = 0x%08x, csf = 0x%08x\n", ivt->entry,
+  ivt->dcd, ivt->csf);
puts("Dumping IVT\n");
print_buffer(ivt_addr, (void *)(ivt_addr), 4, 0x8, 0);
 
-- 
2.7.4

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


[U-Boot] [PATCH v2 03/23] arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail

2017-12-28 Thread Bryan O'Donoghue
There is no need to call is_enabled() twice in authenticate_image - it does
nothing but add an additional layer of indentation.

We can check for is_enabled() at the start of the function and return the
result code directly.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 138 
 1 file changed, 69 insertions(+), 69 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 9fe6d43..6f86c02 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -428,91 +428,91 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
hab_rvt_entry = hab_rvt_entry_p;
hab_rvt_exit = hab_rvt_exit_p;
 
-   if (is_hab_enabled()) {
-   printf("\nAuthenticate image from DDR location 0x%x...\n",
-  ddr_start);
+   if (!is_hab_enabled()) {
+   puts("hab fuse not enabled\n");
+   return result;
+   }
 
-   hab_caam_clock_enable(1);
+   printf("\nAuthenticate image from DDR location 0x%x...\n",
+  ddr_start);
 
-   if (hab_rvt_entry() == HAB_SUCCESS) {
-   /* If not already aligned, Align to ALIGN_SIZE */
-   ivt_offset = (image_size + ALIGN_SIZE - 1) &
-   ~(ALIGN_SIZE - 1);
+   hab_caam_clock_enable(1);
 
-   start = ddr_start;
-   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
+   if (hab_rvt_entry() == HAB_SUCCESS) {
+   /* If not already aligned, Align to ALIGN_SIZE */
+   ivt_offset = (image_size + ALIGN_SIZE - 1) &
+   ~(ALIGN_SIZE - 1);
+
+   start = ddr_start;
+   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
 #ifdef DEBUG
-   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
-  ivt_offset, ddr_start + ivt_offset);
-   puts("Dumping IVT\n");
-   print_buffer(ddr_start + ivt_offset,
-(void *)(ddr_start + ivt_offset),
-4, 0x8, 0);
-
-   puts("Dumping CSF Header\n");
-   print_buffer(ddr_start + ivt_offset+IVT_SIZE,
-(void *)(ddr_start + ivt_offset+IVT_SIZE),
-4, 0x10, 0);
+   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
+  ivt_offset, ddr_start + ivt_offset);
+   puts("Dumping IVT\n");
+   print_buffer(ddr_start + ivt_offset,
+(void *)(ddr_start + ivt_offset),
+4, 0x8, 0);
+
+   puts("Dumping CSF Header\n");
+   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
+(void *)(ddr_start + ivt_offset + IVT_SIZE),
+4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
-   get_hab_status();
+   get_hab_status();
 #endif
 
-   puts("\nCalling authenticate_image in ROM\n");
-   printf("\tivt_offset = 0x%x\n", ivt_offset);
-   printf("\tstart = 0x%08lx\n", start);
-   printf("\tbytes = 0x%x\n", bytes);
+   puts("\nCalling authenticate_image in ROM\n");
+   printf("\tivt_offset = 0x%x\n", ivt_offset);
+   printf("\tstart = 0x%08lx\n", start);
+   printf("\tbytes = 0x%x\n", bytes);
 #endif
-   /*
-* If the MMU is enabled, we have to notify the ROM
-* code, or it won't flush the caches when needed.
-* This is done, by setting the "pu_irom_mmu_enabled"
-* word to 1. You can find its address by looking in
-* the ROM map. This is critical for
-* authenticate_image(). If MMU is enabled, without
-* setting this bit, authentication will fail and may
-* crash.
-*/
-   /* Check MMU enabled */
-   if (is_soc_type(MXC_SOC_MX6) && get_cr() & CR_M) {
-   if (is_mx6dq()) {
-   /*
-* This won't work on Rev 1.0.0 of
-* i.MX6Q/D, since their ROM doesn't
-* do cache flushes. don't think any
-* exist, so we ignore them.
-*/
-   

[U-Boot] [PATCH v2 09/23] arm: imx: hab: Add IVT header definitions

2017-12-28 Thread Bryan O'Donoghue
The various i.MX BootROMs containing the High Assurance Boot (HAB) block
rely on a data structure called the Image Vector Table (IVT) to describe to
the BootROM where to locate various data-structures used by HAB during
authentication.

This patch adds a definition of the IVT header for use in later patches,
where we will break the current incorrect dependence on fixed offsets in
favour of an IVT described parsing of incoming binaries.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index b2a8031..28cde38 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -10,6 +10,34 @@
 
 #include 
 
+/*
+ * IVT header definitions
+ * Security Reference Manual for i.MX 7Dual and 7Solo Applications Processors,
+ * Rev. 0, 03/2017
+ * Section : 6.7.1.1
+ */
+#define IVT_HEADER_MAGIC   0xD1
+#define IVT_TOTAL_LENGTH   0x20
+#define IVT_HEADER_V1  0x40
+#define IVT_HEADER_V2  0x41
+
+struct ivt_header {
+   uint8_t magic;
+   uint16_tlength;
+   uint8_t version;
+} __attribute__((packed));
+
+struct ivt {
+   struct ivt_header hdr;  /* IVT header above */
+   uint32_t entry; /* Absolute address of first instruction */
+   uint32_t reserved1; /* Reserved should be zero */
+   uint32_t dcd;   /* Absolute address of the image DCD */
+   uint32_t boot;  /* Absolute address of the boot data */
+   uint32_t self;  /* Absolute address of the IVT */
+   uint32_t csf;   /* Absolute address of the CSF */
+   uint32_t reserved2; /* Reserved should be zero */
+};
+
 /*  start of HAB API updates */
 /* The following are taken from HAB4 SIS */
 
-- 
2.7.4

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


[U-Boot] [PATCH v2 18/23] arm: imx: hab: Prefix authenticate_image with imx_hab

2017-12-28 Thread Bryan O'Donoghue
Tidy up the HAB namespace a bit by prefixing external functions with
imx_hab. All external facing functions past this point will be prefixed in
the same way to make the fact we are doing IMX HAB activities clear from
reading the code. authenticate_image() could mean anything
imx_hab_authenticate_image() is on the other hand very explicit.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 4 ++--
 arch/arm/mach-imx/hab.c | 6 +++---
 arch/arm/mach-imx/spl.c | 5 +++--
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 14e1220..98bc1bd 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -185,7 +185,7 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size,
-  uint32_t ivt_offset);
+int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 098cd3c..5c2d5fd 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -392,7 +392,7 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
length = simple_strtoul(argv[2], NULL, 16);
ivt_offset = simple_strtoul(argv[3], NULL, 16);
 
-   rcode = authenticate_image(addr, length, ivt_offset);
+   rcode = imx_hab_authenticate_image(addr, length, ivt_offset);
if (rcode == 0)
rcode = CMD_RET_SUCCESS;
else
@@ -435,8 +435,8 @@ static bool is_hab_enabled(void)
return (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
 }
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size,
-  uint32_t ivt_offset)
+int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset)
 {
uint32_t load_addr = 0;
size_t bytes;
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index e5d0c35..a5478ce 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -196,8 +196,9 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
/* HAB looks for the CSF at the end of the authenticated data therefore,
 * we need to subtract the size of the CSF from the actual filesize */
offset = spl_image->size - CONFIG_CSF_SIZE;
-   if (!authenticate_image(spl_image->load_addr,
-   offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
+   if (!imx_hab_authenticate_image(spl_image->load_addr,
+   offset + IVT_SIZE + CSF_PAD_SIZE,
+   offset)) {
image_entry();
} else {
puts("spl: ERROR:  image authentication unsuccessful\n");
-- 
2.7.4

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


[U-Boot] [PATCH v2 10/23] arm: imx: hab: Add IVT header verification

2017-12-28 Thread Bryan O'Donoghue
The IVT header contains a magic number, fixed length and one of two version
identifiers. Validate these settings before doing anything with a putative
IVT binary.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 1d7b069..cb6214d 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -80,6 +80,31 @@
 
 static bool is_hab_enabled(void);
 
+static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
+{
+   printf("%s magic=0x%x length=0x%02x version=0x%x\n", err_str,
+  ivt_hdr->magic, ivt_hdr->length, ivt_hdr->version);
+
+   return 1;
+}
+
+static int verify_ivt_header(struct ivt_header *ivt_hdr)
+{
+   int result = 0;
+
+   if (ivt_hdr->magic != IVT_HEADER_MAGIC)
+   result = ivt_header_error("bad magic", ivt_hdr);
+
+   if (be16_to_cpu(ivt_hdr->length) != IVT_TOTAL_LENGTH)
+   result = ivt_header_error("bad length", ivt_hdr);
+
+   if (ivt_hdr->version != IVT_HEADER_V1 &&
+   ivt_hdr->version != IVT_HEADER_V2)
+   result = ivt_header_error("bad version", ivt_hdr);
+
+   return result;
+}
+
 #if !defined(CONFIG_SPL_BUILD)
 
 #define MAX_RECORD_BYTES (8*1024) /* 4 kbytes */
@@ -394,6 +419,8 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
hab_rvt_exit_t *hab_rvt_exit;
+   struct ivt *ivt;
+   struct ivt_header *ivt_hdr;
 
hab_rvt_authenticate_image = hab_rvt_authenticate_image_p;
hab_rvt_entry = hab_rvt_entry_p;
@@ -416,6 +443,13 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
/* Calculate IVT address header */
ivt_addr = ddr_start + ivt_offset;
+   ivt = (struct ivt *)ivt_addr;
+   ivt_hdr = &ivt->hdr;
+
+   /* Verify IVT header bugging out on error */
+   if (verify_ivt_header(ivt_hdr))
+   goto hab_caam_clock_disable;
+
start = ddr_start;
bytes = image_size;
 #ifdef DEBUG
@@ -435,8 +469,6 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
printf("\tivt_offset = 0x%x\n", ivt_offset);
printf("\tstart = 0x%08lx\n", start);
printf("\tbytes = 0x%x\n", bytes);
-#else
-   (void)ivt_addr;
 #endif
/*
 * If the MMU is enabled, we have to notify the ROM
-- 
2.7.4

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


[U-Boot] [PATCH v2 20/23] arm: imx: hab: Make imx_hab_is_enabled global

2017-12-28 Thread Bryan O'Donoghue
It will be helpful to boot commands to know if the HAB is enabled. Export
imx_hab_is_enabled() now to facilitate further work with this data-point in
a secure-boot context.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 1 +
 arch/arm/mach-imx/hab.c | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 98bc1bd..5c13aff 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -187,5 +187,6 @@ typedef void hapi_clock_init_t(void);
 
 int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
   uint32_t ivt_offset);
+bool imx_hab_is_enabled(void);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index a1a13d6..7b50ef5 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -96,8 +96,6 @@ static inline enum hab_status hab_rvt_check_target_new(enum 
hab_target target,
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-static bool imx_hab_is_enabled(void);
-
 static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
 {
printf("%s magic=0x%x length=0x%02x version=0x%x\n", err_str,
@@ -419,7 +417,7 @@ U_BOOT_CMD(
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-static bool imx_hab_is_enabled(void)
+bool imx_hab_is_enabled(void)
 {
struct imx_sec_config_fuse_t *fuse =
(struct imx_sec_config_fuse_t *)&imx_sec_config_fuse;
-- 
2.7.4

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


[U-Boot] [PATCH v2 12/23] arm: imx: hab: Print CSF based on IVT descriptor

2017-12-28 Thread Bryan O'Donoghue
The IVT gives the absolute address of the CSF. There is no requirement for
the CSF to be located adjacent to the IVT so lets use the address provided
in the IVT header instead of the fixed CSF offset currently in place.

Its worth noting if you use u-boot mkimage and the i.MX CST tool as
described in the NXP documentation you will get an image like

IVT | BINARY | CSF not IVT | CSF | BINARY as the code currently assumes.
The IVT header must correctly describe the location of the CSF or the
BootROM will reject it - so the current dependence on a fixed offset is
nothing except limiting.

Fix it now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 479ed96..d620524 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -465,8 +465,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
print_buffer(ivt_addr, (void *)(ivt_addr), 4, 0x8, 0);
 
puts("Dumping CSF Header\n");
-   print_buffer(ivt_addr + IVT_SIZE, (void *)(ivt_addr + IVT_SIZE), 4,
-0x10, 0);
+   print_buffer(ivt->csf, (void *)(ivt->csf), 4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
get_hab_status();
-- 
2.7.4

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


[U-Boot] [PATCH v2 23/23] arm: imx: hab: Add hab_failsafe console command

2017-12-28 Thread Bryan O'Donoghue
hab_failsafe when called puts the part into BootROM recovery mode.
This will allow u-boot scripts to script the dropping down into recovery
mode.

=> hab_failsafe

Shows the i.MX7 appear as "hiddev0,hidraw5: USB HID v1.10 Device [Freescale
SemiConductor Inc  SP Blank ULT1] " in a Linux dmesg thus allowing download
of a new image via the BootROM USB download protocol routine.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 01c0853..fb78fc1 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -414,6 +414,22 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
return rcode;
 }
 
+static int do_hab_failsafe(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   hab_rvt_failsafe_t *hab_rvt_failsafe;
+
+   if (argc != 1) {
+   cmd_usage(cmdtp);
+   return 1;
+   }
+
+   hab_rvt_failsafe = hab_rvt_failsafe_p;
+   hab_rvt_failsafe();
+
+   return 0;
+}
+
 U_BOOT_CMD(
hab_status, CONFIG_SYS_MAXARGS, 1, do_hab_status,
"display HAB status",
@@ -429,6 +445,11 @@ U_BOOT_CMD(
"ivt_offset - hex offset of IVT in the image"
  );
 
+U_BOOT_CMD(
+   hab_failsafe, CONFIG_SYS_MAXARGS, 1, do_hab_failsafe,
+   "run BootROM failsafe routine",
+   ""
+ );
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-- 
2.7.4

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


[U-Boot] [PATCH v2 19/23] arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled

2017-12-28 Thread Bryan O'Donoghue
Understanding if the HAB is enabled is something that we want to
interrogate and report on outside of the HAB layer. First step to that is
renaming the relevant function to match the previously introduced external
naming convention imx_hab_function()

The name imx_hab_is_hab_enabled() is a tautology. A more logical name is
imx_hab_is_enabled().

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 5c2d5fd..a1a13d6 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -96,7 +96,7 @@ static inline enum hab_status hab_rvt_check_target_new(enum 
hab_target target,
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-static bool is_hab_enabled(void);
+static bool imx_hab_is_enabled(void);
 
 static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
 {
@@ -334,7 +334,7 @@ static int get_hab_status(void)
hab_rvt_report_event = hab_rvt_report_event_p;
hab_rvt_report_status = hab_rvt_report_status_p;
 
-   if (is_hab_enabled())
+   if (imx_hab_is_enabled())
puts("\nSecure boot enabled\n");
else
puts("\nSecure boot disabled\n");
@@ -419,7 +419,7 @@ U_BOOT_CMD(
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-static bool is_hab_enabled(void)
+static bool imx_hab_is_enabled(void)
 {
struct imx_sec_config_fuse_t *fuse =
(struct imx_sec_config_fuse_t *)&imx_sec_config_fuse;
@@ -456,7 +456,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_exit = hab_rvt_exit_p;
hab_rvt_check_target = hab_rvt_check_target_p;
 
-   if (!is_hab_enabled()) {
+   if (!imx_hab_is_enabled()) {
puts("hab fuse not enabled\n");
return result;
}
-- 
2.7.4

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


[U-Boot] [PATCH v2 21/23] arm: imx: hab: Define rvt_failsafe()

2017-12-28 Thread Bryan O'Donoghue
The hab_rvt_failsafe() callback according to the HABv4 documentation:

"This function provides a safe path when image authentication has failed
and all possible boot paths have been exhausted. It is intended for use by
post-ROM boot stage components, via the ROM Vector Table."

Once invoked the part will drop down to its BootROM USB recovery mode.
Should it be the case that the part is in secure boot mode - only an
appropriately signed binary will be accepted by the ROM and subsequently
executed.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 5c13aff..a0cb19d 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -140,6 +140,7 @@ typedef void *hab_rvt_authenticate_image_t(uint8_t, 
ptrdiff_t,
void **, size_t *, hab_loader_callback_f_t);
 typedef enum hab_status hab_rvt_check_target_t(enum hab_target, const void *,
   size_t);
+typedef void hab_rvt_failsafe_t(void);
 typedef void hapi_clock_init_t(void);
 
 #define HAB_ENG_ANY0x00   /* Select first compatible engine */
@@ -170,6 +171,7 @@ typedef void hapi_clock_init_t(void);
 #define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)(HAB_RVT_BASE + 0x10))
 #define HAB_RVT_REPORT_EVENT   (*(uint32_t *)(HAB_RVT_BASE + 0x20))
 #define HAB_RVT_REPORT_STATUS  (*(uint32_t *)(HAB_RVT_BASE + 0x24))
+#define HAB_RVT_FAILSAFE   (*(uint32_t *)(HAB_RVT_BASE + 0x28))
 
 #define HAB_RVT_REPORT_EVENT_NEW   (*(uint32_t *)0x00B8)
 #define HAB_RVT_REPORT_STATUS_NEW  (*(uint32_t *)0x00BC)
-- 
2.7.4

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


[U-Boot] [PATCH v2 11/23] arm: imx: hab: Verify IVT self matches calculated address

2017-12-28 Thread Bryan O'Donoghue
The IVT is a self-describing structure which contains a self field. The
self field is the absolute physical base address the IVT ought to be at in
memory. Use the IVT self field to validate the calculated ivt_addr bugging
out if the two values differ.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index cb6214d..479ed96 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -450,6 +450,13 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
if (verify_ivt_header(ivt_hdr))
goto hab_caam_clock_disable;
 
+   /* Verify IVT body */
+   if (ivt->self != ivt_addr) {
+   printf("ivt->self 0x%08x pointer is 0x%08x\n",
+  ivt->self, ivt_addr);
+   goto hab_caam_clock_disable;
+   }
+
start = ddr_start;
bytes = image_size;
 #ifdef DEBUG
-- 
2.7.4

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


[U-Boot] [PATCH v2 06/23] arm: imx: hab: Move CSF_PAD_SIZE to hab.h

2017-12-28 Thread Bryan O'Donoghue
CSF_PAD_SIZE should be defined in hab.h, move it to that location now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 1 +
 arch/arm/mach-imx/hab.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 3c19d2e..91dda42 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -144,6 +144,7 @@ typedef void hapi_clock_init_t(void);
 #define HAB_CID_UBOOT 1 /**< UBOOT Caller ID*/
 
 #define IVT_SIZE   0x20
+#define CSF_PAD_SIZE   0x2000
 
 /* --- end of HAB API updates */
 
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 6367562..039a017 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -71,7 +71,6 @@
 )
 
 #define ALIGN_SIZE 0x1000
-#define CSF_PAD_SIZE   0x2000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
 #define MX6DLS_PU_IROM_MMU_EN_VAR  0x00901dd0
 #define MX6SL_PU_IROM_MMU_EN_VAR   0x00900a18
-- 
2.7.4

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


[U-Boot] [PATCH v2 15/23] arm: imx: hab: Implement hab_rvt_check_target

2017-12-28 Thread Bryan O'Donoghue
This patch implements the basic callback hooks for hab_rvt_check_target()
for BootROM code using the older BootROM address layout - in my test case
the i.MX7. Code based on new BootROM callbacks will just have HAB_SUCCESS
as a result code. Adding support for the new BootROM callbacks is a TODO.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 6646f81..eb18f76 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,6 +70,24 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
+static inline enum hab_status hab_rvt_check_target_new(enum hab_target target,
+  const void *start,
+  size_t bytes)
+{
+   return HAB_SUCCESS;
+}
+
+#define hab_rvt_check_target_p \
+(  \
+   (is_mx6dqp()) ? \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   ((hab_rvt_check_target_t *)HAB_RVT_CHECK_TARGET)\
+)
+
 #define ALIGN_SIZE 0x1000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
 #define MX6DLS_PU_IROM_MMU_EN_VAR  0x00901dd0
-- 
2.7.4

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


[U-Boot] [PATCH v2 22/23] arm: imx: hab: Implement hab_rvt_failsafe

2017-12-28 Thread Bryan O'Donoghue
This patch implements the basic callback hooks for
hab_rvt_check_failsafe for BootROM code using the older BootROM address
layout - in my test case the i.MX7. Code based on new BootROM callbacks
will just do nothing and there's definitely a TODO to implement that extra
functionality on the alternative BootROM API.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 7b50ef5..01c0853 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,6 +70,21 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
+static inline void hab_rvt_failsafe_new(void)
+{
+}
+
+#define hab_rvt_failsafe_p \
+(  \
+   (is_mx6dqp()) ? \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   ((hab_rvt_failsafe_t *)HAB_RVT_FAILSAFE)\
+)
+
 static inline enum hab_status hab_rvt_check_target_new(enum hab_target target,
   const void *start,
   size_t bytes)
-- 
2.7.4

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


[U-Boot] [PATCH v2 04/23] arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail

2017-12-28 Thread Bryan O'Donoghue
The current code disjoins an entire block of code on hab_entry pass/fail
resulting in a large chunk of authenticate_image being offset to the right.

Fix this by checking hab_entry() pass/failure and exiting the function
directly if in an error state.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 6f86c02..f878b7b 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -438,75 +438,77 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
 
hab_caam_clock_enable(1);
 
-   if (hab_rvt_entry() == HAB_SUCCESS) {
-   /* If not already aligned, Align to ALIGN_SIZE */
-   ivt_offset = (image_size + ALIGN_SIZE - 1) &
-   ~(ALIGN_SIZE - 1);
+   if (hab_rvt_entry() != HAB_SUCCESS) {
+   puts("hab entry function fail\n");
+   goto hab_caam_clock_disable;
+   }
 
-   start = ddr_start;
-   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
+   /* If not already aligned, Align to ALIGN_SIZE */
+   ivt_offset = (image_size + ALIGN_SIZE - 1) &
+   ~(ALIGN_SIZE - 1);
+
+   start = ddr_start;
+   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
 #ifdef DEBUG
-   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
-  ivt_offset, ddr_start + ivt_offset);
-   puts("Dumping IVT\n");
-   print_buffer(ddr_start + ivt_offset,
-(void *)(ddr_start + ivt_offset),
-4, 0x8, 0);
-
-   puts("Dumping CSF Header\n");
-   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
-(void *)(ddr_start + ivt_offset + IVT_SIZE),
-4, 0x10, 0);
+   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
+  ivt_offset, ddr_start + ivt_offset);
+   puts("Dumping IVT\n");
+   print_buffer(ddr_start + ivt_offset,
+(void *)(ddr_start + ivt_offset),
+4, 0x8, 0);
+
+   puts("Dumping CSF Header\n");
+   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
+(void *)(ddr_start + ivt_offset + IVT_SIZE),
+4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
-   get_hab_status();
+   get_hab_status();
 #endif
 
-   puts("\nCalling authenticate_image in ROM\n");
-   printf("\tivt_offset = 0x%x\n", ivt_offset);
-   printf("\tstart = 0x%08lx\n", start);
-   printf("\tbytes = 0x%x\n", bytes);
+   puts("\nCalling authenticate_image in ROM\n");
+   printf("\tivt_offset = 0x%x\n", ivt_offset);
+   printf("\tstart = 0x%08lx\n", start);
+   printf("\tbytes = 0x%x\n", bytes);
 #endif
-   /*
-* If the MMU is enabled, we have to notify the ROM
-* code, or it won't flush the caches when needed.
-* This is done, by setting the "pu_irom_mmu_enabled"
-* word to 1. You can find its address by looking in
-* the ROM map. This is critical for
-* authenticate_image(). If MMU is enabled, without
-* setting this bit, authentication will fail and may
-* crash.
-*/
-   /* Check MMU enabled */
-   if (is_soc_type(MXC_SOC_MX6) && get_cr() & CR_M) {
-   if (is_mx6dq()) {
-   /*
-* This won't work on Rev 1.0.0 of
-* i.MX6Q/D, since their ROM doesn't
-* do cache flushes. don't think any
-* exist, so we ignore them.
-*/
-   if (!is_mx6dqp())
-   writel(1, MX6DQ_PU_IROM_MMU_EN_VAR);
-   } else if (is_mx6sdl()) {
-   writel(1, MX6DLS_PU_IROM_MMU_EN_VAR);
-   } else if (is_mx6sl()) {
-   writel(1, MX6SL_PU_IROM_MMU_EN_VAR);
-   }
+   /*
+* If the MMU is enabled, we have to notify the ROM
+* code, or it won't flush the caches when needed.
+* This is done, by setting the "pu_irom_mmu_enabled"
+* word to 1. You can find its address by looking in
+* the ROM map. This is critical for
+* authenticate_image(). If MMU is enabled, without
+* setting this bit, authentication will fail and may
+* crash.
+*/
+   /* Check MMU

[U-Boot] [PATCH v2 16/23] arm: imx: hab: Add a hab_rvt_check_target to image auth

2017-12-28 Thread Bryan O'Donoghue
Add a hab_rvt_check_target() step to authenticate_image() as a sanity
check for the target memory region authenticate_image() will run over,
prior to making the BootROM authentication callback itself.

This check is recommended by the HAB documentation so it makes sense to
adhere to the guidance and perform that check as directed.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index eb18f76..864b1e2 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -437,12 +437,15 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
hab_rvt_exit_t *hab_rvt_exit;
+   hab_rvt_check_target_t *hab_rvt_check_target;
struct ivt *ivt;
struct ivt_header *ivt_hdr;
+   enum hab_status status;
 
hab_rvt_authenticate_image = hab_rvt_authenticate_image_p;
hab_rvt_entry = hab_rvt_entry_p;
hab_rvt_exit = hab_rvt_exit_p;
+   hab_rvt_check_target = hab_rvt_check_target_p;
 
if (!is_hab_enabled()) {
puts("hab fuse not enabled\n");
@@ -477,6 +480,13 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
start = ddr_start;
bytes = image_size;
+
+   status = hab_rvt_check_target(HAB_TGT_MEMORY, (void *)ddr_start, bytes);
+   if (status != HAB_SUCCESS) {
+   printf("HAB check target 0x%08x-0x%08x fail\n",
+  ddr_start, ddr_start + bytes);
+   goto hab_caam_clock_disable;
+   }
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
printf("ivt entry = 0x%08x, dcd = 0x%08x, csf = 0x%08x\n", ivt->entry,
-- 
2.7.4

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


[U-Boot] [PATCH v2 14/23] arm: imx: hab: Define rvt_check_target()

2017-12-28 Thread Bryan O'Donoghue
The hab_rvt_check_target() callback according to the HABv4 documentation:

"This function reports whether or not a given target region is allowed for
 either peripheral configuration or image loading in memory. It is intended
 for use by post-ROM boot stage components, via the ROM Vector Table, in
 order to avoid configuring security-sensitive peripherals, or loading
 images over sensitive memory regions or outside recognized memory devices
 in the address map."

It is a useful function to support as a precursor to calling into
authenticate_image() to validate the target memory region is good.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 28cde38..14e1220 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -113,6 +113,12 @@ enum hab_context {
HAB_CTX_MAX
 };
 
+enum hab_target {
+   HAB_TGT_MEMORY  = 0x0f,
+   HAB_TGT_PERIPHERAL  = 0xf0,
+   HAB_TGT_ANY = 0x55,
+};
+
 struct imx_sec_config_fuse_t {
int bank;
int word;
@@ -132,6 +138,8 @@ typedef enum hab_status hab_rvt_entry_t(void);
 typedef enum hab_status hab_rvt_exit_t(void);
 typedef void *hab_rvt_authenticate_image_t(uint8_t, ptrdiff_t,
void **, size_t *, hab_loader_callback_f_t);
+typedef enum hab_status hab_rvt_check_target_t(enum hab_target, const void *,
+  size_t);
 typedef void hapi_clock_init_t(void);
 
 #define HAB_ENG_ANY0x00   /* Select first compatible engine */
@@ -158,6 +166,7 @@ typedef void hapi_clock_init_t(void);
 
 #define HAB_RVT_ENTRY  (*(uint32_t *)(HAB_RVT_BASE + 0x04))
 #define HAB_RVT_EXIT   (*(uint32_t *)(HAB_RVT_BASE + 0x08))
+#define HAB_RVT_CHECK_TARGET   (*(uint32_t *)(HAB_RVT_BASE + 0x0C))
 #define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)(HAB_RVT_BASE + 0x10))
 #define HAB_RVT_REPORT_EVENT   (*(uint32_t *)(HAB_RVT_BASE + 0x20))
 #define HAB_RVT_REPORT_STATUS  (*(uint32_t *)(HAB_RVT_BASE + 0x24))
-- 
2.7.4

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


[U-Boot] [PATCH v2 17/23] arm: imx: hab: Make internal functions and data static

2017-12-28 Thread Bryan O'Donoghue
There is no need to export these functions and data structures externally.
Make them all static now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 159 +---
 1 file changed, 84 insertions(+), 75 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 864b1e2..098cd3c 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -135,73 +135,81 @@ struct record {
bool any_rec_flag;
 };
 
-char *rsn_str[] = {"RSN = HAB_RSN_ANY (0x00)\n",
-  "RSN = HAB_ENG_FAIL (0x30)\n",
-  "RSN = HAB_INV_ADDRESS (0x22)\n",
-  "RSN = HAB_INV_ASSERTION (0x0C)\n",
-  "RSN = HAB_INV_CALL (0x28)\n",
-  "RSN = HAB_INV_CERTIFICATE (0x21)\n",
-  "RSN = HAB_INV_COMMAND (0x06)\n",
-  "RSN = HAB_INV_CSF (0x11)\n",
-  "RSN = HAB_INV_DCD (0x27)\n",
-  "RSN = HAB_INV_INDEX (0x0F)\n",
-  "RSN = HAB_INV_IVT (0x05)\n",
-  "RSN = HAB_INV_KEY (0x1D)\n",
-  "RSN = HAB_INV_RETURN (0x1E)\n",
-  "RSN = HAB_INV_SIGNATURE (0x18)\n",
-  "RSN = HAB_INV_SIZE (0x17)\n",
-  "RSN = HAB_MEM_FAIL (0x2E)\n",
-  "RSN = HAB_OVR_COUNT (0x2B)\n",
-  "RSN = HAB_OVR_STORAGE (0x2D)\n",
-  "RSN = HAB_UNS_ALGORITHM (0x12)\n",
-  "RSN = HAB_UNS_COMMAND (0x03)\n",
-  "RSN = HAB_UNS_ENGINE (0x0A)\n",
-  "RSN = HAB_UNS_ITEM (0x24)\n",
-  "RSN = HAB_UNS_KEY (0x1B)\n",
-  "RSN = HAB_UNS_PROTOCOL (0x14)\n",
-  "RSN = HAB_UNS_STATE (0x09)\n",
-  "RSN = INVALID\n",
-  NULL};
-
-char *sts_str[] = {"STS = HAB_SUCCESS (0xF0)\n",
-  "STS = HAB_FAILURE (0x33)\n",
-  "STS = HAB_WARNING (0x69)\n",
-  "STS = INVALID\n",
-  NULL};
-
-char *eng_str[] = {"ENG = HAB_ENG_ANY (0x00)\n",
-  "ENG = HAB_ENG_SCC (0x03)\n",
-  "ENG = HAB_ENG_RTIC (0x05)\n",
-  "ENG = HAB_ENG_SAHARA (0x06)\n",
-  "ENG = HAB_ENG_CSU (0x0A)\n",
-  "ENG = HAB_ENG_SRTC (0x0C)\n",
-  "ENG = HAB_ENG_DCP (0x1B)\n",
-  "ENG = HAB_ENG_CAAM (0x1D)\n",
-  "ENG = HAB_ENG_SNVS (0x1E)\n",
-  "ENG = HAB_ENG_OCOTP (0x21)\n",
-  "ENG = HAB_ENG_DTCP (0x22)\n",
-  "ENG = HAB_ENG_ROM (0x36)\n",
-  "ENG = HAB_ENG_HDCP (0x24)\n",
-  "ENG = HAB_ENG_RTL (0x77)\n",
-  "ENG = HAB_ENG_SW (0xFF)\n",
-  "ENG = INVALID\n",
-  NULL};
-
-char *ctx_str[] = {"CTX = HAB_CTX_ANY(0x00)\n",
-  "CTX = HAB_CTX_FAB (0xFF)\n",
-  "CTX = HAB_CTX_ENTRY (0xE1)\n",
-  "CTX = HAB_CTX_TARGET (0x33)\n",
-  "CTX = HAB_CTX_AUTHENTICATE (0x0A)\n",
-  "CTX = HAB_CTX_DCD (0xDD)\n",
-  "CTX = HAB_CTX_CSF (0xCF)\n",
-  "CTX = HAB_CTX_COMMAND (0xC0)\n",
-  "CTX = HAB_CTX_AUT_DAT (0xDB)\n",
-  "CTX = HAB_CTX_ASSERT (0xA0)\n",
-  "CTX = HAB_CTX_EXIT (0xEE)\n",
-  "CTX = INVALID\n",
-  NULL};
-
-uint8_t hab_statuses[5] = {
+static char *rsn_str[] = {
+ "RSN = HAB_RSN_ANY (0x00)\n",
+ "RSN = HAB_ENG_FAIL (0x30)\n",
+ "RSN = HAB_INV_ADDRESS (0x22)\n",
+ "RSN = HAB_INV_ASSERTION (0x0C)\n",
+ "RSN = HAB_INV_CALL (0x28)\n",
+ "RSN = HAB_INV_CERTIFICATE (0x21)\n",
+  

Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Derald D. Woods
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
> On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> > On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > > 
> > > > This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> > > > 
> > > > Signed-off-by: Derald D. Woods 
> > > > ---
> > > >  include/configs/omap3_evm.h | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> > > > index 629d60b961..d95ccdf035 100644
> > > > --- a/include/configs/omap3_evm.h
> > > > +++ b/include/configs/omap3_evm.h
> > > > @@ -127,6 +127,7 @@
> > > > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > > > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > > > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > > +   "fdt_high=0x\0" \
> > > > "bootenv=uEnv.txt\0" \
> > > > "optargs=\0" \
> > > > "mmcdev=0\0" \
> > > 
> > > What's the problem this solves, and how much memory is on the system in
> > > question?  bootm_size should be ensuring we never relocate it outside of
> > > the first 256MB of memory.  Thanks!
> > > 
> > 
> > The logic within "common/image-fdt.c" lead me down this path. The
> > addition of this fairly common environment variable allowed my
> > OMAP34XX board to boot the kernel without an appended devicetree.
> > When I use the variable to trigger 'disable_relocation', as the code
> > indicates, the kernel boot behavior is what I expect. I spent a few
> > hours following the code path to a single line edition that works.
> > 
> > 
> > Without 'fdt_high'
> > ==
> > 
> > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> > Trying to boot from MMC1
> > reading u-boot.img
> > reading u-boot.img
> > 
> > 
> > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
> > 
> > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > OMAP3 EVM board + LPDDR/NAND
> > I2C:   ready
> > DRAM:  256 MiB
> > NAND:  256 MiB
> > MMC:   OMAP SD/MMC: 0
> > Read back SMSC id 0x9220
> > OMAP die ID: 265a0024040365fa1801b01f
> > Net:   smc911x-0
> > starting USB...
> > USB0:   USB EHCI 1.00
> > scanning bus 0 for devices... 1 USB Device(s) found
> > Hit any key to stop autoboot:  0 
> > switch to partitions #0, OK
> > mmc0 is current device
> > Scanning mmc 0:1...
> > switch to partitions #0, OK
> > mmc0 is current device
> > ** Unable to read file uEnv.txt **
> > reading zImage
> > 4637344 bytes read in 407 ms (10.9 MiB/s)
> > reading omap3-evm.dtb
> > 62832 bytes read in 10 ms (6 MiB/s)
> > Booting zImage from mmc ...
> > *  fdt: cmdline image address = 0x8800
> > ## Checking for 'FDT'/'FDT Image' at 8800
> > *  fdt: raw FDT blob
> > ## Flattened Device Tree blob at 8800
> >Booting using the fdt blob at 0x8800
> >of_flat_tree at 0x8800 size 0xf570
> > ## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
> >Loading Device Tree to 8ffed000, end 856f ... OK
> > 
> > Starting kernel ...
> > 
> > [HANG]
> > 
> > 
> > Make note of the "of_flat_tree" and "Loading Device Tree" lines.
> 
> Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
> 0x0a00 ?  I wonder if, since you have 256MB of memory we're not
> putting the DTB into where U-Boot is and we stomp on it a bit, causing
> Linux to boot, see an invalid DTB and not have a console available to
> tell us.  Thanks!
> 


That seemed to do it.

---8<

OMAP3_EVM # echo $bootm_size
0x0a00
OMAP3_EVM # reset
resetting ...
O
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42)
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP35XX EVM (TMDSEVM3530)
OMAP3 EVM board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
Read back SMSC id 0x9220
OMAP die ID: 265a0024040365fa1801b01f
Net:   smc911x-0
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
** Unable to read file uEnv.txt **
reading zImage
4637344 bytes read in 407 ms (10.9 MiB/s)
reading omap3-evm.dtb
62832 bytes read in 10 ms (6 MiB/s)
Booting zImage from mmc ...
*  fdt: cmdline image address = 0x8800
## Checking for 'FDT'/'FDT Image' at 8800
*  fdt: raw FDT blob
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   of_flat_tree at 0x8800 size 0xf570
## device tree at 8800 ... 880

Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Tom Rini
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
> On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
> > On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> > > On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > > > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > > > 
> > > > > This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> > > > > 
> > > > > Signed-off-by: Derald D. Woods 
> > > > > ---
> > > > >  include/configs/omap3_evm.h | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> > > > > index 629d60b961..d95ccdf035 100644
> > > > > --- a/include/configs/omap3_evm.h
> > > > > +++ b/include/configs/omap3_evm.h
> > > > > @@ -127,6 +127,7 @@
> > > > >   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > > > >   "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > > > >   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > > > + "fdt_high=0x\0" \
> > > > >   "bootenv=uEnv.txt\0" \
> > > > >   "optargs=\0" \
> > > > >   "mmcdev=0\0" \
> > > > 
> > > > What's the problem this solves, and how much memory is on the system in
> > > > question?  bootm_size should be ensuring we never relocate it outside of
> > > > the first 256MB of memory.  Thanks!
> > > > 
> > > 
> > > The logic within "common/image-fdt.c" lead me down this path. The
> > > addition of this fairly common environment variable allowed my
> > > OMAP34XX board to boot the kernel without an appended devicetree.
> > > When I use the variable to trigger 'disable_relocation', as the code
> > > indicates, the kernel boot behavior is what I expect. I spent a few
> > > hours following the code path to a single line edition that works.
> > > 
> > > 
> > > Without 'fdt_high'
> > > ==
> > > 
> > > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> > > Trying to boot from MMC1
> > > reading u-boot.img
> > > reading u-boot.img
> > > 
> > > 
> > > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
> > > 
> > > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > > OMAP3 EVM board + LPDDR/NAND
> > > I2C:   ready
> > > DRAM:  256 MiB
> > > NAND:  256 MiB
> > > MMC:   OMAP SD/MMC: 0
> > > Read back SMSC id 0x9220
> > > OMAP die ID: 265a0024040365fa1801b01f
> > > Net:   smc911x-0
> > > starting USB...
> > > USB0:   USB EHCI 1.00
> > > scanning bus 0 for devices... 1 USB Device(s) found
> > > Hit any key to stop autoboot:  0 
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > Scanning mmc 0:1...
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > ** Unable to read file uEnv.txt **
> > > reading zImage
> > > 4637344 bytes read in 407 ms (10.9 MiB/s)
> > > reading omap3-evm.dtb
> > > 62832 bytes read in 10 ms (6 MiB/s)
> > > Booting zImage from mmc ...
> > > *  fdt: cmdline image address = 0x8800
> > > ## Checking for 'FDT'/'FDT Image' at 8800
> > > *  fdt: raw FDT blob
> > > ## Flattened Device Tree blob at 8800
> > >Booting using the fdt blob at 0x8800
> > >of_flat_tree at 0x8800 size 0xf570
> > > ## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
> > >Loading Device Tree to 8ffed000, end 856f ... OK
> > > 
> > > Starting kernel ...
> > > 
> > > [HANG]
> > > 
> > > 
> > > Make note of the "of_flat_tree" and "Loading Device Tree" lines.
> > 
> > Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
> > 0x0a00 ?  I wonder if, since you have 256MB of memory we're not
> > putting the DTB into where U-Boot is and we stomp on it a bit, causing
> > Linux to boot, see an invalid DTB and not have a console available to
> > tell us.  Thanks!
> > 
> 
> 
> That seemed to do it.

Ah, good!

> ---8<
> 
> OMAP3_EVM # echo $bootm_size
> 0x0a00
> OMAP3_EVM # reset
> resetting ...
> O
> U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42)
> Trying to boot from MMC1
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
> 
> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> Model: TI OMAP35XX EVM (TMDSEVM3530)
> OMAP3 EVM board + LPDDR/NAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  256 MiB
> MMC:   OMAP SD/MMC: 0
> Read back SMSC id 0x9220
> OMAP die ID: 265a0024040365fa1801b01f
> Net:   smc911x-0
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> switch to partitions #0, OK
> mmc0 is current device
> ** Unable to read file uEnv.txt **
> reading zImage
> 4637344 bytes read in 407 ms (10.9 MiB/s)
> reading omap3-evm.dtb
> 62

Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Derald D. Woods
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
> On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
> > On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
> > > On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> > > > On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > > > > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > > > > 
> > > > > > This commit keeps the 'fdtaddr' as provided by 
> > > > > > DEFAULT_LINUX_BOOT_ENV.
> > > > > > 
> > > > > > Signed-off-by: Derald D. Woods 
> > > > > > ---
> > > > > >  include/configs/omap3_evm.h | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/include/configs/omap3_evm.h 
> > > > > > b/include/configs/omap3_evm.h
> > > > > > index 629d60b961..d95ccdf035 100644
> > > > > > --- a/include/configs/omap3_evm.h
> > > > > > +++ b/include/configs/omap3_evm.h
> > > > > > @@ -127,6 +127,7 @@
> > > > > > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > > > > > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > > > > > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > > > > +   "fdt_high=0x\0" \
> > > > > > "bootenv=uEnv.txt\0" \
> > > > > > "optargs=\0" \
> > > > > > "mmcdev=0\0" \
> > > > > 
> > > > > What's the problem this solves, and how much memory is on the system 
> > > > > in
> > > > > question?  bootm_size should be ensuring we never relocate it outside 
> > > > > of
> > > > > the first 256MB of memory.  Thanks!
> > > > > 
> > > > 
> > > > The logic within "common/image-fdt.c" lead me down this path. The
> > > > addition of this fairly common environment variable allowed my
> > > > OMAP34XX board to boot the kernel without an appended devicetree.
> > > > When I use the variable to trigger 'disable_relocation', as the code
> > > > indicates, the kernel boot behavior is what I expect. I spent a few
> > > > hours following the code path to a single line edition that works.
> > > > 
> > > > 
> > > > Without 'fdt_high'
> > > > ==
> > > > 
> > > > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> > > > Trying to boot from MMC1
> > > > reading u-boot.img
> > > > reading u-boot.img
> > > > 
> > > > 
> > > > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 
> > > > -0600)
> > > > 
> > > > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > > > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > > > OMAP3 EVM board + LPDDR/NAND
> > > > I2C:   ready
> > > > DRAM:  256 MiB
> > > > NAND:  256 MiB
> > > > MMC:   OMAP SD/MMC: 0
> > > > Read back SMSC id 0x9220
> > > > OMAP die ID: 265a0024040365fa1801b01f
> > > > Net:   smc911x-0
> > > > starting USB...
> > > > USB0:   USB EHCI 1.00
> > > > scanning bus 0 for devices... 1 USB Device(s) found
> > > > Hit any key to stop autoboot:  0 
> > > > switch to partitions #0, OK
> > > > mmc0 is current device
> > > > Scanning mmc 0:1...
> > > > switch to partitions #0, OK
> > > > mmc0 is current device
> > > > ** Unable to read file uEnv.txt **
> > > > reading zImage
> > > > 4637344 bytes read in 407 ms (10.9 MiB/s)
> > > > reading omap3-evm.dtb
> > > > 62832 bytes read in 10 ms (6 MiB/s)
> > > > Booting zImage from mmc ...
> > > > *  fdt: cmdline image address = 0x8800
> > > > ## Checking for 'FDT'/'FDT Image' at 8800
> > > > *  fdt: raw FDT blob
> > > > ## Flattened Device Tree blob at 8800
> > > >Booting using the fdt blob at 0x8800
> > > >of_flat_tree at 0x8800 size 0xf570
> > > > ## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
> > > >Loading Device Tree to 8ffed000, end 856f ... OK
> > > > 
> > > > Starting kernel ...
> > > > 
> > > > [HANG]
> > > > 
> > > > 
> > > > Make note of the "of_flat_tree" and "Loading Device Tree" lines.
> > > 
> > > Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
> > > 0x0a00 ?  I wonder if, since you have 256MB of memory we're not
> > > putting the DTB into where U-Boot is and we stomp on it a bit, causing
> > > Linux to boot, see an invalid DTB and not have a console available to
> > > tell us.  Thanks!
> > > 
> > 
> > 
> > That seemed to do it.
> 
> Ah, good!
> 
> > ---8<
> > 
> > OMAP3_EVM # echo $bootm_size
> > 0x0a00
> > OMAP3_EVM # reset
> > resetting ...
> > O
> > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42)
> > Trying to boot from MMC1
> > reading u-boot.img
> > reading u-boot.img
> > 
> > 
> > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
> > 
> > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > OMAP3 EVM board + LPDDR/NAND
> > I2C:   ready
> > DRAM:  256 MiB
> > NAND:  256 MiB
> > MMC:   OMAP SD/MMC: 0
> > Read back SMSC id 0x9220
> > OMAP die ID: 265a0024040365fa1801b01f
> > Net:   smc911x-0
> > starting USB...
> > USB0:   U

[U-Boot] [PATCH 0/9] log: Support control over the log output format

2017-12-28 Thread Simon Glass
This adds a few more features to the log system:

- 'log format' command to control the log output format
- 'log rec' command to output a log record manually
- log_ret() function to log error-return values

With these we have more control over how log records are output as well
as the ability to log errors more easily.


Simon Glass (9):
  dm: core: Add a function to look up a uclass by name
  log: Add functions to convert IDs to/from names
  log: Add control over log formatting
  log: Update log_console to honour the log format
  log: Add a command to control the log output format
  log: Add a command to output a log record
  log: Add tests for the new log features
  log: Add documentation for commands and formatting
  log: Add a way to log error-return values

 cmd/log.c | 82 +++
 common/Kconfig| 13 +++
 common/log.c  | 68 
 common/log_console.c  | 27 -
 configs/sandbox_defconfig |  1 +
 doc/README.log| 35 +
 drivers/core/uclass.c | 14 +++
 include/asm-generic/global_data.h |  1 +
 include/dm/uclass.h   |  8 
 include/log.h | 64 +-
 test/dm/core.c|  9 +
 test/py/tests/test_log.py | 32 +--
 12 files changed, 348 insertions(+), 6 deletions(-)

-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 1/9] dm: core: Add a function to look up a uclass by name

2017-12-28 Thread Simon Glass
Each uclass has a driver name which we can use to look up the uclass. This
is useful for logging, where the uclass ID is used as the category.

Add a function to handle this, as well as a test.

Signed-off-by: Simon Glass 
---

 drivers/core/uclass.c | 14 ++
 include/dm/uclass.h   |  8 
 test/dm/core.c|  9 +
 3 files changed, 31 insertions(+)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index f5e4067922..1aedaa08f0 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -158,6 +158,20 @@ const char *uclass_get_name(enum uclass_id id)
return uc->uc_drv->name;
 }
 
+enum uclass_id uclass_get_by_name(const char *name)
+{
+   int i;
+
+   for (i = 0; i < UCLASS_COUNT; i++) {
+   struct uclass_driver *uc_drv = lists_uclass_lookup(i);
+
+   if (uc_drv && !strcmp(uc_drv->name, name))
+   return i;
+   }
+
+   return UCLASS_INVALID;
+}
+
 int uclass_find_device(enum uclass_id id, int index, struct udevice **devp)
 {
struct uclass *uc;
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 18188497c2..88f6ef4ed5 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -127,6 +127,14 @@ int uclass_get(enum uclass_id key, struct uclass **ucp);
  */
 const char *uclass_get_name(enum uclass_id id);
 
+/**
+ * uclass_get_by_name() - Look up a uclass by its driver name
+ *
+ * @name: Name to look up
+ * @returns the associated uclass ID, or UCLASS_INVALID if not found
+ */
+enum uclass_id uclass_get_by_name(const char *name);
+
 /**
  * uclass_get_device() - Get a uclass device based on an ID and index
  *
diff --git a/test/dm/core.c b/test/dm/core.c
index 50ee41b9e2..052bf8fffb 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -862,3 +862,12 @@ static int dm_test_device_get_uclass_id(struct 
unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_device_get_uclass_id, DM_TESTF_SCAN_PDATA);
+
+static int dm_test_uclass_names(struct unit_test_state *uts)
+{
+   ut_asserteq_str("test", uclass_get_name(UCLASS_TEST));
+   ut_asserteq(UCLASS_TEST, uclass_get_by_name("test"));
+
+   return 0;
+}
+DM_TEST(dm_test_uclass_names, DM_TESTF_SCAN_PDATA);
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 7/9] log: Add tests for the new log features

2017-12-28 Thread Simon Glass
Add a test of the 'log format' and 'log rec' commands. This also covers
things like log_get_cat_by_name(), since they are used by these commands.
Fix a style nit in the tests also.

Signed-off-by: Simon Glass 
---

 test/py/tests/test_log.py | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/test/py/tests/test_log.py b/test/py/tests/test_log.py
index 517f415143..76f9236412 100644
--- a/test/py/tests/test_log.py
+++ b/test/py/tests/test_log.py
@@ -40,7 +40,6 @@ def test_log(u_boot_console):
 Returns:
 iterator containing the lines output from the command
 """
-
 with cons.log.section('basic'):
output = u_boot_console.run_command('log test %d' % testnum)
 split = output.replace('\r', '').splitlines()
@@ -99,3 +98,30 @@ def test_log(u_boot_console):
 test7()
 test8()
 test9()
+
+@pytest.mark.buildconfigspec('log')
+def test_log_format(u_boot_console):
+"""Test the 'log format' and 'log rec' commands"""
+def run_with_format(fmt, expected_output):
+"""Set up the log format and then write a log record
+
+Args:
+fmt: Format to use for 'log format'
+expected_output: Expected output from the 'log rec' command
+"""
+output = cons.run_command('log format %s' % fmt)
+assert output == ''
+output = cons.run_command('log rec arch notice file.c 123 func msg')
+assert output == expected_output
+
+cons = u_boot_console
+with cons.log.section('format'):
+run_with_format('all', 'NOTICE.arch,file.c:123-func() msg')
+output = cons.run_command('log format')
+assert output == 'Log format: clFLfm'
+
+run_with_format('fm', 'func() msg')
+run_with_format('clfm', 'NOTICE.arch,func() msg')
+run_with_format('FLfm', 'file.c:123-func() msg')
+run_with_format('lm', 'NOTICE. msg')
+run_with_format('m', 'msg')
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 3/9] log: Add control over log formatting

2017-12-28 Thread Simon Glass
It is useful to be able to control the output format of log records on the
console. As a starting point, add definitions for controlling which
elements of the log record are displayed. Use function and message as the
default, since these are the most useful fields.

Signed-off-by: Simon Glass 
---

 common/log.c  |  1 +
 include/asm-generic/global_data.h |  1 +
 include/log.h | 14 ++
 3 files changed, 16 insertions(+)

diff --git a/common/log.c b/common/log.c
index 5761a2ce76..7559d74e90 100644
--- a/common/log.c
+++ b/common/log.c
@@ -307,6 +307,7 @@ int log_init(void)
}
gd->flags |= GD_FLG_LOG_READY;
gd->default_log_level = LOGL_INFO;
+   gd->log_fmt = LOGF_DEFAULT;
 
return 0;
 }
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index 73e036d6fd..f1c21dfd20 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -118,6 +118,7 @@ typedef struct global_data {
int log_drop_count; /* Number of dropped log messages */
int default_log_level;  /* For devices with no filters */
struct list_head log_head;  /* List of struct log_device */
+   int log_fmt;/* Mask containing log format info */
 #endif
 } gd_t;
 #endif
diff --git a/include/log.h b/include/log.h
index 5133213acf..828919a409 100644
--- a/include/log.h
+++ b/include/log.h
@@ -291,6 +291,20 @@ const char *log_get_level_name(enum log_level_t level);
  */
 enum log_level_t log_get_level_by_name(const char *name);
 
+/* Log format flags (bit numbers) for gd->log_fmt. See log_fmt_chars */
+enum log_fmt {
+   LOGF_CAT= 0,
+   LOGF_LEVEL,
+   LOGF_FILE,
+   LOGF_LINE,
+   LOGF_FUNC,
+   LOGF_MSG,
+
+   LOGF_COUNT,
+   LOGF_DEFAULT = (1 << LOGF_FUNC) | (1 << LOGF_MSG),
+   LOGF_ALL = 0x3f,
+};
+
 /* Handle the 'log test' command */
 int do_log_test(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[]);
 
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 2/9] log: Add functions to convert IDs to/from names

2017-12-28 Thread Simon Glass
Category and level both use an enum for their ID values. Add functions to
convert these IDs to strings and vice versa. This will allow the log to
output the strings instead of the (inscrutable) values.

At the same time, add a new 'driver-model' category, to cover core
driver-model functions and fix an incorrect value for LOGL_MAX.

Tests will be added with the new 'log' subcommands.

Signed-off-by: Simon Glass 
---

 common/log.c  | 67 +++
 include/log.h | 39 --
 2 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/common/log.c b/common/log.c
index 45e46dd520..5761a2ce76 100644
--- a/common/log.c
+++ b/common/log.c
@@ -10,9 +10,76 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static const char *log_cat_name[LOGC_COUNT - LOGC_NONE] = {
+   "none",
+   "arch",
+   "board",
+   "core",
+   "driver-model",
+   "device-tree",
+};
+
+static const char *log_level_name[LOGL_COUNT] = {
+   "EMERG",
+   "ALERT",
+   "CRIT",
+   "ERR",
+   "WARNING",
+   "NOTICE",
+   "INFO",
+   "DEBUG",
+   "CONTENT",
+   "IO",
+};
+
+const char *log_get_cat_name(enum log_category_t cat)
+{
+   if (cat > LOGC_COUNT)
+   return "invalid";
+   if (log_uc_cat(cat) >= LOGC_NONE)
+   return log_cat_name[cat - LOGC_NONE];
+
+   return uclass_get_name(log_uc_cat(cat));
+}
+
+enum log_category_t log_get_cat_by_name(const char *name)
+{
+   enum uclass_id id;
+   int i;
+
+   for (i = LOGC_NONE; i < LOGC_COUNT; i++)
+   if (!strcmp(name, log_cat_name[i - LOGC_NONE]))
+   return i;
+   id = uclass_get_by_name(name);
+   if (id != UCLASS_INVALID)
+   return (enum log_category_t)id;
+
+   return LOGC_NONE;
+}
+
+const char *log_get_level_name(enum log_level_t level)
+{
+   if (level >= LOGL_COUNT)
+   return "INVALID";
+   return log_level_name[level];
+}
+
+enum log_level_t log_get_level_by_name(const char *name)
+{
+   int i;
+
+   for (i = 0; i < LOGL_COUNT; i++) {
+   if (!strcasecmp(log_level_name[i], name))
+   return i;
+   }
+
+   return LOGL_NONE;
+}
+
 static struct log_device *log_device_find_by_name(const char *drv_name)
 {
struct log_device *ldev;
diff --git a/include/log.h b/include/log.h
index 8083b64831..5133213acf 100644
--- a/include/log.h
+++ b/include/log.h
@@ -27,8 +27,10 @@ enum log_level_t {
LOGL_DEBUG_IO,  /* Debug message showing hardware I/O access */
 
LOGL_COUNT,
+   LOGL_NONE,
+
LOGL_FIRST = LOGL_EMERG,
-   LOGL_MAX = LOGL_DEBUG,
+   LOGL_MAX = LOGL_DEBUG_IO,
 };
 
 /**
@@ -42,7 +44,8 @@ enum log_category_t {
LOGC_ARCH,
LOGC_BOARD,
LOGC_CORE,
-   LOGC_DT,
+   LOGC_DM,/* Core driver-model */
+   LOGC_DT,/* Device-tree */
 
LOGC_COUNT,
LOGC_END,
@@ -256,6 +259,38 @@ struct log_filter {
 #define LOG_DRIVER(_name) \
ll_entry_declare(struct log_driver, _name, log_driver)
 
+/**
+ * log_get_cat_name() - Get the name of a category
+ *
+ * @cat: Category to look up
+ * @return category name (which may be a uclass driver name)
+ */
+const char *log_get_cat_name(enum log_category_t cat);
+
+/**
+ * log_get_cat_by_name() - Look up a category by name
+ *
+ * @name: Name to look up
+ * @return category ID, or LOGC_NONE if not found
+ */
+enum log_category_t log_get_cat_by_name(const char *name);
+
+/**
+ * log_get_level_name() - Get the name of a log level
+ *
+ * @level: Log level to look up
+ * @return log level name (in ALL CAPS)
+ */
+const char *log_get_level_name(enum log_level_t level);
+
+/**
+ * log_get_level_by_name() - Look up a log level by name
+ *
+ * @name: Name to look up
+ * @return log level ID, or LOGL_NONE if not found
+ */
+enum log_level_t log_get_level_by_name(const char *name);
+
 /* Handle the 'log test' command */
 int do_log_test(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[]);
 
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 9/9] log: Add a way to log error-return values

2017-12-28 Thread Simon Glass
When functions return an error it propagates up the stack to the point
where it is reported. Often the error code provides enough information
about the root cause of the error that this is obvious what went wrong.

However in some cases the error may be hard to trace. For example if a
driver uses several devices to perform an operation, it may not be
obvious which one failed.

Add a log_ret() macro to help with this. This can be used to wrap any
error-return value. The logging system will then output a log record when
the original error is generated, making it easy to trace the call stack
of the error.

This macro can significantly impact code size, so its use is controlled
by a Kconfig option, which is enabled for sandbox.

Signed-off-by: Simon Glass 
---

 common/Kconfig| 13 +
 configs/sandbox_defconfig |  1 +
 doc/README.log|  8 
 include/log.h | 11 +++
 4 files changed, 33 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 4da095a4fd..c9833b3226 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -504,6 +504,19 @@ config LOG_TEST
  in various different ways to test that the logging system works
  correctly with varoius settings.
 
+config LOG_ERROR_RETURN
+   bool "Log all functions which return an error"
+   depends on LOG
+   help
+ When an error is returned in U-Boot it is sometimes difficult to
+ figure out the root cause. For eaxmple, reading from SPI flash may
+ fail due to a problem in the SPI controller or due to the flash part
+ not returning the expected information. This option changes
+ log_ret() to log any errors it sees. With this option disabled,
+ log_ret() is a nop.
+
+ You can add log_ret() to all functions which return an error code.
+
 endmenu
 
 config DEFAULT_FDT_FILE
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 7efb4ebf11..41a2e34235 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -18,6 +18,7 @@ CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_PRE_CON_BUF_ADDR=0x10
 CONFIG_LOG=y
 CONFIG_LOG_MAX_LEVEL=6
+CONFIG_LOG_ERROR_RETURN=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
 CONFIG_CMD_BOOTZ=y
diff --git a/doc/README.log b/doc/README.log
index 54d9a8e1b9..2abaee0c10 100644
--- a/doc/README.log
+++ b/doc/README.log
@@ -148,6 +148,14 @@ Also debug() and error() will generate log records  - 
these use LOG_CATEGORY
 as the category, so you should #define this right at the top of the source
 file to ensure the category is correct.
 
+You can also define CONFIG_LOG_ERROR_RETURN to enable the log_ret() macro. This
+can be used whenever your function returns an error value:
+
+   return log_ret(uclass_first_device(UCLASS_MMC, &dev));
+
+This will write a log record when an error code is detected (a value < 0). This
+can make it easier to trace errors that are generated deep in the call stack.
+
 
 Code size
 -
diff --git a/include/log.h b/include/log.h
index 828919a409..68368d5cf1 100644
--- a/include/log.h
+++ b/include/log.h
@@ -159,6 +159,17 @@ void __assert_fail(const char *assertion, const char 
*file, unsigned int line,
({ if (!(x) && _DEBUG) \
__assert_fail(#x, __FILE__, __LINE__, __func__); })
 
+#ifdef CONFIG_LOG_ERROR_RETURN
+#define log_ret(_ret) ({ \
+   int __ret = (_ret); \
+   if (__ret < 0) \
+   log(LOG_CATEGORY, LOGL_ERR, "returning err=%d\n", __ret); \
+   __ret; \
+   })
+#else
+#define log_ret(_ret) (_ret)
+#endif
+
 /**
  * struct log_rec - a single log record
  *
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 6/9] log: Add a command to output a log record

2017-12-28 Thread Simon Glass
Add a 'log rec' command which allows a log record to be manually output.
This is useful for scripts which want full control over what is logged. It
also permits easy testing of the log system.

Signed-off-by: Simon Glass 
---

 cmd/log.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/cmd/log.c b/cmd/log.c
index e038bc3269..12bac0e03c 100644
--- a/cmd/log.c
+++ b/cmd/log.c
@@ -59,12 +59,49 @@ static int do_log_format(cmd_tbl_t *cmdtp, int flag, int 
argc,
return 0;
 }
 
+static int do_log_rec(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   enum log_category_t cat;
+   enum log_level_t level;
+   const char *file;
+   uint line;
+   const char *func;
+   const char *msg;
+   char *end;
+
+   if (argc < 7)
+   return CMD_RET_USAGE;
+   cat = log_get_cat_by_name(argv[1]);
+   level = simple_strtoul(argv[2], &end, 10);
+   if (end == argv[2]) {
+   level = log_get_level_by_name(argv[2]);
+
+   if (level == LOGL_NONE) {
+   printf("Invalid log level '%s'\n", argv[2]);
+   return CMD_RET_USAGE;
+   }
+   }
+   if (level >= LOGL_MAX) {
+   printf("Invalid log level %u\n", level);
+   return CMD_RET_USAGE;
+   }
+   file = argv[3];
+   line = simple_strtoul(argv[4], NULL, 10);
+   func = argv[5];
+   msg = argv[6];
+   if (_log(cat, level, file, line, func, "%s\n", msg))
+   return CMD_RET_FAILURE;
+
+   return 0;
+}
+
 static cmd_tbl_t log_sub[] = {
U_BOOT_CMD_MKENT(level, CONFIG_SYS_MAXARGS, 1, do_log_level, "", ""),
 #ifdef CONFIG_LOG_TEST
U_BOOT_CMD_MKENT(test, 2, 1, do_log_test, "", ""),
 #endif
U_BOOT_CMD_MKENT(format, CONFIG_SYS_MAXARGS, 1, do_log_format, "", ""),
+   U_BOOT_CMD_MKENT(rec, CONFIG_SYS_MAXARGS, 1, do_log_rec, "", ""),
 };
 
 static int do_log(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
@@ -94,7 +131,9 @@ static char log_help_text[] =
"log format  - set log output format.  is a string where\n"
"\teach letter indicates something that should be displayed:\n"
"\tc=category, l=level, F=file, L=line number, f=function, m=msg\n"
-   "\tor 'default', equivalent to 'fm', or 'all' for all"
+   "\tor 'default', equivalent to 'fm', or 'all' for all\n"
+   "log rec   - "
+   "output a log record"
;
 #endif
 
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 4/9] log: Update log_console to honour the log format

2017-12-28 Thread Simon Glass
At present this just outputs the message. Update it to output whatever the
format requests.

Signed-off-by: Simon Glass 
---

 common/log_console.c  | 27 ++-
 test/py/tests/test_log.py |  4 ++--
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/common/log_console.c b/common/log_console.c
index 5af73bd8be..2902733078 100644
--- a/common/log_console.c
+++ b/common/log_console.c
@@ -10,9 +10,34 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static int log_console_emit(struct log_device *ldev, struct log_rec *rec)
 {
-   puts(rec->msg);
+   int fmt = gd->log_fmt;
+
+   /*
+* The output format is designed to give someone a fighting chance of
+* figuring out which field is which:
+*- level is in CAPS
+*- cat is lower case and ends with comma
+*- file normally has a .c extension and ends with a colon
+*- line is integer and ends with a -
+*- function is an identifier and ends with ()
+*- message has a space before it unless it is on its own
+*/
+   if (fmt & (1 << LOGF_LEVEL))
+   printf("%s.", log_get_level_name(rec->level));
+   if (fmt & (1 << LOGF_CAT))
+   printf("%s,", log_get_cat_name(rec->cat));
+   if (fmt & (1 << LOGF_FILE))
+   printf("%s:", rec->file);
+   if (fmt & (1 << LOGF_LINE))
+   printf("%d-", rec->line);
+   if (fmt & (1 << LOGF_FUNC))
+   printf("%s()", rec->func);
+   if (fmt & (1 << LOGF_MSG))
+   printf("%s%s", fmt != (1 << LOGF_MSG) ? " " : "", rec->msg);
 
return 0;
 }
diff --git a/test/py/tests/test_log.py b/test/py/tests/test_log.py
index fa9a25e8dc..517f415143 100644
--- a/test/py/tests/test_log.py
+++ b/test/py/tests/test_log.py
@@ -28,9 +28,9 @@ def test_log(u_boot_console):
 """
 for i in range(max_level):
 if mask & 1:
-assert 'log %d' % i == lines.next()
+assert 'log_run() log %d' % i == lines.next()
 if mask & 3:
-assert '_log %d' % i == lines.next()
+assert 'func() _log %d' % i == lines.next()
 
 def run_test(testnum):
 """Run a particular test number (the 'log test' command)
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 5/9] log: Add a command to control the log output format

2017-12-28 Thread Simon Glass
Add a 'log format' command which can display or change the log output
format. This is useful for changing how much information is displayed. The
ordering of the fields is fixed.

Signed-off-by: Simon Glass 
---

 cmd/log.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/cmd/log.c b/cmd/log.c
index abc523b497..e038bc3269 100644
--- a/cmd/log.c
+++ b/cmd/log.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+static char log_fmt_chars[LOGF_COUNT] = "clFLfm";
+
 static int do_log_level(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
@@ -21,11 +23,48 @@ static int do_log_level(cmd_tbl_t *cmdtp, int flag, int 
argc,
return 0;
 }
 
+static int do_log_format(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+   int i;
+
+   if (argc > 1) {
+   const char *str = argv[1];
+
+   if (!strcmp(str, "default")) {
+   gd->log_fmt = LOGF_DEFAULT;
+   } else if (!strcmp(str, "all")) {
+   gd->log_fmt = LOGF_ALL;
+   } else {
+   gd->log_fmt = 0;
+   for (; *str; str++) {
+   char *ptr = strchr(log_fmt_chars, *str);
+
+   if (!ptr) {
+   printf("Invalid log char '%c'\n", *str);
+   return CMD_RET_FAILURE;
+   }
+   gd->log_fmt |= 1 << (ptr - log_fmt_chars);
+   }
+   }
+   } else {
+   printf("Log format: ");
+   for (i = 0; i < LOGF_COUNT; i++) {
+   if (gd->log_fmt & (1 << i))
+   printf("%c", log_fmt_chars[i]);
+   }
+   printf("\n");
+   }
+
+   return 0;
+}
+
 static cmd_tbl_t log_sub[] = {
U_BOOT_CMD_MKENT(level, CONFIG_SYS_MAXARGS, 1, do_log_level, "", ""),
 #ifdef CONFIG_LOG_TEST
U_BOOT_CMD_MKENT(test, 2, 1, do_log_test, "", ""),
 #endif
+   U_BOOT_CMD_MKENT(format, CONFIG_SYS_MAXARGS, 1, do_log_format, "", ""),
 };
 
 static int do_log(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
@@ -52,6 +91,10 @@ static char log_help_text[] =
 #ifdef CONFIG_LOG_TEST
"log test - run log tests\n"
 #endif
+   "log format  - set log output format.  is a string where\n"
+   "\teach letter indicates something that should be displayed:\n"
+   "\tc=category, l=level, F=file, L=line number, f=function, m=msg\n"
+   "\tor 'default', equivalent to 'fm', or 'all' for all"
;
 #endif
 
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH 8/9] log: Add documentation for commands and formatting

2017-12-28 Thread Simon Glass
Add some notes about recent new features.

Signed-off-by: Simon Glass 
---

 doc/README.log | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/doc/README.log b/doc/README.log
index f653fe7d79..54d9a8e1b9 100644
--- a/doc/README.log
+++ b/doc/README.log
@@ -68,6 +68,19 @@ If CONFIG_LOG is not set, then no logging will be available.
 The above have SPL versions also, e.g. CONFIG_SPL_MAX_LOG_LEVEL.
 
 
+Log commands
+
+
+The 'log' command provides access to several features:
+
+   level - access the default log level
+   format - access the console log format
+   rec - output a log record
+   test - run tests
+
+Type 'help log' for details.
+
+
 Using DEBUG
 ---
 
@@ -94,6 +107,20 @@ enabled or disabled independently:
console - goes to stdout
 
 
+Log format
+--
+
+You can control the log format using the 'log format' command. The basic
+format is:
+
+   LEVEL.category,file.c:123-func() message
+
+In the above, file.c:123 is the filename where the log record was generated and
+func() is the function name. By default ('log format default') only the
+function name and message are displayed on the console. You can control which
+fields are present, but not the field order.
+
+
 Filters
 ---
 
-- 
2.15.1.620.gb9897f4670-goog

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


[U-Boot] [PATCH] configs: am335x_boneblack: Bring back missed bootcmd

2017-12-28 Thread Sam Protsenko
Commit b6251db8c3f0 ("Kconfig: Introduce USE_BOOTCOMMAND and migrate
BOOTCOMMAND") removed CONFIG_BOOTCOMMAND option from
include/configs/am335x_evm.h file. But that option wasn't added to
defconfig files for BeagleBone Black board.

Because of this we can't boot Linux from SD card using just
"run bootcmd", getting next error:

** File not found /boot/undefined **

That's because "fdtfile" variable has "undefined" value by default, and
"bootcmd" doesn't call "run findfdt" command, which assigns "fdtfile" to
correct device tree file for current board name (obtained from EEPROM).

So we are forced to either call "run findfdt" command manually, or
assign manually "fdtfile=am335x-boneblack.dtb" (e.g. in uEnv.txt file).

Bring back CONFIG_BOOTCOMMAND to BBB defconfigs so that we can boot
Linux rootfs from SD card automatically without any addition actions.

Signed-off-by: Sam Protsenko 
---
 configs/am335x_boneblack_defconfig   | 1 +
 configs/am335x_boneblack_vboot_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/am335x_boneblack_defconfig 
b/configs/am335x_boneblack_defconfig
index 55e0ebd69c..50093cd662 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -5,6 +5,7 @@ CONFIG_AM33XX=y
 # CONFIG_SPL_NAND_SUPPORT is not set
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
+CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run 
findfdt; run init_console; run envboot; run distro_bootcmd"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_ARCH_MISC_INIT=y
diff --git a/configs/am335x_boneblack_vboot_defconfig 
b/configs/am335x_boneblack_vboot_defconfig
index fe5b9e7622..aa9fb9739e 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -8,6 +8,7 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
+CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run 
findfdt; run init_console; run envboot; run distro_bootcmd"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_ARCH_MISC_INIT=y
-- 
2.15.1

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


Re: [U-Boot] How to restore NVRAM on MTD partition from backup

2017-12-28 Thread Lukasz Majewski
Hi,

> Missed that mail :(
> 
> it's old board, I have no source code for that customized version of
> bootloader.
> 
> I have commands 
> loadb   - load binary file over serial line (kermit mode)
> loads   - load S-Record file over serial line
> loady   - load binary file over serial line (ymodem mode)

You should be able to use kermit to upload new data to RAM (to some
address).

> 
> NAND device: Manufacturer ID: 0xad, Chip ID: 0x75 (Hynix NAND 32MiB
> 3,3V 8-bit) The NVRAM is MTD partition on "gen_nand":
> 0x01f0-0x01f8 : "NVRAM"
> dev:size   erasesize  name
> mtd9: 0008 4000 "NVRAM"

So the NVRAM is a mtd partition for NAND.

What is the output of mtdparts command?

> 
> The cp command is available in bootloader
> 
> # help cp
> cp [.b, .w, .l] source target count
> - copy memory

It should be enough to use "nand" commands:
https://www.denx.de/wiki/DULG/UBootCmdGroupNand

Erase, then write the mtd9 partition.

> 
> 
> 
> 
> Regards,
> Alex
> 
> On Fri, 12/22/17, Lukasz Majewski  wrote:
> 
>  Subject: Re: [U-Boot] How to restore NVRAM on MTD partition from
> backup To: "A.W.C." 
>  Cc: u-boot@lists.denx.de
>  Date: Friday, December 22, 2017, 11:58 PM
>  
>  On Wed, 20 Dec 2017 13:19:58
>  + (UTC)
>  "A.W.C." 
>  wrote:
>  
>  > Hi,
>  > 
>  > U-Boot 2009.03 on  
>  custom board. 
>  
>  Nice :-)
>  
>  I assume that it is not
>  possible to move to newer one?
>  
>  >How to restore NVRAM on MTD partition
>  > from backup use U-boot memory commands, by  
>  uploading backup over
>  > serial line?  
>  (kermit mode or ymodem mode) NAND flash type.
>  
>  It depends on what commands do
>  you have?
>  
>  Yes, it would be
>  best to use load command to get the data via serial
>  line, store it in RAM and then flash it on
>  persistent memory.
>  
>  How do
>  you access NVRAM? (Is it really this memory - not some
>  Parallel
>  NAND, SPI-NOR, OneNAND)?
>  
>  If it has a custom driver
>  ,then you may want to look for 'cp' or other
>  command.
>  
>  >  
>  
>  > Regards,
>  >  
>  Alex
>  > 
>  > 
>  >  
>  ___
>  > U-Boot mailing list
>  >  
>  U-Boot@lists.denx.de
>  > https://lists.denx.de/listinfo/u-boot  
>  
>  
>  
>  Best regards,
>  
>  Lukasz Majewski
>  
>  --
>  
>  DENX
>  Software Engineering GmbH,      Managing Director:
>  Wolfgang Denk
>  HRB 165235 Munich, Office:
>  Kirchenstr.5, D-82194 Groebenzell, Germany
>  Phone: (+49)-8142-66989-10 Fax:
>  (+49)-8142-66989-80 Email: w...@denx.de



Best regards,

Lukasz Majewski

--

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


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


Re: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

2017-12-28 Thread Derald D. Woods
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
> On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
> > On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
> > > On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> > > > On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > > > > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > > > > 
> > > > > > This commit keeps the 'fdtaddr' as provided by 
> > > > > > DEFAULT_LINUX_BOOT_ENV.
> > > > > > 
> > > > > > Signed-off-by: Derald D. Woods 
> > > > > > ---
> > > > > >  include/configs/omap3_evm.h | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/include/configs/omap3_evm.h 
> > > > > > b/include/configs/omap3_evm.h
> > > > > > index 629d60b961..d95ccdf035 100644
> > > > > > --- a/include/configs/omap3_evm.h
> > > > > > +++ b/include/configs/omap3_evm.h
> > > > > > @@ -127,6 +127,7 @@
> > > > > > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > > > > > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > > > > > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > > > > +   "fdt_high=0x\0" \
> > > > > > "bootenv=uEnv.txt\0" \
> > > > > > "optargs=\0" \
> > > > > > "mmcdev=0\0" \
> > > > > 
> > > > > What's the problem this solves, and how much memory is on the system 
> > > > > in
> > > > > question?  bootm_size should be ensuring we never relocate it outside 
> > > > > of
> > > > > the first 256MB of memory.  Thanks!
> > > > > 
> > > > 
> > > > The logic within "common/image-fdt.c" lead me down this path. The
> > > > addition of this fairly common environment variable allowed my
> > > > OMAP34XX board to boot the kernel without an appended devicetree.
> > > > When I use the variable to trigger 'disable_relocation', as the code
> > > > indicates, the kernel boot behavior is what I expect. I spent a few
> > > > hours following the code path to a single line edition that works.
> > > > 
> > > > 
> > > > Without 'fdt_high'
> > > > ==
> > > > 
> > > > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> > > > Trying to boot from MMC1
> > > > reading u-boot.img
> > > > reading u-boot.img
> > > > 
> > > > 
> > > > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 
> > > > -0600)
> > > > 
> > > > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > > > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > > > OMAP3 EVM board + LPDDR/NAND
> > > > I2C:   ready
> > > > DRAM:  256 MiB
> > > > NAND:  256 MiB
> > > > MMC:   OMAP SD/MMC: 0
> > > > Read back SMSC id 0x9220
> > > > OMAP die ID: 265a0024040365fa1801b01f
> > > > Net:   smc911x-0
> > > > starting USB...
> > > > USB0:   USB EHCI 1.00
> > > > scanning bus 0 for devices... 1 USB Device(s) found
> > > > Hit any key to stop autoboot:  0 
> > > > switch to partitions #0, OK
> > > > mmc0 is current device
> > > > Scanning mmc 0:1...
> > > > switch to partitions #0, OK
> > > > mmc0 is current device
> > > > ** Unable to read file uEnv.txt **
> > > > reading zImage
> > > > 4637344 bytes read in 407 ms (10.9 MiB/s)
> > > > reading omap3-evm.dtb
> > > > 62832 bytes read in 10 ms (6 MiB/s)
> > > > Booting zImage from mmc ...
> > > > *  fdt: cmdline image address = 0x8800
> > > > ## Checking for 'FDT'/'FDT Image' at 8800
> > > > *  fdt: raw FDT blob
> > > > ## Flattened Device Tree blob at 8800
> > > >Booting using the fdt blob at 0x8800
> > > >of_flat_tree at 0x8800 size 0xf570
> > > > ## device tree at 8800 ... 8800f56f (len=75120 [0x12570])
> > > >Loading Device Tree to 8ffed000, end 856f ... OK
> > > > 
> > > > Starting kernel ...
> > > > 
> > > > [HANG]
> > > > 
> > > > 
> > > > Make note of the "of_flat_tree" and "Loading Device Tree" lines.
> > > 
> > > Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
> > > 0x0a00 ?  I wonder if, since you have 256MB of memory we're not
> > > putting the DTB into where U-Boot is and we stomp on it a bit, causing
> > > Linux to boot, see an invalid DTB and not have a console available to
> > > tell us.  Thanks!
> > > 
> > 
> > 
> > That seemed to do it.
> 
> Ah, good!
> 
> > ---8<
> > 
> > OMAP3_EVM # echo $bootm_size
> > 0x0a00
> > OMAP3_EVM # reset
> > resetting ...
> > O
> > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42)
> > Trying to boot from MMC1
> > reading u-boot.img
> > reading u-boot.img
> > 
> > 
> > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
> > 
> > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > OMAP3 EVM board + LPDDR/NAND
> > I2C:   ready
> > DRAM:  256 MiB
> > NAND:  256 MiB
> > MMC:   OMAP SD/MMC: 0
> > Read back SMSC id 0x9220
> > OMAP die ID: 265a0024040365fa1801b01f
> > Net:   smc911x-0
> > starting USB...
> > USB0:   U

Re: [U-Boot] [PATCH 01/14] cmd: nvedit: Get rid of the env lookup

2017-12-28 Thread Simon Glass
On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
>
> The nvedit command is the only user of env_driver_lookup_default outside of
> the environment code itself, and it uses it only to print the environment
> it's about to save to during env save.
>
> As we're about to rework the environment to be able to handle multiple
> environment sources, we might not have an idea of what environment backend
> is going to be used before trying (and possibly failing for some).
>
> Therefore, it makes sense to remove that message and move it to the
> env_save function itself. As a side effect, we also can get rid of the call
> to env_driver_lookup_default that is also about to get refactored.
>
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 
> ---
>  cmd/nvedit.c  | 4 
>  env/env.c | 4 +++-
>  include/environment.h | 7 ---
>  3 files changed, 3 insertions(+), 12 deletions(-)

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


Re: [U-Boot] [PATCH 02/14] env: Rename env_driver_lookup_default and env_get_default_location

2017-12-28 Thread Simon Glass
On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> The env_driver_lookup_default and env_get_default_location functions are
> about to get refactored to support loading from multiple environment.
>
> The name is therefore not really well suited anymore. Drop the default
> part to be a bit more relevant.
>
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)

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


Re: [U-Boot] [PATCH 03/14] env: Pass additional parameters to the env lookup function

2017-12-28 Thread Simon Glass
Hi Maxime,

On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> In preparation for the multiple environment support, let's introduce two
> new parameters to the environment driver lookup function: the priority and
> operation.
>
> The operation parameter is meant to identify, obviously, the operation you
> might want to perform on the environment.
>
> The priority is a number passed to identify the environment priority you
> want to retrieve. The lowest priority parameter (0) will be the primary
> source.
>
> Combining the two parameters allow you to support multiple environments
> through different priorities, and to change those priorities between read
> and writes operations.
>
> This is especially useful to implement migration mechanisms where you want
> to always use the same environment first, be it to read or write, while the
> common case is more likely to use the same environment it has read from to
> write it to.
>
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 122 +--
>  include/environment.h |   7 ++-
>  2 files changed, 80 insertions(+), 49 deletions(-)
>
> diff --git a/env/env.c b/env/env.c
> index 97ada5b5a6fd..673bfa6ba41b 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -26,8 +26,11 @@ static struct env_driver *_env_driver_lookup(enum 
> env_location loc)
> return NULL;
>  }
>
> -static enum env_location env_get_location(void)
> +static enum env_location env_get_location(enum env_operation op, int prio)
>  {
> +   if (prio >= 1)
> +   return ENVL_UNKNOWN;
> +
> if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
> return ENVL_EEPROM;
> else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
> @@ -52,11 +55,14 @@ static enum env_location env_get_location(void)
> return ENVL_UNKNOWN;
>  }
>
> -static struct env_driver *env_driver_lookup(void)
> +static struct env_driver *env_driver_lookup(enum env_operation op, int prio)

Can you please document the function args? The operation of prio needs
to be described somewhere.

>  {
> -   enum env_location loc = env_get_location();
> +   enum env_location loc = env_get_location(op, prio);
> struct env_driver *drv;
>
> +   if (loc == ENVL_UNKNOWN)
> +   return NULL;

Why is this needed? Shouldn't _env_driver_lookup() return NULL in this
case anyway?

> +
> drv = _env_driver_lookup(loc);
> if (!drv) {
> debug("%s: No environment driver for location %d\n", __func__,
> @@ -69,83 +75,101 @@ static struct env_driver *env_driver_lookup(void)
>
>  int env_get_char(int index)
>  {
> -   struct env_driver *drv = env_driver_lookup();
> -   int ret;
> +   struct env_driver *drv;
> +   int prio;
>
> if (gd->env_valid == ENV_INVALID)
> return default_environment[index];
> -   if (!drv)
> -   return -ENODEV;
> -   if (!drv->get_char)
> -   return *(uchar *)(gd->env_addr + index);
> -   ret = drv->get_char(index);
> -   if (ret < 0) {
> -   debug("%s: Environment failed to load (err=%d)\n",
> - __func__, ret);
> +
> +   for (prio = 0; (drv = env_driver_lookup(ENVO_GET_CHAR, prio)); 
> prio++) {
> +   int ret;
> +
> +   if (!drv->get_char)
> +   continue;
> +
> +   ret = drv->get_char(index);
> +   if (!ret)
> +   return 0;
> +
> +   debug("%s: Environment %s failed to load (err=%d)\n", 
> __func__,
> + drv->name, ret);
> }
>
> -   return ret;
> +   return -ENODEV;
>  }
>
>  int env_load(void)
>  {
> -   struct env_driver *drv = env_driver_lookup();
> -   int ret = 0;
> +   struct env_driver *drv;
> +   int prio;
>
> -   if (!drv)
> -   return -ENODEV;
> -   if (!drv->load)
> -   return 0;
> -   ret = drv->load();
> -   if (ret) {
> -   debug("%s: Environment failed to load (err=%d)\n", __func__,
> - ret);
> -   return ret;
> +   for (prio = 0; (drv = env_driver_lookup(ENVO_LOAD, prio)); prio++) {
> +   int ret;
> +
> +   if (!drv->load)
> +   continue;
> +
> +   ret = drv->load();
> +   if (!ret)
> +   return 0;
> +
> +   debug("%s: Environment %s failed to load (err=%d)\n", 
> __func__,
> + drv->name, ret);
> }
>
> -   return 0;
> +   return -ENODEV;
>  }
>
>  int env_save(void)
>  {
> -   struct env_driver *drv = env_driver_lookup();
> -   int ret;
> +   struct env_driver *drv;
> +   int prio;
>
> -   if (!drv)
> -   return -ENODEV;
> -   if (!drv->save)
> -   return -ENOSYS;
> -
> -   printf("Saving Environment to %s...\n", drv->name);
> -   ret = drv->save();
>

Re: [U-Boot] [PATCH 11/14] env: Allow to build multiple environments in Kconfig

2017-12-28 Thread Simon Glass
On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> Now that we have everything in place in the code, let's allow to build
> multiple environments backend through Kconfig.
>
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 
> ---
>  env/Kconfig | 65 ++
>  1 file changed, 32 insertions(+), 33 deletions(-)

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


Re: [U-Boot] [PATCH 12/14] env: Mark env_get_location as weak

2017-12-28 Thread Simon Glass
Hi Maxime,

On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> Allow boards and architectures to override the default environment lookup
> code by overriding env_get_location.
>
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/env/env.c b/env/env.c
> index b4d8886e7a69..9b8b38cf3c2b 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -62,7 +62,7 @@ static enum env_location env_locations[] = {
>
>  static enum env_location env_load_location;
>
> -static enum env_location env_get_location(enum env_operation op, int prio)
> +__weak enum env_location env_get_location(enum env_operation op, int prio)

Is it possible instead to make this deterministic, so that the board
sets up the location during boot?

>  {
> switch (op) {
> case ENVO_GET_CHAR:
> --
> git-series 0.9.1
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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


Re: [U-Boot] [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no SPL

2017-12-28 Thread Simon Glass
On 19 December 2017 at 18:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> 64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE
> when building. Fix the binman .dts file so that it doesn't use undefined
> values.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/dts/tegra-u-boot.dtsi | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)

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


Re: [U-Boot] [PATCH 10/14] env: Initialise all the environments

2017-12-28 Thread Simon Glass
Hi Maxime,

On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> Since we want to have multiple environments, we will need to initialise
> all the environments since we don't know at init time what drivers might
> fail when calling load.
>
> Let's init all of them, and only consider for further operations the ones
> that have not reported any errors at init time.
>
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 19 ---
>  include/asm-generic/global_data.h |  1 +
>  2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/env/env.c b/env/env.c
> index 5176700133d3..b4d8886e7a69 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -112,6 +112,9 @@ int env_get_char(int index)
> if (!drv->get_char)
> continue;
>
> +   if (!(gd->env_has_init & BIT(drv->location)))
> +   continue;
> +

Little nit. Can you please put the access in functions like
env_has_inited() and env_set_inited()? This allows us to change the
implementation later, and also it more self-documenting.

> ret = drv->get_char(index);
> if (!ret)
> return 0;
> @@ -134,6 +137,9 @@ int env_load(void)
> if (!drv->load)
> continue;
>
> +   if (!(gd->env_has_init & BIT(drv->location)))
> +   continue;
> +
> printf("Loading Environment from %s... ", drv->name);
> ret = drv->load();
> printf("%s\n", ret ? "Failed" : "OK");
> @@ -155,6 +161,9 @@ int env_save(void)
> if (!drv->save)
> continue;
>
> +   if (!(gd->env_has_init & BIT(drv->location)))
> +   continue;
> +
> printf("Saving Environment to %s... ", drv->name);
> ret = drv->save();
> printf("%s\n", ret ? "Failed" : "OK");
> @@ -175,14 +184,10 @@ int env_init(void)
> int prio;
>
> for (prio = 0; (drv = env_driver_lookup(ENVO_INIT, prio)); prio++) {
> -   if (!drv->init)
> -   continue;
> -
> -   ret = drv->init();
> -   if (!ret)
> -   return 0;
> +   if (!drv->init || !drv->init())
> +   gd->env_has_init |= BIT(drv->location);
>
> -   debug("%s: Environment %s failed to init (err=%d)\n", 
> __func__,
> +   debug("%s: Environment %s init done (ret=%d)\n", __func__,
>   drv->name, ret);
> }
>
> diff --git a/include/asm-generic/global_data.h 
> b/include/asm-generic/global_data.h
> index 944f58195caf..1d0611fe9498 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -50,6 +50,7 @@ typedef struct global_data {
>  #endif
> unsigned long env_addr; /* Address  of Environment struct */
> unsigned long env_valid;/* Environment valid? enum env_valid 
> */
> +   unsigned long env_has_init; /* Bitmask of boolean of struct 
> env_location offsets */
>
> unsigned long ram_top;  /* Top address of RAM used by U-Boot 
> */
> unsigned long relocaddr;/* Start address of U-Boot in RAM */
> --
> git-series 0.9.1
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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


Re: [U-Boot] [PATCH] Travis-CI: Split 't208xrdb t4qds t102*'-job into separate jobs

2017-12-28 Thread Simon Glass
Hi Philipp,

On 20 December 2017 at 03:06, Philipp Tomsich
 wrote:
> The 't208xrdb t4qds t102*' job is close to the time limit and
> sometimes fails, so this splits it into 3 separate jobs.

Should buidman have a time limit parameter? Then it could build for
(say) and hour and exit after that, writing out the boards that it
completed building.

It would be fairly easy to implement.

Regards,
Simon

>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  .travis.yml | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 0b7a062..8a220cc 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -206,7 +206,11 @@ matrix:
>  - env:
>  - BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x p1_p2_rdb_pc -x 
> p1010rdb -x corenet_ds -x b4860qds -x sbc8548 -x bsc91*"
>  - env:
> -- BUILDMAN="t208xrdb t4qds t102*"
> +- BUILDMAN="t208xrdb"
> +- env:
> +- BUILDMAN="t4qds"
> +- env:
> +- BUILDMAN="t102*"
>  - env:
>  - BUILDMAN="p1_p2_rdb_pc"
>  - env:
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] dm: core: remove orphaned parameter description in platdata.h

2017-12-28 Thread Simon Glass
On 24 December 2017 at 05:14, Heinrich Schuchardt  wrote:
> struct driver_info has no field 'flags'.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/dm/platdata.h | 1 -
>  1 file changed, 1 deletion(-)

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


Re: [U-Boot] [PATCH 00/11] Introduce variables whitelisting in environment

2017-12-28 Thread Simon Glass
Hi Quentin,

On 22 December 2017 at 14:13, Quentin Schulz
 wrote:
> This patch series is based on this[1] patch series from Maxime.
>
> This is an RFC. It's been only tested in a specific use case on a custom
> i.MX6 board. It's known to break compilation on a few boards.
>
> I have a use case where we want some variables from a first environment to
> be overriden by variables from a second environment. For example, we want
> to load variables from the default env (ENV_IS_NOWHERE) and then load only
> a handful of other variables from, e.g., NAND.
>
> In our use case, we basically can be sure that the default env in the
> U-Boot binary is secure but we want only a few variables to be modified,
> thus keeping control over the overall behaviour of U-Boot in secure mode.
>
> It works in that way:
>   - from highest to lowest priority, the first environment that can be
>   loaded (that has successfully init and whose load function has returned
>   no errors) will be the main environment,
>   - then, all the following environment that could be successfully loaded
>   (same conditions as the main environment) are secondary environment. The
>   env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and
>   in the secondary environments override the ones in the main environment,
>   - for saving, we save the whole environment to all environments
>   available, be they main or secondary (it does not matter to save the
>   whole environment on secondary environments as only the whitelisted
>   variables will be overriden in the loading process,
>
> I have also a few questions that could help me to get the whole thing to
> work.
>
> 1) I can't really get my head around the use of gd->env_addr, what is it used
> for? It is set in a bunch of different places but only once is it
> explicitly used (basically to alternate the env_addr between the one
> associated to main and redundant environment (in NAND for example)).
>
> 2) Why do we consider ENV_IS_NOWHERE an invalid environment? The only place I
> found a use for it was to just say that if the environment is invalid, we
> should set to default environment (in env_relocate in env/common.c). With
> my patch series I guess that we could remove this fallback and force
> ENV_IS_NOWHERE to be always there.
>
> 3) There are a few (20) boards that set gd->env_addr and gd->env_valid in
> their board file. What is the reason to do such a thing? Isn't those
> overriden anyway by the environment driver?
>
> I'm looking forward to getting your feedback on this patch series.
>

I certainly understand the goal and it seems generally useful.

But I wonder whether this is the best way to implement it.

We could have a UCLASS_ENV uclass, with driver-model drivers which
load the environment (i.e. have load() and save() methods). Config for
the drivers would come from the device tree. Useful drivers would be:

- one that loads the env from a single location
- one that loads multiple envs from different locations in priority order
- one that does what you want

Then people could set their own policy by adding a driver.

I worry that what we have here is quite heavyweight, and will be
imposed on all users, e.g. the size increase of gd, the new logic.
Where does it end? I think splitting things up into different use
cases makes sense.

When I did the env refactor I envisaged using driver-model for the
post-reloc env load/save at some point in the future. It solves the
problem of getting the config (can use device tree) and different
boards wanting to do different things (boards can provide an env
driver).

Regards,
Simon

> Thanks,
> Quentin
>
> [1] https://patchwork.ozlabs.org/cover/842057/
>
> Quentin Schulz (11):
>   env: fix ret not being set and fails when no env could have been init
>   lib: hashtable: support whitelisting env variables
>   env: add support for whitelisting variables from secondary environments
>   env: make nowhere an env medium like the others
>   cmd: saveenv: enable the saveenv command when ENV_IS_NOWHERE is defined but 
> another env medium is enabled too
>   env: add env_driver to env_driver functions' arguments
>   env: gd flags without ENV_READY is enough to discriminate in env_get_default
>   env: add env_driver parameter to env_import_redund
>   env: make env_locations a global variable
>   env: introducing env_info struct for storing info per env
>   env: store information about each environment in gd
>
>  board/sunxi/board.c   |   2 +-
>  cmd/nvedit.c  |  16 ++-
>  common/board_r.c  |   8 +-
>  env/Kconfig   |  29 +++---
>  env/common.c  |  45 ++
>  env/eeprom.c  |  40 -
>  env/env.c | 142 +--
>  env/ext4.c|   4 +-
>  env/fat.c |   4 +-
>  env/flash.c   |  58 ++---
>  env/mmc.c 

Re: [U-Boot] [PATCH 09/14] env: Support multiple environments

2017-12-28 Thread Simon Glass
On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> Now that we have everything in place to support multiple environment, let's
> make sure the current code can use it.
>
> The priority used between the various environment is the same one that was
> used in the code previously.
>
> At read / init times, the highest priority environment is going to be
> detected, and we'll use the same one without lookup during writes. This
> should implement the same behaviour than we currently have.
>
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 75 +---
>  1 file changed, 50 insertions(+), 25 deletions(-)

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


Re: [U-Boot] [PATCH 04/14] env: Make the env save message a bit more explicit

2017-12-28 Thread Simon Glass
On 28 November 2017 at 03:24, Maxime Ripard
 wrote:
> Since we'll soon have support for multiple environments, the environment
> saving message might end up being printed multiple times if the higher
> priority environment cannot be used.
>
> That might confuse the user, so let's make it explicit if the operation
> failed or not.
>
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH RFC] sandbox: Add 64-bit sandbox

2017-12-28 Thread Simon Glass
Hi Mario,

On 20 December 2017 at 07:31, Mario Six  wrote:
> From: Mario Six 
>
> To debug device tree issues involving 32- and 64-bit platforms, it is useful 
> to
> have a generic 64-bit platform available.
>
> Add a version of the sandbox that uses 64-bit integers for its physical
> addresses as well as a modified device tree.
>
> Signed-off-by: Mario Six 
>
> ---
>  arch/sandbox/Kconfig |   6 +
>  arch/sandbox/cpu/cpu.c   |   2 +-
>  arch/sandbox/dts/Makefile|   4 +
>  arch/sandbox/dts/sandbox64.dts   | 317 
> +++
>  arch/sandbox/include/asm/io.h|   6 +
>  arch/sandbox/include/asm/types.h |  14 +-
>  cmd/demo.c   |   6 +-
>  configs/sandbox64_defconfig  | 200 
>  drivers/demo/demo-simple.c   |   2 +-
>  9 files changed, 550 insertions(+), 7 deletions(-)
>  create mode 100644 arch/sandbox/dts/sandbox64.dts
>  create mode 100644 configs/sandbox64_defconfig

Reviewed-by: Simon Glass 

Can you please update the sandbox README?

Also, how does this play with CONFIG_SANDBOX_64BIT and CONFIG_PHYS_64BIT ?

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


Re: [U-Boot] [PATCH 05/14] env: Make it explicit where we're loading our environment from

2017-12-28 Thread Simon Glass
On 5 December 2017 at 03:09, Andre Przywara  wrote:
> On 28/11/17 10:24, Maxime Ripard wrote:
>> Since we can have multiple environments now, it's better to provide a
>> decent indication on what environments were tried and which were the one to
>> fail and succeed.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  env/env.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/env/env.c b/env/env.c
>> index 1d13220aa79b..44f9908e2c2d 100644
>> --- a/env/env.c
>> +++ b/env/env.c
>> @@ -109,12 +109,11 @@ int env_load(void)
>>   if (!drv->load)
>>   continue;
>>
>> + printf("Loading Environment from %s... ", drv->name);
>>   ret = drv->load();
>> + printf("%s\n", ret ? "Failed" : "OK");
>
> This looses the error code that was printed with debug() below. Might be
> worth to keep it? Either always or as a debug?
> printf("%s (%d)\n", ...);
>

Seems like a good idea. Other than that:

Reviewed-by: Simon Glass 


> Cheers,
> Andre.
>
>>   if (!ret)
>>   return 0;
>> -
>> - debug("%s: Environment %s failed to load (err=%d)\n", __func__,
>> -   drv->name, ret);
>>   }
>>
>>   return -ENODEV;
>>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [EXT] Re: Would you please give some advice on our MDIO driver implementaion?

2017-12-28 Thread Simon Glass
Hi Ken,

On 26 December 2017 at 03:38, Ken Ma  wrote:
> Hi Simon & Joe
>
> I've cc the mail, thanks!
>
> BTW, I've implemented Marvell MDIO in plain MDIO APIs as other vendors.
>
> Thanks a lot for your kind help!
> Yours,
> Ken
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2017年12月22日 1:19
> To: Ken Ma
> Cc: joe.hershber...@gmail.com; Wilson Ding; Nadav Haklai; Hua Jing; Victor 
> Gu; Igal Liberman; Stefan Chulski; Stefan Roese
> Subject: [EXT] Re: Would you please give some advice on our MDIO driver 
> implementaion?
>
> External Email
>
> --
> Hi,
>
> Please can you cc the mailing list for U-Boot things?
>
> Regards,
> Simon
>
>
> On 20 December 2017 at 23:55, Ken Ma  wrote:
>> Dear Joe and Simon
>>
>> Excuse me.
>>
>> U-boot v2018 doesn’t have the MDIO support for Armada SoCs(MDIO function is 
>> implemented in net driver - MVPP2 and NETA).
>>
>> We need an unified Marvell MDIO driver for both SMI and XSMI and for
>> both MVPP2 and NETA, the driver can handle complicated mux of PHY and MDIO 
>> bus across different CP module (for example, in a8k MC boards CP1 ETH0 are 
>> connected PHY8 of CP0 XMDIO, CP1 and CP0 are in different address ranges).
>>
>> Now there is no MDIO U-CLASS driver and no MDIO U-CLASS id in u-boot 2018, 
>> other vendors implement their MDIO drivers in plain APIs.
>>
>> My question is whether we should implement MDIO driver in U-CLASS DM 
>> model(in this case, mdio-uclass driver needs to be added).
>>
>> Or is it OK to just provide plain MDIO APIs as other vendors in our Marvell 
>> MDIO driver?
>>
>> Would you please give some advice on our MDIO driver implementation?
>>
>>
>> Thanks a lot for your kind help!
>>
>> Yours,
>> Ken
>>
>> -Original Message-
>> From: Stefan Roese [mailto:s...@denx.de]
>> Sent: 2017年12月21日 14:03
>> To: Ken Ma
>> Cc: Wilson Ding; Nadav Haklai; Hua Jing; Victor Gu; Igal Liberman;
>> Stefan Chulski
>> Subject: Re: Would you please give some advice on our MDIO driver 
>> implementaion?
>>
>> Hi Ken,
>>
>> On 19.12.2017 10:42, Ken Ma wrote:
>>> Hi Stefan
>>>
>>> Excuse me.
>>>
>>> U-boot v2018 doesn’t have the MDIO support for Armada SoCs(MDIO
>>> function is implemented in net driver - MVPP2 and NETA),
>>>
>>> we need an unified Marvell MDIO driver for both SMI and XSMI, the
>>> driver can handle complicated mux of PHY and MDIO bus across
>>> different CP modules
>>>
>>> (for example, in a8k MC boards CP1 ETH0 are connected PHY8 of CP0 XMDIO).
>>>
>>> Now there is no MDIO U-CLASS driver and no MDIO U-CLASS id in u-boot
>>> 2017, other vendors implement their MDIO driver in plain APIs.
>>>
>>> Our question is whether we should implement MDIO driver in U-CLASS DM
>>> model(in this case, mdio-uclass driver needs to be added).
>>>
>>> Or is it OK to just provide plain MDIO APIs as other vendors in our
>>> Marvell MDIO driver?
>>>
>>> Would you please give some advice on our MDIO driver implementation?
>>
>> Implementing a MDIO UCLASS driver would be preferred - at least this is my 
>> first feeling about this. But frankly, I can't decide this. You can either 
>> implement your MDIO / PHY interface in the "normal, plain" APIs and send it 
>> to the list for review and upstream acceptance. But you are correct, that 
>> you might receive comments about using DM with a new MDIO UCLASS for this. 
>> So perhaps its best if you send a mail to the list to ask about this before 
>> implementing it without DM support.
>> Please add Joe Hershberger  (net custodian) and 
>> Simon Glass  (DM custodian) to Cc, if you decide to check 
>> on the list.
>>
>> Thanks,
>> Stefan
>>

Yes this should use driver model. We are likely to start removing
non-DM in 2018 - e,g. boards that don't use CONFIG_BLK will start
being removed after April, I think.

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


[U-Boot] [PATCH v2] armv8: LS1088: Increase size of CONFIG_SYS_MONITOR_LEN

2017-12-28 Thread Ashish Kumar
Total size of relocated u-boot is greater than
current value of 512KB, increase this to 1MB.

Signed-off-by: Ashish Kumar 
---
v2:
Correct commit msg 512KB

 include/configs/ls1088a_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index c96d48d..7ac05ee 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -245,7 +245,7 @@ unsigned long long get_qixis_addr(void);
 
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
 #define CONFIG_SYS_SPL_MALLOC_START0x8020
-#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
+#define CONFIG_SYS_MONITOR_LEN (1024 * 1024)
 #endif
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-- 
2.7.4

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


  1   2   >