Re: [U-Boot] ARM - cache and alignment

[Tom Rini]

On Mon, Jan 16, 2017 at 02:29:21PM +0100, Jean-Jacques Hiblot wrote:

> Tom, Marek
> 
> At the moment, whenever an unaligned address is used in cache
> operations (invalidate_dcache_range, or flush_dcache_range), the
> whole request is discarded  for am926ejs. for armV7 or armV8 only
> the aligned part is maintained. This is probably what is causing the
> bug addressed in 8133f43d1cd. There are a lot of unaligned buffers
> used in DMA operations and for all of them, we're possibly handling
> the cached partially or not at all. I've seen this when using the
> environment from a file stored in a FAT partition. commit
> 8133f43d1cd addresses this by using a bounce buffer at the FAT level
> but it's only one of many cases.
> 
> I think we can do better with unaligned cache operations:

My current feeling here is that the main problems here, with respect to
buffers not being aligned, is that as we move forward with DM changes we
can push this up a level and it will be harder to get this wrong.
Patches to fix problems found in the mean time are welcome.

-- 
Tom


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

[U-Boot] [PATCH] armv8/fsl-layerscape: fdt: remove SYSCLK frequency fixup for ls1012a

[Yangbo Lu]

Generally SYSCLK frequency is dependent on on-board switch settings.
It may vary as per requirement, but this doesn't apply to ls1012a.
ls1012a has its SYSCLK frequencies specified in the RM. The fixup
for all 'fixed-clock' compatibles of ls1012a would cause incorrect
SYSCLK frequency values. So remove the SYSCLK frequency fixup for ls1012a.

Fixes: 6f14e25 ("armv8: fsl-lsch3: fixup SYSCLK frequency in device tree")
Signed-off-by: Yangbo Lu 
---
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index c10ccf9..e59c232 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -161,8 +161,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
   "clock-frequency", CONFIG_SYS_NS16550_CLK, 1);
 #endif
 
+#ifndef CONFIG_ARCH_LS1012A
do_fixup_by_compat_u32(blob, "fixed-clock",
   "clock-frequency", CONFIG_SYS_CLK_FREQ, 1);
+#endif
 
 #ifdef CONFIG_PCI
ft_pci_setup(blob, bd);
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/9] mmc: Add Marvell Xenon SDHCI controller driver

[Stefan Roese]

Hi Masahiro,

On 20.01.2017 00:16, Masahiro Yamada wrote:

2017-01-19 16:39 GMT+09:00 Stefan Roese :

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 9ed8da39ef..87cc9439f3 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -287,6 +287,17 @@ config MMC_SDHCI_SPEAR

  If unsure, say N.

+config MMC_XENON_SDHCI
+   bool "SDHCI support for the Xenon SDHCI controller"
+   depends on MMC_SDHCI && DM_MMC && OF_CONTROL
+   help
+ Support for Xenon SDHCI host controller on Marvell Armada 3700
+ 7k/8k ARM SoCs platforms
+
+ If you have a controller with this interface, say Y here.
+
+ If unsure, say N.
+
 config MMC_SDHCI_TEGRA
bool "SDHCI platform support for the Tegra SD/MMC Controller"
depends on TEGRA



Can you rename the CONFIG symbol to MMC_SDHCI_XENON, please?


Sure.


The renaming is underway, but I want to make this consistent
in the MMC subsystem in the end.


Thanks for working on this. I'll queue this change in v2 and will send
it in a few days.

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

Re: [U-Boot] [PATCH] armv8: fsl-lsch3: enable snoopable sata read and write

[york sun]

On 12/01/2016 01:20 AM, yuantian.t...@nxp.com wrote:
> From: Tang Yuantian 
>
> By default the SATA IP on the ls208Xa SoCs does not generating
> coherent/snoopable transactions.  This patch enable it in the
> sata axicc register.
>
> Signed-off-by: Tang Yuantian 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

[U-Boot] [RFC PATCH 04/11] SPL: FIT: allow loading multiple images

[Andre Przywara]

So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
  ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index d4149c5..18269f7 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -190,6 +190,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_image_info image_info;
int node, images;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
+   int index = 0;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -234,6 +235,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (node < 0) {
debug("could not find firmware image, trying loadables...\n");
node = spl_fit_get_image_node(fit, images, "loadables", 0);
+   /*
+* If we pick the U-Boot image from "loadables", start at
+* the second image when later loading additional images.
+*/
+   index = 1;
}
if (node < 0) {
debug("%s: Cannot find u-boot image node: %d\n",
@@ -259,5 +265,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
image_info.load_addr = spl_image->load_addr + spl_image->size;
spl_load_fit_image(info, sector, fit, base_offset, node, _info);
 
+   /* Now check if there are more images for us to load */
+   for (; ; index++) {
+   node = spl_fit_get_image_node(fit, images, "loadables", index);
+   if (node < 0)
+   break;
+
+   spl_load_fit_image(info, sector, fit, base_offset, node,
+  _info);
+
+   /*
+* If the "firmware" image did not provide an entry point,
+* use the first valid entry point from the loadables.
+*/
+   if (spl_image->entry_point == -1U &&
+   image_info.entry_point != -1U)
+   spl_image->entry_point = image_info.entry_point;
+   }
+
+   if (spl_image->entry_point == -1U || spl_image->entry_point == 0)
+   spl_image->entry_point = spl_image->load_addr;
+
return 0;
 }
-- 
2.8.2

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

[U-Boot] [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)

[Andre Przywara]

Currently the FIT format is not used to its full potential in the SPL:
It only loads the first image from the /images node and appends the
proper FDT.
Some boards and platforms would benefit from loading more images before
starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.

This series tries to solve this in a board agnostic and generic way:
We extend the SPL FIT loading scheme to allow loading multiple images.
So apart from loading the image which is referenced by the "firmware"
property in the respective configuration node and placing the DTB right
behind it, we iterate over all strings in the "loadable" property.
Each image referenced there will be loaded to its specified load address.
The entry point U-Boot eventually branches to will be taken from the
first image to explicitly provide the "entry" property, or, if none
of them does so, from the load address of the "firmware" image.
This keeps the scheme compatible with the FIT images our Makefile creates
automatically at the moment.

Apart from the already mentioned ATF scenario this opens up more usage
scenarios, of which the commit message of patch 04/11 lists some.

The first three patches rework the SPL FIT support to be more flexible
and to allow easier usage in the fourth patch, which introduces the
multiple-image loading facility.
The remaining patches enable that support for the Pine64 board to make
its SPL support finally useful and to demonstrate usage of this scheme:
patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64
compilation of the SPL with FIT support enabled. Patch 8 implements the
board selector routine, which selects either the Pine64 or Pine64+ DTB
depending on the detected DRAM size. Patch 9 enables SPL FIT support in
the Pine64 defconfig.
To demonstrate the usage, patch 10 provides a FIT source file, which
loads and executes ATF before the U-Boot proper. Users are expected to
compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb",
then write the resulting file behind the SPL on an SD card (or any other
U-Boot supported boot media, for that matter).
Patch 11 then adds FIT support to the sunxi SPL SPI loading routine,
which allows to load ATF on boards with SPI flash as well.

Questions:
1) Is this scheme the right one (usage of "firmware" and "loadables",
   determination of entry point)? Shall we make use of the "setup"
   property?
2) Shall we extend mkimage to allow supplying "loadable" files on the
   command line, which would allow to build the .itb file automatically?
3) Is providing the .its source file for a (family of) boards the right
   way?
4) Does this break any boards which already use SPL FIT loading?

And for the Pine64 part:
5) Is extending the usable SPL size like in patch 5-7 acceptable?

I have a more generic solution for the .dtb selection in mind: Based on
some patch from Siarhei we store the .dtb filename in the SPL header and
select the .dtb from the FIT image by simply matching the name. This would
allow _one_ build supporting multiple boards. The actual board name would
need to written into the SPL header or could be copied from there when
updating the image.
I can provide the patches once we agreed upon this series.

Please let me know what you think!

Cheers,
Andre.

Andre Przywara (11):
  SPL: FIT: refactor FDT loading
  SPL: FIT: rework U-Boot image loading
  SPL: FIT: factor out spl_load_fit_image()
  SPL: FIT: allow loading multiple images
  tools: mksunxiboot: allow larger SPL binaries
  sunxi: A64: SPL: allow large SPL binary
  sunxi: A64: move SPL stack to end of SRAM A2
  sunxi: SPL: add FIT config selector for Pine64 boards
  sunxi: Pine64: defconfig: enable SPL FIT support
  sunxi: Pine64: add FIT image source
  SPL: SPI: sunxi: add SPL FIT image support

 board/sunxi/board.c |  13 +++
 board/sunxi/pine64_atf.its  |  54 +
 common/spl/spl_fit.c| 241 +++-
 configs/pine64_plus_defconfig   |   5 +
 drivers/mtd/spi/sunxi_spi_spl.c |  39 +--
 include/configs/sunxi-common.h  |   6 +-
 scripts/Makefile.spl|   7 +-
 tools/mksunxiboot.c |  51 ++---
 8 files changed, 290 insertions(+), 126 deletions(-)
 create mode 100644 board/sunxi/pine64_atf.its

-- 
2.8.2

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

[U-Boot] [RFC PATCH 02/11] SPL: FIT: rework U-Boot image loading

[Andre Przywara]

Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.

Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index c4e2f02..381ed1f 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -55,14 +55,13 @@ static int spl_fit_find_config_node(const void *fdt)
return -1;
 }
 
-static int spl_fit_select_index(const void *fit, int images, int *offsetp,
-   const char *type, int index)
+static int spl_fit_get_image_node(const void *fit, int images,
+ const char *type, int index)
 {
const char *name, *img_name;
int node, conf_node;
int len, i;
 
-   *offsetp = 0;
conf_node = spl_fit_find_config_node(fit);
if (conf_node < 0) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -98,10 +97,7 @@ static int spl_fit_select_index(const void *fit, int images, 
int *offsetp,
return -EINVAL;
}
 
-   *offsetp = fdt_getprop_u32(fit, node, "data-offset");
-   len = fdt_getprop_u32(fit, node, "data-size");
-
-   return len;
+   return node;
 }
 
 static int get_aligned_image_offset(struct spl_load_info *info, int offset)
@@ -187,15 +183,22 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (count == 0)
return -EIO;
 
-   /* find the firmware image to load */
+   /* find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
if (images < 0) {
debug("%s: Cannot find /images node: %d\n", __func__, images);
return -1;
}
-   node = fdt_first_subnode(fit, images);
+
+   /* find the U-Boot image */
+   node = spl_fit_get_image_node(fit, images, "firmware", 0);
+   if (node < 0) {
+   debug("could not find firmware image, trying loadables...\n");
+   node = spl_fit_get_image_node(fit, images, "loadables", 0);
+   }
if (node < 0) {
-   debug("%s: Cannot find first image node: %d\n", __func__, node);
+   debug("%s: Cannot find u-boot image node: %d\n",
+ __func__, node);
return -1;
}
 
@@ -237,10 +240,13 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
memcpy(dst, src, data_size);
 
/* Figure out which device tree the board wants to use */
-   fdt_len = spl_fit_select_index(fit, images, _offset,
-  FIT_FDT_PROP, 0);
-   if (fdt_len < 0)
-   return fdt_len;
+   node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
+   if (node < 0) {
+   debug("%s: cannot find FDT node\n", __func__);
+   return node;
+   }
+   fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
+   fdt_len = fdt_getprop_u32(fit, node, "data-size");
 
/*
 * Read the device tree and place it after the image. There may be
-- 
2.8.2

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

[U-Boot] [RFC PATCH 01/11] SPL: FIT: refactor FDT loading

[Andre Przywara]

Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
   configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
   configuration node points to, additionally using a given index into
   a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.

This patch introduces no functional changes, it just refactors the code
to allow reusing it later.

(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 82 
 1 file changed, 51 insertions(+), 31 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..c4e2f02 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -22,13 +22,11 @@ static ulong fdt_getprop_u32(const void *fdt, int node, 
const char *prop)
return fdt32_to_cpu(*cell);
 }
 
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+static int spl_fit_find_config_node(const void *fdt)
 {
-   const char *name, *fdt_name;
-   int conf, node, fdt_node;
-   int len;
+   const char *name;
+   int conf, node, len;
 
-   *fdt_offsetp = 0;
conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
if (conf < 0) {
debug("%s: Cannot find /configurations node: %d\n", __func__,
@@ -50,39 +48,60 @@ static int spl_fit_select_fdt(const void *fdt, int images, 
int *fdt_offsetp)
continue;
 
debug("Selecting config '%s'", name);
-   fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, );
-   if (!fdt_name) {
-   debug("%s: Cannot find fdt name property: %d\n",
- __func__, len);
-   return -EINVAL;
-   }
 
-   debug(", fdt '%s'\n", fdt_name);
-   fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
-   if (fdt_node < 0) {
-   debug("%s: Cannot find fdt node '%s': %d\n",
- __func__, fdt_name, fdt_node);
-   return -EINVAL;
+   return node;
+   }
+
+   return -1;
+}
+
+static int spl_fit_select_index(const void *fit, int images, int *offsetp,
+   const char *type, int index)
+{
+   const char *name, *img_name;
+   int node, conf_node;
+   int len, i;
+
+   *offsetp = 0;
+   conf_node = spl_fit_find_config_node(fit);
+   if (conf_node < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+   printf("No matching DT out of these options:\n");
+   for (node = fdt_first_subnode(fit, conf_node);
+node >= 0;
+node = fdt_next_subnode(fit, node)) {
+   name = fdt_getprop(fit, node, "description", );
+   printf("   %s\n", name);
}
+#endif
+   return -ENOENT;
+   }
 
-   *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
-   len = fdt_getprop_u32(fdt, fdt_node, "data-size");
-   debug("FIT: Selected '%s'\n", name);
+   img_name = fdt_getprop(fit, conf_node, type, );
+   if (!img_name) {
+   debug("cannot find property '%s': %d\n", type, len);
+   return -EINVAL;
+   }
 
-   return len;
+   for (i = 0; i < index; i++) {
+   img_name = strchr(img_name, '\0') + 1;
+   if (*img_name == '\0') {
+   debug("no string for index %d\n", index);
+   return -E2BIG;
+   }
}
 
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-   printf("No matching DT out of these options:\n");
-   for (node = fdt_first_subnode(fdt, conf);
-node >= 0;
-node = fdt_next_subnode(fdt, node)) {
-   name = fdt_getprop(fdt, node, "description", );
-   printf("   %s\n", name);
+   debug("%s: '%s'\n", type, img_name);
+   node = fdt_subnode_offset(fit, images, 

[U-Boot] [RFC PATCH 03/11] SPL: FIT: factor out spl_load_fit_image()

[Andre Przywara]

At the moment we load two images from a FIT image: the actual U-Boot
image and the DTB. Both times we have very similar code to deal with
alignment requirement the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 122 +--
 1 file changed, 51 insertions(+), 71 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 381ed1f..d4149c5 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -138,19 +138,58 @@ static int get_aligned_image_size(struct spl_load_info 
*info, int data_size,
return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
+ void *fit, ulong base_offset, int node,
+ struct spl_image_info *image_info)
+{
+   ulong offset;
+   size_t length;
+   ulong load, entry;
+   void *src;
+   ulong overhead;
+   int nr_sectors;
+
+   offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
+   length = fdt_getprop_u32(fit, node, "data-size");
+   load = fdt_getprop_u32(fit, node, "load");
+   if (load == -1U && image_info)
+   load = image_info->load_addr;
+   entry = fdt_getprop_u32(fit, node, "entry");
+
+   overhead = get_aligned_image_overhead(info, offset);
+   nr_sectors = get_aligned_image_size(info, overhead + length, offset);
+
+   if (info->read(info, sector + get_aligned_image_offset(info, offset),
+  nr_sectors, (void*)load) != nr_sectors)
+   return -EIO;
+   debug("image: dst=%lx, offset=%lx, size=%lx\n", load, offset,
+ (unsigned long)length);
+
+   src = (void *)load + overhead;
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+   board_fit_image_post_process(, );
+#endif
+
+   memcpy((void*)load, src, length);
+
+   if (image_info) {
+   image_info->load_addr = load;
+   image_info->size = length;
+   image_info->entry_point = entry;
+   }
+
+   return 0;
+}
+
 int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector, void *fit)
 {
int sectors;
-   ulong size, load;
+   ulong size;
unsigned long count;
+   struct spl_image_info image_info;
int node, images;
-   void *load_ptr;
-   int fdt_offset, fdt_len;
-   int data_offset, data_size;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
-   int src_sector;
-   void *dst, *src;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -202,82 +241,23 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
return -1;
}
 
-   /* Get its information and set up the spl_image structure */
-   data_offset = fdt_getprop_u32(fit, node, "data-offset");
-   data_size = fdt_getprop_u32(fit, node, "data-size");
-   load = fdt_getprop_u32(fit, node, "load");
-   debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
-   spl_image->load_addr = load;
-   spl_image->entry_point = load;
+   /* Load the image and set up the spl_image structure */
+   spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
spl_image->os = IH_OS_U_BOOT;
 
-   /*
-* Work out where to place the image. We read it so that the first
-* byte will be at 'load'. This may mean we need to load it starting
-* before then, since we can only read whole blocks.
-*/
-   data_offset += base_offset;
-   sectors = get_aligned_image_size(info, data_size, data_offset);
-   load_ptr = (void *)load;
-   debug("U-Boot size %x, data %p\n", data_size, load_ptr);
-   dst = load_ptr;
-
-   /* Read the image */
-   src_sector = sector + get_aligned_image_offset(info, data_offset);
-   debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
- dst, src_sector, sectors);
-   count = info->read(info, src_sector, sectors, dst);
-   if (count != sectors)
-   return -EIO;
-   debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
- data_size);
-   src = dst + get_aligned_image_overhead(info, data_offset);
-
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
-   board_fit_image_post_process((void **), (size_t *)_size);
-#endif
-
-   memcpy(dst, src, data_size);
-
/* Figure out which device tree the board wants to use */
node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
if (node < 0) {
debug("%s: cannot find FDT node\n", __func__);
return node;
}
-   fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
-   

[U-Boot] [RFC PATCH 08/11] sunxi: SPL: add FIT config selector for Pine64 boards

[Andre Przywara]

For a board or platform to support FIT loading in the SPL, it has to
provide a board_fit_config_name_match() routine, which helps to select
one of possibly multiple DTBs contained in a FIT image.
Provide a simple function to cover the two different Pine64 models,
which can be easily told apart by looking at the amount of installed
RAM.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5365638..826 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -726,3 +726,16 @@ int ft_board_setup(void *blob, bd_t *bd)
 #endif
return 0;
 }
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+#ifdef CONFIG_MACH_SUN50I
+   if ((gd->ram_size > 512 * 1024 * 1024))
+   return !strcmp(name, "sun50i-a64-pine64-plus");
+   else
+   return !strcmp(name, "sun50i-a64-pine64");
+#endif
+   return -1;
+}
+#endif
-- 
2.8.2

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

[U-Boot] [RFC PATCH 07/11] sunxi: A64: move SPL stack to end of SRAM A2

[Andre Przywara]

The SPL stack is usually located at the end of SRAM A1, where it grows
towards the end of the SPL.
For the really big AArch64 binaries the stack overwrites code pretty
soon, so move the SPL stack to the end of SRAM A2, which is unused at this
time.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index d58e5ba..28878a5 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -203,10 +203,14 @@
 
 #define CONFIG_SPL_PAD_TO  32768   /* decimal for 'dd' */
 
-#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
+#if defined(CONFIG_MACH_SUN9I)
 /* FIXME: 40 KiB instead of 32 KiB ? */
 #define LOW_LEVEL_SRAM_STACK   0x00018000
 #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
+#elif defined(CONFIG_MACH_SUN50I)
+/* end of SRAM A2 for now, as SRAM A1 is pretty tight */
+#define LOW_LEVEL_SRAM_STACK   0x00054000
+#define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
 #else
 /* end of 32 KiB in sram */
 #define LOW_LEVEL_SRAM_STACK   0x8000 /* End of sram */
-- 
2.8.2

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

[U-Boot] [RFC PATCH 06/11] sunxi: A64: SPL: allow large SPL binary

[Andre Przywara]

Compiling the SPL in AArch64 results in bigger code, which exceeds the
pretty conservative default limits of mksunxiboot.
Use the newly introduced command line parameters to extend the file size
limit to the actual one, which is 32 KB.

Signed-off-by: Andre Przywara 
---
 scripts/Makefile.spl | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index c962bbc..ee87084 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -167,6 +167,11 @@ endif
 
 ifdef CONFIG_ARCH_SUNXI
 ALL-y  += $(obj)/sunxi-spl.bin
+ifdef CONFIG_MACH_SUN50I
+   MKSUNXIBOOT_PARAMS = --mmc --max
+else
+   MKSUNXIBOOT_PARAMS =
+endif
 endif
 
 ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -271,7 +276,7 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
 
 quiet_cmd_mksunxiboot = MKSUNXI $@
-cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
+cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $(MKSUNXIBOOT_PARAMS) $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)
 
-- 
2.8.2

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

[U-Boot] [RFC PATCH 10/11] sunxi: Pine64: add FIT image source

[Andre Przywara]

The Pine64 boards require an ARM Trusted Firmware (ATF) image to be
loaded and executes prior to the actual U-Boot proper.
Add a FIT image source file to describe the binaries, also add the
supported DTs to be able to boot multiple boards with one image. Use:
$ tools/mkimage -f boards/sunxi/pine64_atf.its -E pine64_image.itb
to create the image file. Copy (or symlink) the bl31.bin file from
the ARM Trusted Firmware build into the current directory.

Signed-off-by: Andre Przywara 
---
 board/sunxi/pine64_atf.its | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 board/sunxi/pine64_atf.its

diff --git a/board/sunxi/pine64_atf.its b/board/sunxi/pine64_atf.its
new file mode 100644
index 000..53fce87
--- /dev/null
+++ b/board/sunxi/pine64_atf.its
@@ -0,0 +1,54 @@
+/dts-v1/;
+
+/ {
+   description = "Configuration to load ATF before U-Boot";
+   #address-cells = <1>;
+
+   images {
+   uboot@1 {
+   description = "U-Boot (64-bit)";
+   data = /incbin/("../../u-boot-nodtb.bin");
+   type = "standalone";
+   arch = "arm64";
+   compression = "none";
+   load = <0x4a00>;
+   };
+   atf@1 {
+   description = "ARM Trusted Firmware";
+   data = /incbin/("../../bl31.bin");
+   type = "firmware";
+   arch = "arm64";
+   compression = "none";
+   load = <0x44000>;
+   entry = <0x44000>;
+   };
+   fdt@1 {
+   description = "Pine64+ DT";
+   data = 
/incbin/("../../arch/arm/dts/sun50i-a64-pine64-plus.dtb");
+type = "flat_dt";
+   compression = "none";
+   };
+   fdt@2 {
+   description = "Pine64 DT";
+   data = 
/incbin/("../../arch/arm/dts/sun50i-a64-pine64.dtb");
+type = "flat_dt";
+   compression = "none";
+   };
+   };
+   configurations {
+   default = "config@1";
+
+   config@1 {
+   description = "sun50i-a64-pine64-plus";
+   firmware = "uboot@1";
+   loadables = "atf@1";
+   fdt = "fdt@1";
+   };
+   config@2 {
+   description = "sun50i-a64-pine64";
+   firmware = "uboot@1";
+   loadables = "atf@1";
+   fdt = "fdt@2";
+   };
+   };
+};
-- 
2.8.2

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

[U-Boot] [RFC PATCH 05/11] tools: mksunxiboot: allow larger SPL binaries

[Andre Przywara]

mksunxiboot limits the size of the resulting SPL binaries to pretty
conservative values to cover all SoCs and all boot media (NAND).
In preparation for supporting modern SoCs without NAND, which may
require a really large SPL, introduce comamnd line parameters to
push the possible SPL size to the limits.

Signed-off-by: Andre Przywara 
---
 tools/mksunxiboot.c | 51 ++-
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0f0b003..fa54bce 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,37 +48,58 @@ int gen_check_sum(struct boot_file_head *head_p)
 #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
 #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))
 
-#define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */
-#define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
+#define SUN4I_SRAM_SIZE0x7600  /* 0x7748+ is used by BROM */
+#define SUNXI_MAX_SRAM_SIZE0x8000
+#define SRAM_LOAD_MAX_SIZE (SUNXI_MAX_SRAM_SIZE - sizeof(struct 
boot_file_head))
 
 /*
  * BROM (at least on A10 and A20) requires NAND-images to be explicitly aligned
  * to a multiple of 8K, and rejects the image otherwise. MMC-images are fine
- * with 512B blocks. To cater for both, align to the largest of the two.
+ * with 512B blocks.
  */
-#define BLOCK_SIZE 0x2000
+#define BLOCK_SIZE_NAND 0x2000
+#define BLOCK_SIZE_MMC  0x0200
+#define MAX_BLOCK_SIZE BLOCK_SIZE_NAND
 
 struct boot_img {
struct boot_file_head header;
char code[SRAM_LOAD_MAX_SIZE];
-   char pad[BLOCK_SIZE];
+   char pad[MAX_BLOCK_SIZE];
 };
 
 int main(int argc, char *argv[])
 {
int fd_in, fd_out;
+   int ac = 1;
struct boot_img img;
unsigned file_size;
+   unsigned size_limit = SUN4I_SRAM_SIZE - sizeof(struct boot_file_head);
+   unsigned block_size = BLOCK_SIZE_NAND;
int count;
 
if (argc < 2) {
printf("\tThis program makes an input bin file to sun4i " \
   "bootable image.\n" \
-  "\tUsage: %s input_file out_putfile\n", argv[0]);
+  "\tUsage: %s input_file [out_putfile]\n", argv[0]);
return EXIT_FAILURE;
}
 
-   fd_in = open(argv[1], O_RDONLY);
+   if (!strcmp(argv[ac], "--mmc")) {
+   block_size = BLOCK_SIZE_MMC;
+   ac++;
+   }
+   if (!strcmp(argv[ac], "--nand")) {
+   block_size = BLOCK_SIZE_NAND;
+   ac++;
+   }
+   if (!strcmp(argv[ac], "--max")) {
+   size_limit = SUNXI_MAX_SRAM_SIZE - sizeof(struct 
boot_file_head);
+   ac++;
+   }
+   if (ac >= argc)
+   return EXIT_FAILURE;
+
+   fd_in = open(argv[ac++], O_RDONLY);
if (fd_in < 0) {
perror("Open input file");
return EXIT_FAILURE;
@@ -89,15 +110,19 @@ int main(int argc, char *argv[])
/* get input file size */
file_size = lseek(fd_in, 0, SEEK_END);
 
-   if (file_size > SRAM_LOAD_MAX_SIZE) {
+   if (file_size > size_limit) {
fprintf(stderr, "ERROR: File too large!\n");
return EXIT_FAILURE;
}
 
-   fd_out = open(argv[2], O_WRONLY | O_CREAT, 0666);
-   if (fd_out < 0) {
-   perror("Open output file");
-   return EXIT_FAILURE;
+   if (ac >= argc) {
+   fd_out = STDOUT_FILENO;
+   } else {
+   fd_out = open(argv[ac], O_WRONLY | O_CREAT, 0666);
+   if (fd_out < 0) {
+   perror("Open output file");
+   return EXIT_FAILURE;
+   }
}
 
/* read file to buffer to calculate checksum */
@@ -115,7 +140,7 @@ int main(int argc, char *argv[])
 & 0x00FF);
memcpy(img.header.magic, BOOT0_MAGIC, 8);   /* no '0' termination */
img.header.length =
-   ALIGN(file_size + sizeof(struct boot_file_head), BLOCK_SIZE);
+   ALIGN(file_size + sizeof(struct boot_file_head), block_size);
img.header.b_instruction = cpu_to_le32(img.header.b_instruction);
img.header.length = cpu_to_le32(img.header.length);
 
-- 
2.8.2

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

[U-Boot] [RFC PATCH 11/11] SPL: SPI: sunxi: add SPL FIT image support

[Andre Przywara]

The sunxi-specific SPI load routine only knows how to load a legacy
U-Boot image.
Teach it how to handle FIT images as well, simply by providing the
existing SPL FIT loader with the right loader routine to access the SPI
NOR flash.

Signed-off-by: Andre Przywara 
---
 drivers/mtd/spi/sunxi_spi_spl.c | 39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
index a24c115..187b39a 100644
--- a/drivers/mtd/spi/sunxi_spi_spl.c
+++ b/drivers/mtd/spi/sunxi_spi_spl.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_SPL_OS_BOOT
 #error CONFIG_SPL_OS_BOOT is not supported yet
@@ -261,27 +262,51 @@ static void spi0_read_data(void *buf, u32 addr, u32 len)
}
 }
 
+static ulong spi_load_read(struct spl_load_info *load, ulong sector,
+  ulong count, void *buf)
+{
+   spi0_read_data(buf, sector, count);
+
+   return count;
+}
+
 /*/
 
 static int spl_spi_load_image(struct spl_image_info *spl_image,
  struct spl_boot_device *bootdev)
 {
-   int err;
+   int ret = 0;
struct image_header *header;
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
 
spi0_init();
 
spi0_read_data((void *)header, CONFIG_SYS_SPI_U_BOOT_OFFS, 0x40);
-   err = spl_parse_image_header(spl_image, header);
-   if (err)
-   return err;
 
-   spi0_read_data((void *)spl_image->load_addr, CONFIG_SYS_SPI_U_BOOT_OFFS,
-  spl_image->size);
+if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+   image_get_magic(header) == FDT_MAGIC) {
+   struct spl_load_info load;
+
+   debug("Found FIT image\n");
+   load.dev = NULL;
+   load.priv = NULL;
+   load.filename = NULL;
+   load.bl_len = 1;
+   load.read = spi_load_read;
+   ret = spl_load_simple_fit(spl_image, ,
+ CONFIG_SYS_SPI_U_BOOT_OFFS, header);
+   } else {
+   ret = spl_parse_image_header(spl_image, header);
+   if (ret)
+   return ret;
+
+   spi0_read_data((void *)spl_image->load_addr,
+  CONFIG_SYS_SPI_U_BOOT_OFFS, spl_image->size);
+   }
 
spi0_deinit();
-   return 0;
+
+   return ret;
 }
 /* Use priorty 0 to override the default if it happens to be linked in */
 SPL_LOAD_IMAGE_METHOD("sunxi SPI", 0, BOOT_DEVICE_SPI, spl_spi_load_image);
-- 
2.8.2

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

[U-Boot] [RFC PATCH 09/11] sunxi: Pine64: defconfig: enable SPL FIT support

[Andre Przywara]

The Pine64 (as all 64-bit Allwinner boards so far) need to load an
ARM Trusted Firmware image beside the actual U-Boot proper.
This can now be easily achieved by using the just extended SPL FIT
loading support, so enable it in the Pine64 defconfig.

Signed-off-by: Andre Przywara 
---
 configs/pine64_plus_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 2374170..e050800 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=y
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
+CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
-- 
2.8.2

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

Re: [U-Boot] mmc: fsl_esdhc: eMMC boot: CMD_ERR (-ECOMM) in u-boot while accessing SD

[Jaehoon Chung]

Hi,

On 01/20/2017 12:37 AM, Jagan Teki wrote:
> On Sun, Jan 15, 2017 at 5:40 PM, Jagan Teki  wrote:
>> Hi,
>>
>> I've observed the CMD_ERR in U-Boot while accessing SD with boot from
>> eMMC on i.MX6 board.
>>
>> SPL initializing SD as well eMMC controllers
>> a) On SD bootmode: from u-boot prompt mmc dev 0 and mmc dev 1 is
>> getting probe SD and eMMC
>> b) On eMMC bootmode: from u-boot prompt mmc dev 0 is returning with
>> -ECOMM in esdhc_send_cmd funtion of fsl_esdhc.c (see the below Log)
>> but mmc dev 1 probed eMMC correctly
>>
>> Log:
>> -
>> icorem6qdl-rqs> mmc dev 0
>>
>> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD0
>>
>> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD8
>>
>> ECOMM irqstat=0xc0001 CMD8
>>
>> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD55
>>
>> ECOMM CMD55
>> mmc_init: -70, time 53
>>
>> With the above log, seems like irqstat has error with
>> BIT19 -CIE-Command Index Error
>> BIT18-CEBE-Command End Bit Error
>>
>> Usually once the CMD8 is executed based on the response the controller
>> will switch to SD or MMC so further communication commands being
>> changes based on that, but here due to controller irqstat error the
>> controller is unable to switch to SD here.
>>
>> The actual working log is [1], this is booting from SD and here is
>> full log[2] for booting from eMMC.
>>
>> [1] https://paste.ubuntu.com/23800820/
>> [2] https://paste.ubuntu.com/23800833/
>>
>> Request for any help.
> 
> Did anyone find this issue? any clue?

Sorry for late..I didn't see this issue..but i will check it..

Best Regards,
Jaehoon Chung

> 
> 

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

Re: [U-Boot] Porting u-boot to a new soc, unsure of standards to follow.

[Marty Plummer]

No comments?

On Sat, Jan 7, 2017 at 12:04 AM, Marty Plummer  wrote:
> Greetings,
>
> So, out of a desire to learn (or simply pure masochism), I've taken it
> upon myself to work on mainlining support for a new arm SoC and board,
> which the vendor SDK only provides source for release 2010.06 (which I
> had to find via taobao since the vendor in question is not being nice
> in regards to providing gpl source code from their sdks, but this is
> besides the point).
>
> Having already cobbled together devicetree files for the SoC which has
> allowed me to boot mainline linux from Linus' tree using the u-boot on
> the board, I figured I'd take a go at using devicetree in u-boot itself
> to describe the hardware. Asking about this on irc, I was pointed at the
> firefly-rk3288 as an example of how to do this. Referencing the source
> code and the datasheet in question, I started to wrap my head around
> bootrom, spl, u-boot, and their interactions, and began the task of
> defining the various system controller registers, using the rockhip code
> as a guide.
>
> However, upon mentioning the structs on irc, I was asked by Marex to not
> use this method, instead using macros and hex offsets. At this point
> I've become a bit confused as to how I should proceed. The coding style
> guide[1] says one should use "a C structure to map out the registers in
> an I/O region", which appears to be what the rk3288 code does, but is at
> odds with Marex's request and instruction to use macros.
>
> So, I'm asking the ml and whatever powers that be how I should proceed,
> as I'd really hate to write a bunch of code that has to be changed to
> such a degree that it may as well be discarded and started from scratch.
>
> Regards,
> Marty Plummer
>
> [1] http://www.denx.de/wiki/U-Boot/CodingStyle
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] mmc: Add Marvell Xenon SDHCI controller driver

[Masahiro Yamada]

Hi Stefan,


2017-01-19 16:39 GMT+09:00 Stefan Roese :
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 9ed8da39ef..87cc9439f3 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -287,6 +287,17 @@ config MMC_SDHCI_SPEAR
>
>   If unsure, say N.
>
> +config MMC_XENON_SDHCI
> +   bool "SDHCI support for the Xenon SDHCI controller"
> +   depends on MMC_SDHCI && DM_MMC && OF_CONTROL
> +   help
> + Support for Xenon SDHCI host controller on Marvell Armada 3700
> + 7k/8k ARM SoCs platforms
> +
> + If you have a controller with this interface, say Y here.
> +
> + If unsure, say N.
> +
>  config MMC_SDHCI_TEGRA
> bool "SDHCI platform support for the Tegra SD/MMC Controller"
> depends on TEGRA


Can you rename the CONFIG symbol to MMC_SDHCI_XENON, please?

The renaming is underway, but I want to make this consistent
in the MMC subsystem in the end.




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

Re: [U-Boot] [PATCH] net: phy: dp83867: add support for MAC impedance configuration

[Grygorii Strashko]

Sry

CC:u-boot@lists.denx.de

On 01/19/2017 04:30 PM, Grygorii Strashko wrote:

From: Mugunthan V N 

Add support for programmable MAC impedance configuration and
fix typo in DT impedance parameters names.

Signed-off-by: Mugunthan V N 
Signed-off-by: Grygorii Strashko 
---
 arch/arm/dts/dra72-evm-revc.dts |  4 ++--
 drivers/net/phy/ti.c| 31 +++
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/dra72-evm-revc.dts b/arch/arm/dts/dra72-evm-revc.dts
index 5a1bb34..bc814f1 100644
--- a/arch/arm/dts/dra72-evm-revc.dts
+++ b/arch/arm/dts/dra72-evm-revc.dts
@@ -67,7 +67,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
-   ti,min-output-imepdance;
+   ti,min-output-impedance;
};

dp83867_1: ethernet-phy@3 {
@@ -75,6 +75,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
-   ti,min-output-imepdance;
+   ti,min-output-impedance;
};
 };
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index c55dd97..21b181a 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -27,6 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170

 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -84,10 +85,17 @@ DECLARE_GLOBAL_DATA_PTR;
 #define DEFAULT_TX_ID_DELAYDP83867_RGMIIDCTL_2_75_NS
 #define DEFAULT_FIFO_DEPTH DP83867_PHYCR_FIFO_DEPTH_4_B_NIB

+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };

 /**
@@ -166,6 +174,15 @@ static int dp83867_of_init(struct phy_device *phydev)
 {
struct dp83867_private *dp83867 = phydev->priv;
struct udevice *dev = phydev->dev;
+   int node = dev->of_offset;
+   const void *fdt = gd->fdt_blob;
+
+   if (fdtdec_get_bool(fdt, node, "ti,max-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (fdtdec_get_bool(fdt, node, "ti,min-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+   else
+   dp83867->io_impedance = -EINVAL;

dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
 "ti,rx-internal-delay", -1);
@@ -186,6 +203,7 @@ static int dp83867_of_init(struct phy_device *phydev)
dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
dp83867->tx_id_delay = DEFAULT_TX_ID_DELAY;
dp83867->fifo_depth = DEFAULT_FIFO_DEPTH;
+   dp83867->io_impedance = -EINVAL;

return 0;
 }
@@ -269,6 +287,19 @@ static int dp83867_config(struct phy_device *phydev)

phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, phydev->addr, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev,
+   DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR,
+   phydev->addr);
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, phydev->addr,
+  val);
+   }
}

genphy_config_aneg(phydev);



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

[U-Boot] [PATCH v3 6/9] imx6: isiotmx6ul: Add FEC support

[Jagan Teki]

From: Jagan Teki 

Add FEC support for Engicam Is.IoT MX6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig |  1 +
 configs/imx6ul_isiot_mmc_defconfig |  3 +++
 include/configs/imx6ul_isiot.h | 10 ++
 3 files changed, 14 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index b81e18c..46b2b59 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -210,6 +210,7 @@ config TARGET_MX6UL_ISIOT
select MX6UL
select OF_CONTROL
select DM
+   select DM_ETH
select DM_GPIO
select DM_I2C
select DM_MMC
diff --git a/configs/imx6ul_isiot_mmc_defconfig 
b/configs/imx6ul_isiot_mmc_defconfig
index 7a7be23..8ecdd8e 100644
--- a/configs/imx6ul_isiot_mmc_defconfig
+++ b/configs/imx6ul_isiot_mmc_defconfig
@@ -23,6 +23,8 @@ CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_GPIO=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
@@ -32,6 +34,7 @@ CONFIG_CMD_FS_GENERIC=y
 # CONFIG_BLK is not set
 CONFIG_SYS_I2C_MXC=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_FEC_MXC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_MXC_UART=y
diff --git a/include/configs/imx6ul_isiot.h b/include/configs/imx6ul_isiot.h
index aba43fc..5a3e05a 100644
--- a/include/configs/imx6ul_isiot.h
+++ b/include/configs/imx6ul_isiot.h
@@ -128,6 +128,16 @@
 # define CONFIG_SYS_FSL_ESDHC_ADDR 0
 #endif
 
+/* Ethernet */
+#ifdef CONFIG_FEC_MXC
+# define CONFIG_FEC_MXC_PHYADDR0
+# define CONFIG_FEC_XCV_TYPE   RMII
+
+# define CONFIG_MII
+# define CONFIG_PHYLIB
+# define CONFIG_PHY_SMSC
+#endif
+
 /* SPL */
 #ifdef CONFIG_SPL
 # define CONFIG_SPL_MMC_SUPPORT
-- 
1.9.1

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

[U-Boot] [PATCH v3 8/9] imx6: isiotmx6ul: Add nandboot env support

[Jagan Teki]

From: Jagan Teki 

Add config options for booting Linux from NAND in UBI format.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 configs/imx6ul_isiot_nand_defconfig |  1 +
 include/configs/imx6ul_isiot.h  | 32 +++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/configs/imx6ul_isiot_nand_defconfig 
b/configs/imx6ul_isiot_nand_defconfig
index 745d10d..bc99d7d 100644
--- a/configs/imx6ul_isiot_nand_defconfig
+++ b/configs/imx6ul_isiot_nand_defconfig
@@ -24,6 +24,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
+CONFIG_CMD_UBI=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
diff --git a/include/configs/imx6ul_isiot.h b/include/configs/imx6ul_isiot.h
index b137848..10311d0 100644
--- a/include/configs/imx6ul_isiot.h
+++ b/include/configs/imx6ul_isiot.h
@@ -48,9 +48,12 @@
"mmcdev=0\0" \
"mmcpart=1\0" \
"mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
+   "nandroot=ubi0:rootfs rootfstype=ubifs\0" \
"mmcautodetect=yes\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=${mmcroot}\0" \
+   "ubiargs=setenv bootargs console=${console},${baudrate} " \
+   "ubi.mtd=5 root=${nandroot} ${mtdparts}\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
@@ -75,8 +78,21 @@
"fi; " \
"else " \
"bootm; " \
-   "fi\0"
+   "fi\0" \
+   "nandboot=echo Booting from nand ...; " \
+   "if mtdparts; then " \
+   "echo Starting nand boot ...; " \
+   "else " \
+   "mtdparts default; " \
+   "fi; " \
+   "run ubiargs; " \
+   "nand read ${loadaddr} kernel 0x80; " \
+   "nand read ${fdt_addr} dtb 0x10; " \
+   "bootm ${loadaddr} - ${fdt_addr}\0"
 
+#ifdef CONFIG_NAND_MXS
+# define CONFIG_BOOTCOMMAND"run nandboot"
+#else
 # define CONFIG_BOOTCOMMAND \
"if mmc rescan; then " \
"if run loadbootscript; then " \
@@ -91,6 +107,7 @@
"fi; " \
"fi; " \
"fi"
+#endif
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_MEMTEST_START   0x8000
@@ -141,6 +158,19 @@
 # define CONFIG_SYS_NAND_U_BOOT_START  CONFIG_SYS_TEXT_BASE
 # define CONFIG_SYS_NAND_U_BOOT_OFFS   0x20
 
+/* MTD device */
+# define CONFIG_MTD_DEVICE
+# define CONFIG_CMD_MTDPARTS
+# define CONFIG_MTD_PARTITIONS
+# define MTDIDS_DEFAULT"nand0=gpmi-nand"
+# define MTDPARTS_DEFAULT  "mtdparts=gpmi-nand:2m(spl),2m(uboot)," 
\
+   "1m(env),8m(kernel),1m(dtb),-(rootfs)"
+
+/* UBI */
+# define CONFIG_CMD_UBIFS
+# define CONFIG_RBTREE
+# define CONFIG_LZO
+
 /* APBH DMA */
 # define CONFIG_APBH_DMA
 # define CONFIG_APBH_DMA_BURST
-- 
1.9.1

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

[U-Boot] [PATCH v3 9/9] imx6ul: isiotmx6ul: Enable I2C support

[Jagan Teki]

From: Jagan Teki 

Enable I2C support for Engicam Is.IoT NAND module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 configs/imx6ul_isiot_nand_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/imx6ul_isiot_nand_defconfig 
b/configs/imx6ul_isiot_nand_defconfig
index bc99d7d..79f08a6 100644
--- a/configs/imx6ul_isiot_nand_defconfig
+++ b/configs/imx6ul_isiot_nand_defconfig
@@ -31,6 +31,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_I2C=y
 CONFIG_OF_LIBFDT=y
 CONFIG_FEC_MXC=y
 CONFIG_MXC_UART=y
@@ -38,6 +39,7 @@ CONFIG_NAND_MXS=y
 CONFIG_IMX_THERMAL=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
+CONFIG_SYS_I2C_MXC=y
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-- 
1.9.1

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

[U-Boot] [PATCH v3 7/9] imx6: isiotmx6ul: Add NAND support

[Jagan Teki]

From: Jagan Teki 

Add NAND support for Engicam Is.IoT MX6UL board.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile |  3 +-
 arch/arm/dts/imx6ul-isiot-nand.dts| 50 +
 board/engicam/isiotmx6ul/MAINTAINERS  |  1 +
 board/engicam/isiotmx6ul/isiotmx6ul.c | 69 +++
 configs/imx6ul_isiot_nand_defconfig   | 46 +++
 include/configs/imx6ul_isiot.h| 25 -
 6 files changed, 192 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/imx6ul-isiot-nand.dts
 create mode 100644 configs/imx6ul_isiot_nand_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd9c0dd..fb2d78a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6ul-geam-kit.dtb \
-   imx6ul-isiot-mmc.dtb
+   imx6ul-isiot-mmc.dtb \
+   imx6ul-isiot-nand.dtb
 
 dtb-$(CONFIG_MX7) += imx7-colibri.dtb
 
diff --git a/arch/arm/dts/imx6ul-isiot-nand.dts 
b/arch/arm/dts/imx6ul-isiot-nand.dts
new file mode 100644
index 000..12a3528
--- /dev/null
+++ b/arch/arm/dts/imx6ul-isiot-nand.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-isiot.dtsi"
+
+/ {
+   model = "Engicam Is.IoT MX6UL NAND Starterkit";
+   compatible = "engicam,imx6ul-isiot", "fsl,imx6ul";
+};
diff --git a/board/engicam/isiotmx6ul/MAINTAINERS 
b/board/engicam/isiotmx6ul/MAINTAINERS
index 0258531..e99e02e 100644
--- a/board/engicam/isiotmx6ul/MAINTAINERS
+++ b/board/engicam/isiotmx6ul/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/engicam/isiotmx6ul
 F: include/configs/imx6ul_isiot.h
 F: configs/imx6ul_isiot_mmc_defconfig
+F: configs/imx6ul_isiot_nand_defconfig
diff --git a/board/engicam/isiotmx6ul/isiotmx6ul.c 
b/board/engicam/isiotmx6ul/isiotmx6ul.c
index c0b18c3..ae3465f 100644
--- a/board/engicam/isiotmx6ul/isiotmx6ul.c
+++ b/board/engicam/isiotmx6ul/isiotmx6ul.c
@@ -37,11 +37,80 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_NAND_MXS
+
+#define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | 
PAD_CTL_PUS_100K_UP)
+#define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \
+   PAD_CTL_SRE_FAST)
+#define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1)
+
+static iomux_v3_cfg_t const nand_pads[] = {
+   MX6_PAD_NAND_DATA00__RAWNAND_DATA00 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA01__RAWNAND_DATA01 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA02__RAWNAND_DATA02 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA03__RAWNAND_DATA03 | MUX_PAD_CTRL(GPMI_PAD_CTRL2),
+   MX6_PAD_NAND_DATA04__RAWNAND_DATA04 | 

[U-Boot] [PATCH v3 3/9] arm: dts: imx6ul-isiot: Add I2C nodes

[Jagan Teki]

From: Jagan Teki 

Add I2C nodes for Engicam Is.IoT MX6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6ul-isiot.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/dts/imx6ul-isiot.dtsi b/arch/arm/dts/imx6ul-isiot.dtsi
index 6108a1a..1a474ca 100644
--- a/arch/arm/dts/imx6ul-isiot.dtsi
+++ b/arch/arm/dts/imx6ul-isiot.dtsi
@@ -56,6 +56,20 @@
};
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1>;
+   status = "okay";
+};
+
+ {
+   clock_frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
@@ -72,6 +86,20 @@
 };
 
  {
+   pinctrl_i2c1: i2c1grp {
+   fsl,pins = <
+   MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+   MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+   >;
+   };
+
+   pinctrl_i2c2: i2c2grp {
+   fsl,pins = <
+   MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+   MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
-- 
1.9.1

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

[U-Boot] [PATCH v3 5/9] arm: dts: imx6ul-isiot: Add FEC node

[Jagan Teki]

From: Jagan Teki 

Add FEC node for Engicam Is.IoT MX6UL module.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/imx6ul-isiot.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/imx6ul-isiot.dtsi b/arch/arm/dts/imx6ul-isiot.dtsi
index 1a474ca..346079a 100644
--- a/arch/arm/dts/imx6ul-isiot.dtsi
+++ b/arch/arm/dts/imx6ul-isiot.dtsi
@@ -56,6 +56,13 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet1>;
+   phy-mode = "rmii";
+   status = "okay";
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -86,6 +93,21 @@
 };
 
  {
+   pinctrl_enet1: enet1grp {
+   fsl,pins = <
+   MX6UL_PAD_ENET2_RX_DATA0__ENET1_MDIO0x1b0b0
+   MX6UL_PAD_ENET2_RX_DATA1__ENET1_MDC 0x1b0b0
+   MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1  0x4001b031
+   MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10   0x1b0b0
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
-- 
1.9.1

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

[U-Boot] [PATCH v3 4/9] imx6: isiotmx6ul: Add I2C support

[Jagan Teki]

From: Jagan Teki 

Add I2C support for Engicam Is.IoT MX6UL module.

isiotmx6ul> i2c bus
Bus 0:  i2c@021a
Bus 1:  i2c@021a4000
isiotmx6ul> i2c dev 0
Setting bus to 0
isiotmx6ul> i2c dev
Current bus is 0
isiotmx6ul> i2c speed 10
Setting bus speed to 10 Hz
isiotmx6ul> i2c probe
Valid chip addresses: 00 2C 44 78
isiotmx6ul> i2c md 2C 0xff
00ff: 00 00 00 00 0f f0 01 64 ff ff 00 00 00 00 00 00...d

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig | 1 +
 configs/imx6ul_isiot_mmc_defconfig | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 72780d7..b81e18c 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -211,6 +211,7 @@ config TARGET_MX6UL_ISIOT
select OF_CONTROL
select DM
select DM_GPIO
+   select DM_I2C
select DM_MMC
select DM_THERMAL
select SUPPORT_SPL
diff --git a/configs/imx6ul_isiot_mmc_defconfig 
b/configs/imx6ul_isiot_mmc_defconfig
index 66eb59f..7a7be23 100644
--- a/configs/imx6ul_isiot_mmc_defconfig
+++ b/configs/imx6ul_isiot_mmc_defconfig
@@ -21,6 +21,7 @@ CONFIG_SYS_PROMPT="isiotmx6ul> "
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_I2C=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -29,6 +30,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 # CONFIG_BLK is not set
+CONFIG_SYS_I2C_MXC=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
-- 
1.9.1

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

[U-Boot] [PATCH v3 1/9] configs: imx6: Don't define USDHC2_BASE_ADDR

[Jagan Teki]

From: Jagan Teki 

USDHC base address will assigned by SPL using fsl_esdhc_initialize
and u-boot with devicetree, hence no remove base address assignment
in config files.

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 include/configs/imx6qdl_icore.h | 2 +-
 include/configs/imx6ul_geam.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/imx6qdl_icore.h b/include/configs/imx6qdl_icore.h
index eb83d23..5a28b15 100644
--- a/include/configs/imx6qdl_icore.h
+++ b/include/configs/imx6qdl_icore.h
@@ -147,7 +147,7 @@
 #ifdef CONFIG_FSL_USDHC
 # define CONFIG_SYS_MMC_ENV_DEV0
 # define CONFIG_SYS_FSL_USDHC_NUM  1
-# define CONFIG_SYS_FSL_ESDHC_ADDR USDHC2_BASE_ADDR
+# define CONFIG_SYS_FSL_ESDHC_ADDR 0
 #endif
 
 /* NAND */
diff --git a/include/configs/imx6ul_geam.h b/include/configs/imx6ul_geam.h
index 23fa3ee..8bffacd 100644
--- a/include/configs/imx6ul_geam.h
+++ b/include/configs/imx6ul_geam.h
@@ -145,7 +145,7 @@
 #ifdef CONFIG_FSL_USDHC
 # define CONFIG_SYS_MMC_ENV_DEV0
 # define CONFIG_SYS_FSL_USDHC_NUM  1
-# define CONFIG_SYS_FSL_ESDHC_ADDR USDHC2_BASE_ADDR
+# define CONFIG_SYS_FSL_ESDHC_ADDR 0
 #endif
 
 /* NAND */
-- 
1.9.1

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

[U-Boot] [PATCH v3 2/9] arm: imx6ul: Add Engicam Is.IoT MX6UL Starter Kit initial support

[Jagan Teki]

From: Jagan Teki 

Boot from MMC:
-
U-Boot SPL 2017.01-rc2-gba3c151-dirty (Jan 02 2017 - 16:59:33)
Trying to boot from MMC1

U-Boot 2017.01-rc2-gba3c151-dirty (Jan 02 2017 - 16:59:33 +0100)

CPU:   Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 33C
Reset cause: POR
Model: Engicam Is.IoT MX6UL Starterkit
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   CPU Net Initialization Failed
No ethernet found.
Hit any key to stop autoboot:  0
isiotmx6ul>

Cc: Stefano Babic 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 arch/arm/cpu/armv7/mx6/Kconfig|  11 ++
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/imx6ul-isiot-mmc.dts |  50 +++
 arch/arm/dts/imx6ul-isiot.dtsi|  92 +
 board/engicam/isiotmx6ul/Kconfig  |  12 ++
 board/engicam/isiotmx6ul/MAINTAINERS  |   6 +
 board/engicam/isiotmx6ul/Makefile |   6 +
 board/engicam/isiotmx6ul/README   |  28 
 board/engicam/isiotmx6ul/isiotmx6ul.c | 247 ++
 configs/imx6ul_isiot_mmc_defconfig|  36 +
 include/configs/imx6ul_isiot.h| 142 +++
 11 files changed, 632 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6ul-isiot-mmc.dts
 create mode 100644 arch/arm/dts/imx6ul-isiot.dtsi
 create mode 100644 board/engicam/isiotmx6ul/Kconfig
 create mode 100644 board/engicam/isiotmx6ul/MAINTAINERS
 create mode 100644 board/engicam/isiotmx6ul/Makefile
 create mode 100644 board/engicam/isiotmx6ul/README
 create mode 100644 board/engicam/isiotmx6ul/isiotmx6ul.c
 create mode 100644 configs/imx6ul_isiot_mmc_defconfig
 create mode 100644 include/configs/imx6ul_isiot.h

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index c646966..72780d7 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -205,6 +205,16 @@ config TARGET_MX6UL_GEAM
select DM_THERMAL
select SUPPORT_SPL
 
+config TARGET_MX6UL_ISIOT
+   bool "Support Engicam Is.IoT MX6UL"
+   select MX6UL
+   select OF_CONTROL
+   select DM
+   select DM_GPIO
+   select DM_MMC
+   select DM_THERMAL
+   select SUPPORT_SPL
+
 config TARGET_MX6ULL_14X14_EVK
bool "Support mx6ull_14x14_evk"
select MX6ULL
@@ -313,6 +323,7 @@ source "board/embest/mx6boards/Kconfig"
 source "board/engicam/geam6ul/Kconfig"
 source "board/engicam/icorem6/Kconfig"
 source "board/engicam/icorem6_rqs/Kconfig"
+source "board/engicam/isiotmx6ul/Kconfig"
 source "board/freescale/mx6qarm2/Kconfig"
 source "board/freescale/mx6qsabreauto/Kconfig"
 source "board/freescale/mx6sabresd/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 66ea0b3..bd9c0dd 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -302,7 +302,8 @@ dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6dl-icore-rqs.dtb \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
-   imx6ul-geam-kit.dtb
+   imx6ul-geam-kit.dtb \
+   imx6ul-isiot-mmc.dtb
 
 dtb-$(CONFIG_MX7) += imx7-colibri.dtb
 
diff --git a/arch/arm/dts/imx6ul-isiot-mmc.dts 
b/arch/arm/dts/imx6ul-isiot-mmc.dts
new file mode 100644
index 000..bb5086a
--- /dev/null
+++ b/arch/arm/dts/imx6ul-isiot-mmc.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of 

[U-Boot] [PATCH v3 0/9] imx6ul: Add Engicam Is.IoT MX6UL support

[Jagan Teki]

From: Jagan Teki 

This patch set support Engicam Is.IoT MX6UL board support.

Changes for v2:
- Skiped eMMC node patch
- Rebase to master

Changes for v1:
- Rebase to master

Jagan Teki (9):
  configs: imx6: Don't define USDHC2_BASE_ADDR
  arm: imx6ul: Add Engicam Is.IoT MX6UL Starter Kit initial support
  arm: dts: imx6ul-isiot: Add I2C nodes
  imx6: isiotmx6ul: Add I2C support
  arm: dts: imx6ul-isiot: Add FEC node
  imx6: isiotmx6ul: Add FEC support
  imx6: isiotmx6ul: Add NAND support
  imx6: isiotmx6ul: Add nandboot env support
  imx6ul: isiotmx6ul: Enable I2C support

 arch/arm/cpu/armv7/mx6/Kconfig|  13 ++
 arch/arm/dts/Makefile |   4 +-
 arch/arm/dts/imx6ul-isiot-mmc.dts |  50 ++
 arch/arm/dts/imx6ul-isiot-nand.dts|  50 ++
 arch/arm/dts/imx6ul-isiot.dtsi| 142 +++
 board/engicam/isiotmx6ul/Kconfig  |  12 ++
 board/engicam/isiotmx6ul/MAINTAINERS  |   7 +
 board/engicam/isiotmx6ul/Makefile |   6 +
 board/engicam/isiotmx6ul/README   |  28 +++
 board/engicam/isiotmx6ul/isiotmx6ul.c | 316 ++
 configs/imx6ul_isiot_mmc_defconfig|  41 +
 configs/imx6ul_isiot_nand_defconfig   |  49 ++
 include/configs/imx6qdl_icore.h   |   2 +-
 include/configs/imx6ul_geam.h |   2 +-
 include/configs/imx6ul_isiot.h| 205 ++
 15 files changed, 924 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/imx6ul-isiot-mmc.dts
 create mode 100644 arch/arm/dts/imx6ul-isiot-nand.dts
 create mode 100644 arch/arm/dts/imx6ul-isiot.dtsi
 create mode 100644 board/engicam/isiotmx6ul/Kconfig
 create mode 100644 board/engicam/isiotmx6ul/MAINTAINERS
 create mode 100644 board/engicam/isiotmx6ul/Makefile
 create mode 100644 board/engicam/isiotmx6ul/README
 create mode 100644 board/engicam/isiotmx6ul/isiotmx6ul.c
 create mode 100644 configs/imx6ul_isiot_mmc_defconfig
 create mode 100644 configs/imx6ul_isiot_nand_defconfig
 create mode 100644 include/configs/imx6ul_isiot.h

-- 
1.9.1

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

Re: [U-Boot] [PATCH] armv8: ls1046aqds: added usb feature support

[Y.T. Tang]

Hi York,

Sorry for the trouble. I remember I tested it when I submitted the patch.
Anyway, I will check it out.

Regards,
Yuantian

> -Original Message-
> From: york sun
> Sent: Thursday, January 19, 2017 1:20 AM
> To: Y.T. Tang 
> Cc: Mingkai Hu ; u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: ls1046aqds: added usb feature support
> 
> On 12/26/2016 06:55 PM, yuantian.t...@nxp.com wrote:
> > From: Tang Yuantian 
> >
> > The LS1046AQDS processor has three integrated USB 3.0 controllers
> > (USB1, USB2, and USB3) that allow direct connection to the USB ports
> > with appropriate protection circuitry and power supplies.
> > USB1 and USB2 ports are powered by a NX5P2190UK device, which supplies
> > 5v power at up to 1.2 A. The power enable and power-fault-detect pins
> > are connected to the LS1046A processor via CPLD for individual port
> > management.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  include/configs/ls1046aqds.h | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/include/configs/ls1046aqds.h
> > b/include/configs/ls1046aqds.h index 29e0aa5..53a1ffb 100644
> > --- a/include/configs/ls1046aqds.h
> > +++ b/include/configs/ls1046aqds.h
> > @@ -135,6 +135,14 @@ unsigned long get_board_ddr_clk(void);
> >  #define CFG_LPUART_EN  0x2
> >  #endif
> >
> > +/* USB */
> > +#define CONFIG_HAS_FSL_XHCI_USB
> > +#ifdef CONFIG_HAS_FSL_XHCI_USB
> > +#define CONFIG_USB_XHCI_FSL
> > +#define CONFIG_USB_MAX_CONTROLLER_COUNT3
> > +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
> > +#endif
> > +
> >  /* SATA */
> >  #define CONFIG_LIBATA
> >  #define CONFIG_SCSI_AHCI
> >
> 
> Yuantian,
> 
> I wonder if CONFIG_USB_XHCI_DWC3 should also be defined. Without it I
> got compiling error
> 
> drivers/usb/host/xhci-fsl.c:72:2: warning: implicit declaration of function
> 'dwc3_core_init' [-Wimplicit-function-declaration]
>ret = dwc3_core_init(fsl_xhci->dwc3_reg);
>^
> 
> I have no issue with this patch with similar change
> http://patchwork.ozlabs.org/patch/695027/
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] SECURE_BOOT: Update bootscript and its hdr addresses

[york sun]

On 01/05/2017 08:30 PM, Udit Agarwal wrote:
> Update bootscript and its hdr addresses for Layerscape Chasis 3
> based platforms instead of individual SoCs.
>
> Signed-off-by: Sumit Garg 
> Signed-off-by: Udit Agarwal 
> ---
>
> Changes for V2:
> Modified the subject
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

[U-Boot] [PATCH] arm: omap3: Update cpuinfo for DM3730, DM3725, AM3715, and AM3703

[Adam Ford]

The check for OMAP3630/3730 only checks for 800MHz 3630/3730, but
anything else is lumped into 36XX/37XX with an assumed 1GHz speed.

Based on the DM3730 TRM bit 9 shows the MPU Frequency (800MHz/1GHZ).
This also adds the ability to distinguish between the DM3730, DM3725,
AM3715, and AM3703 and correctly display their maximum speed.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/include/asm/arch-omap3/omap.h 
b/arch/arm/include/asm/arch-omap3/omap.h
index 417ff89..a70a426 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -230,6 +230,14 @@ struct gpio {
 #define AM3517 0x1c00
 
 #define OMAP3730   0x0c00
+#define OMAP3725   0x4c00
+#define AM3715 0x1c00
+#define AM3703 0x5c00
+
+#define OMAP3730_1GHZ  0x0e00
+#define OMAP3725_1GHZ  0x4e00
+#define AM3715_1GHZ0x1e00
+#define AM3703_1GHZ0x5e00
 
 /*
  * ROM code API related flags
diff --git a/arch/arm/mach-omap2/omap3/sys_info.c 
b/arch/arm/mach-omap2/omap3/sys_info.c
index 6818fab..99c9120 100644
--- a/arch/arm/mach-omap2/omap3/sys_info.c
+++ b/arch/arm/mach-omap2/omap3/sys_info.c
@@ -295,16 +295,54 @@ int print_cpuinfo (void)
max_clk = "600 Mhz";
break;
case CPU_OMAP36XX:
-   cpu_family_s = "OMAP";
switch (get_cpu_type()) {
+   case AM3703:
+   cpu_family_s = "AM";
+   cpu_s = "3703";
+   max_clk = "800 MHz";
+   break;
+   case AM3703_1GHZ:
+   cpu_family_s = "AM";
+   cpu_s = "3703";
+   max_clk = "1 GHz";
+   break;
+   case AM3715:
+   cpu_family_s = "AM";
+   cpu_s = "3715";
+   max_clk = "800 MHz";
+   break;
+   case AM3715_1GHZ:
+   cpu_family_s = "AM";
+   cpu_s = "3715";
+   max_clk = "1 GHz";
+   break;
+   case OMAP3725:
+   cpu_family_s = "OMAP";
+   cpu_s = "3625/3725";
+   max_clk = "800 MHz";
+   break;
+   case OMAP3725_1GHZ:
+   cpu_family_s = "OMAP";
+   cpu_s = "3625/3725";
+   max_clk = "1 GHz";
+   break;
case OMAP3730:
+   cpu_family_s = "OMAP";
cpu_s = "3630/3730";
+   max_clk = "800 MHz";
+   break;
+   case OMAP3730_1GHZ:
+   cpu_family_s = "OMAP";
+   cpu_s = "3630/3730";
+   max_clk = "1 GHz";
break;
default:
+   cpu_family_s = "OMAP/AM";
cpu_s = "36XX/37XX";
+   max_clk = "1 GHz";
break;
}
-   max_clk = "1 Ghz";
+
break;
default:
cpu_family_s = "OMAP";
-- 
2.7.4

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

Re: [U-Boot] [PATCH 3/4] Move CONFIG_NAND_MXS to defconfig

[Tom Rini]

On Thu, Jan 19, 2017 at 05:34:25PM +0100, Jagan Teki wrote:
> On Thu, Jan 19, 2017 at 5:11 PM, Tom Rini  wrote:
> > On Thu, Jan 19, 2017 at 04:46:18PM +0100, Jagan Teki wrote:
> >> On Wed, Jan 11, 2017 at 12:14 AM, Tom Rini  wrote:
> >> > On Sat, Jan 07, 2017 at 12:42:34PM +0100, Jagan Teki wrote:
> >> >
> >> >> Cc: Stefano Babic 
> >> >> Signed-off-by: Jagan Teki 
> >> > [snip]
> >> >>  33 files changed, 21 insertions(+), 12 deletions(-)
> >> > [snip]
> >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> >> >> index 65bb040..682e4e3 100644
> >> >> --- a/drivers/mtd/nand/Kconfig
> >> >> +++ b/drivers/mtd/nand/Kconfig
> >> >> @@ -82,7 +82,6 @@ config NAND_ARASAN
> >> >>
> >> >>  config NAND_MXS
> >> >>   bool "MXS NAND support"
> >> >> - depends on MX6
> >> >>   help
> >> >> This enables NAND driver for the NAND flash controller on the
> >> >> MXS processors.
> >> >
> >> > I think we've got something going wrong here.  Why are we removing the
> >> > depends on line?  I know we can't make this a default y until 'NAND'
> >> > gets migrated, and that's non-trivial.  Thanks!
> >>
> >> Yes, I was trying to add 'depends on' but ended-up making more
> >> complex, because there is common config ARCH_MXC like Linux and
> >
> > I assume that should read "there is not".  And then we should introduce
> > ARCH_MXC like Linux and use it.  Thanks!
> 
> Yeah, sorry for the typo. I too plan for adding ARCH_MXC and it will
> be more change-set better to move defconfig changes first and will
> update them after?

I'd like to add it in first and select it, then we can make these
conversions easier.

-- 
Tom


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

Re: [U-Boot] [PATCHv5 1/2] armv8/fsl-lsch2: refactor the clock system initialization

[york sun]

On 01/10/2017 12:57 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Up to now, there are 3 kind of SoCs under Layerscape Chassis 2,
> like LS1043A, LS1046A and LS1012A. But the clocks tree has a
> lot of differences, for instance, the IP modules have different
> dividers to derive its clock from Platform PLL. And the core
> cluster PLL and platform PLL maybe have different reference
> clocks, such as LS1012A. Another problem is which clock/PLL
> should be described by sys_info->freq_systembus, it is confused
> in Layerscape Chissis 2.
>
> This patch is to bind the sys_info->freq_systembus to the Platform
> PLL, and handle the different divider of IP modules separately
> between different SoCs, and separate reference clocks of core
> cluster PLL and platform PLL.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V5:
>  - Correct the eSDHC controller clock getting.
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCHv5 01/17] configs: ls1021a: enable DT and DM support

[york sun]

On 12/12/2016 11:08 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Enable DT to support Driver Model.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V5:
>  - No change
>

This patch set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York


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

Re: [U-Boot] Rockchip RK3288 boot trouble

[Rick Bronson]

Hi Kever and Simon,

  Thanks very much for the help.  Really appreciate it.

> I didn't see your detail steps for getting u-boot-dtb.bin, does it
> include SPL here?

  I'm using this method:

> 2. with "CONFIG_ROCKCHIP_SPL_BACK_TO_BROM", which is default setting
...

> I'm confusing with this incorrect DRAM size, could you share the console
> output
> during you flash the image, there should have correct DRAM size info.
> I'm not sure if the DRAM on your board is symmetric or not,  or any else
> special.

  See below for the output.  I noticed that I only have "Channel b"
and not "Channel a".  On my other board that boots, I have both a and b. I
wonder if one bank of DDR3 went bad on this
board.  What do you think?

  Thanks again.

  Rick


DDR Version 1.00 20160217
In
Channel b: DDR3 200MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=8 Size=1024MB
Memory OK
OUT
usb boot ver:20160218
ChipType = 8
...FlashInit enter...
FtlMallocOffset = 8040 8000
FtlMallocOffset = 10040 8000
FtlMallocOffset = 11040 1000
FtlMallocOffset = 19040 8000
FtlMallocOffset = 1a040 1000
1:0 0 7f7f05 22
...NandcInit enter...
0:1200 0 7f7f05 22
FtlMallocOffset = 23040 9000
gNandcVer = 6
 SDC_BusRequest:  CMD=8  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=8  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=8  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=5  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=5  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=5  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=55  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=55  SDC_RESP_TIMEOUT 1815
  SDC_BusRequest:  CMD=55  SDC_RESP_TIMEOUT 1815
 mmc Ext_csd, ret=0 ,
 Ext[226]=20, bootSize=2000,
 Ext[215]=1, Ext[214]=d5, Ext[213]=a0, Ext[212]=0,cap
=1d5a000 R
EL=1f
SdmmcInit=2 0
BootCapSize=2000
UserCapSize=1d5a000
FwPartOffset=2000 , 2000
UsbHook 622396
powerOn 623080
DDR Version 1.00 20160217
In
SRX
Channel b: DDR3 200MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=8 Size=1024MB



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

Re: [U-Boot] [PATCH v3] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[york sun]

On 01/16/2017 05:52 PM, Alison Wang wrote:
> For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
> of boot protocol. To fix this issue, input argument 4 is added for
> armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4 will
> be set to the right value, such as zero.
>
> Signed-off-by: Alison Wang 
> Reviewed-by: Alexander Graf 
> Tested-by: Ryan Harkin 
> ---
> Changes in v3:
> - Remove redundant code.
> Changes in v2:
> - Add another input argument 4 for armv8_switch_to_el2 and 
> armv8_switch_to_el1.
> - Give up the previous way to adjust the parameters to transfer and make sure 
> x3 is zero.


Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] armv8: fsl-layerscape: Fix SECURE_BOOT config

[york sun]

On 01/04/2017 10:32 AM, York Sun wrote:
> Without a prompt in Kconfig, SECURE_BOOT cannot be selected by
> defconfig. The option was dropped unintentionally when defconfig
> files were cleaned up. Three targets were impacted
> ls1043ardb_SECURE_BOOT, ls2080ardb_SECURE_BOOT,
> ls2080aqds_SECURE_BOOT.
>
> Signed-off-by: York Sun 
> Reviewed-by: Simon Glass 
> ---

Applied to fsl-qoriq master, awaiting upstream.

York

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

Re: [U-Boot] [PATCHv2 1/2] ARMv8/fsl-layerscape: Correct the OCRAM size

[york sun]

On 12/16/2016 01:29 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> The real size of OCRAM is 128KiB, so correct the size of OCRAM.
> And OCRAM reserved 2MiB space, then add a new macro to describe
> it, which is used for MMU setup.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - New patch
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v2] defconfig: Add a config for AM335x High Security EVM

[Lokesh Vutla]

On Thursday 19 January 2017 09:29 PM, Andrew F. Davis wrote:
> On 01/17/2017 10:14 PM, Lokesh Vutla wrote:
>>
>> [..snip..]
>>
>>> +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
>>> am335x-bonegreen am335x-icev2"
>>
>> Just wondering, do we have HS variants of all these boards? If not we
>> can just keep am335x-evm.
>>
>
> We don't "technically" have HS vs non-HS versions of any board, the
> boards are the same, the non-HS ones simply have the security features
> locked out. If the silicon they put on any of these boards is not locked
> out then it becomes an HS board.

 Thanks.

>
> But, yes, I only know of unlocked AM335x's currently being placed on the
> standard EVMs for now.
>
 okay. Then drop all the other dtbs from the list.

>>>
>>> I'm not sure what that would get us, the differences between non-HS and
>>> HS have nothing to do with the devices on the boards. This will only
>>> create a support burden if someone gets an unlocked Beaglebone for
>>> instance. Why limit the *more* feature-full chip? HS chips needs to be
>>> thought of as they are, a superset of the non-HS chips, not as a
>>> different kind of chip.
>>
>> Is this officially supported? Have you tested before posting?
>> If no then there should not be any argument for adding this support
>> assuming this can possibly be useful or experimental.
>>
> 
> I have tested this on the -EVM and will not test this on other boards.
> The type of board used is unrelated to adding boot authentication. This
> is not a new chip or board, it is a configuration change defconfig only.
> (If we could include other defconfigs like we can DTB files then this
> defconfig would include the regular defconfig and add a few lines. This
> would be useful for merging all the am335x/am43xx defconfig variations
> that have started to get rather out of sync with each other).
> 
> Think if I added an I2C driver, there would be no need to test it on
> every board U-Boot supports, just one, and if it didn't work on some
> board that would be a bug against the board, not against the driver.

The point here is what is being officially supported. Even the $subject
says only *AM335x High security evm* but the patch adds support for all
boards with HS silicon. Also look at the size of the image that is
getting bloated when you know you are using only 1 evm.

I understand that it is good to have but I am saying that it can be
added easily when someone *really* needs it.

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

Re: [U-Boot] [PATCHv2 1/4] kconfig: armv8: move armv8 sec_firmware CONFIG_* to Kconfig

[york sun]

On 01/16/2017 01:45 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - Generate the patch base on the latest code.
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCHv8 1/2] armv8/ls1043a: fixup GIC offset for ls1043a rev1

[york sun]

On 01/17/2017 02:44 AM, Zhiqiang Hou wrote:
> From: Wenbin Song 
>
> The LS1043A rev1.1 silicon supports two types of GIC offset: 4K
> alignment and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT]
> is used to choose which offset will be used.
>
> The LS1043A rev1.0 silicon only supports the CIG offset with 4K
> alignment.
>
> If GIC_ADDR_BIT bit is set, 4K alignment is used, or else 64K alignment
> is used. 64K alignment is the default setting.
>
> Overriding the weak smp_kick_all_cpus, the new impletment is able to
> detect GIC offset.
>
> The default GIC offset in kernel device tree is using 4K alignment, it
> need to be fixed if 64K alignment is detected.
>
> Signed-off-by: Wenbin Song 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Hou Zhiqiang 
> ---
> V8:
>  - Fixed a compile error for ls2080.
>  - Removed the duplicated definition of ls1043a SVR.
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCHv2 1/2] armv8: Enable CPUECTLR.SMPEN for coherency

[york sun]

On 01/06/2017 01:54 AM, Zhiqiang Hou wrote:
> From: Mingkai Hu 
>
> For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
> set. The SMPEN bit should be set before enabling the data cache.
> If not enabled, the cache is not coherent with other cores and
> data corruption could occur.
>
> For A57/A72, SMPEN bit enables the processor to receive instruction
> cache and TLB maintenance operations broadcast from other processors
> in the cluster. This bit should be set before enabling the caches and
> MMU, or performing any cache and TLB maintenance operations.
>
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Gong Qianyu 
> Signed-off-by: Mateusz Kulikowski 
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - Revised the help information.
>

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [v4, 1/3] mmc: fsl_esdhc: move 'status' property fixup into a weak function

[york sun]

On 01/16/2017 06:57 PM, Yangbo Lu wrote:
> Move fdt fixup of 'status' property into a weak function. This allows
> board to define 'status' fdt fixup by themselves.
>
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None
> Changes for v3:
>   - None
> Changes for v4:
>   - None
> ---

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York


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

Re: [U-Boot] [PATCH] armv8/layerscape: remove unnecessary function declares

[york sun]

On 11/15/2016 01:33 AM, Minghuan Lian wrote:
> For the function alloc_stream_ids() append_mmu_masters() and
> fdt_fixup_smmu_pcie() there are no related definitions and they
> are never called. So the patch removes the unnecessary declares.
>
> Signed-off-by: Minghuan Lian 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/5] pmic: pmic_mc34vr500: Add a driver for the mc34vr500 pmic

[york sun]

On 12/09/2016 12:22 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> This patch adds a simple pmic driver for the mc34vr500 pmic which
> is used in conjunction with the fsl T1 and LS1 series SoC.
>
> Signed-off-by: Hou Zhiqiang 
> ---

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/4] mmc: fsl_esdhc: make GPIO support optional

[york sun]

On 12/06/2016 08:08 PM, Yangbo Lu wrote:
> There would be compiling error as below when enable driver model for esdhc.
> undefined reference to `dm_gpio_get_value'
> undefined reference to `gpio_request_by_name_nodev'
> This patch is to make GPIO support optional with CONFIG_DM_GPIO. Because
> all boards of QorIQ platform don't need it and they just check register for
> CD/WP status, only some boards of i.MX platform require this.
>
> Signed-off-by: Yangbo Lu 
> ---

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] arm: layerscape: Enable UUID & GPT partition for NXP's ARM SoC

[york sun]

On 12/25/2016 10:45 PM, Prabhakar Kushwaha wrote:
> Enable UUID and GPT partition support for NXP's ARM based SoCs
> i.e. LS1012A, LS1021A, LS1043A, LS1046A and LS2080A.
>
> Also enable DOS partition for LS1012AFRDM boards.
>
> Signed-off-by: Prabhakar Kushwaha 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2] armv8: ls1012: added usb nodes in dts

[york sun]

On 12/26/2016 06:37 PM, yuantian.t...@nxp.com wrote:
> From: Tang Yuantian 
>
> The LS1012A processor has two integrated USB controllers.
> One is USB2.0 controller, the other is USB3.0 controller that
> allow direct connection to the USB ports with appropriate
> protection circuitry and power supplies.
>
> Signed-off-by: Tang Yuantian 
> ---

This set is applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: fsl-layerscape, ccn504: Set forced-order mode in RNI-6, RNI-20

[york sun]

On 11/08/2016 10:58 PM, Priyanka Jain wrote:
> It is recommended to set forced-order mode in RNI-6,
> RNI-20 for performance optimization in LS2088A.
>
> Both LS2080A, LS2088A families has CONFIG_LS2080A define.
> As above update is required only for LS2088A, skip this
> for LS2080A SoC family
>
> Signed-off-by: Priyanka Jain 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] fsl/usb: enable usb feature for ls1046ardb

[york sun]

On 11/14/2016 07:56 PM, jerry.hu...@nxp.com wrote:
> Enable usb feature for ls1046ardb
>
> Signed-off-by: Changming Huang 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

[U-Boot] Please pull u-boot-fsl-qoriq master

[york sun]

Tom,

The following changes since commit a705ebc81b7f91bbd0ef7c634284208342901149:

   Prepare v2017.01 (2017-01-09 11:57:05 -0500)

are available in the git repository at:

   git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 5e4a6db8f428cb1f8ced74bc77241144ac0c5b1a:

   armv8: ls1012a: define esdhc_status_fixup for RDB board (2017-01-18 
09:46:52 -0800)


Alison Wang (1):
   armv8: aarch64: Fix the warning about x1-x3 nonzero issue

Hou Zhiqiang (17):
   configs: ls1021a: enable DT and DM support
   pci: layerscape: move kernel DT fixup to a separate file
   kconfig: move FSL_PCIE_COMPAT to platform Kconfig
   ARMv8/fsl-layerscape: Correct the OCRAM size
   armv8/fsl_lsch2: Add the OCRAM initialization
   ARMv8/fsl-layerscape: Enable data coherency between cores in cluster
   armv8/fsl-lsch2: refactor the clock system initialization
   armv8/fsl-lsch3: consolidate the clock system initialization
   pmic: pmic_mc34vr500: Add a driver for the mc34vr500 pmic
   pmic: pmic_mc34vr500: Add APIs to set/get SWx volt
   ls1046ardb: cpld: add API for selecting core volt
   armv8/fsl_lsch2: Add chip power supply voltage setup
   ls1046ardb: Add support power initialization
   kconfig: armv8: move armv8 sec_firmware CONFIG_* to Kconfig
   ARMv8/sec_firmware: relocated and renamed the config 
FSL_PPA_ARMV8_PSCI
   kconfig: fsl PPA: move CONFIG_* to Kconfig
   fsl PPA: enable PPA for ls1043ardb and ls1046ardb

Minghuan Lian (15):
   armv8/layerscape: remove unnecessary function declares
   dm: pci: return the real controller in pci_bus_to_hose()
   dm: pci: remove pci_bus_to_hose(0) calling
   arm: ls1021a: add PCIe dts node
   arm: ls1012a: add PCIe dts node
   armv8: ls1043a: add PCIe dts node
   armv8: ls1046a: add PCIe dts node
   armv8: ls2080a: add PCIe dts node
   pci: layerscape: add pci driver based on DM
   arm: ls1021a: Enable PCIe in defconfigs
   arm: ls1012a: Enable PCIe and E1000 in defconfigs
   armv8: ls1043a: Enable PCIe and E1000 in defconfigs
   armv8: ls1046a: Enable PCIe and E1000 in defconfigs
   armv8: ls2080a: Enable PCIe in defconfigs
   pci: layerscape: remove unnecessary legacy code

Mingkai Hu (1):
   armv8: Enable CPUECTLR.SMPEN for coherency

Prabhakar Kushwaha (1):
   arm: layerscape: Enable UUID & GPT partition for NXP's ARM SoC

Priyanka Jain (1):
   armv8: fsl-layerscape, ccn504: Set forced-order mode in RNI-6, RNI-20

Tang Yuantian (3):
   armv8: ls1012: added usb nodes in dts
   armv8: ls1012: Enable CONFIG_DM_USB in defconfigs
   armv8: fsl-lsch3: enable snoopable sata read and write

Udit Agarwal (2):
   SECURE_BOOT: Update bootscript and its hdr addresses
   LS2080A: Add validation of MC & DPC images.

Wenbin Song (2):
   armv8/ls1043a: fixup GIC offset for ls1043a rev1
   armv8/fsl-layerscape: fdt: fixup LS1043A rev1 MSI node

Yangbo Lu (7):
   mmc: fsl_esdhc: make GPIO support optional
   mmc: fsl_esdhc: add 'fsl, esdhc' into of_match table
   armv8: ls1012a: add eSDHC nodes
   configs: ls1012a: enable driver model for eSDHC
   mmc: fsl_esdhc: move 'status' property fixup into a weak function
   armv8: ls1012a: define esdhc_status_fixup for QDS board
   armv8: ls1012a: define esdhc_status_fixup for RDB board

York Sun (1):
   armv8: fsl-layerscape: Fix SECURE_BOOT config

jerry.hu...@nxp.com (1):
   fsl/usb: enable usb feature for ls1046ardb

  arch/arm/Kconfig   |   1 +
  arch/arm/cpu/armv7/ls102xa/Kconfig |   8 +
  arch/arm/cpu/armv8/Kconfig |  59 ++
  arch/arm/cpu/armv8/Makefile|   2 +-
  arch/arm/cpu/armv8/cpu-dt.c|   2 +-
  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  | 132 ++-
  arch/arm/cpu/armv8/fsl-layerscape/Makefile |   2 +-
  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   5 +-
  arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 220 -
  .../cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c| 272 ++
  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |  69 +-
  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |  28 +-
  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   | 146 ++-
  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  91 ++
  arch/arm/cpu/armv8/sec_firmware.c  |   2 +-
  arch/arm/cpu/armv8/sec_firmware_asm.S  |  12 +-
  arch/arm/cpu/armv8/start.S |  19 +-
  arch/arm/cpu/armv8/transition.S|  22 +-
  arch/arm/dts/fsl-ls1012a.dtsi  |  46 +
  arch/arm/dts/fsl-ls1043a.dtsi  |  46 +
  arch/arm/dts/fsl-ls1046a.dtsi  |  49 ++
  arch/arm/dts/fsl-ls2080a.dtsi  |  60 ++
  

[U-Boot] [PATCH 1/1] cmd/host: add missing \n in help text

[Sébastien Szymanski]

Signed-off-by: Sébastien Szymanski 
---
 cmd/host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/host.c b/cmd/host.c
index 515621b..080b7cf 100644
--- a/cmd/host.c
+++ b/cmd/host.c
@@ -181,7 +181,7 @@ U_BOOT_CMD(
"host ls hostfs - - list files on host\n"
"host save hostfs -[] - "
"save a file to host\n"
-   "host size hostfs -  - determine size of file on host"
+   "host size hostfs -  - determine size of file on host\n"
"host bind  [] - bind \"host\" device to file\n"
"host info []- show device binding & info\n"
"host dev [] - Set or retrieve the current host device\n"
-- 
2.7.3

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

Re: [U-Boot] [PATCH 3/4] Move CONFIG_NAND_MXS to defconfig

[Jagan Teki]

On Thu, Jan 19, 2017 at 5:11 PM, Tom Rini  wrote:
> On Thu, Jan 19, 2017 at 04:46:18PM +0100, Jagan Teki wrote:
>> On Wed, Jan 11, 2017 at 12:14 AM, Tom Rini  wrote:
>> > On Sat, Jan 07, 2017 at 12:42:34PM +0100, Jagan Teki wrote:
>> >
>> >> Cc: Stefano Babic 
>> >> Signed-off-by: Jagan Teki 
>> > [snip]
>> >>  33 files changed, 21 insertions(+), 12 deletions(-)
>> > [snip]
>> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>> >> index 65bb040..682e4e3 100644
>> >> --- a/drivers/mtd/nand/Kconfig
>> >> +++ b/drivers/mtd/nand/Kconfig
>> >> @@ -82,7 +82,6 @@ config NAND_ARASAN
>> >>
>> >>  config NAND_MXS
>> >>   bool "MXS NAND support"
>> >> - depends on MX6
>> >>   help
>> >> This enables NAND driver for the NAND flash controller on the
>> >> MXS processors.
>> >
>> > I think we've got something going wrong here.  Why are we removing the
>> > depends on line?  I know we can't make this a default y until 'NAND'
>> > gets migrated, and that's non-trivial.  Thanks!
>>
>> Yes, I was trying to add 'depends on' but ended-up making more
>> complex, because there is common config ARCH_MXC like Linux and
>
> I assume that should read "there is not".  And then we should introduce
> ARCH_MXC like Linux and use it.  Thanks!

Yeah, sorry for the typo. I too plan for adding ARCH_MXC and it will
be more change-set better to move defconfig changes first and will
update them after?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] Move CONFIG_NAND_MXS to defconfig

[Tom Rini]

On Thu, Jan 19, 2017 at 04:46:18PM +0100, Jagan Teki wrote:
> On Wed, Jan 11, 2017 at 12:14 AM, Tom Rini  wrote:
> > On Sat, Jan 07, 2017 at 12:42:34PM +0100, Jagan Teki wrote:
> >
> >> Cc: Stefano Babic 
> >> Signed-off-by: Jagan Teki 
> > [snip]
> >>  33 files changed, 21 insertions(+), 12 deletions(-)
> > [snip]
> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> >> index 65bb040..682e4e3 100644
> >> --- a/drivers/mtd/nand/Kconfig
> >> +++ b/drivers/mtd/nand/Kconfig
> >> @@ -82,7 +82,6 @@ config NAND_ARASAN
> >>
> >>  config NAND_MXS
> >>   bool "MXS NAND support"
> >> - depends on MX6
> >>   help
> >> This enables NAND driver for the NAND flash controller on the
> >> MXS processors.
> >
> > I think we've got something going wrong here.  Why are we removing the
> > depends on line?  I know we can't make this a default y until 'NAND'
> > gets migrated, and that's non-trivial.  Thanks!
> 
> Yes, I was trying to add 'depends on' but ended-up making more
> complex, because there is common config ARCH_MXC like Linux and

I assume that should read "there is not".  And then we should introduce
ARCH_MXC like Linux and use it.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] defconfig: Add a config for AM335x High Security EVM

[Andrew F. Davis]

On 01/17/2017 10:14 PM, Lokesh Vutla wrote:
> 
> [..snip..]
> 
>> +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
>> am335x-bonegreen am335x-icev2"
>
> Just wondering, do we have HS variants of all these boards? If not we
> can just keep am335x-evm.
>

 We don't "technically" have HS vs non-HS versions of any board, the
 boards are the same, the non-HS ones simply have the security features
 locked out. If the silicon they put on any of these boards is not locked
 out then it becomes an HS board.
>>>
>>> Thanks.
>>>

 But, yes, I only know of unlocked AM335x's currently being placed on the
 standard EVMs for now.

>>> okay. Then drop all the other dtbs from the list.
>>>
>>
>> I'm not sure what that would get us, the differences between non-HS and
>> HS have nothing to do with the devices on the boards. This will only
>> create a support burden if someone gets an unlocked Beaglebone for
>> instance. Why limit the *more* feature-full chip? HS chips needs to be
>> thought of as they are, a superset of the non-HS chips, not as a
>> different kind of chip.
> 
> Is this officially supported? Have you tested before posting?
> If no then there should not be any argument for adding this support
> assuming this can possibly be useful or experimental.
> 

I have tested this on the -EVM and will not test this on other boards.
The type of board used is unrelated to adding boot authentication. This
is not a new chip or board, it is a configuration change defconfig only.
(If we could include other defconfigs like we can DTB files then this
defconfig would include the regular defconfig and add a few lines. This
would be useful for merging all the am335x/am43xx defconfig variations
that have started to get rather out of sync with each other).

Think if I added an I2C driver, there would be no need to test it on
every board U-Boot supports, just one, and if it didn't work on some
board that would be a bug against the board, not against the driver.

I hope to at some point merge the HS and non-HS defconfigs, adding any
delta between the two, without a specific reason, only delays this and
will create a future support burden.

Andrew

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

Re: [U-Boot] [PATCH 3/4] Move CONFIG_NAND_MXS to defconfig

[Jagan Teki]

On Wed, Jan 11, 2017 at 12:14 AM, Tom Rini  wrote:
> On Sat, Jan 07, 2017 at 12:42:34PM +0100, Jagan Teki wrote:
>
>> Cc: Stefano Babic 
>> Signed-off-by: Jagan Teki 
> [snip]
>>  33 files changed, 21 insertions(+), 12 deletions(-)
> [snip]
>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>> index 65bb040..682e4e3 100644
>> --- a/drivers/mtd/nand/Kconfig
>> +++ b/drivers/mtd/nand/Kconfig
>> @@ -82,7 +82,6 @@ config NAND_ARASAN
>>
>>  config NAND_MXS
>>   bool "MXS NAND support"
>> - depends on MX6
>>   help
>> This enables NAND driver for the NAND flash controller on the
>> MXS processors.
>
> I think we've got something going wrong here.  Why are we removing the
> depends on line?  I know we can't make this a default y until 'NAND'
> gets migrated, and that's non-trivial.  Thanks!

Yes, I was trying to add 'depends on' but ended-up making more
complex, because there is common config ARCH_MXC like Linux and
when I add supported targets MX5 || MX6 || MX7 || TARGET_TS4800 ||
TARGET_APX4DEVKIT  || TARGET_MX53EVK || TARGET_M53EVK ||
TARGET_MX53LOCO ||
TARGET_MX35PDK || TARGET_VF610TWR || TARGET_FLEA3 ||
TARGET_EMBESTMX6BOARDS || TARGET_WOODBURN_SD || TARGET_MX53SMD ||
TARGET_MX31PDK || TARGET_MX51EVK || TARGET_APF27 || TARGET_WOODBURN ||
TARGET_ADVANTECH_DMS_BA16 || TARGET_MX25PDK || TARGET_ZMX25

it becomes to-worse so opted to remove 'depends on' like few others in Kconfig.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mmc: fsl_esdhc: eMMC boot: CMD_ERR (-ECOMM) in u-boot while accessing SD

[Jagan Teki]

On Sun, Jan 15, 2017 at 5:40 PM, Jagan Teki  wrote:
> Hi,
>
> I've observed the CMD_ERR in U-Boot while accessing SD with boot from
> eMMC on i.MX6 board.
>
> SPL initializing SD as well eMMC controllers
> a) On SD bootmode: from u-boot prompt mmc dev 0 and mmc dev 1 is
> getting probe SD and eMMC
> b) On eMMC bootmode: from u-boot prompt mmc dev 0 is returning with
> -ECOMM in esdhc_send_cmd funtion of fsl_esdhc.c (see the below Log)
> but mmc dev 1 probed eMMC correctly
>
> Log:
> -
> icorem6qdl-rqs> mmc dev 0
>
> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD0
>
> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD8
>
> ECOMM irqstat=0xc0001 CMD8
>
> esdhc_send_cmd: MMC=0x0 addr = 0x2198000, CMD55
>
> ECOMM CMD55
> mmc_init: -70, time 53
>
> With the above log, seems like irqstat has error with
> BIT19 -CIE-Command Index Error
> BIT18-CEBE-Command End Bit Error
>
> Usually once the CMD8 is executed based on the response the controller
> will switch to SD or MMC so further communication commands being
> changes based on that, but here due to controller irqstat error the
> controller is unable to switch to SD here.
>
> The actual working log is [1], this is booting from SD and here is
> full log[2] for booting from eMMC.
>
> [1] https://paste.ubuntu.com/23800820/
> [2] https://paste.ubuntu.com/23800833/
>
> Request for any help.

Did anyone find this issue? any clue?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC Patch V3] drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36xx

[Adam Ford]

On the OMAP36xx/37xx the CONTROL_WKUP_CTRL register has
a field (bit 6) named GPIO_IO_PWRDNZ.  If 0, the IO buffers which
are related to GPIO_126, 127 and 129 are disabled. Some boards may
need this for MMC. After the PBIAS is configured, this bit should
be set high to enable these GPIO pins.

V3:  The OMAP36xx datasheet states to clear this bit before changing
 PBIAS, so this update clears the bit before changing it.  This
 patch also makes the option dependant on MMC_OMAP_HS.
V2:  Make this feature a config option and add it to the MMC section
 of the Kconfig.  This allows the precompiler to only include it
 in a small handfull of OMAP36XX and 37XX boards using MMC1.

V1:  Original submission

Signed-off-by: Adam Ford 

diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
index a71ce5f..e4bd87a 100644
--- a/configs/omap3_logic_defconfig
+++ b/configs/omap3_logic_defconfig
@@ -30,6 +30,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_MMC_OMAP36XX_PINS=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_GADGET=y
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 9ed8da3..7ef2f51 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -148,6 +148,18 @@ config MMC_OMAP_HS
 
  If unsure, say N.
 
+config MMC_OMAP36XX_PINS
+   bool "Enable MMC1 on OMAP36xx/37xx"
+   depends on OMAP34XX && MMC_OMAP_HS
+   help
+ This enables extended-drain in the MMC/SD/SDIO1I/O and
+ GPIO-associated I/O cells (gpio_126, gpio_127, and gpio_129)
+ specific to the OMAP36xx/37xx using MMC1
+
+ If you have a controller with this interface, say Y here.
+
+ If unsure, say N.
+
 config SH_SDHI
bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
depends on RMOBILE
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index b326846..b3f01ca 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -38,6 +38,7 @@
 #include 
 #endif
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -102,19 +103,41 @@ static unsigned char mmc_board_init(struct mmc *mmc)
t2_t *t2_base = (t2_t *)T2_BASE;
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
u32 pbias_lite;
+   u32 cpu_family;
+   u32 wkup_ctrl;
 
pbias_lite = readl(_base->pbias_lite);
pbias_lite &= ~(PBIASLITEPWRDNZ1 | PBIASLITEPWRDNZ0);
+
 #ifdef CONFIG_TARGET_OMAP3_CAIRO
/* for cairo board, we need to set up 1.8 Volt bias level on MMC1 */
pbias_lite &= ~PBIASLITEVMODE0;
 #endif
+
+#ifdef CONFIG_MMC_OMAP36XX_PINS
+   cpu_family = get_cpu_family();
+   if (cpu_family == CPU_OMAP36XX) {
+   wkup_ctrl = readl(OMAP34XX_CTRL_WKUP_CTRL);
+
+   /* Disable the extended drain IO on OMAP36xx before changing 
PBIAS */
+   wkup_ctrl &= ~OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ;
+   writel(wkup_ctrl, OMAP34XX_CTRL_WKUP_CTRL);
+   }
+#endif
writel(pbias_lite, _base->pbias_lite);
 
writel(pbias_lite | PBIASLITEPWRDNZ1 |
PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
_base->pbias_lite);
 
+#ifdef CONFIG_MMC_OMAP36XX_PINS
+   if (cpu_family == CPU_OMAP36XX)
+   /* Enable the extended drain IO on OMAP36xx after changing 
PBIAS */
+   writel(wkup_ctrl |
+   OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ,
+   OMAP34XX_CTRL_WKUP_CTRL);
+#endif
+
writel(readl(_base->devconf0) | MMCSDIO1ADPCLKISEL,
_base->devconf0);
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] sunxi: Add defconfig for the Sinovoip BPI-M2+ board

[Jagan Teki]

On Sun, Jan 8, 2017 at 8:42 PM, Mark Kettenis  wrote:
> The Sinovoip BPI-M2+ is a SBC board based on the H3 SoC.  It has 1G of RAM,
> 8G eMMC, a microSD slot, USB, gigabit Ethernet, AP6212 WiFi, HDMI, etc.

Make these list as line-by-line, please.

> ---
>  configs/Sinovoip_BPI_M2_plus_defconfig | 18 ++

Please update board MAINTAINERS file.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board_init.c: Always use memset()

[Tom Rini]

On Thu, Jan 19, 2017 at 06:57:51AM -0700, Simon Glass wrote:
> On 12 January 2017 at 11:16, Tom Rini  wrote:
> > We can make the code read more easily here by simply using memset()
> > always as when we don't have an optimized version of the function we
> > will still have a version of this function around anyhow.
> >
> > Cc: Simon Glass 
> > Signed-off-by: Tom Rini 
> > ---
> >  common/init/board_init.c | 18 --
> >  1 file changed, 18 deletions(-)
> 
> I recall this didn't work before, but I'm pleased it now does.

Do you recall where, if it was a runtime rather than build time failure?
There was a case or two of build-time failure I had to address.

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] board_init.c: Always use memset()

[Simon Glass]

On 12 January 2017 at 11:16, Tom Rini  wrote:
> We can make the code read more easily here by simply using memset()
> always as when we don't have an optimized version of the function we
> will still have a version of this function around anyhow.
>
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> ---
>  common/init/board_init.c | 18 --
>  1 file changed, 18 deletions(-)

I recall this didn't work before, but I'm pleased it now does.

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

Re: [U-Boot] [PATCH 1/2] ARM: Default to using optimized memset and memcpy routines

[Simon Glass]

On 12 January 2017 at 11:16, Tom Rini  wrote:
> We have long had available optimized versions of the memset and memcpy
> functions that are borrowed from the Linux kernel.  We should use these
> in normal conditions as the speed wins in many workflows outweigh the
> relatively minor size increase.  However, we have a number of places
> where we're simply too close to size limits in SPL and must be able to
> make the size vs performance trade-off in those cases.
>
> Cc: Philippe Reynes 
> Cc: Eric Jarrige 
> Cc: Heiko Schocher 
> Cc: Magnus Lilja 
> Cc: Lokesh Vutla 
> Cc: Chander Kashyap 
> Cc: Akshay Saraswat 
> Cc: Simon Glass 
> Cc: Stefan Roese 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/Kconfig| 22 --
>  arch/arm/lib/Makefile   |  4 ++--
>  common/init/board_init.c|  2 +-
>  configs/apf27_defconfig |  1 +
>  configs/axm_defconfig   |  2 ++
>  configs/corvus_defconfig|  2 ++
>  configs/mx31pdk_defconfig   |  2 ++
>  configs/omap4_sdp4430_defconfig |  2 ++
>  configs/smartweb_defconfig  |  2 ++
>  configs/smdk5250_defconfig  |  2 ++
>  configs/snow_defconfig  |  2 ++
>  configs/spring_defconfig|  2 ++
>  configs/taurus_defconfig|  2 ++
>  configs/x600_defconfig  |  2 ++
>  examples/api/Makefile   |  5 -
>  15 files changed, 48 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH 06/12] SPI: SPL: sunxi: fix 64-bit build

[Simon Glass]

On 15 January 2017 at 05:17, Rask Ingemann Lambertsen  wrote:
> On Fri, Jan 13, 2017 at 01:29:58AM +, Andre Przywara wrote:
>> Addresses passed on to readl and writel are expected to be of the same
>> size as a pointer. Change the parameter types of sunxi_spi0_read_data()
>> to make the compiler happy and allow a warning-free aarch64 compile.
>>
>> Signed-off-by: Andre Przywara 
>
> How about using intptr_t and uintptr_t from include/compiler.h? It will make
> it clearer that these parameters should be able to hold a pointer.
>
>> ---
>>  drivers/mtd/spi/sunxi_spi_spl.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c 
>> b/drivers/mtd/spi/sunxi_spi_spl.c
>> index a24c115..852abd4 100644
>> --- a/drivers/mtd/spi/sunxi_spi_spl.c
>> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
>> @@ -185,14 +185,14 @@ static void spi0_deinit(void)
>>  #define SPI_READ_MAX_SIZE 60 /* FIFO size, minus 4 bytes of the header */
>>
>>  static void sunxi_spi0_read_data(u8 *buf, u32 addr, u32 bufsize,
>> -  u32 spi_ctl_reg,
>> -  u32 spi_ctl_xch_bitmask,
>> -  u32 spi_fifo_reg,
>> -  u32 spi_tx_reg,
>> -  u32 spi_rx_reg,
>> -  u32 spi_bc_reg,
>> -  u32 spi_tc_reg,
>> -  u32 spi_bcc_reg)
>> +  ulong spi_ctl_reg,
>> +  ulong spi_ctl_xch_bitmask,
>> +  ulong spi_fifo_reg,
>> +  ulong spi_tx_reg,
>> +  ulong spi_rx_reg,
>> +  ulong spi_bc_reg,
>> +  ulong spi_tc_reg,
>> +  ulong spi_bcc_reg)
>>  {
>>   writel(4 + bufsize, spi_bc_reg); /* Burst counter (total bytes) */
>>   writel(4, spi_tc_reg);   /* Transfer counter (bytes to send) */

We normally use ulong for addresses in U-Boot.

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

Re: [U-Boot] [PATCH v2 16/18] arm: mvebu: Implement secure boot

[Simon Glass]

On 11 January 2017 at 08:01, Mario Six  wrote:
> The patch implements secure booting for the mvebu architecture.
>
> This includes:
> - The addition of secure headers and all needed signatures and keys in
>   mkimage
> - Commands capable of writing the board's efuses to both write the
>   needed cryptographic data and enable the secure booting mechanism
> - The creation of convenience text files containing the necessary
>   commands to write the efuses
>
> The KAK and CSK keys are expected to reside in the files kwb_kak.key and
> kwb_csk.key (OpenSSL 2048 bit private keys) in the top-level directory.
>
> Signed-off-by: Reinhard Pfau 
> Signed-off-by: Mario Six 
> ---
> Changes in v2:
>
> * Added help text for MVEBU_EFUSE
> * Removed superfluous defined(CONFIG_MVEBU_EFUSE) from
>   arch/arm/mach-mvebu/Makefile
> * Rewrote disable_efuse_program to use clrbits_le32
> * Remove superfluous blank lines from arch/arm/mach-mvebu/include/mach/efuse.h
> ---
>  Makefile |   3 +-
>  arch/arm/mach-mvebu/Kconfig  |  35 ++
>  arch/arm/mach-mvebu/Makefile |   1 +
>  arch/arm/mach-mvebu/efuse.c  | 264 +++
>  arch/arm/mach-mvebu/include/mach/cpu.h   |   2 +
>  arch/arm/mach-mvebu/include/mach/efuse.h |  69 +++
>  doc/README.armada-secureboot | 373 
>  tools/Makefile   |   6 +-
>  tools/kwbimage.c | 744 
> ++-
>  tools/kwbimage.h |  37 ++
>  10 files changed, 1526 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm/mach-mvebu/efuse.c
>  create mode 100644 arch/arm/mach-mvebu/include/mach/efuse.h
>  create mode 100644 doc/README.armada-secureboot
>

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

Re: [U-Boot] [PATCH v2 06/18] lib: tpm: Add command to flush resources

[Simon Glass]

On 11 January 2017 at 08:00, Mario Six  wrote:
>
> This patch adds a function to the TPM library, which allows U-Boot to
> flush resources, e.g. keys, from the TPM.
>
> Signed-off-by: Mario Six 
> ---
> Changes in v2:
>
> * Added U-Boot command for resource flushing ("tpm flush"), and made the
>   command and the library function deactivate-able via config
> ---
>  board/gdsys/p1022/controlcenterd-id.c |  9 -
>  cmd/tpm.c | 70 
> +++
>  drivers/tpm/Kconfig   |  6 +++
>  include/tpm.h | 45 ++
>  lib/tpm.c | 29 +++
>  5 files changed, 150 insertions(+), 9 deletions(-)

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

Re: [U-Boot] [PATCH v2 07/18] core: device: Add dev_get_by_ofname function

[Simon Glass]

Hi,

On 18 January 2017 at 09:23, Stefan Roese  wrote:
> On 11.01.2017 16:00, Mario Six wrote:
>>
>> On boards that use DM, it is sometimes convenient and quicker to get a
>> device
>> via its device tree path, since the devices used in the board
>> initialization
>> routines are usually known beforehand.
>>
>> This patch adds such a convenience function.
>>
>> Signed-off-by: Mario Six 
>> ---
>> Changes in v2:
>>
>> New in v2
>> ---
>>  drivers/core/device.c | 7 +++
>>  include/dm/device.h   | 8 
>>  2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index ed553d7..39d30b3 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -627,6 +627,13 @@ const char *dev_get_uclass_name(struct udevice *dev)
>> return dev->uclass->uc_drv->name;
>>  }
>>
>> +void dev_get_by_ofname(char *ofname, struct udevice *dev)
>> +{
>> +   int offset = fdt_path_offset(gd->fdt_blob, ofname);
>> +
>> +   device_get_global_by_of_offset(offset, );
>> +}
>> +
>>  fdt_addr_t dev_get_addr_index(struct udevice *dev, int index)
>>  {
>>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>> diff --git a/include/dm/device.h b/include/dm/device.h
>> index 9948bd4..402482c 100644
>> --- a/include/dm/device.h
>> +++ b/include/dm/device.h
>> @@ -340,6 +340,14 @@ enum uclass_id device_get_uclass_id(struct udevice
>> *dev);
>>  const char *dev_get_uclass_name(struct udevice *dev);
>>
>>  /**
>> + * dev_get_by_ofname() - find a device via its device tree path
>> + *
>> + * @ofname: Device tree path to use ("/path1/path2/...")
>> + * @dev:The found device or NULL
>> + */
>> +void dev_get_by_ofname(char *ofname, struct udevice *dev);
>
>
> I'm not 100% sure if the function naming is perfect here. Usually
> these dev_get_xxx function work on a "dev" provided by the caller
> and return something else (addr, size). The functions returning a
> "device" are called device_get_xxx. And perhaps its also better stick with
> using "struct udevice **devp" as parameter for
> consistency as the other device_ functions do.
>
> Simon, what do you think?

Agreed.

Also I'm not sure we should be hunting around a path in the DT.
Shouldn't we use compatible strings?

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

Re: [U-Boot] [PATCH] fpga: Use enum for bitstream command types

[Simon Glass]

On 9 January 2017 at 01:21, Michal Simek  wrote:
> Using enum simplify handling of different bitstream command
> types.
>
> Signed-off-by: Michal Simek 
> ---
>
>  cmd/fpga.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)

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

Re: [U-Boot] [PATCH V3 7/7] board: samsung: universal_c210: remove the codes relevant to soft_i2c

[Simon Glass]

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> Removes the codes of soft_i2c.
> There is no usasge for universal_c210, also didn't define
> CONFIG_SOFT_I2C_GPIO_SCL.
> This code seems a dead code.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  board/samsung/universal_c210/universal.c | 11 ---
>  1 file changed, 11 deletions(-)

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

Re: [U-Boot] [PATCH V3 5/7] i2c: s3c24x0: fix the compiler error for exynos4

[Simon Glass]

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> If CONFIG_SYS_I2C_S3C24X0_SLAVE isn't defined, then complie error should
> be occurred.
> This patch is for preventing it.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/i2c/s3c24x0_i2c.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH V3 1/7] ARM: dts: exynos4: use the node's name for i2c

[Simon Glass]

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> Use the node's name for i2c.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  arch/arm/dts/exynos4.dtsi | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH V3 4/7] board: samsung: universal_210: use the driver model for max8998

[Simon Glass]

Hi Jaehoon,

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> Revmoe the "ifndef CONFIG_DM_I2C".
> Intead, use the driver model for max8998.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  board/samsung/universal_c210/universal.c | 169 
> +--
>  1 file changed, 94 insertions(+), 75 deletions(-)
>
> diff --git a/board/samsung/universal_c210/universal.c 
> b/board/samsung/universal_c210/universal.c
> index c3946ee..0645843 100644
> --- a/board/samsung/universal_c210/universal.c
> +++ b/board/samsung/universal_c210/universal.c
> @@ -27,33 +27,21 @@
>  DECLARE_GLOBAL_DATA_PTR;
>
>  unsigned int board_rev;
> +static int init_pmic_lcd(void);
>
>  u32 get_board_rev(void)
>  {
> return board_rev;
>  }
>
> -static int get_hwrev(void)
> +int exynos_power_init(void)
>  {
> -   return board_rev & 0xFF;
> +   return init_pmic_lcd();
>  }
>
> -int exynos_power_init(void)
> +static int get_hwrev(void)
>  {
> -#ifndef CONFIG_DM_I2C /* TODO(maintainer): Convert to driver model */
> -   int ret;
> -
> -   /*
> -* For PMIC the I2C bus is named as I2C5, but it is connected
> -* to logical I2C adapter 0
> -*/
> -   ret = pmic_init(I2C_0);
> -   if (ret)
> -   return ret;
> -
> -   init_pmic_lcd();
> -#endif
> -   return 0;
> +   return board_rev & 0xFF;
>  }
>
>  static unsigned short get_adc_value(int channel)
> @@ -83,23 +71,29 @@ static unsigned short get_adc_value(int channel)
>
>  static int adc_power_control(int on)
>  {
> -#ifndef CONFIG_DM_I2C /* TODO(maintainer): Convert to driver model */
> +   struct udevice *dev;
> int ret;
> -   struct pmic *p = pmic_get("MAX8998_PMIC");
> -   if (!p)
> -   return -ENODEV;
> +   u8 reg;
>
> -   if (pmic_probe(p))
> -   return -1;
> +   ret = pmic_get("max8998-pmic", );
> +   if (ret) {
> +   puts("Failed to get MAX8998!\n");
> +   return ret;
> +   }
>
> -   ret = pmic_set_output(p,
> - MAX8998_REG_ONOFF1,
> - MAX8998_LDO4, !!on);
> +   reg = pmic_reg_read(dev, MAX8998_REG_ONOFF1);
> +   if (on)
> +   reg |= MAX8998_LDO4;
> +   else
> +   reg &= ~MAX8998_LDO4;
> +
> +   ret = pmic_reg_write(dev, MAX8998_REG_ONOFF1, reg);
> +   if (ret) {
> +   puts("MAX8998 LDO setting error\n");
> +   return -EINVAL;
> +   }
>
> -   return ret;
> -#else
> return 0;
> -#endif
>  }
>
>  static unsigned int get_hw_revision(void)
> @@ -147,39 +141,50 @@ static void check_hw_revision(void)
>  #ifdef CONFIG_USB_GADGET
>  static int s5pc210_phy_control(int on)
>  {
> -#ifndef CONFIG_DM_I2C /* TODO(maintainer): Convert to driver model */
> -   int ret = 0;
> -   struct pmic *p = pmic_get("MAX8998_PMIC");
> -   if (!p)
> -   return -ENODEV;
> +   struct udevice *dev;
> +   int ret;
> +   u8 reg;
>
> -   if (pmic_probe(p))
> -   return -1;
> +   ret = pmic_get("max8998-pmic", );
> +   if (ret) {
> +   puts("Failed to get MAX8998!\n");
> +   return ret;
> +   }
>
> if (on) {
> -   ret |= pmic_set_output(p,
> -  MAX8998_REG_BUCK_ACTIVE_DISCHARGE3,
> -  MAX8998_SAFEOUT1, LDO_ON);
> -   ret |= pmic_set_output(p, MAX8998_REG_ONOFF1,
> - MAX8998_LDO3, LDO_ON);
> -   ret |= pmic_set_output(p, MAX8998_REG_ONOFF2,
> - MAX8998_LDO8, LDO_ON);
> +   reg = pmic_reg_read(dev, MAX8998_REG_BUCK_ACTIVE_DISCHARGE3);
> +   reg |= MAX8998_SAFEOUT1;
> +   ret |= pmic_reg_write(dev,
> +   MAX8998_REG_BUCK_ACTIVE_DISCHARGE3, reg);
> +
> +   reg = pmic_reg_read(dev, MAX8998_REG_ONOFF1);
> +   reg |= MAX8998_LDO3;
> +   ret |= pmic_reg_write(dev, MAX8998_REG_ONOFF1, reg);

Can you use pmic_clrsetbits()?

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

Re: [U-Boot] [PATCH V3 6/7] i2c: Kconfig: Add SYS_I2C_S3C24X0 entry

[Simon Glass]

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> Adding Kconfig for SYS_I2C_S3C24X0.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/i2c/Kconfig | 5 +
>  1 file changed, 5 insertions(+)

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

Re: [U-Boot] [PATCH V3 3/7] configs: s5pc210_universal: enable the DM_PMIC and MAX8998

[Simon Glass]

On 8 January 2017 at 22:47, Jaehoon Chung  wrote:
> Enable the CONFIG_DM_PMIC and CONFIG_DM_PMIC_MAX8998.
> s5pc210_universal board is using max8998 pmic.
> To use the i2c/pmic driver model, enable these configurations.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  configs/s5pc210_universal_defconfig | 3 +++
>  1 file changed, 3 insertions(+)

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

Re: [U-Boot] [PATCH 1/2] spl: Move check for SPL_LIBCOMMON support to header

[Simon Glass]

On 6 January 2017 at 12:09, Andrew F. Davis  wrote:
>
> Print statements in SPL depend on lib/common support, so many such
> statements are ifdef'd, move the check to the common.h header and
> remove these inline checks.
>
> Signed-off-by: Andrew F. Davis 
> ---
>  common/spl/spl.c |  2 --
>  common/spl/spl_ext.c |  8 
>  common/spl/spl_fat.c |  6 --
>  common/spl/spl_fit.c |  4 
>  common/spl/spl_mmc.c | 18 --
>  common/spl/spl_sata.c|  2 --
>  common/spl/spl_usb.c |  2 --
>  drivers/mmc/mmc.c| 10 --
>  drivers/mmc/mmc_legacy.c |  2 --
>  include/common.h |  3 ++-
>  10 files changed, 2 insertions(+), 55 deletions(-)

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

Re: [U-Boot] [PATCH 2/2] spl: Remove inline ifdef check for EXT and FAT support

[Simon Glass]

On 11 January 2017 at 09:28, Tom Rini  wrote:
> On Fri, Jan 06, 2017 at 01:35:45PM -0600, Andrew F. Davis wrote:
>
>> These files are only included for build by the make system
>> when CONFIG_SPL_{EXT,FAT}_SUPPORT is enabled, remove the unneed
>> checks for these in the source files.
>>
>> Signed-off-by: Andrew F. Davis 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom

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

Re: [U-Boot] armv8: release slave cores from CPU_RELEASE_ADDR

[Masahiro Yamada]

>> For your information, my own code for spin-table is
>> arch/arm/mach-uniphier/smp_kick_cpus.c
>> this is called from board_init().
>>
> Thanks for the tip, I'll take a look.

I meant

arch/arm/mach-uniphier/arm64/smp_kick_cpus.c


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

Re: [U-Boot] armv8: release slave cores from CPU_RELEASE_ADDR

[Oded Gabbay]

On Thu, Jan 19, 2017 at 2:22 PM, Masahiro Yamada
 wrote:
> 2017-01-17 18:20 GMT+09:00 Oded Gabbay :
>> On Tue, Jan 17, 2017 at 11:07 AM, Masahiro Yamada
>>  wrote:
>>> 2017-01-16 3:30 GMT+09:00 Tom Rini :
 On Wed, Dec 28, 2016 at 01:38:35PM +0200, Oded Gabbay wrote:

> When using ARMv8 with ARMV8_SPIN_TABLE=y, we want the slave cores to
> wait on spin_table_cpu_release_addr, until the Linux kernel will "wake" 
> them
> by writing to that location. The address of spin_table_cpu_release_addr is
> transferred to the kernel using the device tree that is updated by
> spin_table_update_dt().
>
> However, if we also use SPL, then the slave cores are stuck at
> CPU_RELEASE_ADDR instead and as a result, never wake up.
>
> This patch releases the slave cores by writing spl_image->entry_point to
> CPU_RELEASE_ADDR location before the end of the SPL code
> (at jump_to_image_no_args()).
>
> That way, the slave cores will start to execute the u-boot and will get to
> the spin-table code and wait on the correct address
> (spin_table_cpu_release_addr).
>
> Signed-off-by: Oded Gabbay 
> Cc: Simon Glass 
> Reviewed-by: Simon Glass 

 Applied to u-boot/master, thanks!
>>>
>>>
>>> I am the author of the spin table support of U-Boot.
>>>
>>> I should have checked this patch, but unfortunately
>>> I had not noticed it until I saw the commit in the upstream code.
>>>
>>> I am planning to revert it with the following log:
>>>
>>>
>>> Revert "armv8: release slave cores from CPU_RELEASE_ADDR"
>>>
>>> This reverts commit 8c36e99f211104fd7dcbf0669a35a47ce5e154f5.
>>>
>>> There is misunderstanding in commit 8c36e99f2111 ("armv8: release
>>> slave cores from CPU_RELEASE_ADDR").  How to bring the slave cores
>>> into U-Boot proper is platform-specific.  So, it should be cared
>>> in SoC/board files instead of common/spl/spl.c.  As you see SPL
>>> is the acronym of Secondary Program Loader, there is generally
>>> something that runs before SPL (the First one is usually Boot ROM).
>>>
>>> How to wake up slave cores from the Boot ROM is really SoC specific.
>>> So, the intention for the spin table support is to bring the slave
>>> cores into U-Boot proper (this must be done after relocation.  see
>>> below) in an SoC specific manner.  It is still possible to let the
>>> slave cores start from SPL, but it is not a common usecase that should
>>> be supported in the common code.
>>>
>> Then that should be written with CAPITAL letters somewhere in the
>> code/documentation, because what happens now is that in the case all
>> the cores do wake up at the start of the SPL, the slave cores will be
>> forever stuck.
>
> I mentioned "bring in the slaves in a board specific manner"
> in the current Kconfig help.
>
> I meant "U-Boot" as "U-Boot proper" (or aka U-Boot full image)
> instead of SPL.   I reworded to clarify it even more.
>
> http://patchwork.ozlabs.org/patch/717038/
>
> Please let me know if there is something is unclear,
> or you are not convinced with the explanation.
>
I think it is much more clearer now. I sent an r-b to the ML.
>
>
>> Is there a common place to wake up secondary cores / release them from
>> CPU_RELEASE_ADDR ? arch_early_init_r() perhaps ?
>
> Anywhere suitable for you
> if it is run after relocation.
>
> If you look at common/board_r.c, you will see
> various callbacks, board_early_init_r(), board_init(), board_late_init, etc.
>
> For your information, my own code for spin-table is
> arch/arm/mach-uniphier/smp_kick_cpus.c
> this is called from board_init().
>
Thanks for the tip, I'll take a look.
Oded
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm64: spin-table: add more information in Kconfig help

[Oded Gabbay]

On Thu, Jan 19, 2017 at 2:07 PM, Masahiro Yamada
 wrote:
> This feature seems to be sometimes misunderstood.  The intention is
>
> [1] Bring the slaves into U-Boot proper image, not SPL (unless
> you have a special reason).
>
> [2] The operation must be done in a board (SoC) specific manner
> since how to wake the slaves from the Boot ROM is SoC specific.
>
> [3] The slaves must enter U-Boot proper after U-Boot relocates
> itself because the "cpu-release-addr" property points to the
> relocated memory area.
>
> [2] is already explained in the help.  We can make [1] even clearer
> by mentioning "U-Boot proper" instead of "U-Boot".  [3] is missing,
> so I am adding it to the list.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/cpu/armv8/Kconfig | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> index 22dce88..7388eca 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -12,8 +12,11 @@ config ARMV8_SPIN_TABLE
>   To use this feature, you must do:
> - Specify enable-method = "spin-table" in each CPU node in the
>   Device Tree you are using to boot the kernel
> -   - Let secondary CPUs in U-Boot (in a board specific manner)
> - before the master CPU jumps to the kernel
> +   - Bring secondary CPUs into U-Boot proper (in a board specific
> + manner) before the master CPU jumps to the kernel, but *after*
> + relocation.  Otherwise, the master CPU will see a different copy
> + of the spin code, then the secondary CPUs will spin in the
> + unprotected memory area.
>
>   U-Boot automatically does:
> - Set "cpu-release-addr" property of each CPU node
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

This patch is:
Reviewed-by: Oded Gabbay 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] armv8: release slave cores from CPU_RELEASE_ADDR

[Masahiro Yamada]

2017-01-17 18:20 GMT+09:00 Oded Gabbay :
> On Tue, Jan 17, 2017 at 11:07 AM, Masahiro Yamada
>  wrote:
>> 2017-01-16 3:30 GMT+09:00 Tom Rini :
>>> On Wed, Dec 28, 2016 at 01:38:35PM +0200, Oded Gabbay wrote:
>>>
 When using ARMv8 with ARMV8_SPIN_TABLE=y, we want the slave cores to
 wait on spin_table_cpu_release_addr, until the Linux kernel will "wake" 
 them
 by writing to that location. The address of spin_table_cpu_release_addr is
 transferred to the kernel using the device tree that is updated by
 spin_table_update_dt().

 However, if we also use SPL, then the slave cores are stuck at
 CPU_RELEASE_ADDR instead and as a result, never wake up.

 This patch releases the slave cores by writing spl_image->entry_point to
 CPU_RELEASE_ADDR location before the end of the SPL code
 (at jump_to_image_no_args()).

 That way, the slave cores will start to execute the u-boot and will get to
 the spin-table code and wait on the correct address
 (spin_table_cpu_release_addr).

 Signed-off-by: Oded Gabbay 
 Cc: Simon Glass 
 Reviewed-by: Simon Glass 
>>>
>>> Applied to u-boot/master, thanks!
>>
>>
>> I am the author of the spin table support of U-Boot.
>>
>> I should have checked this patch, but unfortunately
>> I had not noticed it until I saw the commit in the upstream code.
>>
>> I am planning to revert it with the following log:
>>
>>
>> Revert "armv8: release slave cores from CPU_RELEASE_ADDR"
>>
>> This reverts commit 8c36e99f211104fd7dcbf0669a35a47ce5e154f5.
>>
>> There is misunderstanding in commit 8c36e99f2111 ("armv8: release
>> slave cores from CPU_RELEASE_ADDR").  How to bring the slave cores
>> into U-Boot proper is platform-specific.  So, it should be cared
>> in SoC/board files instead of common/spl/spl.c.  As you see SPL
>> is the acronym of Secondary Program Loader, there is generally
>> something that runs before SPL (the First one is usually Boot ROM).
>>
>> How to wake up slave cores from the Boot ROM is really SoC specific.
>> So, the intention for the spin table support is to bring the slave
>> cores into U-Boot proper (this must be done after relocation.  see
>> below) in an SoC specific manner.  It is still possible to let the
>> slave cores start from SPL, but it is not a common usecase that should
>> be supported in the common code.
>>
> Then that should be written with CAPITAL letters somewhere in the
> code/documentation, because what happens now is that in the case all
> the cores do wake up at the start of the SPL, the slave cores will be
> forever stuck.

I mentioned "bring in the slaves in a board specific manner"
in the current Kconfig help.

I meant "U-Boot" as "U-Boot proper" (or aka U-Boot full image)
instead of SPL.   I reworded to clarify it even more.

http://patchwork.ozlabs.org/patch/717038/

Please let me know if there is something is unclear,
or you are not convinced with the explanation.



> Is there a common place to wake up secondary cores / release them from
> CPU_RELEASE_ADDR ? arch_early_init_r() perhaps ?

Anywhere suitable for you
if it is run after relocation.

If you look at common/board_r.c, you will see
various callbacks, board_early_init_r(), board_init(), board_late_init, etc.

For your information, my own code for spin-table is
arch/arm/mach-uniphier/smp_kick_cpus.c
this is called from board_init().






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

[U-Boot] [PATCH] arm64: spin-table: add more information in Kconfig help

[Masahiro Yamada]

This feature seems to be sometimes misunderstood.  The intention is

[1] Bring the slaves into U-Boot proper image, not SPL (unless
you have a special reason).

[2] The operation must be done in a board (SoC) specific manner
since how to wake the slaves from the Boot ROM is SoC specific.

[3] The slaves must enter U-Boot proper after U-Boot relocates
itself because the "cpu-release-addr" property points to the
relocated memory area.

[2] is already explained in the help.  We can make [1] even clearer
by mentioning "U-Boot proper" instead of "U-Boot".  [3] is missing,
so I am adding it to the list.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/cpu/armv8/Kconfig | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 22dce88..7388eca 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -12,8 +12,11 @@ config ARMV8_SPIN_TABLE
  To use this feature, you must do:
- Specify enable-method = "spin-table" in each CPU node in the
  Device Tree you are using to boot the kernel
-   - Let secondary CPUs in U-Boot (in a board specific manner)
- before the master CPU jumps to the kernel
+   - Bring secondary CPUs into U-Boot proper (in a board specific
+ manner) before the master CPU jumps to the kernel, but *after*
+ relocation.  Otherwise, the master CPU will see a different copy
+ of the spin code, then the secondary CPUs will spin in the
+ unprotected memory area.
 
  U-Boot automatically does:
- Set "cpu-release-addr" property of each CPU node
-- 
2.7.4

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

Re: [U-Boot] [PATCH][RFT] sunxi: power: axp809.c: Fix aldo1-2 being disabled for mvolt != 0

[Jaehoon Chung]

Hi,

On 01/19/2017 05:53 AM, Rask Ingemann Lambertsen wrote:
> The execution flow is currently like this for aldo_num == 1 or 2:
> 
> int axp_set_aldo(int aldo_num, unsigned int mvolt)
> {
> ...
>   if (mvolt == 0)
>   return pmic_bus_clrbits(AXP809_OUTPUT_CTRL1,
>   AXP809_OUTPUT_CTRL1_ALDO1_EN << (aldo_num - 1));
> ...
>   return pmic_bus_clrbits(AXP809_OUTPUT_CTRL1,
>   AXP809_OUTPUT_CTRL1_ALDO1_EN << (aldo_num - 1));
>  }
> 
> I.e. aldo1 and aldo2 will always be disabled. This patch fixes it by
> setting (rather than clearing) the enable bit when mvolt != 0.
> 
> Signed-off-by: Rask Ingemann Lambertsen 
> Fixes: 795857df413a ("sunxi: power: add AXP809 support")

It makes sense. if someone can test it, it's more better. :)
I can't access u-boot-pmic git repository yet.
So if possible, i will make the "pmic" branch on u-boot-mmc.

And i will apply the patches relevant to Power.

Best Regards,
Jaehoon Chung

> ---
> 
> This patch needs someone to test it. I can't do so myself because I don't
> have any hardware with an AXP809 PMIC. I just happened to spot the bug
> when looking at the code.
> 
>  drivers/power/axp809.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/axp809.c b/drivers/power/axp809.c
> index c5b608d..5b5cb36 100644
> --- a/drivers/power/axp809.c
> +++ b/drivers/power/axp809.c
> @@ -143,7 +143,7 @@ int axp_set_aldo(int aldo_num, unsigned int mvolt)
>   if (aldo_num == 3)
>   return pmic_bus_setbits(AXP809_OUTPUT_CTRL2,
>   AXP809_OUTPUT_CTRL2_ALDO3_EN);
> - return pmic_bus_clrbits(AXP809_OUTPUT_CTRL1,
> + return pmic_bus_setbits(AXP809_OUTPUT_CTRL1,
>   AXP809_OUTPUT_CTRL1_ALDO1_EN << (aldo_num - 1));
>  }
>  
> 

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

Re: [U-Boot] [PATCH v2 10/10] mmc: zynq: Add fdt max-frequency support

[Jaehoon Chung]

On 01/18/2017 12:27 AM, stefan.herbrechtsme...@weidmueller.com wrote:
> From: Stefan Herbrechtsmeier 
> 
> The maximum supported peripheral clock frequency of the zynq depends on
> the IO routing. The MIO and EMIO support a maximum frequency of 50 MHz
> respectively 25 MHz. Use the max-frequency value of the device tree to
> determine the maximal supported peripheral clock frequency.
> 
> Signed-off-by: Stefan Herbrechtsmeier 
> Acked-by: Michal Simek 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> 
> ---
> 
> Changes in v2:
> - Add patch to add fdt max-frequency support to zynq mmc driver
> 
>  drivers/mmc/zynq_sdhci.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index c73a4d3..28cedf0 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -14,6 +14,8 @@
>  #include 
>  #include 
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  #ifndef CONFIG_ZYNQ_SDHCI_MIN_FREQ
>  # define CONFIG_ZYNQ_SDHCI_MIN_FREQ  0
>  #endif
> @@ -21,6 +23,7 @@
>  struct arasan_sdhci_plat {
>   struct mmc_config cfg;
>   struct mmc mmc;
> + unsigned int f_max;
>  };
>  
>  static int arasan_sdhci_probe(struct udevice *dev)
> @@ -60,7 +63,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
>  
>   host->max_clk = clock;
>  
> - ret = sdhci_setup_cfg(>cfg, host, CONFIG_ZYNQ_SDHCI_MAX_FREQ,
> + ret = sdhci_setup_cfg(>cfg, host, plat->f_max,
> CONFIG_ZYNQ_SDHCI_MIN_FREQ);
>   host->mmc = >mmc;
>   if (ret)
> @@ -74,11 +77,15 @@ static int arasan_sdhci_probe(struct udevice *dev)
>  
>  static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
>  {
> + struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
>   struct sdhci_host *host = dev_get_priv(dev);
>  
>   host->name = dev->name;
>   host->ioaddr = (void *)dev_get_addr(dev);
>  
> + plat->f_max = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> + "max-frequency", CONFIG_ZYNQ_SDHCI_MAX_FREQ);
> +
>   return 0;
>  }
>  
> 

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

Re: [U-Boot] [PATCH v2 09/10] mmc: zynq: Determine base clock frequency via clock framework

[Jaehoon Chung]

On 01/18/2017 12:27 AM, stefan.herbrechtsme...@weidmueller.com wrote:
> From: Stefan Herbrechtsmeier 
> 
> The zynq_sdhci controller driver use CONFIG_ZYNQ_SDHCI_MAX_FREQ as base
> clock frequency but this clock is not fixed and depends on the hardware
> configuration. Additionally the value of CONFIG_ZYNQ_SDHCI_MAX_FREQ
> doesn't match the real base clock frequency of SDIO_FREQ. Use the clock
> framework to determine the frequency at run time.
> 
> Signed-off-by: Stefan Herbrechtsmeier 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> 
> ---
> 
> Changes in v2:
> - Add patch to determine base clock frequency of zynq mmc driver via
>   clock framework
> 
>  drivers/mmc/zynq_sdhci.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index 69efa38..c73a4d3 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -6,6 +6,7 @@
>   * SPDX-License-Identifier:  GPL-2.0+
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -27,8 +28,29 @@ static int arasan_sdhci_probe(struct udevice *dev)
>   struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
>   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>   struct sdhci_host *host = dev_get_priv(dev);
> + struct clk clk;
> + unsigned long clock;
>   int ret;
>  
> + ret = clk_get_by_index(dev, 0, );
> + if (ret < 0) {
> + dev_err(dev, "failed to get clock\n");
> + return ret;
> + }
> +
> + clock = clk_get_rate();
> + if (IS_ERR_VALUE(clock)) {
> + dev_err(dev, "failed to get rate\n");
> + return clock;
> + }
> + debug("%s: CLK %ld\n", __func__, clock);
> +
> + ret = clk_enable();
> + if (ret && ret != -ENOSYS) {
> + dev_err(dev, "failed to enable clock\n");
> + return ret;
> + }
> +
>   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD |
>  SDHCI_QUIRK_BROKEN_R1B;
>  
> @@ -36,9 +58,9 @@ static int arasan_sdhci_probe(struct udevice *dev)
>   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
>  #endif
>  
> - host->max_clk = CONFIG_ZYNQ_SDHCI_MAX_FREQ;
> + host->max_clk = clock;
>  
> - ret = sdhci_setup_cfg(>cfg, host, 0,
> + ret = sdhci_setup_cfg(>cfg, host, CONFIG_ZYNQ_SDHCI_MAX_FREQ,
> CONFIG_ZYNQ_SDHCI_MIN_FREQ);
>   host->mmc = >mmc;
>   if (ret)
> 

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

Re: [U-Boot] [PATCH 14/20] mmc: Print error code for mmc_complete_init failure

[Jaehoon Chung]

Hi,

On 01/10/2017 07:18 PM, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Print the error code for non-zero (failure case) instead
> of making debug statement without any condition, this
> usually gives proper clue in failure condition.
> 
> Log:
> ---
> MMC:   FSL_SDHC: 0
> mmc_init: -70, time 38
> *** Warning - MMC init failed, using default environment
> 
> Cc: Jaehoon Chung 
> Signed-off-by: Jagan Teki 

I didn't see the other patches..but i picked this patch on u-boot-mmc.

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/mmc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 9f8368a..3648950 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1751,7 +1751,9 @@ int mmc_init(struct mmc *mmc)
>  
>   if (!err)
>   err = mmc_complete_init(mmc);
> - debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
> + if (err)
> + printf("%s: %d, time %lu\n", __func__, err, get_timer(start));
> +
>   return err;
>  }
>  
> 

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

Re: [U-Boot] [RFC Patch V2] drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36XX

[Jaehoon Chung]

Hi Adam,

On 01/12/2017 06:07 AM, Adam Ford wrote:
> On the OMAP36xx (and 37xx) the CONTROL_WKUP_CTRL register has
> a field (bit 6) named GPIO_IO_PWRDNZ.  If 0, the IO buffers which
> are related to the MMC are disabled. After the PBIAS is configured,
> this bit should be set high to enable the MMC port.
> 
> V2:  Make this feature a config option and add it to the MMC section
>  of the Kconfig.  This allows the precompiler to only include it
>  in a small handfull of OMAP36XX and 37XX boards using MMC1.
> 
> V1:  Original submission
> 
> Signed-off-by: Adam Ford 

Sorry for late, Could you resend the patch on latest?
Current patch has conflict..

Best Regards,
Jaehoon Chung

> 
> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> index ac1a6a3..bd5f1a8 100644
> --- a/configs/omap3_logic_defconfig
> +++ b/configs/omap3_logic_defconfig
> @@ -15,6 +15,7 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_ASKENV=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_MMC=y
> +CONFIG_MMC_OMAP36XX_PINS=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_I2C=y
>  # CONFIG_CMD_FPGA is not set
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index c3462ab..d6fcf7f 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -204,6 +204,17 @@ config MMC_SDHCI_SPEAR
>  
> If unsure, say N.
>  
> +config MMC_OMAP36XX_PINS
> + bool "Enable MMC1 on OMAP36XX/37XX"
> + depends on OMAP34XX
> + help
> +   This enables extended-drain in the MMC/SD/SDIO1I/O and 
> +   GPIO-associated I/O cells (gpio_126, gpio_127, and gpio_129)
> +   specific to the OMAP36XX/37XX using MMC1
> +
> +   If you have a controller with this interface, say Y here.
> +
> +   If unsure, say N.
>  endif
>  
>  endmenu
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index 0a1ee40..a4720e1 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -38,6 +38,7 @@
>  #include 
>  #endif
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -115,6 +116,13 @@ static unsigned char mmc_board_init(struct mmc *mmc)
>   PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
>   _base->pbias_lite);
>  
> +#ifdef CONFIG_MMC_OMAP36XX_PINS
> + if (get_cpu_family() == CPU_OMAP36XX)
> + writel(readl(OMAP34XX_CTRL_WKUP_CTRL) |
> + OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ,
> + OMAP34XX_CTRL_WKUP_CTRL);
> +#endif
> +
>   writel(readl(_base->devconf0) | MMCSDIO1ADPCLKISEL,
>   _base->devconf0);
>  
> 

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

Re: [U-Boot] [PATCH 1/2] armv8: calculate __bss_size in u-boot-spl.lds

[Masahiro Yamada]

Hi.

(CCing Simon because he wrote the code addressed in this discussion.)


2017-01-17 18:27 GMT+09:00 Oded Gabbay :
> Hi Mashiro,
> Could you please also take a look at the patch I sent to add the
> missing __bss_size ?
>
> Thanks,
> Oded
>
> On Mon, Dec 26, 2016 at 4:20 PM, Oded Gabbay  wrote:
>> This patch adds a missing __bss_size symbol to the default armv8
>> u-boot-spl.lds file.
>> Makefile.spl relies on __bss_size to be present when it creates the SPL
>> image. It uses that symbol to create a pad file that will be used to place
>> the dtb after the bss section.
>> In ARMv8 default u-boot-spl.lds, __bss_size was missing and therefore, the
>> pad file was always 0. As a result, the dtb was placed after
>> _image_binary_end, which caused a failure when loading it inside the SPL.
>>
>> Signed-off-by: Oded Gabbay 
>> Cc: Albert Aribaud 
>> ---
>>  arch/arm/cpu/armv8/u-boot-spl.lds | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
>> b/arch/arm/cpu/armv8/u-boot-spl.lds
>> index cc427c3..e7799cc 100644
>> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
>> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
>> @@ -70,6 +70,7 @@ SECTIONS
>> KEEP(*(.__bss_end));
>> } >.sdram
>>
>> +   __bss_size = __bss_end - _image_binary_end;
>> /DISCARD/ : { *(.dynsym) }
>> /DISCARD/ : { *(.dynstr*) }
>> /DISCARD/ : { *(.dynamic*) }



This patch seems wrong.


This linker script seems to support separate two memory regions.

MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
  LENGTH = CONFIG_SPL_MAX_SIZE }
MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
  LENGTH = CONFIG_SPL_BSS_MAX_SIZE }


_image_binary_end is the end of the first region (.sram),
__bss_end is the end of the second region (.sdram).

So, with your patch,

   __bss_size = (gap between .sram and .sdram) + (size of .bss)

This will append really big padding there is a gap between the two regions.
(at least, it will break my boards.)


If you take a look at fdtdec_setup(),

#  ifdef CONFIG_SPL_BUILD
/* FDT is at end of BSS unless it is in a different memory region */
if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
 gd->fdt_blob = (ulong *)&_image_binary_end;
else
 gd->fdt_blob = (ulong *)&__bss_end;

I think you are supposed to enable CONFIG_SPL_SEPARATE_BSS
if you want to use SPL_OF_CONTROL on your arm64 boards.



Checking the following commit will help you.


commit 10172962479ddd6609101fdb83bde66c0719852c
Author: Simon Glass 
Date:   Sat Oct 17 19:41:19 2015 -0600

dm: spl: Support device tree when BSS is in a different section

At present in SPL we place the device tree immediately after BSS. This
avoids needing to copy it out of the way before BSS can be used. However on
some boards BSS is not placed with the image - e.g. it can be in RAM if
available.

Add an option to tell U-Boot that the device tree should be placed at the
end of the image binary (_image_binary_end) instead of at the end of BSS.

Note: A common reason to place BSS in RAM is to support the FAT filesystem.
We should update the code so that it does not use so much BSS.

Signed-off-by: Simon Glass 
Signed-off-by: Michal Simek 


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

Re: [U-Boot] [PATCH v4] mmc: sdhci: Distinguish between base clock and maximum peripheral frequency

[Jaehoon Chung]

Hi Stefan,

On 01/17/2017 11:58 PM, stefan.herbrechtsme...@weidmueller.com wrote:
> From: Stefan Herbrechtsmeier 
> 
> The sdhci controller assumes that the base clock frequency is fully supported 
> by
> the peripheral and doesn't support hardware limitations. The Linux kernel
> distinguishes between base clock (max_clk) of the host controller and maximum
> frequency (f_max) of the card interface. Use the same differentiation and 
> allow
> the platform to constrain the peripheral interface.
> 
> Signed-off-by: Stefan Herbrechtsmeier 

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> ---
> 
> Changes in v4:
> - Remove zynq specific patches
> - Rebase onto latest master
> 
> Changes in v3:
> - Rename arguments of sdhci_setup_cfg function from max_clk/min_clk to 
> f_max/f_min
> 
> Changes in v2:
> - None
> 
>  drivers/mmc/atmel_sdhci.c|  7 +--
>  drivers/mmc/bcm2835_sdhci.c  |  3 ++-
>  drivers/mmc/ftsdc021_sdhci.c |  3 ++-
>  drivers/mmc/kona_sdhci.c |  3 ++-
>  drivers/mmc/msm_sdhci.c  |  2 ++
>  drivers/mmc/mv_sdhci.c   |  3 ++-
>  drivers/mmc/pci_mmc.c|  1 +
>  drivers/mmc/pic32_sdhci.c|  4 +++-
>  drivers/mmc/rockchip_sdhci.c |  4 ++--
>  drivers/mmc/s5p_sdhci.c  |  5 +++--
>  drivers/mmc/sdhci.c  | 34 ++
>  drivers/mmc/zynq_sdhci.c |  4 +++-
>  include/sdhci.h  | 13 +++--
>  13 files changed, 52 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> index 6654b54..62cb242 100644
> --- a/drivers/mmc/atmel_sdhci.c
> +++ b/drivers/mmc/atmel_sdhci.c
> @@ -35,8 +35,9 @@ int atmel_sdhci_init(void *regbase, u32 id)
>   free(host);
>   return -ENODEV;
>   }
> + host->max_clk = max_clk;
>  
> - add_sdhci(host, max_clk, min_clk);
> + add_sdhci(host, 0, min_clk);
>  
>   return 0;
>  }
> @@ -95,7 +96,9 @@ static int atmel_sdhci_probe(struct udevice *dev)
>   if (!max_clk)
>   return -EINVAL;
>  
> - ret = sdhci_setup_cfg(>cfg, host, max_clk, ATMEL_SDHC_MIN_FREQ);
> + host->max_clk = max_clk;
> +
> + ret = sdhci_setup_cfg(>cfg, host, 0, ATMEL_SDHC_MIN_FREQ);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
> index cb2bd40..29c2a85 100644
> --- a/drivers/mmc/bcm2835_sdhci.c
> +++ b/drivers/mmc/bcm2835_sdhci.c
> @@ -181,10 +181,11 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
>   host->ioaddr = (void *)(unsigned long)regbase;
>   host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B |
>   SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_NO_HISPD_BIT;
> + host->max_clk = emmc_freq;
>   host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
>   host->ops = _ops;
>  
> - add_sdhci(host, emmc_freq, MIN_FREQ);
> + add_sdhci(host, 0, MIN_FREQ);
>  
>   return 0;
>  }
> diff --git a/drivers/mmc/ftsdc021_sdhci.c b/drivers/mmc/ftsdc021_sdhci.c
> index 6e9fefa..4940ccb 100644
> --- a/drivers/mmc/ftsdc021_sdhci.c
> +++ b/drivers/mmc/ftsdc021_sdhci.c
> @@ -27,7 +27,8 @@ int ftsdc021_sdhci_init(u32 regbase)
>   host->name = "FTSDC021";
>   host->ioaddr = (void __iomem *)regbase;
>   host->quirks = 0;
> - add_sdhci(host, freq, 0);
> + host->max_clk = freq;
> + add_sdhci(host, 0, 0);
>  
>   return 0;
>  }
> diff --git a/drivers/mmc/kona_sdhci.c b/drivers/mmc/kona_sdhci.c
> index 549f6bc..ddd821b 100644
> --- a/drivers/mmc/kona_sdhci.c
> +++ b/drivers/mmc/kona_sdhci.c
> @@ -121,12 +121,13 @@ int kona_sdhci_init(int dev_index, u32 min_clk, u32 
> quirks)
>   host->name = "kona-sdhci";
>   host->ioaddr = reg_base;
>   host->quirks = quirks;
> + host->max_clk = max_clk;
>  
>   if (init_kona_mmc_core(host)) {
>   free(host);
>   return -EINVAL;
>   }
>  
> - add_sdhci(host, max_clk, min_clk);
> + add_sdhci(host, 0, min_clk);
>   return ret;
>  }
> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> index f33714b..1db683d 100644
> --- a/drivers/mmc/msm_sdhci.c
> +++ b/drivers/mmc/msm_sdhci.c
> @@ -96,6 +96,8 @@ static int msm_sdc_probe(struct udevice *dev)
>  
>   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
>  
> + host->max_clk = 0;
> +
>   /* Init clocks */
>   ret = msm_sdc_clk_init(dev);
>   if (ret)
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index e388ad1..69aa87b 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -77,6 +77,7 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 
> min_clk, u32 quirks)
>   host->name = MVSDH_NAME;
>   host->ioaddr = (void *)regbase;
>   host->quirks = quirks;
> + host->max_clk = max_clk;
>  #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
>   

[U-Boot] [PATCH] cmd: ubi: allow '-' to specify maximum volume size

[Ladislav Michl]

Currently maximum volume size can be specified only if no other
arguments are used. Use '-' placeholder as volume size to allow
maximum volume size to be specified together with volume id and
type.

Signed-off-by: Ladislav Michl 
---
 cmd/ubi.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/cmd/ubi.c b/cmd/ubi.c
index 7d0d7e7a80..efc43ffde9 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -600,7 +600,8 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
/* E.g., create volume size */
if (argc == 4) {
-   size = simple_strtoull(argv[3], NULL, 16);
+   if (argv[3][0] != '-')
+   size = simple_strtoull(argv[3], NULL, 16);
argc--;
}
/* Use maximum available size */
@@ -691,8 +692,9 @@ U_BOOT_CMD(
" - Display volume and ubi layout information\n"
"ubi check volumename"
" - check if volumename exists\n"
-   "ubi create[vol] volume [size] [type] [id]"
-   " - create volume name with size\n"
+   "ubi create[vol] volume [size] [type] [id]\n"
+   " - create volume name with size ('-' for maximum"
+   " available size)\n"
"ubi write[vol] address volume size"
" - Write volume from address with size\n"
"ubi write.part address volume size [fullsize]\n"
-- 
2.11.0

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

Re: [U-Boot] rockchip: rk3288: Possible regression in sdram setup

[Romain Perier]

Hi,

no ideas ?

I can try another solution if you want.

Regards,

Romain


Le 09/01/2017 à 09:23, Romain Perier a écrit :

Hi,


Le 09/01/2017 à 08:20, Kever Yang a écrit :


On 01/06/2017 06:52 PM, Romain Perier wrote:

Add Rockchip Engineers to Cc:


Le 06/01/2017 à 11:28, Romain Perier a écrit :

Hello,

I have a strange behaviour with the SPL on rk3288.

When I build u-boot-rockchip master for the rock2 
(rock2_defconfig), I can easily start u-boot SPL and u-boot from an 
sdcard (the emmc boot partition is erased so my board starts in 
maskrom mode by default) without any issues.



Now, I load uboot SPL and uboot over usb:

- I power up the board

- I generate an image for the bootrom:

# tools/mkimage -n rk3288 -T rkimage -d spl/u-boot-spl-dtb.bin out

- I uploaded this image via usb to the board

# cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | 
../tools/rkflashtool/rkflashtool l


I get no output from the SPL. I have investigated and found that it 
is caused by sdram_rk3288.c: sdram_init(). More especially by the 
function phy_pctrl_reset(). I enabled EARLY_UART and added 2 
printascii() in this function. This functions hangs in the second 
for loop. I hacked this function locally, I reduce the number of 
iterations from 4 to 3 then I added 2 uart outputs to this function 
and "OH!":   it works, I get the following output:


pctrl_reset:for
pctrl_reset:end for
pctrl_reset:for
pctrl_reset:end for

U-Boot SPL 2016.11-08675-ga4ae4ddda3-dirty (Jan 06 2017 - 10:35:41)



Now, if I remove my printascii() functions completly, it's no 
longer working. Which suggests that it might have something to do 
with busy wait delays... (I could be wrong)


From the sdram setup point of view, I don't see a real difference 
between an SPL loaded from sdcard and an SPL loaded via usb.


Rockchip guys: Would you have an idea about the problem ?



SPL load from sdcard/emmc and loaded via usb, one difference may be 
cpu frequency.


I agree that the udelay() may not correct, could you help to do:
- delay 1 S or more with udelay(), then we can see if it's correct, I 
don't know how the udelay is implement on rk3288,

if it's using ARM generic timer, then it's related to cpu frequency;
- using rockchip_udelay() instead of udelay(), this interface is 
using rktimer, it should be correct.


I have just tried both solutions, unfortunately, it did not help (same 
issues)


Thanks,
Romain



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

[U-Boot] [PATCH] bootm: qnx: Disable data cache before booting QNX image

[Emmanuel Vadot]

Instead of disabling the data cache in the bootelf command, disabling
it in the do_bootm_qnxelf function.
Some ELF binary might want the cache enabled.

Signed-off-by: Emmanuel Vadot 
---
 cmd/elf.c | 11 ---
 common/bootm_os.c | 12 
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/cmd/elf.c b/cmd/elf.c
index 5190cc6c0f..e4c6535111 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -110,22 +110,11 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, 
char * const[]),
unsigned long ret;
 
/*
-* QNX images require the data cache is disabled.
-* Data cache is already flushed, so just turn it off.
-*/
-   int dcache = dcache_status();
-   if (dcache)
-   dcache_disable();
-
-   /*
 * pass address parameter as argv[0] (aka command name),
 * and all remaining args
 */
ret = entry(argc, argv);
 
-   if (dcache)
-   dcache_enable();
-
return ret;
 }
 
diff --git a/common/bootm_os.c b/common/bootm_os.c
index e3f5a46412..6e463c317e 100644
--- a/common/bootm_os.c
+++ b/common/bootm_os.c
@@ -353,6 +353,7 @@ static int do_bootm_qnxelf(int flag, int argc, char * const 
argv[],
 {
char *local_args[2];
char str[16];
+   int dcache;
 
if (flag != BOOTM_STATE_OS_GO)
return 0;
@@ -367,8 +368,19 @@ static int do_bootm_qnxelf(int flag, int argc, char * 
const argv[],
sprintf(str, "%lx", images->ep); /* write entry-point into string */
local_args[0] = argv[0];
local_args[1] = str;/* and provide it via the arguments */
+
+   /*
+* QNX images require the data cache is disabled.
+*/
+   dcache = dcache_status();
+   if (dcache)
+   dcache_disable();
+
do_bootelf(NULL, 0, 2, local_args);
 
+   if (dcache)
+   dcache_enable();
+
return 1;
 }
 #endif
-- 
2.11.0

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

[U-Boot] [PATCH 1/2] status_led: Kconfig migration - introduction

[Uri Mashiach]

Move all of the status LED feature to drivers/led/Kconfig.
doc/README.LED updated to reflect the Kconfig implementation.

Tested boards: CL-SOM-AM57x, CM-T335

Signed-off-by: Uri Mashiach 
---
 README  |   8 +-
 doc/README.LED  |  58 +-
 drivers/led/Kconfig | 323 +++-
 3 files changed, 355 insertions(+), 34 deletions(-)

diff --git a/README b/README
index 7e0dd35..a95348a 100644
--- a/README
+++ b/README
@@ -2033,7 +2033,7 @@ The following options need to be configured:
 
A byte containing the id of the VLAN.
 
-- Status LED:  CONFIG_STATUS_LED
+- Status LED:  CONFIG_LED_STATUS
 
Several configurations allow to display the current
status using a LED. For instance, the LED will blink
@@ -2041,15 +2041,15 @@ The following options need to be configured:
soon as a reply to a BOOTP request was received, and
start blinking slow once the Linux kernel is running
(supported by a status LED driver in the Linux
-   kernel). Defining CONFIG_STATUS_LED enables this
+   kernel). Defining CONFIG_LED_STATUS enables this
feature in U-Boot.
 
Additional options:
 
-   CONFIG_GPIO_LED
+   CONFIG_LED_STATUS_GPIO
The status LED can be connected to a GPIO pin.
In such cases, the gpio_led driver can be used as a
-   status LED backend implementation. Define CONFIG_GPIO_LED
+   status LED backend implementation. Define CONFIG_LED_STATUS_GPIO
to include the gpio_led driver in the U-Boot binary.
 
CONFIG_GPIO_LED_INVERTED_TABLE
diff --git a/doc/README.LED b/doc/README.LED
index c3bcb3a..7aa95bd 100644
--- a/doc/README.LED
+++ b/doc/README.LED
@@ -5,48 +5,48 @@ This README describes the status LED API.
 
 The API is defined by the include file include/status_led.h
 
-The first step is to define CONFIG_STATUS_LED in the board config file.
+The first step is to enable CONFIG_LED_STATUS in menuconfig:
+> Device Drivers > LED Support.
 
-If the LED support is only for a single board, define CONFIG_BOARD_SPECIFIC_LED
-in the board config file.
+If the LED support is only for specific board, enable
+CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig.
 
-At a minimum, these macros must be defined at
-STATUS_LED_BIT
-STATUS_LED_STATE
-STATUS_LED_PERIOD
+Status LEDS 0 to 5 are enabled by the following configurations at menuconfig:
+CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5
 
-If there are multiple status LED's define
-STATUS_LED_BIT
-STATUS_LED_STATE
-STATUS_LED_PERIOD
+The following should be configured for each of the enabled LEDs:
+CONFIG_STATUS_LED_BIT
+CONFIG_STATUS_LED_STATE
+CONFIG_STATUS_LED_FREQ
+Where  is an integer 1 through 5 (empty for 0).
 
-Where  can a integer 1 through 3.
-
-STATUS_LED_BIT is passed into the __led_* functions to identify which LED is
-being acted on.  As such, the value choose must be unique with with respect to
-the other STATUS_LED_BIT's.  Mapping the value to a physical LED is the
+CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which 
LED
+is being acted on. As such, the value choose must be unique with with respect 
to
+the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the
 reponsiblity of the __led_* function.
 
-STATUS_LED_STATE is the initial state of the LED. It should be set to one of
-these values: STATUS_LED_OFF or STATUS_LED_ON.
+CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to 
one
+of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON.
 
-STATUS_LED_PERIOD is how long is the LED blink period.  This usually set to
-(CONFIG_SYS_HZ / ) where  is the frequency of the blink. Typical values
-range from 2 to 10.
+CONFIG_STATUS_LED_FREQ determines the LED blink frequency.
+Values range from 2 to 10.
 
 Some other LED macros
+-
 
-STATUS_LED_BOOT is the LED to light when the board is booting.  This must be a
-valid STATUS_LED_BIT value.
+CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting.
+This must be a valid LED number (0-5).
 
-STATUS_LED_RED is the red LED.  It is used signal errors. This must be a valid
-STATUS_LED_BIT value. Other similar color LED's are STATUS_LED_YELLOW and
-STATUS_LED_BLUE.
+CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be
+a valid LED number (0-5). Other similar color LED's macros are
+CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE.
 
-These board must define these functions
+General LED functions
+-
+The following functions should be defined:
 
-__led_init is called once to initialize the LED to STATUS_LED_STATE. One time
-start up code should be placed here.
+__led_init is called once to 

[U-Boot] [PATCH 2/2] status_led: Kconfig migration

[Uri Mashiach]

Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.

TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.

Tested boards: CL-SOM-AM57x, CM-T335

Signed-off-by: Uri Mashiach 
---
 arch/arm/cpu/arm920t/ep93xx/led.c| 35 ++---
 arch/powerpc/include/asm/status_led.h| 10 ++--
 arch/powerpc/lib/interrupts.c|  6 +--
 board/BuS/eb_cpu5282/eb_cpu5282.c|  2 +-
 board/bf533-stamp/bf533-stamp.c  | 28 ++
 board/compulab/cm_t335/cm_t335.c |  4 +-
 board/compulab/cm_t35/cm_t35.c   |  4 +-
 board/compulab/cm_t3517/cm_t3517.c   |  4 +-
 board/corscience/tricorder/led.c | 26 +-
 board/corscience/tricorder/tricorder.c   |  6 +--
 board/isee/igep00x0/igep00x0.c   |  4 +-
 board/motionpro/motionpro.c  | 45 +++-
 board/olimex/mx23_olinuxino/mx23_olinuxino.c |  6 +--
 board/samtec/vining_fpga/socfpga.c   |  4 +-
 board/ti/beagle/Makefile |  2 +-
 board/ti/beagle/beagle.c |  6 +--
 board/ti/beagle/led.c| 14 ++---
 cmd/Makefile |  2 +-
 cmd/ide.c|  2 +-
 cmd/led.c| 69 -
 common/board_r.c |  8 +--
 configs/TQM823L_defconfig|  7 +++
 configs/TQM823M_defconfig|  7 +++
 configs/TQM850L_defconfig|  7 +++
 configs/TQM850M_defconfig|  7 +++
 configs/TQM855L_defconfig|  7 +++
 configs/TQM855M_defconfig|  7 +++
 configs/TQM860L_defconfig|  7 +++
 configs/TQM860M_defconfig|  7 +++
 configs/TQM862L_defconfig|  7 +++
 configs/TQM862M_defconfig|  7 +++
 configs/TQM866M_defconfig|  7 +++
 configs/TQM885D_defconfig|  7 +++
 configs/cl-som-am57x_defconfig   |  5 ++
 configs/cm_t335_defconfig|  6 +++
 configs/cm_t3517_defconfig   |  7 +++
 configs/cm_t35_defconfig |  7 +++
 configs/eb_cpu5282_defconfig |  6 +++
 configs/eb_cpu5282_internal_defconfig|  6 +++
 configs/edb9315a_defconfig   | 12 +
 configs/igep0020_defconfig   |  7 +++
 configs/igep0030_defconfig   |  7 +++
 configs/motionpro_defconfig  | 10 
 configs/mx23_olinuxino_defconfig |  8 +++
 configs/omap3_beagle_defconfig   | 11 
 configs/socfpga_vining_fpga_defconfig| 11 
 configs/tqma6s_wru4_mmc_defconfig| 20 
 configs/tricorder_defconfig  | 11 
 configs/tricorder_flash_defconfig| 11 
 configs/v38b_defconfig   |  6 +++
 drivers/misc/Makefile|  4 +-
 drivers/misc/gpio_led.c  | 26 +-
 drivers/misc/pca9551_led.c   |  2 +-
 drivers/misc/status_led.c| 76 ++--
 include/common.h |  2 +-
 include/configs/PATI.h   |  2 -
 include/configs/TQM823L.h|  6 ---
 include/configs/TQM823M.h|  6 ---
 include/configs/TQM850L.h|  2 -
 include/configs/TQM850M.h|  2 -
 include/configs/TQM855L.h|  2 -
 include/configs/TQM855M.h|  2 -
 include/configs/TQM860L.h|  2 -
 include/configs/TQM860M.h|  2 -
 include/configs/TQM862L.h|  2 -
 include/configs/TQM862M.h|  2 -
 include/configs/TQM866M.h|  2 -
 include/configs/TQM885D.h|  2 -
 include/configs/bf526-ezbrd.h| 16 --
 include/configs/bf533-stamp.h| 16 --
 include/configs/cl-som-am57x.h   | 11 
 include/configs/cm_t335.h|  7 ---
 include/configs/cm_t35.h | 10 +---
 include/configs/cm_t3517.h   | 10 +---
 include/configs/eb_cpu5282.h |  7 ---
 include/configs/edb93xx.h| 13 -
 include/configs/motionpro.h  | 14 -
 include/configs/mx23_olinuxino.h |  9 
 include/configs/omap3_beagle.h   | 11 
 include/configs/omap3_igep00x0.h |  8 ---
 include/configs/socfpga_vining_fpga.h| 16 --
 include/configs/stm32f429-discovery.h|  1 -
 include/configs/tqma6_wru4.h 

[U-Boot] [PATCH 1/3] armv8: fsl-layerscape: Updates DCFG register map

[Priyanka Jain]

Based on latest hardware documentation,
update ccsr_gur structure (represents DCFG register map)

Signed-off-by: Priyanka Jain 
Signed-off-by: Arpit Goel 
---
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   65 ++--
 1 files changed, 46 insertions(+), 19 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 e18dcbd..38a6d03 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -184,21 +184,23 @@ struct ccsr_gur {
u8  res_008[0x20-0x8];
u32 gpporcr1;   /* General-purpose POR configuration */
u32 gpporcr2;   /* General-purpose POR configuration 2 */
+   u32 gpporcr3;
+   u32 gpporcr4;
+   u8  res_030[0x60-0x30];
 #define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 25
 #define FSL_CHASSIS3_DCFG_FUSESR_VID_MASK  0x1F
 #define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  20
 #define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK   0x1F
u32 dcfg_fusesr;/* Fuse status register */
-   u32 gpporcr3;
-   u32 gpporcr4;
-   u8  res_034[0x70-0x34];
-   u32 devdisr;/* Device disable control */
+   u8  res_064[0x70-0x64];
+   u32 devdisr;/* Device disable control 1 */
u32 devdisr2;   /* Device disable control 2 */
u32 devdisr3;   /* Device disable control 3 */
u32 devdisr4;   /* Device disable control 4 */
u32 devdisr5;   /* Device disable control 5 */
u32 devdisr6;   /* Device disable control 6 */
-   u32 devdisr7;   /* Device disable control 7 */
+   u8  res_088[0x94-0x88];
+   u32 coredisr;   /* Device disable control 7 */
 #define FSL_CHASSIS3_DEVDISR2_DPMAC1   0x0001
 #define FSL_CHASSIS3_DEVDISR2_DPMAC2   0x0002
 #define FSL_CHASSIS3_DEVDISR2_DPMAC3   0x0004
@@ -223,15 +225,11 @@ struct ccsr_gur {
 #define FSL_CHASSIS3_DEVDISR2_DPMAC22  0x0020
 #define FSL_CHASSIS3_DEVDISR2_DPMAC23  0x0040
 #define FSL_CHASSIS3_DEVDISR2_DPMAC24  0x0080
-   u8  res_08c[0x90-0x8c];
-   u32 coredisru;  /* uppper portion for support of 64 cores */
-   u32 coredisrl;  /* lower portion for support of 64 cores */
u8  res_098[0xa0-0x98];
u32 pvr;/* Processor version */
u32 svr;/* System version */
-   u32 mvr;/* Manufacturing version */
-   u8  res_0ac[0x100-0xac];
-   u32 rcwsr[32];  /* Reset control word status */
+   u8  res_0a8[0x100-0xa8];
+   u32 rcwsr[30];  /* Reset control word status */
 
 #define FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT  2
 #define FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK   0x1f
@@ -246,24 +244,53 @@ struct ccsr_gur {
 #define RCW_SB_EN_REG_INDEX9
 #define RCW_SB_EN_MASK 0x0400
 
-   u8  res_180[0x200-0x180];
-   u32 scratchrw[32];  /* Scratch Read/Write */
-   u8  res_280[0x300-0x280];
+   u8  res_178[0x200-0x178];
+   u32 scratchrw[16];  /* Scratch Read/Write */
+   u8  res_240[0x300-0x240];
u32 scratchw1r[4];  /* Scratch Read (Write once) */
u8  res_310[0x400-0x310];
u32 bootlocptrl;/* Boot location pointer low-order addr */
u32 bootlocptrh;/* Boot location pointer high-order addr */
-   u8  res_408[0x500-0x408];
-   u8  res_500[0x740-0x500];   /* add more registers when needed */
+   u8  res_408[0x520-0x408];
+   u32 usb1_amqr;
+   u32 usb2_amqr;
+   u8  res_528[0x530-0x528];   /* add more registers when needed */
+   u32 sdmm1_amqr;
+   u8  res_534[0x550-0x534];   /* add more registers when needed */
+   u32 sata1_amqr;
+   u32 sata2_amqr;
+   u8  res_558[0x570-0x558];   /* add more registers when needed */
+   u32 misc1_amqr;
+   u8  res_574[0x590-0x574];   /* add more registers when needed */
+   u32 spare1_amqr;
+   u32 spare2_amqr;
+   u8  res_598[0x620-0x598];   /* add more registers when needed */
+   u32 gencr[7];   /* General Control Registers */
+   u8  res_63c[0x640-0x63c];   /* add more registers when needed */
+   u32 cgensr1;/* Core General Status Register */
+   u8  res_644[0x660-0x644];   /* add more registers when needed */
+   u32 cgencr1;/* Core General Control Register */
+   u8  res_664[0x740-0x664];   /* add more registers when needed */
u32 tp_ityp[64];/* Topology Initiator Type Register */
struct {
u32 upper;
u32 lower;
-   } tp_cluster[3];/* Core Cluster n