Re: [U-Boot] [PATCHv2][RESEND] spi: Add support for N25Q016A

[Jagan Teki]

On 14 July 2016 at 00:00, Moritz Fischer  wrote:
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/mtd/spi/sf_params.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 4f37e33..8ae4eea 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
> {"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM,
> 0},
> {"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM,
> 0},
> {"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM,
>   SECT_4K},
> +   {"N25Q016A",   0x20bb15, 0x1000,64 * 1024,32, RD_NORM,
>   SECT_4K},

Why would we need this ext_id (0x1000) here? I understand this is true
number for this part but it shouldn't require for probe or require
somewhere else?

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/4] fdt_support: define stub for fdt_fixup_mtdparts

[Igor Grinberg]

On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote:
> From: Christopher Spinrath 
> 
> Define an inline stub for fdt_fixup_mtdparts in the case that
> CONFIG_FDT_FIXUP_PARTITIONS is not defined. This avoids the need
> to guard every call to this function by a proper #ifdef in board
> files.
> 
> Signed-off-by: Christopher Spinrath 

Thanks!

Reviewed-by: Igor Grinberg 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] ARM: board: cm_fx6: fixup mtd partitions in the fdt

[Igor Grinberg]

On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote:
> From: Christopher Spinrath 
> 
> The cm-fx6 module has an on-board st,m25p compatible spi flash chip
> used for U-Boot (binary & environment). Overwrite the partitions in
> the device tree by the partition table provided in the mtdparts
> environment variable, if it is set.
> 
> This allows to specify a kernel independent partitioning in the
> environment and provides a convient way for the user to adapt the
> partition table.
> 
> Signed-off-by: Christopher Spinrath 

Acked-by: Igor Grinberg 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] ARM: configs: cm_fx6: add mtd support

[Igor Grinberg]

On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote:
> From: Christopher Spinrath 
> 
> The cm-fx6 module has an on-board spi flash chip. Enable mtd support
> and the mtdparts command. Also define a default partitioning, add
> it to the default environment, and enable support to overwrite the
> partitioning defined in a device tree by it. Finally, probe for the
> chip on preboot to register the flash chip and, thus, establish the
> connection between the mtd environment settings and the actual device.
> 
> These changes move the effective default partitioning from the device
> tree shipped with the vendor kernels to U-Boot which becomes the single
> point of definition for the partitioning for all device tree based
> kernels (in particular, for the upstream Linux kernel which does not
> have a default partitioning defined in its device tree).
> 
> Signed-off-by: Christopher Spinrath 

Acked-by: Igor Grinberg 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] powerpc/mpc85xx: T104x: Add nand secure boot target

[Sumit Garg]

For mpc85xx SoCs, the core begins execution from address 0xFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFF.

For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_ but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_ needs to be mapped to physical address
0xBFFx_.

Create a new PBI file to configure CPC as SRAM with address 0xBFFC
and update DCFG SCRTACH1 register with location of Header required for
secure boot.

The changes are similar to
commit 467a40dfe35f48d830f01a72617207d03ca85b4d
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.

Reviewed-by: Ruchika Gupta 
Reviewed-by: Simon Glass 
Signed-off-by: Aneesh Bansal 
Signed-off-by: Sumit Garg 
---

Changes PATCH v5->PATCH v6:
Incorporated review comments regarding comment style.

Changes PATCH v4->PATCH v5:
No change.

Changes PATCH v3->PATCH v4:
No change.

Changes PATCH v2->PATCH v3:
Patches rebased

Changes PATCH->PATCH v2:
Patches rebased

 arch/powerpc/cpu/mpc85xx/cpu_init.c|  4 +--
 arch/powerpc/cpu/mpc85xx/start.S   | 12 ++--
 arch/powerpc/include/asm/fsl_secure_boot.h | 10 ++-
 board/freescale/t104xrdb/t104x_pbi_sb.cfg  | 38 ++
 board/freescale/t104xrdb/tlb.c | 15 +-
 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 30 
 include/configs/T104xRDB.h | 29 +++-
 7 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 board/freescale/t104xrdb/t104x_pbi_sb.cfg
 create mode 100644 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 61f5639..ace4279 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -439,7 +439,7 @@ ulong cpu_init_f(void)
 #ifdef CONFIG_SYS_DCSRBAR_PHYS
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 #endif
-#if defined(CONFIG_SECURE_BOOT)
+#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT)
struct law_entry law;
 #endif
 #ifdef CONFIG_MPC8548
@@ -459,7 +459,7 @@ ulong cpu_init_f(void)
disable_tlb(14);
disable_tlb(15);
 
-#if defined(CONFIG_SECURE_BOOT)
+#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT)
/* Disable the LAW created for NOR flash by the PBI commands */
law = find_law(CONFIG_SYS_PBI_FLASH_BASE);
if (law.index != -1)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 4c51225..c3e1234 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1069,17 +1069,23 @@ create_init_ram_area:
 #elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT)
/* create a temp mapping in AS = 1 for Flash mapping
 * created by PBL for ISBC code
-   */
+*/
create_tlb1_entry 15, \
1, BOOKE_PAGESZ_1M, \
CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \
CONFIG_SYS_PBI_FLASH_WINDOW & 0xfff0, 
MAS3_SX|MAS3_SW|MAS3_SR, \
0, r6
 
-#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT)
+/*
+ * For Targets without CONFIG_SPL like P3, P5
+ * and for targets with CONFIG_SPL like T1, T2, T4, only for
+ * u-boot-spl i.e. CONFIG_SPL_BUILD
+ */
+#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT) && \
+   (!defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD))
/* create a temp mapping in AS = 1 for mapping CONFIG_SYS_MONITOR_BASE
 * to L3 Address configured by PBL for ISBC code
-   */
+*/
create_tlb1_entry 15, \
1, BOOKE_PAGESZ_1M, \
CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 9420021..2e2d565 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -35,7 +35,9 @@
defined(CONFIG_T104xD4RDB) || \
defined(CONFIG_PPC_T1023) || \
defined(CONFIG_PPC_T1024)
+#ifndef CONFIG_SYS_RAMBOOT
 #define CONFIG_SYS_CPC_REINIT_F
+#endif
 #define CONFIG_KEY_REVOCATION
 #undef CONFIG_SYS_INIT_L3_ADDR
 #define CONFIG_SYS_INIT_L3_ADDR 

[U-Boot] [PATCH 1/3] powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL

[Sumit Garg]

As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
the next level U-boot image. Add a new function spl_validate_uboot to
perform the validation.

Enable hardware crypto operations in SPL using SEC block.
In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
access to CPC configured as SRAM, configure PAMU.

Reviewed-by: Ruchika Gupta 
Signed-off-by: Aneesh Bansal 
Signed-off-by: Sumit Garg 
---

Changes PATCH v5->PATCH v6:
Incorporated review comments regarding comment style.

Changes PATCH v4->PATCH v5:
Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead
of def CONFIG_DM macro to include call to dm_init_and_scan().
As dm_init_and_scan() is called as part of common SPL framework,
so no need to call it again but in case of powerpc platforms which
currently do not use common SPL framework, so need to include this
function call here.

Changes PATCH v3->PATCH v4:
Generic changes in lib, drivers, common Makefiles removed from
this patchset. Rebased this patchset on top of patch [1], so this
patchset is dependent on patch [1].

Changes PATCH v2->PATCH v3:
Patches rebased

Changes PATCH->PATCH v2:
Patches rebased

[1]https://patchwork.ozlabs.org/patch/627664/

 arch/powerpc/cpu/mpc8xxx/fsl_pamu.c |  8 +
 arch/powerpc/cpu/mpc8xxx/pamu_table.c   |  8 +
 arch/powerpc/include/asm/fsl_secure_boot.h  | 31 +++-
 board/freescale/common/fsl_chain_of_trust.c | 56 +
 drivers/crypto/fsl/jr.c | 17 +
 drivers/mtd/nand/fsl_ifc_spl.c  | 24 +
 include/fsl_validate.h  |  7 
 7 files changed, 150 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c 
b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
index 9421f1e..ede8e66 100644
--- a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
@@ -239,15 +239,23 @@ int pamu_init(void)
spaact_size = sizeof(struct paace) * NUM_SPAACT_ENTRIES;
 
/* Allocate space for Primary PAACT Table */
+#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_PPAACT_ADDR))
+   ppaact = (void *)CONFIG_SPL_PPAACT_ADDR;
+#else
ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size);
if (!ppaact)
return -1;
+#endif
memset(ppaact, 0, ppaact_size);
 
/* Allocate space for Secondary PAACT Table */
+#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SPAACT_ADDR))
+   sec = (void *)CONFIG_SPL_SPAACT_ADDR;
+#else
sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size);
if (!sec)
return -1;
+#endif
memset(sec, 0, spaact_size);
 
ppaact_phys = virt_to_phys((void *)ppaact);
diff --git a/arch/powerpc/cpu/mpc8xxx/pamu_table.c 
b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
index 26c5ea4..a8e6f51 100644
--- a/arch/powerpc/cpu/mpc8xxx/pamu_table.c
+++ b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
@@ -28,6 +28,14 @@ void construct_pamu_addr_table(struct pamu_addr_tbl *tbl, 
int *num_entries)
 
i++;
 #endif
+#if (defined(CONFIG_SPL_BUILD) && (CONFIG_SYS_INIT_L3_VADDR))
+   tbl->start_addr[i] =
+   (uint64_t)virt_to_phys((void *)CONFIG_SYS_INIT_L3_VADDR);
+   tbl->size[i] = 256 * 1024; /* 256K CPC flash */
+   tbl->end_addr[i] = tbl->start_addr[i] +  tbl->size[i] - 1;
+
+   i++;
+#endif
debug("PAMU address\t\t\tsize\n");
for (j = 0; j < i ; j++)
debug("%llx \t\t\t%llx\n",  tbl->start_addr[j],  tbl->size[j]);
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 826f9c9..9420021 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -72,6 +72,32 @@
 
 #ifdef CONFIG_CHAIN_OF_TRUST
 
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_DM  1
+#define CONFIG_SPL_CRYPTO_SUPPORT
+#define CONFIG_SPL_HASH_SUPPORT
+#define CONFIG_SPL_RSA
+#define CONFIG_SPL_DRIVERS_MISC_SUPPORT
+/*
+ * PPAACT and SPAACT table for PAMU must be placed on DDR after DDR init
+ * due to space crunch on CPC and thus malloc will not work.
+ */
+#define CONFIG_SPL_PPAACT_ADDR 0x2e00
+#define CONFIG_SPL_SPAACT_ADDR 0x2f00
+#define CONFIG_SPL_JR0_LIODN_S 454
+#define CONFIG_SPL_JR0_LIODN_NS458
+/*
+ * Define the key hash for U-Boot here if public/private key pair used to
+ * sign U-boot are different from the SRK hash put in the fuse
+ * Example of defining KEY_HASH is
+ * #define CONFIG_SPL_UBOOT_KEY_HASH \
+ *  "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
+ * else leave it defined as NULL
+ */
+
+#define CONFIG_SPL_UBOOT_KEY_HASH  NULL
+#endif /* ifdef CONFIG_SPL_BUILD */
+
 #define CONFIG_CMD_ESBC_VALIDATE
 #define CONFIG_CMD_BLOB
 #define CONFIG_FSL_SEC_MON
@@ -82,7 +108,9 @@
 #define CONFIG_FSL_CAAM
 #endif
 
-/* fsl_setenv_chain_of_trust() must be called from
+#ifndef CONFIG_SPL_BUIL

[U-Boot] [PATCH 3/3] doc: SPL: Add README for secure boot support

[Sumit Garg]

Adds information regarding SPL handling validation process of main u-boot
image on power/mpc85xx and arm/layerscape platforms.

Signed-off-by: Sumit Garg 
---

Changes PATCH v5->PATCH v6:
Added README for SECURE BOOT support in SPL framework.

 doc/SPL/README.spl-secure-boot | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 doc/SPL/README.spl-secure-boot

diff --git a/doc/SPL/README.spl-secure-boot b/doc/SPL/README.spl-secure-boot
new file mode 100644
index 000..f2f8d78
--- /dev/null
+++ b/doc/SPL/README.spl-secure-boot
@@ -0,0 +1,18 @@
+Overview of SPL verified boot on powerpc/mpc85xx & arm/layerscape platforms
+===
+
+Introduction
+
+
+This document provides an overview of how SPL verified boot works on powerpc/
+mpc85xx & arm/layerscape platforms.
+
+Methodology
+---
+
+The SPL image is responsible for loading the next stage boot loader, which is
+the main u-boot image. For secure boot process on these platforms ROM verifies
+SPL image, so to continue chain of trust SPL image verifies U-boot image using
+spl_validate_uboot(). This function uses QorIQ Trust Architecture header
+(appended to U-boot image) to validate the U-boot binary just before passing
+control to it.
-- 
1.8.1.4

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

[U-Boot] does u-boot automatically determine valid command abbreviations?

[Robert P. J. Day]

  i just want to confirm that u-boot *automatically* determines the
valid prefix abbreviations for u-boot commands, correct? as in, there
is no registration or configuration to do that, it's done
automatically based on the commands that have been configured into
u-boot and whether a command abbreviation represents a unique prefix
for all configured commands, yes?

  i'm making that assumption based on this routine from
common/command.c:

  /* find command table entry for a command */
  cmd_tbl_t *find_cmd_tbl(const char *cmd, cmd_tbl_t *table, int table_len)
  {
  #ifdef CONFIG_CMDLINE
cmd_tbl_t *cmdtp;
cmd_tbl_t *cmdtp_temp = table;  /* Init value */
const char *p;
int len;
int n_found = 0;

if (!cmd)
return NULL;
/*
 * Some commands allow length modifiers (like "cp.b");
 * compare command name only until first dot.
 */
len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd);

for (cmdtp = table; cmdtp != table + table_len; cmdtp++) {
if (strncmp(cmd, cmdtp->name, len) == 0) {
if (len == strlen(cmdtp->name))
return cmdtp;   /* full match */

cmdtp_temp = cmdtp; /* abbreviated command ? */
n_found++;
}
}
if (n_found == 1) { /* exactly one match */
return cmdtp_temp;
}
  #endif /* CONFIG_CMDLINE */

return NULL;/* not found or ambiguous command */
  }

so am i reading that correctly that any unique prefix for configured
commands will work? i ask only because, recently, someone made the
claim in some u-boot instructions i'm reading:

  * Use “setenv” command instead of “set” for target boards.  u-boot
source is not yet modified to alias “setenv” to “set”. Other
commands like “printenv” and “saveenv” can still be called as
“print” and “save”.

huh? why would someone have to "modify" the source to allow "set" to
be a valid abbreviation for "setenv"? (aside: these instructions mix
advice for both current and very old versions of u-boot, so maybe that
claim is only for very old versions.)

  anyway, clarifiation would be appreciated. thank you kindly.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[U-Boot] [PATCH] crypto/fsl: Update blob cmd to accept 64bit addresses

[Sumit Garg]

Update blob cmd to accept 64bit source, key modifier and destination
addresses. Also correct output result print format for fsl specific
implementation of blob cmd.

Signed-off-by: Sumit Garg 
---
 cmd/blob.c|  2 +-
 drivers/crypto/fsl/fsl_blob.c | 13 ++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/cmd/blob.c b/cmd/blob.c
index ac8b268..bdd4cfd 100644
--- a/cmd/blob.c
+++ b/cmd/blob.c
@@ -54,7 +54,7 @@ __weak int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
  */
 static int do_blob(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
 {
-   uint32_t key_addr, src_addr, dst_addr, len;
+   ulong key_addr, src_addr, dst_addr, len;
uint8_t *km_ptr, *src_ptr, *dst_ptr;
int enc, ret = 0;
 
diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
index 8b25921..d24b8fc 100644
--- a/drivers/crypto/fsl/fsl_blob.c
+++ b/drivers/crypto/fsl/fsl_blob.c
@@ -18,7 +18,7 @@ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
int ret, i = 0;
u32 *desc;
 
-   printf("\nDecapsulating data to form blob\n");
+   printf("\nDecapsulating blob to get data\n");
desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE);
if (!desc) {
debug("Not enough memory for descriptor allocation\n");
@@ -27,12 +27,15 @@ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
 
inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len);
 
+   debug("Descriptor dump:\n");
for (i = 0; i < 14; i++)
-   printf("%x\n", *(desc + i));
+   debug("Word[%d]: %08x\n", i, *(desc + i));
ret = run_descriptor_jr(desc);
 
if (ret)
printf("Error in Decapsulation %d\n", ret);
+   else
+   printf("Decapsulation Success\n");
 
free(desc);
return ret;
@@ -51,12 +54,16 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
}
 
inline_cnstr_jobdesc_blob_encap(desc, key_mod, src, dst, len);
+
+   debug("Descriptor dump:\n");
for (i = 0; i < 14; i++)
-   printf("%x\n", *(desc + i));
+   debug("Word[%d]: %08x\n", i, *(desc + i));
ret = run_descriptor_jr(desc);
 
if (ret)
printf("Error in Encapsulation %d\n", ret);
+   else
+   printf("Encapsulation Success\n");
 
free(desc);
return ret;
-- 
1.8.1.4

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

[U-Boot] [PATCH] dm: clk: Remove simple version of clk_get_by_index()

[Michal Simek]

Simple version of clk_get_by_index() added by:
"dm: clk: Add a simple version of clk_get_by_index()"
(sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44)
is not sufficient if you use multiple clocks in the system
because clk->id is phandle id which for example fixed-clock
is not able to handle. Use the same implementation as is used
in full version.

Signed-off-by: Michal Simek 
---

Diff for ZynqMP is 773 B based on buildman.
---
 drivers/clk/clk-uclass.c | 55 
 1 file changed, 18 insertions(+), 37 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 6e4d67220a16..c6c5ba2f2511 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -21,30 +21,29 @@ static inline struct clk_ops *clk_dev_ops(struct udevice 
*dev)
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
 #ifdef CONFIG_SPL_BUILD
-int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
-{
-   int ret;
-   u32 cell[2];
-
-   if (index != 0)
-   return -ENOSYS;
-   assert(clk);
-   ret = uclass_get_device(UCLASS_CLK, 0, &clk->dev);
-   if (ret)
-   return ret;
-   ret = fdtdec_get_int_array(gd->fdt_blob, dev->of_offset, "clocks",
-  cell, 2);
-   if (ret)
-   return ret;
-   clk->id = cell[1];
-   return 0;
-}
-
 int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
 {
return -ENOSYS;
 }
 #else
+int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
+{
+   int index;
+
+   debug("%s(dev=%p, name=%s, clk=%p)\n", __func__, dev, name, clk);
+
+   index = fdt_find_string(gd->fdt_blob, dev->of_offset, "clock-names",
+   name);
+   if (index < 0) {
+   debug("fdt_find_string() failed: %d\n", index);
+   return index;
+   }
+
+   return clk_get_by_index(dev, index, clk);
+}
+#endif
+#endif
+
 static int clk_of_xlate_default(struct clk *clk,
struct fdtdec_phandle_args *args)
 {
@@ -102,24 +101,6 @@ int clk_get_by_index(struct udevice *dev, int index, 
struct clk *clk)
return clk_request(dev_clk, clk);
 }
 
-int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
-{
-   int index;
-
-   debug("%s(dev=%p, name=%s, clk=%p)\n", __func__, dev, name, clk);
-
-   index = fdt_find_string(gd->fdt_blob, dev->of_offset, "clock-names",
-   name);
-   if (index < 0) {
-   debug("fdt_find_string() failed: %d\n", index);
-   return index;
-   }
-
-   return clk_get_by_index(dev, index, clk);
-}
-#endif
-#endif
-
 int clk_request(struct udevice *dev, struct clk *clk)
 {
struct clk_ops *ops = clk_dev_ops(dev);
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework

[Sumit Garg]

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Thursday, July 14, 2016 5:00 PM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: york sun ; Ruchika Gupta ;
> s...@google.com; teddy.r...@gmail.com; dannenb...@ti.com;
> tr...@konsulko.com; Sumit Garg 
> Subject: RE: [PATCH 0/3] Enable SECURE BOOT in SPL framework
> 
> Dear Sumit,
> 
> > -Original Message-
> > From: Sumit Garg [mailto:sumit.g...@nxp.com]
> > Sent: Thursday, July 14, 2016 9:58 PM
> > To: u-boot@lists.denx.de
> > Cc: york sun ; Ruchika Gupta
> > ; Prabhakar Kushwaha
> > ; s...@google.com;
> teddy.r...@gmail.com;
> > dannenb...@ti.com; tr...@konsulko.com; Sumit Garg
> 
> > Subject: [PATCH 0/3] Enable SECURE BOOT in SPL framework
> >
> 
> Patch version history is missing from patch header.
> If you get any comments then please incorporate in next patch-set.
> 
> --prabhakar 

Yes you are right, I missed it. Sure I will incorporate it in next patch set if 
I get any comments.

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

[U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework

[Sumit Garg]

The patch-set does the following:

1. Enable SECURE BOOT framework in SPL for powerpc/mpc85xx and
   arm/layerscape platform.
2. Add NAND SECURE BOOT support for powerpc/mpc85xx T104x platform.


Changes PATCH v5->PATCH v6:
Added README for SECURE BOOT support in SPL framework. Also
incorporated review comments regarding comment style. Also patch
[1] has been accepted in upstream, so no dependency.

Changes PATCH v4->PATCH v5:
Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead
of def CONFIG_DM macro to include call to dm_init_and_scan().
As dm_init_and_scan() is called as part of common SPL framework,
so no need to call it again but in case of powerpc platforms which
currently do not use common SPL framework, so need to include this
function call here.

Changes PATCH v3->PATCH v4:
Generic changes in lib, drivers, common Makefiles removed from
this patchset. Rebased this patchset on top of patch [1], so this
patchset is dependent on patch [1].

Changes PATCH v2->PATCH v3:
Patches rebased

Changes PATCH->PATCH v2:
Patches rebased

[1]https://patchwork.ozlabs.org/patch/627664/


Sumit Garg (3):
  powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL
  powerpc/mpc85xx: T104x: Add nand secure boot target
  doc: SPL: Add README for secure boot support

 arch/powerpc/cpu/mpc85xx/cpu_init.c|  4 +-
 arch/powerpc/cpu/mpc85xx/start.S   | 12 --
 arch/powerpc/cpu/mpc8xxx/fsl_pamu.c|  8 
 arch/powerpc/cpu/mpc8xxx/pamu_table.c  |  8 
 arch/powerpc/include/asm/fsl_secure_boot.h | 41 ++-
 board/freescale/common/fsl_chain_of_trust.c| 56 ++
 board/freescale/t104xrdb/t104x_pbi_sb.cfg  | 38 +
 board/freescale/t104xrdb/tlb.c | 15 ++-
 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 30 ++
 doc/SPL/README.spl-secure-boot | 18 +
 drivers/crypto/fsl/jr.c| 17 
 drivers/mtd/nand/fsl_ifc_spl.c | 24 +++
 include/configs/T104xRDB.h | 29 -
 include/fsl_validate.h |  7 
 14 files changed, 298 insertions(+), 9 deletions(-)
 create mode 100644 board/freescale/t104xrdb/t104x_pbi_sb.cfg
 create mode 100644 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig
 create mode 100644 doc/SPL/README.spl-secure-boot

-- 
1.8.1.4

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

Re: [U-Boot] How to support ATF on u-boot

[Kever Yang]

Hi Andre,

On 07/13/2016 08:45 PM, Andre Przywara wrote:

Hi,

On 13/07/16 13:27, Andreas Färber wrote:

Hi Kever,

Am 20.06.2016 um 04:59 schrieb Kever Yang:

 I want to upstream a new SoC named RK3399 from Rockchip which is
AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.

 Right now we are using a miniloader(just like SPL in U-boot) to load
ATF/U-boot,
and PC jump from miniloader to ATF and then to U-boot(with CPU change to
EL2 mode or nsEL1),
then U-boot load kernel/rootfs as usual.

 The ATF support for RK3399 has already upstream
 Could you give your opinion on how to support ATF on U-boot upstream?
When I asked Simon Glass offline, he suggest if we can build ATF as part
of the
U-boot build process, perhaps with a script in U-boot tree,

Perhaps something like:

make rk3399_board_defconfig
make
./scripts/build-atf-image rk3399_board
^^ new script

I am not sure we should trigger an ATF build on building U-Boot. In my
build process for the Pine64 I just point to the compiled binary and
leave it up to the user to take care of compiling that. ATF builds are
really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
bl31" for instance and takes only a few seconds.

I have send my patch set today, get bl31 from ATF is easy, still need some
rockchip tools to do the package and load the image.



In any case, a good README would help.

I've started looking into RK3368 for my GeekBox, which raises a similar
issue. Are you working on that as well or just RK3399?

Personally I think that the approach the HiKey has taken is the best,
i.e. decouple U-Boot from ATF and just supply a README for how to make
it work with U-Boot as ATF payload.

Interestingly ATF itself considers U-Boot a payload, as it provides its
own bootstrapping parts which take a similar role as U-Boot's SPL.
So the official ATF build process (at least for Juno) lets you specify
the location of the U-Boot binary to be included in their FIP image.

OTOH, some boards (like the Pine64) only use the runtime component of
ATF, so including it in U-Boot makes more sense (see below). I guess
this is similar for Rockchip?

Yes for now, but I think there might be a secure OS in the future.



Obviously it would help to integrate your loaderimage tool into mkimage.

FWIW, I extended SPL's FIT loading to support loading multiple images.
With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs
into one FIT image and attach that to the SPL.
I even managed to include a kernel and initrd in there, fwiw.
I will post those patches soonish.

Great, good news! Simon also want to enable the SPL support for ATF when we
discuss this issue offline, so I think we can see this feature enabled 
very soon.


Thanks,
- Kever


Cheers,
Andre.


Also, what is the difference between your trust_merger tool and ATF's
fip_create / fiptool?

Regards,
Andreas







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

[U-Boot] [PATCH 1/3] ARM64: zynqmp: Enable CLK and SPL_CLK by default

[Michal Simek]

Serial driver starts to use clk framework that's why
enable it by default.

Signed-off-by: Michal Simek 
---

 arch/arm/Kconfig | 2 ++
 configs/xilinx_zynqmp_ep_defconfig   | 2 --
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 2 --
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 2 --
 configs/xilinx_zynqmp_zcu102_defconfig   | 2 --
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 2 --
 8 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3237a74f7223..f01eadf69f5e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -669,6 +669,8 @@ config ARCH_ZYNQMP
select OF_CONTROL
select DM_SERIAL
select SUPPORT_SPL
+   select CLK
+   select SPL_CLK
 
 config TEGRA
bool "NVIDIA Tegra"
diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index fa380ef7f08f..b02ab0883543 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -42,8 +42,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 35226d6fd3c9..b11586211adb 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -33,8 +33,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index cc13179a1e5f..d1e8778dc4c8 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -33,8 +33,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_NAND_ARASAN=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
index 65703481ae31..4342e0546b0c 100644
--- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
@@ -29,8 +29,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
index e1fc8b0ee271..06c07c128a65 100644
--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
@@ -28,8 +28,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
b/configs/xilinx_zynqmp_zcu102_defconfig
index 28290296853d..140b80017295 100644
--- a/configs/xilinx_zynqmp_zcu102_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_defconfig
@@ -32,8 +32,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 92633d6fcc98..727e22c267ab 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -32,8 +32,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] serial: zynq: Read information about clock from DT

[Michal Simek]

Read information about clock frequency from DT.

Signed-off-by: Michal Simek 
---

 drivers/serial/serial_zynq.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index 66d54e32ab38..4f6e7e442fa2 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -108,8 +109,33 @@ static int _uart_zynq_serial_putc(struct uart_zynq *regs, 
const char c)
 int zynq_serial_setbrg(struct udevice *dev, int baudrate)
 {
struct zynq_uart_priv *priv = dev_get_priv(dev);
-   unsigned long clock = get_uart_clk(0);
+   unsigned long clock;
 
+#if defined(CONFIG_CLK) || defined(CONFIG_SPL_CLK)
+   int ret;
+   struct clk clk;
+
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to get clock\n");
+   return ret;
+   }
+
+   clock = clk_get_rate(&clk);
+   if (IS_ERR_VALUE(clock)) {
+   dev_err(dev, "failed to get rate\n");
+   return clock;
+   }
+   debug("%s: CLK %ld\n", __func__, clock);
+
+   ret = clk_enable(&clk);
+   if (ret && ret != -ENOSYS) {
+   dev_err(dev, "failed to enable clock\n");
+   return ret;
+   }
+#else
+   clock = get_uart_clk(0);
+#endif
_uart_zynq_serial_setbrg(priv->regs, clock, baudrate);
 
return 0;
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] ARM64: zynqmp: Remove get_uart_clk()

[Michal Simek]

ZynqMP will use reading clock freq directly from DT.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/clk.c| 16 
 arch/arm/include/asm/arch-zynqmp/clk.h |  1 -
 2 files changed, 17 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/clk.c b/arch/arm/cpu/armv8/zynqmp/clk.c
index 690c72dd6683..f7e5ebfa6343 100644
--- a/arch/arm/cpu/armv8/zynqmp/clk.c
+++ b/arch/arm/cpu/armv8/zynqmp/clk.c
@@ -12,22 +12,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-unsigned long get_uart_clk(int dev_id)
-{
-   u32 ver = zynqmp_get_silicon_version();
-
-   switch (ver) {
-   case ZYNQMP_CSU_VERSION_VELOCE:
-   return 48000;
-   case ZYNQMP_CSU_VERSION_EP108:
-   return 2500;
-   case ZYNQMP_CSU_VERSION_QEMU:
-   return 13300;
-   }
-
-   return 1;
-}
-
 unsigned long zynqmp_get_system_timer_freq(void)
 {
u32 ver = zynqmp_get_silicon_version();
diff --git a/arch/arm/include/asm/arch-zynqmp/clk.h 
b/arch/arm/include/asm/arch-zynqmp/clk.h
index b18333d1ca25..bfd53b530584 100644
--- a/arch/arm/include/asm/arch-zynqmp/clk.h
+++ b/arch/arm/include/asm/arch-zynqmp/clk.h
@@ -8,7 +8,6 @@
 #ifndef _ASM_ARCH_CLK_H_
 #define _ASM_ARCH_CLK_H_
 
-unsigned long get_uart_clk(int dev_id);
 unsigned long zynqmp_get_system_timer_freq(void);
 
 #endif /* _ASM_ARCH_CLK_H_ */
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries

[Tien Fong Chee]

fill_dir_slot use get_contents_vfatname_block as a temporary buffer for
constructing a list of dir_slot entries. To save the memory and providing
correct type of memory for above usage, a local buffer with accurate size
declaration is introduced.

The local array size 640 is used because for long file name entry,
each entry use 32 bytes, one entry can store up to 13 characters.
The maximum number of entry possible is 20. So, total size is
32*20=640bytes.

Signed-off-by: Genevieve Chan 
Signed-off-by: Tien Fong Chee 
Cc: Dinh Nguyen 
Cc: Dinh Nguyen 
Cc: ChinLiang 
Cc: Vagrant Cascadian 
Cc: Simon Glass 
Cc: Stephen Warren 
Cc: Benoît Thébaudeau 
---
 fs/fat/fat_write.c |3 ++-
 include/fat.h  |3 +++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index eb3a916..c1d48c5 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -323,7 +323,8 @@ static void flush_dir_table(fsdata *mydata, dir_entry 
**dentptr);
 static void
 fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const char *l_name)
 {
-   dir_slot *slotptr = (dir_slot *)get_contents_vfatname_block;
+   __u8 temp_dir_slot_buffer[MAX_LFN_SLOT * sizeof(dir_slot)];
+   dir_slot *slotptr = (dir_slot *)temp_dir_slot_buffer;
__u8 counter = 0, checksum;
int idx = 0, ret;
char s_name[16];
diff --git a/include/fat.h b/include/fat.h
index 9d053e6..90fdeba 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -33,6 +33,9 @@
 #define FAT16BUFSIZE   (FATBUFSIZE/2)
 #define FAT32BUFSIZE   (FATBUFSIZE/4)
 
+/* Maximum number of entry for long file name according to spec */
+#define MAX_LFN_SLOT   20
+
 
 /* Filesystem identifiers */
 #define FAT12_SIGN "FAT12   "
-- 
1.7.7.4

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

[U-Boot] [PATCH v2 0/9] mx7: add Colibri iMX7S/iMX7D support

[Stefan Agner]

From: Stefan Agner 

This patchset adds support for the Toradex i.MX 7Solo and 7Dual
based computer on modules Colibri iMX7S/iMX7D.

It also brings several smaller i.MX 7 related fixes/cleanups.

Changes since v1:
- Dropped Ricoh RN5T567 PMIC support (for now)
- Use CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG for runtime variables
- Convert USB OTG Power Pin Polarity to Kconfig
- Use gpio_request in lcd_setup

Stefan Agner (9):
  dm: imx: serial: Support DTE mode when using driver model
  usb: move CONFIG_USB_EHCI_MX7 to Kconfig
  usb: ehci-mx6: configure power polarity in usb_power_config
  usb: ehci-mx6: introduce config for high active power pin
  mx7: set soc environment according to exact SoC type
  mx7_common: Put display board info config into board file
  mx7_common: use Kconfig for ARMv7 non-secure mode
  imx_watchdog: add weak attribute to reset_cpu function
  colibri_imx7: add Colibri iMX7S/iMX7D module support

 arch/arm/cpu/armv7/mx7/Kconfig|   9 +
 arch/arm/cpu/armv7/mx7/soc.c  |  14 +
 board/toradex/colibri_imx7/Kconfig|  12 +
 board/toradex/colibri_imx7/MAINTAINERS|   6 +
 board/toradex/colibri_imx7/Makefile   |   6 +
 board/toradex/colibri_imx7/colibri_imx7.c | 420 ++
 board/toradex/colibri_imx7/imximage.cfg   | 150 +++
 configs/colibri_imx7_defconfig|  40 +++
 configs/mx7dsabresd_defconfig |   3 +
 configs/warp7_defconfig   |   4 +
 drivers/serial/serial_mxc.c   |   9 +-
 drivers/usb/host/Kconfig  |  16 ++
 drivers/usb/host/ehci-mx6.c   |  14 +-
 drivers/watchdog/imx_watchdog.c   |   2 +-
 include/configs/colibri_imx7.h| 248 ++
 include/configs/mx7_common.h  |  10 +-
 include/configs/mx7dsabresd.h |   4 +-
 include/configs/warp7.h   |   4 +-
 include/dm/platform_data/serial_mxc.h |   1 +
 19 files changed, 953 insertions(+), 19 deletions(-)
 create mode 100644 board/toradex/colibri_imx7/Kconfig
 create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
 create mode 100644 board/toradex/colibri_imx7/Makefile
 create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
 create mode 100644 board/toradex/colibri_imx7/imximage.cfg
 create mode 100644 configs/colibri_imx7_defconfig
 create mode 100644 include/configs/colibri_imx7.h

-- 
2.9.0

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

Re: [U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

I did a little more on this, and talked to someone else here. It seems that
my problem with loading the kernel including these patches is specific to
our kernel and after applying a local patch we have, it appears to load
fine.

So this patchset gets me back to the same functionality in v2016.03.

We're left with the puzzle of what's wrong on the RK3288 regarding caching
and memory.

Sandy Patterson

On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson 
wrote:

> I wasn't able to load the linux kernel using a Rock2 board
> using the latest master branch. The board hangs after it has
> handed executing over to the kernel. I found that the latest release
> that worked was v2016.03.
>
> I did some searching and I suspect the problem may be cache related.
>
> This patchset allows the kernel to start by reverting two problem
> commits and disabling EFI_LOADER which I suspect rubs the caching the
> wrong way. We also found that the 512M limit for fdt and initrd is now
> 256M.
> I'm not sure why this is.
>
> This still doesn't work 100%. I think it's not initializing the SD card
> volages correctly, but at least the Kernel is loading.
>
> I also am not sure changing the caching for all armv7 is the right
> answer. I wasn't too sure about the revert. I am not very familiar with
> this low level stuff.
>
> Sandy Patterson
>
>
> Sandy Patterson (4):
>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
> with asm code"
>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
> asm code"
>   Disable CONFIG_EFI_LOADER for rock2.
>   RK3288 needs fdt and initrd below 256M now.
>
>  arch/arm/cpu/armv7/Makefile  |   2 +-
>  arch/arm/cpu/armv7/cache_v7.c| 135 ++-
>  arch/arm/cpu/armv7/cache_v7_asm.S| 154
> ---
>  arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++-
>  configs/rock2_defconfig  |   1 +
>  include/configs/rk3288_common.h  |   6 +-
>  6 files changed, 201 insertions(+), 164 deletions(-)
>  delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
>
> --
> 1.9.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

[Tien Fong Chee]

Single 64KB get_contents_vfatname_block global variable would be used for
all FAT implementation instead of allocating additional two global variables
which are get_denfromdir_block and do_fat_read_at_block. This implementation
can help in saving up 128KB memory space.

Signed-off-by: Tien Fong Chee 
Cc: Dinh Nguyen 
Cc: Dinh Nguyen 
Cc: ChinLiang 
Cc: Vagrant Cascadian 
Cc: Simon Glass 
Cc: Stephen Warren 
Cc: Benoît Thébaudeau 
---
 fs/fat/fat.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 826bd85..5d1afe6 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const char ext[3])
  * Get the directory entry associated with 'filename' from the directory
  * starting at 'startsect'
  */
-__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
-   __aligned(ARCH_DMA_MINALIGN);
+__u8 *get_dentfromdir_block = get_contents_vfatname_block;
 
 static dir_entry *get_dentfromdir(fsdata *mydata, int startsect,
  char *filename, dir_entry *retdent,
@@ -811,8 +810,7 @@ exit:
return ret;
 }
 
-__u8 do_fat_read_at_block[MAX_CLUSTSIZE]
-   __aligned(ARCH_DMA_MINALIGN);
+__u8 *do_fat_read_at_block = get_contents_vfatname_block;
 
 int do_fat_read_at(const char *filename, loff_t pos, void *buffer,
   loff_t maxsize, int dols, int dogetsize, loff_t *size)
-- 
1.7.7.4

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

[U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries

[Tien Fong Chee]

fill_dir_slot use get_contents_vfatname_block as a temporary buffer for
constructing a list of dir_slot entries. To save the memory and providing
correct type of memory for above usage, a local buffer with accurate size
declaration is introduced.

The local array size 640 is used because for long file name entry,
each entry use 32 bytes, one entry can store up to 13 characters.
The maximum number of entry possible is 20. So, total size is
32*20=640bytes.

Signed-off-by: Genevieve Chan 
Signed-off-by: Tien Fong Chee 
Cc: Dinh Nguyen 
Cc: Dinh Nguyen 
Cc: ChinLiang 
Cc: Vagrant Cascadian 
Cc: Simon Glass 
Cc: Stephen Warren 
Cc: Benoît Thébaudeau 
---
 fs/fat/fat_write.c |3 ++-
 include/fat.h  |3 +++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index eb3a916..c1d48c5 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -323,7 +323,8 @@ static void flush_dir_table(fsdata *mydata, dir_entry 
**dentptr);
 static void
 fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const char *l_name)
 {
-   dir_slot *slotptr = (dir_slot *)get_contents_vfatname_block;
+   __u8 temp_dir_slot_buffer[MAX_LFN_SLOT * sizeof(dir_slot)];
+   dir_slot *slotptr = (dir_slot *)temp_dir_slot_buffer;
__u8 counter = 0, checksum;
int idx = 0, ret;
char s_name[16];
diff --git a/include/fat.h b/include/fat.h
index 9d053e6..90fdeba 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -33,6 +33,9 @@
 #define FAT16BUFSIZE   (FATBUFSIZE/2)
 #define FAT32BUFSIZE   (FATBUFSIZE/4)
 
+/* Maximum number of entry for long file name according to spec */
+#define MAX_LFN_SLOT   20
+
 
 /* Filesystem identifiers */
 #define FAT12_SIGN "FAT12   "
-- 
1.7.7.4

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

Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

[Tien Fong Chee]

Dear Benoît,

On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote:
> Dear Tien Fong Chee,
>
> On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote:
> > Single 64KB get_contents_vfatname_block global variable would be
> > used for
> > all FAT implementation instead of allocating additional two global
> > variables
> > which are get_denfromdir_block and do_fat_read_at_block. This
> > implementation
> > can help in saving up 128KB memory space.
> >
> > Signed-off-by: Tien Fong Chee 
> > Cc: Dinh Nguyen 
> > Cc: Dinh Nguyen 
> > Cc: ChinLiang 
> > Cc: Vagrant Cascadian 
> > Cc: Simon Glass 
> > Cc: Stephen Warren 
> > Cc: Benoît Thébaudeau 
> > ---
> >  fs/fat/fat.c |6 ++
> >  1 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> > index 826bd85..5d1afe6 100644
> > --- a/fs/fat/fat.c
> > +++ b/fs/fat/fat.c
> > @@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const
> > char ext[3])
> >   * Get the directory entry associated with 'filename' from the
> > directory
> >   * starting at 'startsect'
> >   */
> > -__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
> > -   __aligned(ARCH_DMA_MINALIGN);
> > +__u8 *get_dentfromdir_block = get_contents_vfatname_block;
> >
> >  static dir_entry *get_dentfromdir(fsdata *mydata, int startsect,
> >   char *filename, dir_entry
> > *retdent,
> > @@ -811,8 +810,7 @@ exit:
> > return ret;
> >  }
> >
> > -__u8 do_fat_read_at_block[MAX_CLUSTSIZE]
> > -   __aligned(ARCH_DMA_MINALIGN);
> > +__u8 *do_fat_read_at_block = get_contents_vfatname_block;
> >
> >  int do_fat_read_at(const char *filename, loff_t pos, void *buffer,
> >loff_t maxsize, int dols, int dogetsize, loff_t
> > *size)
>
> This probably breaks at least fat_write.c, which uses:
>   memcpy(get_dentfromdir_block, get_contents_vfatname_block,
>
> Best regards,
> Benoît

With this patch, this line code "memcpy(get_dentfromdir_block,
get_contents_vfatname_block," is not required anymore since both
 get_dentfromdir_block and get_contents_vfatname_block are sharing the
same content and memory. So, this line code can be removed or leaving
in there. However, there is only one place within fill_dir_slot_buffer
function where it can corrupt the the global memory, and it is fixed by
replacing with local buffer. This was sent out with another patch
called "[PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store
dir_slot entries". Overall, applying these two patches, a lot memory
space can be saved and fitting into small OCRAM, but need to be very
careful when modifying the code related to global memory.

Best regards,
Tien Fong
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/4] rockchip: rk3288: add fastboot support

[William.wu]

Hi Ziyuan Xu，


On 2016/7/14 14:52, Ziyuan Xu wrote:

From: Xu Ziyuan 

Enable fastboot feature on rk3288.

This path doesn't support the fastboot flash function command entirely.
We will hit "cannot find partition" assertion without specified
partition environment. Define gpt partition layout in specified board
such as firefly-rk3288, then enjoy it!

Signed-off-by: Ziyuan Xu 

---

Changes in v4:
- Add fifo size for rk3288
- Get usb_phy's dt_node

Changes in v3:
- Achieve UOC_CON_OFFSET physical address from DT

Changes in v2:
- Achieve the regs_phy from DT
- Update comments a little

  arch/arm/dts/rk3288.dtsi|  1 +
  arch/arm/mach-rockchip/board.c  | 72 +
  include/configs/rk3288_common.h | 26 +++
  3 files changed, 99 insertions(+)

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 3dab0fc..bcf051a 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -454,6 +454,7 @@
interrupts = ;
clocks = <&cru HCLK_OTG0>;
clock-names = "otg";
+   dr_mode = "otg";
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..ab41877 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -52,6 +52,78 @@ void lowlevel_init(void)
  {
  }
  
+#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)

+#include 
+#include 
+
+static struct dwc2_plat_otg_data rk3288_otg_data = {
+   .rx_fifo_sz = 512,
+   .np_tx_fifo_sz  = 16,
+   .tx_fifo_sz = 512,
+};
+
rk3288 otg port total fifo size is only 0x3cc （972，this value is in 
terms of 32-bit words），
read from  GHWCFG3 register bit[31:16], it's smaller than the total fifo 
size you configured.



+int board_usb_init(int index, enum usb_init_type init)
+{
+   int node, phy_node;
+   const char *mode;
+   bool matched = false;
+   const void *blob = gd->fdt_blob;
+   u32 grf_phy_offset;
+
+   /* find the usb_otg node */
+   node = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-usb");
+
+   while (node > 0) {
+   mode = fdt_getprop(blob, node, "dr_mode", NULL);
+   if (mode && strcmp(mode, "otg") == 0) {
+   matched = true;
+   break;
+   }
+
+   node = fdt_node_offset_by_compatible(blob, node,
+   "rockchip,rk3288-usb");
+   }
+   if (!matched) {
+   debug("Not found usb_otg device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg");
+
+   node = fdtdec_lookup_phandle(blob, node, "phys");
+   if (node <= 0) {
+   debug("Not found usb phy device\n");
+   return -ENODEV;
+   }
+
+   phy_node = fdt_parent_offset(blob, node);
+   if (phy_node <= 0) {
+   debug("Not found usb phy device\n");
+   return -ENODEV;
+   }
+
+   rk3288_otg_data.phy_of_node = phy_node;
+   grf_phy_offset = fdtdec_get_addr(blob, node, "reg");
+
+   /* find the grf node */
+   node = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-grf");
+   if (node <= 0) {
+   debug("Not found grf device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_phy = grf_phy_offset +
+   fdtdec_get_addr(blob, node, "reg");
+
+   return dwc2_udc_probe(&rk3288_otg_data);
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+   return 0;
+}
+#endif
+
  static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
  {
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 8adc26f..2040cdd 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -79,6 +79,32 @@
  #define CONFIG_SPI
  #define CONFIG_SF_DEFAULT_SPEED 2000
  
+/* usb otg */

+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_DWC2_OTG
+#define CONFIG_ROCKCHIP_USB2_PHY
+#define CONFIG_USB_GADGET_VBUS_DRAW0
+
+/* fastboot  */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV  1   /* eMMC */
+/* stroe safely fastboot buffer data to the middle of bank */
+#define CONFIG_FASTBOOT_BUF_ADDR   (CONFIG_SYS_SDRAM_BASE \
+   + SDRAM_BANK_SIZE / 2)
+#define CONFIG_FASTBOOT_BUF_SIZE   0x0800
+
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_G_DNL_MANUFACTURER  "Rockchip"
+#define CONFIG_G_DNL_VENDOR_NUM0x2207
+#defi

Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Andreas Dannenberg]

Hi Tom, Simon,

On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> This is an updated version of a patch series that introduces a generic way
> to optionally post-process blobs as they get extracted by the SPL from the
> u-boot.img FIT image, and uses this scheme to perform some authentication/
> decryption related processing on TI's high-secure (HS) SoC variants. For
> additional background please see here [1].

just wanted to send a quick ping on this patch series. My optimistic
understanding from the review and comments is that it should be in a
reasonable state right now. Please let me know if there is anything else
gating the acceptance other perhaps you wanting it to give more time for
others to chime in.

Thanks and Regards,
Andreas

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

[U-Boot] best way to submit a patch for numerous, tree-wide typoz?

[Robert P. J. Day]

  what is the best way to send in a patch for quite a number of
tree-wide (ie., unrelated) typos throughout the source? almost all of
them are innocuous -- either comments or in printed strings, so they
*shouldn't* break anything.

  these days, i have a separate "typos" git branch where i just
collect typos i run across, and keep rebasing it against "master" to
stay up to date. and since this appears to be the u-boot merge window,
i figure now is a good time to send it in. but, as i said, it's spread
all over the tree, so is a single patch even a good idea, or should i
try to break it into smaller, bite-size pieces?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Tom Rini]

On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote:
> Hi Tom, Simon,
> 
> On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> > This is an updated version of a patch series that introduces a generic way
> > to optionally post-process blobs as they get extracted by the SPL from the
> > u-boot.img FIT image, and uses this scheme to perform some authentication/
> > decryption related processing on TI's high-secure (HS) SoC variants. For
> > additional background please see here [1].
> 
> just wanted to send a quick ping on this patch series. My optimistic
> understanding from the review and comments is that it should be in a
> reasonable state right now. Please let me know if there is anything else
> gating the acceptance other perhaps you wanting it to give more time for
> others to chime in.

I'm giving people a little more time to chime in and will pick it up
soon.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Simon Glass]

Hi Andreas,

On 14 July 2016 at 07:55, Andreas Dannenberg  wrote:
> Hi Tom, Simon,
>
> On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
>> This is an updated version of a patch series that introduces a generic way
>> to optionally post-process blobs as they get extracted by the SPL from the
>> u-boot.img FIT image, and uses this scheme to perform some authentication/
>> decryption related processing on TI's high-secure (HS) SoC variants. For
>> additional background please see here [1].
>
> just wanted to send a quick ping on this patch series. My optimistic
> understanding from the review and comments is that it should be in a
> reasonable state right now. Please let me know if there is anything else
> gating the acceptance other perhaps you wanting it to give more time for
> others to chime in.

It looks fine to me. I think it should go through Tom's tree, but I'm
happy to pick it up via dm if needed.

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

Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA

[Simon Glass]

On 12 July 2016 at 19:06, Ziyuan Xu  wrote:
>
>
> On 2016年07月12日 20:59, Simon Glass wrote:
>>
>> Hi Ziyuan,
>>
>> On 6 July 2016 at 03:34, Ziyuan Xu  wrote:
>>>
>>> From: Xu Ziyuan 
>>>
>>> Invalidate dcache before starting the DMA to ensure coherency. In case
>>> there are any dirty lines from the DMA buffer in the cache, subsequent
>>> cache-line replacements may corrupt the buffer in memory while the DMA
>>> is still going on. Cache-line replacement can happen if the CPU tries to
>>> bring some other memory locations into the cache while the DMA is going
>>> on.
>>>
>>> Signed-off-by: Ziyuan Xu 
>>> ---
>>>
>>> Changes in v3:
>>> - New commit since v3 to fix the coherence issue between memory and
>>> cache
>>>
>>> Changes in v2: None
>>>
>>>   drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>>> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>>> index 12f5c85..0d6d2fb 100644
>>> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>>> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>>> @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct
>>> dwc2_request *req)
>>>
>>>  ctrl =  readl(®->out_endp[ep_num].doepctl);
>>>
>>> +   invalidate_dcache_range((unsigned long) ep->dma_buf,
>>> +   (unsigned long) ep->dma_buf + ep->len);
>>
>> There is an invalidate in complete_rx() which is one of the callers
>> for this function. It seems to me that we should not have this in two
>> places. Why do we have this problem? Is it because the other calls to
>> setdma_rx() don't invalidate?
>
>
> Yup, invoke invalidate method twice during one complete transmission:
> 1- invalidate in setdma_rx() in case of  the write back cache, present from
> cache-line replacement after DMA transmission complete.
> i.e.
> 1) dma_buf = "123456789abcd";
> 2) didn't invalidate in setdma_rx()
> 3) DMA complete interrupt coming
> 4) invalidate in complete_rx()
> 5) read dma_buf, it's "123456789abcd"
>
> If invalidate in step 2, we will achieve correct data.
> I think it's necessary to invalidate before starting DMA, and
> doc/README.arm-caches describe  details.
> 2- invalidate in complete_rx(), cpu read the dma_buf from memory directly.
>
>> I think the invalidate should happen just before reading the data. Can
>> you please check if the other invalidate is needed? Also see how it
>> cache-aligns the end address.
>
> memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE);
> cache-aligns: 64 bytes.
> dma_buffer size: 4096
>
> I had check cache-aligins and end address, rightful.
> Furthermore, everything works fine with noncached_alloc().
>

OK, thanks for the details. Can the invalidate in (4) be dropped? We
should only need one invalidate.

Reviewed-by: Simon Glass 

>>
>>> +
>>>  writel((unsigned int) ep->dma_buf,
>>> ®->out_endp[ep_num].doepdma);
>>>  writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
>>> ®->out_endp[ep_num].doeptsiz);
>>> --
>>> 1.9.1
>>>
>>>
>> Regards,
>> Simon
>>
>>
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Andreas Dannenberg]

Hi Tom,

On Thu, Jul 14, 2016 at 10:57:34AM -0400, Tom Rini wrote:
> On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote:
> > Hi Tom, Simon,
> > 
> > On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> > > This is an updated version of a patch series that introduces a generic way
> > > to optionally post-process blobs as they get extracted by the SPL from the
> > > u-boot.img FIT image, and uses this scheme to perform some authentication/
> > > decryption related processing on TI's high-secure (HS) SoC variants. For
> > > additional background please see here [1].
> > 
> > just wanted to send a quick ping on this patch series. My optimistic
> > understanding from the review and comments is that it should be in a
> > reasonable state right now. Please let me know if there is anything else
> > gating the acceptance other perhaps you wanting it to give more time for
> > others to chime in.
> 
> I'm giving people a little more time to chime in and will pick it up
> soon.  Thanks!

Understood, that's what I thought since it touches rather "global"
files. I also just re-applied the patch series to the latest 'master'
branch and it still applies cleanly and the resulting MLO/u-boot.img
images still perform as expected.

Thanks and Regards,
Andreas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA

[Ziyuan Xu]

Hi Simon,

On 2016年07月14日 23:00, Simon Glass wrote:

On 12 July 2016 at 19:06, Ziyuan Xu  wrote:


On 2016年07月12日 20:59, Simon Glass wrote:

Hi Ziyuan,

On 6 July 2016 at 03:34, Ziyuan Xu  wrote:

From: Xu Ziyuan 

Invalidate dcache before starting the DMA to ensure coherency. In case
there are any dirty lines from the DMA buffer in the cache, subsequent
cache-line replacements may corrupt the buffer in memory while the DMA
is still going on. Cache-line replacement can happen if the CPU tries to
bring some other memory locations into the cache while the DMA is going
on.

Signed-off-by: Ziyuan Xu 
---

Changes in v3:
- New commit since v3 to fix the coherence issue between memory and
cache

Changes in v2: None

   drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 12f5c85..0d6d2fb 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct
dwc2_request *req)

  ctrl =  readl(®->out_endp[ep_num].doepctl);

+   invalidate_dcache_range((unsigned long) ep->dma_buf,
+   (unsigned long) ep->dma_buf + ep->len);

There is an invalidate in complete_rx() which is one of the callers
for this function. It seems to me that we should not have this in two
places. Why do we have this problem? Is it because the other calls to
setdma_rx() don't invalidate?


Yup, invoke invalidate method twice during one complete transmission:
1- invalidate in setdma_rx() in case of  the write back cache, present from
cache-line replacement after DMA transmission complete.
i.e.
1) dma_buf = "123456789abcd";
2) didn't invalidate in setdma_rx()
3) DMA complete interrupt coming
4) invalidate in complete_rx()
5) read dma_buf, it's "123456789abcd"

If invalidate in step 2, we will achieve correct data.
I think it's necessary to invalidate before starting DMA, and
doc/README.arm-caches describe  details.
2- invalidate in complete_rx(), cpu read the dma_buf from memory directly.


I think the invalidate should happen just before reading the data. Can
you please check if the other invalidate is needed? Also see how it
cache-aligns the end address.

memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE);
cache-aligns: 64 bytes.
dma_buffer size: 4096

I had check cache-aligins and end address, rightful.
Furthermore, everything works fine with noncached_alloc().


OK, thanks for the details. Can the invalidate in (4) be dropped? We
should only need one invalidate.
We also need invalidate in after  DMA transfer completed, because in 
some processors memory contents can spontaneouslycome to the cache due 
to speculative memory access by the CPU. If this happens with the DMA 
buffer while DMA is going on we have a coherency problem.

Thanks for your review!



Reviewed-by: Simon Glass 


+
  writel((unsigned int) ep->dma_buf,
®->out_endp[ep_num].doepdma);
  writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
 ®->out_endp[ep_num].doeptsiz);
--
1.9.1



Regards,
Simon











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

Re: [U-Boot] [PATCH v2 0/4] ARM: imx: enhance support for the cm-fx6 module

[Nikita Kiryanov]

Hi Christopher, Stefano,

Whole series:
Acked-by: Nikita Kiryanov 

On Tue, Jul 12, 2016 at 11:37:33PM +0200, christopher.spinr...@rwth-aachen.de 
wrote:
> Hi,
> 
> this is v2 of the series. To address the review comments of v1, v2 has an
> addtional patch (2/4) touching include/fdt_support.h (thus, I added Simon
> to the recipients).
> 
> The original cover letter was (for a discussion cf. [2]):
> 
> this series aims at enhancing support for the cm-fx6 module. In
> particular, with respect to the upstream linux kernel.
> 
> The first patch improves the default environment. It is non-functional
> but makes it more convenient to adapt certain settings.
> 
> The later two patches add mtd partition support for the on-board spi
> flash chip. They pick up the discussion about specifying a default
> partitioning in the device tree from here [1]. In short: adding the
> default partitioning to the device tree was rejected by the linux/
> device tree community during mainlining large parts of the device tree.
> It was proposed to implement the partition/mtd handling in u-boot.
> On the other hand, it was argued that the flash chip becomes some
> kind of "black-box" since there will be no partition labeling (in
> particular, with old u-boot versions).
> 
> IMHO defining the mtd partitioning has the following (dis-)advantages:
> 
> Advantages:
> - It is easier for the user to change the partitioning (e.g. to use
>   the unsued 1MB free space).
> 
> - The flash ship is used entirely for u-boot. So it is quite natural
>   that u-boot manages it. Also, moving the partition table to it
>   allows us to change the layout in future versions of u-boot (almost
>   independently of the kernel - there are still non-device tree kernels).
> 
> - U-Boot becomes the single point of definition for all device tree
>   kernels. Otherwise, each kernel (vendor vs. upstream + version)
>   would ship its own partitioning. Moreover, u-boot has to know
>   something about the partitioning, too, because it has to know where
>   the environment is saved.
> 
> Disadvantages:
> - Users of the upstream linux kernel have to use a recent u-boot
>   version to avoid the "black box" effect. A concrete impact is
>   that the update routine (described/proposed by CompuLab) does
>   not work out of the box with older u-boot versions.
> 
> - Updating u-boot is something users might not want or miss to do.
> 
> However, I think nowadays it is ok to demand a recent u-boot in
> combination with the upstream kernel. The cm-fx6 wouldn't be
> the first board doing so. Hence, I propose these patches here.
> 
> Cheers,
> Christopher
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html
> [2] http://lists.denx.de/pipermail/u-boot/2016-June/258546.html
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/4] rockchip: rk3288: add fastboot support

[Ziyuan Xu]

Hi William,

On 2016年07月14日 19:06, William.wu wrote:

Hi Ziyuan Xu，


On 2016/7/14 14:52, Ziyuan Xu wrote:

From: Xu Ziyuan 

Enable fastboot feature on rk3288.

This path doesn't support the fastboot flash function command entirely.
We will hit "cannot find partition" assertion without specified
partition environment. Define gpt partition layout in specified board
such as firefly-rk3288, then enjoy it!

Signed-off-by: Ziyuan Xu 

---

Changes in v4:
- Add fifo size for rk3288
- Get usb_phy's dt_node

Changes in v3:
- Achieve UOC_CON_OFFSET physical address from DT

Changes in v2:
- Achieve the regs_phy from DT
- Update comments a little

  arch/arm/dts/rk3288.dtsi|  1 +
  arch/arm/mach-rockchip/board.c  | 72 
+

  include/configs/rk3288_common.h | 26 +++
  3 files changed, 99 insertions(+)

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 3dab0fc..bcf051a 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -454,6 +454,7 @@
  interrupts = ;
  clocks = <&cru HCLK_OTG0>;
  clock-names = "otg";
+dr_mode = "otg";
  phys = <&usbphy0>;
  phy-names = "usb2-phy";
  status = "disabled";
diff --git a/arch/arm/mach-rockchip/board.c 
b/arch/arm/mach-rockchip/board.c

index 816540e..ab41877 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -52,6 +52,78 @@ void lowlevel_init(void)
  {
  }
  +#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
+#include 
+#include 
+
+static struct dwc2_plat_otg_data rk3288_otg_data = {
+.rx_fifo_sz= 512,
+.np_tx_fifo_sz= 16,
+.tx_fifo_sz= 512,
+};
+
rk3288 otg port total fifo size is only 0x3cc （972，this value is in 
terms of 32-bit words），
read from  GHWCFG3 register bit[31:16], it's smaller than the total 
fifo size you configured.


I understand what you concern, but fifo size is in terms of 1 byte 
above, please take a look on v4 
2/4(http://patchwork.ozlabs.org/patch/648237/).I remove >> 2 on the 
former code. Let  me know if you still disagree with it.

Thanks!

+int board_usb_init(int index, enum usb_init_type init)
+{
+int node, phy_node;
+const char *mode;
+bool matched = false;
+const void *blob = gd->fdt_blob;
+u32 grf_phy_offset;
+
+/* find the usb_otg node */
+node = fdt_node_offset_by_compatible(blob, -1,
+"rockchip,rk3288-usb");
+
+while (node > 0) {
+mode = fdt_getprop(blob, node, "dr_mode", NULL);
+if (mode && strcmp(mode, "otg") == 0) {
+matched = true;
+break;
+}
+
+node = fdt_node_offset_by_compatible(blob, node,
+"rockchip,rk3288-usb");
+}
+if (!matched) {
+debug("Not found usb_otg device\n");
+return -ENODEV;
+}
+rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg");
+
+node = fdtdec_lookup_phandle(blob, node, "phys");
+if (node <= 0) {
+debug("Not found usb phy device\n");
+return -ENODEV;
+}
+
+phy_node = fdt_parent_offset(blob, node);
+if (phy_node <= 0) {
+debug("Not found usb phy device\n");
+return -ENODEV;
+}
+
+rk3288_otg_data.phy_of_node = phy_node;
+grf_phy_offset = fdtdec_get_addr(blob, node, "reg");
+
+/* find the grf node */
+node = fdt_node_offset_by_compatible(blob, -1,
+"rockchip,rk3288-grf");
+if (node <= 0) {
+debug("Not found grf device\n");
+return -ENODEV;
+}
+rk3288_otg_data.regs_phy = grf_phy_offset +
+fdtdec_get_addr(blob, node, "reg");
+
+return dwc2_udc_probe(&rk3288_otg_data);
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+return 0;
+}
+#endif
+
  static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc,
 char * const argv[])
  {
diff --git a/include/configs/rk3288_common.h 
b/include/configs/rk3288_common.h

index 8adc26f..2040cdd 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -79,6 +79,32 @@
  #define CONFIG_SPI
  #define CONFIG_SF_DEFAULT_SPEED 2000
  +/* usb otg */
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_DWC2_OTG
+#define CONFIG_ROCKCHIP_USB2_PHY
+#define CONFIG_USB_GADGET_VBUS_DRAW0
+
+/* fastboot  */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV1/* eMMC */
+/* stroe safely fastboot buffer data to the middle of bank */
+#define CONFIG_FASTBOOT_BUF_ADDR(CONFIG_SYS_SDRAM_BASE \
++ SDRAM_BANK_SIZE / 2)
+#define CONFIG_FASTBOOT_BUF_SIZE0x0800
+
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_G_DNL_MANUFACTURER"Rockchip"
+#define CONFIG_G_DNL_VENDOR_NUM0x2207
+#define CONFIG_G_DNL_PRODUCT_NUM0x320a
+
+/* Enable gpt partit

[U-Boot] [PATCH v4.1 3/4] rockchip: rk3288: add fastboot support

[Ziyuan Xu]

From: Xu Ziyuan 

Enable fastboot feature on rk3288.

This path doesn't support the fastboot flash function command entirely.
We will hit "cannot find partition" assertion without specified
partition environment. Define gpt partition layout in specified board
such as firefly-rk3288, then enjoy it!

Signed-off-by: Ziyuan Xu 

---

Changes in v4.1:
- Revise tx_fifo_sz to 128

Changes in v4:
- Add fifo size for rk3288
- Get usb_phy's dt_node

Changes in v3:
- Achieve UOC_CON_OFFSET physical address from DT

Changes in v2:
- Achieve the regs_phy from DT
- Update comments a little

 arch/arm/dts/rk3288.dtsi|  1 +
 arch/arm/mach-rockchip/board.c  | 72 +
 include/configs/rk3288_common.h | 26 +++
 3 files changed, 99 insertions(+)

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 3dab0fc..bcf051a 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -454,6 +454,7 @@
interrupts = ;
clocks = <&cru HCLK_OTG0>;
clock-names = "otg";
+   dr_mode = "otg";
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..1458e80 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -52,6 +52,78 @@ void lowlevel_init(void)
 {
 }
 
+#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
+#include 
+#include 
+
+static struct dwc2_plat_otg_data rk3288_otg_data = {
+   .rx_fifo_sz = 512,
+   .np_tx_fifo_sz  = 16,
+   .tx_fifo_sz = 128,
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+   int node, phy_node;
+   const char *mode;
+   bool matched = false;
+   const void *blob = gd->fdt_blob;
+   u32 grf_phy_offset;
+
+   /* find the usb_otg node */
+   node = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-usb");
+
+   while (node > 0) {
+   mode = fdt_getprop(blob, node, "dr_mode", NULL);
+   if (mode && strcmp(mode, "otg") == 0) {
+   matched = true;
+   break;
+   }
+
+   node = fdt_node_offset_by_compatible(blob, node,
+   "rockchip,rk3288-usb");
+   }
+   if (!matched) {
+   debug("Not found usb_otg device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg");
+
+   node = fdtdec_lookup_phandle(blob, node, "phys");
+   if (node <= 0) {
+   debug("Not found usb phy device\n");
+   return -ENODEV;
+   }
+
+   phy_node = fdt_parent_offset(blob, node);
+   if (phy_node <= 0) {
+   debug("Not found usb phy device\n");
+   return -ENODEV;
+   }
+
+   rk3288_otg_data.phy_of_node = phy_node;
+   grf_phy_offset = fdtdec_get_addr(blob, node, "reg");
+
+   /* find the grf node */
+   node = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-grf");
+   if (node <= 0) {
+   debug("Not found grf device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_phy = grf_phy_offset +
+   fdtdec_get_addr(blob, node, "reg");
+
+   return dwc2_udc_probe(&rk3288_otg_data);
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+   return 0;
+}
+#endif
+
 static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
 {
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 8adc26f..2040cdd 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -79,6 +79,32 @@
 #define CONFIG_SPI
 #define CONFIG_SF_DEFAULT_SPEED 2000
 
+/* usb otg */
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_DWC2_OTG
+#define CONFIG_ROCKCHIP_USB2_PHY
+#define CONFIG_USB_GADGET_VBUS_DRAW0
+
+/* fastboot  */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV  1   /* eMMC */
+/* stroe safely fastboot buffer data to the middle of bank */
+#define CONFIG_FASTBOOT_BUF_ADDR   (CONFIG_SYS_SDRAM_BASE \
+   + SDRAM_BANK_SIZE / 2)
+#define CONFIG_FASTBOOT_BUF_SIZE   0x0800
+
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_G_DNL_MANUFACTURER  "Rockchip"
+#define CONFIG_G_DNL_VENDOR_NUM0x2207
+#define CONFIG_G_DNL_PRODUCT_NUM   0x320a
+
+/* Enable gpt partition table */
+#define CONFIG_CMD_GPT
+#define CONFIG_EFI_PARTITION
+
 #ifndef CONFIG_SPL_BUILD
 #include 
 
-- 
1.9.1


___

[U-Boot] Please investigate T2080QDS U-Boot

[york sun]

Shengzhou,

Can you investigate this message on T2080QDS (see log below)? Looks like 
some issue with NAND flash. It doesn't happen on T4240QDS.

York

U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700)

CPU0:  T2080E, Version: 1.1, (0x85380011)
Core:  e6500, Version: 2.0, (0x80400120)
Clock Configuration:
CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz,
CCB:600  MHz,
DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), 
IFC:150  MHz
FMAN1: 700 MHz
QMAN:  300 MHz
PME:   600 MHz
L1:D-cache 32 KiB enabled
I-cache 32 KiB enabled
Reset Configuration Word (RCW):
: 0c070012 0e00  
0010: 6c2d0002  ec027000 c100
0020:    000307fc
0030:    0004
Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot 
from vBank4
FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26 2014
SERDES Reference Clocks:
SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz
SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz
I2C:   ready
SPI:   ready
DRAM:  Initializingusing SPD
Detected UDIMM
6 GiB left unmapped
8 GiB (DDR3, 64-bit, CL=13, ECC on)
DDR Chip-Select Interleaving Mode: CS0+CS1
Flash: 128 MiB
L2:2 MiB enabled
Corenet Platform Cache: 512 KiB enabled
Using SERDES1 Protocol: 108 (0x6c)
Using SERDES2 Protocol: 45 (0x2d)
SRIO1: enabled
SRIO2: enabled
SEC0: RNG instantiated
NAND:  fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
fsl_ifc_read_byte beyond end of buffer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: clk: Remove simple version of clk_get_by_index()

[Stephen Warren]

On 07/14/2016 05:24 AM, Michal Simek wrote:

Simple version of clk_get_by_index() added by:
"dm: clk: Add a simple version of clk_get_by_index()"
(sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44)
is not sufficient if you use multiple clocks in the system
because clk->id is phandle id which for example fixed-clock
is not able to handle. Use the same implementation as is used
in full version.


It took me a while to work out what failure case you were describing. It 
might be worth more explicitly pointing out that the existing simple 
implementation fails in any case where #clock-cells=<0>, or for larger 
#clock-cells, where the clock ID isn't in the first cell.


To be honest, I'd be inclined to always include the real 
clk_get_by_name() in SPL builds too. If it's never called, the function 
will be dropped by the linker. If it is called, the dummy implementation 
probably actively causes failures that we should avoid by using the real 
implementation. I'm not sure why the original SPL-specific code existed, 
unless the 773 byte code increase you mention is actually problematic 
for some specific build?




Signed-off-by: Michal Simek 
---

Diff for ZynqMP is 773 B based on buildman.


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

Re: [U-Boot] does u-boot automatically determine valid command abbreviations?

[Wolfgang Denk]

Dear Robert,

In message  you 
wrote:
> 
>   i just want to confirm that u-boot *automatically* determines the
> valid prefix abbreviations for u-boot commands, correct? as in, there
> is no registration or configuration to do that, it's done
> automatically based on the commands that have been configured into
> u-boot and whether a command abbreviation represents a unique prefix
> for all configured commands, yes?

Correct.

> i ask only because, recently, someone made the
> claim in some u-boot instructions i'm reading:
> 
>   * Use “setenv” command instead of “set” for target boards.  u-boot
> source is not yet modified to alias “setenv” to “set”. Other
> commands like “printenv” and “saveenv” can still be called as
> “print” and “save”.
> 
> huh? why would someone have to "modify" the source to allow "set" to
> be a valid abbreviation for "setenv"? (aside: these instructions mix
> advice for both current and very old versions of u-boot, so maybe that
> claim is only for very old versions.)

I cannot comment on the "modify" part, as it makes no sense to me.
But I can comment on the background of the story:  In the early days
of U-Boot, actually for ages, it has been more or less standard habit
to most experienced users to just write "set" instead of "setenv", as
this was sufficient to uniquely identify that command.   This was also
used in a ton of scripts.

Then, at some point, a new command (can't remember which one it was;
eventually "setdcr"?) was added, and "set" was no longer a unique
prefix, old habits and a ton of scripts broke.

So habits had to be adjusted to type "sete" instead.  So were
scripts.  The word was fine again.

You guess what happened?  Right - then the command "setexpr" was
added, and again "sete" was no longer unique.

Moral of the stroy: use "env set" ;-)

Best regards,

Wolfgang Denk

-- 
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
Work 8 hours, sleep 8 hours; but not the same 8 hours.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] does u-boot automatically determine valid command abbreviations?

[Robert P. J. Day]

On Thu, 14 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,

... snip ...

> Then, at some point, a new command (can't remember which one it was;
> eventually "setdcr"?) was added, and "set" was no longer a unique
> prefix, old habits and a ton of scripts broke.
>
> So habits had to be adjusted to type "sete" instead.  So were
> scripts.  The word was fine again.
>
> You guess what happened?  Right - then the command "setexpr" was
> added, and again "sete" was no longer unique.
>
> Moral of the stroy: use "env set" ;-)

  i'm embarrassed to admit i didn't even know the "env" command
existed. learn something new every day.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework

[Prabhakar Kushwaha]

Dear Sumit,

> -Original Message-
> From: Sumit Garg [mailto:sumit.g...@nxp.com]
> Sent: Thursday, July 14, 2016 9:58 PM
> To: u-boot@lists.denx.de
> Cc: york sun ; Ruchika Gupta ;
> Prabhakar Kushwaha ; s...@google.com;
> teddy.r...@gmail.com; dannenb...@ti.com; tr...@konsulko.com; Sumit Garg
> 
> Subject: [PATCH 0/3] Enable SECURE BOOT in SPL framework
> 

Patch version history is missing from patch header.  
If you get any comments then please incorporate in next patch-set. 

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

Re: [U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries

[Stephen Warren]

On 07/13/2016 03:01 AM, Tien Fong Chee wrote:

fill_dir_slot use get_contents_vfatname_block as a temporary buffer for
constructing a list of dir_slot entries. To save the memory and providing
correct type of memory for above usage, a local buffer with accurate size
declaration is introduced.

The local array size 640 is used because for long file name entry,
each entry use 32 bytes, one entry can store up to 13 characters.
The maximum number of entry possible is 20. So, total size is
32*20=640bytes.


I'm fairly sure this series is correct[1], although the FAT write code 
is a little hard to follow.


[1] except in the face of disk read errors or corrupted data while 
parsing long filename entries, but the code already looks broken in the 
case of disk errors, and the corrupted data case probably isn't much 
worse now.



diff --git a/include/fat.h b/include/fat.h



+/* Maximum number of entry for long file name according to spec */
+#define MAX_LFN_SLOT   20
+

  /* Filesystem identifiers */
  #define FAT12_SIGN"FAT12   "


Why 2 blank lines there?

Also, I'd suggest simply deleting get_contents_vfatname_block and 
renaming all references to it to use get_dentfromdir_block instead. That 
way, anyone reading the code in the future won't assume the two "block" 
variables refer to different memory, when in fact they share storage. 
Related, there's little point keeping the now-redundant memcpy() call at 
the end of get_long_file_name():



memcpy(get_dentfromdir_block, get_contents_vfatname_block,
mydata->clust_size * mydata->sect_size);


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

Re: [U-Boot] [PATCH] arm: start.S: Fix startup of dragonboard410c

[Tom Rini]

On Tue, Jul 12, 2016 at 11:10:28PM +0100, André Przywara wrote:
> On 12/07/16 21:15, Mateusz Kulikowski wrote:
> 
> Hi Mateusz,
> 
> > Commit d73718f3 breaks devices where:
> > - There is EL2/EL3 firmware and
> > - U-Boot starts in NS EL1 and
> > - EL2/EL3 firmware didn't unlocked write-access to CPUECTLR_EL1.
> > 
> > This patch makes that change opt-out configuration option,
> > and disables it for dragonboard410c.
> 
> thanks for bringing this up!
> You are totally right, as this register isn't architecturally defined,
> we should never set it without checking for a particular core.
> Actually even that is not enough, as it's also access restricted - even
> defaulting to RO - as you mentioned.
> 
> So I am very much for a board specific _opt-in_ solution, also as ARM
> Trusted Firmware takes care of the bit already, for instance.
> 
> Mingkai Hu, can you say for which board/SoC/family the original patch
> was needed for? Layerscape?

OK, I'm going to revert the original patch here (and would recommend
that distros that are picking up v2016.07 do the same).  Thanks all!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/8] xtensa: add support for the xtensa processor architecture [1/2]

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:01PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:41, Max Filippov  wrote:
> > From: Chris Zankel 
> >
> > The Xtensa processor architecture is a configurable, extensible,
> > and synthesizable 32-bit RISC processor core provided by Cadence.
> >
> > This is the first part of the basic architecture port with changes to
> > common files. The 'arch/xtensa' directory, and boards and additional
> > drivers will be in separate commits.
> >
> > Signed-off-by: Chris Zankel 
> > Signed-off-by: Max Filippov 
> > ---
> >  MAINTAINERS |   5 +++
> >  MAKEALL |   6 +++
> >  Makefile|  10 -
> >  cmd/bdinfo.c|  22 ++
> >  common/board_f.c|   7 ++--
> >  common/image.c  |   1 +
> >  doc/README.xtensa   | 100 
> > 
> >  examples/standalone/stubs.c |  47 +
> >  include/image.h |   1 +
> >  include/linux/stat.h|   4 +-
> >  10 files changed, 197 insertions(+), 6 deletions(-)
> >  create mode 100644 doc/README.xtensa
> 
> Reviewed-by: Simon Glass 

Thanks for the review.

[...]

> > diff --git a/MAKEALL b/MAKEALL
> > index 7e42f10..e669aa9 100755
> > --- a/MAKEALL
> > +++ b/MAKEALL
> 
> This is deprecated and will be removed soon, so you don't need to
> update it. See buildman.

Ok.

[...]

> > diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
> > index 1c4bed9..076b950 100644
> > --- a/cmd/bdinfo.c
> > +++ b/cmd/bdinfo.c
> > @@ -563,6 +563,28 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, 
> > char * const argv[])
> > return 0;
> >  }
> >
> > +#elif defined(CONFIG_XTENSA)
> > +
> > +int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> > +{
> > +   bd_t *bd = gd->bd;
> > +
> > +   print_num("boot_params",(ulong)bd->bi_boot_params);
> > +   print_num("memstart",   (ulong)bd->bi_memstart);
> > +   print_lnum("memsize",   (u64)bd->bi_memsize);
> > +   print_num("flashstart", (ulong)bd->bi_flashstart);
> > +   print_num("flashsize",  (ulong)bd->bi_flashsize);
> > +   print_num("flashoffset",(ulong)bd->bi_flashoffset);
> > +
> > +#if defined(CONFIG_CMD_NET)
> > +   print_eth(0);
> > +   printf("ip_addr = %s\n", getenv("ipaddr"));
> > +#endif
> > +   printf("baudrate= %d bps\n", gd->baudrate);
> 
> It would be great if you could put this in a common function so that
> other archs can call it. There is a lot of duplication in this file.

Ok, let me look at that.

[...]

> > diff --git a/doc/README.xtensa b/doc/README.xtensa
> > new file mode 100644
> > index 000..a461714
> > --- /dev/null
> > +++ b/doc/README.xtensa

[...]

> > +The header files for one particular processor configuration are inside
> > +a variant specific directory located in the arch/xtensa/include/asm
> 
> variant-specific

Ok.

[...]

> > +Windowed ABI presents unique difficulties with the approach based on
> > +keeping global data pointer in dedicated register. Because the register
> > +window rotates during a call, there is no register that is constantly
> > +available for the gd pointer. Therefore, a global variable is used in
> > +the same manner as i386.
> 
> Or you could make gd a simple global variable. It you keep it in the
> data section that should work.

gd is a simple global variable on xtensa, I haven't actually checked
what 'in the same manner as i386' means now. Will fix wording.

[...]

> > +U-Boot for Xtensa provides a special memory exception handler to prevent
> > +hanging. The memory exception handler simply skips over the offending
> > +instruction. It is called for all memory exception causes that might
> > +be triggered by bad user input. While this is simplistic, it's better
> > +than hanging in most cases, while keeping U-Boot small and simple.
> 
> Wouldn't it be better to print an exception message? See for example
> ARM's do_prefetch_abort().

I see that on ARM such errors result in panic and reset. Sure I can do
that if that's the preferred way of dealing with such errors.

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

Re: [U-Boot] common: cli_readline: Improve command line editing

[Tom Rini]

On Wed, Jun 08, 2016 at 01:49:46PM +0100, James Byrne wrote:

> This improves the cread_line() function so that it will correctly
> process the 'Home', 'End', 'Delete' and arrow key escape sequences
> produced by various terminal emulators. This makes command line editing
> a more pleasant experience.
> 
> The previous code only supported the cursor keys and the 'Home' key, and
> only for certain terminal emulator configurations. This adds support for
> the 'End and 'Delete' keys, and recognises a wider range of escape
> sequences. For example, the left arrow key can be 'ESC O D' instead of
> 'ESC [ D', and the 'Home' key can be 'ESC [ H', 'ESC O H', 'ESC 1 ~' or
> 'ESC 7 ~', depending on what terminal emulator you use and how it is
> configured.
> 
> Signed-off-by: James Byrne 

This introduces a new warning:
common/cli_readline.c: In function ‘cli_readline_into_buffer’:
common/cli_readline.c:361:4: warning: ‘act’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]

-- 
Tom


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

Re: [U-Boot] [PATCH 2/8] xtensa: add support for the xtensa processor architecture [2/2]

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:05PM -0600, Simon Glass wrote:

[...]

> Reviewed-by: Simon Glass 
> 
> Some comments below.
> 
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 566f044..a36ac2f 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -83,6 +83,13 @@ config X86
> > select DM_SPI
> > select DM_SPI_FLASH
> >
> > +config XTENSA
> > +   bool "Xtensa architecture"
> > +   select CREATE_ARCH_SYMLINK
> > +   select HAVE_GENERIC_BOARD
> 
> This doesn't exist anymore as the migration is complete.
>
> > +   select SUPPORT_OF_CONTROL
> > +   select SYS_GENERIC_BOARD
> 
> Same here.

Ok, will remove both.

> > diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> > new file mode 100644
> > index 000..e4e3625
> > --- /dev/null
> > +++ b/arch/xtensa/Kconfig
> > @@ -0,0 +1,26 @@
> > +menu "Xtensa architecture"
> > +   depends on XTENSA
> > +
> > +config SYS_ARCH
> > +   string
> > +   default "xtensa"
> > +
> > +config SYS_CPU
> > +   string "Xtensa Core Variant"
> > +
> > +choice
> > +   prompt "Target select"
> > +
> > +
> > +endchoice
> > +
> > +
> > +config HAVE_SYS_ASCDISP
> > +   bool
> > +
> > +config SYS_ASCDISP
> > +   bool "System LCD Display"
> > +   default y
> > +   depends on HAVE_SYS_ASCDISP
> 
> Needs a help message. Should SYS_ASCDISP go in drivers/video?

Ok, will move it there and write help message.

[...]

> > diff --git a/arch/xtensa/cpu/cpu.c b/arch/xtensa/cpu/cpu.c
> > new file mode 100644
> > index 000..fb7f810
> > --- /dev/null
> > +++ b/arch/xtensa/cpu/cpu.c
> > @@ -0,0 +1,92 @@
> > +/*
> > + * (C) Copyright 2008 - 2013 Tensilica Inc.
> > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +/*
> > + * CPU specific code
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +gd_t *gd;
> > +
> > +#if defined(CONFIG_DISPLAY_CPUINFO)
> > +/*
> > + * Print information about the CPU.
> > + */
> > +
> > +int print_cpuinfo(void)
> > +{
> > +   char buf[120], mhz[8];
> > +   uint32_t id0, id1;
> > +
> > +   asm volatile ("rsr %0, 176\n"
> > + "rsr %1, 208\n"
> > + : "=r"(id0), "=r"(id1));
> > +
> > +   sprintf(buf, "CPU:   Xtensa %s (id: %08x:%08x) at %s MHz\n",
> > +   XCHAL_CORE_ID, id0, id1, strmhz(mhz, gd->cpu_clk));
> > +   puts(buf);
> > +   return 0;
> > +}
> > +#endif
> > +
> > +/*
> > + * Implement the "reset" command.
> > + * We need support from the board, though.
> > + */
> > +
> > +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> > +{
> > +   board_reset();
> > +
> > +   /* Shouldn't come back! */
> > +   printf("** RESET FAILED **\n");
> 
> All of this can be replaced by a call to sysreset_walk_halt() I think,
> if you have a suitable UCLASS_RESET driver.

Ok, let me look at that.

> > +   return 0;
> > +}
> > +
> > +/*
> > + * We currently run always with caches enabled when running for mmemory.
> 
> Do you mean 'from memory'?

Yes, will fix.

[...]

> > diff --git a/arch/xtensa/cpu/exceptions.c b/arch/xtensa/cpu/exceptions.c
> > new file mode 100644
> > index 000..412ca5f
> > --- /dev/null
> > +++ b/arch/xtensa/cpu/exceptions.c
> > @@ -0,0 +1,64 @@
> > +/*
> > + * (C) Copyright 2008 - 2013 Tensilica Inc.
> > + * (C) Copyright 2014 Cadence Design Systems Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +/*
> > + * Exception handling.
> > + *  We currently don't handle any exception and force a reset.
> > + *  (Note that alloca is a special case and handled in start.S)
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +typedef void (*handler_t)(struct pt_regs *);
> > +
> > +void xtensa_mem_exc_dummy(struct pt_regs *);
> > +
> > +void unhandled_exception(struct pt_regs *regs)
> > +{
> > +   display_printf("!! EXCCAUSE = %2ld", regs->exccause);
> > +   printf("Unhandled Exception: EXCCAUSE = %ld (pc %lx)\n",
> > +  regs->exccause, regs->pc);
> > +   udelay(1000);   /* 10s to read display message */
> 
> Probably not needed? Up to you though.

I'd either drop it together with ASCII display, or leave them both.

[...]

> > diff --git a/arch/xtensa/cpu/start.S b/arch/xtensa/cpu/start.S
> > new file mode 100644
> > index 000..ac32efb
> > --- /dev/null
> > +++ b/arch/xtensa/cpu/start.S

[...]

> > +3: /* All code and initalized data segments have been copied. */
> > +
> > +   /* Setup PS, PS.WOE = 1, PS.EXCM = 0, PS.INTLEVEL = EXCM level. */
> > +
> > +#if __XTENSA_CALL0_ABI__
> > +   movia2, XCHAL_EXCM_LEVEL
> > +#else
> > +   movia2, (1< > +#endif
> > +   wsr a2, PS
> > +   rsync
> > +
> > +   /* Clear BSS */
> > +
> >

Re: [U-Boot] [PATCH 3/8] xtensa: add core information for the dc232b processor

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:46PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > From: Chris Zankel 
> 
> Commit message?

Ok, will add.

> >
> > Signed-off-by: Chris Zankel 
> > Signed-off-by: Max Filippov 
> > ---
> >  arch/xtensa/include/asm/arch-dc232b/core.h| 422 
> > ++
> >  arch/xtensa/include/asm/arch-dc232b/tie-asm.h | 120 
> >  arch/xtensa/include/asm/arch-dc232b/tie.h | 129 
> >  3 files changed, 671 insertions(+)
> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/core.h
> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie-asm.h
> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie.h
> 
> Reviewed-by: Simon Glass 
> 
> nits below.
> 
> >
> > diff --git a/arch/xtensa/include/asm/arch-dc232b/core.h 
> > b/arch/xtensa/include/asm/arch-dc232b/core.h
> > new file mode 100644
> > index 000..7fd1aee
> > --- /dev/null
> > +++ b/arch/xtensa/include/asm/arch-dc232b/core.h
> > @@ -0,0 +1,422 @@
> > +/*
> > + * Xtensa processor core configuration information.
> > + *
> > + * Copyright (c) 1999-2007 Tensilica Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#ifndef _XTENSA_CORE_CONFIGURATION_H
> > +#define _XTENSA_CORE_CONFIGURATION_H
> > +
> > +
> > +/
> > +   Parameters Useful for Any Code, USER or PRIVILEGED
> > + 
> > /
> > +
> > +/*
> > + *  Note:  Macros of the form XCHAL_HAVE_*** have a value of 1 if the 
> > option is
> > + *  configured, and a value of 0 otherwise.  These macros are always 
> > defined.
> > + */
> > +
> > +
> > +/*--
> > +   ISA
> > +  --*/
> > +
> > +#define XCHAL_HAVE_BE  0   /* big-endian byte ordering 
> > */
> > +#define XCHAL_HAVE_WINDOWED1   /* windowed registers 
> > option */
> > +#define XCHAL_NUM_AREGS32  /* num of physical 
> > addr regs */
> > +#define XCHAL_NUM_AREGS_LOG2   5   /* log2(XCHAL_NUM_AREGS) */
> > +#define XCHAL_MAX_INSTRUCTION_SIZE 3   /* max instr bytes (3..8) */
> > +#define XCHAL_HAVE_DEBUG   1   /* debug option */
> > +#define XCHAL_HAVE_DENSITY 1   /* 16-bit instructions */
> > +#define XCHAL_HAVE_LOOPS   1   /* zero-overhead loops */
> > +#define XCHAL_HAVE_NSA 1   /* NSA/NSAU instructions */
> > +#define XCHAL_HAVE_MINMAX  1   /* MIN/MAX instructions */
> > +#define XCHAL_HAVE_SEXT1   /* SEXT instruction 
> > */
> > +#define XCHAL_HAVE_CLAMPS  1   /* CLAMPS instruction */
> > +#define XCHAL_HAVE_MUL16   1   /* MUL16S/MUL16U 
> > instructions */
> > +#define XCHAL_HAVE_MUL32   1   /* MULL instruction */
> > +#define XCHAL_HAVE_MUL32_HIGH  0   /* MULUH/MULSH instructions 
> > */
> > +#define XCHAL_HAVE_DIV32   1   /* QUOS/QUOU/REMS/REMU 
> > instructions */
> > +#define XCHAL_HAVE_L32R1   /* L32R instruction 
> > */
> > +#define XCHAL_HAVE_ABSOLUTE_LITERALS   1   /* non-PC-rel (extended) 
> > L32R */
> > +#define XCHAL_HAVE_CONST16 0   /* CONST16 instruction */
> > +#define XCHAL_HAVE_ADDX1   /* ADDX#/SUBX# 
> > instructions */
> > +#define XCHAL_HAVE_WIDE_BRANCHES   0   /* B*.W18 or B*.W15 instr's 
> > */
> > +#define XCHAL_HAVE_PREDICTED_BRANCHES  0   /* B[EQ/EQZ/NE/NEZ]T 
> > instr's */
> > +#define XCHAL_HAVE_CALL4AND12  1   /* (obsolete option) */
> > +#define XCHAL_HAVE_ABS 1   /* ABS instruction */
> > +/*#define XCHAL_HAVE_POPC  0*/ /* POPC instruction */
> > +/*#define XCHAL_HAVE_CRC   0*/ /* CRC instruction */
> > +#define XCHAL_HAVE_RELEASE_SYNC1   /* L32AI/S32RI 
> > instructions */
> > +#define XCHAL_HAVE_S32C1I  1   /* S32C1I instruction */
> > +#define XCHAL_HAVE_SPECULATION 0   /* speculation */
> > +#define XCHAL_HAVE_FULL_RESET  1   /* all regs/state reset */
> > +#define XCHAL_NUM_CONTEXTS 1   /* */
> > +#define XCHAL_NUM_MISC_REGS2   /* num of scratch regs 
> > (0..4) */
> > +#define XCHAL_HAVE_TAP_MASTER  0   /* JTAG TAP control instr's 
> > */
> > +#define XCHAL_HAVE_PRID1   /* processor ID 
> > register */
> > +#define XCHAL_HAVE_THREADPTR   1   /* THREADPTR register */
> > +#define XCHAL_HAVE_BOOLEANS0   /* boolean registers */
> > +#define XCHAL_HAVE_CP  1   /* CPEN

Re: [U-Boot] [PATCH 4/8] xtensa: add core information for the dc233c processor

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:49PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > Signed-off-by: Max Filippov 
> > ---
> 
> Commit message?

Will add.

> >  arch/xtensa/include/asm/arch-dc233c/core.h| 475 
> > ++
> >  arch/xtensa/include/asm/arch-dc233c/tie-asm.h | 193 +++
> >  arch/xtensa/include/asm/arch-dc233c/tie.h | 150 
> >  3 files changed, 818 insertions(+)
> >  create mode 100644 arch/xtensa/include/asm/arch-dc233c/core.h
> >  create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie-asm.h
> >  create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie.h
> >
> > diff --git a/arch/xtensa/include/asm/arch-dc233c/core.h 
> > b/arch/xtensa/include/asm/arch-dc233c/core.h
> > new file mode 100644
> > index 000..3a2e53b
> > --- /dev/null
> > +++ b/arch/xtensa/include/asm/arch-dc233c/core.h
> > @@ -0,0 +1,475 @@
> > +/*
> > + * xtensa/config/core-isa.h -- HAL definitions that are dependent on Xtensa
> > + * processor CORE configuration
> > + *
> > + *  See , which includes this file, for more details.
> > + */
> > +
> > +/* Xtensa processor core configuration information.
> > +
> > +   Copyright (c) 1999-2010 Tensilica Inc.
> > +
> > +   Permission is hereby granted, free of charge, to any person obtaining
> > +   a copy of this software and associated documentation files (the
> > +   "Software"), to deal in the Software without restriction, including
> > +   without limitation the rights to use, copy, modify, merge, publish,
> > +   distribute, sublicense, and/or sell copies of the Software, and to
> > +   permit persons to whom the Software is furnished to do so, subject to
> > +   the following conditions:
> > +
> > +   The above copyright notice and this permission notice shall be included
> > +   in all copies or substantial portions of the Software.
> > +
> > +   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > +   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +   MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
> > +   IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
> > +   CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> > +   TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> > +   SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
> 
> */ on next line
> 
> Can you use SPDX for this?

Ok.

> > +
> > +#ifndef _XTENSA_CORE_CONFIGURATION_H
> > +#define _XTENSA_CORE_CONFIGURATION_H
> > +
> > +
> > +/
> > +   Parameters Useful for Any Code, USER or PRIVILEGED
> > + 
> > /
> 
> Would be better without all this * and - stuff I think.

Again: autogenerated, not really meant to be edited or even read by
humans. Is it worth it?

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

Re: [U-Boot] [PATCH 5/8] xtensa: add core information for the de212 processor

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:51PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > Signed-off-by: Max Filippov 
> > ---
> >  arch/xtensa/include/asm/arch-de212/core.h| 594 
> > +++
> >  arch/xtensa/include/asm/arch-de212/tie-asm.h | 170 
> >  arch/xtensa/include/asm/arch-de212/tie.h | 136 ++
> >  3 files changed, 900 insertions(+)
> >  create mode 100644 arch/xtensa/include/asm/arch-de212/core.h
> >  create mode 100644 arch/xtensa/include/asm/arch-de212/tie-asm.h
> >  create mode 100644 arch/xtensa/include/asm/arch-de212/tie.h
> >
> 
> Reviewed-by: Simon Glass 
> 
> Same comments as previous patch - needs commit message and could do
> without all the   stuff.

Ok.

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

[U-Boot] [PATCHv3] spi: Add support for N25Q016A

[Moritz Fischer]

This commit adds support in the spi-nor driver for the
N25Q016A, a 16Mbit SPI NOR flash from Micron.

Signed-off-by: Moritz Fischer 
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 4f37e33..0ac7971 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM,  
  0},
{"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM,  
  0},
{"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM,  
SECT_4K},
+   {"N25Q016A",   0x20bb15, 0x0,   64 * 1024,32, RD_NORM,  
SECT_4K},
{"N25Q32", 0x20ba16, 0x0,   64 * 1024,64, RD_FULL,  
   WR_QPP | SECT_4K},
{"N25Q32A",0x20bb16, 0x0,   64 * 1024,64, RD_FULL,  
   WR_QPP | SECT_4K},
{"N25Q64", 0x20ba17, 0x0,   64 * 1024,   128, RD_FULL,  
   WR_QPP | SECT_4K},
-- 
2.7.4

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

Re: [U-Boot] [PATCHv2][RESEND] spi: Add support for N25Q016A

[Moritz Fischer]

Jagan,

thanks for your review!

On Thu, Jul 14, 2016 at 12:01 AM, Jagan Teki  wrote:
> On 14 July 2016 at 00:00, Moritz Fischer  wrote:
>> Signed-off-by: Moritz Fischer 
>> ---
>>  drivers/mtd/spi/sf_params.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index 4f37e33..8ae4eea 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
>> {"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM,   
>>  0},
>> {"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM,   
>>  0},
>> {"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM,   
>>SECT_4K},
>> +   {"N25Q016A",   0x20bb15, 0x1000,64 * 1024,32, RD_NORM,   
>>SECT_4K},
>
> Why would we need this ext_id (0x1000) here? I understand this is true
> number for this part but it shouldn't require for probe or require
> somewhere else?

You're right. I just sent v3.

Cheers,

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

Re: [U-Boot] [PATCH 6/8] net/ethoc: support private memory configurations

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:54PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > From: Chris Zankel 
> >
> > The 'ethoc' device could also be configured to have a private memory
> > region instead of having access to the main memory. In that case,
> > the packets must be copied into (transmit) or out of (receive) that
> > memory.
> >
> > This behavior is configured by defining CONFIG_SYS_ETHOC_BUFFER_ADDR.
> > Make sure to have enough memory for the configured buffers
> > (one for transmit, and 'PKTBUFSRX' for receive)
> >
> > Signed-off-by: Chris Zankel 
> > Signed-off-by: Max Filippov 
> > ---
> >  drivers/net/ethoc.c | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
> > index edb3c80..ee7c01e 100644
> > --- a/drivers/net/ethoc.c
> > +++ b/drivers/net/ethoc.c
> > @@ -248,6 +248,9 @@ static int ethoc_init_ring(struct eth_device *dev)
> >  {
> > struct ethoc *priv = (struct ethoc *)dev->priv;
> > struct ethoc_bd bd;
> > +#ifdef CONFIG_SYS_ETHOC_BUFFER_ADDR
> > +   unsigned long addr = CONFIG_SYS_ETHOC_BUFFER_ADDR;
> 
> These should be in Kconfig.

Ok.

> Also you might find bouncebuf.c useful, although it allocates memory
> with malloc().

The ethoc variant that we use in XTFPGA boards can only access packets
in its dedicated packet memory and we don't have other DMA, so bouncebuf
doesn't look useful for our case.

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

Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

[Benoît Thébaudeau]

Dear Tien Fong,

On Thu, Jul 14, 2016 at 12:48 PM, Tien Fong Chee  wrote:
> Dear Benoît,
>
> On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote:
>> Dear Tien Fong Chee,
>>
>> On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote:
>> > Single 64KB get_contents_vfatname_block global variable would be
>> > used for
>> > all FAT implementation instead of allocating additional two global
>> > variables
>> > which are get_denfromdir_block and do_fat_read_at_block. This
>> > implementation
>> > can help in saving up 128KB memory space.
>> >
>> > Signed-off-by: Tien Fong Chee 
>> > Cc: Dinh Nguyen 
>> > Cc: Dinh Nguyen 
>> > Cc: ChinLiang 
>> > Cc: Vagrant Cascadian 
>> > Cc: Simon Glass 
>> > Cc: Stephen Warren 
>> > Cc: Benoît Thébaudeau 
>> > ---
>> >  fs/fat/fat.c |6 ++
>> >  1 files changed, 2 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>> > index 826bd85..5d1afe6 100644
>> > --- a/fs/fat/fat.c
>> > +++ b/fs/fat/fat.c
>> > @@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const
>> > char ext[3])
>> >   * Get the directory entry associated with 'filename' from the
>> > directory
>> >   * starting at 'startsect'
>> >   */
>> > -__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
>> > -   __aligned(ARCH_DMA_MINALIGN);
>> > +__u8 *get_dentfromdir_block = get_contents_vfatname_block;
>> >
>> >  static dir_entry *get_dentfromdir(fsdata *mydata, int startsect,
>> >   char *filename, dir_entry
>> > *retdent,
>> > @@ -811,8 +810,7 @@ exit:
>> > return ret;
>> >  }
>> >
>> > -__u8 do_fat_read_at_block[MAX_CLUSTSIZE]
>> > -   __aligned(ARCH_DMA_MINALIGN);
>> > +__u8 *do_fat_read_at_block = get_contents_vfatname_block;
>> >
>> >  int do_fat_read_at(const char *filename, loff_t pos, void *buffer,
>> >loff_t maxsize, int dols, int dogetsize, loff_t
>> > *size)
>>
>> This probably breaks at least fat_write.c, which uses:
>>   memcpy(get_dentfromdir_block, get_contents_vfatname_block,
>
> With this patch, this line code "memcpy(get_dentfromdir_block,
> get_contents_vfatname_block," is not required anymore since both
>  get_dentfromdir_block and get_contents_vfatname_block are sharing the
> same content and memory. So, this line code can be removed or leaving
> in there. However, there is only one place within fill_dir_slot_buffer
> function where it can corrupt the the global memory, and it is fixed by
> replacing with local buffer. This was sent out with another patch
> called "[PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store
> dir_slot entries". Overall, applying these two patches, a lot memory
> space can be saved and fitting into small OCRAM, but need to be very
> careful when modifying the code related to global memory.

I get the point, but I am a bit concerned because these changes make
the code even more fragile and hard to maintain than it currently is.
Perhaps it would be time to switch to FatFs as previously suggested.
Here is its memory usage:
http://elm-chan.org/fsw/ff/en/appnote.html#memory

I've not checked in detail all the possible code paths, but for
instance, if I look at get_vfatname(), it's called twice in fat.c,
once with cluster and retdent pointing to somewhere in
get_dentfromdir_block, and once with them pointing to somewhere in
do_fat_read_at_block (through other pointer variables), while
get_vfatname() may write to get_contents_vfatname_block.
get_vfatname() then uses the original data pointed to by slotptr >=
retdent. To make things worse, there is a memcpy (not memmove) from
realdent, which may point to somewhere in get_contents_vfatname_block,
to retdent. It's almost impossible for the involved buffer areas not
to overlap in that case since a whole cluster is read.

I also agree with Stephen's recommendations.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/8] net/ethoc: don't advertise gigabit on the connected PHY

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:56:57PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > Introduce MDIO communication routines. Scan MDIO bus at reset to find
> > attached PHYs and see if they support gigabit speeds. If they do check
> > their gigabit control register: if gigabit autonegotiation is enabled
> > clear it and reset the PHY.
> >
> > This allows using OpenCores 10/100 MAC with gigabit PHY connected to
> > gigabit network.
> >
> > Signed-off-by: Max Filippov 
> > ---
> >  drivers/net/ethoc.c | 76 
> > +
> >  1 file changed, 76 insertions(+)
> >
> > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
> > index ee7c01e..8f70c0c 100644
> > --- a/drivers/net/ethoc.c
> > +++ b/drivers/net/ethoc.c
> > @@ -290,6 +290,80 @@ static int ethoc_init_ring(struct eth_device *dev)
> > return 0;
> >  }
> >
> > +#ifdef CONFIG_SYS_ETHOC_SETUP_PHY
> 
> This should be in Kconfig.

Ok, will add.

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

Re: [U-Boot] [PATCH 7/8] net/ethoc: don't advertise gigabit on the connected PHY

[Max Filippov]

Hi Michal,

On Wed, Jul 13, 2016 at 08:28:44AM +0200, Michal Simek wrote:
> On 8.7.2016 17:42, Max Filippov wrote:
> > Introduce MDIO communication routines. Scan MDIO bus at reset to find
> > attached PHYs and see if they support gigabit speeds. If they do check
> > their gigabit control register: if gigabit autonegotiation is enabled
> > clear it and reset the PHY.
> > 
> > This allows using OpenCores 10/100 MAC with gigabit PHY connected to
> > gigabit network.
> > 
> > Signed-off-by: Max Filippov 
> 
> This looks kind of weird. If you have standard phy and you do it
> properly in the driver you shouldn't do it in this way.
> We have the same stuff for emaclite where IP can work only at 10/100 and
> it can be used with 1G phy. Just look at setting there.

Ok, let me look at that.

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

Re: [U-Boot] [PATCH 8/8] xtensa: add support for the 'xtfpga' evaluation board

[Max Filippov]

Hi Michal,

On Wed, Jul 13, 2016 at 08:35:37AM +0200, Michal Simek wrote:
> On 8.7.2016 17:42, Max Filippov wrote:
> > From: Chris Zankel 
> > 
> > The 'xtfpga' board is actually a set of FPGA evaluation boards that
> > can be configured to run an Xtensa processor.
> > 
> >  - Avnet Xilinx LX60
> >  - Avnet Xilinx LX110
> >  - Avnet Xilinx LX200
> >  - Xilinx ML605
> >  - Xilinx KC705
> > 
> > These boards share the same components (open-ethernet, ns16550 serial,
> > lcd display, flash, etc.).
> > 
> > Signed-off-by: Chris Zankel 
> > Signed-off-by: Max Filippov 
> > ---

[...]

> > diff --git a/board/cadence/xtfpga/Kconfig b/board/cadence/xtfpga/Kconfig
> > new file mode 100644
> > index 000..a7b65ef
> > --- /dev/null
> > +++ b/board/cadence/xtfpga/Kconfig
> > @@ -0,0 +1,43 @@
> > +if TARGET_XTFPGA
> > +
> > +choice
> > +   prompt "XTFPGA board type select"
> > +
> > +config XTFPGA_LX60
> > +   bool "Support Avnet LX60"
> > +   select HAVE_SYS_ASCDISP
> > +config XTFPGA_LX110
> > +   bool "Support Avnet LX110"
> > +   select HAVE_SYS_ASCDISP
> > +config XTFPGA_LX200
> > +   bool "Support Avnet LX200"
> > +config XTFPGA_ML605
> > +   bool "Support Xilinx ML605"
> > +   select HAVE_SYS_ASCDISP
> > +config XTFPGA_KC705
> > +   bool "Support Xilinx KC705"
> > +   select HAVE_SYS_ASCDISP
> > +
> > +endchoice
> > +
> > +config SYS_BOARD
> > +   string
> > +   default "xtfpga"
> > +
> > +config SYS_VENDOR
> > +   string
> > +   default "cadence"
> > +
> > +config SYS_CONFIG_NAME
> > +   string
> > +   default "xtfpga"
> > +V
> > +config BOARD_SDRAM_SIZE
> > +   hex
> > +   default 0x0400 if XTFPGA_LX60
> > +   default 0x0300 if XTFPGA_LX110
> > +   default 0x0600 if XTFPGA_LX200
> > +   default 0x1800 if XTFPGA_ML605
> > +   default 0x3800 if XTFPGA_KC705
> 
> You should read this directly from DTS files.
> The same you have below in config.

We have it this way so that we could calculate the location of monitor
below the top of available RAM at compile time and use it in the linker
script. Thus we avoid doing generic relocations at startup and just copy
monitor to the address it was linked for.

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

Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

[Fabio Estevam]

On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
 wrote:
> Recently I started to notice that u-boot.img built for Wandboard
> by some toolchains becomes so large that it basically overlaps with
> U-Boot environment area on SD-card.
>
> According to
> http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
> Wandboard's SD-card layout is as follows:
> -->8---
> ==
> 1. 0x   Reserved For MBR
> 2. 0x0200   512 Secondary Image Table (optional)
> 3. 0x0400   1024uBoot Image (Starting From IVT)
> 4. 0x0006   393216  start of uboot env (size:8k)
> 5. 0x00062000   end of uboot env
> 6. 0x0010   1048576 Linux kernel start
> 7. 0x0076AC00   280 start of partition 1
> -->8---
>
> So for U-Boot we have 383kB (392192 bytes).
>
> But in up to date U-Boot for Wandboard we build separately
>  a) SPL
>  b) u-boot.img
>
> which gives us a bit more detailed SD-card layout:
> -->8---
> ==
> 1. 0x   Reserved For MBR
> 2. 0x0200   512 Secondary Image Table (optional)
> 3. 0x0400   1024SPL
> 4. 0x00011400   70656   u-boot.img
> 5. 0x0006   393216  start of uboot env (size:8k)
> 6. 0x00062000   end of uboot env
> ...
> -->8---
>
> From that layout we may calculate amount of space reserved for
> u-boot.img. It's just 315kb (322560 bytes).
>
> Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
> u-boot.img is already more than we expected
> (323840 bytes instead of "< 322560"):
> -->8---
> ls -la u-boot.img
> -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
> -->8---
>
> Funny enough if I rebuild U-Boot with ARM toolchain available in
> my Fedora 23 distro u-boot.img becomes a little bit smaller:
> -->8---
> ls -la u-boot.img
> -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
> -->8---
>
> What's worse this problem might not affect people most of the time
> because what happens people would just copy u-boot.img on SD-card and
> live in happiness with it... well until somebody attempts to save
> environment in U-Boot with "saveenv" command which will simply
> overwrite the very end of u-boot.img.
> That will lead to unusable SD-card until user dd u-boot.img on
> SD-card again.
>
> I may foresee this issue in the future to become more visible once we
> add more features in U-Boot for Wandboard or just existing code base
> becomes bulkier and people will consistently get larger u-boot.img
> files produced.
>
> IMHO there's an obvious solution for all that - just move U-Boot's env
> to the very end of the gap between U-Boot and the first real partition
> on the SD-card. This patch will follow
> 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
> So env is still not in the very end of the gap (obviously 256kb is way
> too much for U-Boot's env) but at least we have now the same
> partitioning for i.MX6 boards.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Peter Robinson 
> Cc: Tom Rini 
> Cc: Peter Korsgaard 
> Cc: Wolfgang Denk 

Acked-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] xtensa: add support for the 'xtfpga' evaluation board

[Max Filippov]

Hi Simon,

On Tue, Jul 12, 2016 at 03:57:00PM -0600, Simon Glass wrote:
> On 8 July 2016 at 09:42, Max Filippov  wrote:
> > From: Chris Zankel 
> >
> > The 'xtfpga' board is actually a set of FPGA evaluation boards that
> > can be configured to run an Xtensa processor.
> >
> >  - Avnet Xilinx LX60
> >  - Avnet Xilinx LX110
> >  - Avnet Xilinx LX200
> >  - Xilinx ML605
> >  - Xilinx KC705
> >
> > These boards share the same components (open-ethernet, ns16550 serial,
> > lcd display, flash, etc.).
> >
> > Signed-off-by: Chris Zankel 
> > Signed-off-by: Max Filippov 
> > ---

[...]

> >  board/cadence/xtfpga/lcd.c |  88 ++
> 
> This should be in drivers/video and use driver model (UCLASS_VIDEO).

Ok, will move.

> > diff --git a/board/cadence/xtfpga/xtfpga.c b/board/cadence/xtfpga/xtfpga.c
> > new file mode 100644
> > index 000..35de2f3
> > --- /dev/null
> > +++ b/board/cadence/xtfpga/xtfpga.c
> > @@ -0,0 +1,173 @@
> > +/*
> > + * (C) Copyright 2007 - 2013 Tensilica Inc.
> > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "lcd.h"
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +/*
> > + * Check board idendity.
> > + * (Print information about the board to stdout.)
> > + */
> > +
> > +
> > +#if defined(CONFIG_XTFPGA_LX60)
> > +const char *board = "XT_AV60";
> > +const char *description = "Avnet Xilinx LX60 FPGA Evaluation Board / ";
> > +#elif defined(CONFIG_XTFPGA_LX110)
> > +const char *board = "XT_AV110";
> > +const char *description = "Avnet Xilinx Virtex-5 LX110 Evaluation Kit / ";
> > +#elif defined(CONFIG_XTFPGA_LX200)
> > +const char *board = "XT_AV200";
> > +const char *description = "Avnet Xilinx Virtex-4 LX200 Evaluation Kit / ";
> > +#elif defined(CONFIG_XTFPGA_ML605)
> > +const char *board = "XT_ML605";
> > +const char *description = "Xilinx Virtex-6 FPGA ML605 Evaluation Kit / ";
> > +#elif defined(CONFIG_XTFPGA_KC705)
> > +const char *board = "XT_KC705";
> > +const char *description = "Xilinx Kintex-7 FPGA KC705 Evaluation Kit / ";
> > +#else
> > +const char *board = "";
> > +const char *description = "";
> > +#endif
> 
> Shouldn't this go in the device tree? See show_board_info().

It can, but we don't have OF_CONTROL enabled in the default XTFPGA
configuration. One reason is that otherwise it wouldn't fit into the LX60
board.

> > +
> > +int checkboard(void)
> > +{
> > +   printf("Board: %s: %sTensilica bitstream\n", board, description);
> > +   return 0;
> > +}
> > +
> > +void dram_init_banksize(void)
> > +{
> > +   gd->bd->bi_memstart = PHYSADDR(CONFIG_SYS_SDRAM_BASE);
> > +   gd->bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
> > +}
> > +
> > +int board_postclk_init(void)
> > +{
> > +   /*
> > +* Obtain CPU clock frequency from board and cache in global
> > +* data structure (Hz). Return 0 on success (OK to continue),
> > +* else non-zero (hang).
> > +*/
> > +
> > +#ifdef CONFIG_SYS_FPGAREG_FREQ
> > +   gd->cpu_clk = (*(volatile unsigned long *)CONFIG_SYS_FPGAREG_FREQ);
> > +#else
> > +   /* early Tensilica bitstreams lack this reg, but most run at 50 MHz 
> > */
> > +   gd->cpu_clk = 5000UL;
> > +#endif
> > +   return 0;
> > +}
> > +
> > +/*
> > + * Miscellaneous early initializations.
> > + * We use this hook to initialize the LCD display.
> > + */
> > +
> > +int misc_init_f(void)
> > +{
> > +#ifdef CONFIG_SYS_ASCDISP
> > +   /* Initialize the LCD. */
> > +
> > +   lcd_init();
> > +#endif
> > +   display_printf("U-Boot starting", NULL);
> 
> Should use driver-model.

Ok.

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

Re: [U-Boot] [PATCH 2/8] xtensa: add support for the xtensa processor architecture [2/2]

[Simon Glass]

Hi Max,

On 14 July 2016 at 16:58, Max Filippov  wrote:
> Hi Simon,
>
> On Tue, Jul 12, 2016 at 03:56:05PM -0600, Simon Glass wrote:
>
> [...]
>
>> Reviewed-by: Simon Glass 
>>
>> Some comments below.
>>


>
>> > diff --git a/arch/xtensa/cpu/start.S b/arch/xtensa/cpu/start.S
>> > new file mode 100644
>> > index 000..ac32efb
>> > --- /dev/null
>> > +++ b/arch/xtensa/cpu/start.S
>
> [...]
>
>> > +3: /* All code and initalized data segments have been copied. */
>> > +
>> > +   /* Setup PS, PS.WOE = 1, PS.EXCM = 0, PS.INTLEVEL = EXCM level. */
>> > +
>> > +#if __XTENSA_CALL0_ABI__
>> > +   movia2, XCHAL_EXCM_LEVEL
>> > +#else
>> > +   movia2, (1<> > +#endif
>> > +   wsr a2, PS
>> > +   rsync
>> > +
>> > +   /* Clear BSS */
>> > +
>> > +   movia2, _bss_start
>> > +   movia3, _bss_end
>>
>> Can you please use board_init_f_init_reserve(), etc.? You can copy how
>> ARM does things perhaps. This should not be in assembly.
>
> We use them, one screen below.
> What exactly should not be in assembly? BSS zeroing?

Yes.

I misunderstood this sorry, but the idea is to have a little as
possible in assembler. Perhaps you are already doing that, but if you
can avoid clearing BSS here that would be better.

>
>> > +
>> > +   __loopt a2, a3, a4, 2
>> > +   s32ia0, a2, 0
>> > +   __endla a2, a3, 4
>> > +
>> > +   /* Writeback */
>> > +
>> > +   ___flush_dcache_all a2, a3
>> > +
>> > +#ifdef __XTENSA_WINDOWED_ABI__
>> > +   /*
>> > +* In windowed ABI caller and call target need to be within the 
>> > same
>> > +* gigabyte. Put the rest of the code into the text segment and 
>> > jump
>> > +* there.
>> > +*/
>> > +
>> > +   movia4, .Lboard_init_code
>> > +   jx  a4
>> > +
>> > +   .text
>> > +   .align  4
>> > +.Lboard_init_code:
>> > +#endif
>> > +
>> > +   movia0, 0
>> > +   movisp, (CONFIG_SYS_TEXT_ADDR - 16) & 0xfff0
>> > +
>> > +#ifdef CONFIG_DEBUG_UART
>> > +   movia4, debug_uart_init
>> > +#ifdef __XTENSA_CALL0_ABI__
>> > +   callx0  a4
>> > +#else
>> > +   callx4  a4
>> > +#endif
>> > +#endif
>> > +
>> > +   movia4, board_init_f_alloc_reserve
>> > +
>> > +#ifdef __XTENSA_CALL0_ABI__
>> > +   mov a2, sp
>> > +   callx0  a4
>> > +   mov sp, a2
>> > +#else
>> > +   mov a6, sp
>> > +   callx4  a4
>> > +   movsp   sp, a6
>> > +#endif
>> > +
>> > +   movia4, board_init_f_init_reserve
>> > +
>> > +#ifdef __XTENSA_CALL0_ABI__
>> > +   callx0  a4
>> > +#else
>> > +   callx4  a4
>> > +#endif
>> > +
>> > +/*
>> > +* Call board initialization routine (never returns).
>> > +*/
>> > +
>> > +   movia4, board_init_f
>>
>> As above. This is using the old approach.
>
> I see the same sequence in the ARM's _main in arch/arm/lib/crt0.S:
>
> mov r0, sp
> bl  board_init_f_alloc_reserve
> mov sp, r0
> /* set up gd here, outside any C code */
> mov r9, r0
> bl  board_init_f_init_reserve
>
> mov r0, #0
> bl  board_init_f
>
> What is 'the new approach' and how does it differ from the old?

The old approach was to have it all in assembler.

>
> [...]
>
>> > +   /* Does not return here. */
>>
>> nit: drop periods before */
>
> Ok.
>
> [...]
>
>> > +fast_alloca_exception: /* must be at _WindowUnderflow4 + 16
>>
>> */ ?
>
> Oops, right.
>
> [...]
>
>> > diff --git a/arch/xtensa/cpu/u-boot.lds b/arch/xtensa/cpu/u-boot.lds
>> > new file mode 100644
>> > index 000..853ae5a
>> > --- /dev/null
>> > +++ b/arch/xtensa/cpu/u-boot.lds
>> > @@ -0,0 +1,116 @@
>> > +/*
>> > + * (C) Copyright 2008 - 2013 Tensilica, Inc.
>> > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc.
>> > + *
>> > + * SPDX-License-Identifier:GPL-2.0+
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +OUTPUT_ARCH(xtensa)
>> > +ENTRY(_start)
>> > +
>> > +/*
>> > + * U-Boot resets from SYSROM and unpacks itself from a ROM store to RAM.
>> > + * The reset vector is usually near the base of SYSROM and has room
>> > + * above it for the ROM store into which the rest of U-Boot is packed.
>> > + * The ROM store also needs to be above any other vectors that are in ROM.
>> > + * If a core has its vectors near the top of ROM, this must be edited.
>> > + *
>> > + * Note that to run C code out of ROM, the processor would have to support
>> > + * 'relocatable' exception vectors and provide a scratch memory for the
>> > + * initial stack. Not all Xtensa processor configurations support that, so
>> > + * we can simplify the boot process and unpack U-Boot to RAM immediately.
>> > + * This, however, requires that memory have been initialized throug some
>> > + * other means (serial ROM, for example) or are initialized early 
>> > (requiring
>> > + * an assembler function.

Re: [U-Boot] [PATCH 3/8] xtensa: add core information for the dc232b processor

[Simon Glass]

Hi Max,

On 14 July 2016 at 17:15, Max Filippov  wrote:
> Hi Simon,
>
> On Tue, Jul 12, 2016 at 03:56:46PM -0600, Simon Glass wrote:
>> On 8 July 2016 at 09:42, Max Filippov  wrote:
>> > From: Chris Zankel 
>>
>> Commit message?
>
> Ok, will add.
>
>> >
>> > Signed-off-by: Chris Zankel 
>> > Signed-off-by: Max Filippov 
>> > ---
>> >  arch/xtensa/include/asm/arch-dc232b/core.h| 422 
>> > ++
>> >  arch/xtensa/include/asm/arch-dc232b/tie-asm.h | 120 
>> >  arch/xtensa/include/asm/arch-dc232b/tie.h | 129 
>> >  3 files changed, 671 insertions(+)
>> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/core.h
>> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie-asm.h
>> >  create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie.h
>>
>> Reviewed-by: Simon Glass 
>>
>> nits below.
>>

>> > +/*--
>>
>> Do we need all these lines and stars?
>
> These files are autogenerated, so I tried to avoid editing them.
> Sure I can remove these lines and start if absolutely necessary.

If it is auto-generated, can you add a comment to that effect
(including the tool that generated), or better yet, update the tool to
emit that comment? Do you expect it to be regenerated later, or will
edits be done as normal patches? Is there a source file and tool that
you could submit instead, so that the build system creates the
auto-generated source?

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

Re: [U-Boot] [PATCH 6/8] net/ethoc: support private memory configurations

[Simon Glass]

Hi Max,

On 14 July 2016 at 17:34, Max Filippov  wrote:
> Hi Simon,
>
> On Tue, Jul 12, 2016 at 03:56:54PM -0600, Simon Glass wrote:
>> On 8 July 2016 at 09:42, Max Filippov  wrote:
>> > From: Chris Zankel 
>> >
>> > The 'ethoc' device could also be configured to have a private memory
>> > region instead of having access to the main memory. In that case,
>> > the packets must be copied into (transmit) or out of (receive) that
>> > memory.
>> >
>> > This behavior is configured by defining CONFIG_SYS_ETHOC_BUFFER_ADDR.
>> > Make sure to have enough memory for the configured buffers
>> > (one for transmit, and 'PKTBUFSRX' for receive)
>> >
>> > Signed-off-by: Chris Zankel 
>> > Signed-off-by: Max Filippov 
>> > ---
>> >  drivers/net/ethoc.c | 21 +
>> >  1 file changed, 21 insertions(+)
>> >
>> > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
>> > index edb3c80..ee7c01e 100644
>> > --- a/drivers/net/ethoc.c
>> > +++ b/drivers/net/ethoc.c
>> > @@ -248,6 +248,9 @@ static int ethoc_init_ring(struct eth_device *dev)
>> >  {
>> > struct ethoc *priv = (struct ethoc *)dev->priv;
>> > struct ethoc_bd bd;
>> > +#ifdef CONFIG_SYS_ETHOC_BUFFER_ADDR
>> > +   unsigned long addr = CONFIG_SYS_ETHOC_BUFFER_ADDR;
>>
>> These should be in Kconfig.
>
> Ok.
>
>> Also you might find bouncebuf.c useful, although it allocates memory
>> with malloc().
>
> The ethoc variant that we use in XTFPGA boards can only access packets
> in its dedicated packet memory and we don't have other DMA, so bouncebuf
> doesn't look useful for our case.

OK.

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

Re: [U-Boot] [PATCH] dm: mmc: Add the function for getting current device number

[Jaehoon Chung]

On 07/13/2016 06:57 AM, Simon Glass wrote:
> Hi Jaehoon,
> 
> On 4 July 2016 at 01:40, Jaehoon Chung  wrote:
>> get_mmc_num can be returned 0. Then if you use the "mmcinfo" command, it
>> can't print the mmc information.
>> If get_mmc_num is 0, it means that there is not mmc device.
>> So it added the get_mmc_curr_num() function for getting current device
>> number(index). And get_mmc_num() is returned the number of device.
>>
>> This patch is only tested with mmc block..so i didn't touch the
>> blk-uclass.c.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/mmc-uclass.c | 12 +++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
> 
> Can you please add a function comment for get_mmc_num() in the header
> file? It's not really clear what is supposed to return.
> 
> Also there are two implementations - one in the uclass and one in
> mmc_legacy.c. If the latter does not need changing, can you please add
> a comment in your commit as to why?

Ok, I will add the explanation in more detail.

> 
> Can you repeat this problem with sandbox?

I will check this problem with sandbox. After that, i will share..

> 
>> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
>> index 38ced41..a3f2463 100644
>> --- a/drivers/mmc/mmc-uclass.c
>> +++ b/drivers/mmc/mmc-uclass.c
>> @@ -111,6 +111,16 @@ struct mmc *find_mmc_device(int dev_num)
>>
>>  int get_mmc_num(void)
>>  {
>> +   int devnum = blk_find_max_devnum(IF_TYPE_MMC);
>> +
>> +   if (devnum < 0)
>> +   return devnum;
>> +
>> +   return devnum + 1;
>> +}
>> +
>> +static int get_mmc_curr_num(void)
>> +{
>> return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
>>  }
>>
>> @@ -118,7 +128,7 @@ int mmc_get_next_devnum(void)
>>  {
>> int ret;
>>
>> -   ret = get_mmc_num();
>> +   ret = get_mmc_curr_num();
>> if (ret < 0)
>> return ret;
> 
> But get_mmc_curr_num() cannot return < 0

You're right. It's my mistake.

Best Regards,
Jaehoon Chung

> 
>>
>> --
>> 1.9.1
>>
> 
> Regards,
> Simon
> 
> 
> 

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

Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial

[Kever Yang]

Hi Andreas,

On 07/14/2016 12:26 PM, Andreas Färber wrote:

Am 14.07.2016 um 05:51 schrieb Kever Yang:

Add support for rockchip rk33 series Soc like rk3368 and rk3399

Signed-off-by: Kever Yang 
---

  tools/rkcommon.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 72621fd..9ec7eb2 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -56,6 +56,7 @@ struct spl_info {
  static struct spl_info spl_infos[] = {
{ "rk3036", "RK30", 0x1000 },
{ "rk3288", "RK32", 0x8000 },
+   { "rk33xx", "RK33", 0x2 },

Is xx really future-safe or would it be better to have two lines with
the exact model names as before?
Two information here, one is TAG 'RK33' which used by bootrom, they are 
the same
for rk33 series SoC; another is SPL size which is depend on IRAM size, 
this is

different for different SoC, rk3368 is smaller than rk3399.

I will use rk3399 first, but we may need to optimize the size limit 
later for the tool,
because the image in Rockchip IDB format could be two parts, one like 
SPL should
be run in IRAM, and another one like U-boot can be run in DRAM, the tool 
only

consider the SPL part now.

Thanks,
- Kever


Cheers,
Andreas


  };
  
  static unsigned char rc4_key[16] = {







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

Re: [U-Boot] Please investigate T2080QDS U-Boot

[Prabhakar Kushwaha]

Hi York,

I am just curious about this issue. 

Was it coming earlier on this board or started coming now.
I guess you can still access NAND flash on the board. 


Regards,
Prabhakar

> -Original Message-
> From: york sun
> Sent: Thursday, July 14, 2016 10:33 PM
> To: Shengzhou Liu 
> Cc: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Please investigate T2080QDS U-Boot
> 
> Shengzhou,
> 
> Can you investigate this message on T2080QDS (see log below)? Looks like
> some issue with NAND flash. It doesn't happen on T4240QDS.
> 
> York
> 
> U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700)
> 
> CPU0:  T2080E, Version: 1.1, (0x85380011)
> Core:  e6500, Version: 2.0, (0x80400120)
> Clock Configuration:
> CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz,
> CCB:600  MHz,
> DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous),
> IFC:150  MHz
> FMAN1: 700 MHz
> QMAN:  300 MHz
> PME:   600 MHz
> L1:D-cache 32 KiB enabled
> I-cache 32 KiB enabled
> Reset Configuration Word (RCW):
> : 0c070012 0e00  
> 0010: 6c2d0002  ec027000 c100
> 0020:    000307fc
> 0030:    0004
> Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot
> from vBank4
> FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26
> 2014
> SERDES Reference Clocks:
> SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz
> SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz
> I2C:   ready
> SPI:   ready
> DRAM:  Initializingusing SPD
> Detected UDIMM
> 6 GiB left unmapped
> 8 GiB (DDR3, 64-bit, CL=13, ECC on)
> DDR Chip-Select Interleaving Mode: CS0+CS1
> Flash: 128 MiB
> L2:2 MiB enabled
> Corenet Platform Cache: 512 KiB enabled
> Using SERDES1 Protocol: 108 (0x6c)
> Using SERDES2 Protocol: 45 (0x2d)
> SRIO1: enabled
> SRIO2: enabled
> SEC0: RNG instantiated
> NAND:  fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please investigate T2080QDS U-Boot

[york sun]

I went back to last several releases and saw the same. Do we have it in SDK 
U-Boot?

York


 Original Message 
From: Prabhakar Kushwaha 
Sent: Thursday, July 14, 2016 06:40 PM
To: york sun ,Shengzhou Liu 
Subject: RE: Please investigate T2080QDS U-Boot
CC: u-boot@lists.denx.de


Hi York,

I am just curious about this issue.

Was it coming earlier on this board or started coming now.
I guess you can still access NAND flash on the board.


Regards,
Prabhakar

> -Original Message-
> From: york sun
> Sent: Thursday, July 14, 2016 10:33 PM
> To: Shengzhou Liu 
> Cc: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Please investigate T2080QDS U-Boot
>
> Shengzhou,
>
> Can you investigate this message on T2080QDS (see log below)? Looks like
> some issue with NAND flash. It doesn't happen on T4240QDS.
>
> York
>
> U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700)
>
> CPU0:  T2080E, Version: 1.1, (0x85380011)
> Core:  e6500, Version: 2.0, (0x80400120)
> Clock Configuration:
> CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz,
> CCB:600  MHz,
> DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous),
> IFC:150  MHz
> FMAN1: 700 MHz
> QMAN:  300 MHz
> PME:   600 MHz
> L1:D-cache 32 KiB enabled
> I-cache 32 KiB enabled
> Reset Configuration Word (RCW):
> : 0c070012 0e00  
> 0010: 6c2d0002  ec027000 c100
> 0020:    000307fc
> 0030:    0004
> Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot
> from vBank4
> FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26
> 2014
> SERDES Reference Clocks:
> SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz
> SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz
> I2C:   ready
> SPI:   ready
> DRAM:  Initializingusing SPD
> Detected UDIMM
> 6 GiB left unmapped
> 8 GiB (DDR3, 64-bit, CL=13, ECC on)
> DDR Chip-Select Interleaving Mode: CS0+CS1
> Flash: 128 MiB
> L2:2 MiB enabled
> Corenet Platform Cache: 512 KiB enabled
> Using SERDES1 Protocol: 108 (0x6c)
> Using SERDES2 Protocol: 45 (0x2d)
> SRIO1: enabled
> SRIO2: enabled
> SEC0: RNG instantiated
> NAND:  fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
> fsl_ifc_read_byte beyond end of buffer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Simon Glass]

HI Sandy,

On 13 July 2016 at 11:51, Sandy Patterson  wrote:
> I did a little more on this, and talked to someone else here. It seems that
> my problem with loading the kernel including these patches is specific to
> our kernel and after applying a local patch we have, it appears to load
> fine.
>
> So this patchset gets me back to the same functionality in v2016.03.
>
> We're left with the puzzle of what's wrong on the RK3288 regarding caching
> and memory.

So what is the status of this patch set? Should it be withdrawn?

Regards,
Simon

>
> Sandy Patterson
>
> On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson 
> wrote:
>>
>> I wasn't able to load the linux kernel using a Rock2 board
>> using the latest master branch. The board hangs after it has
>> handed executing over to the kernel. I found that the latest release
>> that worked was v2016.03.
>>
>> I did some searching and I suspect the problem may be cache related.
>>
>> This patchset allows the kernel to start by reverting two problem
>> commits and disabling EFI_LOADER which I suspect rubs the caching the
>> wrong way. We also found that the 512M limit for fdt and initrd is now
>> 256M.
>> I'm not sure why this is.
>>
>> This still doesn't work 100%. I think it's not initializing the SD card
>> volages correctly, but at least the Kernel is loading.
>>
>> I also am not sure changing the caching for all armv7 is the right
>> answer. I wasn't too sure about the revert. I am not very familiar with
>> this low level stuff.
>>
>> Sandy Patterson
>>
>>
>> Sandy Patterson (4):
>>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
>> with asm code"
>>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
>> asm code"
>>   Disable CONFIG_EFI_LOADER for rock2.
>>   RK3288 needs fdt and initrd below 256M now.
>>
>>  arch/arm/cpu/armv7/Makefile  |   2 +-
>>  arch/arm/cpu/armv7/cache_v7.c| 135
>> ++-
>>  arch/arm/cpu/armv7/cache_v7_asm.S| 154
>> ---
>>  arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++-
>>  configs/rock2_defconfig  |   1 +
>>  include/configs/rk3288_common.h  |   6 +-
>>  6 files changed, 201 insertions(+), 164 deletions(-)
>>  delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
>>
>> --
>> 1.9.1
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/7] net: dm: Ignore unknown env_op_* constants

[Simon Glass]

Hi Bernhard,

On 11 July 2016 at 12:14, Bernhard Nortmann  wrote:
> This prevents a possible compiler warning similar to
> "net/eth-uclass.c::: warning: enumeration value
> 'env_op_*' not handled in switch [-Wswitch]".
>
> Signed-off-by: Bernhard Nortmann 
> ---
>
>  net/eth-uclass.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass 

> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index c15cc4d..e38edd7 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -230,6 +230,8 @@ static int on_ethaddr(const char *name, const char 
> *value, enum env_op op,
> break;
> case env_op_delete:
> memset(pdata->enetaddr, 0, 6);
> +   default:
> +   break; /* ignore */

Presumably hitting the default would be an internal error. So in that
case there is no point in returning an error, I think, and what you
have is best.

> }
> }
>
> --
> 2.7.3
>

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

Re: [U-Boot] [PATCH] armv8: spl: Call board_init_r from crt0_64 in SPL

[Simon Glass]

Hi Jeremy,

On 11 July 2016 at 16:55, Jeremy Hunt  wrote:
> As part of the startup process for boards using the SPL, the
> meaning of board_init_f changed such that it should return normally
> rather than calling board_init_r directly.
> (see db910353a126d84fe8dff7a694ea792f50fcfb6a)
> This was fixed in 32-bit arm, but broke when SPL was added to
> 64 bit arm. This fixes crt0_64 so that it calls board_init_r
> durring the SPL and removes the direct call from board_init_f
> from the arm SPL example.
>
> Signed-off-by: Jeremy Hunt 
>
> ---
>
>  arch/arm/lib/crt0_64.S |  3 +--
>  arch/arm/lib/spl.c | 18 +-
>  2 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
> index cad22c7..91b19e0 100644
> --- a/arch/arm/lib/crt0_64.S
> +++ b/arch/arm/lib/crt0_64.S
> @@ -108,6 +108,7 @@ relocation_return:
>   * Set up final (full) environment
>   */
> bl  c_runtime_cpu_setup /* still call old routine */
> +#endif /* !CONFIG_SPL_BUILD */
>
>  /* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
>
> @@ -130,6 +131,4 @@ clear_loop:
>
> /* NOTREACHED - board_init_r() does not return */
>
> -#endif /* !CONFIG_SPL_BUILD */
> -
>  ENDPROC(_main)
> diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
> index e428868..b188834 100644
> --- a/arch/arm/lib/spl.c
> +++ b/arch/arm/lib/spl.c
> @@ -25,22 +25,22 @@ gd_t gdata __attribute__ ((section(".data")));
>  #endif
>
>  /*
> - * In the context of SPL, board_init_f must ensure that any clocks/etc for
> - * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
> - * and call board_init_r.  We provide this version by default but mark it
> - * as __weak to allow for platforms to do this in their own way if needed.
> + * In the context of SPL, board_init_f() prepares the hardware for execution
> + * from system RAM (DRAM, DDR...). As system RAM may not be available yet,
> + * board_init_f() must use the current GD to store any data which must be
> + * passed on to later stages. These data include the relocation destination,
> + * the future stack, and the future GD location. BSS is cleared after this
> + * function (and therefore must be accessible).
> + *
> + * We provide this version by default but mark it as __weak to allow for
> + * platforms to do this in their own way if needed.

Can you please add a comment pointing to the README also ("Board
Initialisation Flow")?

>   */
>  void __weak board_init_f(ulong dummy)
>  {
> -   /* Clear the BSS. */
> -   memset(__bss_start, 0, __bss_end - __bss_start);
> -
>  #ifndef CONFIG_SPL_DM
> /* TODO: Remove settings of the global data pointer here */
> gd = &gdata;
>  #endif
> -

This is a good change, but if you are dropping the call to
board_init_r() then you should drop the above code also (along with
the gdata variable). I doubt any more is using it now as it has been a
while. So this weak function should be empty.

> -   board_init_r(NULL, 0);
>  }
>
>  /*
> --
> 2.4.4
>

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

Re: [U-Boot] xHCI on x86

[Simon Glass]

Hi,

On 13 July 2016 at 00:20, Stefan Roese  wrote:
> Hi!
>
> I'm currently trying to get xHCI working on some BayTrail based
> x86 boards. For this I've added DM support to xhci-pci and made a
> small change to cache.h to enable compilation of the xhci driver on
> x86 (please find those 2 patches attached - I'll send then to the
> list once this is resolved). But I noticed that the xhci driver
> hangs in xhci_queue_command() in this line:
>
> xhci_writel(&ctrl->dba->doorbell[0], DB_VALUE_HOST);
>
> when first writing to the doorbell register. Reading from this doorbell
> register still works just fine.
>
> IIRC, Simon has mentioned that xHCI still has some "issues" on x86.
> Simon, is this what you have seen as well? Does anyone have some ideas
> how to solve this?

I'm really not sure what is wrong, sorry. The discussion about
enabling the pin settings correctly may be relevant since I believe
two GPIOs need to be set up for both ports to work, and that patch was
never cleaned up and applied, so far as I know...

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

Re: [U-Boot] [PATCH 8/9] power: pmic: add Ricoh RN5T567 PMIC support

[Simon Glass]

Hi Stefan,

On 13 July 2016 at 00:10, Stefan Agner  wrote:
> On 2016-07-03 16:18, Simon Glass wrote:
>> Hi,
>>
>> On 3 July 2016 at 13:33, Stefan Agner  wrote:
>>> From: Stefan Agner 
>>>
>>> Add power driver for Ricoh PMIC used on Colibri iMX7.
>>>
>>> Signed-off-by: Stefan Agner 
>>> Acked-by: Marcel Ziswiler 
>>> ---
>>>
>>>  drivers/power/pmic/Makefile   |   1 +
>>>  drivers/power/pmic/pmic_rn5t567.c |  32 +++
>>>  include/power/rn5t567_pmic.h  | 115 
>>> ++
>>>  3 files changed, 148 insertions(+)
>>>  create mode 100644 drivers/power/pmic/pmic_rn5t567.c
>>>  create mode 100644 include/power/rn5t567_pmic.h
>>
>> Shouldn't this use driver model?
>
> Looked into this a bit more in detail.
>
> Afaict, using DM for PMIC would need to use DM for I2C too. The current
> driver supports I2C DM only when using device tree, plus it would also
> require DM for GPIOs, all that is currently not used by the i.MX 7
> platform.
>
> I would prefer to stick with the current implementation until that is
> sorted, is that acceptable for now?

Yes, but I hope you can resolve this quickly. It is not good to add
new code to old frameworks as they get harder to remove.

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

Re: [U-Boot] [PATCH] rockchip: Clean up CPU selection

[Simon Glass]

On 13 July 2016 at 21:09, Andreas Färber  wrote:
> In preparation for RK3368 and RK3399, which need to select ARM64, don't
> select CPU_V7 at the ARCH_ROCKCHIP level but at the SoC level instead.
>
> Cc: Kever Yang 
> Signed-off-by: Andreas Färber 
> ---
>  arch/arm/Kconfig   | 1 -
>  arch/arm/mach-rockchip/Kconfig | 2 ++
>  2 files changed, 2 insertions(+), 1 deletion(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: Exclude rk_timer for ARM64

[Simon Glass]

On 13 July 2016 at 22:22, Andreas Färber  wrote:
> It conflicts with the generic_timer.
>
> Cc: Kever Yang 
> Signed-off-by: Andreas Färber 
> ---
>  arch/arm/mach-rockchip/Makefile | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5] rockchip: add option to change method of loading u-boot

[Simon Glass]

On 12 July 2016 at 18:42, Ziyuan Xu  wrote:
> hi Simon,
>
>
> On 2016年07月12日 21:28, Simon Glass wrote:
>>
>> On 12 July 2016 at 05:09, Ziyuan Xu  wrote:
>>>
>>> From: Xu Ziyuan 
>>>
>>> If we would like to boot from SD card, we have to implement mmc driver
>>> in SPL stage, and get a slightly large SPL binary. Rockchip SoC's
>>> bootrom code has the ability to load spl and u-boot, then boot.
>>>
>>> If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to
>>> bootrom in board_init_f(), then bootrom loads u-boot binary.
>>>
>>> Loading sequence after rework:
>>> bootrom ==> spl ==> bootrom ==> u-boot
>>>
>>> Signed-off-by: Ziyuan Xu 
>>> Acked-by: Simon Glass 
>>> ---
>>>
>>> Changes in v5:
>>> - Revise some typos
>>>
>>> Changes in v4:
>>> - Add acked flag from Simon
>>> - Rename to CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
>>> - Add Kconfig option for this feature support
>>> - Revise some nits
>>> - Update comments a little
>>> - Update commit message
>>>
>>> Changes in v3:
>>> - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature
>>> - Update doc/README.rockchip to instruct how to use it
>>> - Detailed commit message
>>>
>>> Changes in v2:
>>> - Add sdcard iomux initlization in board_init() to fix sdmmc command
>>> sending timeout issue when booting from eMMC
>>>
>>>   arch/arm/mach-rockchip/Kconfig |  8 ++
>>>   arch/arm/mach-rockchip/Makefile|  1 +
>>>   arch/arm/mach-rockchip/board.c | 33
>>> ++
>>>   arch/arm/mach-rockchip/rk3036/Makefile |  1 -
>>>   arch/arm/mach-rockchip/rk3288-board-spl.c  |  5 +++-
>>>   .../mach-rockchip/{rk3036 => }/save_boot_param.S   |  2 +-
>>>   doc/README.rockchip| 14 +
>>>   include/configs/rk3288_common.h|  5 
>>>   8 files changed, 66 insertions(+), 3 deletions(-)
>>>   rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%)
>>
>> I fixed several typos in the Kconfig help, so ended up rewording it a
>> little. Your patches are good but please can you take a little more
>> time to read them before sending? Also please use "U-Boot"
>> consistently instead of u-boot, U-BOOT, etc. I am not claiming to be
>> perfect here either - in fact I am quite bad with typos sometimes. But
>> a read through will often reduce their number.
>>
>> Fixed, and:
>>
>> Applied to u-boot-rockchip, thanks!
>
> Thanks for your help, I will be more carefully. :-)
> [snip]
> A nit should be fixed.
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index d1c0dde..cf718fa 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -22,7 +22,7 @@ config ROCKCHIP_SPL_BACK_TO_BROM
> default y if ROCKCHIP_RK3036
> help
>   Rockchip SoCs have ability to load SPL & U-Boot binary. If
> enabled,
> -  SPL will return to the boot rom, whch will then load the U-Boot
> +  SPL will return to the boot rom, which will then load the U-Boot
>binary to keep going on.

Thanks - fixed!

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

Re: [U-Boot] [PATCH 1/5] dts: add support for rkchichip rk3399 soc

[Simon Glass]

On 13 July 2016 at 23:08, Kever Yang  wrote:
> These files are from kernel upstream with some modification
> need by uboot:
> - chosen with stdout-path to uart2.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/dts/Makefile  |3 +-
>  arch/arm/dts/rk3399-evb.dts|  104 
>  arch/arm/dts/rk3399.dtsi   | 1028 
> 
>  include/dt-bindings/clock/rk3399-cru.h |  746 +++
>  4 files changed, 1880 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/rk3399-evb.dts
>  create mode 100644 arch/arm/dts/rk3399.dtsi
>  create mode 100644 include/dt-bindings/clock/rk3399-cru.h

Acked-by: Simon Glass 

But please fix the typo in the commit subject.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5]

[Simon Glass]

Hi Kever,

On 13 July 2016 at 23:08, Kever Yang  wrote:
> This patchset add support for rk3399 with ATF based on
> Rockchip miniloader as secondary bootloader instead of
> u-boot SPL.

U-Boot

>
> Rockchip miniloader init the DRAM and load the ATF and
> u-boot to runing address, and then jump to ATF, ATM
> do some init and switch to EL2/EL1 mode before jump to
> next loader which is u-boot here.
>
> Pls reference board/rockchip/evb_rk3399/README to setup
> the board.
>
> Will migrate to SPL once its ready for ATF.
>
> This patch set is based on below patch:
> "board: move all the rockchip board in one folder"
>
> This patch set has been test on rk3399 evb board.
>
>
>
> Kever Yang (5):
>   dts: add support for rkchichip rk3399 soc
>   ARM64: rockchip: add support for rk3399 SoC based evb-board
>   config: add config file for evb-rk3399
>   mmc: rockchip: add SDHCI driver support for rockchip soc
>   ARM64: evb-rk3399: add a README for this board setup

I don't see this last patch on the mailing list.

>
>  arch/arm/Kconfig   |3 -
>  arch/arm/dts/Makefile  |3 +-
>  arch/arm/dts/rk3399-evb.dts|  104 
>  arch/arm/dts/rk3399.dtsi   | 1028 
> 
>  arch/arm/mach-rockchip/Kconfig |   25 +-
>  arch/arm/mach-rockchip/Makefile|2 +-
>  arch/arm/mach-rockchip/rk3399/Kconfig  |   19 +
>  arch/arm/mach-rockchip/rk3399/Makefile |5 +
>  board/rockchip/evb_rk3399/Kconfig  |   15 +
>  board/rockchip/evb_rk3399/MAINTAINERS  |0
>  board/rockchip/evb_rk3399/Makefile |7 +
>  board/rockchip/evb_rk3399/README   |   73 +++
>  board/rockchip/evb_rk3399/evb-rk3399.c |   41 ++
>  configs/evb-rk3399_defconfig   |   32 +
>  drivers/mmc/Kconfig|6 +
>  drivers/mmc/Makefile   |1 +
>  drivers/mmc/rockchip_sdhci.c   |   58 ++
>  include/configs/evb_rk3399.h   |   24 +
>  include/configs/rk3399_common.h|   84 +++
>  include/dt-bindings/clock/rk3399-cru.h |  746 +++
>  20 files changed, 2270 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-evb.dts
>  create mode 100644 arch/arm/dts/rk3399.dtsi
>  create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile
>  create mode 100644 board/rockchip/evb_rk3399/Kconfig
>  create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
>  create mode 100644 board/rockchip/evb_rk3399/Makefile
>  create mode 100644 board/rockchip/evb_rk3399/README
>  create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
>  create mode 100644 configs/evb-rk3399_defconfig
>  create mode 100644 drivers/mmc/rockchip_sdhci.c
>  create mode 100644 include/configs/evb_rk3399.h
>  create mode 100644 include/configs/rk3399_common.h
>  create mode 100644 include/dt-bindings/clock/rk3399-cru.h
>
> --
> 1.9.1
>
>

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

Re: [U-Boot] [PATCH 4/5] mmc: rockchip: add SDHCI driver support for rockchip soc

[Simon Glass]

Hi Kever,

On 13 July 2016 at 23:08, Kever Yang  wrote:
> Rockchip rk3399 using arasan sdhci-5.1 controller.
> This patch add the controller support to enable mmc device and tested on
> rk3399 evb board.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/mmc/Kconfig  |  6 +
>  drivers/mmc/Makefile |  1 +
>  drivers/mmc/rockchip_sdhci.c | 58 
> 
>  3 files changed, 65 insertions(+)
>  create mode 100644 drivers/mmc/rockchip_sdhci.c
>

Can you please update this to define CONFIG_BLK and CONFIG_DM_MMC_OPS?
This will give it full driver-model support.

See msm_sdhci.c for an example.

> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index c80efc3..75c2d92 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -52,6 +52,12 @@ config ZYNQ_SDHCI
> help
>   Support for Arasan SDHCI host controller on Zynq/ZynqMP ARM SoCs 
> platform
>
> +config ROCKCHIP_SDHCI
> +   bool "Arasan SDHCI controller for Rockchip support"
> +   depends on DM_MMC && OF_CONTROL
> +   help
> + Support for Arasan SDHCI host controller on Rockchip ARM SoCs 
> platform
> +
>  config MMC_UNIPHIER
> bool "UniPhier SD/MMC Host Controller support"
> depends on ARCH_UNIPHIER
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 3da4817..7cb2ab0 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
>  obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
>  obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
>  obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
> +obj-$(CONFIG_ROCKCHIP_SDHCI) += rockchip_sdhci.o
>
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> new file mode 100644
> index 000..bee269d
> --- /dev/null
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -0,0 +1,58 @@
> +/*
> + * (C) Copyright 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Rockchip SD Host Controller Interface
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* 400KHz is max freq for card ID etc. Use that as min */
> +#define EMMC_MIN_FREQ  40
> +
> +static int arasan_sdhci_probe(struct udevice *dev)
> +{
> +   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> +   struct sdhci_host *host = dev_get_priv(dev);
> +
> +
> +   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> +   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD;
> +
> +   add_sdhci(host, CONFIG_ROCKCHIP_SDHCI_MAX_FREQ, EMMC_MIN_FREQ);
> +
> +   upriv->mmc = host->mmc;
> +   host->mmc->dev = dev;
> +
> +   return 0;
> +}
> +
> +static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
> +{
> +   struct sdhci_host *host = dev_get_priv(dev);
> +
> +   host->name = dev->name;
> +   host->ioaddr = (void *)dev_get_addr(dev);

You can use dev_get_addr_ptr() here.

> +
> +   return 0;
> +}
> +
> +static const struct udevice_id arasan_sdhci_ids[] = {
> +   { .compatible = "arasan,sdhci-5.1" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(arasan_sdhci_drv) = {
> +   .name   = "arasan_sdhci",
> +   .id = UCLASS_MMC,
> +   .of_match   = arasan_sdhci_ids,
> +   .ofdata_to_platdata = arasan_sdhci_ofdata_to_platdata,
> +   .probe  = arasan_sdhci_probe,
> +   .priv_auto_alloc_size = sizeof(struct sdhci_host),
> +};
> --
> 1.9.1
>
>

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

Re: [U-Boot] [PATCH 3/5] config: add config file for evb-rk3399

[Simon Glass]

On 13 July 2016 at 23:08, Kever Yang  wrote:
> This patch add basic config option for evb-rk3399 board.
>
> Signed-off-by: Kever Yang 
> ---
>
>  configs/evb-rk3399_defconfig | 32 
>  1 file changed, 32 insertions(+)
>  create mode 100644 configs/evb-rk3399_defconfig

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board

[Simon Glass]

Hi Kever,

On 13 July 2016 at 23:08, Kever Yang  wrote:
> RK3399 is a SoC from Rockchip with dual-core Cortex-A72
> and qual-core Cortex-A53 CPU. It supports two USB3.0
> type-C ports and two USB2.0 EHCI ports. Other interfaces
> are very like RK3288, the DRAM are 32bit width address
> and support address from 0 to 4GB-128MB range.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/Kconfig   |  3 --
>  arch/arm/mach-rockchip/Kconfig | 25 +-
>  arch/arm/mach-rockchip/Makefile|  2 +-
>  arch/arm/mach-rockchip/rk3399/Kconfig  | 19 
>  arch/arm/mach-rockchip/rk3399/Makefile |  5 ++
>  board/rockchip/evb_rk3399/Kconfig  | 15 ++
>  board/rockchip/evb_rk3399/MAINTAINERS  |  0
>  board/rockchip/evb_rk3399/Makefile |  7 +++
>  board/rockchip/evb_rk3399/evb-rk3399.c | 41 +
>  include/configs/evb_rk3399.h   | 24 ++
>  include/configs/rk3399_common.h| 84 
> ++
>  11 files changed, 220 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile
>  create mode 100644 board/rockchip/evb_rk3399/Kconfig
>  create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
>  create mode 100644 board/rockchip/evb_rk3399/Makefile
>  create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
>  create mode 100644 include/configs/evb_rk3399.h
>  create mode 100644 include/configs/rk3399_common.h

Acked-by: Simon Glass 

nits below

>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8a9cfcc..6e4d78a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -846,10 +846,7 @@ config STM32
>
>  config ARCH_ROCKCHIP
> bool "Support Rockchip SoCs"
> -   select SUPPORT_SPL
> -   select SPL
> select OF_CONTROL
> -   select CPU_V7
> select DM
>
>  config TARGET_THUNDERX_88XX
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 2a8afac..2a739ea 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -1,5 +1,8 @@
>  if ARCH_ROCKCHIP
>
> +config RK_TIMER
> +   bool
> +
>  config ROCKCHIP_RK3288
> bool "Support Rockchip RK3288"
> help
> @@ -8,6 +11,10 @@ config ROCKCHIP_RK3288
>   video interfaces supporting HDMI and eDP, several DDR3 options
>   and video codec support. Peripherals include Gigabit Ethernet,
>   USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.
> +   select CPU_V7
> +   select RK_TIMER
> +   select SUPPORT_SPL
> +   select SPL
>
>  config ROCKCHIP_RK3036
> bool "Support Rockchip RK3036"
> @@ -16,6 +23,21 @@ config ROCKCHIP_RK3036
>   including NEON and GPU, Mali-400 graphics, several DDR3 options
>   and video codec support. Peripherals include Gigabit Ethernet,
>   USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
> +   select CPU_V7
> +   select RK_TIMER
> +   select SUPPORT_SPL
> +   select SPL
> +
> +config ROCKCHIP_RK3399
> +   bool "Support Rockchip RK3399"
> +   help
> + The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
> + and qual-core Cortex-A53.
> + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
> + video interfaces supporting HDMI and eDP, several DDR3 options
> + and video codec support. Peripherals include Gigabit Ethernet,
> + USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.
> +   select ARM64
>
>  config SYS_MALLOC_F
> default y
> @@ -42,8 +64,9 @@ config DM_GPIO
> default y
>
>  config BLK
> -   default y
> +   default y if CPU_V7
>
>  source "arch/arm/mach-rockchip/rk3288/Kconfig"
>  source "arch/arm/mach-rockchip/rk3036/Kconfig"
> +source "arch/arm/mach-rockchip/rk3399/Kconfig"
>  endif
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 55567cb..50246f0 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -10,6 +10,6 @@ obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
>  else
>  obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
>  endif
> -obj-y += rk_timer.o
> +obj-$(CONFIG_RK_TIMER) += rk_timer.o
>  obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
>  obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
> b/arch/arm/mach-rockchip/rk3399/Kconfig
> new file mode 100644
> index 000..603f534
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -0,0 +1,19 @@
> +if ROCKCHIP_RK3399
> +
> +config TARGET_EVB_RK3399
> +   bool "RK3399 evb board"
> +   help
> + Firefly is a RK3288-based development board with 2 USB ports,

Firefly?

Please check that this help is correct.

> + HDMI, VGA, micro-SD card, audio, WiFi  and Gigabit Ethernet, It
> + also includes on-board eMMC and 1GB of SDRAM. Expansio

Re: [U-Boot] [PATCH v4 4/4] usb: dwc2 : invalidate dcache before starting DMA

[Simon Glass]

On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> Invalidate dcache before starting the DMA to ensure coherency. In case
> there are any dirty lines from the DMA buffer in the cache, subsequent
> cache-line replacements may corrupt the buffer in memory while the DMA
> is still going on. Cache-line replacement can happen if the CPU tries to
> bring some other memory locations into the cache while the DMA is going
> on.
>
> Signed-off-by: Ziyuan Xu 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - New commit since v3 to fix the coherence issue between memory and
> cache
>
> Changes in v2: None
>
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/4] usb: rockchip-phy: implement USB2.0 phy control

[Simon Glass]

On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> So far, Rockchip SoCs have two kinds of USB2.0 phy, such as Synopsys and
> Innosilicon. This patch applys dwc2 usb driver framework to implement
> phy_init() and phy_off() methods for Synopsys phy on Rockchip platform.
>
> Signed-off-by: Ziyuan Xu 
>
> ---
>
> Changes in v4:
> - Implement a mechanism to be compatible with more Rockchip SoCs
> - Rename rockchip_usb_syno_phy.c to rockchip_usb2_phy.c
>
> Changes in v3:
> - Make UOC_CON registers to be unfixed which should be got from DT
>
> Changes in v2:
> - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
> - Rework the behaviour in otg_phy_init() and otg_phy_off()
>
>  drivers/usb/phy/Makefile|   1 +
>  drivers/usb/phy/rockchip_usb2_phy.c | 107 
> 
>  include/usb/dwc2_udc.h  |   2 +
>  3 files changed, 110 insertions(+)
>  create mode 100644 drivers/usb/phy/rockchip_usb2_phy.c

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/4] usb: dwc2-otg: adjust fifo size via platform data

[Simon Glass]

On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> The total FIFO size of some SoCs may be different from the existen, this
> patch supports fifo size setting from platform data.
>
> Signed-off-by: Ziyuan Xu 
>
> ---
>
> Changes in v4:
> - Rework fifo size getting and setting
> - Update commit message
>
> Changes in v3: None
> Changes in v2:
> - Update detailed commit message
> - Modify the macro's values
>
>  drivers/usb/gadget/dwc2_udc_otg.c  | 22 --
>  drivers/usb/gadget/dwc2_udc_otg_regs.h |  6 +++---
>  include/usb/dwc2_udc.h |  3 +++
>  3 files changed, 22 insertions(+), 9 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA

[Simon Glass]

Hi Ziyuan,

On 14 July 2016 at 09:43, Ziyuan Xu  wrote:
> Hi Simon,
>
>
> On 2016年07月14日 23:00, Simon Glass wrote:
>>
>> On 12 July 2016 at 19:06, Ziyuan Xu  wrote:
>>>
>>>
>>> On 2016年07月12日 20:59, Simon Glass wrote:

 Hi Ziyuan,

 On 6 July 2016 at 03:34, Ziyuan Xu  wrote:
>
> From: Xu Ziyuan 
>
> Invalidate dcache before starting the DMA to ensure coherency. In case
> there are any dirty lines from the DMA buffer in the cache, subsequent
> cache-line replacements may corrupt the buffer in memory while the DMA
> is still going on. Cache-line replacement can happen if the CPU tries
> to
> bring some other memory locations into the cache while the DMA is going
> on.
>
> Signed-off-by: Ziyuan Xu 
> ---
>
> Changes in v3:
> - New commit since v3 to fix the coherence issue between memory and
> cache
>
> Changes in v2: None
>
>drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
>1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> index 12f5c85..0d6d2fb 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct
> dwc2_request *req)
>
>   ctrl =  readl(®->out_endp[ep_num].doepctl);
>
> +   invalidate_dcache_range((unsigned long) ep->dma_buf,
> +   (unsigned long) ep->dma_buf + ep->len);

 There is an invalidate in complete_rx() which is one of the callers
 for this function. It seems to me that we should not have this in two
 places. Why do we have this problem? Is it because the other calls to
 setdma_rx() don't invalidate?
>>>
>>>
>>> Yup, invoke invalidate method twice during one complete transmission:
>>> 1- invalidate in setdma_rx() in case of  the write back cache, present
>>> from
>>> cache-line replacement after DMA transmission complete.
>>> i.e.
>>> 1) dma_buf = "123456789abcd";
>>> 2) didn't invalidate in setdma_rx()
>>> 3) DMA complete interrupt coming
>>> 4) invalidate in complete_rx()
>>> 5) read dma_buf, it's "123456789abcd"
>>>
>>> If invalidate in step 2, we will achieve correct data.
>>> I think it's necessary to invalidate before starting DMA, and
>>> doc/README.arm-caches describe  details.
>>> 2- invalidate in complete_rx(), cpu read the dma_buf from memory
>>> directly.
>>>
 I think the invalidate should happen just before reading the data. Can
 you please check if the other invalidate is needed? Also see how it
 cache-aligns the end address.
>>>
>>> memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE);
>>> cache-aligns: 64 bytes.
>>> dma_buffer size: 4096
>>>
>>> I had check cache-aligins and end address, rightful.
>>> Furthermore, everything works fine with noncached_alloc().
>>>
>> OK, thanks for the details. Can the invalidate in (4) be dropped? We
>> should only need one invalidate.
>
> We also need invalidate in after  DMA transfer completed, because in some
> processors memory contents can spontaneouslycome to the cache due to
> speculative memory access by the CPU. If this happens with the DMA buffer
> while DMA is going on we have a coherency problem.

Gosh that is horrible.

> Thanks for your review!
>
>
>>
>> Reviewed-by: Simon Glass 
>>
> +
>   writel((unsigned int) ep->dma_buf,
> ®->out_endp[ep_num].doepdma);
>   writel(DOEPT_SIZ_PKT_CNT(pktcnt) |
> DOEPT_SIZ_XFER_SIZE(length),
>  ®->out_endp[ep_num].doeptsiz);
> --
> 1.9.1
>
>
 Regards,
 Simon



>>>
>>
>>
>
>

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

Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial

[Simon Glass]

On 13 July 2016 at 21:51, Kever Yang  wrote:
> Add support for rockchip rk33 series Soc like rk3368 and rk3399
>
> Signed-off-by: Kever Yang 
> ---
>
>  tools/rkcommon.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> index 72621fd..9ec7eb2 100644
> --- a/tools/rkcommon.c
> +++ b/tools/rkcommon.c
> @@ -56,6 +56,7 @@ struct spl_info {
>  static struct spl_info spl_infos[] = {
> { "rk3036", "RK30", 0x1000 },
> { "rk3288", "RK32", 0x8000 },
> +   { "rk33xx", "RK33", 0x2 },
>  };
>
>  static unsigned char rc4_key[16] = {
> --
> 1.9.1
>
>

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4.1 3/4] rockchip: rk3288: add fastboot support

[Simon Glass]

On 14 July 2016 at 10:26, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> Enable fastboot feature on rk3288.
>
> This path doesn't support the fastboot flash function command entirely.

patch?

> We will hit "cannot find partition" assertion without specified
> partition environment. Define gpt partition layout in specified board
> such as firefly-rk3288, then enjoy it!
>
> Signed-off-by: Ziyuan Xu 
>
> ---
>
> Changes in v4.1:
> - Revise tx_fifo_sz to 128
>
> Changes in v4:
> - Add fifo size for rk3288
> - Get usb_phy's dt_node
>
> Changes in v3:
> - Achieve UOC_CON_OFFSET physical address from DT
>
> Changes in v2:
> - Achieve the regs_phy from DT
> - Update comments a little
>
>  arch/arm/dts/rk3288.dtsi|  1 +
>  arch/arm/mach-rockchip/board.c  | 72 
> +
>  include/configs/rk3288_common.h | 26 +++
>  3 files changed, 99 insertions(+)

Acked-by: Simon Glass 

Could you please add some documentation to README.rockchip on how to use this?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: Exclude rk_timer for ARM64

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 13 July 2016 at 22:22, Andreas Färber  wrote:
>> It conflicts with the generic_timer.
>>
>> Cc: Kever Yang 
>> Signed-off-by: Andreas Färber 
>> ---
>>  arch/arm/mach-rockchip/Makefile | 2 ++
>>  1 file changed, 2 insertions(+)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 13 July 2016 at 21:51, Kever Yang  wrote:
>> Add support for rockchip rk33 series Soc like rk3368 and rk3399
>>
>> Signed-off-by: Kever Yang 
>> ---
>>
>>  tools/rkcommon.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
>> index 72621fd..9ec7eb2 100644
>> --- a/tools/rkcommon.c
>> +++ b/tools/rkcommon.c
>> @@ -56,6 +56,7 @@ struct spl_info {
>>  static struct spl_info spl_infos[] = {
>> { "rk3036", "RK30", 0x1000 },
>> { "rk3288", "RK32", 0x8000 },
>> +   { "rk33xx", "RK33", 0x2 },
>>  };
>>
>>  static unsigned char rc4_key[16] = {
>> --
>> 1.9.1
>>
>>
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v4 1/4] usb: rockchip-phy: implement USB2.0 phy control

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
>> From: Xu Ziyuan 
>>
>> So far, Rockchip SoCs have two kinds of USB2.0 phy, such as Synopsys and
>> Innosilicon. This patch applys dwc2 usb driver framework to implement
>> phy_init() and phy_off() methods for Synopsys phy on Rockchip platform.
>>
>> Signed-off-by: Ziyuan Xu 
>>
>> ---
>>
>> Changes in v4:
>> - Implement a mechanism to be compatible with more Rockchip SoCs
>> - Rename rockchip_usb_syno_phy.c to rockchip_usb2_phy.c
>>
>> Changes in v3:
>> - Make UOC_CON registers to be unfixed which should be got from DT
>>
>> Changes in v2:
>> - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
>> - Rework the behaviour in otg_phy_init() and otg_phy_off()
>>
>>  drivers/usb/phy/Makefile|   1 +
>>  drivers/usb/phy/rockchip_usb2_phy.c | 107 
>> 
>>  include/usb/dwc2_udc.h  |   2 +
>>  3 files changed, 110 insertions(+)
>>  create mode 100644 drivers/usb/phy/rockchip_usb2_phy.c
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v4 2/4] usb: dwc2-otg: adjust fifo size via platform data

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
>> From: Xu Ziyuan 
>>
>> The total FIFO size of some SoCs may be different from the existen, this
>> patch supports fifo size setting from platform data.
>>
>> Signed-off-by: Ziyuan Xu 
>>
>> ---
>>
>> Changes in v4:
>> - Rework fifo size getting and setting
>> - Update commit message
>>
>> Changes in v3: None
>> Changes in v2:
>> - Update detailed commit message
>> - Modify the macro's values
>>
>>  drivers/usb/gadget/dwc2_udc_otg.c  | 22 --
>>  drivers/usb/gadget/dwc2_udc_otg_regs.h |  6 +++---
>>  include/usb/dwc2_udc.h |  3 +++
>>  3 files changed, 22 insertions(+), 9 deletions(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] rockchip: Clean up CPU selection

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 13 July 2016 at 21:09, Andreas Färber  wrote:
>> In preparation for RK3368 and RK3399, which need to select ARM64, don't
>> select CPU_V7 at the ARCH_ROCKCHIP level but at the SoC level instead.
>>
>> Cc: Kever Yang 
>> Signed-off-by: Andreas Färber 
>> ---
>>  arch/arm/Kconfig   | 1 -
>>  arch/arm/mach-rockchip/Kconfig | 2 ++
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 03/62] spl: Drop include of i2c.h

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> This file does not appear to use I2C, so drop this include.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/spl.c | 1 -
>  1 file changed, 1 deletion(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> Hi Ziyuan,
>
> On 14 July 2016 at 09:43, Ziyuan Xu  wrote:
>> Hi Simon,
>>
>>
>> On 2016年07月14日 23:00, Simon Glass wrote:
>>>
>>> On 12 July 2016 at 19:06, Ziyuan Xu  wrote:


 On 2016年07月12日 20:59, Simon Glass wrote:
>
> Hi Ziyuan,
>
> On 6 July 2016 at 03:34, Ziyuan Xu  wrote:
>>
>> From: Xu Ziyuan 
>>
>> Invalidate dcache before starting the DMA to ensure coherency. In case
>> there are any dirty lines from the DMA buffer in the cache, subsequent
>> cache-line replacements may corrupt the buffer in memory while the DMA
>> is still going on. Cache-line replacement can happen if the CPU tries
>> to
>> bring some other memory locations into the cache while the DMA is going
>> on.
>>
>> Signed-off-by: Ziyuan Xu 
>> ---
>>
>> Changes in v3:
>> - New commit since v3 to fix the coherence issue between memory and
>> cache
>>
>> Changes in v2: None
>>
>>drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
>>1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> index 12f5c85..0d6d2fb 100644
>> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct
>> dwc2_request *req)
>>
>>   ctrl =  readl(®->out_endp[ep_num].doepctl);
>>
>> +   invalidate_dcache_range((unsigned long) ep->dma_buf,
>> +   (unsigned long) ep->dma_buf + ep->len);
>
> There is an invalidate in complete_rx() which is one of the callers
> for this function. It seems to me that we should not have this in two
> places. Why do we have this problem? Is it because the other calls to
> setdma_rx() don't invalidate?


 Yup, invoke invalidate method twice during one complete transmission:
 1- invalidate in setdma_rx() in case of  the write back cache, present
 from
 cache-line replacement after DMA transmission complete.
 i.e.
 1) dma_buf = "123456789abcd";
 2) didn't invalidate in setdma_rx()
 3) DMA complete interrupt coming
 4) invalidate in complete_rx()
 5) read dma_buf, it's "123456789abcd"

 If invalidate in step 2, we will achieve correct data.
 I think it's necessary to invalidate before starting DMA, and
 doc/README.arm-caches describe  details.
 2- invalidate in complete_rx(), cpu read the dma_buf from memory
 directly.

> I think the invalidate should happen just before reading the data. Can
> you please check if the other invalidate is needed? Also see how it
> cache-aligns the end address.

 memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE);
 cache-aligns: 64 bytes.
 dma_buffer size: 4096

 I had check cache-aligins and end address, rightful.
 Furthermore, everything works fine with noncached_alloc().

>>> OK, thanks for the details. Can the invalidate in (4) be dropped? We
>>> should only need one invalidate.
>>
>> We also need invalidate in after  DMA transfer completed, because in some
>> processors memory contents can spontaneouslycome to the cache due to
>> speculative memory access by the CPU. If this happens with the DMA buffer
>> while DMA is going on we have a coherency problem.
>
> Gosh that is horrible.
>
>> Thanks for your review!
>>

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

Re: [U-Boot] [PATCH v3 01/62] sandbox: Don't print a warning for CONFIG_I2C_COMPAT

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> Sandbox includes this code to provide build coverage. While we retain this
> feature we should have sandbox build it. Sandbox does not in fact use the
> I2C compatibility mode. Showing a warning for sandbox is just confusing,
> since no conversion is expected.
>
> Drop the warning for sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 04/62] Makefile: Allow the SPL final link rule to be overridden

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> Overriding the final link rule is possible with U-Boot proper. It us used to
> create a sandbox image links with host libraries. To build a sandbox SPL
> image we need the same feature for SPL.
>
> To support this, update the SPL link rule so sandbox can override it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  scripts/Makefile.spl | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/62] README: Remove CONFIG_SYS_MALLOC_F_LEN comment

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> This option is now widely available, so remove the comment that it is only
> available on ARM and sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  README | 3 ---
>  1 file changed, 3 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/4] usb: dwc2 : invalidate dcache before starting DMA

[Simon Glass]

On 14 July 2016 at 21:20, Simon Glass  wrote:
> On 14 July 2016 at 00:52, Ziyuan Xu  wrote:
>> From: Xu Ziyuan 
>>
>> Invalidate dcache before starting the DMA to ensure coherency. In case
>> there are any dirty lines from the DMA buffer in the cache, subsequent
>> cache-line replacements may corrupt the buffer in memory while the DMA
>> is still going on. Cache-line replacement can happen if the CPU tries to
>> bring some other memory locations into the cache while the DMA is going
>> on.
>>
>> Signed-off-by: Ziyuan Xu 
>>
>> ---
>>
>> Changes in v4: None
>> Changes in v3:
>> - New commit since v3 to fix the coherence issue between memory and
>> cache
>>
>> Changes in v2: None
>>
>>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
>>  1 file changed, 3 insertions(+)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 06/62] sandbox: Support building an SPL image

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> When building an SPL image, override the link flags so that it uses the
> system libraries. This is similar to the way the non-SPL image is built.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/config.mk | 5 +
>  1 file changed, 5 insertions(+)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/62] sandbox: Allow chaining from SPL to U-Boot proper

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> SPL is expected to load and run U-Boot. This needs to work with sandbox also.
> Provide a function to locate the U-Boot image, and another to start it. This
> allows SPL to function on sandbox as it does on other archs.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/os.c | 51 
> +++
>  include/os.h  | 25 +
>  2 files changed, 76 insertions(+)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/62] sandbox: Add some missing headers in cpu.c

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> These headers are needed in case they are not transitively included.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/cpu.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 07/62] sandbox: Correct header file order in cpu.c

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> The dm/ file should go at the end. Move it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/62] sandbox: Don't include the main loop in SPL

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> SPL does not have a command interface so we should not include the main loop
> code.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/start.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/62] sandbox: Don't use PCI in SPL

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> PCI is not supported in SPL for sandbox, so avoid using it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/cpu.c| 2 +-
>  arch/sandbox/lib/Makefile | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/62] sandbox: Add basic SPL implementation

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> Add an sandbox implementation for the generic SPL framework. This supports
> locating and running U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/Makefile  |  1 +
>  arch/sandbox/cpu/spl.c | 51 
> ++
>  arch/sandbox/include/asm/spl.h | 23 +++
>  3 files changed, 75 insertions(+)
>  create mode 100644 arch/sandbox/cpu/spl.c
>  create mode 100644 arch/sandbox/include/asm/spl.h

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 13/62] sandbox: serial: Don't sync video in SPL

[Simon Glass]

On 4 July 2016 at 11:57, Simon Glass  wrote:
> SPL does not support an LCD display so there is no need to sync the video
> when there is serial output.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/serial/sandbox.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot