Re: [U-Boot] Azalia verb table from DT with Baytrail FSP

[Bin Meng]

Hi George,

On Fri, May 20, 2016 at 11:05 PM, George McCollister
 wrote:
> I'm working with an Advantech som-6867 (Baytrail com express CPU
> module) and som-db5800 carrier board (with ALC892 HD audio codec) as
> well as a custom carrier board (with CS4207 HD audio codec).
>
> After adding DT entries for the correct HDA pad configuration, I got
> the ALC892 working by hacking over ALC262 verb table in
> arch/x86/cpu/baytrail/fsp_configs.c and am now investigating a
> permanent solution.
>
> I noticed in Bin's patchset titled "x86: fsp: Move platform-specific
> config to chipset directory" his comment "But with this series, we are
> now able to get Azalia verb table from device tree, just like what we
> did for overriding UPD data configuration. This can be done in future
> patch set."
>
> I also however noticed Simon's conflicting comment in
> arch/x86/cpu/baytrail/fsp_configs.c "This needs to be in ROM since if
> we put it in CAR, FSP init loses it when it drops CAR."
>

Guess the comment is out of date.

> Is it safe to move Azalia verb tables into DT for Baytrail FSP?
>

Yes it is safe to move verb tables to DT, but I have not looked into
this. Patches are welcome.

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

Re: [U-Boot] style issue: ft_board_setup() versus ft_verify_fdt()?

[Simon Glass]

Hi Robert,

On 19 May 2016 at 06:51, Robert P. J. Day  wrote:
>
>   curious about recommended coding style related to modifying and
> verifying FDTs ... i'm perusing common/image-fdt.c and can see the
> order of (possible) operations here in the function
> image_setup_libfdt():
>
>  * arch_fixup_fdt()
>  * ft_board_setup()
>  * ft_system_setup()
>  * fdt_fixup_ethernet()
>... etc etc ...
>  * ft_verify_fdt()
>
> where an earlier comment explains that last routine:
>
> /*
>  * Verify the device tree.
>  *
>  * This function is called after all device tree fix-ups have been enacted,
>  * so that the final device tree can be verified.  The definition of 
> "verified"
>  * is up to the specific implementation.  However, it generally means that the
>  * addresses of some of the devices in the device tree are compared with the
>  * actual addresses at which U-Boot has placed them.
>  *
>  * Returns 1 on success, 0 on failure.  If 0 is returned, U-Boot will halt the
>  * boot process.
>  */
> __weak int ft_verify_fdt(void *fdt)
> {
> return 1;
> }
>
>
>   which seems reasonable ... after you've mangled your FDT in every
> way you need, optionally supply a routine to make sure it looks sane.
>
>   however, for the freescale board mpc8641hpcn.c, here's part of the
> ft_board_setup() routine (actually, this is pretty much all that
> function does):
>
>
> if (tmp) {
> u64 addr;
>
> if (addrcells == 1)
> addr = *(u32 *)tmp;
> else
> addr = *tmp;
>
> if (addr != CONFIG_SYS_CCSRBAR_PHYS)
> printf("WARNING: The CCSRBAR address in your .dts "
>"does not match the address of the CCSR "
>"in u-boot.  This means your .dts might "
>"be old.\n");
> }
>
> so the board setup routine is doing some quick sanity checking, which
> is perfectly fine, but seems to be exactly the sort of thing
> ft_verify_fdt() was designed for.
>
>   obviously, one can add sanity checking to any of those routines
> depending on how early you want to notice stuff -- is there somewhere
> a style guide that gives recommendations? just looking for "best
> practices," thanks.
>
>   i'm sure there will be more FDT-related questions coming ... thank
> you for your patience.

My suggestion would be to always use an 'fdt_' prefix.

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

Re: [U-Boot] [PATCH] net: Add ag7xxx driver for Atheros MIPS

[Wills Wang]

On 05/21/2016 01:08 AM, Marek Vasut wrote:

On 05/20/2016 06:43 PM, Wills Wang wrote:


On 05/20/2016 07:59 PM, Marek Vasut wrote:

On 05/20/2016 06:18 AM, Wills Wang wrote:

On 05/08/2016 11:22 PM, Marek Vasut wrote:

On 05/08/2016 02:58 PM, Daniel Schwierzeck wrote:

Hi!


Am 05.05.2016 um 21:34 schrieb Marek Vasut:

Add ethernet driver for the AR933x and AR934x Atheros MIPS machines.
The driver could be easily extended to other WiSoCs.

How to make this patch work on ar933x board?
I apply this patch on the top of mips/next branch and enable this option
in menuconfig,
but i can't see any boot information for Ethernet.

The Kconfig conversion is not complete. See the tplink_wdr4300_defconfig
for the necessary options, it should be at least these:

CONFIG_CMD_NET=y
CONFIG_CMD_NFS=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM_ETH=y
CONFIG_AG7XXX=y


I add these options and boot up as the following, but my ar933x board
don't work,
the link indicator led on router is off when plug in the cable and
execute "dhcp" command.


Hrm, I have no idea, sorry, you'd have to dive in. It works on the board
I have. The ar933x is such a junk chip that I kinda gave up on it. I
also tested this on ar934x (my primary test platform) and it works.


I boot openwrt from u-boot on my ar933x board, and the ethernet driver
can't find chip build-in PHY, but it work well if boot from original 
manufacturer's

u-boot 1.14.

[1.854519] libphy: ag71xx_mdio: probed
[2.646539] ag71xx-mdio.1: unknown phy id ':'
[3.235778] ag71xx ag71xx.0: no PHY found with phy_mask=0010

Do you test this situation on your ar934x platform?

--
Best Regards
Wills

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

Re: [U-Boot] Sharing code between Linux and bootloader (U-boot) ?

[Tom Rini]

On Fri, May 20, 2016 at 04:28:23PM +0200, Sebastian Frias wrote:

> Hi,
> 
> Some bootloaders (like U-boot) support several HW devices: serial,
> network, NAND, USB, etc. most of which are also supported by Linux.
> 
> So the question is: is code shared? I mean, I understand that the
> drivers need to talk to the appropriate API, and such API could be
> different between Linux and U-boot.
> But putting that aside, would it be naive to imagine that some "core"
> functionality could be shared? Or would that part be so small it is
> not worth the effort?
> 
> Since many companies use both, U-boot and Linux, I would figure they
> try their best to optimize engineering resources and share code,
> right?
> In that case, I also wonder how do they share DT descriptions that
> right now are being stored in the Linux kernel tree.
> 
> We'd like to share code/DT for obvious reasons, what would you guys
> suggest?

So, in all cases, Linux is always the primary.  In some cases in U-Boot
we port drivers over (NAND is a good example here).  In other cases,
things are similar enough that it's having done it in one place it's
easy enough to do it again in the other.

-- 
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 0/9] sh: Convert generic board

[Tom Rini]

On Thu, May 19, 2016 at 09:26:46PM +0900, Yoshinori Sato wrote:

> Hello.
> This patch series convert generic board for SH.
> Tested on r2dplus target.

Since I believe you said before this was QEMU, how did you start it off?
Thanks!

-- 
Tom


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

[U-Boot] [PATCH 0/5] Update fastboot sparse image handling

[Steve Rae]

While retaining the storage abstraction feature implemented in U-Boot,
this series updates the fastboot sparse image handling by
(1) fixing broken code,
(2) resync'ing with the upstream code, and
(3) improving performance when writing CHUNK_TYPE_FILL


Steve Rae (5):
  fastboot: sparse: remove session-id logic
  fastboot: sparse: resync common/image-sparse.c (part 1)
  fastboot: sparse: resync common/image-sparse.c (part 2)
  fastboot: sparse: implement reserve()
  fastboot: sparse: improve CHUNK_TYPE_FILL write performance

 common/fb_mmc.c |  79 +++
 common/fb_nand.c| 100 +
 common/image-sparse.c   | 478 +++-
 drivers/usb/gadget/f_fastboot.c |  47 ++--
 include/fastboot.h  |   4 +-
 include/fb_mmc.h|   7 +-
 include/fb_nand.h   |   7 +-
 include/image-sparse.h  |  29 ++-
 8 files changed, 309 insertions(+), 442 deletions(-)

-- 
1.8.5

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

[U-Boot] [PATCH 4/5] fastboot: sparse: implement reserve()

[Steve Rae]

In order to process the CHUNK_TYPE_DONT_CARE properly, there is
a requirement to be able to 'reserve' a specified number of blocks
in the storage media. Because of the special handling of "bad blocks"
in NAND devices, this is implemented in a storage abstraction function.

Signed-off-by: Steve Rae 
---

 common/fb_mmc.c|  7 +++
 common/fb_nand.c   | 20 
 common/image-sparse.c  |  5 ++---
 include/image-sparse.h |  4 
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 6bafbc6..c739651 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -53,6 +53,12 @@ static lbaint_t fb_mmc_sparse_write(struct sparse_storage 
*info,
return blk_dwrite(dev_desc, blk, blkcnt, buffer);
 }
 
+static lbaint_t fb_mmc_sparse_reserve(struct sparse_storage *info,
+   lbaint_t blk, lbaint_t blkcnt)
+{
+   return blkcnt;
+}
+
 static void write_raw_image(struct blk_desc *dev_desc, disk_partition_t *info,
const char *part_name, void *buffer,
unsigned int download_bytes)
@@ -131,6 +137,7 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
sparse.start = info.start;
sparse.size = info.size;
sparse.write = fb_mmc_sparse_write;
+   sparse.reserve = fb_mmc_sparse_reserve;
 
printf("Flashing sparse image at offset " LBAFU "\n",
   sparse.start);
diff --git a/common/fb_nand.c b/common/fb_nand.c
index b5a3820..ce63006 100644
--- a/common/fb_nand.c
+++ b/common/fb_nand.c
@@ -126,6 +126,25 @@ static lbaint_t fb_nand_sparse_write(struct sparse_storage 
*info,
return written / info->blksz;
 }
 
+static lbaint_t fb_nand_sparse_reserve(struct sparse_storage *info,
+   lbaint_t blk, lbaint_t blkcnt)
+{
+   int bad_blocks = 0;
+
+/*
+ * TODO - implement a function to determine the total number
+ * of blocks which must be used in order to reserve the specified
+ * number ("blkcnt") of "good-blocks", starting at "blk"...
+ * ( possibly something like the "check_skip_len()" function )
+ */
+
+   /*
+* the return value must be 'blkcnt' ("good-blocks") plus the
+* number of "bad-blocks" encountered within this space...
+*/
+   return blkcnt + bad_blocks;
+}
+
 void fb_nand_flash_write(const char *cmd, void *download_buffer,
 unsigned int download_bytes)
 {
@@ -155,6 +174,7 @@ void fb_nand_flash_write(const char *cmd, void 
*download_buffer,
sparse.start = part->offset / sparse.blksz;
sparse.size = part->size / sparse.blksz;
sparse.write = fb_nand_sparse_write;
+   sparse.reserve = fb_nand_sparse_reserve;
 
printf("Flashing sparse image at offset " LBAFU "\n",
   sparse.start);
diff --git a/common/image-sparse.c b/common/image-sparse.c
index b36703b..9632c6f 100644
--- a/common/image-sparse.c
+++ b/common/image-sparse.c
@@ -1,3 +1,4 @@
+
 /*
  * Copyright (c) 2009, Google Inc.
  * All rights reserved.
@@ -210,10 +211,8 @@ void write_sparse_image(
break;
 
case CHUNK_TYPE_DONT_CARE:
-#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
-   blk += blkcnt;
+   blk += info->reserve(info, blk, blkcnt);
total_blocks += chunk_header->chunk_sz;
-#endif
break;
 
case CHUNK_TYPE_CRC32:
diff --git a/include/image-sparse.h b/include/image-sparse.h
index f6869d6..b0cc500 100644
--- a/include/image-sparse.h
+++ b/include/image-sparse.h
@@ -19,6 +19,10 @@ struct sparse_storage {
 lbaint_t blk,
 lbaint_t blkcnt,
 const void *buffer);
+
+   lbaint_t(*reserve)(struct sparse_storage *info,
+lbaint_t blk,
+lbaint_t blkcnt);
 };
 
 static inline int is_sparse_image(void *buf)
-- 
1.8.5

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

[U-Boot] [PATCH 5/5] fastboot: sparse: improve CHUNK_TYPE_FILL write performance

[Steve Rae]

- increase the size of the fill buffer
- testing has shown a 10x improvement when the sparse image
  has large CHUNK_TYPE_FILL chunks

Signed-off-by: Steve Rae 
---

 common/image-sparse.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/common/image-sparse.c b/common/image-sparse.c
index 9632c6f..ddf5772 100644
--- a/common/image-sparse.c
+++ b/common/image-sparse.c
@@ -1,4 +1,3 @@
-
 /*
  * Copyright (c) 2009, Google Inc.
  * All rights reserved.
@@ -46,6 +45,10 @@
 
 #include 
 
+#ifndef CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE
+#define CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE (1024 * 512)
+#endif
+
 void write_sparse_image(
struct sparse_storage *info, const char *part_name,
void *data, unsigned sz)
@@ -62,7 +65,11 @@ void write_sparse_image(
sparse_header_t *sparse_header;
chunk_header_t *chunk_header;
uint32_t total_blocks = 0;
+   int fill_buf_num_blks;
int i;
+   int j;
+
+   fill_buf_num_blks = CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE / info->blksz;
 
/* Read and skip over sparse image header */
sparse_header = (sparse_header_t *)data;
@@ -169,8 +176,9 @@ void write_sparse_image(
 
fill_buf = (uint32_t *)
   memalign(ARCH_DMA_MINALIGN,
-   ROUNDUP(info->blksz,
-   ARCH_DMA_MINALIGN));
+   ROUNDUP(
+   info->blksz * fill_buf_num_blks,
+   ARCH_DMA_MINALIGN));
if (!fill_buf) {
fastboot_fail(
"Malloc failed for: CHUNK_TYPE_FILL");
@@ -180,7 +188,10 @@ void write_sparse_image(
fill_val = *(uint32_t *)data;
data = (char *)data + sizeof(uint32_t);
 
-   for (i = 0; i < (info->blksz / sizeof(fill_val)); i++)
+   for (i = 0;
+i < (info->blksz * fill_buf_num_blks /
+ sizeof(fill_val));
+i++)
fill_buf[i] = fill_val;
 
if (blk + blkcnt > info->start + info->size) {
@@ -192,18 +203,24 @@ void write_sparse_image(
return;
}
 
-   for (i = 0; i < blkcnt; i++) {
-   blks = info->write(info, blk, 1, fill_buf);
-   /* blks might be > 1 (eg. NAND bad-blocks) */
-   if (blks < 1) {
-   printf("%s: %s, block # " LBAFU "\n",
-  __func__, "Write failed", blk);
+   for (i = 0; i < blkcnt;) {
+   j = blkcnt - i;
+   if (j > fill_buf_num_blks)
+   j = fill_buf_num_blks;
+   blks = info->write(info, blk, j, fill_buf);
+   /* blks might be > j (eg. NAND bad-blocks) */
+   if (blks < j) {
+   printf("%s: %s " LBAFU " [%d]\n",
+  __func__,
+  "Write failed, block #",
+  blk, j);
fastboot_fail(
  "flash write failure");
free(fill_buf);
return;
}
blk += blks;
+   i += j;
}
bytes_written += blkcnt * info->blksz;
total_blocks += chunk_data_sz / sparse_header->blk_sz;
-- 
1.8.5

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

[U-Boot] [PATCH 2/5] fastboot: sparse: resync common/image-sparse.c (part 1)

[Steve Rae]

This file originally came from upstream code.

While retaining the storage abstraction feature, this is the first
set of the changes required to resync with the
  cmd_flash_mmc_sparse_img()
in the file
  aboot.c
from
  
https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1

Signed-off-by: Steve Rae 
---

 common/fb_mmc.c|  32 ++--
 common/fb_nand.c   |  52 +++---
 common/image-sparse.c  | 449 +
 include/image-sparse.h |  25 +--
 4 files changed, 208 insertions(+), 350 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 9e53adb..3dad0ea 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -7,12 +7,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -48,22 +46,13 @@ static int part_get_info_efi_by_name_or_alias(struct 
blk_desc *dev_desc,
return ret;
 }
 
-
-static int fb_mmc_sparse_write(struct sparse_storage *storage,
-  void *priv,
-  unsigned int offset,
-  unsigned int size,
-  char *data)
+static lbaint_t fb_mmc_sparse_write(struct sparse_storage *info,
+   lbaint_t blk, lbaint_t blkcnt, const void *buffer)
 {
-   struct fb_mmc_sparse *sparse = priv;
+   struct fb_mmc_sparse *sparse = info->priv;
struct blk_desc *dev_desc = sparse->dev_desc;
-   int ret;
-
-   ret = blk_dwrite(dev_desc, offset, size, data);
-   if (!ret)
-   return -EIO;
 
-   return ret;
+   return blk_dwrite(dev_desc, blk, blkcnt, buffer);
 }
 
 static void write_raw_image(struct blk_desc *dev_desc, disk_partition_t *info,
@@ -139,26 +128,25 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
 
if (is_sparse_image(download_buffer)) {
struct fb_mmc_sparse sparse_priv;
-   sparse_storage_t sparse;
+   struct sparse_storage sparse;
 
sparse_priv.dev_desc = dev_desc;
 
-   sparse.block_sz = info.blksz;
+   sparse.blksz = info.blksz;
sparse.start = info.start;
sparse.size = info.size;
-   sparse.name = cmd;
sparse.write = fb_mmc_sparse_write;
 
printf("Flashing sparse image at offset " LBAFU "\n",
-  info.start);
+  sparse.start);
 
-   store_sparse_image(, _priv, download_buffer);
+   sparse.priv = _priv;
+   write_sparse_image(, cmd, download_buffer,
+  download_bytes, response_str);
} else {
write_raw_image(dev_desc, , cmd, download_buffer,
download_bytes);
}
-
-   fastboot_okay(response_str, "");
 }
 
 void fb_mmc_erase(const char *cmd, char *response)
diff --git a/common/fb_nand.c b/common/fb_nand.c
index 896ed6d..6307bfc 100644
--- a/common/fb_nand.c
+++ b/common/fb_nand.c
@@ -10,7 +10,6 @@
 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -105,30 +104,32 @@ static int _fb_nand_write(nand_info_t *nand, struct 
part_info *part,
   buffer, flags);
 }
 
-static int fb_nand_sparse_write(struct sparse_storage *storage,
-   void *priv,
-   unsigned int offset,
-   unsigned int size,
-   char *data)
+static lbaint_t fb_nand_sparse_write(struct sparse_storage *info,
+   lbaint_t blk, lbaint_t blkcnt, const void *buffer)
 {
-   struct fb_nand_sparse *sparse = priv;
+   struct fb_nand_sparse *sparse = info->priv;
size_t written;
int ret;
 
-   ret = _fb_nand_write(sparse->nand, sparse->part, data,
-offset * storage->block_sz,
-size * storage->block_sz, );
+   ret = _fb_nand_write(sparse->nand, sparse->part, (void *)buffer,
+blk * info->blksz,
+blkcnt * info->blksz, );
if (ret < 0) {
printf("Failed to write sparse chunk\n");
return ret;
}
 
-   return written / storage->block_sz;
+/* TODO - verify that the value "written" includes the "bad-blocks" ... */
+
+   /*
+* the return value must be 'blkcnt' ("good-blocks") plus the
+* number of "bad-blocks" encountered within this space...
+*/
+   return written / info->blksz;
 }
 
-void fb_nand_flash_write(const char *partname,
-void *download_buffer, unsigned int download_bytes,
-char *response)
+void fb_nand_flash_write(const char *cmd, void *download_buffer,
+unsigned int download_bytes, char *response)
 {
  

[U-Boot] [PATCH 1/5] fastboot: sparse: remove session-id logic

[Steve Rae]

This "session-id" alogrithm is not required, and currently corrupts
the stored image whenever more the one "session" is required.

Signed-off-by: Steve Rae 
---
for more information, see the thread starting at [1]
[1] http://lists.denx.de/pipermail/u-boot/2016-April/251889.html

 common/fb_mmc.c |  8 +++-
 common/fb_nand.c|  4 ++--
 common/image-sparse.c   | 21 -
 drivers/usb/gadget/f_fastboot.c | 16 ++--
 include/fb_mmc.h|  5 ++---
 include/fb_nand.h   |  5 ++---
 include/image-sparse.h  |  2 +-
 7 files changed, 16 insertions(+), 45 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index e3abcc8..9e53adb 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -97,9 +97,8 @@ static void write_raw_image(struct blk_desc *dev_desc, 
disk_partition_t *info,
fastboot_okay(response_str, "");
 }
 
-void fb_mmc_flash_write(const char *cmd, unsigned int session_id,
-   void *download_buffer, unsigned int download_bytes,
-   char *response)
+void fb_mmc_flash_write(const char *cmd, void *download_buffer,
+   unsigned int download_bytes, char *response)
 {
struct blk_desc *dev_desc;
disk_partition_t info;
@@ -153,8 +152,7 @@ void fb_mmc_flash_write(const char *cmd, unsigned int 
session_id,
printf("Flashing sparse image at offset " LBAFU "\n",
   info.start);
 
-   store_sparse_image(, _priv, session_id,
-  download_buffer);
+   store_sparse_image(, _priv, download_buffer);
} else {
write_raw_image(dev_desc, , cmd, download_buffer,
download_bytes);
diff --git a/common/fb_nand.c b/common/fb_nand.c
index 9ca8602..896ed6d 100644
--- a/common/fb_nand.c
+++ b/common/fb_nand.c
@@ -126,7 +126,7 @@ static int fb_nand_sparse_write(struct sparse_storage 
*storage,
return written / storage->block_sz;
 }
 
-void fb_nand_flash_write(const char *partname, unsigned int session_id,
+void fb_nand_flash_write(const char *partname,
 void *download_buffer, unsigned int download_bytes,
 char *response)
 {
@@ -161,7 +161,7 @@ void fb_nand_flash_write(const char *partname, unsigned int 
session_id,
sparse.name = part->name;
sparse.write = fb_nand_sparse_write;
 
-   ret = store_sparse_image(, _priv, session_id,
+   ret = store_sparse_image(, _priv,
 download_buffer);
} else {
printf("Flashing raw image at offset 0x%llx\n",
diff --git a/common/image-sparse.c b/common/image-sparse.c
index 2bf737b..893c68b 100644
--- a/common/image-sparse.c
+++ b/common/image-sparse.c
@@ -52,8 +52,6 @@ typedef struct sparse_buffer {
u16 type;
 } sparse_buffer_t;
 
-static uint32_t last_offset;
-
 static unsigned int sparse_get_chunk_data_size(sparse_header_t *sparse,
   chunk_header_t *chunk)
 {
@@ -267,8 +265,8 @@ static void sparse_put_data_buffer(sparse_buffer_t *buffer)
free(buffer);
 }
 
-int store_sparse_image(sparse_storage_t *storage, void *storage_priv,
-  unsigned int session_id, void *data)
+int store_sparse_image(sparse_storage_t *storage,
+  void *storage_priv, void *data)
 {
unsigned int chunk, offset;
sparse_header_t *sparse_header;
@@ -303,19 +301,10 @@ int store_sparse_image(sparse_storage_t *storage, void 
*storage_priv,
return -EINVAL;
}
 
-   /*
-* If it's a new flashing session, start at the beginning of
-* the partition. If not, then simply resume where we were.
-*/
-   if (session_id > 0)
-   start = last_offset;
-   else
-   start = storage->start;
-
-   printf("Flashing sparse image on partition %s at offset 0x%x (ID: 
%d)\n",
-  storage->name, start * storage->block_sz, session_id);
+   puts("Flashing Sparse Image\n");
 
/* Start processing chunks */
+   start = storage->start;
for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
uint32_t blkcnt;
 
@@ -390,7 +379,5 @@ int store_sparse_image(sparse_storage_t *storage, void 
*storage_priv,
return -EIO;
}
 
-   last_offset = start + total_blocks;
-
return 0;
 }
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 28b244a..ddf989c 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -59,7 +59,6 @@ static inline struct f_fastboot *func_to_fastboot(struct 
usb_function *f)
 }
 
 static struct f_fastboot *fastboot_func;
-static unsigned int fastboot_flash_session_id;
 static unsigned 

[U-Boot] [PATCH 3/5] fastboot: sparse: resync common/image-sparse.c (part 2)

[Steve Rae]

- update fastboot_okay() and fastboot_fail()

This file originally came from upstream code.

While retaining the storage abstraction feature, this is the second
set of the changes required to resync with the
  cmd_flash_mmc_sparse_img()
in the file
  aboot.c
from
  
https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1

Signed-off-by: Steve Rae 
---

 common/fb_mmc.c | 40 
 common/fb_nand.c| 38 +++---
 common/image-sparse.c   | 26 +-
 drivers/usb/gadget/f_fastboot.c | 31 +++
 include/fastboot.h  |  4 ++--
 include/fb_mmc.h|  4 ++--
 include/fb_nand.h   |  4 ++--
 include/image-sparse.h  |  2 +-
 8 files changed, 70 insertions(+), 79 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 3dad0ea..6bafbc6 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -18,8 +18,6 @@
 #define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
 #endif
 
-static char *response_str;
-
 struct fb_mmc_sparse {
struct blk_desc *dev_desc;
 };
@@ -68,7 +66,7 @@ static void write_raw_image(struct blk_desc *dev_desc, 
disk_partition_t *info,
 
if (blkcnt > info->size) {
error("too large for partition: '%s'\n", part_name);
-   fastboot_fail(response_str, "too large for partition");
+   fastboot_fail("too large for partition");
return;
}
 
@@ -77,28 +75,25 @@ static void write_raw_image(struct blk_desc *dev_desc, 
disk_partition_t *info,
blks = blk_dwrite(dev_desc, info->start, blkcnt, buffer);
if (blks != blkcnt) {
error("failed writing to device %d\n", dev_desc->devnum);
-   fastboot_fail(response_str, "failed writing to device");
+   fastboot_fail("failed writing to device");
return;
}
 
printf(" wrote " LBAFU " bytes to '%s'\n", blkcnt * info->blksz,
   part_name);
-   fastboot_okay(response_str, "");
+   fastboot_okay("");
 }
 
 void fb_mmc_flash_write(const char *cmd, void *download_buffer,
-   unsigned int download_bytes, char *response)
+   unsigned int download_bytes)
 {
struct blk_desc *dev_desc;
disk_partition_t info;
 
-   /* initialize the response buffer */
-   response_str = response;
-
dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
if (!dev_desc || dev_desc->type == DEV_TYPE_UNKNOWN) {
error("invalid mmc device\n");
-   fastboot_fail(response_str, "invalid mmc device");
+   fastboot_fail("invalid mmc device");
return;
}
 
@@ -108,21 +103,21 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
if (is_valid_gpt_buf(dev_desc, download_buffer)) {
printf("%s: invalid GPT - refusing to write to flash\n",
   __func__);
-   fastboot_fail(response_str, "invalid GPT partition");
+   fastboot_fail("invalid GPT partition");
return;
}
if (write_mbr_and_gpt_partitions(dev_desc, download_buffer)) {
printf("%s: writing GPT partitions failed\n", __func__);
-   fastboot_fail(response_str,
+   fastboot_fail(
  "writing GPT partitions failed");
return;
}
printf(" success\n");
-   fastboot_okay(response_str, "");
+   fastboot_okay("");
return;
} else if (part_get_info_efi_by_name_or_alias(dev_desc, cmd, )) {
error("cannot find partition: '%s'\n", cmd);
-   fastboot_fail(response_str, "cannot find partition");
+   fastboot_fail("cannot find partition");
return;
}
 
@@ -142,14 +137,14 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
 
sparse.priv = _priv;
write_sparse_image(, cmd, download_buffer,
-  download_bytes, response_str);
+  download_bytes);
} else {
write_raw_image(dev_desc, , cmd, download_buffer,
download_bytes);
}
 }
 
-void fb_mmc_erase(const char *cmd, char *response)
+void fb_mmc_erase(const char *cmd)
 {
int ret;
struct blk_desc *dev_desc;
@@ -159,24 +154,21 @@ void fb_mmc_erase(const char *cmd, char *response)
 
if (mmc == NULL) {
error("invalid mmc device");
-   fastboot_fail(response_str, "invalid mmc device");
+   

Re: [U-Boot] [PATCH 1/3] SPL: Let spl_parse_image_header() return value

[Fabio Estevam]

On Fri, May 20, 2016 at 6:56 PM, Nishanth Menon  wrote:
> Marek,
>
> Just forwarding report from Suman (in CC) reporting that as of u-boot
> master 4b6e1fd "Merge git://git.denx.de/u-boot-dm"
> It looks like BeagleBoard-X15, DRA7 platforms fail due to this commit.
> Fail signature looks like the following:
> ...
> DRA752 ES2.0
> Trying to boot from MMC1
> reading args
> spl_load_image_fat_os: error reading image args, err - -1
> reading u-boot.img
> spl_load_image_fat: error reading image u-boot.img, err - 0
> Failed to mount ext2 filesystem...
> spl_load_image_ext_os: ext4fs mount err - 0
> Failed to mount ext2 filesystem...
> spl_load_image_ext: ext4fs mount err - 0

Looks like this can be fixed with this patch from Marek:
https://patchwork.ozlabs.org/patch/624267/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [GIT PULL] u-boot-mips/next

[Daniel Schwierzeck]

Hi Tom,

please pull the first batch of MIPS updates, thanks.


The following changes since commit 4b6e1fda107e5244e80ebc41865650ac2873dc88:

  Merge git://git.denx.de/u-boot-dm (2016-05-17 13:58:27 -0400)

are available in the git repository at:

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

for you to fetch changes up to 40ba13c98627055465709acd67872e381b42f928:

  malta: Support MIPS32r6 configurations (2016-05-21 01:36:39 +0200)


Marek Vasut (10):
  mips: Fix compiler warning in cpu.c
  mips: Add MIPS 74Kc tune
  mips: ath79: Fix ar71xx_regs.h indent
  mips: ath79: Fix compiler warning on const assignment
  mips: ath79: dts: Add generic-ehci node
  mips: ath79: Add support for ungating USB on ar933x and ar934x
  mips: ath79: dts: Add ethernet MAC nodes for ar933x
  mips: ath79: Add support for ungating ethernet on ar933x and ar934x
  mips: ath79: Add AR934x support
  mips: ath79: Add support for TPLink WDR4300

Paul Burton (5):
  MIPS: Use unchecked immediate addition/subtraction
  MIPS: Simplify CONFIG_SYS_CPU values
  MIPS: Support for targetting MIPSr6
  malta: Remove ".set mips32" directive
  malta: Support MIPS32r6 configurations

Purna Chandra Mandal (2):
  flash: add device ID for Microchip PIC32 internal flash.
  drivers: mtd: add Microchip PIC32 internal non-CFI flash driver.

Stanislav Galabov (4):
  Properly calculate ATA_SECTORWORDS, using a fixed-size integer, so it 
works for both 32-bit and 64-bit targets
  Use CONFIG_IDE_SWAP_IO when running on big-endian MIPS (32 or 64-bit) in 
QEMU so that IDE transfers work properly
  Fix FreeBSD loader API so that it works on both 32-bit and 64-bit targets.
  Add support for 64-bit MIPS to examples/standalone

Tim Chick (1):
  mips: Report reloc information in bdinfo

Wills Wang (13):
  mips: add base support for QCA/Atheros ath79 SOCs
  mips: ath79: add support for AR933x SOCs
  mips: ath79: add support for QCA953x SOCs
  drivers: pinctrl: Add simple pinctrl driver for Qualcomm/Atheros ar933x.
  drivers: pinctrl: Add simple pinctrl driver for Qualcomm/Atheros qca953x.
  drivers: serial: add serial driver for ar933x SOC
  drivers: spi: add spi support for QCA/Atheros ath79 SOCs
  mips: ath79: add AP121 reference board
  mips: ath79: add AP143 reference board
  ath79: spi: Remove the explicit pinctrl setting
  ar933x: serial: Remove the explicit pinctrl setting
  ath79: ar933x: use BIT macro for bit shift operation
  ath79: add readonly attribute for ath79_soc_desc

 api/api.c   |   58 +++---
 arch/mips/Kconfig   |   48 -
 arch/mips/Makefile  |4 +
 arch/mips/cpu/cpu.c |1 -
 arch/mips/cpu/start.S   |   22 +-
 arch/mips/dts/Makefile  |3 +
 arch/mips/dts/ap121.dts |   43 
 arch/mips/dts/ap143.dts |   43 
 arch/mips/dts/ar933x.dtsi   |  115 +++
 arch/mips/dts/ar934x.dtsi   |  112 ++
 arch/mips/dts/qca953x.dtsi  |   84 
 arch/mips/dts/tplink_wdr4300.dts|   53 +
 arch/mips/include/asm/global_data.h |6 +
 arch/mips/lib/cache_init.S  |2 +-
 arch/mips/mach-ath79/Kconfig|   55 +
 arch/mips/mach-ath79/Makefile   |   11 +
 arch/mips/mach-ath79/ar933x/Makefile|7 +
 arch/mips/mach-ath79/ar933x/clk.c   |   89 
 arch/mips/mach-ath79/ar933x/ddr.c   |  333 
++
 arch/mips/mach-ath79/ar933x/lowlevel_init.S |  280 
+
 arch/mips/mach-ath79/ar934x/Makefile|7 +
 arch/mips/mach-ath79/ar934x/clk.c   |  334 
++
 arch/mips/mach-ath79/ar934x/cpu.c   |   10 +
 arch/mips/mach-ath79/ar934x/ddr.c   |  163 +++
 arch/mips/mach-ath79/cpu.c  |  142 +
 arch/mips/mach-ath79/dram.c |   16 ++
 arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 1263 
+
 arch/mips/mach-ath79/include/mach/ath79.h   |  149 ++
 arch/mips/mach-ath79/include/mach/ddr.h |   13 ++
 arch/mips/mach-ath79/include/mach/reset.h   |   14 ++
 arch/mips/mach-ath79/qca953x/Makefile   |7 +
 arch/mips/mach-ath79/qca953x/clk.c  |  111 ++
 arch/mips/mach-ath79/qca953x/ddr.c

Re: [U-Boot] [U-Boot,2/4] board: ti: am57xx: Fix USB configuration

[Tom Rini]

On Fri, May 13, 2016 at 03:17:51PM +0300, Roger Quadros wrote:

> This fixes build.
> 
> Signed-off-by: Roger Quadros 
> ---
>  include/configs/am57xx_evm.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index 32d7d4d..939057c 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -63,6 +63,7 @@
>  #define CONFIG_SUPPORT_EMMC_BOOT
>  
>  /* USB xHCI HOST */
> +#define CONFIG_USB_DWC3
>  #define CONFIG_USB_HOST
>  #define CONFIG_USB_XHCI_DWC3
>  #define CONFIG_USB_XHCI
> @@ -72,6 +73,8 @@
>  
>  #define CONFIG_OMAP_USB_PHY
>  #define CONFIG_OMAP_USB3PHY1_HOST
> +#define CONFIG_USB_DWC3_PHY_OMAP
> +#define CONFIG_USB_DWC3_OMAP

This needs to be done in the defconfig.  And you're leaving other boards
broken: pcm051_rev1 and others, please do at least an am33xx build,
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 1/3] SPL: Let spl_parse_image_header() return value

[Nishanth Menon]

Marek,

Just forwarding report from Suman (in CC) reporting that as of u-boot
master 4b6e1fd "Merge git://git.denx.de/u-boot-dm"
It looks like BeagleBoard-X15, DRA7 platforms fail due to this commit.
Fail signature looks like the following:
...
DRA752 ES2.0
Trying to boot from MMC1
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
spl_load_image_fat: error reading image u-boot.img, err - 0
Failed to mount ext2 filesystem...
spl_load_image_ext_os: ext4fs mount err - 0
Failed to mount ext2 filesystem...
spl_load_image_ext: ext4fs mount err - 0

...

On Thu, Apr 28, 2016 at 5:44 PM, Marek Vasut  wrote:
> Allow the spl_parse_image_header() to return value. This is convenient
> for controlling the SPL boot flow if the loaded image is corrupted.
>
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Tom Rini 
> ---
>  common/spl/spl.c   |  3 ++-
>  common/spl/spl_ext.c   |  6 +-
>  common/spl/spl_fat.c   |  4 +++-
>  common/spl/spl_mmc.c   |  6 +-
>  common/spl/spl_nand.c  |  9 +++--
>  common/spl/spl_net.c   |  4 +---
>  common/spl/spl_nor.c   |  9 +++--
>  common/spl/spl_onenand.c   |  5 -
>  common/spl/spl_ymodem.c|  7 +--
>  drivers/mtd/spi/spi_spl_load.c | 10 --
>  include/spl.h  |  2 +-
>  11 files changed, 48 insertions(+), 17 deletions(-)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 82e7f58..7259619 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -73,7 +73,7 @@ void spl_set_header_raw_uboot(void)
> spl_image.name = "U-Boot";
>  }
>
> -void spl_parse_image_header(const struct image_header *header)
> +int spl_parse_image_header(const struct image_header *header)
>  {
> u32 header_size = sizeof(struct image_header);
>
> @@ -118,6 +118,7 @@ void spl_parse_image_header(const struct image_header 
> *header)
> spl_set_header_raw_uboot();
>  #endif
> }
> +   return 0;
>  }
>
>  __weak void __noreturn jump_to_image_no_args(struct spl_image_info 
> *spl_image)
> diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
> index b77dbf4..ade5496 100644
> --- a/common/spl/spl_ext.c
> +++ b/common/spl/spl_ext.c
> @@ -48,7 +48,11 @@ int spl_load_image_ext(struct blk_desc *block_dev,
> goto end;
> }
>
> -   spl_parse_image_header(header);
> +   err = spl_parse_image_header(header);
> +   if (err < 0) {
> +   puts("spl: ext4fs_read failed\n");
> +   goto end;
> +   }
>
> err = ext4fs_read((char *)spl_image.load_addr, filelen, );
>
> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
> index d761b26..338ea2f 100644
> --- a/common/spl/spl_fat.c
> +++ b/common/spl/spl_fat.c
> @@ -57,7 +57,9 @@ int spl_load_image_fat(struct blk_desc *block_dev,
> if (err <= 0)
> goto end;
>
> -   spl_parse_image_header(header);
> +   err = spl_parse_image_header(header);
> +   if (err <= 0)
> +   goto end;
>
> err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 8d588d1..360c754 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -23,8 +23,12 @@ static int mmc_load_legacy(struct mmc *mmc, ulong sector,
>  {
> u32 image_size_sectors;
> unsigned long count;
> +   int ret;
> +
> +   ret = spl_parse_image_header(header);
> +   if (ret)
> +   return ret;
>
> -   spl_parse_image_header(header);
> /* convert size to sectors - round up */
> image_size_sectors = (spl_image.size + mmc->read_bl_len - 1) /
>  mmc->read_bl_len;
> diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> index 79388ff..bbd9546 100644
> --- a/common/spl/spl_nand.c
> +++ b/common/spl/spl_nand.c
> @@ -32,7 +32,10 @@ static int spl_nand_load_element(int offset, struct 
> image_header *header)
> if (err)
> return err;
>
> -   spl_parse_image_header(header);
> +   err = spl_parse_image_header(header);
> +   if (err)
> +   return err;
> +
> return nand_spl_load_image(offset, spl_image.size,
>(void *)(unsigned 
> long)spl_image.load_addr);
>  }
> @@ -77,7 +80,9 @@ int spl_nand_load_image(void)
> /* load linux */
> nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
> sizeof(*header), (void *)header);
> -   spl_parse_image_header(header);
> +   err = spl_parse_image_header(header);
> +   if (err)
> +   return err;
> if (header->ih_os == IH_OS_LINUX) {
>   

Re: [U-Boot] [PATCH] ts4800: add CONFIG_SYS_FSL_ERRATUM_ESDHC_A001

[Fabio Estevam]

Hi Sebastien,

On Fri, May 20, 2016 at 5:13 PM, Sebastien Bourdelin
 wrote:

> This issue happen with the SD card, i currently didn't found the time to
> try with eMMC.

Ok, we also boot from SD card on the mx51evk and never observed this
issue there.

What is the MX51 silicon version you have on your board?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] arm: Introduce setjmp/longjmp

[Alexander Graf]

To quit an EFI application we will need logic to jump to the caller
of a function without returning from the function we called into,
so we need setjmp/longjmp functionality.

This patch introduces a trivial implementation of these that I
verified works on armv7, thumb2 and aarch64.

Signed-off-by: Alexander Graf 
---
 arch/arm/include/asm/setjmp.h | 99 +++
 1 file changed, 99 insertions(+)
 create mode 100644 arch/arm/include/asm/setjmp.h

diff --git a/arch/arm/include/asm/setjmp.h b/arch/arm/include/asm/setjmp.h
new file mode 100644
index 000..b8b85b7
--- /dev/null
+++ b/arch/arm/include/asm/setjmp.h
@@ -0,0 +1,99 @@
+/*
+ * (C) Copyright 2016
+ * Alexander Graf 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SETJMP_H_
+#define _SETJMP_H_ 1
+
+struct jmp_buf_data {
+   ulong target;
+   ulong regs[5];
+};
+
+typedef struct jmp_buf_data jmp_buf[1];
+
+static inline int setjmp(jmp_buf jmp)
+{
+   long r = 0;
+
+#ifdef CONFIG_ARM64
+   asm volatile(
+   "adr x1, jmp_target\n"
+   "str x1, %1\n"
+   "stp x26, x27, %2\n"
+   "stp x28, x29, %3\n"
+   "mov x1, sp\n"
+   "str x1, %4\n"
+   "b 2f\n"
+   "jmp_target: "
+   "mov %0, #1\n"
+   "2:\n"
+   : "+r" (r), "=m" (jmp->target),
+ "=m" (jmp->regs[0]), "=m" (jmp->regs[2]),
+ "=m" (jmp->regs[4])
+   :
+   : "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+ "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
+ "x16", "x17", "x18", "x19", "x20", "x21", "x22",
+ "x23", "x24", "x25", /* x26, x27, x28, x29, sp */
+ "x30", "cc", "memory");
+#else
+   asm volatile(
+#ifdef CONFIG_SYS_THUMB_BUILD
+   "adr r0, jmp_target + 1\n"
+#else
+   "adr r0, jmp_target\n"
+#endif
+   "mov r1, %1\n"
+   "mov r2, sp\n"
+   "stm r1, {r0, r2, r4, r5, r6, r7}\n"
+   "b 2f\n"
+   "jmp_target: "
+   "mov %0, #1\n"
+   "2:\n"
+   : "+l" (r)
+   : "l" (>target)
+   : "r0", "r1", "r2", "r3", /* "r4", "r5", "r6", "r7", */
+ "r8", "r9", "r10", "r11", /* sp, */ "ip", "lr",
+ "cc", "memory");
+#endif
+
+printf("%s:%d target=%#lx\n", __func__, __LINE__, jmp->target);
+
+   return r;
+}
+
+static inline __noreturn void longjmp(jmp_buf jmp)
+{
+#ifdef CONFIG_ARM64
+   asm volatile(
+   "ldr x0, %0\n"
+   "ldr x1, %3\n"
+   "mov sp, x1\n"
+   "ldp x26, x27, %1\n"
+   "ldp x28, x25, %2\n"
+   "mov x29, x25\n"
+   "br x0\n"
+   :
+   : "m" (jmp->target), "m" (jmp->regs[0]), "m" (jmp->regs[2]),
+ "m" (jmp->regs[4])
+   : "x0", "x1", "x25", "x26", "x27", "x28");
+#else
+   asm volatile(
+   "mov r1, %0\n"
+   "ldm r1, {r0, r2, r4, r5, r6, r7}\n"
+   "mov sp, r2\n"
+   "bx r0\n"
+   :
+   : "l" (>target)
+   : "r1");
+#endif
+
+   while (1) { }
+}
+
+
+#endif /* _SETJMP_H_ */
-- 
1.8.5.6

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

[U-Boot] [PATCH 2/2] efi_loader: Add exit support

[Alexander Graf]

Some times you may want to exit an EFI payload again, for example
to default boot into a PXE installation and decide that you would
rather want to boot from the local disk instead.

This patch adds exit functionality to the EFI implementation, allowing
EFI payloads to exit.

Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c |  6 ++
 include/efi_api.h | 10 ++
 lib/efi_loader/efi_boottime.c | 21 -
 3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index d3a2331..2a62dce 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -209,6 +209,12 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
 #ifdef DEBUG_EFI
printf("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
 #endif
+
+   if (setjmp(_image_info.exit_jmp)) {
+   efi_status_t status = loaded_image_info.exit_status;
+   return status == EFI_SUCCESS ? 0 : -EINVAL;
+   }
+
return entry(_image_info, );
 }
 
diff --git a/include/efi_api.h b/include/efi_api.h
index 20035d7..f572b88 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -17,6 +17,10 @@
 
 #include 
 
+#ifdef CONFIG_EFI_LOADER
+#include 
+#endif
+
 /* Types and defines for EFI CreateEvent */
 enum efi_event_type {
EFI_TIMER_STOP = 0,
@@ -239,6 +243,12 @@ struct efi_loaded_image {
unsigned int image_code_type;
unsigned int image_data_type;
unsigned long unload;
+
+   /* Below are efi loader private fields */
+#ifdef CONFIG_EFI_LOADER
+   efi_status_t exit_status;
+   struct jmp_buf_data exit_jmp;
+#endif
 };
 
 #define DEVICE_PATH_GUID \
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 9daca50..15a1b90 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -458,19 +458,30 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
efi_is_direct_boot = false;
 
/* call the image! */
+   if (setjmp(>exit_jmp)) {
+   /* We returned from the child image */
+   return EFI_EXIT(info->exit_status);
+   }
+
entry(image_handle, );
 
/* Should usually never get here */
return EFI_EXIT(EFI_SUCCESS);
 }
 
-static efi_status_t EFIAPI efi_exit(void *image_handle, long exit_status,
-   unsigned long exit_data_size,
-   uint16_t *exit_data)
+static efi_status_t EFIAPI efi_exit(efi_handle_t image_handle,
+   efi_status_t exit_status, unsigned long exit_data_size,
+   int16_t *exit_data)
 {
+   struct efi_loaded_image *loaded_image_info = (void*)image_handle;
+
EFI_ENTRY("%p, %ld, %ld, %p", image_handle, exit_status,
  exit_data_size, exit_data);
-   return EFI_EXIT(efi_unsupported(__func__));
+
+   loaded_image_info->exit_status = exit_status;
+   longjmp(_image_info->exit_jmp);
+
+   panic("EFI application exited");
 }
 
 static struct efi_object *efi_search_obj(void *handle)
@@ -746,7 +757,7 @@ static const struct efi_boot_services efi_boot_services = {
.install_configuration_table = efi_install_configuration_table,
.load_image = efi_load_image,
.start_image = efi_start_image,
-   .exit = (void*)efi_exit,
+   .exit = efi_exit,
.unload_image = efi_unload_image,
.exit_boot_services = efi_exit_boot_services,
.get_next_monotonic_count = efi_get_next_monotonic_count,
-- 
1.8.5.6

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

[U-Boot] [PATCH 0/2] efi_loader: Implement exit

[Alexander Graf]

In some environments it makes sense to try different boot paths in order,
for example boot from network, then determine that network boot is not for
you based on a configuration file, then continue descending the list to
SD boot.

The usual way this works in an EFI world is to just exit th EFI payload.
So far we didn't implement the exit call though. This patch set does it.

Alexander Graf (2):
  arm: Introduce setjmp/longjmp
  efi_loader: Add exit support

 arch/arm/include/asm/setjmp.h | 99 +++
 cmd/bootefi.c |  6 +++
 include/efi_api.h | 10 +
 lib/efi_loader/efi_boottime.c | 21 ++---
 4 files changed, 131 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/include/asm/setjmp.h

-- 
1.8.5.6

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

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

[Tom Rini]

On Fri, May 20, 2016 at 09:12:57PM +0200, Karsten Merker wrote:
> On Fri, May 20, 2016 at 01:55:12PM -0400, Tom Rini wrote:
> > On Fri, May 20, 2016 at 05:53:34PM +0200, Hans de Goede wrote:
> 
> > > >>I've been happy when I can use gcc-6.x for all the free cost savings but
> > > >>current Debian tools (and current Fedora, and current any other big
> > > >>distro) toolchains matter too.  You can also see the size growth (but
> > > >>not to fatal proportions) on CHIP or warp7 or MSI_Primo73
> > > >
> > > >OK thanks for the pointers. I will take a look. I spent quite a bit of
> > > >time on this (it was pretty awful at the start!) but obviously I
> > > >haven't quite nailed it.
> > > 
> > > So I've run some quick tests on F-24 which is at gcc-6 (and it is unlikely
> > > u-boot v2015.07 will be coming to older Fedora versions) and I got the
> > > following u-boot-spl.bin increase for Cubietruck:
> > > 
> > > v2015.05: 19696
> > > master:   19932
> > > 
> > > So if others are seeing some more extreme increase then that is probably
> > > the good old tool-chain problem with not eliminating unused strings.
> > > 
> > > The way to work around this is look at the linker.map, find out which
> > > object files have grown considerably on master, and check if the patches
> > > in one of those files perhaps has caused us to use some const string
> > > in there, where before we were not using any. The problem with the 
> > > toolchain
> > > bug is that using a single const string in a .o file will make it link
> > > in ALL const strings in the .o file, even the 99 other unused ones.
> > > 
> > > In the past I've hacked around that in e.g. the malloc code, but TBH,
> > > now that the upstream toolchain is fixed I'm not sure if we should
> > > bother with kludging around this.
> > 
> > I am a fan of gcc-6.x (as it saves us space on so many platforms), but
> > with your sunxi hat on, rather than Fedora guy hat on, do you think
> > telling people to just grab gcc-6.x is an OK solution for users?
> 
> If I may chime in with my Debian hat on:
> 
> Debian/unstable has gcc-6.1.1, so for the Debian developers and
> "bleeding edge" users there is no problem.  For users of
> Debian/stable things don't look that good as there probably won't
> be a backport of gcc-6 for Debian/stable and the other "usual"
> source for a comparatively current crosscompiler - crosstool-ng -
> also doesn't provide support for gcc-6 builds (not even in git
> head).
> 
> With Ubuntu the situation is similar: the current (and just
> freshly released) Ubuntu 16.04 doesn't ship gcc-6; the first
> Ubuntu release to ship gcc-6 will be 16.10.
> 
> So the question is: does u-boot mainly address active developers
> or shall it also be easily buildable for end-users.  For the
> former, requiring gcc-6 wouldn't be a problem, but for the
> latter, it most probably would be as things are now.

So, I think we agree then that yes, we need to care about gcc-5.x,
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 03/13] imx-common: use simpler runtime cpu dection macros

[Benoît Thébaudeau]

Hi Peng,

On Fri, May 20, 2016 at 10:41 AM, Peng Fan  wrote:
> On Fri, May 20, 2016 at 01:02:10AM +0200, Benoît Thébaudeau wrote:
>>On Wed, May 18, 2016 at 9:53 AM, Peng Fan  wrote:
>>> Use simpler runtime cpu dection macros.
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: Stefano Babic 
>>> Cc: Ulises Cardenas 
>>> Cc: Bhuvanchandra DV 
>>> Cc: "Benoît Thébaudeau" 
>>> ---
>>>  arch/arm/imx-common/hab.c  | 43 
>>> +-
>>>  arch/arm/imx-common/init.c |  5 ++---
>>>  arch/arm/imx-common/iomux-v3.c |  2 +-
>>>  arch/arm/imx-common/sata.c |  2 +-
>>>  arch/arm/imx-common/timer.c| 11 +++
>>>  5 files changed, 20 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/arch/arm/imx-common/hab.c b/arch/arm/imx-common/hab.c
>>> index 8bbcc22..a980688 100644
>>> --- a/arch/arm/imx-common/hab.c
>>> +++ b/arch/arm/imx-common/hab.c
>>> @@ -17,60 +17,45 @@
>>>
>>>  #define hab_rvt_report_event_p \
>>>  (  \
>>> -   ((is_cpu_type(MXC_CPU_MX6Q) ||  \
>>> - is_cpu_type(MXC_CPU_MX6D)) && \
>>> - (soc_rev() >= CHIP_REV_1_5)) ?\
>>> +   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
>>> ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) :  \
>>> -   (is_cpu_type(MXC_CPU_MX6DL) &&  \
>>> -(soc_rev() >= CHIP_REV_1_2)) ? \
>>> +   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
>>
>>This change silently introduces the possibility of MXC_CPU_MX6SOLO. Is
>>this on purpose? If so, then it means that there was something
>
> Yeah. on purpose.
>
>>unrelated to this patch that was wrong in this code for
>>MXC_CPU_MX6SOLO, so this should be fixed in a separate patch before
>>this one. If not, then an is_mx6dl() macro should be introduced.
>
> 6solo and 6dl works the same. I do not plan to add a is_mx6dl here.
> I can refine the commit log to note this in V2.

Then you can indeed either mention this in the commit message, or add
a patch fixing 6solo support before this one.

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] ts4800: add CONFIG_SYS_FSL_ERRATUM_ESDHC_A001

[Sebastien Bourdelin]

Hi Fabio,

On 05/10/2016 04:43 PM, Fabio Estevam wrote:
> Hi Sebastien,
>
> On Thu, Apr 21, 2016 at 2:37 PM, Sebastien Bourdelin
>  wrote:
>> This commit fixes the MMC data transactions timeout problem on the
>> TS4800.
>>
>> The changes introduced in the commit e978a31 on the timeout calculation
>> for the MMC data transactions has revealed there is something wrong with
>> the timeout setting of the eSDHC controller used in the IMX51.
>>
>> The IMX51 seems to be concerned by this erratum and without this change
>> the MMC driver is unable to do any transactions.
>>
>> Signed-off-by: Sebastien Bourdelin 
> Does this issue only happen with eMMC and not with SD card? mx51evk
> boots fine without this config option.
This issue happen with the SD card, i currently didn't found the time to
try with eMMC.

Best Regards,
Sebastien.
> As this change affects only ts4800.h I think it is safer to apply for
> this release:
>
> Reviewed-by: Fabio Estevam 

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

Re: [U-Boot] [PATCH v1 11/12] doc, spl, am335x: update am335x-network

[Tom Rini]

On Wed, May 18, 2016 at 04:18:37PM +0200, Heiko Schocher wrote:

> on the shc board we see when booting in net boot mode,
> that the ROM bootloader sends "AM335x ROM" as
> vendor-class-identifier. U-Boots doc says "DM814x ROM".
> 
> So, add the info to the doc, that there is also
> "AM335x ROM" possible.
> 
> Signed-off-by: Heiko Schocher 

... interesting that they changed it finally.

Reviewed-by: Tom Rini 

-- 
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 v1 09/12] mmc: omap_hsmmc: enable 8bit interface for eMMC for AM33xx

[Tom Rini]

On Wed, May 18, 2016 at 04:18:35PM +0200, Heiko Schocher wrote:

> Enable 8bit interface on HSMMC2 for am33xx to support 8bit eMMC chips.
> 
> Signed-off-by: Heiko Schocher 

Reviewed-by: Tom Rini 

-- 
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 v1 12/12] am335x, shc: add support for the am335x based bosch shc board

[Tom Rini]

On Wed, May 18, 2016 at 04:18:38PM +0200, Heiko Schocher wrote:

> U-Boot SPL 2016.03-rc3-00019-g6dfb4c2-dirty (Mar 09 2016 - 07:40:06)
> SHC C3-Sample
> MPU reference clock runs at 6 MHz
> Setting MPU clock to 594 MHz
> Enabling Spread Spectrum of 18 permille for MPU
> Trying to boot from MMC
> reading u-boot.img
> reading u-boot.img
> 
> U-Boot 2016.03-rc3-00019-g6dfb4c2-dirty (Mar 09 2016 - 07:05:35 +0100)
> 
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> reloc off 1f783000
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Net:   cpsw
> U-Boot#
> 
> Signed-off-by: Heiko Schocher 
> 
> ---
> This patch drops the following checkpatch warnings:
> 
> warning: please write a paragraph that describes the config symbol fully
>   I wrote a help ... I do not understand, whats missing here...
> 
> warning: line over 80 characters
>   On places where I think this does not disturb...
> 
>   Patch:
>   http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/259522
>   is needed for clean compiling.

We need to find some other way to solve this or move all of the
partition stuff to Kconfig as well so we can default some stuff on and
then turn it off in cases.

> +config CONS_INDEX
> + int "UART used for console"
> + range 1 6
> + default 1
> + help
> +   The AM335x SoC has a total of 6 UARTs (UART0 to UART5 as referenced
> +   in documentation, etc) available to it. The SHC board uses UART1
> +   for the console.

Can you really have console on the other locations?  On the AM335x EVM,
it was possible, and doubly so with people making RS232 capes for
Beaglebones.  That's why it's exposed there.

> +int do_panic(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + hang_bosch("u-boot: uImage not found", 4);
> +
> + /*NOTREACHED*/
> + return 0;
> +}
> +
> +U_BOOT_CMD(
> + panic, 1, 0,do_panic,
> + "Hang the CPU - Panic!",
> + ""
> +);

No more commands in board directories, and we should be able to do this
generically.  In fact, we should already be able to make fail to boot
Linux fatal which I gather is what this is used for.

-- 
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 v1 05/12] am335x: add some missing CM_CLKMODE_DPLL_SSC macros

[Tom Rini]

On Wed, May 18, 2016 at 04:18:31PM +0200, Heiko Schocher wrote:

> add missing CM_CLKMODE_DPLL_SSC_ACK_MASK,
> CM_CLKMODE_DPLL_SSC_DOWNSPREAD_MASK and
> CM_CLKMODE_DPLL_SSC_TYPE_MASK
> defines. Used for enabling spread spectrum.
> 
> Signed-off-by: Heiko Schocher 

Reviewed-by: Tom Rini 

-- 
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 v1 06/12] arm, am335x: Enable Spread Spectrum for the MPU

[Tom Rini]

On Wed, May 18, 2016 at 04:18:32PM +0200, Heiko Schocher wrote:

> Enable Spread Spectrum for the MPU by calculating the required
> values and setting the registers accordingly.
> 
> Signed-off-by: Heiko Schocher 

Reviewed-by: Tom Rini 

-- 
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 v1 04/12] arm, am335x: add some missing GPIO register definitions

[Tom Rini]

On Wed, May 18, 2016 at 04:18:30PM +0200, Heiko Schocher wrote:

> add missing:
> OMAP_GPIO_IRQSTATUS_SET_0 and OMAP_GPIO_IRQSTATUS_SET_1
> registers.
> 
> Signed-off-by: Heiko Schocher 

Reviewed-by: Tom Rini 

-- 
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 v1 03/12] power, tps65217: add some defines

[Tom Rini]

On Wed, May 18, 2016 at 04:18:29PM +0200, Heiko Schocher wrote:

> add the following defines, needed for the upcoming shc board
> support:
> 
> Signed-off-by: Heiko Schocher 

Reviewed-by: Tom Rini 

-- 
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 0/2] Add support for Amlogic Meson MMC controller

[Carlo Caione]

On 20/05/16 11:58, Robert Gadsdon wrote:
> On 05/20/2016 01:07 AM, Carlo Caione wrote:
> > On 20/05/16 08:27, Carlo Caione wrote:
> >> On 19/05/16 21:51, Robert Gadsdon wrote:
> >>> Applied this on my Odroid C2, and it worked OK when installed on the
> >>> SDcard, but failed when installed on the eMMC module:
> > 
> > Oh, reading this again you meant that you put u-boot directly on the
> > eMMC? Ok then, something is wrong when using the driver with the eMMC.
> > 
> 
> Yes, I installed it directly on the eMMC, using the micro-sd adapter,
> and following the same instructions as for the SDcard..

Could you try with this patch?

diff --git a/board/hardkernel/odroid-c2/odroid-c2.c
b/board/hardkernel/odroid-c2/odroid-c2.c
index 34b9a95..ab78328 100644
--- a/board/hardkernel/odroid-c2/odroid-c2.c
+++ b/board/hardkernel/odroid-c2/odroid-c2.c
@@ -80,6 +80,11 @@ U_BOOT_DEVICE(meson_mmc) = {
.platdata = _sd_platdata[CONFIG_MMC_MESON_SD_PORT],
 };
  
  +U_BOOT_DEVICE(meson_emmc) = {
  +   .name = "meson_mmc",
  +   .platdata = _sd_platdata[2],
  +};
  +
   static void meson_mmc_pinmux_setup(unsigned int port)
{
switch (port) {

Thanks,

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

Re: [U-Boot] [PATCH 0/2] Add support for Amlogic Meson MMC controller

[Robert Gadsdon]

On 05/20/2016 01:07 AM, Carlo Caione wrote:
> On 20/05/16 08:27, Carlo Caione wrote:
>> On 19/05/16 21:51, Robert Gadsdon wrote:
>>> Applied this on my Odroid C2, and it worked OK when installed on the
>>> SDcard, but failed when installed on the eMMC module:
> 
> Oh, reading this again you meant that you put u-boot directly on the
> eMMC? Ok then, something is wrong when using the driver with the eMMC.
> 

Yes, I installed it directly on the eMMC, using the micro-sd adapter,
and following the same instructions as for the SDcard..

Robert Gadsdon.

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

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

[Hans de Goede]

Hi,

On 20-05-16 19:55, Tom Rini wrote:

On Fri, May 20, 2016 at 05:53:34PM +0200, Hans de Goede wrote:

Hi,

On 20-05-16 17:23, Simon Glass wrote:

Hi Tom,

On 19 May 2016 at 10:02, Tom Rini  wrote:

On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote:

Hi Tom,

On 19 May 2016 at 06:09, Tom Rini  wrote:

On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote:


Hi Tom,

This includes a refinement of the GPIO interface, soft SPI fixes,
driver model block-device support (and a legacy driver for
non-driver-model code) and a few other things. The changes are fairly
major so I'd like to get the maximum possible test window.


The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed:

 Prepare v2016.05 (2016-05-16 10:40:32 -0400)

are available in the git repository at:

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

for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30:

 dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600)



Applied to u-boot/master, thanks!

But please note that this is starting to push some boards to or over the
SPL edge such as Cubietruck so we need to look into some waste areas
again.  Adding Hans in case there's also stuff we could simply be
dropping out of SPL but aren't today.


Yes I saw that but the increase was much larger than it should have
been. I meant to try it with the bug-fixed gcc and see if the increase
was smaller. It does unfortunately add a few hundred bytes of code. I
believe it might be possible to reduce this but I haven't yet figured
out how.


I've been happy when I can use gcc-6.x for all the free cost savings but
current Debian tools (and current Fedora, and current any other big
distro) toolchains matter too.  You can also see the size growth (but
not to fatal proportions) on CHIP or warp7 or MSI_Primo73


OK thanks for the pointers. I will take a look. I spent quite a bit of
time on this (it was pretty awful at the start!) but obviously I
haven't quite nailed it.


So I've run some quick tests on F-24 which is at gcc-6 (and it is unlikely
u-boot v2015.07 will be coming to older Fedora versions) and I got the
following u-boot-spl.bin increase for Cubietruck:

v2015.05: 19696
master:   19932

So if others are seeing some more extreme increase then that is probably
the good old tool-chain problem with not eliminating unused strings.

The way to work around this is look at the linker.map, find out which
object files have grown considerably on master, and check if the patches
in one of those files perhaps has caused us to use some const string
in there, where before we were not using any. The problem with the toolchain
bug is that using a single const string in a .o file will make it link
in ALL const strings in the .o file, even the 99 other unused ones.

In the past I've hacked around that in e.g. the malloc code, but TBH,
now that the upstream toolchain is fixed I'm not sure if we should
bother with kludging around this.


I am a fan of gcc-6.x (as it saves us space on so many platforms), but
with your sunxi hat on, rather than Fedora guy hat on, do you think
telling people to just grab gcc-6.x is an OK solution for users?


With my sunxi custodian hat on, I'm divided on the issue, we've had
to jump through some hoops before because of the linker issue which
causes all strings in a .o file, including unused ones to get linked
into the SPL and I would really like to see us to be able to stop
worrying about this. OTOH the reality is that plenty of people are
still using older tool-chains.

The question is do we expect people to use older tool-chains, and
yet use the latest and greatest u-boot. For Fedora the answer is
no, for Debian I do not know and individual users are likely to
hit this problem too.

So having said all the above, then with my sunxi custodian hat
still on, I have to agree that the size increase with gcc-5
is indeed an issue.

Simon, if you've some time to look into this, that would be great.

As said before I suspect the culprit to be a .o file with lots
of strings in there, of which we ended up using 0 strings before
and are now using 1 or more strings, which brings in ALL the
strings with gcc-5.x . Note I could be completely of the mark
here, this was the problem the last time we had SPL size issues,
might be something different now.

Regards,

Hans

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

[U-Boot] [PATCH] cosmetic: mx6slevk: Minor coding-style fix

[Sebastien Bourdelin]

Fix the brace indentation in board_mmc_init().

Signed-off-by: Sebastien Bourdelin 
---
 board/freescale/mx6slevk/mx6slevk.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/freescale/mx6slevk/mx6slevk.c 
b/board/freescale/mx6slevk/mx6slevk.c
index f1915a8..256d602 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -230,14 +230,14 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more USDHC controllers"
"(%d) than supported by the board\n", i + 1);
return -EINVAL;
-   }
-
-   ret = fsl_esdhc_initialize(bis, _cfg[i]);
-   if (ret) {
-   printf("Warning: failed to initialize "
-   "mmc dev %d\n", i);
-   return ret;
-   }
+   }
+
+   ret = fsl_esdhc_initialize(bis, _cfg[i]);
+   if (ret) {
+   printf("Warning: failed to initialize "
+   "mmc dev %d\n", i);
+   return ret;
+   }
}
 
return 0;
-- 
2.8.0

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

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

[Tom Rini]

On Fri, May 20, 2016 at 05:53:34PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 20-05-16 17:23, Simon Glass wrote:
> >Hi Tom,
> >
> >On 19 May 2016 at 10:02, Tom Rini  wrote:
> >>On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote:
> >>>Hi Tom,
> >>>
> >>>On 19 May 2016 at 06:09, Tom Rini  wrote:
> On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote:
> 
> >Hi Tom,
> >
> >This includes a refinement of the GPIO interface, soft SPI fixes,
> >driver model block-device support (and a legacy driver for
> >non-driver-model code) and a few other things. The changes are fairly
> >major so I'd like to get the maximum possible test window.
> >
> >
> >The following changes since commit 
> >aeaec0e682f45b9e0c62c522fafea353931f73ed:
> >
> >  Prepare v2016.05 (2016-05-16 10:40:32 -0400)
> >
> >are available in the git repository at:
> >
> >  git://git.denx.de/u-boot-dm.git
> >
> >for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30:
> >
> >  dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600)
> >
> 
> Applied to u-boot/master, thanks!
> 
> But please note that this is starting to push some boards to or over the
> SPL edge such as Cubietruck so we need to look into some waste areas
> again.  Adding Hans in case there's also stuff we could simply be
> dropping out of SPL but aren't today.
> >>>
> >>>Yes I saw that but the increase was much larger than it should have
> >>>been. I meant to try it with the bug-fixed gcc and see if the increase
> >>>was smaller. It does unfortunately add a few hundred bytes of code. I
> >>>believe it might be possible to reduce this but I haven't yet figured
> >>>out how.
> >>
> >>I've been happy when I can use gcc-6.x for all the free cost savings but
> >>current Debian tools (and current Fedora, and current any other big
> >>distro) toolchains matter too.  You can also see the size growth (but
> >>not to fatal proportions) on CHIP or warp7 or MSI_Primo73
> >
> >OK thanks for the pointers. I will take a look. I spent quite a bit of
> >time on this (it was pretty awful at the start!) but obviously I
> >haven't quite nailed it.
> 
> So I've run some quick tests on F-24 which is at gcc-6 (and it is unlikely
> u-boot v2015.07 will be coming to older Fedora versions) and I got the
> following u-boot-spl.bin increase for Cubietruck:
> 
> v2015.05: 19696
> master:   19932
> 
> So if others are seeing some more extreme increase then that is probably
> the good old tool-chain problem with not eliminating unused strings.
> 
> The way to work around this is look at the linker.map, find out which
> object files have grown considerably on master, and check if the patches
> in one of those files perhaps has caused us to use some const string
> in there, where before we were not using any. The problem with the toolchain
> bug is that using a single const string in a .o file will make it link
> in ALL const strings in the .o file, even the 99 other unused ones.
> 
> In the past I've hacked around that in e.g. the malloc code, but TBH,
> now that the upstream toolchain is fixed I'm not sure if we should
> bother with kludging around this.

I am a fan of gcc-6.x (as it saves us space on so many platforms), but
with your sunxi hat on, rather than Fedora guy hat on, do you think
telling people to just grab gcc-6.x is an OK solution for users?

-- 
Tom


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

[U-Boot] uboot xHCI driver crash sometimes when endpoint stalls

[Mohammed Mohisin]

Hi All,

Sometimes crash is observed, when the endpoint stalls.
And the crash happens in xhci_ctrl_tx() -> xhci_acknowledge_event()


In my case,
1) scsi read command is sent successfully,
2) Then for Get data command stall is received (as i mentioned issue is
seen sometimes, which means data is being sent and received correctly other
times.)
3) As a response to STALL event, i do the following (as endpoint stall is
not handled in u-boot)
- send reset endpoint command
- wait for trb completion event
- call abort_td() which stops endpoint ring and sets deq pointer to enq
pointer.
- Now return error STALL status to application
- Now application sends
a) reset device (0xFF) command > issue is seen here...
 Issue description:
  - when control setup and status TRBs are enq'ed and
doorbell is   rung, event is received.
  - while acknowledging this event, crash is seen
b) clear stall on both bulk in and out endpoints
4) Now the scsi read command is retried.

Can anyone tell what might be happening, ??

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

Re: [U-Boot] why so little use of ft_system_setup()?

[Robert P. J. Day]

On Fri, 20 May 2016, Stephen Warren wrote:

> On 05/19/2016 12:19 PM, Robert P. J. Day wrote:
> >
> >still crawling through the code related to FDTs, and while i see a
> > pile of boards that define CONFIG_OF_SYSTEM_SETUP, i see very few that
> > define the corresponding(?) ft_system_setup() routine.
> >
> > $ grep -r CONFIG_OF_SYSTEM_SETUP *
>
> > configs/apalis_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/paz00_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/plutux_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/venice2_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/p2571_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/beaver_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/ventana_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/p2371-_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/tec-ng_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/seaboard_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/dalmore_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/harmony_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/cardhu_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/p2371-2180_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/trimslice_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/colibri_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/colibri_t20_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/whistler_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/tec_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/jetson-tk1_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/e2220-1170_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/medcom-wide_defconfig:CONFIG_OF_SYSTEM_SETUP=y
> > configs/nyan-big_defconfig:CONFIG_OF_SYSTEM_SETUP=y
>
> All of those are Tegra boards.
>
> >and yet ...
> >
> > $ grep -rw ft_system_setup *
> > arch/arm/mach-tegra/board2.c:int ft_system_setup(void *blob, bd_t *bd)
>
> ... which link in that file.

  ah, quite so, sorry for not noticing that.

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] net: Add ag7xxx driver for Atheros MIPS

[Marek Vasut]

On 05/20/2016 06:43 PM, Wills Wang wrote:
> 
> 
> On 05/20/2016 07:59 PM, Marek Vasut wrote:
>> On 05/20/2016 06:18 AM, Wills Wang wrote:
>>>
>>> On 05/08/2016 11:22 PM, Marek Vasut wrote:
 On 05/08/2016 02:58 PM, Daniel Schwierzeck wrote:

 Hi!

> Am 05.05.2016 um 21:34 schrieb Marek Vasut:
>> Add ethernet driver for the AR933x and AR934x Atheros MIPS machines.
>> The driver could be easily extended to other WiSoCs.
>>> How to make this patch work on ar933x board?
>>> I apply this patch on the top of mips/next branch and enable this option
>>> in menuconfig,
>>> but i can't see any boot information for Ethernet.
>> The Kconfig conversion is not complete. See the tplink_wdr4300_defconfig
>> for the necessary options, it should be at least these:
>>
>> CONFIG_CMD_NET=y
>> CONFIG_CMD_NFS=y
>> CONFIG_CMD_DHCP=y
>> CONFIG_CMD_PING=y
>> CONFIG_NET_RANDOM_ETHADDR=y
>> CONFIG_DM_ETH=y
>> CONFIG_AG7XXX=y
>>
> I add these options and boot up as the following, but my ar933x board
> don't work,
> the link indicator led on router is off when plug in the cable and
> execute "dhcp" command.
> 

Hrm, I have no idea, sorry, you'd have to dive in. It works on the board
I have. The ar933x is such a junk chip that I kinda gave up on it. I
also tested this on ar934x (my primary test platform) and it works.

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

Re: [U-Boot] [PATCH] net: Add ag7xxx driver for Atheros MIPS

[Wills Wang]

On 05/20/2016 07:59 PM, Marek Vasut wrote:

On 05/20/2016 06:18 AM, Wills Wang wrote:


On 05/08/2016 11:22 PM, Marek Vasut wrote:

On 05/08/2016 02:58 PM, Daniel Schwierzeck wrote:

Hi!


Am 05.05.2016 um 21:34 schrieb Marek Vasut:

Add ethernet driver for the AR933x and AR934x Atheros MIPS machines.
The driver could be easily extended to other WiSoCs.

How to make this patch work on ar933x board?
I apply this patch on the top of mips/next branch and enable this option
in menuconfig,
but i can't see any boot information for Ethernet.

The Kconfig conversion is not complete. See the tplink_wdr4300_defconfig
for the necessary options, it should be at least these:

CONFIG_CMD_NET=y
CONFIG_CMD_NFS=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM_ETH=y
CONFIG_AG7XXX=y

I add these options and boot up as the following, but my ar933x board 
don't work,
the link indicator led on router is off when plug in the cable and 
execute "dhcp" command.


U-Boot 2016.05-gfe4be7c-dirty (May 21 2016 - 00:10:47 +0800)

Atheros AR9330 rev 1
Model: AP121 Reference Board
DRAM:  64 MiB
SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 
8 MiB, mapped at 9f00

*** Warning - bad CRC, using default environment

In:uart@1802
Out:   uart@1802
Err:   uart@1802
Net:
Warning: eth@0x1900 (eth0) using random MAC address - 6a:62:33:b1:0d:2e
eth0: eth@0x1900
Hit any key to stop autoboot:  0
ap121 # dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
ag7xxx: Out of TX DMA descriptors!
BOOTP broadcast 15
ag7xxx: Out of TX DMA descriptors!
BOOTP broadcast 16
ag7xxx: Out of TX DMA descriptors!
BOOTP broadcast 17
ag7xxx: Out of TX DMA descriptors!

Retry time exceeded; starting again
ap121 #


By the way, the DT node "compatible" in driver is different from
arch/mips/dts/ar933x.dtsi

OK, tweak that one to "qca,ag933x-mac" in the DTS.

, and

the following compiling error occur because of commit
4feefdcfe916113ac6e1837ea22857f25fe1771c:

Enable CONFIG_CLK=y in your defconfig .


drivers/usb/host/built-in.o: In function `ehci_usb_probe':
drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x40): undefined
reference to `clk_get_by_index'
drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x4c): undefined
reference to `clk_get_by_index'
drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x60): undefined
reference to `clk_enable'
drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x68): undefined
reference to `clk_enable'





--
Best Regards
Wills

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

Re: [U-Boot] [PATCH] mmc: tegra: add basic Tegra186 support

[Stephen Warren]

On 05/18/2016 10:02 PM, Simon Glass wrote:

Hi Stephen,

On 12 May 2016 at 12:11, Stephen Warren  wrote:

...

  arch/arm/include/asm/arch-tegra/tegra_mmc.h |  2 ++
  drivers/mmc/tegra_mmc.c | 32 -
  include/fdtdec.h|  1 +
  lib/fdtdec.c|  1 +
  4 files changed, 35 insertions(+), 1 deletion(-)


Can you convert this driver to use CONFIG_DM_MMC and CONFIG_BLK?


I believe Tom will take a look at this.

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

Re: [U-Boot] [PATCH v2] ARM: fix ifdef in ARMv8 lowlevel_init() again

[Stephen Warren]

On 05/19/2016 09:13 PM, Masahiro Yamada wrote:

Commit 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
accidentally inverted the logic of CONFIG_ARMV8_MULTIENTRY.

Fixes: 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
Signed-off-by: Masahiro Yamada 


Reviewed-by: Stephen Warren 

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

Re: [U-Boot] why so little use of ft_system_setup()?

[Stephen Warren]

On 05/19/2016 12:19 PM, Robert P. J. Day wrote:


   still crawling through the code related to FDTs, and while i see a
pile of boards that define CONFIG_OF_SYSTEM_SETUP, i see very few that
define the corresponding(?) ft_system_setup() routine.

$ grep -r CONFIG_OF_SYSTEM_SETUP *



configs/apalis_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/paz00_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/plutux_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/venice2_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/p2571_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/beaver_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/ventana_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/p2371-_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/tec-ng_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/seaboard_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/dalmore_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/harmony_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/cardhu_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/p2371-2180_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/trimslice_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/colibri_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/colibri_t20_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/whistler_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/tec_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/jetson-tk1_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/e2220-1170_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/medcom-wide_defconfig:CONFIG_OF_SYSTEM_SETUP=y
configs/nyan-big_defconfig:CONFIG_OF_SYSTEM_SETUP=y


All of those are Tegra boards.


   and yet ...

$ grep -rw ft_system_setup *
arch/arm/mach-tegra/board2.c:int ft_system_setup(void *blob, bd_t *bd)


... which link in that file.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Hans de Goede]

Hi,

On 20-05-16 17:23, Simon Glass wrote:

Hi Tom,

On 19 May 2016 at 10:02, Tom Rini  wrote:

On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote:

Hi Tom,

On 19 May 2016 at 06:09, Tom Rini  wrote:

On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote:


Hi Tom,

This includes a refinement of the GPIO interface, soft SPI fixes,
driver model block-device support (and a legacy driver for
non-driver-model code) and a few other things. The changes are fairly
major so I'd like to get the maximum possible test window.


The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed:

  Prepare v2016.05 (2016-05-16 10:40:32 -0400)

are available in the git repository at:

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

for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30:

  dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600)



Applied to u-boot/master, thanks!

But please note that this is starting to push some boards to or over the
SPL edge such as Cubietruck so we need to look into some waste areas
again.  Adding Hans in case there's also stuff we could simply be
dropping out of SPL but aren't today.


Yes I saw that but the increase was much larger than it should have
been. I meant to try it with the bug-fixed gcc and see if the increase
was smaller. It does unfortunately add a few hundred bytes of code. I
believe it might be possible to reduce this but I haven't yet figured
out how.


I've been happy when I can use gcc-6.x for all the free cost savings but
current Debian tools (and current Fedora, and current any other big
distro) toolchains matter too.  You can also see the size growth (but
not to fatal proportions) on CHIP or warp7 or MSI_Primo73


OK thanks for the pointers. I will take a look. I spent quite a bit of
time on this (it was pretty awful at the start!) but obviously I
haven't quite nailed it.


So I've run some quick tests on F-24 which is at gcc-6 (and it is unlikely
u-boot v2015.07 will be coming to older Fedora versions) and I got the
following u-boot-spl.bin increase for Cubietruck:

v2015.05: 19696
master:   19932

So if others are seeing some more extreme increase then that is probably
the good old tool-chain problem with not eliminating unused strings.

The way to work around this is look at the linker.map, find out which
object files have grown considerably on master, and check if the patches
in one of those files perhaps has caused us to use some const string
in there, where before we were not using any. The problem with the toolchain
bug is that using a single const string in a .o file will make it link
in ALL const strings in the .o file, even the 99 other unused ones.

In the past I've hacked around that in e.g. the malloc code, but TBH,
now that the upstream toolchain is fixed I'm not sure if we should
bother with kludging around this.

Regards,

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

Re: [U-Boot] [PATCH v7 3/4] arm: add initial support for Amlogic Meson and ODROID-C2

[Carlo Caione]

On 08/05/16 08:30, Beniamino Galvani wrote:
> This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a
> board definition for ODROID-C2. This initial submission only supports
> UART and Ethernet (through the existing Designware driver). DTS files
> are the ones submitted to Linux arm-soc for 4.7 [1].
> 
> [1] https://patchwork.ozlabs.org/patch/603583/
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/Kconfig   |   9 ++
>  arch/arm/Makefile  |   1 +
>  arch/arm/dts/Makefile  |   2 +
>  arch/arm/dts/meson-gxbb-odroidc2.dts   |  69 +
>  arch/arm/dts/meson-gxbb.dtsi   | 178 
> +
>  arch/arm/include/asm/arch-meson/gxbb.h |  52 ++
>  arch/arm/mach-meson/Kconfig|  31 ++
>  arch/arm/mach-meson/Makefile   |   7 ++
>  arch/arm/mach-meson/board.c|  66 
>  board/hardkernel/odroid-c2/Kconfig |  12 +++
>  board/hardkernel/odroid-c2/MAINTAINERS |   6 ++
>  board/hardkernel/odroid-c2/Makefile|   7 ++
>  board/hardkernel/odroid-c2/README  |  60 +++
>  board/hardkernel/odroid-c2/odroid-c2.c |  51 ++

I suggest to have s/hardkernel/amlogic/ so that we can have all the
amlogic boards in the same place.

Also I wonder if it's worth to have one single board file board.c so to
avoid duplicating code among the boards, especially now that the DT
support is still incomplete. 

Cheers,

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

[U-Boot] Sharing code between Linux and bootloader (U-boot) ?

[Sebastian Frias]

Hi,

Some bootloaders (like U-boot) support several HW devices: serial, network, 
NAND, USB, etc. most of which are also supported by Linux.

So the question is: is code shared? I mean, I understand that the drivers need 
to talk to the appropriate API, and such API could be different between Linux 
and U-boot.
But putting that aside, would it be naive to imagine that some "core" 
functionality could be shared? Or would that part be so small it is not worth 
the effort?

Since many companies use both, U-boot and Linux, I would figure they try their 
best to optimize engineering resources and share code, right?
In that case, I also wonder how do they share DT descriptions that right now 
are being stored in the Linux kernel tree.

We'd like to share code/DT for obvious reasons, what would you guys suggest?

Best regards,

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

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Rajesh Bhagat]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut
> Sent: Tuesday, May 10, 2016 6:02 PM
> To: Diego 
> Cc: u-boot@lists.denx.de; Stefan Roese 
> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
> 
> On 05/10/2016 02:04 PM, Diego wrote:
> > In data mercoledì 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
> >> On 05/04/2016 04:06 PM, Diego wrote:
> >>> In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>  On 05/04/2016 11:13 AM, Diego wrote:
> > 
> > So I see three options:
> > 1) 65535 default with quirk table
> > 2) 32767 default without quirk table
> > 3) 32767 default with quirk table
> >
> > Personally I think 3) would be the safest solution, but I think 2)
> > would at least work for most thumb drives.
> 
>  1) with the quirk table would be the way to go, modern(ish) drives
>  should work fine with 65535 .
> >>>
> >>> I personally can't see any improvement with more recent thumb
> >>> drives, quite the opposite.
> >>>
> >>> 
> >>> Why are you saying modern(ish) drives should work?
> >>
> >> Hm :-(
> >>
> >>> For others following the thread, please post your experience,
> >>> especially with more recent drives (remember to test with files >16MB).
> >>
> >> I don't think it's really worth doing a thread about which sticks
> >> work and which don't. I would find it much more valuable to address
> >> this issue properly. I wonder if it would make sense to, instead of
> >> starting with a big value which might not work, start with a
> >> small(er) value and increase it with each subsequent block transfer.
> >> Quite similarly to what TCP does. Would you be willing to look into it ?
> >>
> >
> > Hi Marek,
> 
> Hi!
> 
> > so your proposal is to ramp up transferred block size during transfer?
> > What's the rationale behind the proposal? In other words, why do you
> > think it will fix the problem?
> 
> You will get one transfer failure somewhere in the middle and this will let 
> you
> determine the maximum transfer size for particular stick.
> 
> > Regarding implementing your proposal, it might take me very long to
> > find some time to dedicate to it, so if anybody else wants to step up
> > before I look at it, just raise your hand.
> 
> OK
> 

Hello Marek, 

I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem 
to 
focus on this value and is not impacted, kept the value so low i.e. 20?

#ifdef CONFIG_USB_EHCI
/*
 * The U-Boot EHCI driver can handle any transfer length as long as there is
 * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are
 * limited to 65535 blocks.
 */
#define USB_MAX_XFER_BLK65535
#else
#define USB_MAX_XFER_BLK20
#endif

Common code suggests it is used in same way as used in EHCI. Please comment.

Best Regards,
Rajesh Bhagat 

> > Bests,
> > Diego
> >
> 
> 
> --
> Best regards,
> Marek Vasut
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] Add support for Amlogic Meson MMC controller

[Carlo Caione]

On 19/05/16 21:51, Robert Gadsdon wrote:
> Applied this on my Odroid C2, and it worked OK when installed on the
> SDcard, but failed when installed on the eMMC module:
> 
> => version
> U-Boot 2016.05-rc3 (May 14 2016 - 21:06:28 -0700) odroid-c2
> aarch64-linux-gnu-gcc (GCC) 5.3.1 20160212 (Red Hat Cross 5.3.1-2)
> GNU ld version 2.26.20160125
> 
> => mmc info
> Card did not respond to voltage select!

Yes, this is expected since the muxing in the board file is only
enabling the SDcard. Could you try to set the correct muxing also for
the eMMC and check again?

Unfortunately I don't have an eMMC for the Odroid-C2 to check this out.
I'll try to prepare a board file also for the P20x so I can test this
better.

Thank you for testing this BTW.

Cheers,

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

Re: [U-Boot] [PATCH 0/2] Add support for Amlogic Meson MMC controller

[Carlo Caione]

On 20/05/16 08:27, Carlo Caione wrote:
> On 19/05/16 21:51, Robert Gadsdon wrote:
> > Applied this on my Odroid C2, and it worked OK when installed on the
> > SDcard, but failed when installed on the eMMC module:

Oh, reading this again you meant that you put u-boot directly on the
eMMC? Ok then, something is wrong when using the driver with the eMMC.

I'll try to boot it on the P20x and check what's wrong with it.

Thanks,

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

Re: [U-Boot] [PATCH] driver/ddr/fsl: Force enabling parity for A-009803

[York Sun]

On 05/20/2016 01:15 AM, Shengzhou Liu wrote:
> Default address parity is disabled for DDR4 UDIMM for considing
> performance, it needs to enable parity for A-009803 workaround.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  drivers/ddr/fsl/options.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
> index d0075ff..dcef0bb 100644
> --- a/drivers/ddr/fsl/options.c
> +++ b/drivers/ddr/fsl/options.c
> @@ -1016,6 +1016,9 @@ unsigned int populate_memctl_options(const 
> common_timing_params_t *common_dimm,
>   }
>   }
>  
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
> + popts->ap_en = 1;
> +#endif
>   /*
>* BSTTOPRE precharge interval
>*
> 

Shengzhou,

It looks backward. You should detect if the condition is right before applying
the workaround, not by forcing the condition.

York

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

Re: [U-Boot] [PATCH v5 02/12] spi: davinci_spi: Convert to driver to adapt to DM

[Simon Glass]

Hi Vignesh,

On 19 May 2016 at 23:01, Vignesh R  wrote:
>
> Convert davinci_spi driver so that it complies with SPI DM framework.
>
> Signed-off-by: Vignesh R 
> Reviewed-by: Tom Rini 
> ---
>
> v5: correct error message.
>
> v4: Check error returned by dev_map_physmem().
>
> v3: No changes
>
> v2: Add comments to struct davinci_spi_slave members.
> Use dev_map_physmem() added by previous patch.
>
>  drivers/spi/davinci_spi.c | 329 
> +-
>  1 file changed, 240 insertions(+), 89 deletions(-)

Sorry I missed something below.
[snip]

> +static int davinci_ofdata_to_platadata(struct udevice *bus)
> +{
> +   struct davinci_spi_slave *ds = dev_get_priv(bus);
> +   const void *blob = gd->fdt_blob;
> +   int node = bus->of_offset;
> +
> +   ds->regs = dev_map_physmem(bus, sizeof(struct davinci_spi_regs));
> +   if (!ds->regs) {
> +   printf("%s: could not map device address\n", __func__);
> +   return -ENODEV;

-EINVAL

We use -ENODEV to say there is no device. Here, we have a device but
the configuration is wrong.

> }
> +   ds->num_cs = fdtdec_get_int(blob, node, "num-cs", 4);
> +
> return 0;
>  }
> +
> +static const struct dm_spi_ops davinci_spi_ops = {
> +   .claim_bus  = davinci_spi_claim_bus,
> +   .release_bus= davinci_spi_release_bus,
> +   .xfer   = davinci_spi_xfer,
> +   .set_speed  = davinci_spi_set_speed,
> +   .set_mode   = davinci_spi_set_mode,
> +};
> +
> +static const struct udevice_id davinci_spi_ids[] = {
> +   { .compatible = "ti,keystone-spi" },
> +   { .compatible = "ti,dm6441-spi" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(davinci_spi) = {
> +   .name = "davinci_spi",
> +   .id = UCLASS_SPI,
> +   .of_match = davinci_spi_ids,
> +   .ops = _spi_ops,
> +   .ofdata_to_platdata = davinci_ofdata_to_platadata,
> +   .priv_auto_alloc_size = sizeof(struct davinci_spi_slave),
> +   .probe = davinci_spi_probe,
> +};
> +#endif
> --
> 2.8.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 01/12] common: bootdelay: move CONFIG_BOOTDELAY into a Kconfig option

[Tom Rini]

On Fri, May 20, 2016 at 03:19:46PM +0200, Daniel Schwierzeck wrote:
> Am 20.05.2016 um 15:09 schrieb Tom Rini:
> > On Wed, May 18, 2016 at 04:18:27PM +0200, Heiko Schocher wrote:
> > 
> >> move CONFIG_BOOTDELAY into a Kconfig option. Used for this
> >> purpose the moveconfig.py tool in tools.
> >>
> >> Signed-off-by: Heiko Schocher 
> > 
> > So, my question here is did you do a buildman -S (sizes) before/after
> > this patch?  That's the hard part of moveconfig.py migrations, making
> > sure that in the end everyone is still the same.  Since the cover letter
> > talks about ARM only, I'll do that shortly and let you know, thanks!
> 
> could you postpone and refresh this patch after the merge window has
> closed? I have queued support for new SoC's and boards in
> u-boot-mips/next for which I want to send a PR soon. But merging new
> boards after such a patch is problematic. I guess other archs also have
> queued support for new boards.

Good point.  Maybe I'll just drop the defconfig changes portion of this
and update after it's closed like I did last release.  I'll see how that
goes after this build run of everything is done.

-- 
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 v4 02/12] spi: davinci_spi: Convert to driver to adapt to DM

[Simon Glass]

On 16 May 2016 at 03:38, Vignesh R  wrote:
> Convert davinci_spi driver so that it complies with SPI DM framework.
>
> Signed-off-by: Vignesh R 
> Reviewed-by: Tom Rini 
> ---
>
> v4: Check error returned by dev_map_physmem().
>
> v3: No changes
>
> v2: Add comments to struct davinci_spi_slave members.
> Use dev_map_physmem() added by previous patch.
>
>  drivers/spi/davinci_spi.c | 329 
> +-
>  1 file changed, 240 insertions(+), 89 deletions(-)

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

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

[Simon Glass]

Hi Tom,

On 19 May 2016 at 10:02, Tom Rini  wrote:
> On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 19 May 2016 at 06:09, Tom Rini  wrote:
>> > On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote:
>> >
>> >> Hi Tom,
>> >>
>> >> This includes a refinement of the GPIO interface, soft SPI fixes,
>> >> driver model block-device support (and a legacy driver for
>> >> non-driver-model code) and a few other things. The changes are fairly
>> >> major so I'd like to get the maximum possible test window.
>> >>
>> >>
>> >> The following changes since commit 
>> >> aeaec0e682f45b9e0c62c522fafea353931f73ed:
>> >>
>> >>   Prepare v2016.05 (2016-05-16 10:40:32 -0400)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>   git://git.denx.de/u-boot-dm.git
>> >>
>> >> for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30:
>> >>
>> >>   dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600)
>> >>
>> >
>> > Applied to u-boot/master, thanks!
>> >
>> > But please note that this is starting to push some boards to or over the
>> > SPL edge such as Cubietruck so we need to look into some waste areas
>> > again.  Adding Hans in case there's also stuff we could simply be
>> > dropping out of SPL but aren't today.
>>
>> Yes I saw that but the increase was much larger than it should have
>> been. I meant to try it with the bug-fixed gcc and see if the increase
>> was smaller. It does unfortunately add a few hundred bytes of code. I
>> believe it might be possible to reduce this but I haven't yet figured
>> out how.
>
> I've been happy when I can use gcc-6.x for all the free cost savings but
> current Debian tools (and current Fedora, and current any other big
> distro) toolchains matter too.  You can also see the size growth (but
> not to fatal proportions) on CHIP or warp7 or MSI_Primo73

OK thanks for the pointers. I will take a look. I spent quite a bit of
time on this (it was pretty awful at the start!) but obviously I
haven't quite nailed it.

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

[U-Boot] Azalia verb table from DT with Baytrail FSP

[George McCollister]

I'm working with an Advantech som-6867 (Baytrail com express CPU
module) and som-db5800 carrier board (with ALC892 HD audio codec) as
well as a custom carrier board (with CS4207 HD audio codec).

After adding DT entries for the correct HDA pad configuration, I got
the ALC892 working by hacking over ALC262 verb table in
arch/x86/cpu/baytrail/fsp_configs.c and am now investigating a
permanent solution.

I noticed in Bin's patchset titled "x86: fsp: Move platform-specific
config to chipset directory" his comment "But with this series, we are
now able to get Azalia verb table from device tree, just like what we
did for overriding UPD data configuration. This can be done in future
patch set."

I also however noticed Simon's conflicting comment in
arch/x86/cpu/baytrail/fsp_configs.c "This needs to be in ROM since if
we put it in CAR, FSP init loses it when it drops CAR."

Is it safe to move Azalia verb tables into DT for Baytrail FSP?

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

Re: [U-Boot] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 04:23 PM, Tim Harvey wrote:
> On Fri, May 20, 2016 at 6:16 AM, Marek Vasut  wrote:
>>> Marek,
>>>
>>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>>> config? It looks like the novena board was the only one using it and
>>> it breaks Ventana build.
>>
>> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
>> ventana. If we have FS boot, we should push for filesystems which are
>> not a patent minefield (like fat).
>>
>> So what about adding this to ventana:
>> #undef CONFIG_SPL_EXT_SUPPORT
>>
> 
> sounds reasonable - I'll submit that shortly

Cool, thanks!


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

Re: [U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Fri, May 20, 2016 at 6:16 AM, Marek Vasut  wrote:
>> Marek,
>>
>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>> config? It looks like the novena board was the only one using it and
>> it breaks Ventana build.
>
> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
> ventana. If we have FS boot, we should push for filesystems which are
> not a patent minefield (like fat).
>
> So what about adding this to ventana:
> #undef CONFIG_SPL_EXT_SUPPORT
>

sounds reasonable - I'll submit that shortly

Regards,

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

[U-Boot] [PATCH 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

[Boris Brezillon]

The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
to explicitly depend on platforms that are not already defining it in their
include/configs/.h header.

Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency
on NAND_SUNXI and make it dependent on SPL selection.

common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to
CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay
compatible with the existing behavior.

Signed-off-by: Boris Brezillon 
---
 common/spl/spl_nand.c | 4 
 drivers/mtd/nand/Kconfig  | 9 +
 drivers/mtd/nand/sunxi_nand_spl.c | 8 
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index bbd9546..612bd4a 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -10,6 +10,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#endif
+
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
 int spl_nand_load_image(void)
 {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2fc73ef..4b0f92c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -99,16 +99,17 @@ config SYS_NAND_BUSWIDTH_16BIT
not available while configuring controller. So a static 
CONFIG_NAND_xx
is needed to know the device's bus-width in advance.
 
-# Enhance depends when converting drivers to Kconfig which use this config
-config SYS_NAND_U_BOOT_OFFS
+if SPL
+
+# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS.
+# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined.
+config SPL_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
-   depends on NAND_SUNXI
help
Set the offset from the start of the nand where u-boot should be
loaded from.
 
-if SPL
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 1739da2..85cb127 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -348,14 +348,14 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
 * u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
 * for backup u-boot 1 erase block further.
 */
-   const uint32_t eraseblock_size = CONFIG_SYS_NAND_U_BOOT_OFFS / 2;
+   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
const uint32_t boot_offsets[] = {
-   CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_U_BOOT_OFFS + eraseblock_size,
+   CONFIG_SPL_NAND_U_BOOT_OFFS,
+   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
};
int i;
 
-   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
+   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
if (nand_read_buffer(boot_offsets[i], size,
 dest) == 0)
-- 
2.7.4

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

[U-Boot] [PATCH 3/7] spl: nand: support redundant u-boot image

[Boris Brezillon]

On modern NAND it's more than recommended to have a backup copy of the
u-boot binary to recover from corruption: bitflips are quite common on
MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
more quickly than what you would see on an SLC NAND.

Add an extra Kconfig option to specify the offset of the redundant u-boot
image.

Signed-off-by: Boris Brezillon 
---
 common/spl/spl_nand.c| 8 
 drivers/mtd/nand/Kconfig | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 612bd4a..0bf0848 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -12,6 +12,9 @@
 
 #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
 #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND
+#else
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
 #endif
 
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
@@ -111,6 +114,11 @@ int spl_nand_load_image(void)
 #endif
/* Load u-boot */
err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
+#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
+   if (err)
+   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
+   header);
+#endif
nand_deselect();
return err;
 }
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4b0f92c..2f1d1f7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -110,6 +110,12 @@ config SPL_NAND_U_BOOT_OFFS
Set the offset from the start of the nand where u-boot should be
loaded from.
 
+config SPL_NAND_U_BOOT_OFFS_REDUND
+   hex "Location in NAND to read U-Boot from"
+   default SPL_NAND_U_BOOT_OFFS
+   help
+   Set the offset from the start of the nand where u-boot should be
+   loaded from.
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
-- 
2.7.4

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

[U-Boot] [PATCH 4/7] spl: nand: sunxi: stop guessing the redundant u-boot offset

[Boris Brezillon]

Use CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND value instead of trying to guess
where the redundant u-boot image is based on simple (and most of the time
erroneous) heuristics.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 85cb127..13e6eab 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -344,26 +344,6 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest)
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
-   /*
-* u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
-* for backup u-boot 1 erase block further.
-*/
-   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
-   const uint32_t boot_offsets[] = {
-   CONFIG_SPL_NAND_U_BOOT_OFFS,
-   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
-   };
-   int i;
-
-   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
-   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
-   if (nand_read_buffer(boot_offsets[i], size,
-dest) == 0)
-   return 0;
-   }
-   return -1;
-   }
-
return nand_read_buffer(offs, size, dest);
 }
 
-- 
2.7.4

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

[U-Boot] [PATCH 7/7] spl: nand: sunxi: add support for NAND config auto-detection

[Boris Brezillon]

NAND chips are supposed to expose their capabilities through advanced
mechanisms like READID, ONFI or JEDEC parameter tables. While those
methods are appropriate for the bootloader itself, it's way to
complicated and takes too much space to fit in the SPL.

Replace those mechanisms by a dumb 'trial and error' mechanism.

With this new approach we can get rid of the fixed config list that was
used in the sunxi NAND SPL driver.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 262 +-
 1 file changed, 204 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b43f2af..cc2e69b 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -103,6 +103,7 @@ struct nfc_config {
int addr_cycles;
int nseeds;
bool randomize;
+   bool valid;
 };
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
@@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
u32 offs)
return 0;
 }
 
+static int nand_reset_column(void)
+{
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
+  (1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static int nand_read_page(const struct nfc_config *conf, u32 offs,
  void *dest, int len)
 {
@@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config *conf, 
u32 offs,
return (val & 0x1) ? 1 : 0;
 }
 
-static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
+static int nand_max_ecc_strength(struct nfc_config *conf)
 {
-   void *end = dest + size;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
-   struct nfc_config conf = {
-   .page_size = page_size,
-   .ecc_size = ecc_page_size,
-   .addr_cycles = addr_cycles,
-   .nseeds = ARRAY_SIZE(random_seed),
-   .randomize = true,
-   };
+   static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
};
+   int max_oobsize, max_ecc_bytes;
+   int nsectors = conf->page_size / conf->ecc_size;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   conf.ecc_strength = i;
+   /*
+* ECC strength is limited by the size of the OOB area which is
+* correlated with the page size.
+*/
+   switch (conf->page_size) {
+   case 2048:
+   max_oobsize = 64;
+   break;
+   case 4096:
+   max_oobsize = 256;
+   break;
+   case 8196:
+   max_oobsize = 620;
+   break;
+   case 16384:
+   max_oobsize = 1664;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   max_ecc_bytes = max_oobsize / nsectors;
+
+   for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
+   if (ecc_bytes[i] > max_ecc_bytes)
break;
-   }
}
 
+   if (!i)
+   return -EINVAL;
 
-   nand_apply_config();
+   return i - 1;
+}
 
-   for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
-   if (nand_load_page(, offs))
-   return -1;
+static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
+ void *dest)
+{
+   /* NAND with pages > 4k will likely require 1k sector size. */
+   int min_ecc_size = conf->page_size > 4096 ? 1024 : 512;
+   int page = offs / conf->page_size;
+   int ret;
 
-   if (nand_read_page(, offs, dest, page_size))
-   return -1;
+   /*
+* In most cases, 1k sectors are preferred over 512b ones, start
+* testing this config first.
+*/
+   for (conf->ecc_size = 1024; conf->ecc_size >= min_ecc_size;
+conf->ecc_size >>= 1) {
+   int max_ecc_strength = nand_max_ecc_strength(conf);
+
+   nand_apply_config(conf);
+
+   /*
+* We are starting from the maximum ECC strength because
+* most of the time NAND vendors 

[U-Boot] [PATCH 5/7] spl: nand: sunxi: rework status polling loop

[Boris Brezillon]

check_value_xxx() helpers are using a 1ms delay between each test, which
can be quite long for some operations (like a page read on an SLC NAND).
Since we don't have anything to do but to poll this register, reduce the
delay between each test to 1us.

While we're at it, rename the max_number_of_retries parameters and the
MAX_RETRIES macro into timeout_us and DEFAULT_TIMEOUT_US to reflect that
we're actually waiting a given amount of time and not only a number of
retries.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 13e6eab..55b3c8a 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,35 +119,31 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-#define MAX_RETRIES 10
+#define DEFAULT_TIMEOUT_US 10
 
 static int check_value_inner(int offset, int expected_bits,
-   int max_number_of_retries, int negation)
+int timeout_us, int negation)
 {
-   int retries = 0;
do {
int val = readl(offset) & expected_bits;
if (negation ? !val : val)
return 1;
-   mdelay(1);
-   retries++;
-   } while (retries < max_number_of_retries);
+   udelay(1);
+   } while (--timeout_us);
 
return 0;
 }
 
 static inline int check_value(int offset, int expected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, expected_bits,
-   max_number_of_retries, 0);
+   return check_value_inner(offset, expected_bits, timeout_us, 0);
 }
 
 static inline int check_value_negated(int offset, int unexpected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, unexpected_bits,
-   max_number_of_retries, 1);
+   return check_value_inner(offset, unexpected_bits, timeout_us, 1);
 }
 
 void nand_init(void)
@@ -162,7 +158,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CTL);
 
if (!check_value_negated(SUNXI_NFC_BASE + NFC_CTL,
-NFC_CTL_RESET, MAX_RETRIES)) {
+NFC_CTL_RESET, DEFAULT_TIMEOUT_US)) {
printf("Couldn't initialize nand\n");
}
 
@@ -172,7 +168,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error timeout waiting for nand reset\n");
return;
}
@@ -260,14 +256,15 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error while initializing dma interrupt\n");
return -1;
}
writel(NFC_ST_DMA_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
-SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
+SUNXI_DMA_DDMA_CFG_REG_LOADING,
+DEFAULT_TIMEOUT_US)) {
printf("Error while waiting for dma transfer to finish\n");
return -1;
}
-- 
2.7.4

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

[U-Boot] [PATCH 6/7] spl: nand: sunxi: split 'load page' and 'read page' logic

[Boris Brezillon]

Split the 'load page' and 'read page' logic in 2 different functions so
we can later load the page and test different ECC configs without the
penalty of reloading the same page in the NAND cache.

We also move common setup to a dedicated function (nand_apply_config()) to
avoid rewriting the same values in NFC registers each time we read a page.

These new functions are passed a pointer to an nfc_config struct to limit
the number of parameters.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 185 +++---
 1 file changed, 114 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 55b3c8a..b43f2af 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -66,6 +66,8 @@
 #define NFC_ROW_AUTO_INC   (1 << 27)
 #define NFC_SEND_CMD3  (1 << 28)
 #define NFC_SEND_CMD4  (1 << 29)
+#define NFC_RAW_CMD(0 << 30)
+#define NFC_PAGE_CMD   (2 << 30)
 
 #define NFC_ST_CMD_INT_FLAG(1 << 1)
 #define NFC_ST_DMA_INT_FLAG(1 << 2)
@@ -78,9 +80,6 @@
 #define NFC_CMD_RNDOUT 0x05
 #define NFC_CMD_READSTART  0x30
 
-
-#define NFC_PAGE_CMD   (2 << 30)
-
 #define SUNXI_DMA_CFG_REG0  0x300
 #define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
 #define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
@@ -97,6 +96,15 @@
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
 
+struct nfc_config {
+   int page_size;
+   int ecc_strength;
+   int ecc_size;
+   int addr_cycles;
+   int nseeds;
+   bool randomize;
+};
+
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
 /* random seed used by linux */
@@ -175,50 +183,70 @@ void nand_init(void)
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 }
 
-static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
+static void nand_apply_config(const struct nfc_config *conf)
 {
-   uint32_t val;
-   int i, ecc_off = 0;
-   uint16_t ecc_mode = 0;
-   uint16_t rand_seed;
-   uint32_t page;
-   uint16_t column;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+   u32 val;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   ecc_mode = i;
-   break;
-   }
+   val = readl(SUNXI_NFC_BASE + NFC_CTL);
+   val &= ~NFC_CTL_PAGE_SIZE_MASK;
+   writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
+  SUNXI_NFC_BASE + NFC_CTL);
+   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
+   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
+}
+
+static int nand_load_page(const struct nfc_config *conf, u32 offs)
+{
+   int page = offs / conf->page_size;
+
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(((page & 0x) << 16), SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
+   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
+  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -EIO;
}
 
-   /* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
-   /* HW ECC always work with even numbers of ECC bytes */
-   ecc_off += (ecc_off & 1);
-   ecc_off += 4; /* prepad */
+   return 0;
+}
+
+static int nand_read_page(const struct nfc_config *conf, u32 offs,
+ void *dest, int len)
+{
+   dma_addr_t dst = (dma_addr_t)dest;
+   int nsectors = len / conf->ecc_size;
+   u16 rand_seed;
+   u32 val;
+   int page;
+
+   page = offs / conf->page_size;
 
-   page = real_addr / page_size;
-   column = real_addr % page_size;
+   if (offs % conf->page_size || len % conf->ecc_size ||
+   len > conf->page_size || len < 0)
+   return -EINVAL;
 
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % conf->nseeds];
 

[U-Boot] [PATCH 1/7] spl: nand: sunxi: remove support for so-called 'syndrome' mode

[Boris Brezillon]

The sunxi SPL NAND controller driver supports use 'BootROM'-like configs,
that is, configs where the ECC bytes and real data are interleaved in the
page instead of putting ECC bytes in the OOB area.

Doing that has several drawbacks:
- since you're interleaving data and ECC bytes you can't use the whole page
  otherwise you might override the bad block marker with non-FF bytes.
- to solve the bad block marker problem, the ROM code supports partially
  using the page, but this introduces a huge penalty both in term of read
  speed and NAND memory usage. While this is fine for rather small
  binaries(like the SPL one which is at maximum 24KB large), it becomes
  non-negligible for the bootloader image (several hundred of KB).
- auto-detection of the page size is not reliable (this is in my opinion
  the biggest problem). If you get the page size wrong, you'll end up
  reading data at a different offset than what was specified by the caller
  and the reading may succeed (if valid data were written at this address).

For all those reasons I think it's wiser to completely remove support for
'syndrome' configs. If we ever need to support it again, then I'd recommend
specifying all the config parameters through Kconfig options.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 56 ++-
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b0e07aa..1739da2 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,9 +119,6 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-/* random seed used for syndrome calls */
-const uint16_t random_seed_syndrome = 0x4a80;
-
 #define MAX_RETRIES 10
 
 static int check_value_inner(int offset, int expected_bits,
@@ -183,7 +180,7 @@ void nand_init(void)
 }
 
 static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -209,17 +206,11 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
page = real_addr / page_size;
column = real_addr % page_size;
 
-   if (syndrome)
-   column += (column / ecc_page_size) * ecc_off;
-
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   if (syndrome)
-   rand_seed = random_seed_syndrome;
-   else
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % 128];
 
writel((rand_seed << 16) | NFC_ECC_RANDOM_EN | NFC_ECC_EN
| NFC_ECC_PIPELINE | (ecc_mode << 12),
@@ -228,9 +219,8 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome)
-   writel(page_size + (column / ecc_page_size) * ecc_off,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
@@ -266,7 +256,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
NFC_PAGE_CMD | NFC_WAIT_FLAG |
((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
-   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
+   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
@@ -292,7 +282,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
 }
 
 static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest, int syndrome)
+   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
 {
void *end = dest + size;
 
@@ -301,16 +291,14 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 
for ( ;dest < end; dest += ecc_page_size, offs += ecc_page_size) {
if (nand_read_page(page_size, ecc_strength, ecc_page_size,
-  addr_cycles, offs, (dma_addr_t)dest,
-  syndrome))
+  addr_cycles, offs, (dma_addr_t)dest))
return -1;
}
 
return 0;
 }
 
-static int nand_read_buffer(uint32_t offs, unsigned int size, void *dest,
-

[U-Boot] [PATCH 0/7] spl: nand: sunxi: implement auto-detection

[Boris Brezillon]

Hello,

This patch series aims at adding support for NAND auto-detection to
the sunxi SPL NAND driver.

As explained in patch 7, this auto-detection is nothing more than a
dumb "trial and error" logic, but it allows one to use the same
SPL binary for all kind of sunxi boards booting from NAND.
Of course, this approach might increase a bit the boot-time, but this
is something we could address by adding a "default NAND config",
that would be tested before launching the auto-detection procedure.

Now let's detail a bit what's inside this patch-set.
Patch 1 is a cleanup removing support for BootROM configs, which in
my opinion are not only inefficient but also not reliable (at least
the current implementation does not guarantee that you'll be using
the correct configuration when reading the NAND).

Piotr, Hans, any comment?
Is this a real problem if we get rid of syndrome/BootROM configs?
I mean, are you really using this mode? If that's not the case, I'd
prefer dropping support for this feature. ITOH, if you really
need this mode, then I'd recommend adding Kconfig options to specify
the exact config to be used rather than randomly testing configs
(see my explanation in patch 1).

Patch 2 is renaming the SYS_NAND_U_BOOT_OFFS Kconfig option to make it
usable on all platforms (not only sunxi) and avoid conflicts when
one board is defining CONFIG_SYS_NAND_U_BOOT_OFFS in its
include/configs/.h header.

Patch 3 is adding generic support for redundant u-boot images, which
is particularly useful on modern NANDs where corruptions is likely to
happen.
Patch 4 is just getting rid of the open-coded version of redundant
u-boot image support in the sunxi NAND driver.

Patch 5 is a simple improvement of the NAND controller status polling
loop, which is really important to make the "trial and error"
approach efficient (we try to limit the impact on boot-time here).
Patch 6 and 7 are implementing the auto-detection logic.


Best Regards,

Boris

Boris Brezillon (7):
  spl: nand: sunxi: remove support for so-called 'syndrome' mode
  spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
  spl: nand: support redundant u-boot image
  spl: nand: sunxi: stop guessing the redundant u-boot offset
  spl: nand: sunxi: rework status polling loop
  spl: nand: sunxi: split 'load page' and 'read page' logic
  spl: nand: sunxi: add support for NAND config auto-detection

 common/spl/spl_nand.c |  12 +
 drivers/mtd/nand/Kconfig  |  15 +-
 drivers/mtd/nand/sunxi_nand_spl.c | 480 --
 3 files changed, 332 insertions(+), 175 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH] ARM: zynq: Simplify zynq configuration

[Michal Simek]

Extending Kconfig for adding new platform is a lot of work
for nothing. Setting SYS_CONFIG_NAME directly in Kconfig and
remove all dependencies on TARGET_ZYNQ_* options including SPL.
As a side-effect it also remove custom init folder for ps7_init_gpl.*
files. Folder is choosed based on device-tree file.

Signed-off-by: Michal Simek 
---

 arch/arm/mach-zynq/Kconfig | 48 +++---
 board/xilinx/zynq/Makefile | 12 +-
 board/xilinx/zynq/custom_hw_platform/.gitignore|  1 -
 .../ps7_init_gpl.c |  0
 .../ps7_init_gpl.h |  0
 .../ps7_init_gpl.c |  0
 .../ps7_init_gpl.h |  0
 .../ps7_init_gpl.c |  0
 .../ps7_init_gpl.h |  0
 .../{zed_hw_platform => zynq-zed}/ps7_init_gpl.c   |  0
 .../{zed_hw_platform => zynq-zed}/ps7_init_gpl.h   |  0
 .../{zybo_hw_platform => zynq-zybo}/ps7_init_gpl.c |  0
 .../{zybo_hw_platform => zynq-zybo}/ps7_init_gpl.h |  0
 configs/zynq_microzed_defconfig|  2 +-
 configs/zynq_picozed_defconfig |  2 +-
 configs/zynq_zc702_defconfig   |  1 +
 configs/zynq_zc706_defconfig   |  2 +-
 configs/zynq_zc770_xm010_defconfig |  2 +-
 configs/zynq_zc770_xm011_defconfig |  2 +-
 configs/zynq_zc770_xm012_defconfig |  2 +-
 configs/zynq_zc770_xm013_defconfig |  2 +-
 configs/zynq_zed_defconfig |  2 +-
 configs/zynq_zybo_defconfig|  2 +-
 23 files changed, 17 insertions(+), 63 deletions(-)
 delete mode 100644 board/xilinx/zynq/custom_hw_platform/.gitignore
 rename board/xilinx/zynq/{MicroZed_hw_platform => 
zynq-microzed}/ps7_init_gpl.c (100%)
 rename board/xilinx/zynq/{MicroZed_hw_platform => 
zynq-microzed}/ps7_init_gpl.h (100%)
 rename board/xilinx/zynq/{ZC702_hw_platform => zynq-zc702}/ps7_init_gpl.c 
(100%)
 rename board/xilinx/zynq/{ZC702_hw_platform => zynq-zc702}/ps7_init_gpl.h 
(100%)
 rename board/xilinx/zynq/{ZC706_hw_platform => zynq-zc706}/ps7_init_gpl.c 
(100%)
 rename board/xilinx/zynq/{ZC706_hw_platform => zynq-zc706}/ps7_init_gpl.h 
(100%)
 rename board/xilinx/zynq/{zed_hw_platform => zynq-zed}/ps7_init_gpl.c (100%)
 rename board/xilinx/zynq/{zed_hw_platform => zynq-zed}/ps7_init_gpl.h (100%)
 rename board/xilinx/zynq/{zybo_hw_platform => zynq-zybo}/ps7_init_gpl.c (100%)
 rename board/xilinx/zynq/{zybo_hw_platform => zynq-zybo}/ps7_init_gpl.h (100%)

diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index d396a13b6f7c..db3c5792939e 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -1,41 +1,5 @@
 if ARCH_ZYNQ
 
-config ZYNQ_CUSTOM_INIT
-   bool "Use custom ps7_init provided by Xilinx tool"
-   help
- U-Boot includes ps7_init_gpl.[ch] for some Zynq board variants.
- If you want to override them with customized ones
- or ps7_init code for your board is missing, please say Y here
- and add ones into board/xilinx/zynq/custom_hw_platform/ directory.
-
-choice
-   prompt "Xilinx Zynq board select"
-   default TARGET_ZYNQ_ZC702
-
-config TARGET_ZYNQ_ZED
-   bool "Zynq ZedBoard"
-
-config TARGET_ZYNQ_MICROZED
-   bool "Zynq MicroZed"
-
-config TARGET_ZYNQ_PICOZED
-   bool "Zynq PicoZed"
-
-config TARGET_ZYNQ_ZC702
-   bool "Zynq ZC702 Board"
-
-config TARGET_ZYNQ_ZC706
-   bool "Zynq ZC706 Board"
-
-config TARGET_ZYNQ_ZC770
-   bool "Zynq ZC770 Board"
-   select ZYNQ_CUSTOM_INIT
-
-config TARGET_ZYNQ_ZYBO
-   bool "Zynq Zybo Board"
-
-endchoice
-
 config SYS_BOARD
default "zynq"
 
@@ -46,11 +10,11 @@ config SYS_SOC
default "zynq"
 
 config SYS_CONFIG_NAME
-   default "zynq_zed" if TARGET_ZYNQ_ZED
-   default "zynq_microzed" if TARGET_ZYNQ_MICROZED
-   default "zynq_picozed" if TARGET_ZYNQ_PICOZED
-   default "zynq_zc70x" if TARGET_ZYNQ_ZC702 || TARGET_ZYNQ_ZC706
-   default "zynq_zc770" if TARGET_ZYNQ_ZC770
-   default "zynq_zybo" if TARGET_ZYNQ_ZYBO
+   string "Board configuration name"
+   default "zynq-common"
+   help
+ This option contains information about board configuration name.
+ Based on this option include/configs/.h header
+ will be used for board configuration.
 
 endif
diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile
index eab93038cefe..7de0212bc9f7 100644
--- a/board/xilinx/zynq/Makefile
+++ b/board/xilinx/zynq/Makefile
@@ -7,17 +7,7 @@
 
 obj-y  := board.o
 
-# Copied from Xilinx SDK 2014.4
-hw-platform-$(CONFIG_TARGET_ZYNQ_ZED)  := zed_hw_platform
-hw-platform-$(CONFIG_TARGET_ZYNQ_MICROZED) := MicroZed_hw_platform
-hw-platform-$(CONFIG_TARGET_ZYNQ_ZC702):= 

Re: [U-Boot] [PATCH 2/2] tools: env: Add support for direct read/write UBI volumes

[Marcin Niestroj]

On 06.05.2016 14:58, Marcin Niestroj wrote:

Up to now we were able to read/write environment data from/to UBI
volumes only indirectly by gluebi driver. This driver creates NAND MTD
on top of UBI volumes, which is quite a workaroung for this use case.

Add support for direct read/write UBI volumes in order to not use
obsolete gluebi driver.

Signed-off-by: Marcin Niestroj 
---
 tools/env/fw_env.c  | 249 +++-
 tools/env/fw_env.config |   8 ++
 2 files changed, 256 insertions(+), 1 deletion(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index b4b542a..0e977e3 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 

 #ifdef MTD_OLD
 # include 
@@ -33,6 +34,8 @@
 # include 
 #endif

+#include 
+
 #include "fw_env.h"

 struct common_args common_args;
@@ -54,6 +57,7 @@ struct envdev_s {
ulong erase_size;   /* device erase size */
ulong env_sectors;  /* number of environment sectors */
uint8_t mtd_type;   /* type of the MTD device */
+   int is_ubi; /* set if we use UBI volume */
 };

 static struct envdev_s envdevices[2] =
@@ -72,6 +76,7 @@ static int dev_current;
 #define DEVESIZE(i)   envdevices[(i)].erase_size
 #define ENVSECTORS(i) envdevices[(i)].env_sectors
 #define DEVTYPE(i)envdevices[(i)].mtd_type
+#define IS_UBI(i) envdevices[(i)].is_ubi

 #define CUR_ENVSIZE ENVSIZE(dev_current)

@@ -117,6 +122,229 @@ static unsigned char obsolete_flag = 0;
 #define DEFAULT_ENV_INSTANCE_STATIC
 #include 

+#define UBI_DEV_START "/dev/ubi"
+#define UBI_SYSFS "/sys/class/ubi"
+#define UBI_VOL_NAME_PATT "ubi%d_%d"
+
+static int is_ubi_devname(const char *devname)
+{
+   return !strncmp(devname, UBI_DEV_START, sizeof(UBI_DEV_START) - 1);
+}
+
+static int ubi_check_volume_sysfs_name(const char *volume_sysfs_name,
+   const char *volname)
+{
+   char path[256];
+   FILE *file;
+   char *name;
+   int ret;
+
+   strcpy(path, UBI_SYSFS "/");
+   strcat(path, volume_sysfs_name);
+   strcat(path, "/name");
+
+   file = fopen(path, "r");
+   if (!file)
+   return -1;
+
+   ret = fscanf(file, "%ms", );
+   fclose(file);
+   if (ret <= 0 || !name) {
+   fprintf(stderr,
+   "Failed to read from file %s, ret = %d, name = %s\n",
+   path, ret, name);
+   return -1;
+   }
+
+   if (!strcmp(name, volname)) {
+   free(name);
+   return 0;
+   }
+   free(name);
+
+   return -1;
+}
+
+static int ubi_get_volnum_by_name(int devnum, const char *volname)
+{
+   DIR *sysfs_ubi;
+   struct dirent *dirent;
+   int ret;
+   int tmp_devnum;
+   int volnum;
+
+   sysfs_ubi = opendir(UBI_SYSFS);
+   if (!sysfs_ubi)
+   return -1;
+
+#ifdef DEBUG
+   fprintf(stderr, "Looking for volume name \"%s\"\n", volname);
+#endif
+
+   while (1) {
+   dirent = readdir(sysfs_ubi);
+   if (!dirent)
+   return -1;
+
+   ret = sscanf(dirent->d_name, UBI_VOL_NAME_PATT,
+   _devnum, );
+   if (ret == 2 && devnum == tmp_devnum) {
+   if (ubi_check_volume_sysfs_name(dirent->d_name,
+   volname) == 0)
+   return volnum;
+   }
+   }
+
+   return -1;
+}
+
+static int ubi_get_devnum_by_devname(const char *devname)
+{
+   int devnum;
+   int ret;
+
+   ret = sscanf(devname + sizeof(UBI_DEV_START) - 1, "%d", );
+   if (ret != 1)
+   return -1;
+
+   return devnum;
+}
+
+static const char *ubi_get_volume_devname(const char *devname,
+   const char *volname)
+{
+   char *volume_devname;
+   int volnum;
+   int devnum;
+   int ret;
+
+   devnum = ubi_get_devnum_by_devname(devname);
+   if (devnum < 0)
+   return NULL;
+
+   volnum = ubi_get_volnum_by_name(devnum, volname);
+   if (volnum < 0)
+   return NULL;
+
+   ret = asprintf(_devname, "%s_%d", devname, volnum);
+   if (ret < 0)
+   return NULL;
+
+#ifdef DEBUG
+   fprintf(stderr, "Found ubi volume \"%s:%s\" -> %s\n",
+   devname, volname, volume_devname);
+#endif
+
+   return volume_devname;
+}
+
+static void ubi_check_dev(unsigned int dev_id)
+{
+   char *devname = (char *) DEVNAME(dev_id);
+   char *pname;
+   const char *volname = NULL;
+   const char *volume_devname;
+
+   if (!is_ubi_devname(DEVNAME(dev_id)))
+   return;
+
+   IS_UBI(dev_id) = 1;
+
+   for (pname = devname; *pname != '\0'; pname++) {
+ 

Re: [U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Marek, Tim,

On 20/05/2016 15:16, Marek Vasut wrote:

>> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
>> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
>> config? It looks like the novena board was the only one using it and
>> it breaks Ventana build.
> 
> I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
> ventana. If we have FS boot, we should push for filesystems which are
> not a patent minefield (like fat).
> 
> So what about adding this to ventana:
> #undef CONFIG_SPL_EXT_SUPPORT

Agree. This makes sense. We set as common rules what most boards need,
if that let us the way to disable for some boards. The way described by
Marek does this.

>>> It's it used during HAB ? It might be some area used by the crypto
>>> coprocessor or somesuch.
>>
>> That's a good question. Are you using HAB anywhere or anyone else we
>> know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE
>> to 0x0090?
> 
> I am not using HAB on mx6, I think there was only one user of it ever.

HAB remains a use case, but I cannot find in the manual any reference
for the IRAM (if any) it needs.

Regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/2] tools: env: Fix format warnings in debug

[Marcin Niestroj]

ping

On 06.05.2016 14:58, Marcin Niestroj wrote:

Format warnings (-Wformat) were shown in printf() calls after defining
DEBUG macro.

Update format string and explicitly cast variables to suppress all
warnings.

Signed-off-by: Marcin Niestroj 
---
 tools/env/fw_env.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 06cf63d..b4b542a 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -649,8 +649,8 @@ static int flash_bad_block (int fd, uint8_t mtd_type, 
loff_t *blockstart)

if (badblock) {
 #ifdef DEBUG
-   fprintf (stderr, "Bad block at 0x%llx, "
-"skipping\n", *blockstart);
+   fprintf (stderr, "Bad block at 0x%llx, skipping\n",
+   (unsigned long long) *blockstart);
 #endif
return badblock;
}
@@ -737,7 +737,8 @@ static int flash_read_buf (int dev, int fd, void *buf, 
size_t count,
}
 #ifdef DEBUG
fprintf(stderr, "Read 0x%x bytes at 0x%llx on %s\n",
-rc, blockstart + block_seek, DEVNAME(dev));
+   rc, (unsigned long long) blockstart + block_seek,
+   DEVNAME(dev));
 #endif
processed += readlen;
readlen = min (blocklen, count - processed);
@@ -835,8 +836,9 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
if (block_seek + count != write_total) {
if (block_seek != 0)
fprintf(stderr, " and ");
-   fprintf(stderr, "0x%lx - 0x%x",
-   block_seek + count, write_total - 1);
+   fprintf(stderr, "0x%lx - 0x%lx",
+   (unsigned long) block_seek + count,
+   (unsigned long) write_total - 1);
}
fprintf(stderr, "\n");
 #endif
@@ -899,8 +901,9 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
}

 #ifdef DEBUG
-   fprintf(stderr, "Write 0x%x bytes at 0x%llx\n", erasesize,
-   blockstart);
+   fprintf(stderr, "Write 0x%llx bytes at 0x%llx\n",
+   (unsigned long long) erasesize,
+   (unsigned long long) blockstart);
 #endif
if (write (fd, data + processed, erasesize) != erasesize) {
fprintf (stderr, "Write error on %s: %s\n",



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

Re: [U-Boot] [PATCH v1 01/12] common: bootdelay: move CONFIG_BOOTDELAY into a Kconfig option

[Daniel Schwierzeck]

Am 20.05.2016 um 15:09 schrieb Tom Rini:
> On Wed, May 18, 2016 at 04:18:27PM +0200, Heiko Schocher wrote:
> 
>> move CONFIG_BOOTDELAY into a Kconfig option. Used for this
>> purpose the moveconfig.py tool in tools.
>>
>> Signed-off-by: Heiko Schocher 
> 
> So, my question here is did you do a buildman -S (sizes) before/after
> this patch?  That's the hard part of moveconfig.py migrations, making
> sure that in the end everyone is still the same.  Since the cover letter
> talks about ARM only, I'll do that shortly and let you know, thanks!
> 

could you postpone and refresh this patch after the merge window has
closed? I have queued support for new SoC's and boards in
u-boot-mips/next for which I want to send a PR soon. But merging new
boards after such a patch is problematic. I guess other archs also have
queued support for new boards.

-- 
- Daniel



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

Re: [U-Boot] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 03:10 PM, Tim Harvey wrote:
> On Fri, May 20, 2016 at 5:50 AM, Marek Vasut  wrote:
>> On 05/20/2016 02:41 PM, Stefano Babic wrote:
>>> Hi Tim,
>>>
>>> On 19/05/2016 16:34, Tim Harvey wrote:
 On Thu, May 19, 2016 at 7:05 AM, Stefano Babic  wrote:
> Hi Tim,
>
> On 19/05/2016 15:48, Tim Harvey wrote:
>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic  wrote:
>>> Hi Tim,
>>>
>>> last changes break build for the gw_ventana board. In fact, in case
>>> kernel is on a fs, we need to pass the name for kernel.  These two
>>> defines should be set into gw_ventana.h:
>>>
>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME
>>> CONFIG_SPL_FS_LOAD_ARGS_NAME
>>>
>>> I could simply fix it, but it does not make sense without asking you :-)
>>>
>>> I have also seen that SPL for gw_ventana raises an exception because SPL
>>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>>> mx6 with smaller SRAM has at least 128KB.
>>>
>>
>> Stefano,
>>
>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>> branch with some patches on top that I haven't had time to mainline
>> yet.
>>
>> When you say 'last changes' was there something specific? Something
>> must of grown the size of the SPL code quite a bit.
>
> I think (but I am not sure) the biggest increase was done by allowing to
> load image directly from filesystem, and then the size increased.
>
> But I admit I did not take a closer look before - it looks like that
> gw_ventana is the first to fail, just because it supports more methods
> for booting. Most boards boots just from one media,
>

 That makes sense.

 Looking at my notes (again this is based on 2015.04) I found the
 following increases in SPL:

 base+serial+i2c: 23K
 +mmc: +12K
 +nand: +8K
 +gpio: +4K
 +env: +12K (big!)
 +fat: +4K
 +ext: +8K
 +fastboot: +4K

 These numbers were with backported thumb binary support (without it
 they get much more inflated).

 My SPL is at 63K currently but that is largely because I'm including
 nand+mmc and env (both env from nand and from mmc) with the help of a
 patch to allow either env that didn't get accepted upstream (because
 of the desire to re-write the env code for DM). I was after a single
 SPL that could handle a NAND or MMC boot device.

 I don't include fs support simply because I didn't have the room so if
 that truly was added I can see how that through it over the edge.

 I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
 just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
 me that should be in the board config file(s) where needed and not in
 the general SPL config file, otherwise your adding support that some
 boards (like ventana!) don't have room for.

>>>
>>> Yes, agree - this should be splitted and moved to board config files.
> 
> Marek,
> 
> Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
> submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
> config? It looks like the novena board was the only one using it and
> it breaks Ventana build.

I would much rather see explicit disable of CONFIG_SPL_EXT_SUPPORT for
ventana. If we have FS boot, we should push for filesystems which are
not a patent minefield (like fat).

So what about adding this to ventana:
#undef CONFIG_SPL_EXT_SUPPORT

>>>
>> Take a look at my comments at
>> the top of include/configs/imx6_spl.h and let me know if you find
>> something wrong with my analysis that led to a 64KB max.
>
> Nothing wrong, but as far as I know in start.S cache and muu are turned
> off, and they are turned on later again. This could let us to reuse
> maybe the 24KB space previously set by the Bootrom

 they may be turned off by the time we get to U-Boot SPL or within
 U-Boot SPL but the question is 'does the boot ROM need them?'. I
 suppose its not too difficult to test by artificially growing the SPL
 with random/zero'd data and letting it clobber the 24KB shown for the
 MMU table.
>>>
>>> Right - and it should be very nice to know what happens to the
>>> "reserved" area (0x90 - 0x96). From some simple tests, it looks
>>> like that the Boot ROM does not use it - but it is marked as reserved in
>>> the manual, and for this reason it was never used, but I am now
>>> speculating if the space can be taken for our purposes.
>>
>> It's it used during HAB ? It might be some area used by the crypto
>> coprocessor or somesuch.
> 
> That's a good question. Are you using HAB 

Re: [U-Boot] Breakage on gw_ventana

[Tim Harvey]

On Fri, May 20, 2016 at 5:50 AM, Marek Vasut  wrote:
> On 05/20/2016 02:41 PM, Stefano Babic wrote:
>> Hi Tim,
>>
>> On 19/05/2016 16:34, Tim Harvey wrote:
>>> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic  wrote:
 Hi Tim,

 On 19/05/2016 15:48, Tim Harvey wrote:
> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic  wrote:
>> Hi Tim,
>>
>> last changes break build for the gw_ventana board. In fact, in case
>> kernel is on a fs, we need to pass the name for kernel.  These two
>> defines should be set into gw_ventana.h:
>>
>> CONFIG_SPL_FS_LOAD_KERNEL_NAME
>> CONFIG_SPL_FS_LOAD_ARGS_NAME
>>
>> I could simply fix it, but it does not make sense without asking you :-)
>>
>> I have also seen that SPL for gw_ventana raises an exception because SPL
>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
>> mx6 with smaller SRAM has at least 128KB.
>>
>
> Stefano,
>
> Thanks for the heads-up. I have to admit I haven't looked at mainline
> u-boot on Ventana for quite some time - I'm still using a 2015-04
> branch with some patches on top that I haven't had time to mainline
> yet.
>
> When you say 'last changes' was there something specific? Something
> must of grown the size of the SPL code quite a bit.

 I think (but I am not sure) the biggest increase was done by allowing to
 load image directly from filesystem, and then the size increased.

 But I admit I did not take a closer look before - it looks like that
 gw_ventana is the first to fail, just because it supports more methods
 for booting. Most boards boots just from one media,

>>>
>>> That makes sense.
>>>
>>> Looking at my notes (again this is based on 2015.04) I found the
>>> following increases in SPL:
>>>
>>> base+serial+i2c: 23K
>>> +mmc: +12K
>>> +nand: +8K
>>> +gpio: +4K
>>> +env: +12K (big!)
>>> +fat: +4K
>>> +ext: +8K
>>> +fastboot: +4K
>>>
>>> These numbers were with backported thumb binary support (without it
>>> they get much more inflated).
>>>
>>> My SPL is at 63K currently but that is largely because I'm including
>>> nand+mmc and env (both env from nand and from mmc) with the help of a
>>> patch to allow either env that didn't get accepted upstream (because
>>> of the desire to re-write the env code for DM). I was after a single
>>> SPL that could handle a NAND or MMC boot device.
>>>
>>> I don't include fs support simply because I didn't have the room so if
>>> that truly was added I can see how that through it over the edge.
>>>
>>> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
>>> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
>>> me that should be in the board config file(s) where needed and not in
>>> the general SPL config file, otherwise your adding support that some
>>> boards (like ventana!) don't have room for.
>>>
>>
>> Yes, agree - this should be splitted and moved to board config files.

Marek,

Could you revert 291000894ed4d6257830baba547764b86e335b5c and/or
submit a patch to move CONFIG_SPL_EXT_SUPPORT back into the board
config? It looks like the novena board was the only one using it and
it breaks Ventana build.

>>
> Take a look at my comments at
> the top of include/configs/imx6_spl.h and let me know if you find
> something wrong with my analysis that led to a 64KB max.

 Nothing wrong, but as far as I know in start.S cache and muu are turned
 off, and they are turned on later again. This could let us to reuse
 maybe the 24KB space previously set by the Bootrom
>>>
>>> they may be turned off by the time we get to U-Boot SPL or within
>>> U-Boot SPL but the question is 'does the boot ROM need them?'. I
>>> suppose its not too difficult to test by artificially growing the SPL
>>> with random/zero'd data and letting it clobber the 24KB shown for the
>>> MMU table.
>>
>> Right - and it should be very nice to know what happens to the
>> "reserved" area (0x90 - 0x96). From some simple tests, it looks
>> like that the Boot ROM does not use it - but it is marked as reserved in
>> the manual, and for this reason it was never used, but I am now
>> speculating if the space can be taken for our purposes.
>
> It's it used during HAB ? It might be some area used by the crypto
> coprocessor or somesuch.

That's a good question. Are you using HAB anywhere or anyone else we
know of using SPL and HAB that can test setting CONFIG_SPL_TEXT_BASE
to 0x0090?

Regards,

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

Re: [U-Boot] [PATCH v1 01/12] common: bootdelay: move CONFIG_BOOTDELAY into a Kconfig option

[Tom Rini]

On Wed, May 18, 2016 at 04:18:27PM +0200, Heiko Schocher wrote:

> move CONFIG_BOOTDELAY into a Kconfig option. Used for this
> purpose the moveconfig.py tool in tools.
> 
> Signed-off-by: Heiko Schocher 

So, my question here is did you do a buildman -S (sizes) before/after
this patch?  That's the hard part of moveconfig.py migrations, making
sure that in the end everyone is still the same.  Since the cover letter
talks about ARM only, I'll do that shortly and let you know, 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 10/15] ti_omap5_common: Update SPL start address on secure parts

[Tom Rini]

On Thu, May 19, 2016 at 07:10:50PM -0500, Daniel Allred wrote:

> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
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] SPL: fat: Fix spl_parse_image_header() return value handling

[Tom Rini]

On Fri, May 20, 2016 at 01:45:24AM +0200, Marek Vasut wrote:

> The spl_parse_image_header() can return 0 and it is not an error.
> Only treat non-zero return value as an error.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Tom Rini 

Reviewed-by: Tom Rini 

-- 
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] ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz

[Tom Rini]

On Fri, May 20, 2016 at 04:11:22PM +0530, Vignesh R wrote:

> According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
> DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
> MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
> throughput.
> 
> Signed-off-by: Vignesh R 

Are older revs seen in the wild or just within TI?  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] Breakage on gw_ventana

[Marek Vasut]

On 05/20/2016 02:41 PM, Stefano Babic wrote:
> Hi Tim,
> 
> On 19/05/2016 16:34, Tim Harvey wrote:
>> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic  wrote:
>>> Hi Tim,
>>>
>>> On 19/05/2016 15:48, Tim Harvey wrote:
 On Thu, May 19, 2016 at 6:02 AM, Stefano Babic  wrote:
> Hi Tim,
>
> last changes break build for the gw_ventana board. In fact, in case
> kernel is on a fs, we need to pass the name for kernel.  These two
> defines should be set into gw_ventana.h:
>
> CONFIG_SPL_FS_LOAD_KERNEL_NAME
> CONFIG_SPL_FS_LOAD_ARGS_NAME
>
> I could simply fix it, but it does not make sense without asking you :-)
>
> I have also seen that SPL for gw_ventana raises an exception because SPL
> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
> mx6 with smaller SRAM has at least 128KB.
>

 Stefano,

 Thanks for the heads-up. I have to admit I haven't looked at mainline
 u-boot on Ventana for quite some time - I'm still using a 2015-04
 branch with some patches on top that I haven't had time to mainline
 yet.

 When you say 'last changes' was there something specific? Something
 must of grown the size of the SPL code quite a bit.
>>>
>>> I think (but I am not sure) the biggest increase was done by allowing to
>>> load image directly from filesystem, and then the size increased.
>>>
>>> But I admit I did not take a closer look before - it looks like that
>>> gw_ventana is the first to fail, just because it supports more methods
>>> for booting. Most boards boots just from one media,
>>>
>>
>> That makes sense.
>>
>> Looking at my notes (again this is based on 2015.04) I found the
>> following increases in SPL:
>>
>> base+serial+i2c: 23K
>> +mmc: +12K
>> +nand: +8K
>> +gpio: +4K
>> +env: +12K (big!)
>> +fat: +4K
>> +ext: +8K
>> +fastboot: +4K
>>
>> These numbers were with backported thumb binary support (without it
>> they get much more inflated).
>>
>> My SPL is at 63K currently but that is largely because I'm including
>> nand+mmc and env (both env from nand and from mmc) with the help of a
>> patch to allow either env that didn't get accepted upstream (because
>> of the desire to re-write the env code for DM). I was after a single
>> SPL that could handle a NAND or MMC boot device.
>>
>> I don't include fs support simply because I didn't have the room so if
>> that truly was added I can see how that through it over the edge.
>>
>> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
>> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
>> me that should be in the board config file(s) where needed and not in
>> the general SPL config file, otherwise your adding support that some
>> boards (like ventana!) don't have room for.
>>
> 
> Yes, agree - this should be splitted and moved to board config files.
> 
 Take a look at my comments at
 the top of include/configs/imx6_spl.h and let me know if you find
 something wrong with my analysis that led to a 64KB max.
>>>
>>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>>> off, and they are turned on later again. This could let us to reuse
>>> maybe the 24KB space previously set by the Bootrom
>>
>> they may be turned off by the time we get to U-Boot SPL or within
>> U-Boot SPL but the question is 'does the boot ROM need them?'. I
>> suppose its not too difficult to test by artificially growing the SPL
>> with random/zero'd data and letting it clobber the 24KB shown for the
>> MMU table.
> 
> Right - and it should be very nice to know what happens to the
> "reserved" area (0x90 - 0x96). From some simple tests, it looks
> like that the Boot ROM does not use it - but it is marked as reserved in
> the manual, and for this reason it was never used, but I am now
> speculating if the space can be taken for our purposes.

It's it used during HAB ? It might be some area used by the crypto
coprocessor or somesuch.


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

Re: [U-Boot] Breakage on gw_ventana

[Stefano Babic]

Hi Tim,

On 19/05/2016 16:34, Tim Harvey wrote:
> On Thu, May 19, 2016 at 7:05 AM, Stefano Babic  wrote:
>> Hi Tim,
>>
>> On 19/05/2016 15:48, Tim Harvey wrote:
>>> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic  wrote:
 Hi Tim,

 last changes break build for the gw_ventana board. In fact, in case
 kernel is on a fs, we need to pass the name for kernel.  These two
 defines should be set into gw_ventana.h:

 CONFIG_SPL_FS_LOAD_KERNEL_NAME
 CONFIG_SPL_FS_LOAD_ARGS_NAME

 I could simply fix it, but it does not make sense without asking you :-)

 I have also seen that SPL for gw_ventana raises an exception because SPL
 is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb).
 Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the
 mx6 with smaller SRAM has at least 128KB.

>>>
>>> Stefano,
>>>
>>> Thanks for the heads-up. I have to admit I haven't looked at mainline
>>> u-boot on Ventana for quite some time - I'm still using a 2015-04
>>> branch with some patches on top that I haven't had time to mainline
>>> yet.
>>>
>>> When you say 'last changes' was there something specific? Something
>>> must of grown the size of the SPL code quite a bit.
>>
>> I think (but I am not sure) the biggest increase was done by allowing to
>> load image directly from filesystem, and then the size increased.
>>
>> But I admit I did not take a closer look before - it looks like that
>> gw_ventana is the first to fail, just because it supports more methods
>> for booting. Most boards boots just from one media,
>>
> 
> That makes sense.
> 
> Looking at my notes (again this is based on 2015.04) I found the
> following increases in SPL:
> 
> base+serial+i2c: 23K
> +mmc: +12K
> +nand: +8K
> +gpio: +4K
> +env: +12K (big!)
> +fat: +4K
> +ext: +8K
> +fastboot: +4K
> 
> These numbers were with backported thumb binary support (without it
> they get much more inflated).
> 
> My SPL is at 63K currently but that is largely because I'm including
> nand+mmc and env (both env from nand and from mmc) with the help of a
> patch to allow either env that didn't get accepted upstream (because
> of the desire to re-write the env code for DM). I was after a single
> SPL that could handle a NAND or MMC boot device.
> 
> I don't include fs support simply because I didn't have the room so if
> that truly was added I can see how that through it over the edge.
> 
> I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was
> just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to
> me that should be in the board config file(s) where needed and not in
> the general SPL config file, otherwise your adding support that some
> boards (like ventana!) don't have room for.
> 

Yes, agree - this should be splitted and moved to board config files.

>>> Take a look at my comments at
>>> the top of include/configs/imx6_spl.h and let me know if you find
>>> something wrong with my analysis that led to a 64KB max.
>>
>> Nothing wrong, but as far as I know in start.S cache and muu are turned
>> off, and they are turned on later again. This could let us to reuse
>> maybe the 24KB space previously set by the Bootrom
> 
> they may be turned off by the time we get to U-Boot SPL or within
> U-Boot SPL but the question is 'does the boot ROM need them?'. I
> suppose its not too difficult to test by artificially growing the SPL
> with random/zero'd data and letting it clobber the 24KB shown for the
> MMU table.

Right - and it should be very nice to know what happens to the
"reserved" area (0x90 - 0x96). From some simple tests, it looks
like that the Boot ROM does not use it - but it is marked as reserved in
the manual, and for this reason it was never used, but I am now
speculating if the space can be taken for our purposes.

Stefano

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

[U-Boot] coding style question: when to use __weak function attributes?

[Robert P. J. Day]

  pardon yet another question on coding style and pedantry, but i'm
curious about the following. i'm crawling through the code in
common/image-fdt.c, specifically in image_setup_libfdt(), and first i
see the following:

  __weak int arch_fixup_fdt(void *blob)
  {
  return 0;
  }

  ... snip ...

if (arch_fixup_fdt(blob) < 0) {
printf("ERROR: arch-specific fdt fixup failed\n");
goto err;
}

which is perfectly understandable -- use the weak function attribute,
and let each architecture decide if it wants to override that. same
thing here in that same file:

  __weak int ft_verify_fdt(void *fdt)
  {
  return 1;
  }

  ... snip ...

if (!ft_verify_fdt(blob))
goto err;

which then makes me wonder why the same approach wasn't used for these
routines as well:

if (IMAGE_OF_BOARD_SETUP) {
fdt_ret = ft_board_setup(blob, gd->bd);
if (fdt_ret) {
printf("ERROR: board-specific fdt fixup failed: %s\n",
   fdt_strerror(fdt_ret));
goto err;
}
}
if (IMAGE_OF_SYSTEM_SETUP) {
fdt_ret = ft_system_setup(blob, gd->bd);
if (fdt_ret) {
printf("ERROR: system-specific fdt fixup failed: %s\n",
   fdt_strerror(fdt_ret));
goto err;
}
}

couldn't ft_board_setup() and ft_system_setup() have been defined the
same way? or is there something different about those two routines
that wouldn't allow the weak function attribute and do away with all
the OF_BOARD_SETUP and OF_SYSTEM_SETUP usage?

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] board: ge: bx50v3: don't configure the backlight when there's no display

[Andrew Shadura]

Don't try to configure the backlight when CONFIG_VIDEO_IPUV3 isn't set.

Signed-off-by: Andrew Shadura 
---
 board/ge/bx50v3/bx50v3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index e167cd5..fb112ee 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -601,6 +601,8 @@ int board_late_init(void)
 #ifdef CONFIG_CMD_BMODE
add_board_boot_modes(board_boot_modes);
 #endif
+
+#ifdef CONFIG_VIDEO_IPUV3
/* We need at least 200ms between power on and backlight on
 * as per specifications from CHI MEI */
mdelay(250);
@@ -615,6 +617,7 @@ int board_late_init(void)
gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
 
pwm_enable(0);
+#endif
 
return 0;
 }
-- 
2.7.4

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

[U-Boot] [PATCH v2] board: ge: bx50v3: move detect_baseboard() out of CONFIG_VIDEO_IPUV3

[Andrew Shadura]

detect_baseboard() function doesn't depend on CONFIG_VIDEO_IPUV3.
Make sure it's available when CONFIG_VIDEO_IPUV3 is off.

Signed-off-by: Andrew Shadura 
---

The first version of the patch moved the function down below
its first use, thus making the code uncompilable when CONFIG_VIDEO_IPUV3
is enabled. This revision fixes that issue.

---
 board/ge/bx50v3/bx50v3.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index ff8f4d7..e167cd5 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -321,6 +321,15 @@ int board_phy_config(struct phy_device *phydev)
return 0;
 }
 
+static int detect_baseboard(struct display_info_t const *dev)
+{
+   if (IS_ENABLED(CONFIG_TARGET_GE_B450V3) ||
+   IS_ENABLED(CONFIG_TARGET_GE_B650V3))
+   return 1;
+
+   return 0;
+}
+
 #if defined(CONFIG_VIDEO_IPUV3)
 static iomux_v3_cfg_t const backlight_pads[] = {
/* Power for LVDS Display */
@@ -345,15 +354,6 @@ int board_cfb_skip(void)
return 0;
 }
 
-static int detect_baseboard(struct display_info_t const *dev)
-{
-   if (IS_ENABLED(CONFIG_TARGET_GE_B450V3) ||
-   IS_ENABLED(CONFIG_TARGET_GE_B650V3))
-   return 1;
-
-   return 0;
-}
-
 struct display_info_t const displays[] = {{
.bus= -1,
.addr   = -1,
-- 
2.7.4

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

Re: [U-Boot] [PATCH] net: Add ag7xxx driver for Atheros MIPS

[Marek Vasut]

On 05/20/2016 06:18 AM, Wills Wang wrote:
> 
> 
> On 05/08/2016 11:22 PM, Marek Vasut wrote:
>> On 05/08/2016 02:58 PM, Daniel Schwierzeck wrote:
>>
>> Hi!
>>
>>> Am 05.05.2016 um 21:34 schrieb Marek Vasut:
 Add ethernet driver for the AR933x and AR934x Atheros MIPS machines.
 The driver could be easily extended to other WiSoCs.
> How to make this patch work on ar933x board?
> I apply this patch on the top of mips/next branch and enable this option
> in menuconfig,
> but i can't see any boot information for Ethernet.

The Kconfig conversion is not complete. See the tplink_wdr4300_defconfig
for the necessary options, it should be at least these:

CONFIG_CMD_NET=y
CONFIG_CMD_NFS=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM_ETH=y
CONFIG_AG7XXX=y

> By the way, the DT node "compatible" in driver is different from
> arch/mips/dts/ar933x.dtsi

OK, tweak that one to "qca,ag933x-mac" in the DTS.

, and
> the following compiling error occur because of commit
> 4feefdcfe916113ac6e1837ea22857f25fe1771c:

Enable CONFIG_CLK=y in your defconfig .

> drivers/usb/host/built-in.o: In function `ehci_usb_probe':
> drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x40): undefined
> reference to `clk_get_by_index'
> drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x4c): undefined
> reference to `clk_get_by_index'
> drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x60): undefined
> reference to `clk_enable'
> drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x68): undefined
> reference to `clk_enable'
> 


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

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Marek Vasut]

On 05/20/2016 07:07 AM, Rajesh Bhagat wrote:
> 
> 
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut
>> Sent: Tuesday, May 10, 2016 6:02 PM
>> To: Diego 
>> Cc: u-boot@lists.denx.de; Stefan Roese 
>> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives)
>>
>> On 05/10/2016 02:04 PM, Diego wrote:
>>> In data mercoledì 4 maggio 2016 23:36:46, Marek Vasut ha scritto:
 On 05/04/2016 04:06 PM, Diego wrote:
> In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
>> On 05/04/2016 11:13 AM, Diego wrote:
>>> 
>>> So I see three options:
>>> 1) 65535 default with quirk table
>>> 2) 32767 default without quirk table
>>> 3) 32767 default with quirk table
>>>
>>> Personally I think 3) would be the safest solution, but I think 2)
>>> would at least work for most thumb drives.
>>
>> 1) with the quirk table would be the way to go, modern(ish) drives
>> should work fine with 65535 .
>
> I personally can't see any improvement with more recent thumb
> drives, quite the opposite.
>
> 
> Why are you saying modern(ish) drives should work?

 Hm :-(

> For others following the thread, please post your experience,
> especially with more recent drives (remember to test with files >16MB).

 I don't think it's really worth doing a thread about which sticks
 work and which don't. I would find it much more valuable to address
 this issue properly. I wonder if it would make sense to, instead of
 starting with a big value which might not work, start with a
 small(er) value and increase it with each subsequent block transfer.
 Quite similarly to what TCP does. Would you be willing to look into it ?

>>>
>>> Hi Marek,
>>
>> Hi!
>>
>>> so your proposal is to ramp up transferred block size during transfer?
>>> What's the rationale behind the proposal? In other words, why do you
>>> think it will fix the problem?
>>
>> You will get one transfer failure somewhere in the middle and this will let 
>> you
>> determine the maximum transfer size for particular stick.
>>
>>> Regarding implementing your proposal, it might take me very long to
>>> find some time to dedicate to it, so if anybody else wants to step up
>>> before I look at it, just raise your hand.
>>
>> OK
>>
> 
> Hello Marek, 
> 
> I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't 
> seem to 
> focus on this value and is not impacted, kept the value so low i.e. 20?
> 
> #ifdef CONFIG_USB_EHCI
> /*
>  * The U-Boot EHCI driver can handle any transfer length as long as there is
>  * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands 
> are
>  * limited to 65535 blocks.
>  */
> #define USB_MAX_XFER_BLK65535
> #else
> #define USB_MAX_XFER_BLK20
> #endif
> 
> Common code suggests it is used in same way as used in EHCI. Please comment.

The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be
patches to set it to higher value for XHCI. Feel free to test and send a
patch.

Thanks

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

[U-Boot] [PATCH] board: ge: bx50v3: move detect_baseboard() out of CONFIG_VIDEO_IPUV3

[Andrew Shadura]

detect_baseboard() function doesn't depend on CONFIG_VIDEO_IPUV3.
Make sure it's available when CONFIG_VIDEO_IPUV3 is off.

Signed-off-by: Andrew Shadura 
---
 board/ge/bx50v3/bx50v3.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index ff8f4d7..e3233a2 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -345,15 +345,6 @@ int board_cfb_skip(void)
return 0;
 }
 
-static int detect_baseboard(struct display_info_t const *dev)
-{
-   if (IS_ENABLED(CONFIG_TARGET_GE_B450V3) ||
-   IS_ENABLED(CONFIG_TARGET_GE_B650V3))
-   return 1;
-
-   return 0;
-}
-
 struct display_info_t const displays[] = {{
.bus= -1,
.addr   = -1,
@@ -517,6 +508,15 @@ static void setup_display_bx50v3(void)
 }
 #endif /* CONFIG_VIDEO_IPUV3 */
 
+static int detect_baseboard(struct display_info_t const *dev)
+{
+   if (IS_ENABLED(CONFIG_TARGET_GE_B450V3) ||
+   IS_ENABLED(CONFIG_TARGET_GE_B650V3))
+   return 1;
+
+   return 0;
+}
+
 /*
  * Do not overwrite the console
  * Use always serial for U-Boot console
-- 
2.7.4

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

[U-Boot] abbreviating header files with CONFIG_IS_ENABLED()?

[Robert P. J. Day]

  just want to make sure i'm interpreting the use of this macro
correctly in that, if i look in include/image.h, i see (abbreviated
snippet):

  #if IMAGE_ENABLE_FIT
  # ifdef CONFIG_SPL_BUILD
  #  ifdef CONFIG_SPL_CRC32_SUPPORT
  #   define IMAGE_ENABLE_CRC32   1
  #  endif
  #  ifdef CONFIG_SPL_MD5_SUPPORT
  #   define IMAGE_ENABLE_MD5 1
  #  endif
  #  ifdef CONFIG_SPL_SHA1_SUPPORT
  #   define IMAGE_ENABLE_SHA11
  #  endif
  #  ifdef CONFIG_SPL_SHA256_SUPPORT
  #   define IMAGE_ENABLE_SHA256  1
  #  endif
  # else
  #  define CONFIG_CRC32  /* FIT images need CRC32 support */
  #  define CONFIG_MD5/* and MD5 */
  #  define CONFIG_SHA1   /* and SHA1 */
  #  define CONFIG_SHA256 /* and SHA256 */
  #  define IMAGE_ENABLE_CRC321
  #  define IMAGE_ENABLE_MD5  1
  #  define IMAGE_ENABLE_SHA1 1
  #  define IMAGE_ENABLE_SHA256   1
  # endif
  ...
  #ifndef IMAGE_ENABLE_CRC32
  #define IMAGE_ENABLE_CRC32  0
  #endif

  ... snip ...

which i *assume* could be written with more brevity as:

  #if IMAGE_ENABLE_FIT
  # ifdef CONFIG_SPL_BUILD
  #  define IMAGE_ENABLE_CRC32   CONFIG_IS_ENABLED(SPL_CRC32_SUPPORT)
  #  define IMAGE_ENABLE_MD5 CONFIG_IS_ENABLED(SPL_MD5_SUPPORT)
  #  define IMAGE_ENABLE_SHA1CONFIG_IS_ENABLED(SPL_SHA1_SUPPORT)
  #  define IMAGE_ENABLE_SHA256  CONFIG_IS_ENABLED(SPL_SHA256_SUPPORT)
  # else
  ... snip ...

that sort of thing. if i'm reading that correctly, i can do a bit of
cleanup this weekend and submit a patch for whatever looks obvious.

rday

p.s. i mentioned this before in that i have one nitpick with some of
the usage of this in that, in the above, *i* would have used:

  #ifdef CONFIG_FIT

rather than:

  #define IMAGE_ENABLE_FITCONFIG_IS_ENABLED(FIT)
  ...
  #if IMAGE_ENABLE_FIT

that is, i would use the CONFIG_* checks for preprocessor work, and
reserve the IMAGE_ENABLE_* conditionals exclusively for run-time
testing, just for consistency. but that's just me.


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

Re: [U-Boot] [PATCH v3 01/11] ARM: PSCI: change PSCI function IDs base and offsets

[Hongbo Zhang]

On Thu, May 19, 2016 at 5:07 PM, Andre Przywara  wrote:
> Hi,
>
> On 19/05/16 09:45, Hongbo Zhang wrote:
>> On Wed, May 18, 2016 at 6:07 PM, Andre Przywara  
>> wrote:
>>> Hi,
>>>
>>> On 18/05/16 10:10, macro.wav...@gmail.com wrote:
 From: Wang Dongsheng 

 According to PSCI specification v1.0, the PSCI functions should start from
 0x8400 for SMC32, this patch changes this base value as well as other
 function offset values.
>>>
>>> Out of curiosity: Do you plan to ever support ARMv8 boards with PSCI
>>> services in U-Boot as well?
>>> Then we would need to think about adjusting the function IDs, because
>>> they use a "64-bit" flag for some functions.
>>>
>> My workmate Hongtao Jia  is working for ARMv8 PSCI.
>> That should be in another separate file, so same or different function
>> names can both be used freely I think.
>
> OK, let's see how this looks like. The offsets are the same, the prefix
> is different, but not for every function - only for those that carry a
> register-sized argument (CPU_OFF uses the 32-bit prefix, CPU_ON the
> 64-bit one, for instance).
> That's why I was asking how we address this without duplicating
> everything. But we can discuss this in the ARMv8 support thread.
>

OK, I see, we can discuss that later for armv8.
And welcome to leave any comments for other patches in this serial.

Thanks.

> Cheers,
> Andre.
>
>>
 Signed-off-by: Wang Dongsheng 
 Signed-off-by: Hongbo Zhang 
>>>
>>> Otherwise:
>>> Reviewed-by: Andre Przywara 
>>>
>> Thanks for review.
>>
 ---
  arch/arm/include/asm/psci.h | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
 index 128a606..a4a19e3 100644
 --- a/arch/arm/include/asm/psci.h
 +++ b/arch/arm/include/asm/psci.h
 @@ -19,13 +19,13 @@
  #define __ARM_PSCI_H__

  /* PSCI interface */
 -#define ARM_PSCI_FN_BASE 0x95c1ba5e
 +#define ARM_PSCI_FN_BASE 0x8400
  #define ARM_PSCI_FN(n)   (ARM_PSCI_FN_BASE + (n))

 -#define ARM_PSCI_FN_CPU_SUSPEND  ARM_PSCI_FN(0)
 -#define ARM_PSCI_FN_CPU_OFF  ARM_PSCI_FN(1)
 -#define ARM_PSCI_FN_CPU_ON   ARM_PSCI_FN(2)
 -#define ARM_PSCI_FN_MIGRATE  ARM_PSCI_FN(3)
 +#define ARM_PSCI_FN_CPU_SUSPEND  ARM_PSCI_FN(1)
 +#define ARM_PSCI_FN_CPU_OFF  ARM_PSCI_FN(2)
 +#define ARM_PSCI_FN_CPU_ON   ARM_PSCI_FN(3)
 +#define ARM_PSCI_FN_MIGRATE  ARM_PSCI_FN(5)

  #define ARM_PSCI_RET_SUCCESS 0
  #define ARM_PSCI_RET_NI  (-1)

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

[U-Boot] [PATCH 3/4] mmc: fsl_esdhc: add error recovery for data transfer with Auto CMD12

[Yangbo Lu]

For data transfer with Auto CMD12, the host will not send an Auto
CMD12 to stop when the transfer fails. So this patch adds a flag
to indicate the READ/WRITE command error, and makes the driver
continue to send a CMD12 manually.

Signed-off-by: Yangbo Lu 
---
 drivers/mmc/fsl_esdhc.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index b06dd69..744037e 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -96,6 +96,9 @@ struct fsl_esdhc_priv {
struct udevice *dev;
int non_removable;
struct gpio_desc cd_gpio;
+#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
+   int rw_err;
+#endif
 };
 
 /* Return the XFERTYP flags for a given command and data packet */
@@ -350,8 +353,12 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
struct mmc_data *data)
struct fsl_esdhc *regs = priv->esdhc_regs;
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
-   if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
-   return 0;
+   if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION) {
+   if (priv->rw_err)
+   priv->rw_err = 0;
+   else
+   return 0;
+   }
 #endif
 
esdhc_write32(>irqstat, -1);
@@ -506,6 +513,13 @@ out:
/* If this was CMD11, then notify that power cycle is needed */
if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V)
printf("CMD11 to switch to 1.8V mode failed, card 
requires power cycle.\n");
+#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
+   if (cmd->cmdidx == MMC_CMD_READ_SINGLE_BLOCK ||
+   cmd->cmdidx == MMC_CMD_READ_MULTIPLE_BLOCK ||
+   cmd->cmdidx == MMC_CMD_WRITE_SINGLE_BLOCK ||
+   cmd->cmdidx == MMC_CMD_WRITE_MULTIPLE_BLOCK)
+   priv->rw_err = 1;
+#endif
}
 
esdhc_write32(>irqstat, -1);
@@ -796,6 +810,10 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv)
 
priv->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
+   priv->rw_err = 0;
+#endif
+
mmc = mmc_create(>cfg, priv);
if (mmc == NULL)
return -1;
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH 2/4] mmc: send STOP command when the READ/WIRTE commands fail

[Yangbo Lu]

The STOP command should be sent to stop data transfer when the
READ/WRITE commands fail. Otherwise, any subsequent command will
fail to be sent.

Signed-off-by: Yangbo Lu 
---
 drivers/mmc/mmc.c | 28 +++-
 drivers/mmc/mmc_private.h |  1 +
 drivers/mmc/mmc_write.c   |  8 ++--
 3 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d3c22ab..713a934 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -197,6 +197,21 @@ struct mmc *find_mmc_device(int dev_num)
return NULL;
 }
 
+int mmc_send_stop(struct mmc *mmc)
+{
+   struct mmc_cmd cmd;
+   int err;
+
+   cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+   cmd.cmdarg = 0;
+   cmd.resp_type = MMC_RSP_R1b;
+
+   err = mmc_send_cmd(mmc, , NULL);
+   if (err)
+   printf("mmc fail to send stop cmd\n");
+   return err;
+}
+
 static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
   lbaint_t blkcnt)
 {
@@ -220,19 +235,14 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst, 
lbaint_t start,
data.blocksize = mmc->read_bl_len;
data.flags = MMC_DATA_READ;
 
-   if (mmc_send_cmd(mmc, , ))
+   if (mmc_send_cmd(mmc, , )) {
+   mmc_send_stop(mmc);
return 0;
+   }
 
if (blkcnt > 1) {
-   cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
-   cmd.cmdarg = 0;
-   cmd.resp_type = MMC_RSP_R1b;
-   if (mmc_send_cmd(mmc, , NULL)) {
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
-   printf("mmc fail to send stop cmd\n");
-#endif
+   if (mmc_send_stop(mmc))
return 0;
-   }
}
 
return blkcnt;
diff --git a/drivers/mmc/mmc_private.h b/drivers/mmc/mmc_private.h
index d3f6bfe..df507fc 100644
--- a/drivers/mmc/mmc_private.h
+++ b/drivers/mmc/mmc_private.h
@@ -16,6 +16,7 @@ extern int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data);
 extern int mmc_send_status(struct mmc *mmc, int timeout);
 extern int mmc_set_blocklen(struct mmc *mmc, int len);
+int mmc_send_stop(struct mmc *mmc);
 #ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
 void mmc_adapter_card_type_ident(void);
 #endif
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 7b186f8..4f00657 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -148,6 +148,7 @@ static ulong mmc_write_blocks(struct mmc *mmc, lbaint_t 
start,
 
if (mmc_send_cmd(mmc, , )) {
printf("mmc write failed\n");
+   mmc_send_stop(mmc);
return 0;
}
 
@@ -155,13 +156,8 @@ static ulong mmc_write_blocks(struct mmc *mmc, lbaint_t 
start,
 * token, not a STOP_TRANSMISSION request.
 */
if (!mmc_host_is_spi(mmc) && blkcnt > 1) {
-   cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
-   cmd.cmdarg = 0;
-   cmd.resp_type = MMC_RSP_R1b;
-   if (mmc_send_cmd(mmc, , NULL)) {
-   printf("mmc fail to send stop cmd\n");
+   if (mmc_send_stop(mmc))
return 0;
-   }
}
 
/* Waiting for the ready status */
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz

[Vignesh R]

According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
throughput.

Signed-off-by: Vignesh R 
---
 arch/arm/dts/dra7-evm.dts  | 6 ++
 arch/arm/dts/dra72-evm.dts | 6 ++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
index 08ef04e177b0..429b9edc1b2b 100644
--- a/arch/arm/dts/dra7-evm.dts
+++ b/arch/arm/dts/dra7-evm.dts
@@ -491,15 +491,13 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 
-   spi-max-frequency = <4800>;
+   spi-max-frequency = <6400>;
m25p80@0 {
compatible = "s25fl256s1","spi-flash";
-   spi-max-frequency = <4800>;
+   spi-max-frequency = <6400>;
reg = <0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
-   spi-cpol;
-   spi-cpha;
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arm/dts/dra72-evm.dts b/arch/arm/dts/dra72-evm.dts
index 205103e2b0e1..ced2f1166d8c 100644
--- a/arch/arm/dts/dra72-evm.dts
+++ b/arch/arm/dts/dra72-evm.dts
@@ -603,15 +603,13 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 
-   spi-max-frequency = <4800>;
+   spi-max-frequency = <6400>;
m25p80@0 {
compatible = "s25fl256s1","spi-flash";
-   spi-max-frequency = <4800>;
+   spi-max-frequency = <6400>;
reg = <0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
-   spi-cpol;
-   spi-cpha;
#address-cells = <1>;
#size-cells = <1>;
 
-- 
2.8.3

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

[U-Boot] [PATCH 4/4] mmc: add workaround for eSDHC erratum A009620

[Yangbo Lu]

Erratum Title:
Data timeout error not getting set in case of command with busy
response (R1b) as well as for busy period after last write block
transfer.

Description:
In the event that a busy timeout occurs for a command with a busy
response (e.g. R1b response) as well as busy period after the last
write block, the eSDHC does not set the IRQSTAT[DTOE] bit or the
IRQSTAT[TC]. Therefore, the current command transfer is never completed.

Workaround:
Workaround for CMD with busy:
Don't set the XFRTYP[RSP]=2'b11 for commands with busy response and
poll the busy status of the card from the PRSSTAT[DLSL]

Workaround for busy period after last write block:
1. After the command completion interrupt (IRQSTAT[CC]), wait for
   de-assertion of PRSTAT[WTA].
2. Once PRSTAT[WTA] is de-asserted, start the software timer and poll
   the busy signal (DAT0) using PRSTAT[DLSL[0]].
3. Wait for DAT0 signal to go high (which indicate transfer complete)
   or software timer expiry (which indicate data timeout error).
4. Issue soft reset for data (SYSCTL[RSTD]).
5. In case of data timeout error (detected in step 3) perform the
   error recovery.

The workaround for CMD with busy has already been applied in eSDHC
driver. This patch is to add workaround for the 2nd issue, and the
fixup platforms include PowerPC(P1010/P2020/P5020/P5040/T1024/T1040/
T2080/T4240) and ARM(LS1021A/LS1043A/LS2080A).

Signed-off-by: Yangbo Lu 
---
 arch/powerpc/include/asm/config_mpc85xx.h |  8 
 drivers/mmc/fsl_esdhc.c   | 26 ++
 include/configs/ls1021aqds.h  |  1 +
 include/configs/ls1021atwr.h  |  1 +
 include/configs/ls1043a_common.h  |  1 +
 include/configs/ls2080a_simu.h|  1 +
 include/configs/ls2080aqds.h  |  1 +
 include/configs/ls2080ardb.h  |  1 +
 include/fsl_esdhc.h   |  1 +
 9 files changed, 41 insertions(+)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index eccc146..197ee42 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -148,6 +148,7 @@
 #define CONFIG_TSECV2
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_USB_MAX_CONTROLLER_COUNT1
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT  4
@@ -369,6 +370,7 @@
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define CONFIG_SYS_FSL_SRIO_MAX_PORTS  2
 #define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
 #define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
@@ -530,6 +532,7 @@
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
@@ -568,6 +571,7 @@
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define CONFIG_SYS_FSL_ERRATUM_USB14
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
@@ -686,6 +690,7 @@
 #define CONFIG_SYS_FSL_ERRATUM_A007186
 #define CONFIG_SYS_FSL_ERRATUM_A006593
 #define CONFIG_SYS_FSL_ERRATUM_A007798
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 #define CONFIG_SYS_FSL_PCI_VER_3_X
@@ -802,6 +807,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
 #define CONFIG_SYS_FSL_ERRATUM_A006261
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
 #define QE_MURAM_SIZE  0x6000UL
 #define MAX_QE_RISC1
@@ -823,6 +829,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #endif
 #if defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023)
 #define CONFIG_MAX_CPUS2
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #elif defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_MAX_CPUS1
 #endif
@@ -882,6 +889,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_SRIO_MAX_PORTS  2
 #define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
 #define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620
 #elif defined(CONFIG_PPC_T2081)
 #define CONFIG_SYS_NUM_FM1_DTSEC   6
 #define CONFIG_SYS_NUM_FM1_10GEC   2
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 744037e..fba87d2 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ 

[U-Boot] [PATCH 1/4] mmc: fsl_esdhc: don't set XFERTYP_RSPTYP_48_BUSY for CMD with busy response

[Yangbo Lu]

For CMD with busy response, the eSDHC driver would poll DAT0 until
CMD completion rather than polling IRQSTAT. So, don't set
XFERTYP_RSPTYP_48_BUSY to avoid interrupts (DTOE or TC) in IRQSTAT.

Signed-off-by: Yangbo Lu 
---
 drivers/mmc/fsl_esdhc.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3acf9e8..b06dd69 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -126,8 +126,16 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
xfertyp |= XFERTYP_CICEN;
if (cmd->resp_type & MMC_RSP_136)
xfertyp |= XFERTYP_RSPTYP_136;
-   else if (cmd->resp_type & MMC_RSP_BUSY)
-   xfertyp |= XFERTYP_RSPTYP_48_BUSY;
+   /*
+* For CMD with busy response, the eSDHC driver would poll DAT0
+* until CMD completion rather than polling IRQSTAT. So, don't
+* set XFERTYP_RSPTYP_48_BUSY to avoid interrupts (DTOE or TC)
+* in IRQSTAT.
+*
+* Remove:
+* else if (cmd->resp_type & MMC_RSP_BUSY)
+*  xfertyp |= XFERTYP_RSPTYP_48_BUSY;
+*/
else if (cmd->resp_type & MMC_RSP_PRESENT)
xfertyp |= XFERTYP_RSPTYP_48;
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] SPL: fat: Fix spl_parse_image_header() return value handling

[Stefano Babic]

On 20/05/2016 01:45, Marek Vasut wrote:
> The spl_parse_image_header() can return 0 and it is not an error.
> Only treat non-zero return value as an error.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Tom Rini 
> ---
>  common/spl/spl_fat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
> index 338ea2f..5b0d969 100644
> --- a/common/spl/spl_fat.c
> +++ b/common/spl/spl_fat.c
> @@ -58,7 +58,7 @@ int spl_load_image_fat(struct blk_desc *block_dev,
>   goto end;
>  
>   err = spl_parse_image_header(header);
> - if (err <= 0)
> + if (err)
>   goto end;
>  
>   err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] SPL: fat: Fix spl_parse_image_header() return value handling

[Peng Fan]

On Fri, May 20, 2016 at 01:45:24AM +0200, Marek Vasut wrote:
>The spl_parse_image_header() can return 0 and it is not an error.
>Only treat non-zero return value as an error.
>
>Signed-off-by: Marek Vasut 
>Cc: Fabio Estevam 
>Cc: Peng Fan 
>Cc: Stefano Babic 
>Cc: Tom Rini 

Reviewed-by: Peng Fan 

Regards,
Peng.
>---
> common/spl/spl_fat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
>index 338ea2f..5b0d969 100644
>--- a/common/spl/spl_fat.c
>+++ b/common/spl/spl_fat.c
>@@ -58,7 +58,7 @@ int spl_load_image_fat(struct blk_desc *block_dev,
>   goto end;
> 
>   err = spl_parse_image_header(header);
>-  if (err <= 0)
>+  if (err)
>   goto end;
> 
>   err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
>-- 
>2.7.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull those 2 patches.

Thanks,
Stefan

The following changes since commit 4b6e1fda107e5244e80ebc41865650ac2873dc88:

  Merge git://git.denx.de/u-boot-dm (2016-05-17 13:58:27 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-marvell.git 

for you to fetch changes up to fbaf42724f372ee3fb0d7cd83107f5bae416028f:

  arm: mvebu: theadorable: Enable CONFIG_ZERO_BOOTDELAY_CHECK (2016-05-20 
11:08:16 +0200)


Marek Vasut (1):
  arm: mvebu: a38x: Weed out floating point use

Stefan Roese (1):
  arm: mvebu: theadorable: Enable CONFIG_ZERO_BOOTDELAY_CHECK

 drivers/ddr/marvell/a38x/ddr3_init.c | 29 ++---
 include/configs/theadorable.h|  1 +
 2 files changed, 11 insertions(+), 19 deletions(-)



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

Re: [U-Boot] [PATCH] arm: mvebu: theadorable: Enable CONFIG_ZERO_BOOTDELAY_CHECK

[Stefan Roese]

On 13.04.2016 11:02, Stefan Roese wrote:

Enable bootdelay 0 check so that booting can be interrupted even with
bootdelay configured to 0.

Signed-off-by: Stefan Roese 
---
  include/configs/theadorable.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h
index 5864f27..6c0e7dc 100644
--- a/include/configs/theadorable.h
+++ b/include/configs/theadorable.h
@@ -76,6 +76,7 @@
  #define PHY_ANEG_TIMEOUT  8000/* PHY needs a longer aneg time */

  #define CONFIG_SYS_CONSOLE_INFO_QUIET /* don't print console @ startup */
+#define CONFIG_ZERO_BOOTDELAY_CHECK/* check for keypress on bootdelay==0 */
  #define CONFIG_SYS_ALT_MEMTEST
  #define CONFIG_PREBOOT




Applied to u-boot-marvell/master

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

Re: [U-Boot] [PATCH] arm: mvebu: a38x: Weed out floating point use

[Stefan Roese]

On 30.04.2016 14:45, Marek Vasut wrote:

For reason unknown, recently, the DDR init code writers are really fond
of hiding some small floating point operating deep in their creations.
This patch removes one from the Marvell A38x code.

Instead of returning size of chip as float from ddr3_get_device_size()
in GiB units, return it as int in MiB units. Since this would interfere
with the huge switch code in ddr3_calc_mem_cs_size(), rework the code
to match the change.

Before this patch, the cs_mem_size variable could have these values:
  ( { 16, 32 } x { 8, 16 } x { 0.01, 0.5, 1, 2, 4, 8 } ) / 8 =
{ 0.00, 0.001250, 0.002500, 0.005000, 0.062500, 0.125000,
  0.25, 0.50, 1.00, 2.00, 4.00, }
The switch code checked for a subset of the resulting RAM sizes, which
is in range 128 MiB ... 2048 MiB.

With this patch, the cs_mem_size variable can have these values:
  ( { 16, 32 } x { 8, 16 } x { 0, 512, 1024, 2048, 4096, 8192 } ) / 8 =
{ 0, 64, 128, 256, 512, 1024, 2048, 4096 }
To retain previous behavior, filter out 0 MiB (invalid size), 64 MiB
and 4096 MiB options.

Removing the floating point stuff also saves 1.5k from text segment:
   clearfog   :  spl/u-boot-spl:all -1592  spl/u-boot-spl:text -1592

Signed-off-by: Marek Vasut 
Cc: Dirk Eibach 
Cc: Stefan Roese 


Marek, thanks for working on this.

Applied to u-boot-marvell/master

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

Re: [U-Boot] [PATCH 03/13] imx-common: use simpler runtime cpu dection macros

[Peng Fan]

Hi Benoît,

On Fri, May 20, 2016 at 01:02:10AM +0200, Benoît Thébaudeau wrote:
>Dear Peng Fan,
>
>On Wed, May 18, 2016 at 9:53 AM, Peng Fan  wrote:
>> Use simpler runtime cpu dection macros.
>>
>> Signed-off-by: Peng Fan 
>> Cc: Stefano Babic 
>> Cc: Ulises Cardenas 
>> Cc: Bhuvanchandra DV 
>> Cc: "Benoît Thébaudeau" 
>> ---
>>  arch/arm/imx-common/hab.c  | 43 
>> +-
>>  arch/arm/imx-common/init.c |  5 ++---
>>  arch/arm/imx-common/iomux-v3.c |  2 +-
>>  arch/arm/imx-common/sata.c |  2 +-
>>  arch/arm/imx-common/timer.c| 11 +++
>>  5 files changed, 20 insertions(+), 43 deletions(-)
>>
>> diff --git a/arch/arm/imx-common/hab.c b/arch/arm/imx-common/hab.c
>> index 8bbcc22..a980688 100644
>> --- a/arch/arm/imx-common/hab.c
>> +++ b/arch/arm/imx-common/hab.c
>> @@ -17,60 +17,45 @@
>>
>>  #define hab_rvt_report_event_p \
>>  (  \
>> -   ((is_cpu_type(MXC_CPU_MX6Q) ||  \
>> - is_cpu_type(MXC_CPU_MX6D)) && \
>> - (soc_rev() >= CHIP_REV_1_5)) ?\
>> +   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
>> ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) :  \
>> -   (is_cpu_type(MXC_CPU_MX6DL) &&  \
>> -(soc_rev() >= CHIP_REV_1_2)) ? \
>> +   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
>
>This change silently introduces the possibility of MXC_CPU_MX6SOLO. Is
>this on purpose? If so, then it means that there was something

Yeah. on purpose.

>unrelated to this patch that was wrong in this code for
>MXC_CPU_MX6SOLO, so this should be fixed in a separate patch before
>this one. If not, then an is_mx6dl() macro should be introduced.

6solo and 6dl works the same. I do not plan to add a is_mx6dl here.
I can refine the commit log to note this in V2.

Stefano, do you have any comments on this?

Thanks,
Peng.

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

Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Huan Wang]

> On 20.05.16 10:26, Huan Wang wrote:
> >> On 20.05.16 08:53, Huan Wang wrote:
>  On 05/19/2016 10:26 AM, Alison Wang wrote:
> > To support loading a 32-bit OS, the execution state will change
> > from
> > AArch64 to AArch32 when jumping to kernel.
> >
> > The architecture information will be got through checking FIT
> > image, then U-Boot will load 32-bit OS or 64-bit OS automatically.
> >
> > Signed-off-by: Ebony Zhu 
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Chenhui Zhao 
> > ---
> 
> [...]
> 
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -1163,7 +1163,8 @@ int fit_image_check_arch(const void *fit,
> > int
>  noffset, uint8_t arch)
> > if (fit_image_get_arch(fit, noffset, _arch))
> > return 0;
> > return (arch == image_arch) ||
> > -   (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64);
> > +   (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64)
> ||
> > +   (arch == IH_ARCH_ARM64 && image_arch == IH_ARCH_ARM);
> 
>  This should be a Kconfig option. ThunderX doesn't support AArch32
>  execution.
> >>> [Alison Wang] I can't understand your meaning. Can you clarify it?
> >>
> >> U-Boot supports the ThunderX SoC which uses Cavium's own ARMv8 core
> >> implementation. That core does not support running AArch32 code.
> >>
> > [Alison Wang] Oh, I think your concern is that this function will not
> > detect FIT image is wrong when loading 32-bit kernel on ThunderX,
> right?
> >
> > Then what is your suggestion to fix this issue?
> 
> My suggestion is to introduce a new Kconfig option that says "this arm64
> system can execute aarch32 code" which is set as default y.
> CONFIG_THUNDERX would then set it to n if that's possible - or you'd
> just set it to n in the thunderx defconfig.
[Alison Wang] Good idea. I will do it in the next version. Thanks.

Best Regards,
Alison Wang

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

Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 20.05.16 10:26, Huan Wang wrote:
>> On 20.05.16 08:53, Huan Wang wrote:
 On 05/19/2016 10:26 AM, Alison Wang wrote:
> To support loading a 32-bit OS, the execution state will change from
> AArch64 to AArch32 when jumping to kernel.
>
> The architecture information will be got through checking FIT image,
> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>
> Signed-off-by: Ebony Zhu 
> Signed-off-by: Alison Wang 
> Signed-off-by: Chenhui Zhao 
> ---

[...]

> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1163,7 +1163,8 @@ int fit_image_check_arch(const void *fit, int
 noffset, uint8_t arch)
>   if (fit_image_get_arch(fit, noffset, _arch))
>   return 0;
>   return (arch == image_arch) ||
> - (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64);
> + (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64) ||
> + (arch == IH_ARCH_ARM64 && image_arch == IH_ARCH_ARM);

 This should be a Kconfig option. ThunderX doesn't support AArch32
 execution.
>>> [Alison Wang] I can't understand your meaning. Can you clarify it?
>>
>> U-Boot supports the ThunderX SoC which uses Cavium's own ARMv8 core
>> implementation. That core does not support running AArch32 code.
>>
> [Alison Wang] Oh, I think your concern is that this function will not
> detect FIT image is wrong when loading 32-bit kernel on ThunderX, right?
> 
> Then what is your suggestion to fix this issue?

My suggestion is to introduce a new Kconfig option that says "this arm64
system can execute aarch32 code" which is set as default y.
CONFIG_THUNDERX would then set it to n if that's possible - or you'd
just set it to n in the thunderx defconfig.


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

Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Huan Wang]

> On 20.05.16 08:53, Huan Wang wrote:
> >> On 05/19/2016 10:26 AM, Alison Wang wrote:
> >>> To support loading a 32-bit OS, the execution state will change from
> >>> AArch64 to AArch32 when jumping to kernel.
> >>>
> >>> The architecture information will be got through checking FIT image,
> >>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
> >>>
> >>> Signed-off-by: Ebony Zhu 
> >>> Signed-off-by: Alison Wang 
> >>> Signed-off-by: Chenhui Zhao 
> >>> ---
> >>> Changes in v2:
> >>> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is
> >> used
> >>>to switch to AArch64 EL2 or AArch32 Hyp.
> >>> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is
> >> used
> >>>to switch to AArch64 EL1 or AArch32 SVC.
> >>>
> >>>   arch/arm/cpu/armv8/transition.S |  8 ++---
> >>>   arch/arm/include/asm/macro.h| 80
> >> +
> >>>   arch/arm/include/asm/system.h   | 25 +++--
> >>>   arch/arm/lib/bootm.c| 26 +++---
> >>>   common/image-fit.c  | 12 ++-
> >>>   5 files changed, 133 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/transition.S
> >>> b/arch/arm/cpu/armv8/transition.S index 253a39b..9fa3b59 100644
> >>> --- a/arch/arm/cpu/armv8/transition.S
> >>> +++ b/arch/arm/cpu/armv8/transition.S
> >>> @@ -11,13 +11,13 @@
> >>>   #include 
> >>>
> >>>   ENTRY(armv8_switch_to_el2)
> >>> - switch_el x0, 1f, 0f, 0f
> >>> + switch_el x4, 1f, 0f, 0f
> >>>   0:  ret
> >>> -1:   armv8_switch_to_el2_m x0
> >>> +1:   armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6
> >>>   ENDPROC(armv8_switch_to_el2)
> >>>
> >>>   ENTRY(armv8_switch_to_el1)
> >>> - switch_el x0, 0f, 1f, 0f
> >>> + switch_el x4, 0f, 1f, 0f
> >>>   0:  ret
> >>> -1:   armv8_switch_to_el1_m x0, x1
> >>> +1:   armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6
> >>>   ENDPROC(armv8_switch_to_el1)
> >>> diff --git a/arch/arm/include/asm/macro.h
> >>> b/arch/arm/include/asm/macro.h index 9bb0efa..56d77f6 100644
> >>> --- a/arch/arm/include/asm/macro.h
> >>> +++ b/arch/arm/include/asm/macro.h
> >>> @@ -8,6 +8,9 @@
> >>>
> >>>   #ifndef __ASM_ARM_MACRO_H__
> >>>   #define __ASM_ARM_MACRO_H__
> >>> +
> >>> +#include 
> >>> +
> >>>   #ifdef __ASSEMBLY__
> >>>
> >>>   /*
> >>> @@ -135,9 +138,20 @@ lr   .reqx30
> >>>   #endif
> >>>   .endm
> >>>
> >>> -.macro armv8_switch_to_el2_m, xreg1
> >>> - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1
> >> */
> >>> - mov \xreg1, #0x5b1
> >>> +.macro armv8_switch_to_el2_m, xreg1, xreg2, xreg3, xreg4, xreg5,
> >>> +xreg6, xreg7
> >>
> >> These arguments should probably get documented :). Also xreg4 doesn't
> >> seem to actually be a scratch register, but a real parameter. So
> >> please name it accordingly.
> > [Alison Wang] Ok, I will add the descriptions for these arguments. Not
> > only xreg4, xreg1, xreg2 and xreg3 are real parameters too. I will
> > rename them in the next version.
> >>
> >>> + mov \xreg5, \xreg1
> >>> + mov \xreg6, \xreg2
> >>> + mov \xreg7, \xreg3
> >>> +
> >>> + /*
> >>> +  * If the next lower exception level is AArch64, 64bit EL2 | HCE |
> >> SMD |
> >>> +  * RES1 (Bits[5:4]) | Non-secure EL0/EL1. If the next lower
> >> exception
> >>> +  * level is AArch32, 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) |
> >>> +  * Non-secure EL0/EL1.
> >>> +  */
> >>> + mov \xreg1, #0x1b1
> >>> + lsl \xreg2, \xreg4, #10
> >>> + orr \xreg1, \xreg1, \xreg2
> >>
> >> Is there any way you can make this obvious from the code? Basically
> >> we would want something like
> >>
> >> mov \xreg1, #(SCR_EL3_EL2_AA64 | SCR_EL3_HCE | SCR_EL3_SMD ...)
> >>
> >> I'm sure there are creative ways to achieve this even with the high
> >> bits set. Maybe ldr = works?
> > [Alison Wang] Yes, I will change them and make them obvious.
> >>
> >>>   msr scr_el3, \xreg1
> >>>   msr cptr_el3, xzr   /* Disable coprocessor traps
> to EL3
> >> */
> >>>   mov \xreg1, #0x33ff
> >>> @@ -156,18 +170,46 @@ lr  .reqx30
> >>>   movk\xreg1, #0x30C5, lsl #16
> >>>   msr sctlr_el2, \xreg1
> >>>
> >>> - /* Return to the EL2_SP2 mode from EL3 */
> >>>   mov \xreg1, sp
> >>>   msr sp_el2, \xreg1  /* Migrate SP */
> >>>   mrs \xreg1, vbar_el3
> >>>   msr vbar_el2, \xreg1/* Migrate VBAR */
> >>> +
> >>> + /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */
> >>> + ldr \xreg1, =ES_TO_AARCH64
> >>> + cmp \xreg4, \xreg1
> >>> + b.eq1f
> >>> + b.ne2f
> >>
> >> Just b.ne should be enough, no?
> > [Alison Wang] Yes, you are right.
> >>
> >>> +
> >>> +1:
> >>> + /* Return to the EL2_SP2 mode from EL3 */
> >>>   mov \xreg1, #0x3c9
> >>
> >> Magic values again :). Please convert them to constants getting ORed.
> > [Alison 

[U-Boot] [PATCH] driver/ddr/fsl: Force enabling parity for A-009803

[Shengzhou Liu]

Default address parity is disabled for DDR4 UDIMM for considing
performance, it needs to enable parity for A-009803 workaround.

Signed-off-by: Shengzhou Liu 
---
 drivers/ddr/fsl/options.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
index d0075ff..dcef0bb 100644
--- a/drivers/ddr/fsl/options.c
+++ b/drivers/ddr/fsl/options.c
@@ -1016,6 +1016,9 @@ unsigned int populate_memctl_options(const 
common_timing_params_t *common_dimm,
}
}
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
+   popts->ap_en = 1;
+#endif
/*
 * BSTTOPRE precharge interval
 *
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 20.05.16 08:53, Huan Wang wrote:
>> On 05/19/2016 10:26 AM, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT image,
>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu 
>>> Signed-off-by: Alison Wang 
>>> Signed-off-by: Chenhui Zhao 
>>> ---
>>> Changes in v2:
>>> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is
>> used
>>>to switch to AArch64 EL2 or AArch32 Hyp.
>>> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is
>> used
>>>to switch to AArch64 EL1 or AArch32 SVC.
>>>
>>>   arch/arm/cpu/armv8/transition.S |  8 ++---
>>>   arch/arm/include/asm/macro.h| 80
>> +
>>>   arch/arm/include/asm/system.h   | 25 +++--
>>>   arch/arm/lib/bootm.c| 26 +++---
>>>   common/image-fit.c  | 12 ++-
>>>   5 files changed, 133 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/transition.S
>>> b/arch/arm/cpu/armv8/transition.S index 253a39b..9fa3b59 100644
>>> --- a/arch/arm/cpu/armv8/transition.S
>>> +++ b/arch/arm/cpu/armv8/transition.S
>>> @@ -11,13 +11,13 @@
>>>   #include 
>>>
>>>   ENTRY(armv8_switch_to_el2)
>>> -   switch_el x0, 1f, 0f, 0f
>>> +   switch_el x4, 1f, 0f, 0f
>>>   0:ret
>>> -1: armv8_switch_to_el2_m x0
>>> +1: armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6
>>>   ENDPROC(armv8_switch_to_el2)
>>>
>>>   ENTRY(armv8_switch_to_el1)
>>> -   switch_el x0, 0f, 1f, 0f
>>> +   switch_el x4, 0f, 1f, 0f
>>>   0:ret
>>> -1: armv8_switch_to_el1_m x0, x1
>>> +1: armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6
>>>   ENDPROC(armv8_switch_to_el1)
>>> diff --git a/arch/arm/include/asm/macro.h
>>> b/arch/arm/include/asm/macro.h index 9bb0efa..56d77f6 100644
>>> --- a/arch/arm/include/asm/macro.h
>>> +++ b/arch/arm/include/asm/macro.h
>>> @@ -8,6 +8,9 @@
>>>
>>>   #ifndef __ASM_ARM_MACRO_H__
>>>   #define __ASM_ARM_MACRO_H__
>>> +
>>> +#include 
>>> +
>>>   #ifdef __ASSEMBLY__
>>>
>>>   /*
>>> @@ -135,9 +138,20 @@ lr .reqx30
>>>   #endif
>>>   .endm
>>>
>>> -.macro armv8_switch_to_el2_m, xreg1
>>> -   /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1
>> */
>>> -   mov \xreg1, #0x5b1
>>> +.macro armv8_switch_to_el2_m, xreg1, xreg2, xreg3, xreg4, xreg5,
>>> +xreg6, xreg7
>>
>> These arguments should probably get documented :). Also xreg4 doesn't
>> seem to actually be a scratch register, but a real parameter. So please
>> name it accordingly.
> [Alison Wang] Ok, I will add the descriptions for these arguments. Not only
> xreg4, xreg1, xreg2 and xreg3 are real parameters too. I will rename them in
> the next version.
>>
>>> +   mov \xreg5, \xreg1
>>> +   mov \xreg6, \xreg2
>>> +   mov \xreg7, \xreg3
>>> +
>>> +   /*
>>> +* If the next lower exception level is AArch64, 64bit EL2 | HCE |
>> SMD |
>>> +* RES1 (Bits[5:4]) | Non-secure EL0/EL1. If the next lower
>> exception
>>> +* level is AArch32, 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) |
>>> +* Non-secure EL0/EL1.
>>> +*/
>>> +   mov \xreg1, #0x1b1
>>> +   lsl \xreg2, \xreg4, #10
>>> +   orr \xreg1, \xreg1, \xreg2
>>
>> Is there any way you can make this obvious from the code? Basically we
>> would want something like
>>
>> mov \xreg1, #(SCR_EL3_EL2_AA64 | SCR_EL3_HCE | SCR_EL3_SMD ...)
>>
>> I'm sure there are creative ways to achieve this even with the high bits
>> set. Maybe ldr = works?
> [Alison Wang] Yes, I will change them and make them obvious.
>>
>>> msr scr_el3, \xreg1
>>> msr cptr_el3, xzr   /* Disable coprocessor traps to EL3
>> */
>>> mov \xreg1, #0x33ff
>>> @@ -156,18 +170,46 @@ lr.reqx30
>>> movk\xreg1, #0x30C5, lsl #16
>>> msr sctlr_el2, \xreg1
>>>
>>> -   /* Return to the EL2_SP2 mode from EL3 */
>>> mov \xreg1, sp
>>> msr sp_el2, \xreg1  /* Migrate SP */
>>> mrs \xreg1, vbar_el3
>>> msr vbar_el2, \xreg1/* Migrate VBAR */
>>> +
>>> +   /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */
>>> +   ldr \xreg1, =ES_TO_AARCH64
>>> +   cmp \xreg4, \xreg1
>>> +   b.eq1f
>>> +   b.ne2f
>>
>> Just b.ne should be enough, no?
> [Alison Wang] Yes, you are right.
>>
>>> +
>>> +1:
>>> +   /* Return to the EL2_SP2 mode from EL3 */
>>> mov \xreg1, #0x3c9
>>
>> Magic values again :). Please convert them to constants getting ORed.
> [Alison Wang] Ok, I will change the original magic values too.
>>
>>> msr spsr_el3, \xreg1/* EL2_SP2 | D | A | I | F */
>>> msr elr_el3, lr
>>> +
>>> +   mov \xreg1, \xreg5
>>> +   mov \xreg2, \xreg6
>>> +   mov \xreg3, \xreg7
>>> +   eret
>>> +
>>> +2:
>>> +   /* Return to