[U-Boot] [PATCH v5 2/2] common: Generic firmware loader for file system

[tien . fong . chee]

From: Tien Fong Chee 

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.

Signed-off-by: Tien Fong Chee 
---
 common/Makefile|   1 +
 common/fs_loader.c | 311 +
 doc/README.firmware_loader |  76 +++
 include/fs_loader.h|  28 
 4 files changed, 416 insertions(+)
 create mode 100644 common/fs_loader.c
 create mode 100644 doc/README.firmware_loader
 create mode 100644 include/fs_loader.h

diff --git a/common/Makefile b/common/Makefile
index cec506f..2934221 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -130,3 +130,4 @@ obj-$(CONFIG_CMD_DFU) += dfu.o
 obj-y += command.o
 obj-y += s_record.o
 obj-y += xyzModem.o
+obj-y += fs_loader.o
diff --git a/common/fs_loader.c b/common/fs_loader.c
new file mode 100644
index 000..ddfce58
--- /dev/null
+++ b/common/fs_loader.c
@@ -0,0 +1,311 @@
+/*
+ * Copyright (C) 2017 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct firmware_priv {
+   const char *name;   /* Filename */
+   u32 offset; /* Offset of reading a file */
+};
+
+static struct device_location default_locations[] = {
+   {
+   .name = "mmc",
+   .devpart = "0:1",
+   },
+   {
+   .name = "usb",
+   .devpart = "0:1",
+   },
+   {
+   .name = "sata",
+   .devpart = "0:1",
+   },
+};
+
+/* USB build is not supported yet in SPL */
+#ifndef CONFIG_SPL_BUILD
+#ifdef CONFIG_USB_STORAGE
+static int init_usb(void)
+{
+   int err;
+
+   err = usb_init();
+   if (err)
+   return err;
+
+#ifndef CONFIG_DM_USB
+   err = usb_stor_scan(1) < 0 ? -ENODEV : 0;
+#endif
+
+   return err;
+}
+#else
+static int init_usb(void)
+{
+   printf("Error: Cannot load flash image: no USB support\n");
+   return -ENOSYS;
+}
+#endif
+#endif
+
+#ifdef CONFIG_SATA
+static int init_storage_sata(void)
+{
+   return sata_probe(0);
+}
+#else
+static int init_storage_sata(void)
+{
+   printf("Error: Cannot load image: no SATA support\n");
+   return -ENOSYS;
+}
+#endif
+
+#ifdef CONFIG_CMD_UBIFS
+static int mount_ubifs(struct device_location *location)
+{
+   int ret;
+   char cmd[32];
+
+   sprintf(cmd, "ubi part %s", location->mtdpart);
+
+   ret = run_command(cmd, 0);
+   if (ret)
+   return ret;
+
+   sprintf(cmd, "ubifsmount %s", location->ubivol);
+
+   ret = run_command(cmd, 0);
+
+   return ret;
+}
+
+static int umount_ubifs(void)
+{
+   return run_command("ubifsumount", 0);
+}
+#else
+static int mount_ubifs(struct device_location *location)
+{
+   printf("Error: Cannot load image: no UBIFS support\n");
+   return -ENOSYS;
+}
+#endif
+
+#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
+static int init_mmc(void)
+{
+   /* Just for the case MMC is not yet initialized */
+   struct mmc *mmc = NULL;
+   int err;
+
+   spl_mmc_find_device(, spl_boot_device());
+
+   err = mmc_init(mmc);
+   if (err) {
+   printf("spl: mmc init failed with error: %d\n", err);
+   return err;
+   }
+
+   return err;
+}
+#else
+static int init_mmc(void)
+{
+   /* Expect somewhere already initialize MMC */
+   return 0;
+}
+#endif
+
+static int select_fs_dev(struct device_location *location)
+{
+   int ret;
+
+   if (!strcmp("mmc", location->name)) {
+   ret = fs_set_blk_dev("mmc", location->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("usb", location->name)) {
+   ret = fs_set_blk_dev("usb", location->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("sata", location->name)) {
+   ret = fs_set_blk_dev("sata", location->devpart, FS_TYPE_ANY);
+   } else if (!strcmp("ubi", location->name)) {
+   if (location->ubivol != NULL)
+   ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
+   else
+   ret = -ENODEV;
+   } else {
+   printf("Error: unsupported location storage.\n");
+   return -ENODEV;
+   }
+
+   if (ret)
+   printf("Error: could not access storage.\n");
+
+   return ret;
+}
+
+static int init_storage_device(struct device_location *location)
+{
+   int ret;
+
+   if (!strcmp("mmc", location->name)) {
+   ret = init_mmc();
+   } else if (!strcmp("sata", location->name)) {
+   ret = init_storage_sata();
+   } else if (location->ubivol != NULL) {
+   ret = mount_ubifs(location);
+#ifndef 

[U-Boot] [PATCH v5 0/2] Generic firmware loader

[tien . fong . chee]

From: Tien Fong Chee 

This patchset contains generic firmware loader which is very close to Linux
firmware loader but for U-Boot framework. Generic firmware loader can be used
load whatever into target location, and then consumer driver would use it to
program whatever, ie. the FPGA. This version mainly resolved comments from
Lothar Waßmann, and Lukasz Majewski in [v4].

This series is working on top of u-boot.git -
 http://git.denx.de/u-boot.git .

[v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272432.html

v4 -> v5 changes:
-
- Changed the env variable name to lower case.
- Added memory freeing function in failure case.
- Assign valid pointer to *firmware_p only when everything is OK.
- Removed the casting on void pointer when assigning to any type pointer.
- Fixed withthe right return code.

Patchset history

[v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271905.html
[v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271979.html
[v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272039.html

Tien Fong Chee (2):
  spl: Remove static declaration on spl_mmc_find_device function
  common: Generic firmware loader for file system

 common/Makefile|   1 +
 common/fs_loader.c | 311 +
 common/spl/spl_mmc.c   |   2 +-
 doc/README.firmware_loader |  76 +++
 include/fs_loader.h|  28 
 include/spl.h  |   2 +
 6 files changed, 419 insertions(+), 1 deletion(-)
 create mode 100644 common/fs_loader.c
 create mode 100644 doc/README.firmware_loader
 create mode 100644 include/fs_loader.h

-- 
2.2.0

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

[U-Boot] [PATCH v5 1/2] spl: Remove static declaration on spl_mmc_find_device function

[tien . fong . chee]

From: Tien Fong Chee 

This patch removes the static declation on spl_mmc_find_device_function
so this function is accessible by the caller from other file. This patch
is required for later patch.

Signed-off-by: Tien Fong Chee 
---
 common/spl/spl_mmc.c | 2 +-
 include/spl.h| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index b57e0b0..183d05a 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -114,7 +114,7 @@ static int spl_mmc_get_device_index(u32 boot_device)
return -ENODEV;
 }
 
-static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
+int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 {
 #if CONFIG_IS_ENABLED(DM_MMC)
struct udevice *dev;
diff --git a/include/spl.h b/include/spl.h
index 308ce7b..912983a 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -10,6 +10,7 @@
 /* Platform-specific defines */
 #include 
 #include 
+#include 
 
 /* Value in r0 indicates we booted from U-Boot */
 #define UBOOT_NOT_LOADED_FROM_SPL  0x13578642
@@ -72,6 +73,7 @@ void preloader_console_init(void);
 u32 spl_boot_device(void);
 u32 spl_boot_mode(const u32 boot_device);
 void spl_set_bd(void);
+int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device);
 
 /**
  * spl_set_header_raw_uboot() - Set up a standard SPL image structure
-- 
2.2.0

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

[U-Boot] [PATCH v5 0/2] Generic firmware loader

[tien . fong . chee]

From: Tien Fong Chee 

This patchset contains generic firmware loader which is very close to Linux
firmware loader but for U-Boot framework. Generic firmware loader can be used
load whatever into target location, and then consumer driver would use it to
program whatever, ie. the FPGA. This version mainly resolved comments from
Lothar Waßmann, and Lukasz Majewski in [v4].

This series is working on top of u-boot.git -
 http://git.denx.de/u-boot.git .

[v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272432.html

v4 -> v5 changes:
-
- Changed the env variable name to lower case.
- Added memory freeing function in failure case.
- Assign valid pointer to *firmware_p only when everything is OK.
- Removed the casting on void pointer when assigning to any type pointer.
- Fixed with the right return code.

Patchset history

[v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271905.html
[v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271979.html
[v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272039.html

Tien Fong Chee (2):
  spl: Remove static declaration on spl_mmc_find_device function
  common: Generic firmware loader for file system

 common/Makefile|   1 +
 common/fs_loader.c | 311 +
 common/spl/spl_mmc.c   |   2 +-
 doc/README.firmware_loader |  76 +++
 include/fs_loader.h|  28 
 include/spl.h  |   2 +
 6 files changed, 419 insertions(+), 1 deletion(-)
 create mode 100644 common/fs_loader.c
 create mode 100644 doc/README.firmware_loader
 create mode 100644 include/fs_loader.h

-- 
2.2.0

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

Re: [U-Boot] [PATCH] bootm: flush cache on aligned region

[Lothar Waßmann]

Hi your name,

On Wed, 20 Dec 2017 09:12:28 -0800 your name wrote:
> From: Andrey Yurovsky 
> 
> bootm_load_os() uses flush_cache() on the region where the OS image is
> loaded however the OS image may be part of a FIT image and thereby may
> not be aligned with respect to the machine's cache lines. Give
> flush_cache() an aligned start of the region to avoid misalignment.
> 
> Signed-off-by: Andrey Yurovsky 
> ---
>  common/bootm.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/common/bootm.c b/common/bootm.c
> index adb12137c7..948807af25 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -447,7 +447,10 @@ static int bootm_load_os(bootm_headers_t *images, 
> unsigned long *load_end,
>   bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
>   return err;
>   }
> - flush_cache(load, ALIGN(*load_end - load, ARCH_DMA_MINALIGN));
> +
> + ulong load_a = ALIGN(load, ARCH_DMA_MINALIGN);
> +
This is WRONG. ALIGN() only ever _increases_ the value passed to it, so
the first ARCH_DMA_MINALIGN - 1 bytes of the image may not be flushed
in the worst case.

> + flush_cache(load_a, ALIGN(*load_end - load_a, ARCH_DMA_MINALIGN));
>  
>   debug("   kernel loaded at 0x%08lx, end = 0x%08lx\n", load, *load_end);
>   bootstage_mark(BOOTSTAGE_ID_KERNEL_LOADED);


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

Re: [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Sel, 2017-12-19 at 12:21 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Tue, 19 Dec 2017 10:31:13 + Chee, Tien Fong wrote:
> > 
> > On Isn, 2017-12-18 at 08:39 +0100, Lothar Waßmann wrote:
> > > 
> > > Hi,
> > > 
> > > On Mon, 18 Dec 2017 13:10:56 +0800 tien.fong.c...@intel.com
> > > wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  common/Makefile|   1 +
> > > >  common/fs_loader.c | 311
> > > > +
> > > >  doc/README.firmware_loader |  77 +++
> > > >  include/fs_loader.h|  28 
> > > >  4 files changed, 417 insertions(+)
> > > >  create mode 100644 common/fs_loader.c
> > > >  create mode 100644 doc/README.firmware_loader
> > > >  create mode 100644 include/fs_loader.h
> > > > 
> > > [...]
> > > > 
> > > > 
> > > > diff --git a/common/fs_loader.c b/common/fs_loader.c
> > > > new file mode 100644
> > > > index 000..81cf5d6
> > > > --- /dev/null
> > > > +++ b/common/fs_loader.c
> > > [...]
> > > > 
> > > > 
> > > > +/*
> > > > + * Prepare firmware struct;
> > > > + * return -ve if fail.
> > > > + */
> > > > +static int _request_firmware_prepare(struct firmware
> > > > **firmware_p,
> > > > +    const char *name, void
> > > > *dbuf,
> > > > +    size_t size, u32 offset)
> > > > +{
> > > > +   struct firmware *firmware = NULL;
> > > > +   struct firmware_priv *fw_priv = NULL;
> > > > +
> > > > +   *firmware_p = NULL;
> > > > +
> > > > +   if (!name || name[0] == '\0')
> > > > +   return -EINVAL;
> > > > +
> > > > +   *firmware_p = firmware = calloc(1, sizeof(*firmware));
> > > > +
> > > > +   if (!firmware) {
> > > > +   printf("%s: calloc(struct firmware) failed\n",
> > > > __func__);
> > > > +   return -ENOMEM;
> > > > +   }
> > > > +
> > > > +   fw_priv = calloc(1, sizeof(*fw_priv));
> > > > +
> > > > +   if (!fw_priv) {
> > > > +   printf("%s: calloc(struct fw_priv) failed\n",
> > > > __func__);
> > > > +   return -ENOMEM;
> > > What about freeing 'firmware' and NULLing *firmware_p here?
> > There is no "freeing" support in U-Boot. I can assign NULL
> > 
> How do you come to that conclusion?
> 
Sorry for misleading because i was tracking the free function until i
saw the function direct return when the bit GD_FLG_FULL_MALLOC_INIT was
found in gd->flags in beginning of the function long time ago. So, i
always assume that memory will always be freed in relocation on most
cases.
I will put the free to the firmware in next release.
> > 
> > to *firmware_p.
> > > 
> > > Or better, do the assignment of *firmware_p at the end.
> > Are you means switch the location between *firmware_p and fw_priv
> > in
> > calloc?
> > 
> No. I would assign *firmware_p only when everything else was OK, so
> that there won't be a valid pointer in *firmware_p when the struct
> firmware it is pointing to has not been set up completely.
> 
> I would do like this:
> static int _request_firmware_prepare(struct firmware **firmware_p,
>    const char *name, void *dbuf,
>    size_t size, u32 offset)
> {
>   struct firmware *firmware;
>   struct firmware_priv *fw_priv;
> 
>   *firmware_p = NULL;
> 
>   if (!name || name[0] == '\0')
>   return -EINVAL;
> 
>   firmware = calloc(1, sizeof(*firmware));
>   if (!firmware) {
>   printf("%s: calloc(struct firmware) failed\n",
> __func__);
>   return -ENOMEM;
>   }
> 
>   fw_priv = calloc(1, sizeof(*fw_priv));
>   if (!fw_priv) {
>   printf("%s: calloc(struct fw_priv) failed\n",
> __func__);
>   free(firmware);
>   return -ENOMEM;
>   }
> 
>   fw_priv->name = name;
>   fw_priv->offset = offset;
>   firmware->data = dbuf;
>   firmware->size = size;
>   firmware->priv = fw_priv;
>   *firmware_p = firmware;
> 
>   return 0;
> }
> so that *firmware_p is only assigned to when everything was OK.
> (Note, that there is no need to initialize firmware and fw_priv to
> NULL)
> 
Okay.
> > 
> > > 
> > > > 
> > > > + * fw_get_filesystem_firmware - load firmware into an
> > > > allocated
> > > > buffer
> > > > + * @location: An array of supported firmware location
> > > > + * @firmware_p: pointer to firmware image
> > > > + *
> > > > + * @return: size of total read
> > > > + * -ve when error
> > > > + */
> > > > +static int fw_get_filesystem_firmware(struct device_location
> > > > 

[U-Boot] [PATCH] linux/kernel.h: Add ALIGN_DOWN macro

[Masahiro Yamada]

Follow Linux commit ed067d4a859f ("linux/kernel.h: Add ALIGN_DOWN
macro").

Signed-off-by: Masahiro Yamada 
---

 include/linux/kernel.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 87d2d95..04a09eb 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -38,6 +38,7 @@
 #define REPEAT_BYTE(x) ((~0ul / 0xff) * (x))
 
 #define ALIGN(x,a) __ALIGN_MASK((x),(typeof(x))(a)-1)
+#define ALIGN_DOWN(x, a)   ALIGN((x) - ((a) - 1), (a))
 #define __ALIGN_MASK(x,mask)   (((x)+(mask))&~(mask))
 #define PTR_ALIGN(p, a)((typeof(p))ALIGN((unsigned long)(p), 
(a)))
 #define IS_ALIGNED(x, a)   (((x) & ((typeof(x))(a) - 1)) == 0)
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Lokesh Vutla]

On Wednesday 20 December 2017 09:35 PM, Tom Rini wrote:
> On Wed, Dec 20, 2017 at 08:59:37PM +0530, Lokesh Vutla wrote:
>> From: Rex Chang 
>>
>> Added support for K2G EVM with FlipChip SoC of which
>> ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
>> backward compatible with old revision EVM and EVM
>> with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.
>>
>> The new SoC supports 2 different speeds at 1GHz and 600MHz.
>> Modyfied the CPU Name to show which SoC is used in the EVM.
>> Modified the DDR3 configuration to reflect New SoC supports
>> 2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.
>>
>> Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
>> and set the u-boot env variable board_name accordingly.
>>
>> Modified findfdt script in u-boot environment variable to include new k2g 
>> board type.
>>
>> Signed-off-by: Rex Chang 
>> Signed-off-by: Lokesh Vutla 
> [snip]
>> diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
>> index 01328f1955..88df419b10 100644
>> --- a/board/ti/ks2_evm/board_k2g.c
>> +++ b/board/ti/ks2_evm/board_k2g.c
>> @@ -55,7 +55,7 @@ unsigned int get_external_clk(u32 clk)
>>  return clk_freq;
>>  }
>>  
>> -static int arm_speeds[DEVSPEED_NUMSPDS] = {
>> +int speeds[DEVSPEED_NUMSPDS] = {
> 
> With some quick git grep'ing, this should still be static, yes?  And
> then board/ti/ks2_evm/board_k2e.c should have its existing field marked
> as static too.

For k2g, speeds array is used in arch/arm/mach-keystone/init.c. So
removed static from here. For k2e yes, it should be static. Will send a
separate patch for fixing it.

> 
> [snip]
>> diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
>> index 44db335580..923401cfd2 100644
>> --- a/board/ti/ks2_evm/ddr3_k2g.c
>> +++ b/board/ti/ks2_evm/ddr3_k2g.c
> [snip]
>> @@ -53,6 +54,46 @@ struct ddr3_phy_config ddr3phy_800_2g = {
>>  .pir_v2 = 0x0F81ul,
>>  };
>>  
>> +struct ddr3_phy_config ddr3phy_1066_2g = {
> 
> And then all of these too should be static?
> 

Right, will post v3 fixing this.

Thanks and regards,
Lokesh

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

[U-Boot] [PATCH] bootm: flush cache on aligned region

[your name]

From: Andrey Yurovsky 

bootm_load_os() uses flush_cache() on the region where the OS image is
loaded however the OS image may be part of a FIT image and thereby may
not be aligned with respect to the machine's cache lines. Give
flush_cache() an aligned start of the region to avoid misalignment.

Signed-off-by: Andrey Yurovsky 
---
 common/bootm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/common/bootm.c b/common/bootm.c
index adb12137c7..948807af25 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -447,7 +447,10 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return err;
}
-   flush_cache(load, ALIGN(*load_end - load, ARCH_DMA_MINALIGN));
+
+   ulong load_a = ALIGN(load, ARCH_DMA_MINALIGN);
+
+   flush_cache(load_a, ALIGN(*load_end - load_a, ARCH_DMA_MINALIGN));
 
debug("   kernel loaded at 0x%08lx, end = 0x%08lx\n", load, *load_end);
bootstage_mark(BOOTSTAGE_ID_KERNEL_LOADED);
-- 
2.14.3

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

[U-Boot] [PATCH 2/2] sh: Drop unreferenced CONFIG_* defines

[Tuomas Tynkkynen]

The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_AP325RXA
CONFIG_AP_SH4A_4A
CONFIG_CPU_SH_TYPE_R
CONFIG_ECOVEC
CONFIG_ESPT
CONFIG_MIGO_R
CONFIG_MPR2
CONFIG_MS7720SE
CONFIG_MS7722SE
CONFIG_MS7750SE
CONFIG_R0P7734
CONFIG_R2DPLUS
CONFIG_RSK7203
CONFIG_RSK7264
CONFIG_RSK7269
CONFIG_SH7752EVB
CONFIG_SH7753EVB
CONFIG_SH7757LCR
CONFIG_SH7763RDP
CONFIG_SH7785LCR

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/MigoR.h  |  1 -
 include/configs/ap325rxa.h   |  1 -
 include/configs/ap_sh4a_4a.h |  1 -
 include/configs/ecovec.h |  1 -
 include/configs/espt.h   |  1 -
 include/configs/mpr2.h   |  1 -
 include/configs/ms7720se.h   |  1 -
 include/configs/ms7722se.h   |  1 -
 include/configs/ms7750se.h   |  1 -
 include/configs/r0p7734.h|  1 -
 include/configs/r2dplus.h|  2 --
 include/configs/rsk7203.h|  1 -
 include/configs/rsk7264.h|  1 -
 include/configs/rsk7269.h|  1 -
 include/configs/sh7752evb.h  |  1 -
 include/configs/sh7753evb.h  |  1 -
 include/configs/sh7757lcr.h  |  1 -
 include/configs/sh7763rdp.h  |  1 -
 include/configs/sh7785lcr.h  |  1 -
 scripts/config_whitelist.txt | 20 
 20 files changed, 40 deletions(-)

diff --git a/include/configs/MigoR.h b/include/configs/MigoR.h
index 3cf2f0984a..dbdf3dc0cf 100644
--- a/include/configs/MigoR.h
+++ b/include/configs/MigoR.h
@@ -10,7 +10,6 @@
 #define __MIGO_R_H
 
 #define CONFIG_CPU_SH7722  1
-#define CONFIG_MIGO_R  1
 
 #define CONFIG_DISPLAY_BOARDINFO
 #undef  CONFIG_SHOW_BOOT_PROGRESS
diff --git a/include/configs/ap325rxa.h b/include/configs/ap325rxa.h
index c09769dbed..4c2a2bd737 100644
--- a/include/configs/ap325rxa.h
+++ b/include/configs/ap325rxa.h
@@ -11,7 +11,6 @@
 #define __AP325RXA_H
 
 #define CONFIG_CPU_SH7723  1
-#define CONFIG_AP325RXA1
 
 #define CONFIG_DISPLAY_BOARDINFO
 #undef  CONFIG_SHOW_BOOT_PROGRESS
diff --git a/include/configs/ap_sh4a_4a.h b/include/configs/ap_sh4a_4a.h
index 717ec80f82..37aaec30c5 100644
--- a/include/configs/ap_sh4a_4a.h
+++ b/include/configs/ap_sh4a_4a.h
@@ -10,7 +10,6 @@
 #define __AP_SH4A_4A_H
 
 #define CONFIG_CPU_SH7734  1
-#define CONFIG_AP_SH4A_4A  1
 #define CONFIG_400MHZ_MODE 1
 
 #define CONFIG_SYS_TEXT_BASE 0x8BFC
diff --git a/include/configs/ecovec.h b/include/configs/ecovec.h
index 8cb3efc96d..c6fb59f753 100644
--- a/include/configs/ecovec.h
+++ b/include/configs/ecovec.h
@@ -23,7 +23,6 @@
  */
 
 #define CONFIG_CPU_SH7724  1
-#define CONFIG_ECOVEC  1
 
 #define CONFIG_ECOVEC_ROMIMAGE_ADDR 0xA004
 #define CONFIG_SYS_TEXT_BASE 0x8FFC
diff --git a/include/configs/espt.h b/include/configs/espt.h
index 628406ae6b..a5ac8cb584 100644
--- a/include/configs/espt.h
+++ b/include/configs/espt.h
@@ -11,7 +11,6 @@
 #define __ESPT_H
 
 #define CONFIG_CPU_SH7763  1
-#define CONFIG_ESPT1
 #define __LITTLE_ENDIAN1
 
 #define CONFIG_ENV_OVERWRITE1
diff --git a/include/configs/mpr2.h b/include/configs/mpr2.h
index 14b0492eb7..a6e172659f 100644
--- a/include/configs/mpr2.h
+++ b/include/configs/mpr2.h
@@ -18,7 +18,6 @@
 
 /* CPU and platform */
 #define CONFIG_CPU_SH7720  1
-#define CONFIG_MPR21
 
 #define CONFIG_DISPLAY_BOARDINFO
 
diff --git a/include/configs/ms7720se.h b/include/configs/ms7720se.h
index 7a9aa82158..cade328a9c 100644
--- a/include/configs/ms7720se.h
+++ b/include/configs/ms7720se.h
@@ -10,7 +10,6 @@
 #define __MS7720SE_H
 
 #define CONFIG_CPU_SH7720  1
-#define CONFIG_MS7720SE1
 
 #define CONFIG_BOOTFILE"/boot/zImage"
 #define CONFIG_LOADADDR0x8E00
diff --git a/include/configs/ms7722se.h b/include/configs/ms7722se.h
index 431d747489..3db6c249c2 100644
--- a/include/configs/ms7722se.h
+++ b/include/configs/ms7722se.h
@@ -10,7 +10,6 @@
 #define __MS7722SE_H
 
 #define CONFIG_CPU_SH7722  1
-#define CONFIG_MS7722SE1
 
 #define CONFIG_DISPLAY_BOARDINFO
 #undef  CONFIG_SHOW_BOOT_PROGRESS
diff --git a/include/configs/ms7750se.h b/include/configs/ms7750se.h
index e942758b32..1cd7ae0303 100644
--- a/include/configs/ms7750se.h
+++ b/include/configs/ms7750se.h
@@ -12,7 +12,6 @@
 #define CONFIG_CPU_SH7750  1
 /* #define CONFIG_CPU_SH7751   1 */
 /* #define CONFIG_CPU_TYPE_R   1 */
-#define CONFIG_MS7750SE1
 #define __LITTLE_ENDIAN__  1
 
 #define CONFIG_DISPLAY_BOARDINFO
diff --git a/include/configs/r0p7734.h b/include/configs/r0p7734.h
index 1fef8b5f92..9258a3bcde 100644
--- a/include/configs/r0p7734.h
+++ b/include/configs/r0p7734.h
@@ -10,7 +10,6 @@
 #define __R0P7734_H
 
 #define CONFIG_CPU_SH7734  1
-#define CONFIG_R0P7734 1
 #define CONFIG_400MHZ_MODE 1
 
 #define CONFIG_SYS_TEXT_BASE 0x8FFC
diff --git a/include/configs/r2dplus.h 

[U-Boot] [PATCH 1/2] ARM: Drop unreferenced CONFIG_MACH_* defines

[Tuomas Tynkkynen]

These macros are all defined once and never checked or used anywhere:

CONFIG_MACH_ASPENITE
CONFIG_MACH_DAVINCI_CALIMAIN
CONFIG_MACH_DOCKSTAR
CONFIG_MACH_EDMINIV2
CONFIG_MACH_GOFLEXHOME
CONFIG_MACH_GONI
CONFIG_MACH_GURUPLUG
CONFIG_MACH_KM_KIRKWOOD
CONFIG_MACH_OPENRD_BASE
CONFIG_MACH_SHEEVAPLUG

Almost all of them were only used for the mach_is_foo() logic in
arch/arm/asm/mach-types.h that were dropped in
commit f9dadaef8b75fa ("arm: Re-sync asm/mach-types.h with
Linux Kernel v4.9")

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/aspenite.h   |  1 -
 include/configs/calimain.h   |  1 -
 include/configs/dockstar.h   |  1 -
 include/configs/edminiv2.h   |  1 -
 include/configs/goflexhome.h |  1 -
 include/configs/guruplug.h   |  1 -
 include/configs/km/km_arm.h  |  1 -
 include/configs/openrd.h |  1 -
 include/configs/s5p_goni.h   |  1 -
 include/configs/sheevaplug.h |  1 -
 scripts/config_whitelist.txt | 10 --
 11 files changed, 20 deletions(-)

diff --git a/include/configs/aspenite.h b/include/configs/aspenite.h
index 36d74f3b26..d2f4c441c8 100644
--- a/include/configs/aspenite.h
+++ b/include/configs/aspenite.h
@@ -16,7 +16,6 @@
 #define CONFIG_SHEEVA_88SV331xV5   1   /* CPU Core subversion */
 #define CONFIG_ARMADA100   1   /* SOC Family Name */
 #define CONFIG_ARMADA168   1   /* SOC Used on this Board */
-#define CONFIG_MACH_ASPENITE   /* Machine type */
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
 
 /*
diff --git a/include/configs/calimain.h b/include/configs/calimain.h
index 60068d1fbb..7686592ee1 100644
--- a/include/configs/calimain.h
+++ b/include/configs/calimain.h
@@ -21,7 +21,6 @@
 /*
  * SoC Configuration
  */
-#define CONFIG_MACH_DAVINCI_CALIMAIN
 #define CONFIG_SOC_DA8XX   /* TI DA8xx SoC */
 #define CONFIG_SOC_DA850   /* TI DA850 SoC */
 #define CONFIG_SYS_EXCEPTION_VECTORS_HIGH
diff --git a/include/configs/dockstar.h b/include/configs/dockstar.h
index 1802a6e5c0..72386a671e 100644
--- a/include/configs/dockstar.h
+++ b/include/configs/dockstar.h
@@ -17,7 +17,6 @@
  */
 #define CONFIG_FEROCEON_88FR1311   /* CPU Core subversion */
 #define CONFIG_KW88F6281   1   /* SOC Name */
-#define CONFIG_MACH_DOCKSTAR   /* Machine type */
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
 
 /*
diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h
index 2b7a5d7c5c..b77cfc5d21 100644
--- a/include/configs/edminiv2.h
+++ b/include/configs/edminiv2.h
@@ -35,7 +35,6 @@
 #define CONFIG_MARVELL 1
 #define CONFIG_FEROCEON1   /* CPU Core subversion */
 #define CONFIG_88F5182 1   /* SOC Name */
-#define CONFIG_MACH_EDMINIV2   1   /* Machine type */
 
 #include 
 /*
diff --git a/include/configs/goflexhome.h b/include/configs/goflexhome.h
index 16e55b0c2b..0dc8ed143e 100644
--- a/include/configs/goflexhome.h
+++ b/include/configs/goflexhome.h
@@ -20,7 +20,6 @@
  */
 #define CONFIG_FEROCEON_88FR1311   /* CPU Core subversion */
 #define CONFIG_KW88F6281   1   /* SOC Name */
-#define CONFIG_MACH_GOFLEXHOME /* Machine type */
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
 
 /*
diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h
index b13c6c9279..dcb2a698f8 100644
--- a/include/configs/guruplug.h
+++ b/include/configs/guruplug.h
@@ -14,7 +14,6 @@
  * High Level Configuration Options (easy to change)
  */
 #define CONFIG_SHEEVA_88SV131  1   /* CPU Core subversion */
-#define CONFIG_MACH_GURUPLUG   /* Machine type */
 
 /*
  * Standard filesystems
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 277f8be60e..ed58d1e76c 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -26,7 +26,6 @@
 #define CONFIG_MARVELL
 #define CONFIG_FEROCEON_88FR131/* CPU Core subversion */
 #define CONFIG_KW88F6281   /* SOC Name */
-#define CONFIG_MACH_KM_KIRKWOOD/* Machine type */
 
 #define CONFIG_MACH_TYPE   MACH_TYPE_KM_KIRKWOOD
 
diff --git a/include/configs/openrd.h b/include/configs/openrd.h
index 1bea7f58cb..0165d9cf0e 100644
--- a/include/configs/openrd.h
+++ b/include/configs/openrd.h
@@ -19,7 +19,6 @@
  */
 #define CONFIG_SHEEVA_88SV131  1   /* CPU Core subversion */
 #define CONFIG_KW88F6281   1   /* SOC Name */
-#define CONFIG_MACH_OPENRD_BASE/* Machine type */
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
 
 /*
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 86835e735e..1aa1671738 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -15,7 +15,6 @@
 #define CONFIG_SAMSUNG 1   /* in a SAMSUNG core */
 #define CONFIG_S5P 1   /* which is in a S5P Family */
 #define CONFIG_S5PC110 1 

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

[Bin Meng]

Hi Tom,

The following changes since commit b55c89ce0207d3a504238c1b8f268c56035656a3:

  Merge git://git.denx.de/u-boot-spi (2017-12-19 07:57:40 -0500)

are available in the git repository at:

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

for you to fetch changes up to 1602d215b595b9cf4be460101f5c8892623fe3a0:

  x86: tangier: Use official ACPI HID for FLIS IP (2017-12-21 09:18:05 +0800)


Andy Shevchenko (1):
  x86: tangier: Use official ACPI HID for FLIS IP

 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

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

[U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation

[Clemens Gruber]

The blob_encap and blob_decap functions were not flushing the dcache
before passing data to CAAM/DMA and not invalidating the dcache when
getting data back.
Therefore, blob encapsulation and decapsulation failed with errors like
the following due to data cache incoherency:
"4006: DECO: desc idx 0: Invalid KEY command"

To ensure coherency, we allocate aligned memory to store the data passed
to/from CAAM and flush/invalidate the memory regions.
Blobs can now be encapsulated and decapsulated with the blob cmd as well
as from board code by calling blob_encap and blob_decap directly.

Tested on an i.MX6Q board.

Signed-off-by: Clemens Gruber 
---
 drivers/crypto/fsl/fsl_blob.c | 99 ---
 1 file changed, 83 insertions(+), 16 deletions(-)

diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
index 38c6f9486b..65ce21f4af 100644
--- a/drivers/crypto/fsl/fsl_blob.c
+++ b/drivers/crypto/fsl/fsl_blob.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "jobdesc.h"
@@ -15,56 +16,122 @@
 
 int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
 {
-   int ret, i = 0;
+   ALLOC_CACHE_ALIGN_BUFFER(u8, aligned_key_mod, 16);
+   u8 *aligned_src, *aligned_dst;
+   int ret, size, i = 0;
u32 *desc;
 
printf("\nDecapsulating blob to get data\n");
-   desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE);
+   desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
if (!desc) {
debug("Not enough memory for descriptor allocation\n");
-   return -1;
+   return -ENOMEM;
}
 
-   inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len);
+   aligned_src = malloc_cache_aligned(BLOB_SIZE(len));
+   aligned_dst = malloc_cache_aligned(len);
+   if (!aligned_src || !aligned_dst) {
+   debug("Not enough memory for blob allocations\n");
+   return -ENOMEM;
+   }
+
+   memcpy(aligned_key_mod, key_mod, 16);
+   size = ALIGN(16, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)aligned_key_mod,
+  (unsigned long)aligned_key_mod + size);
+
+   memcpy(aligned_src, src, BLOB_SIZE(len));
+   size = ALIGN(BLOB_SIZE(len), ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)aligned_src,
+  (unsigned long)aligned_src + size);
+
+   inline_cnstr_jobdesc_blob_decap(desc, aligned_key_mod, aligned_src,
+   aligned_dst, len);
 
debug("Descriptor dump:\n");
for (i = 0; i < 14; i++)
debug("Word[%d]: %08x\n", i, *(desc + i));
+
+   size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)desc,
+  (unsigned long)desc + size);
+
ret = run_descriptor_jr(desc);
 
-   if (ret)
-   printf("Error in Decapsulation %d\n", ret);
-   else
-   printf("Decapsulation Success\n");
+   if (ret) {
+   printf("Error in blob decapsulation: %d\n", ret);
+   } else {
+   size = ALIGN(len, ARCH_DMA_MINALIGN);
+   invalidate_dcache_range((unsigned long)aligned_dst,
+   (unsigned long)aligned_dst + size);
+   memcpy(dst, aligned_dst, len);
+
+   puts("Blob decapsulation successful.\n");
+   }
 
+   free(aligned_dst);
+   free(aligned_src);
free(desc);
return ret;
 }
 
 int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
 {
-   int ret, i = 0;
+   ALLOC_CACHE_ALIGN_BUFFER(u8, aligned_key_mod, 16);
+   u8 *aligned_src, *aligned_dst;
+   int ret, size, i = 0;
u32 *desc;
 
printf("\nEncapsulating data to form blob\n");
-   desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE);
+   desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
if (!desc) {
debug("Not enough memory for descriptor allocation\n");
-   return -1;
+   return -ENOMEM;
}
 
-   inline_cnstr_jobdesc_blob_encap(desc, key_mod, src, dst, len);
+   aligned_src = malloc_cache_aligned(len);
+   aligned_dst = malloc_cache_aligned(BLOB_SIZE(len));
+   if (!aligned_src || !aligned_dst) {
+   debug("Not enough memory for blob allocations\n");
+   return -ENOMEM;
+   }
+
+   memcpy(aligned_key_mod, key_mod, 16);
+   size = ALIGN(16, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)aligned_key_mod,
+  (unsigned long)aligned_key_mod + size);
+
+   memcpy(aligned_src, src, len);
+   size = ALIGN(len, ARCH_DMA_MINALIGN);
+   flush_dcache_range((unsigned long)aligned_src,
+  (unsigned long)aligned_src + size);
+
+   

Re: [U-Boot] ARM64 Allwinner Binary Size

[Duncan Hare]

 From: Jagan Teki 
On Wed, Dec 20, 2017 at 11:22 PM, Duncan Hare  wrote:
>> An observation: The Banana PI boards, allwinner based, I've use have a 
>> boot.scr file on the fat partition to direct booting.
>> A Suggestion: If this is widespread, the memory used by the u-boot image 
>> could be reduce by eliminating much of the
>> pre-defined boot hush scripts.

>not exactly are you trying to avoid env space to not define extra
>variable instead scripts? which board from Bpi are you using?
___
Jagan
We tried the B PI 2 and 3 believe.
We dropped them, because of the inability to manage over-scan. If there is 
documentation on this we could not find it, nor could the board manufacturer 
send it to us.

If u-boot is using boot.scr for a boot script, it appears nearly everything 
else in the environment, especially the predefined scripts, are not needed, and 
if there is a "size of u-boot issue", this might be a mechanism to reduce 
u-boot's overall size.

It was a suggestion, Not a recommendation.
 Duncan Hare

714 931 7952


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

Re: [U-Boot] License violations

[Maxim Sloyko]

Hi Jon,

This looks like a good start: https://opensource.org/faq#copyleft-violation

On Tue, Dec 19, 2017 at 9:21 PM, Jon 'jcase' Sawyer 
wrote:

> I've been attempting to obtain source to the u boot implementation in a
> tablet used to control DJI drones, called crystal sky.  Today after many
> games of chase the tail, DJI came back and told me they wouldn't release
> it.
>
> Is there anyone more capable, who could help put some pressure on this
> large corperation?
>
>
>
> JC
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>



-- 
*M*axim *S*loyko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] arm: sunxi: Allwinner A10 SPI driver

[Jagan Teki]

On Wed, Dec 20, 2017 at 11:42 AM, Stefan Mavrodiev
 wrote:
> On 12/13/2017 08:27 AM, Jagan Teki wrote:
>>
>> On Wed, Dec 13, 2017 at 11:43 AM, Stefan Mavrodiev 
>> wrote:
>>>
>>> On 12/13/2017 07:19 AM, Jagan Teki wrote:

 On Fri, Dec 8, 2017 at 5:08 PM, Jagan Teki 
 wrote:
>
> On Fri, Dec 8, 2017 at 2:05 PM, Stefan Mavrodiev 
> wrote:
>>
>> Add spi driver for sun4i, sun5i and sun7i SoCs. The driver is
>> adapted from mailine kernel (currently 4.15.0-rc1).
>>
>> Signed-off-by: Stefan Mavrodiev 
>> ---
>
> Reviewed-by: Jagan Teki 

 Are you planning to send dts and configs changes for this? I'm enough
 confident to apply only when it tested.

 thanks!
>>>
>>>
>>> I'm not sure I understand you.
>>>
>>> I've made the test with Lime2, but the spi flash is optional in
>>> production.
>>> Thus I'm not sure if changes in the dts and config should be made.
>>> I've tried pushing spi node to mainline kernel dts, but the patch wasn't
>>> accepted. https://patchwork.kernel.org/patch/10076721/
>>
>> Yes I've seen.
>>
>>> I can update sun4i, sun5i and sun7i dtsi files to add spi0_pins_b, if
>>> this
>>> is the point of your question.
>>
>> But it should accept Linux first for dts updates.
>>
>> thanks!
>
>
> I guess there won't be any changes in the device tree files as described
> here:
> https://patchwork.kernel.org/patch/10109445/

ok then send the dts sync as separate patch, will test and try to
submit all together.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Jagan Teki]

On Wed, Dec 20, 2017 at 11:22 PM, Duncan Hare  wrote:
> An observation: The Banana PI boards, allwinner based, I've use have a 
> boot.scr file on the fat partition to direct booting.
> A Suggestion: If this is widespread, the memory used by the u-boot image 
> could be reduce by eliminating much of the
> pre-defined boot hush scripts.

not exactly are you trying to avoid env space to not define extra
variable instead scripts? which board from Bpi are you using?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] ARM64 Allwinner Binary Size

[Duncan Hare]

An observation: The Banana PI boards, allwinner based, I've use have a boot.scr 
file on the fat partition to direct booting.
A Suggestion: If this is widespread, the memory used by the u-boot image could 
be reduce by eliminating much of the 
pre-defined boot hush scripts.

I offer this as an observation and suggestion. It may have no merit. Duncan Hare

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

Re: [U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Marek Vasut]

On 12/20/2017 12:51 PM, Jan Siegmund wrote:
[...]
>>> My preferred usecase would be configuring the registers in the table below 
>>> in
>>> SPL and configuring the FPGA in Linux, with a design using the FPGA-to-HPS 
>>> SDRAM
>>> interface.
>>>
>>> For example, the last bits in the portcfg register define whether the
>>> FPGA-to-HPS SDRAM interface's protocol is AXI or Avalon MM. The problem is, 
>>> that
>>> this register can't be written to in U-Boot, even though it is specified as 
>>> rw
>>> [3]. Can this register just be set by programming the FPGA?
>>
>> You might need to regenerate the SPL if you changed those kinds of
>> settings. The SPL programs these based on the handoff files IIRC.
> 
> I generated the headers using the bsp-editor from Quartus 17 and converted 
> them
> using the qts-filter.sh script in U-Boot. Since then, I did not change any 
> settings.
> 
> sdram.h in board/.../qts and mach-socfpga/
> 
>   #define CONFIG_HPS_SDR_CTRLCFG_PORTCFG_AUTOPCHEN0
> 
>   #define SDR_CTRLGRP_PORTCFG_AUTOPCHEN_LSB   10
> 
> wrap_sdram_config.c
>   .port_cfg =
>   (CONFIG_HPS_SDR_CTRLCFG_PORTCFG_AUTOPCHEN <<
>   SDR_CTRLGRP_PORTCFG_AUTOPCHEN_LSB),
> 
> sdram.c
>   debug("Configuring PORTCFG\n");
>   writel(cfg->port_cfg, _ctrl->port_cfg);
> 
> When I add some debug printing around the code shown above, SPL console shows 
> this:
> 
> U-Boot SPL 2018.01-rc1-00129-ga8548b9-dirty (Dec 18 2017 - 14:13:21)
> Content of ffc2507c is 3f
> Wrote 0 to ffc2507c
> Content of ffc2507c is 3f
> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
> drivers/ddr/altera/sequencer.c: Calibration complete
> Trying to boot from MMC1
> 
> Maybe the portprotocol part of portcfg is just a status register. But then
> again, why would it be specified as rw?

It should be RW actually.

> Do you have any idea what I might be missing, to get the f2s running without
> programming the FPGA?
CCing Dinh and Chin.

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

Re: [U-Boot] [GIT] Pull request: u-boot-dfu (20.12.2017)

[Marek Vasut]

On 12/20/2017 01:52 PM, Lukasz Majewski wrote:
> Dear Marek,

Hi,

I presume this is for -next , right ?

> The following changes since commit
> 8cd368294e917e205f61b2c66cdeed6f4c08a100:
> 
>   power: pmic/regulator: Add basic support for TPS65910 (2017-12-20
>   13:47:18 +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dfu.git 
> 
> for you to fetch changes up to e3d35f7cf7eeb4fec97e34f6efbb68ad7220c006:
> 
>   rockchip: rk3288: enable rockusb support on rk3288 based device
>   (2017-12-20 13:47:19 +0100)
> 
> 
> Eddie Cai (4):
>   usb: rockchip: add the rockusb gadget
>   usb: rockchip: add rockusb command
>   rockchip:usb: add a simple readme for rockusb
>   rockchip: rk3288: enable rockusb support on rk3288 based device
> 
>  MAINTAINERS|   7 +
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h | 133 ++
>  arch/arm/mach-rockchip/Kconfig |   2 +
>  cmd/Kconfig|   8 +
>  cmd/Makefile   |   1 +
>  cmd/rockusb.c  |  74 ++
>  configs/chromebit_mickey_defconfig |   7 +
>  configs/chromebook_jerry_defconfig |   7 +
>  configs/chromebook_minnie_defconfig|   7 +
>  configs/evb-rk3288_defconfig   |   9 +
>  configs/fennec-rk3288_defconfig|   5 +
>  configs/firefly-rk3288_defconfig   |   7 +
>  configs/miqi-rk3288_defconfig  |   5 +
>  configs/phycore-rk3288_defconfig   |   6 +
>  configs/popmetal-rk3288_defconfig  |   5 +
>  configs/rock2_defconfig|   8 +
>  configs/tinker-rk3288_defconfig|   5 +
>  configs/vyasa-rk3288_defconfig |  25 ++
>  doc/README.rockusb |  51 
>  drivers/usb/gadget/Kconfig |   8 +
>  drivers/usb/gadget/Makefile|   1 +
>  drivers/usb/gadget/f_rockusb.c | 718
>  + 22 files
>  changed, 1099 insertions(+) create mode 100644
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h create mode 100644
>  cmd/rockusb.c create mode 100644 doc/README.rockusb
>  create mode 100644 drivers/usb/gadget/f_rockusb.c
> 
> 
> 
> Travis-CI tests: https://travis-ci.org/lmajewski/u-boot-dfu/builds
> Checkpatch is clean.
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> 


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

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

[Tom Warren]

Stephen,

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, December 19, 2017 6:31 PM
> To: Tom Warren 
> Cc: Simon Glass ; Tom Rini ; u-
> b...@lists.denx.de; Stephen Warren 
> Subject: [PATCH 1/4] ARM: tegra: don't use CONFIG_SPL_TEXT_BASE when no
> SPL
> 
> From: Stephen Warren 
> 
> 64-bit Tegra don't use SPL, and soon won't define CONFIG_SPL_TEXT_BASE
> when building. Fix the binman .dts file so that it doesn't use undefined 
> values.
> 
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/dts/tegra-u-boot.dtsi | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 

This series: Reviewed-by: Tom Warren 

I'll wait a bit for other reviews & apply it to u-boot-tegra today or tomorrow.

Tom
> diff --git a/arch/arm/dts/tegra-u-boot.dtsi b/arch/arm/dts/tegra-u-boot.dtsi
> index cde591c5fca4..4f692ee97572 100644
> --- a/arch/arm/dts/tegra-u-boot.dtsi
> +++ b/arch/arm/dts/tegra-u-boot.dtsi
> @@ -1,5 +1,11 @@
>  #include 
> 
> +#ifdef CONFIG_SPL_TEXT_BASE
> +#define U_BOOT_OFFSET (CONFIG_SYS_TEXT_BASE -
> CONFIG_SPL_TEXT_BASE)
> +#else #define U_BOOT_OFFSET 0 #endif
> +
>  / {
>   binman {
>   multiple-images;
> @@ -9,8 +15,7 @@
>   u-boot-spl {
>   };
>   u-boot {
> - pos = <(CONFIG_SYS_TEXT_BASE -
> - CONFIG_SPL_TEXT_BASE)>;
> + pos = <(U_BOOT_OFFSET)>;
>   };
>   };
> 
> @@ -21,8 +26,7 @@
>   u-boot-spl {
>   };
>   u-boot {
> - pos = <(CONFIG_SYS_TEXT_BASE -
> - CONFIG_SPL_TEXT_BASE)>;
> + pos = <(U_BOOT_OFFSET)>;
>   };
>   };
> 
> @@ -32,8 +36,7 @@
>   u-boot-spl {
>   };
>   u-boot-nodtb {
> - pos = <(CONFIG_SYS_TEXT_BASE -
> - CONFIG_SPL_TEXT_BASE)>;
> + pos = <(U_BOOT_OFFSET)>;
>   };
>   };
>   };
> --
> 2.15.1
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sf: parse Serial Flash Discoverable Parameters (SFDP) tables

[Cyrille Pitchen]

Hi Prabhakar,

Le 20/12/2017 à 11:32, Prabhakar Kushwaha a écrit :
> This patch adds support to the JESD216 rev B standard and parses the
> SFDP tables to dynamically initialize the 'struct spi_nor_flash_parameter'.
> 
> It has been ported from Linux commit "mtd: spi-nor: parse Serial Flash
> Discoverable Parameters (SFDP) tables". It Also ports all modifications
> done on top of the mentioned commit.
> 
> This feature is enabled by defining FLASH_SFDP in spi_flash_info's flag 
> field. 
> 
> Signed-off-by: Prabhakar Kushwaha 
> CC: Cyrille Pitchen 
> CC: Marek Vasut 
> ---
>  drivers/mtd/spi/sf_internal.h | 204 +
>  drivers/mtd/spi/spi_flash.c   | 416 
> +-
>  2 files changed, 619 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 164b0ea..73fe207 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -12,6 +12,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  /* Dual SPI flash memories - see SPI_COMM_DUAL_... */
>  enum spi_dual_flash {
> @@ -82,6 +83,7 @@ enum spi_nor_option_flags {
>  #define CMD_FLAG_STATUS  0x70
>  #define CMD_EN4B 0xB7
>  #define CMD_EX4B 0xE9
> +#define CMD_READ_SFDP0x5a
>  
>  /* Bank addr access commands */
>  #ifdef CONFIG_SPI_FLASH_BAR
> @@ -155,9 +157,211 @@ struct spi_flash_info {
>* Use dedicated 4byte address op codes
>* to support memory size above 128Mib.
>*/
> +#define FLASH_SFDP   BIT(9)   /* Parse SFDP tables */
>  #define RD_FULL  (RD_QUAD | RD_DUAL | RD_QUADIO | 
> RD_DUALIO)
>  };
>  
> +struct sfdp_parameter_header {
> + u8  id_lsb;
> + u8  minor;
> + u8  major;
> + u8  length; /* in double words */
> + u8  parameter_table_pointer[3]; /* byte address */
> + u8  id_msb;
> +};
> +
> +#define SFDP_PARAM_HEADER_ID(p)  (((p)->id_msb << 8) | (p)->id_lsb)
> +#define SFDP_PARAM_HEADER_PTP(p) \
> + (((p)->parameter_table_pointer[2] << 16) | \
> +  ((p)->parameter_table_pointer[1] <<  8) | \
> +  ((p)->parameter_table_pointer[0] <<  0))
> +
> +#define SFDP_BFPT_ID 0xff00  /* Basic Flash Parameter Table */
> +#define SFDP_SECTOR_MAP_ID   0xff81  /* Sector Map Table */
> +
> +#define SFDP_SIGNATURE   0x50444653U
> +#define SFDP_JESD216_MAJOR   1
> +#define SFDP_JESD216_MINOR   0
> +#define SFDP_JESD216A_MINOR  5
> +#define SFDP_JESD216B_MINOR  6
> +
> +struct sfdp_header {
> + u32 signature; /* Ox50444653U <=> "SFDP" */
> + u8  minor;
> + u8  major;
> + u8  nph; /* 0-base number of parameter headers */
> + u8  unused;
> +
> + /* Basic Flash Parameter Table. */
> + struct sfdp_parameter_headerbfpt_header;
> +};
> +
> +/* Basic Flash Parameter Table */
> +
> +/*
> + * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
> + * They are indexed from 1 but C arrays are indexed from 0.
> + */
> +#define BFPT_DWORD(i)((i) - 1)
> +#define BFPT_DWORD_MAX   16
> +
> +/* The first version of JESB216 defined only 9 DWORDs. */
> +#define BFPT_DWORD_MAX_JESD216   9
> +
> +/* 1st DWORD. */
> +#define BFPT_DWORD1_FAST_READ_1_1_2  BIT(16)
> +#define BFPT_DWORD1_ADDRESS_BYTES_MASK   GENMASK(18, 17)
> +#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY (0x0UL << 17)
> +#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 (0x1UL << 17)
> +#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY (0x2UL << 17)
> +#define BFPT_DWORD1_DTR  BIT(19)
> +#define BFPT_DWORD1_FAST_READ_1_2_2  BIT(20)
> +#define BFPT_DWORD1_FAST_READ_1_4_4  BIT(21)
> +#define BFPT_DWORD1_FAST_READ_1_1_4  BIT(22)
> +
> +/* 5th DWORD. */
> +#define BFPT_DWORD5_FAST_READ_2_2_2  BIT(0)
> +#define BFPT_DWORD5_FAST_READ_4_4_4  BIT(4)
> +
> +/* 11th DWORD. */
> +#define BFPT_DWORD11_PAGE_SIZE_SHIFT 4
> +#define BFPT_DWORD11_PAGE_SIZE_MASK  GENMASK(7, 4)
> +
> +/* 15th DWORD. */
> +
> +/*
> + * (from JESD216 rev B)
> + * Quad Enable Requirements (QER):
> + * - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4
> + * reads based on instruction. DQ3/HOLD# functions are hold during
> + * instruction phase.
> + * - 001b: QE is bit 1 of status register 2. It is set via Write Status with
> + * two data bytes where bit 1 of the second byte is one.
> + * [...]
> + * Writing only one byte to the status register has the side-effect 
> of
> + * clearing 

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

[A.W.C.]

Hi,

U-Boot 2009.03 on custom board. How to restore NVRAM on MTD partition from 
backup use U-boot memory commands, by uploading backup over serial line? 
(kermit mode or ymodem mode)
NAND flash type.

Regards,
Alex


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

Re: [U-Boot] [PATCH 2/3] sf: add method to support memory size above 128Mib

[Cyrille Pitchen]

Hi Prabhakar,

Le 20/12/2017 à 11:32, Prabhakar Kushwaha a écrit :
> This patch add support of memories with size above 128Mib. It has
> been ported from Linux commit "mtd: spi-nor: add a
> stateless method to support memory size above 128Mib".
> 
> It convert 3byte opcode into 4byte opcode based upon
> OPCODES_4B or Spansion flash. Also the commands are malloc'ed
> at run time based on 3byte or 4byte address opcode requirement.
> 
> Signed-off-by: Prabhakar Kushwaha 
> CC: Cyrille Pitchen 
> CC: Marek Vasut 
> CC: Vignesh R 
> ---
> depends upon https://patchwork.ozlabs.org/patch/826919/
> 
>  drivers/mtd/spi/sf_internal.h |  28 -
>  drivers/mtd/spi/spi_flash.c   | 136 
> --
>  include/spi_flash.h   |   2 +
>  3 files changed, 146 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 06dee0a..164b0ea 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -27,7 +27,8 @@ enum spi_nor_option_flags {
>  };
>  
>  #define SPI_FLASH_3B_ADDR_LEN3
> -#define SPI_FLASH_CMD_LEN(1 + SPI_FLASH_3B_ADDR_LEN)
> +#define SPI_FLASH_4B_ADDR_LEN4
> +#define SPI_FLASH_MAX_ADDR_WIDTH 4
>  #define SPI_FLASH_16MB_BOUN  0x100
>  
>  /* CFI Manufacture ID's */
> @@ -57,13 +58,30 @@ enum spi_nor_option_flags {
>  #define CMD_READ_DUAL_IO_FAST0xbb
>  #define CMD_READ_QUAD_OUTPUT_FAST0x6b
>  #define CMD_READ_QUAD_IO_FAST0xeb
> +
> +/* 4B READ commands */
> +#define CMD_READ_ARRAY_SLOW_4B   0x13
> +#define CMD_READ_ARRAY_FAST_4B   0x0c
> +#define CMD_READ_DUAL_OUTPUT_FAST_4B 0x3c
> +#define CMD_READ_DUAL_IO_FAST_4B 0xbc
> +#define CMD_READ_QUAD_OUTPUT_FAST_4B 0x6c
> +#define CMD_READ_QUAD_IO_FAST_4B 0xec
> +
> +/* 4B Write commands */
> +#define CMD_PAGE_PROGRAM_4B  0x12
> +
> +/* 4B Erase commands */
> +#define CMD_ERASE_4K_4B  0x21
> +#define CMD_ERASE_CHIP_4B0x5c
> +#define CMD_ERASE_64K_4B 0xdc
> +
>  #define CMD_READ_ID  0x9f
>  #define CMD_READ_STATUS  0x05
>  #define CMD_READ_STATUS1 0x35
>  #define CMD_READ_CONFIG  0x35
>  #define CMD_FLAG_STATUS  0x70
> -#define CMD_EN4B 0xB7
> -#define CMD_EX4B 0xE9
> +#define CMD_EN4B 0xB7
> +#define CMD_EX4B 0xE9
>  
>  /* Bank addr access commands */
>  #ifdef CONFIG_SPI_FLASH_BAR
> @@ -133,6 +151,10 @@ struct spi_flash_info {
>  #define RD_DUAL  BIT(5)  /* use Dual Read */
>  #define RD_QUADIOBIT(6)  /* use Quad IO Read */
>  #define RD_DUALIOBIT(7)  /* use Dual IO Read */
> +#define OPCODES_4B   BIT(8)  /*
> +  * Use dedicated 4byte address op codes
> +  * to support memory size above 128Mib.
> +  */
>  #define RD_FULL  (RD_QUAD | RD_DUAL | RD_QUADIO | 
> RD_DUALIO)
>  };
>  
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 7581622..4d2e58e 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -22,12 +22,28 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -static void spi_flash_addr(u32 addr, u8 *cmd)
> +static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
>  {
>   /* cmd[0] is actual command */
> - cmd[1] = addr >> 16;
> - cmd[2] = addr >> 8;
> - cmd[3] = addr >> 0;
> +
> + switch (flash->addr_width) {
> + case SPI_FLASH_3B_ADDR_LEN:
> + cmd[1] = addr >> 16;
> + cmd[2] = addr >> 8;
> + cmd[3] = addr >> 0;
> + break;
> +
> + case SPI_FLASH_4B_ADDR_LEN:
> + cmd[1] = addr >> 24;
> + cmd[2] = addr >> 16;
> + cmd[3] = addr >> 8;
> + cmd[4] = addr >> 0;
> + break;
> +
> + default:
> + debug("SF: Wrong opcode size\n");
> + break;
> + }

Not a big deal and mostly a question of personal taste but you can have a
look at what's done by the m25p80 driver from linux (m25p_addr2cmd()
function):

cmd[1] = addr >> (flash->addr_width * 8 -  8);
cmd[2] = addr >> (flash->addr_width * 8 - 16);
cmd[3] = addr >> (flash->addr_width * 8 - 24);
cmd[4] = addr >> (flash->addr_width * 8 - 32);

>  }
>  
>  static int read_sr(struct spi_flash *flash, u8 *rs)
> @@ -74,6 +90,64 @@ static int write_sr(struct spi_flash *flash, u8 ws)
>   return 0;
>  }
>  
> +static u8 spi_flash_convert_opcode(u8 opcode, const u8 table[][2], size_t 
> size)
> +{
> + size_t i;
> +

Re: [U-Boot] [EXT] Re: arm64: a37xx: add distro boot compability

[Kostya Porotchkin]

Hi, Andre,

> -Original Message-
> From: Andre Heider [mailto:a.hei...@gmail.com]
> Sent: Thursday, December 14, 2017 14:50
> To: Kostya Porotchkin; Stefan Roese
> Cc: u-boot@lists.denx.de; Nadav Haklai; Igal Liberman
> Subject: Re: [EXT] Re: arm64: a37xx: add distro boot compability
> 
> Hi Kostya,
> 
> On 14/12/17 13:21, Kostya Porotchkin wrote:
> >> While having the attention of both of you:
> >> Downstream has diverged quite a bit compared to upstream, is there
> >> any ongoing work to upstream the missing bits?
> > [Konstantin Porotchkin] I need to understand the terminology first :-)
> > The upstream is the DENX release and the downstream is Marvell's
> 2017.03?
> 
> Exactly ;)
> 
> >> Konstantin, since the discrepancy got pretty big I guess most users
> >> are currently using a downstream release. Is there any chance to get
> >> this set in there? I already got these patches against that tree if
> it helps.
> > [Konstantin Porotchkin] If my assumption above is right, you are
> asking when we are planning to sync with the current mainline, right?
> > Unfortunately this is out of my control. We are planning to do so as
> soon as we have time for it, but we got pretty busy supporting new SoC
> devices at this moment.
> 
> Alright, and I can see that syncing would be a rather big task.
> 
> But instead I was offering the same patches against the Marvell tree,
> without the need for any syncing.
> 
> They're now in a pull request I just created on Marvell's public github:
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/pull/8
[Konstantin Porotchkin] Thank you, I hope that I or Igal (in CC list) will have 
some time shortly for merging your changes into our GIT.

Regards
Kosta
> 
> Thanks,
> Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Tom Rini]

On Wed, Dec 20, 2017 at 08:59:37PM +0530, Lokesh Vutla wrote:
> From: Rex Chang 
> 
> Added support for K2G EVM with FlipChip SoC of which
> ARM/DDR3 runs at 1GHz/1066 MT/s. The patch is also
> backward compatible with old revision EVM and EVM
> with WireBond SoC. Their ARM/DDR3 run at 600MHz/800 MT/s.
> 
> The new SoC supports 2 different speeds at 1GHz and 600MHz.
> Modyfied the CPU Name to show which SoC is used in the EVM.
> Modified the DDR3 configuration to reflect New SoC supports
> 2 different CPU and DDR3 speeds, 1GHz/1066MT and 600MHz/800MT.
> 
> Added new inline function board_it_k2g_g1() for the new FlipChip 1GHz,
> and set the u-boot env variable board_name accordingly.
> 
> Modified findfdt script in u-boot environment variable to include new k2g 
> board type.
> 
> Signed-off-by: Rex Chang 
> Signed-off-by: Lokesh Vutla 
[snip]
> diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
> index 01328f1955..88df419b10 100644
> --- a/board/ti/ks2_evm/board_k2g.c
> +++ b/board/ti/ks2_evm/board_k2g.c
> @@ -55,7 +55,7 @@ unsigned int get_external_clk(u32 clk)
>   return clk_freq;
>  }
>  
> -static int arm_speeds[DEVSPEED_NUMSPDS] = {
> +int speeds[DEVSPEED_NUMSPDS] = {

With some quick git grep'ing, this should still be static, yes?  And
then board/ti/ks2_evm/board_k2e.c should have its existing field marked
as static too.

[snip]
> diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
> index 44db335580..923401cfd2 100644
> --- a/board/ti/ks2_evm/ddr3_k2g.c
> +++ b/board/ti/ks2_evm/ddr3_k2g.c
[snip]
> @@ -53,6 +54,46 @@ struct ddr3_phy_config ddr3phy_800_2g = {
>   .pir_v2 = 0x0F81ul,
>  };
>  
> +struct ddr3_phy_config ddr3phy_1066_2g = {

And then all of these too should be static?

-- 
Tom


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

Re: [U-Boot] [PATCH v4] drivers: core: Add translation in live tree case

[Stephen Warren]

On 12/20/2017 01:52 AM, Mario Six wrote:

The function dev_read_addr calls ofnode_get_addr_index in the live tree
case, which does not apply bus translations to the address read from the
device tree. This results in illegal addresses on boards that rely on
bus translations being applied.

Fix this situation by applying bus translations in the live tree case as
well.

Signed-off-by: Mario Six 

---
v3 -> v4:
* Fixed issue on 64-bit platforms


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

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

[Lokesh Vutla]

This series consolidates few bug fixes on TI platforms.

Changes since v1:
- Removed ifdef aroung externs

Lokesh Vutla (3):
  configs: k2g_evm: Allocate more space for u-boot
  tools: omapimage: Fix mismatch of image size in header
  arm: am33xx: Avoid writing into reserved DPLL divider

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

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

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

-- 
2.15.1

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

[U-Boot] [PATCH v2 2/5] board: TI K2G: FC SoC 1GHz and DDR3 1066 MT/s support

[Lokesh Vutla]

From: Rex Chang 

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

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

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

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

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

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

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

[Lokesh Vutla]

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

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

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

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

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

[Lokesh Vutla]

From: Tomi Valkeinen 

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

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

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

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

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

[Lokesh Vutla]

The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage tool is updating size
as image size + 2 * header size. Remove this extra header size bytes.

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

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

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

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

[Lokesh Vutla]

Now that we have multi dtb enabled in u-boot allocate
128K space for u-boot.

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

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

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

[U-Boot] [PATCH] configs: am57xx_evm: fix ethernet phy configuration

[Sekhar Nori]

Configure AM57xx EVMs for the exact PHY part that is
present on the various boards. This makes U-Boot apply
configurations needed for this PHY like centering the
FLP timing.

For configurations to take effect, DM_ETH needs to be
enabled. Do that too.

Tested on BeagleBoard x15 and AM571x IDK.

Signed-off-by: Sekhar Nori 
---
 configs/am57xx_evm_defconfig| 3 +++
 configs/am57xx_hs_evm_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index fc96401d3e55..04484e0ae213 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -52,6 +52,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_PALMAS=y
 CONFIG_DM_REGULATOR=y
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 681e2a54c8ff..6c33cc9030e0 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -55,6 +55,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_PALMAS=y
 CONFIG_DM_REGULATOR=y
-- 
2.9.0

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

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

[Mario Six]

From: Mario Six 

To debug device tree issues involving 32- and 64-bit platforms, it is useful to
have a generic 64-bit platform available.

Add a version of the sandbox that uses 64-bit integers for its physical
addresses as well as a modified device tree.

Signed-off-by: Mario Six 

---
 arch/sandbox/Kconfig |   6 +
 arch/sandbox/cpu/cpu.c   |   2 +-
 arch/sandbox/dts/Makefile|   4 +
 arch/sandbox/dts/sandbox64.dts   | 317 +++
 arch/sandbox/include/asm/io.h|   6 +
 arch/sandbox/include/asm/types.h |  14 +-
 cmd/demo.c   |   6 +-
 configs/sandbox64_defconfig  | 200 
 drivers/demo/demo-simple.c   |   2 +-
 9 files changed, 550 insertions(+), 7 deletions(-)
 create mode 100644 arch/sandbox/dts/sandbox64.dts
 create mode 100644 configs/sandbox64_defconfig

diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index 87418e3986..be001604aa 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -10,6 +10,11 @@ config SYS_BOARD
 config SYS_CPU
default "sandbox"

+config SANDBOX64
+   bool "Use 64-bit addresses"
+   select PHYS_64BIT
+   select SANDBOX_64BIT
+
 config SANDBOX_SPL
bool "Enable SPL for sandbox"
select SUPPORT_SPL
@@ -29,6 +34,7 @@ choice

 config SANDBOX_32BIT
bool "32-bit host"
+   depends on !SANDBOX64

 config SANDBOX_64BIT
bool "64-bit host"
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 66c3a6a88a..4a20fde787 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -76,7 +76,7 @@ void *map_physmem(phys_addr_t paddr, unsigned long len, 
unsigned long flags)
if (enable_pci_map && !pci_map_physmem(paddr, , _dev, )) {
if (plen != len) {
printf("%s: Warning: partial map at %x, wanted %lx, got 
%lx\n",
-  __func__, paddr, len, plen);
+  __func__, (uint)paddr, len, plen);
}
map_len = len;
return ptr;
diff --git a/arch/sandbox/dts/Makefile b/arch/sandbox/dts/Makefile
index 0197569262..861b4dc2b1 100644
--- a/arch/sandbox/dts/Makefile
+++ b/arch/sandbox/dts/Makefile
@@ -2,7 +2,11 @@
 # SPDX-License-Identifier: GPL-2.0+
 #

+ifdef CONFIG_SANDBOX64
+dtb-$(CONFIG_SANDBOX) += sandbox64.dtb
+else
 dtb-$(CONFIG_SANDBOX) += sandbox.dtb
+endif
 dtb-$(CONFIG_UT_DM) += test.dtb

 targets += $(dtb-y)
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
new file mode 100644
index 00..18be889db6
--- /dev/null
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -0,0 +1,317 @@
+/dts-v1/;
+
+#define USB_CLASS_HUB  9
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   model = "sandbox";
+
+   aliases {
+   eth5 = "/eth@9000";
+   i2c0 = _0;
+   pci0 = 
+   rtc0 = _0;
+   };
+
+   chosen {
+   stdout-path = "/serial";
+   };
+
+   cros_ec: cros-ec@0 {
+   reg = <0 0 0 0>;
+   compatible = "google,cros-ec-sandbox";
+
+   /*
+* This describes the flash memory within the EC. Note
+* that the STM32L flash erases to 0, not 0xff.
+*/
+   #address-cells = <1>;
+   #size-cells = <1>;
+   flash@800 {
+   reg = <0x0800 0x2>;
+   erase-value = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Information for sandbox */
+   ro {
+   reg = <0 0xf000>;
+   };
+   wp-ro {
+   reg = <0xf000 0x1000>;
+   };
+   rw {
+   reg = <0x1 0x1>;
+   };
+   };
+   };
+
+   eth@10002000 {
+   compatible = "sandbox,eth";
+   reg = <0x0 0x10002000 0x0 0x1000>;
+   fake-host-hwaddr = [00 00 66 44 22 00];
+   };
+
+   eth@8000 {
+   compatible = "sandbox,eth-raw";
+   reg = <0x0 0x8000 0x0 0x1000>;
+   host-raw-interface = "eth0";
+   };
+
+   eth@9000 {
+   compatible = "sandbox,eth-raw";
+   reg = <0x0 0x9000 0x0 0x1000>;
+   host-raw-interface = "lo";
+   };
+
+   gpio_a: gpios@0 {
+   gpio-controller;
+   compatible = "sandbox,gpio";
+   #gpio-cells = <1>;
+   gpio-bank-name = "a";
+   num-gpios = <20>;
+   };
+
+   gpio_b: gpios@1 {
+   gpio-controller;
+   compatible = "sandbox,gpio";
+   

[U-Boot] [PATCH] xilinx: zynqmp: Use strlen only if env_get doesn't return null

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Add check if boot_targets exists in environment and then
generate new_targets env accordingly. Performing strlen on
null address causes it to fail with exception if isolation
is enabled with DDR address zero as secure. It works with out
isolation enabled as zero is valid address but it may lead to
junk values in boot_targets.
This patch fixes the issue by checking return value of env_get
so that it generate boot_targets properly.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index c198a4d92063..8b6c0ea46698 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -346,6 +346,7 @@ int board_late_init(void)
u8 bootmode;
const char *mode;
char *new_targets;
+   char *env_targets;
int ret;
 
if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
@@ -418,10 +419,16 @@ int board_late_init(void)
 * One terminating char + one byte for space between mode
 * and default boot_targets
 */
-   new_targets = calloc(1, strlen(mode) +
-   strlen(env_get("boot_targets")) + 2);
+   env_targets = env_get("boot_targets");
+   if (env_targets) {
+   new_targets = calloc(1, strlen(mode) +
+strlen(env_targets) + 2);
+   sprintf(new_targets, "%s %s", mode, env_targets);
+   } else {
+   new_targets = calloc(1, strlen(mode) + 2);
+   sprintf(new_targets, "%s", mode);
+   }
 
-   sprintf(new_targets, "%s %s", mode, env_get("boot_targets"));
env_set("boot_targets", new_targets);
 
return 0;
-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/2] ARM: sunxi: Enable DM MMC+SATA for the PcDuino3 Nano board

[Tuomas Tynkkynen]

On Wed, 2017-12-20 at 13:26 +0100, Maxime Ripard wrote:
> On Mon, Dec 18, 2017 at 10:09:42PM +0200, Tuomas Tynkkynen wrote:
> > After the previous commit which adds support for the cd-inverted
> > property to the sunxi MMC driver, driver-model MMC works fine on
> > this
> > board.
> > 
> > Signed-off-by: Tuomas Tynkkynen 
> > ---
> >  configs/Linksprite_pcDuino3_Nano_defconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig
> > b/configs/Linksprite_pcDuino3_Nano_defconfig
> > index 13538fafd1..44ce8b3ead 100644
> > --- a/configs/Linksprite_pcDuino3_Nano_defconfig
> > +++ b/configs/Linksprite_pcDuino3_Nano_defconfig
> > @@ -17,9 +17,11 @@ CONFIG_SPL_I2C_SUPPORT=y
> >  # CONFIG_SPL_ISO_PARTITION is not set
> >  # CONFIG_SPL_EFI_PARTITION is not set
> >  CONFIG_SCSI_AHCI=y
> > +CONFIG_DM_MMC=y
> >  CONFIG_ETH_DESIGNWARE=y
> >  CONFIG_RGMII=y
> >  CONFIG_SUN7I_GMAC=y
> >  CONFIG_SCSI=y
> > +CONFIG_DM_SCSI=y
> 
> Those should not be in a single defconfig, but enabled for all the
> Allwinner boards (that have SATA and MMC).
> 
> Maxime
> 

Makes sense. I don't have any other boards to test with so I just
imitated Simon's change for the non-Nano pcduino3.

I will try to see if this could be imply'd in Kconfig.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mmc: sunxi: Support cd-inverted DT property

[Tuomas Tynkkynen]

On Wed, 2017-12-20 at 13:26 +0100, Maxime Ripard wrote:
> On Mon, Dec 18, 2017 at 10:09:41PM +0200, Tuomas Tynkkynen wrote:
> > Commit 8620f384098b ("dm: sunxi: Linksprite_pcDuino3: Correct
> > polarity
> > of MMC card detect") claims that the Pcduino3 device tree has an
> > incorrect polarity for the card detect pin, but the actual problem
> > is
> > that unlike the Linux MMC driver, the U-Boot driver isn't
> > respecting the
> > cd-invert property (see
> > Documentation/devicetree/bindings/mmc/mmc.txt)
> > which tells that the card detect signal level should be inverted.
> > 
> > Fix this properly by adding support for the cd-inverted property
> > while
> > reverting the original commit at the same time. While at it, I
> > noticed
> > the driver always enables pullups for the card detect line, which
> > is not
> > right if the card detect GPIO is active-high, so fix that as well.
> > 
> > Signed-off-by: Tuomas Tynkkynen 
> > ---
> >  arch/arm/dts/sun7i-a20-pcduino3.dts |  2 +-
> >  drivers/mmc/sunxi_mmc.c | 12 ++--
> >  2 files changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/dts/sun7i-a20-pcduino3.dts
> > b/arch/arm/dts/sun7i-a20-pcduino3.dts
> > index 37b1e0ee9b..1a8b39be1d 100644
> > --- a/arch/arm/dts/sun7i-a20-pcduino3.dts
> > +++ b/arch/arm/dts/sun7i-a20-pcduino3.dts
> > @@ -164,7 +164,7 @@
> > pinctrl-0 = <_pins_a>,
> > <_cd_pin_reference_design>;
> > vmmc-supply = <_vcc3v3>;
> > bus-width = <4>;
> > -   cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
> > +   cd-gpios = < 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> > cd-inverted;
> > status = "okay";
> >  };
> > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > index 4edb4be46c..7cc7303570 100644
> > --- a/drivers/mmc/sunxi_mmc.c
> > +++ b/drivers/mmc/sunxi_mmc.c
> > @@ -30,6 +30,7 @@ struct sunxi_mmc_priv {
> > uint32_t *mclkreg;
> > unsigned fatal_err;
> > struct gpio_desc cd_gpio;   /* Change Detect GPIO */
> > +   int cd_inverted;
> > struct sunxi_mmc *reg;
> > struct mmc_config cfg;
> >  };
> > @@ -545,7 +546,7 @@ static int sunxi_mmc_getcd(struct udevice *dev)
> > struct sunxi_mmc_priv *priv = dev_get_priv(dev);
> >  
> > if (dm_gpio_is_valid(>cd_gpio))
> > -   return dm_gpio_get_value(>cd_gpio);
> > +   return dm_gpio_get_value(>cd_gpio) ^ priv-
> > >cd_inverted;
> >  
> > return 1;
> >  }
> > @@ -606,8 +607,15 @@ static int sunxi_mmc_probe(struct udevice
> > *dev)
> > if (!gpio_request_by_name(dev, "cd-gpios", 0, 
> > >cd_gpio,
> >   GPIOD_IS_IN)) {
> > int cd_pin = gpio_get_number(>cd_gpio);
> > +   int cd_state = priv->cd_gpio.flags &
> > GPIOD_ACTIVE_LOW ? 0 : 1;
> 
> Isn't that change itself enough to get what you wanted?
> 
> You really shouldn't be doing anything else.

Was that the correct part you meant to quote? The cd_state
was only for the somewhat pull-up change... Sorry about that,
here's the minimal (probably whitespace-damaged) change:

diff --git a/arch/arm/dts/sun7i-a20-pcduino3.dts 
b/arch/arm/dts/sun7i-a20-pcduino3.dts
index 37b1e0ee9b..1a8b39be1d 100644
--- a/arch/arm/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/dts/sun7i-a20-pcduino3.dts
@@ -164,7 +164,7 @@
pinctrl-0 = <_pins_a>, <_cd_pin_reference_design>;
vmmc-supply = <_vcc3v3>;
bus-width = <4>;
-   cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+   cd-gpios = < 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
cd-inverted;
status = "okay";
 };
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 4edb4be46c..a974543148 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -30,6 +30,7 @@ struct sunxi_mmc_priv {
uint32_t *mclkreg;
unsigned fatal_err;
struct gpio_desc cd_gpio;   /* Change Detect GPIO */
+   int cd_inverted;
struct sunxi_mmc *reg;
struct mmc_config cfg;
 };
@@ -545,7 +546,7 @@ static int sunxi_mmc_getcd(struct udevice *dev)
struct sunxi_mmc_priv *priv = dev_get_priv(dev);
 
if (dm_gpio_is_valid(>cd_gpio))
-   return dm_gpio_get_value(>cd_gpio);
+   return dm_gpio_get_value(>cd_gpio) ^ priv->cd_inverted;
 
return 1;
 }
@@ -607,6 +608,8 @@ static int sunxi_mmc_probe(struct udevice *dev)
  GPIOD_IS_IN)) {
int cd_pin = gpio_get_number(>cd_gpio);
 
+   priv->cd_inverted = dev_read_bool(dev, "cd-inverted");
+
sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
}
 
So: if the DT specifies GPIO_ACTIVE_LOW, dm_gpio_get_value()
does its own inversion of the GPIO level. Then, on top of that
we do another inversion if the "cd-inverted" property was specified.
This matches what the Linux MMC driver does.

Does that make sense?

Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size

[Jean-Jacques Hiblot]

On 19/12/2017 16:00, Tom Rini wrote:

On Tue, Dec 19, 2017 at 08:54:25AM -0600, Andrew F. Davis wrote:

On 12/16/2017 10:04 PM, Tom Rini wrote:

The am335x_hs_evm runs into size constraint problems at times with
various toolchains as changes come in due to the config have a large
number of options in SPL (to showcase what is possible) while also
having rather constrained binary limits.  Gain some of this room back by
lowering the loglevel, disabling HW partition support and switching over
to the tiny FIT image support.

Cc: Andrew F. Davis 
Signed-off-by: Tom Rini 
---
I'd really appreciate a run-time test of this patch if at all possible
as I'm a little worried about TINY_FIT being incompatible with all of
the security options.  Thanks!
---
  configs/am335x_hs_evm_defconfig | 4 
  1 file changed, 4 insertions(+)

diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 48b0e8583997..8eb304686dc7 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -13,10 +13,12 @@ CONFIG_ANDROID_BOOT_IMAGE=y
  CONFIG_FIT_IMAGE_POST_PROCESS=y
  CONFIG_SPL_LOAD_FIT=y
  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_LOGLEVEL=3
  CONFIG_SYS_CONSOLE_INFO_QUIET=y
  CONFIG_VERSION_VARIABLE=y
  CONFIG_ARCH_MISC_INIT=y
  CONFIG_SPL=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
  # CONFIG_SPL_ENV_SUPPORT is not set
  # CONFIG_SPL_EXT_SUPPORT is not set
  CONFIG_SPL_MTD_SUPPORT=y
@@ -37,6 +39,7 @@ CONFIG_DFU_RAM=y
  CONFIG_DM_I2C=y
  CONFIG_MISC=y
  CONFIG_DM_MMC=y
+# CONFIG_MMC_HW_PARTITIONING is not set

I haven't gotten around to testing the FIT_IMAGE_TINY stuff yet, but
conceptually I have a much bigger problem with this part.

Sacrificing functionality to allow continued SPL bloat is just wrong.

Whatever caused SPL to grow should be re-worked or the author should
have also made some optimization elsewhere to offset this. Now I'll have
to go hunt for more optimizations somewhere so I can get all my features
back here :(

FWIW, I don't think there was any functionality (aside from switching to
FIT_IMAGE_TINY, but if that supports everything needed in this
use-case...) that was removed exactly.  But I see your point too.
Jean-Jacques, was there anything else that could have been made
configurable in your MMC work, that wasn't?  Thanks!
I tried to make most of the new features optional. I'll try to scrap 
more bytes and will let you know


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

[U-Boot] [GIT] Pull request: u-boot-dfu (20.12.2017)

[Lukasz Majewski]

Dear Marek,

The following changes since commit
8cd368294e917e205f61b2c66cdeed6f4c08a100:

  power: pmic/regulator: Add basic support for TPS65910 (2017-12-20
  13:47:18 +0100)

are available in the git repository at:

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

for you to fetch changes up to e3d35f7cf7eeb4fec97e34f6efbb68ad7220c006:

  rockchip: rk3288: enable rockusb support on rk3288 based device
  (2017-12-20 13:47:19 +0100)


Eddie Cai (4):
  usb: rockchip: add the rockusb gadget
  usb: rockchip: add rockusb command
  rockchip:usb: add a simple readme for rockusb
  rockchip: rk3288: enable rockusb support on rk3288 based device

 MAINTAINERS|   7 +
 arch/arm/include/asm/arch-rockchip/f_rockusb.h | 133 ++
 arch/arm/mach-rockchip/Kconfig |   2 +
 cmd/Kconfig|   8 +
 cmd/Makefile   |   1 +
 cmd/rockusb.c  |  74 ++
 configs/chromebit_mickey_defconfig |   7 +
 configs/chromebook_jerry_defconfig |   7 +
 configs/chromebook_minnie_defconfig|   7 +
 configs/evb-rk3288_defconfig   |   9 +
 configs/fennec-rk3288_defconfig|   5 +
 configs/firefly-rk3288_defconfig   |   7 +
 configs/miqi-rk3288_defconfig  |   5 +
 configs/phycore-rk3288_defconfig   |   6 +
 configs/popmetal-rk3288_defconfig  |   5 +
 configs/rock2_defconfig|   8 +
 configs/tinker-rk3288_defconfig|   5 +
 configs/vyasa-rk3288_defconfig |  25 ++
 doc/README.rockusb |  51 
 drivers/usb/gadget/Kconfig |   8 +
 drivers/usb/gadget/Makefile|   1 +
 drivers/usb/gadget/f_rockusb.c | 718
 + 22 files
 changed, 1099 insertions(+) create mode 100644
 arch/arm/include/asm/arch-rockchip/f_rockusb.h create mode 100644
 cmd/rockusb.c create mode 100644 doc/README.rockusb
 create mode 100644 drivers/usb/gadget/f_rockusb.c



Travis-CI tests: https://travis-ci.org/lmajewski/u-boot-dfu/builds
Checkpatch is clean.


Best regards,

Lukasz Majewski

--

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


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

Re: [U-Boot] [PATCH 2/2] ARM: sunxi: Enable DM MMC+SATA for the PcDuino3 Nano board

[Maxime Ripard]

On Mon, Dec 18, 2017 at 10:09:42PM +0200, Tuomas Tynkkynen wrote:
> After the previous commit which adds support for the cd-inverted
> property to the sunxi MMC driver, driver-model MMC works fine on this
> board.
> 
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  configs/Linksprite_pcDuino3_Nano_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig 
> b/configs/Linksprite_pcDuino3_Nano_defconfig
> index 13538fafd1..44ce8b3ead 100644
> --- a/configs/Linksprite_pcDuino3_Nano_defconfig
> +++ b/configs/Linksprite_pcDuino3_Nano_defconfig
> @@ -17,9 +17,11 @@ CONFIG_SPL_I2C_SUPPORT=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_SCSI_AHCI=y
> +CONFIG_DM_MMC=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_RGMII=y
>  CONFIG_SUN7I_GMAC=y
>  CONFIG_SCSI=y
> +CONFIG_DM_SCSI=y

Those should not be in a single defconfig, but enabled for all the
Allwinner boards (that have SATA and MMC).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 1/2] mmc: sunxi: Support cd-inverted DT property

[Maxime Ripard]

On Mon, Dec 18, 2017 at 10:09:41PM +0200, Tuomas Tynkkynen wrote:
> Commit 8620f384098b ("dm: sunxi: Linksprite_pcDuino3: Correct polarity
> of MMC card detect") claims that the Pcduino3 device tree has an
> incorrect polarity for the card detect pin, but the actual problem is
> that unlike the Linux MMC driver, the U-Boot driver isn't respecting the
> cd-invert property (see Documentation/devicetree/bindings/mmc/mmc.txt)
> which tells that the card detect signal level should be inverted.
> 
> Fix this properly by adding support for the cd-inverted property while
> reverting the original commit at the same time. While at it, I noticed
> the driver always enables pullups for the card detect line, which is not
> right if the card detect GPIO is active-high, so fix that as well.
> 
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  arch/arm/dts/sun7i-a20-pcduino3.dts |  2 +-
>  drivers/mmc/sunxi_mmc.c | 12 ++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/dts/sun7i-a20-pcduino3.dts 
> b/arch/arm/dts/sun7i-a20-pcduino3.dts
> index 37b1e0ee9b..1a8b39be1d 100644
> --- a/arch/arm/dts/sun7i-a20-pcduino3.dts
> +++ b/arch/arm/dts/sun7i-a20-pcduino3.dts
> @@ -164,7 +164,7 @@
>   pinctrl-0 = <_pins_a>, <_cd_pin_reference_design>;
>   vmmc-supply = <_vcc3v3>;
>   bus-width = <4>;
> - cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
> + cd-gpios = < 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>   cd-inverted;
>   status = "okay";
>  };
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 4edb4be46c..7cc7303570 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -30,6 +30,7 @@ struct sunxi_mmc_priv {
>   uint32_t *mclkreg;
>   unsigned fatal_err;
>   struct gpio_desc cd_gpio;   /* Change Detect GPIO */
> + int cd_inverted;
>   struct sunxi_mmc *reg;
>   struct mmc_config cfg;
>  };
> @@ -545,7 +546,7 @@ static int sunxi_mmc_getcd(struct udevice *dev)
>   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
>  
>   if (dm_gpio_is_valid(>cd_gpio))
> - return dm_gpio_get_value(>cd_gpio);
> + return dm_gpio_get_value(>cd_gpio) ^ priv->cd_inverted;
>  
>   return 1;
>  }
> @@ -606,8 +607,15 @@ static int sunxi_mmc_probe(struct udevice *dev)
>   if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
> GPIOD_IS_IN)) {
>   int cd_pin = gpio_get_number(>cd_gpio);
> + int cd_state = priv->cd_gpio.flags & GPIOD_ACTIVE_LOW ? 0 : 1;

Isn't that change itself enough to get what you wanted?

You really shouldn't be doing anything else.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[U-Boot] [PATCH] freescale: vid: add support LTC3882 and rework of the VID support

[ying.zhang22455]

From: Zhang Ying-22455 

Add support new regular chip: LTC3882.

The origianl VID code didn't properly read the FUSESR on all chips
and set the voltages on all chips. It didn't properly support the
voltage regulators in use by NXP and report voltage changes.

Signed-off-by: Zhang Ying-22455 
---
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |9 +-
 board/freescale/common/vid.c   |  465 +++-
 board/freescale/common/vid.h   |   19 +
 3 files changed, 291 insertions(+), 202 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 957e23b..0ee7a3f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -201,10 +201,15 @@ struct ccsr_gur {
u32 gpporcr3;
u32 gpporcr4;
u8  res_030[0x60-0x30];
-#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 2
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 25
 #define FSL_CHASSIS3_DCFG_FUSESR_VID_MASK  0x1F
-#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  7
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  20
 #define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK   0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_VID_SHIFT 2
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_VID_MASK  0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_ALTVID_SHIFT  7
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_ALTVID_MASK   0x1F
+   u8  res_030[0x60-0x30];
u32 dcfg_fusesr;/* Fuse status register */
u8  res_064[0x70-0x64];
u32 devdisr;/* Device disable control 1 */
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index d6d1bfc..1e2ddb0 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -11,6 +11,7 @@
 #ifdef CONFIG_FSL_LSCH2
 #include 
 #elif defined(CONFIG_FSL_LSCH3)
+#include 
 #include 
 #else
 #include 
@@ -33,8 +34,42 @@ int __weak board_vdd_drop_compensation(void)
return 0;
 }
 
+#if defined(CONFIG_VOL_MONITOR_LTC3882)
+/* Helper function to write a mV value as LTC L16 into the chip,
+ * returning a boolean for success */
+static int write_l16_mV_LTC3882(int i2caddress, int cmd, int mv)
+{
+   int wait, vdd_last, l16;
+   int ret;
+   u8 buf[2];
+
+   /* Scale mV to L16 */
+   l16 = mv;
+   l16 <<= 12;
+   l16 /= 1000;
+   debug("VID: cmd 0x%02x voltage write 0x%04x\n", cmd, l16);
+   buf[0] = (l16 & 0xff);
+   buf[1] = (l16 >> 8);
+
+   /* This code assumes that both channels run the very
+* SAME voltage. This is likely true for LS2 style
+* devices. For any other configuration, all hell will
+* break loose!
+*/
+   ret = i2c_write(i2caddress, LTC3882_PAGE, 1,
+  (void *)"\377", 1);
+   if (!ret)
+   ret = i2c_write(i2caddress, cmd, 1,
+  (void *)[0], 2);
+   if (!ret)
+   ret = i2c_write(i2caddress, LTC3882_PAGE, 1,
+  (void *)"\0", 1);
+   return ret;
+}
+#endif
+
 /*
- * Get the i2c address configuration for the IR regulator chip
+ * Get the i2c address configuration for the regulator chip
  *
  * There are some variance in the RDB HW regarding the I2C address 
configuration
  * for the IR regulator chip, which is likely a problem of external resistor
@@ -45,9 +80,13 @@ int __weak board_vdd_drop_compensation(void)
  * 0x08 (Verified on T1040RDB-PA,T4240RDB-PB,X-T4240RDB-16GPA)
  * 0x09 (Verified on T1040RDB-PA)
  * 0x38 (Verified on T2080QDS, T2081QDS, T4240RDB)
+ *
+ * For other types of regulator chips, we check the IDs before we
+ * return the address to avoid making damaging mistakes
  */
-static int find_ir_chip_on_i2c(void)
+static int find_vid_chip_on_i2c(void)
 {
+#if defined(CONFIG_VOL_MONITOR_IR36021_READ) || 
defined(CONFIG_VOL_MONITOR_IR36021_SET)
int i2caddress;
int ret;
u8 byte;
@@ -63,6 +102,23 @@ static int find_ir_chip_on_i2c(void)
if ((ret >= 0) && (byte == IR36021_MFR_ID))
return i2caddress;
}
+#endif
+#if defined(CONFIG_VOL_MONITOR_LTC3882)
+   int i2caddress = I2C_VOL_MONITOR_ADDR;
+   int ret;
+   u8 buf[8];
+
+   ret = i2c_read(i2caddress,
+  LTC3882_MFR_ID, 1, (void *)[0],
+  4);
+   if (!ret && memcmp(buf, "\3LTC", 4) == 0) {
+   ret = i2c_read(i2caddress,
+  LTC3882_MFR_MODEL, 1, (void *)[0],
+  8);
+   if (!ret && memcmp(buf, "\7LTC3882", 8) == 0)
+   return i2caddress;
+   }
+#endif
return -1;
 }
 
@@ -83,10 +139,15 @@ static int find_ir_chip_on_i2c(void)
 #ifdef CONFIG_VOL_MONITOR_INA220
 #define WAIT_FOR_ADC   532 /* 

[U-Boot] [PATCH] freescale: vid: add support LTC3882 and rework of the VID support

[ying.zhang22455]

From: Zhang Ying-22455 

Add support new regular chip: LTC3882.

The origianl VID code didn't properly read the FUSESR on all chips
and set the voltages on all chips. It didn't properly support the
voltage regulators in use by NXP and report voltage changes.

Signed-off-by: Zhang Ying-22455 
---
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |9 +-
 board/freescale/common/vid.c   |  465 +++-
 board/freescale/common/vid.h   |   19 +
 3 files changed, 291 insertions(+), 202 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 957e23b..0ee7a3f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -201,10 +201,15 @@ struct ccsr_gur {
u32 gpporcr3;
u32 gpporcr4;
u8  res_030[0x60-0x30];
-#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 2
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 25
 #define FSL_CHASSIS3_DCFG_FUSESR_VID_MASK  0x1F
-#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  7
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  20
 #define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK   0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_VID_SHIFT 2
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_VID_MASK  0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_ALTVID_SHIFT  7
+#define FSL_CHASSIS3_DCFG_FUSESR_LOW_ALTVID_MASK   0x1F
+   u8  res_030[0x60-0x30];
u32 dcfg_fusesr;/* Fuse status register */
u8  res_064[0x70-0x64];
u32 devdisr;/* Device disable control 1 */
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index d6d1bfc..1e2ddb0 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -11,6 +11,7 @@
 #ifdef CONFIG_FSL_LSCH2
 #include 
 #elif defined(CONFIG_FSL_LSCH3)
+#include 
 #include 
 #else
 #include 
@@ -33,8 +34,42 @@ int __weak board_vdd_drop_compensation(void)
return 0;
 }
 
+#if defined(CONFIG_VOL_MONITOR_LTC3882)
+/* Helper function to write a mV value as LTC L16 into the chip,
+ * returning a boolean for success */
+static int write_l16_mV_LTC3882(int i2caddress, int cmd, int mv)
+{
+   int wait, vdd_last, l16;
+   int ret;
+   u8 buf[2];
+
+   /* Scale mV to L16 */
+   l16 = mv;
+   l16 <<= 12;
+   l16 /= 1000;
+   debug("VID: cmd 0x%02x voltage write 0x%04x\n", cmd, l16);
+   buf[0] = (l16 & 0xff);
+   buf[1] = (l16 >> 8);
+
+   /* This code assumes that both channels run the very
+* SAME voltage. This is likely true for LS2 style
+* devices. For any other configuration, all hell will
+* break loose!
+*/
+   ret = i2c_write(i2caddress, LTC3882_PAGE, 1,
+  (void *)"\377", 1);
+   if (!ret)
+   ret = i2c_write(i2caddress, cmd, 1,
+  (void *)[0], 2);
+   if (!ret)
+   ret = i2c_write(i2caddress, LTC3882_PAGE, 1,
+  (void *)"\0", 1);
+   return ret;
+}
+#endif
+
 /*
- * Get the i2c address configuration for the IR regulator chip
+ * Get the i2c address configuration for the regulator chip
  *
  * There are some variance in the RDB HW regarding the I2C address 
configuration
  * for the IR regulator chip, which is likely a problem of external resistor
@@ -45,9 +80,13 @@ int __weak board_vdd_drop_compensation(void)
  * 0x08 (Verified on T1040RDB-PA,T4240RDB-PB,X-T4240RDB-16GPA)
  * 0x09 (Verified on T1040RDB-PA)
  * 0x38 (Verified on T2080QDS, T2081QDS, T4240RDB)
+ *
+ * For other types of regulator chips, we check the IDs before we
+ * return the address to avoid making damaging mistakes
  */
-static int find_ir_chip_on_i2c(void)
+static int find_vid_chip_on_i2c(void)
 {
+#if defined(CONFIG_VOL_MONITOR_IR36021_READ) || 
defined(CONFIG_VOL_MONITOR_IR36021_SET)
int i2caddress;
int ret;
u8 byte;
@@ -63,6 +102,23 @@ static int find_ir_chip_on_i2c(void)
if ((ret >= 0) && (byte == IR36021_MFR_ID))
return i2caddress;
}
+#endif
+#if defined(CONFIG_VOL_MONITOR_LTC3882)
+   int i2caddress = I2C_VOL_MONITOR_ADDR;
+   int ret;
+   u8 buf[8];
+
+   ret = i2c_read(i2caddress,
+  LTC3882_MFR_ID, 1, (void *)[0],
+  4);
+   if (!ret && memcmp(buf, "\3LTC", 4) == 0) {
+   ret = i2c_read(i2caddress,
+  LTC3882_MFR_MODEL, 1, (void *)[0],
+  8);
+   if (!ret && memcmp(buf, "\7LTC3882", 8) == 0)
+   return i2caddress;
+   }
+#endif
return -1;
 }
 
@@ -83,10 +139,15 @@ static int find_ir_chip_on_i2c(void)
 #ifdef CONFIG_VOL_MONITOR_INA220
 #define WAIT_FOR_ADC   532 /* 

Re: [U-Boot] [PATCH v2 1/1] arm: sunxi: Allwinner A10 SPI driver

[Stefan Mavrodiev]

On 12/13/2017 08:27 AM, Jagan Teki wrote:

On Wed, Dec 13, 2017 at 11:43 AM, Stefan Mavrodiev  wrote:

On 12/13/2017 07:19 AM, Jagan Teki wrote:

On Fri, Dec 8, 2017 at 5:08 PM, Jagan Teki 
wrote:

On Fri, Dec 8, 2017 at 2:05 PM, Stefan Mavrodiev 
wrote:

Add spi driver for sun4i, sun5i and sun7i SoCs. The driver is
adapted from mailine kernel (currently 4.15.0-rc1).

Signed-off-by: Stefan Mavrodiev 
---

Reviewed-by: Jagan Teki 

Are you planning to send dts and configs changes for this? I'm enough
confident to apply only when it tested.

thanks!


I'm not sure I understand you.

I've made the test with Lime2, but the spi flash is optional in production.
Thus I'm not sure if changes in the dts and config should be made.
I've tried pushing spi node to mainline kernel dts, but the patch wasn't
accepted. https://patchwork.kernel.org/patch/10076721/

Yes I've seen.


I can update sun4i, sun5i and sun7i dtsi files to add spi0_pins_b, if this
is the point of your question.

But it should accept Linux first for dts updates.

thanks!


I guess there won't be any changes in the device tree files as described 
here:

https://patchwork.kernel.org/patch/10109445/

Best regards,
Stefan Mavrodiev

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

[U-Boot] License violations

[Jon 'jcase' Sawyer]

I've been attempting to obtain source to the u boot implementation in a
tablet used to control DJI drones, called crystal sky.  Today after many
games of chase the tail, DJI came back and told me they wouldn't release it.

Is there anyone more capable, who could help put some pressure on this
large corperation?



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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Emmanuel Vadot]

On Tue, 19 Dec 2017 15:09:52 +0100
Maxime Ripard  wrote:

> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
> > On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
> > > 1;5002;0c
> > > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
> > > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote:
> > > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > > > > > So even though the actual u-boot.bin for 64-bit boards is still 
> > > > > > somewhat
> > > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it 
> > > > > > over
> > > > > > the edge. So since v2017.11 u-boot.itb is already too big for the
> > > > > > traditional MMC env location.
> > > > > 
> > > > > So I've had a quick look about what could go possibly go away in our
> > > > > current armv8 config (using the pine64+ defconfig). Let me know if
> > > > > some are actually vitals:
> > > > > 
> > > > >  - FIT_ENABLE_SHA256_SUPPORT
> > > > >  - CONSOLE_MUX
> > > > >  - CMD_CRC32
> > > > >  - CMD_LZMADEC
> > > > >  - CMD_UNZIP
> > > > >  - CMD_LOADB
> > > > >  - CMD_LOADS
> > > > >  - CMD_MISC (actually implementing the command sleep)
> > > > >  - ISO_PARTITION (yes. For CDROMs.)
> > > > >  - VIDEO_BPP8, VIDEO_BPP16
> > > > >  - VIDEO_ANSI
> > > > >  - SHA256
> > > > >  - LZMA
> > > > > 
> > > > > Removing those options make the u-boot.itb binary size going from
> > > > > 516kB to 478kB, making it functional again *and* allowing us to enable
> > > > > the DT overlays that seem way more important than any feature
> > > > > mentionned above (and bumps the size to 483kB).
> > > > 
> > > > You want to keep sha256 support in FIT images, we only have dropping
> > > > that allowed for some very odd use-cases.  And while I don't have a
> > > > strong opinion about unzip, lzma is one of the valid/likelu compressions
> > > > for an Image (and aside, I, or someone, needs to look into having
> > > > 'booti' recognize various compression algorithms and automatically
> > > > decompress them) so I don't think we should get rid of that.
> > > 
> > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
> > > 499kB. Still tight, but it fits.
> > 
> > Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?
> 
> And we're at 498kB now! :)
> 
> Is CMD_ELF useful as well?

 Speaking for the BSDs, FreeBSD and OpenBSD are using EFI, NetBSD is
using uImage, CMD_ELF  be useful for test but people who run
test on u-boot should know how to configure it.

> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

Re: [U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Jan Siegmund]

Am 20.12.2017 um 10:35 schrieb Marek Vasut:
> On 12/20/2017 12:29 AM, Jan Siegmund wrote:
>> Am 18.12.2017 um 22:05 schrieb Marek Vasut:
>>> On 12/18/2017 09:44 PM, Jan Siegmund wrote:
>>
>> Hi Marek,
> 
> Hi,
> 

Hi Marek,

 Hi all,
>>>
>>> Hi,
>>>
 Here is another question on the FPGA to SDRAM interface of the Cyclone V 
 SoC.
 Is is possible to configure the the interface in U-Boot or SPL,
>>>
>>> What is "the interface" ?
>>
>> I am sorry I did not specify it further. I meant the FPGA-to-HPS SDRAM 
>> interface
>> [2], sometimes called FPGA2SDRAM bridge.
> 
> Oh OK. The F2S bridge is a bit special indeed.
> 
>>> If you mean DRAM, then yes, the CV/AV do _not_ configure the FPGA in SPL
>>> at all. They just configure the IOMUX/clock rings, but that's all.
>>>
>>
>> I know the FPGA is not configured in SPL, but does the FPGA need to be
>> configured in SPL or U-Boot, to use the FPGA-to-HPS SDRAM interface?
> 
> No
> 
>> Would it be
>> possible to just preset the registers for later configuration?
> 
> Yes
> 
>> My preferred usecase would be configuring the registers in the table below in
>> SPL and configuring the FPGA in Linux, with a design using the FPGA-to-HPS 
>> SDRAM
>> interface.
>>
>> For example, the last bits in the portcfg register define whether the
>> FPGA-to-HPS SDRAM interface's protocol is AXI or Avalon MM. The problem is, 
>> that
>> this register can't be written to in U-Boot, even though it is specified as 
>> rw
>> [3]. Can this register just be set by programming the FPGA?
> 
> You might need to regenerate the SPL if you changed those kinds of
> settings. The SPL programs these based on the handoff files IIRC.

I generated the headers using the bsp-editor from Quartus 17 and converted them
using the qts-filter.sh script in U-Boot. Since then, I did not change any 
settings.

sdram.h in board/.../qts and mach-socfpga/

#define CONFIG_HPS_SDR_CTRLCFG_PORTCFG_AUTOPCHEN0

#define SDR_CTRLGRP_PORTCFG_AUTOPCHEN_LSB   10

wrap_sdram_config.c
.port_cfg =
(CONFIG_HPS_SDR_CTRLCFG_PORTCFG_AUTOPCHEN <<
SDR_CTRLGRP_PORTCFG_AUTOPCHEN_LSB),

sdram.c
debug("Configuring PORTCFG\n");
writel(cfg->port_cfg, _ctrl->port_cfg);

When I add some debug printing around the code shown above, SPL console shows 
this:

U-Boot SPL 2018.01-rc1-00129-ga8548b9-dirty (Dec 18 2017 - 14:13:21)
Content of ffc2507c is 3f
Wrote 0 to ffc2507c
Content of ffc2507c is 3f
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
Trying to boot from MMC1

Maybe the portprotocol part of portcfg is just a status register. But then
again, why would it be specified as rw?

Do you have any idea what I might be missing, to get the f2s running without
programming the FPGA?

> 
 without reprogramming the FPGA? Maybe through the usage of the generated
 header files from the Quartus synthesis?
 The SDRAM controller's registers only differ in eight entries in Linux 
 when the
 FPGA is programmed or not.

 +--+-+++
 | address  |name | programmed | not programmed |
 +--+-+++
 | FFC25064 | | 00044003   | 00044FFF   |
 | FFC25068 | | 2C00   | 2C03   |
 | FFC2506c | | 00B0   | 00B3   |
 | FFC25070 | | 0076   | 0076   |
 | FFC25074 | | 0098   | 0098   |
 | FFC25078 | | 0005A003   | 0005AFFF   |
 | FFC2507c | portcfg |    | 003F   |
 | FFC25080 | fpgaportrst | 01FF   |    |
 +--+-+++

 The registers 0xFFC25064-0xFFC25078 don't show up on the HPS' memory map
 [1], so are they even intended to be configured?

 Thanks



 [1]
 https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577380716.html#sfo1411577380716

>>>
>>>
>>
>> Best regards,
>> Jan
>>
>> [2]
>> https://www.altera.com/documentation/sfo1410143707420.html#sfo1411577336440__section_N10012_N1000F_N10001
>>
>>
>> [3] https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577375739.html
>>
> 
> 

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

[U-Boot] [PATCH 3/3] sf: parse Serial Flash Discoverable Parameters (SFDP) tables

[Prabhakar Kushwaha]

This patch adds support to the JESD216 rev B standard and parses the
SFDP tables to dynamically initialize the 'struct spi_nor_flash_parameter'.

It has been ported from Linux commit "mtd: spi-nor: parse Serial Flash
Discoverable Parameters (SFDP) tables". It Also ports all modifications
done on top of the mentioned commit.

This feature is enabled by defining FLASH_SFDP in spi_flash_info's flag field. 

Signed-off-by: Prabhakar Kushwaha 
CC: Cyrille Pitchen 
CC: Marek Vasut 
---
 drivers/mtd/spi/sf_internal.h | 204 +
 drivers/mtd/spi/spi_flash.c   | 416 +-
 2 files changed, 619 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 164b0ea..73fe207 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 
 /* Dual SPI flash memories - see SPI_COMM_DUAL_... */
 enum spi_dual_flash {
@@ -82,6 +83,7 @@ enum spi_nor_option_flags {
 #define CMD_FLAG_STATUS0x70
 #define CMD_EN4B   0xB7
 #define CMD_EX4B   0xE9
+#define CMD_READ_SFDP  0x5a
 
 /* Bank addr access commands */
 #ifdef CONFIG_SPI_FLASH_BAR
@@ -155,9 +157,211 @@ struct spi_flash_info {
 * Use dedicated 4byte address op codes
 * to support memory size above 128Mib.
 */
+#define FLASH_SFDP BIT(9)   /* Parse SFDP tables */
 #define RD_FULL(RD_QUAD | RD_DUAL | RD_QUADIO | 
RD_DUALIO)
 };
 
+struct sfdp_parameter_header {
+   u8  id_lsb;
+   u8  minor;
+   u8  major;
+   u8  length; /* in double words */
+   u8  parameter_table_pointer[3]; /* byte address */
+   u8  id_msb;
+};
+
+#define SFDP_PARAM_HEADER_ID(p)(((p)->id_msb << 8) | (p)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(p) \
+   (((p)->parameter_table_pointer[2] << 16) | \
+((p)->parameter_table_pointer[1] <<  8) | \
+((p)->parameter_table_pointer[0] <<  0))
+
+#define SFDP_BFPT_ID   0xff00  /* Basic Flash Parameter Table */
+#define SFDP_SECTOR_MAP_ID 0xff81  /* Sector Map Table */
+
+#define SFDP_SIGNATURE 0x50444653U
+#define SFDP_JESD216_MAJOR 1
+#define SFDP_JESD216_MINOR 0
+#define SFDP_JESD216A_MINOR5
+#define SFDP_JESD216B_MINOR6
+
+struct sfdp_header {
+   u32 signature; /* Ox50444653U <=> "SFDP" */
+   u8  minor;
+   u8  major;
+   u8  nph; /* 0-base number of parameter headers */
+   u8  unused;
+
+   /* Basic Flash Parameter Table. */
+   struct sfdp_parameter_headerbfpt_header;
+};
+
+/* Basic Flash Parameter Table */
+
+/*
+ * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * They are indexed from 1 but C arrays are indexed from 0.
+ */
+#define BFPT_DWORD(i)  ((i) - 1)
+#define BFPT_DWORD_MAX 16
+
+/* The first version of JESB216 defined only 9 DWORDs. */
+#define BFPT_DWORD_MAX_JESD216 9
+
+/* 1st DWORD. */
+#define BFPT_DWORD1_FAST_READ_1_1_2BIT(16)
+#define BFPT_DWORD1_ADDRESS_BYTES_MASK GENMASK(18, 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY   (0x0UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4   (0x1UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY   (0x2UL << 17)
+#define BFPT_DWORD1_DTRBIT(19)
+#define BFPT_DWORD1_FAST_READ_1_2_2BIT(20)
+#define BFPT_DWORD1_FAST_READ_1_4_4BIT(21)
+#define BFPT_DWORD1_FAST_READ_1_1_4BIT(22)
+
+/* 5th DWORD. */
+#define BFPT_DWORD5_FAST_READ_2_2_2BIT(0)
+#define BFPT_DWORD5_FAST_READ_4_4_4BIT(4)
+
+/* 11th DWORD. */
+#define BFPT_DWORD11_PAGE_SIZE_SHIFT   4
+#define BFPT_DWORD11_PAGE_SIZE_MASKGENMASK(7, 4)
+
+/* 15th DWORD. */
+
+/*
+ * (from JESD216 rev B)
+ * Quad Enable Requirements (QER):
+ * - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4
+ * reads based on instruction. DQ3/HOLD# functions are hold during
+ * instruction phase.
+ * - 001b: QE is bit 1 of status register 2. It is set via Write Status with
+ * two data bytes where bit 1 of the second byte is one.
+ * [...]
+ * Writing only one byte to the status register has the side-effect of
+ * clearing status register 2, including the QE bit. The 100b code is
+ * used if writing one byte to the status register does not modify
+ * status register 2.
+ * - 010b: QE is bit 6 of status register 1. It is set via Write Status with
+ * one data byte where bit 

[U-Boot] [PATCH 2/3] sf: add method to support memory size above 128Mib

[Prabhakar Kushwaha]

This patch add support of memories with size above 128Mib. It has
been ported from Linux commit "mtd: spi-nor: add a
stateless method to support memory size above 128Mib".

It convert 3byte opcode into 4byte opcode based upon
OPCODES_4B or Spansion flash. Also the commands are malloc'ed
at run time based on 3byte or 4byte address opcode requirement.

Signed-off-by: Prabhakar Kushwaha 
CC: Cyrille Pitchen 
CC: Marek Vasut 
CC: Vignesh R 
---
depends upon https://patchwork.ozlabs.org/patch/826919/

 drivers/mtd/spi/sf_internal.h |  28 -
 drivers/mtd/spi/spi_flash.c   | 136 --
 include/spi_flash.h   |   2 +
 3 files changed, 146 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 06dee0a..164b0ea 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -27,7 +27,8 @@ enum spi_nor_option_flags {
 };
 
 #define SPI_FLASH_3B_ADDR_LEN  3
-#define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN  4
+#define SPI_FLASH_MAX_ADDR_WIDTH   4
 #define SPI_FLASH_16MB_BOUN0x100
 
 /* CFI Manufacture ID's */
@@ -57,13 +58,30 @@ enum spi_nor_option_flags {
 #define CMD_READ_DUAL_IO_FAST  0xbb
 #define CMD_READ_QUAD_OUTPUT_FAST  0x6b
 #define CMD_READ_QUAD_IO_FAST  0xeb
+
+/* 4B READ commands */
+#define CMD_READ_ARRAY_SLOW_4B 0x13
+#define CMD_READ_ARRAY_FAST_4B 0x0c
+#define CMD_READ_DUAL_OUTPUT_FAST_4B   0x3c
+#define CMD_READ_DUAL_IO_FAST_4B   0xbc
+#define CMD_READ_QUAD_OUTPUT_FAST_4B   0x6c
+#define CMD_READ_QUAD_IO_FAST_4B   0xec
+
+/* 4B Write commands */
+#define CMD_PAGE_PROGRAM_4B0x12
+
+/* 4B Erase commands */
+#define CMD_ERASE_4K_4B0x21
+#define CMD_ERASE_CHIP_4B  0x5c
+#define CMD_ERASE_64K_4B   0xdc
+
 #define CMD_READ_ID0x9f
 #define CMD_READ_STATUS0x05
 #define CMD_READ_STATUS1   0x35
 #define CMD_READ_CONFIG0x35
 #define CMD_FLAG_STATUS0x70
-#define CMD_EN4B   0xB7
-#define CMD_EX4B   0xE9
+#define CMD_EN4B   0xB7
+#define CMD_EX4B   0xE9
 
 /* Bank addr access commands */
 #ifdef CONFIG_SPI_FLASH_BAR
@@ -133,6 +151,10 @@ struct spi_flash_info {
 #define RD_DUALBIT(5)  /* use Dual Read */
 #define RD_QUADIO  BIT(6)  /* use Quad IO Read */
 #define RD_DUALIO  BIT(7)  /* use Dual IO Read */
+#define OPCODES_4B BIT(8)  /*
+* Use dedicated 4byte address op codes
+* to support memory size above 128Mib.
+*/
 #define RD_FULL(RD_QUAD | RD_DUAL | RD_QUADIO | 
RD_DUALIO)
 };
 
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 7581622..4d2e58e 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -22,12 +22,28 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
 {
/* cmd[0] is actual command */
-   cmd[1] = addr >> 16;
-   cmd[2] = addr >> 8;
-   cmd[3] = addr >> 0;
+
+   switch (flash->addr_width) {
+   case SPI_FLASH_3B_ADDR_LEN:
+   cmd[1] = addr >> 16;
+   cmd[2] = addr >> 8;
+   cmd[3] = addr >> 0;
+   break;
+
+   case SPI_FLASH_4B_ADDR_LEN:
+   cmd[1] = addr >> 24;
+   cmd[2] = addr >> 16;
+   cmd[3] = addr >> 8;
+   cmd[4] = addr >> 0;
+   break;
+
+   default:
+   debug("SF: Wrong opcode size\n");
+   break;
+   }
 }
 
 static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -74,6 +90,64 @@ static int write_sr(struct spi_flash *flash, u8 ws)
return 0;
 }
 
+static u8 spi_flash_convert_opcode(u8 opcode, const u8 table[][2], size_t size)
+{
+   size_t i;
+
+   for (i = 0; i < size; i++)
+   if (table[i][0] == opcode)
+   return table[i][1];
+
+   /* No conversion found, keep input op code. */
+   return opcode;
+}
+
+static inline u8 spi_flash_convert_3to4_read(u8 opcode)
+{
+   static const u8 spi_flash_3to4_read[][2] = {
+   { CMD_READ_ARRAY_SLOW,  CMD_READ_ARRAY_SLOW_4B },
+   { CMD_READ_ARRAY_FAST,  CMD_READ_ARRAY_FAST_4B },
+   { CMD_READ_DUAL_OUTPUT_FAST,CMD_READ_DUAL_OUTPUT_FAST_4B },
+   { CMD_READ_DUAL_IO_FAST,CMD_READ_DUAL_IO_FAST_4B },
+   

[U-Boot] [PATCH 1/3] sf: Add support of 1-2-2, 1-4-4 IO READ protocols

[Prabhakar Kushwaha]

IO READ protocols transfers both address and data on multiple
data bits. 1-2-2(DUAL IO), 1-4-4(QUAD IO) transfer address on 2
data bits or 4 bits per rising edge of SCK respectively.

This patch update spi_nor_flash_parameter->spi_nor_read_command
array based on DUAL or QUAD IO flag enabled in flash_info for a flash.

Signed-off-by: Prabhakar Kushwaha 
---
 drivers/mtd/spi/spi_flash.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 51e28bf..4ff8d8b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1071,8 +1071,12 @@ int spi_flash_scan(struct spi_flash *flash)
flash->read_cmd = CMD_READ_ARRAY_FAST;
if (spi->mode & SPI_RX_SLOW)
flash->read_cmd = CMD_READ_ARRAY_SLOW;
+   else if (spi->mode & SPI_RX_QUAD && info->flags & RD_QUADIO)
+   flash->read_cmd = CMD_READ_QUAD_IO_FAST;
else if (spi->mode & SPI_RX_QUAD && info->flags & RD_QUAD)
flash->read_cmd = CMD_READ_QUAD_OUTPUT_FAST;
+   else if (spi->mode & SPI_RX_DUAL && info->flags & RD_DUALIO)
+   flash->read_cmd = CMD_READ_DUAL_IO_FAST;
else if (spi->mode & SPI_RX_DUAL && info->flags & RD_DUAL)
flash->read_cmd = CMD_READ_DUAL_OUTPUT_FAST;
 
-- 
2.7.4

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

[U-Boot] [PATCH 0/3] sf: Update spi-nor framework

[Prabhakar Kushwaha]

SPI-NOR framework currently supports-
 - (1-1-1, 1-1-2, 1-1-4) read protocols
 - read latency(dummy bytes) are hardcoded with the assumption
 that the flash would support it.
 - No support of mode bits.
 - No support of flash size above 128Mib

This patch set add support of 1-2-2, 1-4-4 read protocols. 
It ports Linux commits "mtd: spi-nor: add a stateless method to support
memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
and run time flash parameters discovery including dummy cycle and mode
cycle.

Prabhakar Kushwaha (3):
  sf: Add support of 1-2-2, 1-4-4 IO READ protocols
  sf: add method to support memory size above 128Mib
  sf: parse Serial Flash Discoverable Parameters (SFDP) tables

 drivers/mtd/spi/sf_internal.h | 230 +++-
 drivers/mtd/spi/spi_flash.c   | 599 +-
 include/spi_flash.h   |   2 +
 3 files changed, 817 insertions(+), 14 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Ran Wang]

From: Marek Vasut [mailto:ma...@denx.de]
Sent: Wednesday, December 20, 2017 6:05 PM
> On 12/20/2017 10:54 AM, Ran Wang wrote:
> > Hi Marek,
> >
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Wednesday, December 20, 2017 5:02 PM
> >> To: Ran Wang ; Albert Aribaud
> >> ; Prabhakar Kushwaha
> >> ; Alison Wang
> >> ; Sumit Garg ; York
> >> Sun ; Bin Meng 
> >> Cc: Stefan Roese ; Nobuhiro Iwamatsu
> >> ; Philipp Tomsich  >> systems.com>; Konstantin Porotchkin ; Uri
> >> Mashiach ; Simon Glass
> >> ; Xiaobo Xie ; Jiafei Pan
> >> ; u- b...@lists.denx.de
> >> Subject: Re: [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0
> >> controller phy type for ls1012aqds board
> 
> ^ drop this nonsense please
> 
> >> On 12/20/2017 03:34 AM, Ran Wang wrote:
> >>> Without this propertiy, U-Boot will pop warning of 'USB phy type not
> >>> defined' when select CONFIG_HAS_FSL_DR_USB.
> >>
> >> I take it the "propertiy" is the phy_type one , right ?
> >>
> >
> > Yes, it's phy_type.
> 
> You should be more precise in the commit message. Also, cull the CC list next
> time.

Got it. Thanks for advice.
--
Best regards,
Ran
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Philipp Tomsich]

The 't208xrdb t4qds t102*' job is close to the time limit and
sometimes fails, so this splits it into 3 separate jobs.

Signed-off-by: Philipp Tomsich 
---

 .travis.yml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 0b7a062..8a220cc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -206,7 +206,11 @@ matrix:
 - env:
 - BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x p1_p2_rdb_pc -x 
p1010rdb -x corenet_ds -x b4860qds -x sbc8548 -x bsc91*"
 - env:
-- BUILDMAN="t208xrdb t4qds t102*"
+- BUILDMAN="t208xrdb"
+- env:
+- BUILDMAN="t4qds"
+- env:
+- BUILDMAN="t102*"
 - env:
 - BUILDMAN="p1_p2_rdb_pc"
 - env:
-- 
2.1.4

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

Re: [U-Boot] [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Marek Vasut]

On 12/20/2017 10:54 AM, Ran Wang wrote:
> Hi Marek,
> 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Wednesday, December 20, 2017 5:02 PM
>> To: Ran Wang ; Albert Aribaud
>> ; Prabhakar Kushwaha
>> ; Alison Wang
>> ; Sumit Garg ; York Sun
>> ; Bin Meng 
>> Cc: Stefan Roese ; Nobuhiro Iwamatsu
>> ; Philipp Tomsich > systems.com>; Konstantin Porotchkin ; Uri Mashiach
>> ; Simon Glass ; Xiaobo
>> Xie ; Jiafei Pan ; u-
>> b...@lists.denx.de
>> Subject: Re: [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller
>> phy type for ls1012aqds board

^ drop this nonsense please

>> On 12/20/2017 03:34 AM, Ran Wang wrote:
>>> Without this propertiy, U-Boot will pop warning of 'USB phy type not
>>> defined' when select CONFIG_HAS_FSL_DR_USB.
>>
>> I take it the "propertiy" is the phy_type one , right ?
>>
> 
> Yes, it's phy_type.

You should be more precise in the commit message. Also, cull the CC list
next time.

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

Re: [U-Boot] [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Ran Wang]

Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Wednesday, December 20, 2017 5:02 PM
> To: Ran Wang ; Albert Aribaud
> ; Prabhakar Kushwaha
> ; Alison Wang
> ; Sumit Garg ; York Sun
> ; Bin Meng 
> Cc: Stefan Roese ; Nobuhiro Iwamatsu
> ; Philipp Tomsich  systems.com>; Konstantin Porotchkin ; Uri Mashiach
> ; Simon Glass ; Xiaobo
> Xie ; Jiafei Pan ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller
> phy type for ls1012aqds board
> 
> On 12/20/2017 03:34 AM, Ran Wang wrote:
> > Without this propertiy, U-Boot will pop warning of 'USB phy type not
> > defined' when select CONFIG_HAS_FSL_DR_USB.
> 
> I take it the "propertiy" is the phy_type one , right ?
> 

Yes, it's phy_type.

> Anyway, applied all 3 .
>

Thank you.
 
> > Signed-off-by: Ran Wang 
> > ---
> > Change in v2:
> > None
> >
> >  arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi
> > b/arch/arm/dts/fsl-ls1012a-qds.dtsi
> > index dde7134..d17cd99 100644
> > --- a/arch/arm/dts/fsl-ls1012a-qds.dtsi
> > +++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
> > @@ -121,3 +121,8 @@
> >   {
> > status = "okay";
> >  };
> > +
> > + {
> > +   status = "okay";
> > +   phy_type = "ulpi";
> > +};
> >
> 
> 
Best Regards,
Ran
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Socfpga: configure FPGA to SDRAM interface without reprogramming the FPGA

[Marek Vasut]

On 12/20/2017 12:29 AM, Jan Siegmund wrote:
> Am 18.12.2017 um 22:05 schrieb Marek Vasut:
>> On 12/18/2017 09:44 PM, Jan Siegmund wrote:
> 
> Hi Marek,

Hi,

>>> Hi all,
>>
>> Hi,
>>
>>> Here is another question on the FPGA to SDRAM interface of the Cyclone V 
>>> SoC.
>>> Is is possible to configure the the interface in U-Boot or SPL,
>>
>> What is "the interface" ?
> 
> I am sorry I did not specify it further. I meant the FPGA-to-HPS SDRAM 
> interface
> [2], sometimes called FPGA2SDRAM bridge.

Oh OK. The F2S bridge is a bit special indeed.

>> If you mean DRAM, then yes, the CV/AV do _not_ configure the FPGA in SPL
>> at all. They just configure the IOMUX/clock rings, but that's all.
>>
> 
> I know the FPGA is not configured in SPL, but does the FPGA need to be
> configured in SPL or U-Boot, to use the FPGA-to-HPS SDRAM interface?

No

> Would it be
> possible to just preset the registers for later configuration?

Yes

> My preferred usecase would be configuring the registers in the table below in
> SPL and configuring the FPGA in Linux, with a design using the FPGA-to-HPS 
> SDRAM
> interface.
> 
> For example, the last bits in the portcfg register define whether the
> FPGA-to-HPS SDRAM interface's protocol is AXI or Avalon MM. The problem is, 
> that
> this register can't be written to in U-Boot, even though it is specified as rw
> [3]. Can this register just be set by programming the FPGA?

You might need to regenerate the SPL if you changed those kinds of
settings. The SPL programs these based on the handoff files IIRC.

>>> without reprogramming the FPGA? Maybe through the usage of the generated
>>> header files from the Quartus synthesis?
>>> The SDRAM controller's registers only differ in eight entries in Linux when 
>>> the
>>> FPGA is programmed or not.
>>>
>>> +--+-+++
>>> | address  |name | programmed | not programmed |
>>> +--+-+++
>>> | FFC25064 | | 00044003   | 00044FFF   |
>>> | FFC25068 | | 2C00   | 2C03   |
>>> | FFC2506c | | 00B0   | 00B3   |
>>> | FFC25070 | | 0076   | 0076   |
>>> | FFC25074 | | 0098   | 0098   |
>>> | FFC25078 | | 0005A003   | 0005AFFF   |
>>> | FFC2507c | portcfg |    | 003F   |
>>> | FFC25080 | fpgaportrst | 01FF   |    |
>>> +--+-+++
>>>
>>> The registers 0xFFC25064-0xFFC25078 don't show up on the HPS' memory map
>>> [1], so are they even intended to be configured?
>>>
>>> Thanks
>>>
>>>
>>>
>>> [1]
>>> https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577380716.html#sfo1411577380716
>>>
>>
>>
> 
> Best regards,
> Jan
> 
> [2]
> https://www.altera.com/documentation/sfo1410143707420.html#sfo1411577336440__section_N10012_N1000F_N10001
> 
> 
> [3] https://www.altera.com/hps/cyclone-v/hps.html#topic/sfo1411577375739.html
> 


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

Re: [U-Boot] ARM64 Allwinner Binary Size

[Mark Kettenis]

> From: Andre Przywara 
> Date: Tue, 19 Dec 2017 14:17:37 +
> 
> Hi,
> 
> On 19/12/17 13:51, Mark Kettenis wrote:
> >> From: Andre Przywara 
> >> Date: Tue, 19 Dec 2017 13:38:59 +
> >>
> >> Hi Maxime,
> >>
> >> thanks for having a look!
> >>
> >> On 19/12/17 13:12, Maxime Ripard wrote:
> >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
>  So even though the actual u-boot.bin for 64-bit boards is still somewhat
>  below the limit (~480KB), adding the ATF image (~32KB) pushes it over
>  the edge. So since v2017.11 u-boot.itb is already too big for the
>  traditional MMC env location.
> >>>
> >>> So I've had a quick look about what could go possibly go away in our
> >>> current armv8 config (using the pine64+ defconfig). Let me know if
> >>> some are actually vitals:
> >>>
> >>>  - FIT_ENABLE_SHA256_SUPPORT
> >>>  - CONSOLE_MUX
> >>>  - CMD_CRC32
> >>>  - CMD_LZMADEC
> >>>  - CMD_UNZIP
> >>>  - CMD_LOADB
> >>>  - CMD_LOADS
> >>>  - CMD_MISC (actually implementing the command sleep)
> >>>  - ISO_PARTITION (yes. For CDROMs.)
> >>
> >> As Alex mentioned, this is needed for some installer images, which come
> >> as ISOs. So if possible, we should keep this in.
> >>
> >>>  - VIDEO_BPP8, VIDEO_BPP16
> >>>  - VIDEO_ANSI
> >>>  - SHA256
> >>>  - LZMA
> >>
> >> From just looking at the names I am fine with the rest gone. But let me
> >> test tonight if there are any side effects.
> >>
> >> Some of them seem useful, but I would leave enabling them to the actual
> >> users. If someone needs it, they can enable them and loose the raw MMC
> >> environment. I think this is a fair trade-off.
> >>
> >>> Removing those options make the u-boot.itb binary size going from
> >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> >>> the DT overlays that seem way more important than any feature
> >>> mentionned above (and bumps the size to 483kB).
> >>
> >> How important is the raw MMC environment for the ARM64 boards, actually?
> >> Most of the rationale for the 32-bit side seemed to apply to legacy use
> >> cases only. Do we have reports/complaints from 64-bit users?
> > 
> > For me/us (OpenBSD) the environment is still important.  I have many
> > setups where U-Boot lives on a uSD card but the installed OS lives on
> > a USB device.  In that scenario I set boot_targets to boot the EFI
> > bootloader and OS off the USB disk.  This is very helpfull for testing
> > new versions of U-Boot as I can simply swap the uSD card.  But for
> > some setups this is essential as OpenBSD doesn't support the SD/MCC
> > controller on all ARM hardware yet (but we do support it on
> > Allwinner).
> 
> I see, but I wasn't arguing for dropping the environment altogether,
> more for supporting FAT environments *only*.
> So how important is preserving existing environments over a firmware
> update in your scenario? I think this is the killer question here, isn't
> it? I'm inclined to just drop raw MMC environment support from sunxi64
> boards and then enjoy the ~450KB more worth of code, until we hit the
> first MB boundary.

I wouldn't consider preserving the environment as crucial.

> I have builds with all (DDR3) A64 board DTs in the binary [1], which
> would be larger than 504K anyway.

Oh, that's some cool work on the ATF side.  Need to check that out.

> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/pine64/commit/ee12bea43
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Wed, Dec 20, 2017 at 08:42:22AM +0100, Mark Kettenis wrote:
> > Date: Wed, 20 Dec 2017 08:15:46 +0100
> > From: Maxime Ripard 
> > 
> > On Wed, Dec 20, 2017 at 01:55:51AM +, Andr=E9 Przywara wrote:
> > > On 19/12/17 15:24, Maxime Ripard wrote:
> > > > On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote:
> > > >>> Date: Tue, 19 Dec 2017 14:12:02 +0100
> > > >>> From: Maxime Ripard 
> > > >>>
> > > >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote:
> > >  So even though the actual u-boot.bin for 64-bit boards is still some=
> > what
> > >  below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> > >  the edge. So since v2017.11 u-boot.itb is already too big for the
> > >  traditional MMC env location.
> > > >>>
> > > >>> So I've had a quick look about what could go possibly go away in our
> > > >>> current armv8 config (using the pine64+ defconfig). Let me know if
> > > >>> some are actually vitals:
> > > >>>
> > > >>>  - FIT_ENABLE_SHA256_SUPPORT
> > > >>>  - CONSOLE_MUX
> > > >>>  - CMD_CRC32
> > > >>>  - CMD_LZMADEC
> > > >>>  - CMD_UNZIP
> > > >>>  - CMD_LOADB
> > > >>>  - CMD_LOADS
> > > >>>  - CMD_MISC (actually implementing the command sleep)
> > > >>>  - ISO_PARTITION (yes. For CDROMs.)
> > > >>>  - VIDEO_BPP8, VIDEO_BPP16
> > > >>>  - VIDEO_ANSI
> > > >>>  - SHA256
> > > >>>  - LZMA
> > > >>>
> > > >>> Removing those options make the u-boot.itb binary size going from
> > > >>> 516kB to 478kB, making it functional again *and* allowing us to enable
> > > >>> the DT overlays that seem way more important than any feature
> > > >>> mentionned above (and bumps the size to 483kB).
> > > >>
> > > >> So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial
> > > >> console and usb keyboard are present?  Is the usb keyboard used when
> > > >> it is plugged in but serial otherwise?
> > > >=20
> > > > That's actually a very good question, and I don't know, I never used a
> > > > USB keyboard with U-Boot.
> > > >=20
> > > > This is enabled on 7 Allwinner boards, and no one complained so far,
> > > > so I would expect to work without that option activated. However, it
> > > > doesn't take that much space either, so it's not like we really need
> > > > to disable it either.
> > >=20
> > > Just tested it: without CONSOLE_MUX we don't use video and USB keyboard
> > > automatically. It seems to default to serial, "setenv stdout vidconsole"
> > > switches over (immediately). This is quite weird behaviour, and probably
> > > quite unpleasant for the casual user.
> > > With CONSOLE_MUX defined we get what we want: always serial console,
> > > plus USB keyboard and HDMI, if connected. Output appears on both, input
> > > is accepted from both.
> > > So I would very much like to keep it in.
> > 
> > Sounds like we should even enable it for everyone then.
> 
> common/Kconfig has:
> 
> config CONSOLE_MUX
> bool "Enable console multiplexing"
> default y if DM_VIDEO || VIDEO || LCD
> 
> so it is already enabled in the cases where it matters.

Ok, then the next question is why a few of our boards are actually
setting it in their defconfig instead of just using that default :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH RESEND v2 1/3] armv8: ls1012a: Add USB 2.0 controller phy type for ls1012aqds board

[Marek Vasut]

On 12/20/2017 03:34 AM, Ran Wang wrote:
> Without this propertiy, U-Boot will pop warning of 'USB phy type not
> defined' when select CONFIG_HAS_FSL_DR_USB.

I take it the "propertiy" is the phy_type one , right ?

Anyway, applied all 3 .

> Signed-off-by: Ran Wang 
> ---
> Change in v2:
>   None
> 
>  arch/arm/dts/fsl-ls1012a-qds.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
> b/arch/arm/dts/fsl-ls1012a-qds.dtsi
> index dde7134..d17cd99 100644
> --- a/arch/arm/dts/fsl-ls1012a-qds.dtsi
> +++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
> @@ -121,3 +121,8 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> + phy_type = "ulpi";
> +};
> 


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

Re: [U-Boot] [PATCH v3] drivers: core: Add translation in live tree case

[Mario Six]

On Tue, Dec 19, 2017 at 12:03 AM, Stephen Warren  wrote:
> On 12/18/2017 03:33 PM, Stephen Warren wrote:
>>
>> On 12/18/2017 03:29 PM, Stephen Warren wrote:
>>>
>>> On 12/18/2017 01:34 AM, Mario Six wrote:

 The function dev_read_addr calls ofnode_get_addr_index in the live tree
 case, which does not apply bus translations to the address read from the
 device tree. This results in illegal addresses on boards that rely on
 bus translations being applied.

 Fix this situation by applying bus translations in the live tree case as
 well.
>>>
>>>
>>> Tested-by: Stephen Warren 
>>
>>
>> Uggh. Sorry, I take that back. This seems to break NVIDIA Jetson TX1
>> (p2371-2180 board), even though it did solve this issue that was present on
>> other boards in the previous patch version. I'll try and see what's up
>> (something to do with I2C accesses early during boot)...
>
>
> I guess this is something to do with:
>
>> +   if (IS_ENABLED(CONFIG_OF_TRANSLATE)) {
>> +   u64 paddr =
>> of_translate_address(ofnode_to_np(node), );
>> +
>> +   return be32_to_cpu((fdt_addr_t)paddr);
>
>
> My tests passed on a 32-bit platform but failed on a 64-bit platform. I
> expect you need be64_to_cpu() there on 64-bit platforms? Actually, it should
> really base the bit-width on #address-cells, but we only support 32- or
> 64-bit at the moment so switching between the two is probably fine.
>

Just sent a v4, which will hopefully fix this for all platforms. I tested with
32-bit and 64-bit sandbox, and I now get the same result with and without
translation for both.

@Simon: I also sent a RFC patch for a sandbox with 64-bit addresses, since it
might be useful for testing.

Best regards,

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

[U-Boot] [PATCH v4] drivers: core: Add translation in live tree case

[Mario Six]

The function dev_read_addr calls ofnode_get_addr_index in the live tree
case, which does not apply bus translations to the address read from the
device tree. This results in illegal addresses on boards that rely on
bus translations being applied.

Fix this situation by applying bus translations in the live tree case as
well.

Signed-off-by: Mario Six 

---
v3 -> v4:
* Fixed issue on 64-bit platforms

v2 -> v3:
* Fixed endianness issue on little-endian platforms

v1 -> v2:
* Added IS_ENABLED(CONFIG_OF_TRANSLATE) case distinction
---
 drivers/core/ofnode.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 0030ab962e..2dbf3a7cd7 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -205,8 +205,13 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
  );
if (!prop_val)
return FDT_ADDR_T_NONE;
-   na = of_n_addr_cells(ofnode_to_np(node));
-   return of_read_number(prop_val, na);
+
+   if (IS_ENABLED(CONFIG_OF_TRANSLATE)) {
+   return of_translate_address(ofnode_to_np(node), 
prop_val);
+   } else {
+   na = of_n_addr_cells(ofnode_to_np(node));
+   return of_read_number(prop_val, na);
+   }
} else {
return fdt_get_base_address(gd->fdt_blob,
ofnode_to_offset(node));
--
2.13.6

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