[U-Boot] [PATCH V2]Powerpc/P1022DS: Enable the DIU for P1022DS board.

[Jason Jin]

The DIU of P1022DS was disabled by commit:
dfe64e2c89731a3f9950d7acd8681b68df2bae03 to verify the
u-boot MTD subsystem.

The local bus and DIU is multiplex on P1022, but the
DIU will not be enabled if there is no video-mode environment.
The NAND still can be used with DIU enabled in the configuration
file with the video-mode environment disabled.

Signed-off-by: Jason Jin 
---
V2: Remove the ATI enablement when not enable the DIU.

 include/configs/P1022DS.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index edece1f..9da9cdf 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -413,6 +413,7 @@
 #define CONFIG_SYS_HUSH_PARSER
 
 /* Video */
+#define CONFIG_FSL_DIU_FB
 
 #ifdef CONFIG_FSL_DIU_FB
 #define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x1)
-- 
1.8.0


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

Re: [U-Boot] [PATCH] Enable the DIU for P1022DS board.

[Jin Zhengxiong-R64188]

> -Original Message-
> From: Timur Tabi [mailto:ti...@tabi.org]
> Sent: Friday, September 06, 2013 10:53 PM
> To: Jin Zhengxiong-R64188
> Cc: sun york-R58495; Wood Scott-B07421; U-Boot Mailing List
> Subject: Re: [U-Boot] [PATCH] Enable the DIU for P1022DS board.
> 
> On Fri, Sep 6, 2013 at 4:21 AM, Jason Jin  wrote:
> >
> >  #ifndef CONFIG_FSL_DIU_FB
> > +#define CONFIG_ATI
> >  #endif
> 
> Is this really necessary?  If the DIU is disabled, why would someone use
> a PCI video controller?
[Jason Jin-R64188] IF only they just want to verify the PCI video. Anyway, I'll 
not enable the ATI when the DIU is disabled. Thanks.

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

Re: [U-Boot] Bootdelay -1 for none autoboot does not work

[Mario Albrecht]

Hi,

the board uses an Freescale i.MX35 Controller.

When I use the u-boot revision 2013.01.01
with same configuration all works fine (-1 disables autoboot)
Only when I use u-boot 2013.07 it does not work.
I have looked in main.c and found the following differences:

2013.01.01: Line 68: #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
2013.07: Line 88: #if defined(CONFIG_BOOTDELAY)

2013.01.01: Line 298: #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) 
&& defined(CONFIG_OF_CONTROL)
2013.07: Line 286: #if defined(CONFIG_BOOTDELAY) && defined(CONFIG_OF_CONTROL)

Could it be, that -1 Value for disable autoboot is not longer
supported in u-boot 2013.07?

Regards Mario


-Ursprüngliche Nachricht-
Von: Robert P. J. Day [mailto:rpj...@crashcourse.ca] 
Gesendet: Montag, 7. Oktober 2013 21:10
An: Eric Nelson
Cc: Mario Albrecht; u-boot@lists.denx.de
Betreff: Re: [U-Boot] Bootdelay -1 for none autoboot does not work

On Mon, 7 Oct 2013, Eric Nelson wrote:

> Hi Mario,
>
> On 10/07/2013 09:05 AM, Mario Albrecht wrote:
> > Hi,
> >
> > i am using u-boot 213.07 and hav set CONFIG_BOOTDELAY to -1 to 
> > prevent autoboot. But u-boot seems to ignore the parameter and do 
> > autoboot after 1 second. Could someon please help why I cannot 
> > disable autoboot?
>
> Do you by chance have 'bootdelay' saved in a persistent environment?
>
> If memory serves, the 'bootdelay' environment variable over-rides the 
> default from the CONFIG variable.

  what board is this on?

rday

-- 


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

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


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

Re: [U-Boot] [PATCH 1/8] Tegra124: Add arch-tegra124 include/header files

[Thierry Reding]

On Tue, Oct 08, 2013 at 12:42:51AM +0200, Tom Warren wrote:
> No real HW change on T124 for 90% of the toys, so just include
> a common T1x4 header file (based on T114 headers), and if a new
> register/bit is needed, add it at the end. Some headers (clk_rst,
> clock-tables, pinmux, etc.) had too many changes in structs,
> devices, etc. added/removed, so they are added as complete new
> files for T124, and can be diffed against T114 headers to see
> what's changed (again, not a lot).
> 
> In a future (RSN) patch I'll point the T114 headers at the
> new common tegra1x4-xxx files, too.
> 
> Change-Id: I02a37e1a6bee0c62721f1ffb3968379b36d0f2dd

As a general note: you should strip these Change-Id tags when posting
patches upstream. It's completely useless unless you provide a URL and
access to the gerrit instance that carries the change.

Thierry

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


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

Re: [U-Boot] [PATCH 2/8] Tegra124: Add changes to common arch-tegra header files

[Thierry Reding]

On Tue, Oct 08, 2013 at 12:42:52AM +0200, Tom Warren wrote:
> Minor changes to support T124 chip and sku IDs.

SKU is an abbreviation, therefore should be uppercase.

Thierry

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


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

Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[Albert ARIBAUD]

Hi Scott,

On Mon, 7 Oct 2013 19:55:46 -0500, Scott Wood 
wrote:

> On Sat, 2013-10-05 at 09:52 +0200, Albert ARIBAUD wrote:
> > Hi Scott,
> > 
> > On Thu, 3 Oct 2013 17:48:28 -0500, Scott Wood 
> > wrote:
> > 
> > > ARM64 uses the newer RELA-style relocations rather than the older REL.
> > > RELA relocations have an addend in the relocation struct, rather than
> > > expecting the loader to read a value from the location to be updated.
> > >
> > > While this is beneficial for ordinary program loading, it's problematic
> > > for U-Boot because the location to be updated starts out with zero,
> > > rather than a pre-relocation value.  Since we need to be able to run C
> > > code before relocation, we need a tool to apply the relocations at
> > > build time.
> > 
> > I love it when support for a feature which offers more capabilities is
> > replaced with support for one which offers less. What's the point of a
> > relocation system that produces a binary which will *never* work if
> > not relocated first? What's the point of zeroing position-dependent
> > locations instead of putting some useful value in it, like the value
> > they would have if no relocation occurred? :/
> 
> Yeah, it's annoying.  It also seems to affect gdb printing global
> variables before a program has started.
> 
> > I really don't understand why REL-style relocation is impossible. Is it
> > an EABI specification? A toolchain limitation? A toolchain design
> > decision (i.e., a limitation that will not be lifted)?
> 
> It looks like one of the latter two.  I don't know which.  I tried
> looking at the linker code to see if there was an option to switch, and
> had difficulty following it.  If someone else wants to engage with the
> binutils people and get a REL option added, that'd be great, but I don't
> have the bandwidth right now, and in any case it would be a while before
> we could rely on such a solution.
> 
> > OTOH, I don't have an EABI doc for arm64. Could someone just
> > copy-paster its URL to me? Thanks in advance.
> 
> I don't know of an "E"ABI for arm64, but googling "aarch64 abi" turns up
> an ELF ABI document as the first result.  I tried to copy and paste the
> URL but it's google-encoded crap, and it's PDF so I can't copy it from
> the browser window that opens.
> 
> That document says that both REL and RELA are acceptable.
> 
> > > In theory this tool is applicable to other newer architectures (mainly
> > > 64-bit), but currently the only relocations it supports are for arm64,
> > > and it assumes a 64-bit little-endian target.  If the latter limitation
> > > is ever to be changed, we'll need a way to tell the tool what format
> > > the image is in.  Eventually this may be replaced by a tool that uses
> > > libelf or similar and operates directly on the ELF file.  I've written
> > > some code for such an approach but libelf does not make it easy to poke
> > > addresses by memory address (rather than by section), and I was
> > > hesitant to write code to manually parse the program headers and do the
> > > update outside of libelf (or to iterate over sections) -- especially
> > > since it wouldn't get test coverage on things like binaries with
> > > multiple PT_LOAD segments.  This should be good enough for now to let
> > > the manual relocation stuff be removed from the arm64 patches.
> > 
> > Can you clarify what makes this tool beneficial as opposed to e.g.
> > doing an objcopy from .elf to binary? After all, if we're going to
> > relocate at build time from address A to B, why not directly build
> > for address B, objcopy the resulting ELF and be done with it?
> 
> We do use objcopy, but it doesn't apply the relocations.  It doesn't
> matter what address we build for; if the relocations aren't applied, all
> to-be-relocated pointers will be zero.

Thanks Scott fot the heads-up. I have found the arm64 ABI and traced it
back to this URL:



(Somehow the document can be read in Firefox but evince chokes on it)

I see that some relocation types are deemed mandatory (4.6.1, page 13)
and the way I read it, R_AARCH64_RELATIVE should be one of them...

I'll have a stab at investigating both binutil and gcc.

Meanwhile, even if we end up being able to use R_AARCH64_RELATIVE, part
of the patch series will remain useful, notably the filtering in the
makefile. I would just like a note added somewhere stating that this is
hopefully an interim solution until R_AARCH64_RELATIVE is available.
 
> -Scott

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

Re: [U-Boot] [PATCH 0/4] arm64: rela relocation

[Albert ARIBAUD]

Hi FengHua,

On Tue, 8 Oct 2013 11:32:39 +0800 (GMT+08:00), FengHua
 wrote:

> 
> > Hi FengHua,
> > 
> > On Fri, 4 Oct 2013 23:55:01 +0800 (GMT+08:00), FengHua
> >  wrote:
> > 
> > > 
> > > 
> > > > arm64: rela relocation
> > > > 
> > > > This lets us remove the manual relocation stuff from the arm64 patchset
> > > > (the symbol itself is removed by this patchset, but not all the new
> > > > manual relocations added by the arm64 patchset).
> > > > 
> > > > I'm not terribly happy with the way relocate-rela is now, versus 
> > > > something
> > > > cleaner that operates on the ELF file, but it's good enough for now and
> > > > waiting longer to get rid of the manual relocations would be worse.
> > > > 
> > > > This patchset is based on David's arm64 patchset v13.  David, the first
> > > > two patches should be applied before your arm64 patches.  Maybe the
> > > > fourth as well (except for the removal of the arm64 ifdef you added,
> > > > which would then need to be squashed with your patch).  The third patch
> > > > should be squashed with your patches (plus you should remove the manual
> > > > relocs).
> > > > 
> > > > Scott Wood (4):
> > > >   arm64: Add tool to statically apply RELA relocations
> > > >   arm64: Turn u-boot.bin back into an ELF file after relocate-rela
> > > >   arm64: Non-manual relocation
> > > >   arm64: Make checkarmreloc accept arm64 relocations
> > > > 
> > > >  Makefile  |  39 ++--
> > > >  arch/arm/config.mk|   4 -
> > > >  arch/arm/cpu/armv8/config.mk  |   1 -
> > > >  arch/arm/cpu/armv8/u-boot.lds |  32 +--
> > > >  arch/arm/include/asm/config.h |   5 --
> > > >  arch/arm/lib/crt0_64.S|   7 +-
> > > >  arch/arm/lib/relocate_64.S|  41 -
> > > >  include/configs/vexpress_aemv8a.h |   3 +
> > > >  tools/Makefile|   6 ++
> > > >  tools/relocate-rela.c | 185 
> > > > ++
> > > >  10 files changed, 276 insertions(+), 47 deletions(-)
> > > >  create mode 100644 tools/relocate-rela.c
> > > > 
> > > Great, some fixups related with relocation could be removed.
> > > I will modify arm64 patchset according this.
> > 
> > Stop me if I'm missing something, but doesn't Scott's patch series need
> > yours? And if you remove the manual relocas in yours, doesn't that make
> > your series unable to function properly until Scott's series is applied
> > too?
> > 
> > If I am not mistaken, then maybe Scott's and your patches should be
> > merged in a single series, with adequate attribution of course. 
> > 
> > > David
> > 
> > Amicalement,
> > -- 
> > Albert.
> 
> 
> Yes, these two patches should work together.

Yep, Scott pointed me to where my eyes would not look. Must have been a
SEP field. :)

> We'd better merge them to one patchset.
> The point is we should make choice between CONFIG_NEED_MANUAL_RELOC
> and relocation-rela tool before aarch64-gcc support rel
> relocation format or maybe aarch64-gcc will never do it.
> Another motivation to update arm64 patch is that it's too old
> and got wrong when applied to current u-boot master.

I am in favor of going for relocation-rela, if only because manual
relocations are a major pain in the long run, so I want relocation
handling to be automated.
 
> Best Regards.
> 
> David.

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

Re: [U-Boot] Bootdelay -1 for none autoboot does not work

[Mario Albrecht]

Hi,

i have found a working configuration.
When I comment out the CONFIG_BOOTDELAY in the board header file,
autoboot is disabled. 

Regards Mario

-Ursprüngliche Nachricht-
Von: Robert P. J. Day [mailto:rpj...@crashcourse.ca] 
Gesendet: Montag, 7. Oktober 2013 21:10
An: Eric Nelson
Cc: Mario Albrecht; u-boot@lists.denx.de
Betreff: Re: [U-Boot] Bootdelay -1 for none autoboot does not work

On Mon, 7 Oct 2013, Eric Nelson wrote:

> Hi Mario,
>
> On 10/07/2013 09:05 AM, Mario Albrecht wrote:
> > Hi,
> >
> > i am using u-boot 213.07 and hav set CONFIG_BOOTDELAY to -1 to 
> > prevent autoboot. But u-boot seems to ignore the parameter and do 
> > autoboot after 1 second. Could someon please help why I cannot 
> > disable autoboot?
>
> Do you by chance have 'bootdelay' saved in a persistent environment?
>
> If memory serves, the 'bootdelay' environment variable over-rides the 
> default from the CONFIG variable.

  what board is this on?

rday

-- 


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

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


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

Re: [U-Boot] [PATCH 3/8] Tegra124: Add SPL/AVP (arm720t) cpu files

[Thierry Reding]

On Tue, Oct 08, 2013 at 12:42:53AM +0200, Tom Warren wrote:
> This provides SPL support for T124 boards - AVP
> early init, plus CPU (A15) init/jump to main U-Boot.
> 
> Change-Id: I721f83f1d5fa549e0698e0cc76ab3e5ea11ba895
> Signed-off-by: Tom Warren 
> ---
>  arch/arm/cpu/arm720t/tegra-common/cpu.c |  63 +--
>  arch/arm/cpu/arm720t/tegra-common/cpu.h |   6 +-
>  arch/arm/cpu/arm720t/tegra124/Makefile  |  31 
>  arch/arm/cpu/arm720t/tegra124/config.mk |   7 +
>  arch/arm/cpu/arm720t/tegra124/cpu.c | 301 
> 
>  5 files changed, 387 insertions(+), 21 deletions(-)
>  create mode 100644 arch/arm/cpu/arm720t/tegra124/Makefile
>  create mode 100644 arch/arm/cpu/arm720t/tegra124/config.mk
>  create mode 100644 arch/arm/cpu/arm720t/tegra124/cpu.c
> 
> diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
> b/arch/arm/cpu/arm720t/tegra-common/cpu.c
> index 72c69b9..fbe553a 100644
> --- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
> +++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
> @@ -1,17 +1,8 @@
>  /*
> - * Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
> + * (C) Copyright 2013
> + * NVIDIA Corporation 

What about years 2010-2012? Shouldn't they be kept in the copyright
line? Also, we should probably try to be more consistent with our
copyright notices. There's a variety of ways that we use:

(C) Copyright 2013
NVIDIA Corporation 

Copyright (c) 2010-2013, NVIDIA CORPORATION.  All rights reserved.

(C) Copyright 2010-2013, NVIDIA Corporation 

Copyright (c) 2010-2011 NVIDIA Corporation

There may be more. I personally have a preference for the last of these,
but as long as we can keep some consistency I don't mind which one we
settle on.

>  void adjust_pllp_out_freqs(void)
> @@ -146,6 +153,18 @@ int pllx_set_rate(struct clk_pll_simple *pll , u32 divn, 
> u32 divm,
> 
> debug(" pllx_set_rate entry\n");
> 
> +#if defined(CONFIG_TEGRA124)
> +   struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
> *)NV_PA_CLK_RST_BASE;
> +
> +   /* Disable IDDQ */
> +   reg = readl(&clkrst->crc_pllx_misc3);
> +   reg &= ~PLLX_IDDQ_MASK;
> +   writel(reg, &clkrst->crc_pllx_misc3);
> +   udelay(2);
> +   debug("%s: IDDQ: PLLX IDDQ = 0x%08X\n", __func__,
> + readl(&clkrst->crc_pllx_misc3));
> +#endif /* T124 */

Perhaps this should be moved to a separate function that can be provided
as a dummy for non-Tegra124?

> @@ -162,18 +181,23 @@ int pllx_set_rate(struct clk_pll_simple *pll , u32 
> divn, u32 divm,
> reg |= (1 << PLL_DCCON_SHIFT);
> writel(reg, &pll->pll_misc);
> 
> -   /* Enable PLLX */
> -   reg = readl(&pll->pll_base);
> -   reg |= PLL_ENABLE_MASK;
> -
> /* Disable BYPASS */
> +   reg = readl(&pll->pll_base);
> reg &= ~PLL_BYPASS_MASK;
> writel(reg, &pll->pll_base);
> +   debug(" pllx_set_rate: base = 0x%08X\n", reg);

Why's there a leading space in that debug message? I see that other
debug messages have it as well, but I don't see any reason for it.
Copied and pasted?

> /* Set lock_enable to PLLX_MISC */
> reg = readl(&pll->pll_misc);
> reg |= PLL_LOCK_ENABLE_MASK;
> writel(reg, &pll->pll_misc);
> +   debug(" pllx_set_rate: misc = 0x%08X\n", reg);
> +
> +   /* Enable PLLX last, as per JZ */

I guess JZ is Jimmy Zhang, but a proper explanation for why this is done
on necessary would be more valuable.

> -   /* adjust PLLP_out1-4 on T3x/T114 */
> +   /* adjust PLLP_out1-4 on T3x/T1x4 */

I don't know about this. What ever happens if engineering comes up with
a chip, say, T194 that's not compatible? I think there's some sense in
being explicit here and making this T3x/T114/T124. I don't know why T3x
is used here either for that matter.

> soc_type = tegra_get_chip();
> -   if (soc_type == CHIPID_TEGRA30 || soc_type == CHIPID_TEGRA114)
> +   if (soc_type == CHIPID_TEGRA30 || soc_type == CHIPID_TEGRA114 
> ||
> +   soc_type == CHIPID_TEGRA124)

Perhaps:

if (soc_type >= CHIPID_TEGRA30)

?

> @@ -12,7 +12,8 @@
> 
>  #if defined(CONFIG_TEGRA20)
>  #define NVBL_PLLP_KHZ  (216000)
> -#elif defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
> +#elif defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114) || \
> +   defined(CONFIG_TEGRA124)
>  #define NVBL_PLLP_KHZ  (408000)
>  #else
>  #error "Unknown Tegra chip!"
> @@ -68,3 +69,4 @@ int tegra_get_chip(void);
>  int tegra_get_sku_info(void);
>  int tegra_get_chip_sku(void);
>  void adjust_pllp_out_freqs(void);
> +void pmic_enable_cpu_vdd(void);

This doesn't seem to exist until patch 8. Perhaps this should really be
an weak function so that it always exists but can still be overwritten
by individual boards?

> diff --git a/arch/arm/cpu/arm720t/tegra124/cpu.c 
> b/arch/arm/cpu/arm720t/tegra124/cpu.c
> +static void enable_cpu_power_rail(void)
> +{
> +  

[U-Boot] [PATCH] env: dataflash: fix env_init issue

[Bo Shen]

As the SPI controller is not initialized before env_init(), it causes
reading env in dataflash failed. So, although saveenv() successfully,
it shows warning information when reboot the system as following:

  *** Warning - bad CRC, using default environment

Let the env_relocate() to check env CRC and import it.

Signed-off-by: Bo Shen 

---
 common/env_dataflash.c |   50 +---
 1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/common/env_dataflash.c b/common/env_dataflash.c
index 5f21d5c..b53b87e 100644
--- a/common/env_dataflash.c
+++ b/common/env_dataflash.c
@@ -29,11 +29,25 @@ uchar env_get_char_spec(int index)
 
 void env_relocate_spec(void)
 {
+   ulong crc, new = 0;
+   unsigned off;
char buf[CONFIG_ENV_SIZE];
 
+   /* Read old CRC */
+   read_dataflash(CONFIG_ENV_ADDR + offsetof(env_t, crc),
+  sizeof(ulong), (char *)&crc);
+
+   /* Read whole environment */
read_dataflash(CONFIG_ENV_ADDR, CONFIG_ENV_SIZE, buf);
 
-   env_import(buf, 1);
+   /* Calculate the CRC */
+   off = offsetof(env_t, data);
+   new = crc32(new, (unsigned char *)(buf + off), ENV_SIZE);
+
+   if (crc == new)
+   env_import(buf, 1);
+   else
+   set_default_env("!bad CRC");
 }
 
 #ifdef CONFIG_ENV_OFFSET_REDUND
@@ -67,37 +81,9 @@ int saveenv(void)
  */
 int env_init(void)
 {
-   ulong crc, len = ENV_SIZE, new = 0;
-   unsigned off;
-   uchar buf[64];
-
-   if (gd->env_valid)
-   return 0;
-
-   AT91F_DataflashInit();  /* prepare for DATAFLASH read/write */
-
-   /* read old CRC */
-   read_dataflash(CONFIG_ENV_ADDR + offsetof(env_t, crc),
-   sizeof(ulong), (char *)&crc);
-
-   off = offsetof(env_t, data);
-   while (len > 0) {
-   int n = (len > sizeof(buf)) ? sizeof(buf) : len;
-
-   read_dataflash(CONFIG_ENV_ADDR + off, n, (char *)buf);
-
-   new = crc32(new, buf, n);
-   len -= n;
-   off += n;
-   }
-
-   if (crc == new) {
-   gd->env_addr= offsetof(env_t, data);
-   gd->env_valid   = 1;
-   } else {
-   gd->env_addr= (ulong)&default_environment[0];
-   gd->env_valid   = 0;
-   }
+   /* use default */
+   gd->env_addr = (ulong)&default_environment[0];
+   gd->env_valid = 1;
 
return 0;
 }
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v6] usb: new board-specific USB init interface

[Marek Vasut]

Dear Troy Kisky,

> On 10/7/2013 3:32 AM, Mateusz Zalega wrote:
> > On 10/05/13 02:48, Troy Kisky wrote:
> >> On 10/4/2013 10:22 AM, Mateusz Zalega wrote:
> >>>+/*
> >>> 
> >>> + * You can initialize platform's USB host or device
> >>> + * ports by passing this enum as an argument to
> >>> + * board_usb_init().
> >>> + */
> >>> +enum board_usb_init_type {
> >>> +USB_INIT_HOST,
> >>> +USB_INIT_DEVICE
> >>> +};
> >>> +
> >> 
> >> I'm a little late to the game, but can you rename this to just
> >> usb_init_type ?
> >> I'm wanting to use this as a parameter to usb_lowlevel_init, moving it
> >> above the usb_lowlevel_init definition would help me too.
> > 
> > Looks like Marek already applied it. You can always send another RFC.
> > 
> > Regards,
> 
> So you are O.K. with me sending a rename patch?

Send a patch on top of usb/next please.

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

[U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Rajeshwari S Shinde]

This patchset has a set of patches which improves the
performance of spi on exynos.
Have combined all individual patches into a single patchset.
Patches are based on u-boot-spi.git master branch.

Rajeshwari S Shinde (3):
  exynos: Export timer_get_us() to get microsecond timer
  spi: exynos: Support a delay after deactivate
  spi: exynos: Minimise access to SPI FIFO level
  spi: exynos: Support word transfers

 arch/arm/include/asm/arch-exynos/spi.h |  11 +++-
 drivers/spi/exynos_spi.c   | 107 +++--
 include/common.h   |   6 ++
 3 files changed, 104 insertions(+), 20 deletions(-)

-- 
1.7.12.4

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

[U-Boot] [PATCH 1/4] exynos: Export timer_get_us() to get microsecond timer

[Rajeshwari S Shinde]

From: Rajeshwari Shinde 

This function, if implemented by the board, provides a microsecond
timer. The granularity may be larger than 1us if hardware does not
support this.

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari S Shinde 
---
 include/common.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/common.h b/include/common.h
index 8addf43..42964bc 100644
--- a/include/common.h
+++ b/include/common.h
@@ -596,6 +596,12 @@ void ddr_enable_ecc(unsigned int dram_size);
 #endif
 #endif
 
+/*
+ * Return the current value of a monotonically increasing microsecond timer.
+ * Granularity may be larger than 1us if hardware does not support this.
+ */
+ulong timer_get_us(void);
+
 /* $(CPU)/cpu.c */
 static inline int cpumask_next(int cpu, unsigned int mask)
 {
-- 
1.7.12.4

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

[U-Boot] [PATCH 3/4] spi: exynos: Minimise access to SPI FIFO level

[Rajeshwari S Shinde]

Accessing SPI registers is slow, but access to the FIFO level register
in particular seems to be extraordinarily expensive (I measure up to
600ns). Perhaps it is required to synchronise with the SPI byte output
logic which might run at 1/8th of the 40MHz SPI speed (just a guess).

Reduce access to this register by filling up and emptying FIFOs
more completely, rather than just one word each time around the inner
loop.

Since the rxfifo value will now likely be much greater that what we read
before we fill the txfifo, we only fill the txfifo halfway. This is
because if the txfifo is empty, but the rxfifo has data in it, then writing
too much data to the txfifo may overflow the rxfifo as data arrives.

This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari S Shinde 
---
 drivers/spi/exynos_spi.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index d7fdaac..7407d6c 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -247,24 +247,27 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
 
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl);
-   if (tx_lvl < spi_slave->fifo_size && out_bytes) {
+   while (tx_lvl < spi_slave->fifo_size/2 && out_bytes) {
temp = txp ? *txp++ : 0xff;
writel(temp, ®s->tx_data);
out_bytes--;
+   tx_lvl++;
}
if (rx_lvl > 0) {
-   temp = readl(®s->rx_data);
-   if (spi_slave->skip_preamble) {
-   if (temp == SPI_PREAMBLE_END_BYTE) {
-   spi_slave->skip_preamble = 0;
-   stopping = 0;
+   while (rx_lvl > 0) {
+   temp = readl(®s->rx_data);
+   if (spi_slave->skip_preamble) {
+   if (temp == SPI_PREAMBLE_END_BYTE) {
+   spi_slave->skip_preamble = 0;
+   stopping = 0;
+   }
+   } else {
+   if (rxp || stopping)
+   *rxp++ = temp;
+   in_bytes--;
}
-   } else {
-   if (rxp || stopping)
-   *rxp++ = temp;
-   in_bytes--;
-   }
-   toread--;
+   toread--;
+   rx_lvl--;
} else if (!toread) {
/*
 * We have run out of input data, but haven't read
-- 
1.7.12.4

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

[U-Boot] [PATCH 2/4] spi: exynos: Support a delay after deactivate

[Rajeshwari S Shinde]

For devices that need some time to react after a spi transaction
finishes, add the ability to set a delay.

Implement this as a delay on the first/next transaction to avoid
any delay in the fairly common case where a SPI transaction is
followed by other processing.

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari S Shinde 
---
 drivers/spi/exynos_spi.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index efc8b1e..d7fdaac 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -26,6 +26,7 @@ struct spi_bus {
struct exynos_spi *regs;
int inited; /* 1 if this bus is ready for use */
int node;
+   uint deactivate_delay_us;   /* Delay to wait after deactivate */
 };
 
 /* A list of spi buses that we know about */
@@ -40,6 +41,8 @@ struct exynos_spi_slave {
enum periph_id periph_id;   /* Peripheral ID for this device */
unsigned int fifo_size;
int skip_preamble;
+   struct spi_bus *bus;/* Pointer to our SPI bus info */
+   ulong last_transaction_us;  /* Time of last transaction end */
 };
 
 static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -85,6 +88,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum, 
unsigned int cs,
}
 
bus = &spi_bus[busnum];
+   spi_slave->bus = bus;
spi_slave->regs = bus->regs;
spi_slave->mode = mode;
spi_slave->periph_id = bus->periph_id;
@@ -95,6 +99,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum, 
unsigned int cs,
spi_slave->fifo_size = 256;
 
spi_slave->skip_preamble = 0;
+   spi_slave->last_transaction_us = timer_get_us();
 
spi_slave->freq = bus->frequency;
if (max_hz)
@@ -359,9 +364,22 @@ void spi_cs_activate(struct spi_slave *slave)
 {
struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
 
+   /* If it's too soon to do another transaction, wait */
+   if (spi_slave->bus->deactivate_delay_us &&
+   spi_slave->last_transaction_us) {
+   ulong delay_us; /* The delay completed so far */
+   delay_us = timer_get_us() - spi_slave->last_transaction_us;
+   if (delay_us < spi_slave->bus->deactivate_delay_us)
+   udelay(spi_slave->bus->deactivate_delay_us - delay_us);
+   }
+
clrbits_le32(&spi_slave->regs->cs_reg, SPI_SLAVE_SIG_INACT);
debug("Activate CS, bus %d\n", spi_slave->slave.bus);
spi_slave->skip_preamble = spi_slave->mode & SPI_PREAMBLE;
+
+   /* Remember time of this transaction so we can honour the bus delay */
+   if (spi_slave->bus->deactivate_delay_us)
+   spi_slave->last_transaction_us = timer_get_us();
 }
 
 /**
@@ -411,6 +429,8 @@ static int spi_get_config(const void *blob, int node, 
struct spi_bus *bus)
/* Use 500KHz as a suitable default */
bus->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
50);
+   bus->deactivate_delay_us = fdtdec_get_int(blob, node,
+   "spi-deactivate-delay", 0);
 
return 0;
 }
-- 
1.7.12.4

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

[U-Boot] [PATCH 4/4] spi: exynos: Support word transfers

[Rajeshwari S Shinde]

Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.

Use the byte-swapping feature to avoid having to convert to/from big
endian in software.

This change increases speed from about 2MB/s to about 4.5MB/s.

Signed-off-by: Simon Glass 
Signed-off-by: Rajeshwari S Shinde 
---
 arch/arm/include/asm/arch-exynos/spi.h | 11 -
 drivers/spi/exynos_spi.c   | 76 +++---
 2 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
b/arch/arm/include/asm/arch-exynos/spi.h
index fb23aa6..147c1a7 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -22,7 +22,7 @@ struct exynos_spi {
unsigned intrx_data;/* 0x1c */
unsigned intpkt_cnt;/* 0x20 */
unsigned char   reserved2[4];
-   unsigned char   reserved3[4];
+   unsigned intswap_cfg;   /* 0x28 */
unsigned intfb_clk; /* 0x2c */
unsigned char   padding[0xffd0];
 };
@@ -62,5 +62,14 @@ struct exynos_spi {
 /* Packet Count */
 #define SPI_PACKET_CNT_EN  (1 << 16)
 
+/* Swap config */
+#define SPI_TX_SWAP_EN (1 << 0)
+#define SPI_TX_BYTE_SWAP   (1 << 2)
+#define SPI_TX_HWORD_SWAP  (1 << 3)
+#define SPI_TX_BYTE_SWAP   (1 << 2)
+#define SPI_RX_SWAP_EN (1 << 4)
+#define SPI_RX_BYTE_SWAP   (1 << 6)
+#define SPI_RX_HWORD_SWAP  (1 << 7)
+
 #endif /* __ASSEMBLY__ */
 #endif
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 7407d6c..699c57e 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -204,12 +204,29 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
  *
  * @param regs SPI peripheral registers
  * @param countNumber of bytes to transfer
+ * @param step Number of bytes to transfer in each packet (1 or 4)
  */
-static void spi_request_bytes(struct exynos_spi *regs, int count)
+static void spi_request_bytes(struct exynos_spi *regs, int count, int step)
 {
+   /* For word address we need to swap bytes */
+   if (step == 4) {
+   setbits_le32(®s->mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+   count /= 4;
+   setbits_le32(®s->swap_cfg, SPI_TX_SWAP_EN | SPI_RX_SWAP_EN |
+   SPI_TX_BYTE_SWAP | SPI_RX_BYTE_SWAP |
+   SPI_TX_HWORD_SWAP | SPI_RX_HWORD_SWAP);
+   } else {
+   /* Select byte access and clear the swap configuration */
+   clrbits_le32(®s->mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+   writel(0, ®s->swap_cfg);
+   }
+
assert(count && count < (1 << 16));
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
+
writel(count | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
 }
 
@@ -224,6 +241,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
int toread;
unsigned start = get_timer(0);
int stopping;
+   int step;
 
out_bytes = in_bytes = todo;
 
@@ -231,10 +249,19 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
!(spi_slave->mode & SPI_SLAVE);
 
/*
+* Try to transfer words if we can. This helps read performance at
+* SPI clock speeds above about 20MHz.
+*/
+   step = 1;
+   if (!((todo | (uintptr_t)rxp | (uintptr_t)txp) & 3) &&
+   !spi_slave->skip_preamble)
+   step = 4;
+
+   /*
 * If there's something to send, do a software reset and set a
 * transaction size.
 */
-   spi_request_bytes(regs, todo);
+   spi_request_bytes(regs, todo, step);
 
/*
 * Bytes are transmitted/received in pairs. Wait to receive all the
@@ -247,14 +274,26 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
int todo,
 
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl);
+
+   /*
+* Don't completely fill the txfifo, since we don't want our
+* rxfifo to overflow, and it may already contain data.
+*/
while (tx_lvl < spi_slave->fifo_size/2 && out_bytes) {
-   temp = txp ? *txp++ : 0xff;
+   if (!txp)
+   temp = -1;
+   else if (step == 4)
+   temp = *(uint32_t *)txp;
+   else
+   temp = *txp;
writel(temp, ®s->tx_data);
-   out_bytes--;
-   tx_lvl++;
+   out_bytes -= step;
+

Re: [U-Boot] [PATCH 00/10 V4] EXYNOS5420: Add SMDK5420 board support

[Rajeshwari Birje]

Hi Minkyu Kang,

Please do let me if any comments on this patch set

Regards,
Rajeshwari Shinde.

On Fri, Sep 27, 2013 at 5:40 PM, Rajeshwari S Shinde
 wrote:
> This patch adds basic board support for SMDK5420 board.
> These patches are tested for booting fine on EVT1 SMDK5420.
>
> Changes in V2:
> - Corrected a compilation issue for SMDK5420.
>
> Changes in V3:
> - Add patch to support variable size SPL support
> - Add patch to disable SMU for eMMC.
>
> Changes in V4:
> - Added check for MAX77686 pmic compilation.
> - Added correct calculation of gpio based addresses.
> - Rebased on the latest u-boot code.
> - Removed patches for UART and TZPC changes as
> they were not needed.
> - Added flag to disable SMU for eMMC.
>
> Rajeshwari S Shinde (9):
>   EXYNOS5: Create a common board file
>   Exynos5420: Add base addresses for 5420
>   Exynos5420: Add clock initialization for 5420
>   Exynos5420: Add DDR3 initialization for 5420
>   Exynos5420: Add support for 5420 in pinmux and gpio
>   Exynos5420: Add base patch for SMDK5420
>   DTS: Add dts support for SMDK5420
>   Config: Add initial config for SMDK5420
>   SPL: EXYNOS: Prepare for variable size SPL support
>   DWMMC: SMDK5420: Disable SMU for eMMC
>
>  arch/arm/cpu/armv7/exynos/clock.c  | 270 -
>  arch/arm/cpu/armv7/exynos/clock_init.h |  17 +
>  arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 352 +++-
>  arch/arm/cpu/armv7/exynos/dmc_common.c |  10 +-
>  arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c  | 421 +-
>  arch/arm/cpu/armv7/exynos/exynos5_setup.h  | 740 
> +++--
>  arch/arm/cpu/armv7/exynos/pinmux.c | 245 +++-
>  arch/arm/dts/exynos5.dtsi  | 213 +++
>  arch/arm/dts/exynos5250.dtsi   | 177 +-
>  arch/arm/dts/exynos5420.dtsi   |  74 +++
>  arch/arm/include/asm/arch-exynos/board.h   |  17 +
>  arch/arm/include/asm/arch-exynos/clk.h |   1 +
>  arch/arm/include/asm/arch-exynos/clock.h   | 494 +
>  arch/arm/include/asm/arch-exynos/cpu.h |  52 +-
>  arch/arm/include/asm/arch-exynos/dmc.h | 121 ++--
>  arch/arm/include/asm/arch-exynos/gpio.h| 143 -
>  arch/arm/include/asm/arch-exynos/periph.h  |   3 +
>  board/samsung/common/Makefile  |   4 +
>  board/samsung/common/board.c   | 312 +++
>  board/samsung/dts/exynos5420-smdk5420.dts  | 172 ++
>  board/samsung/smdk5250/exynos5-dt.c| 269 +
>  board/samsung/smdk5250/smdk5250.c  | 182 +-
>  board/samsung/smdk5420/Makefile|  34 ++
>  board/samsung/smdk5420/smdk5420.c  | 253 +
>  board/samsung/smdk5420/smdk5420_spl.c  |  52 ++
>  boards.cfg |   1 +
>  drivers/mmc/dw_mmc.c   |  10 +
>  drivers/mmc/exynos_dw_mmc.c|   3 +
>  include/configs/exynos5-dt.h   | 302 ++
>  include/configs/exynos5250-dt.h| 317 +--
>  include/configs/smdk5420.h |  56 ++
>  include/dwmmc.h|  15 +
>  spl/Makefile   |   7 +-
>  tools/Makefile |   2 +
>  tools/mkexynosspl.c| 167 --
>  35 files changed, 4271 insertions(+), 1237 deletions(-)
>  create mode 100644 arch/arm/dts/exynos5.dtsi
>  create mode 100644 arch/arm/dts/exynos5420.dtsi
>  create mode 100644 arch/arm/include/asm/arch-exynos/board.h
>  create mode 100644 board/samsung/common/board.c
>  create mode 100644 board/samsung/dts/exynos5420-smdk5420.dts
>  create mode 100644 board/samsung/smdk5420/Makefile
>  create mode 100644 board/samsung/smdk5420/smdk5420.c
>  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
>  create mode 100644 include/configs/exynos5-dt.h
>  create mode 100644 include/configs/smdk5420.h
>
> --
> 1.7.12.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

[U-Boot] [PATCH] env: fix the env export varname

[Pierre Aubert]

The env export command doesn't export the first variable of the list
since commit 5a31ea04c9ee5544fbb70ad7597ea4b294840eab
"env grep" - reimplement command using hexport_r()

Signed-off-by: Pierre Aubert 
---
 common/cmd_nvedit.c |6 ++
 lib/hashtable.c |2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 778dca5..c249286 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -157,10 +157,8 @@ static int do_env_grep(cmd_tbl_t *cmdtp, int flag,
grep_how  = H_MATCH_SUBSTR; /* default: substring search*/
grep_what = H_MATCH_BOTH;   /* default: grep names and values */
 
-   while (argc > 1 && **(argv + 1) == '-') {
-   char *arg = *++argv;
-
-   --argc;
+   while (--argc > 0 && **++argv == '-') {
+   char *arg = *argv;
while (*++arg) {
switch (*arg) {
 #ifdef CONFIG_REGEX
diff --git a/lib/hashtable.c b/lib/hashtable.c
index c5a2b08..4356b23 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -564,7 +564,7 @@ static int match_entry(ENTRY *ep, int flag,
int arg;
void *priv = NULL;
 
-   for (arg = 1; arg < argc; ++arg) {
+   for (arg = 0; arg < argc; ++arg) {
 #ifdef CONFIG_REGEX
struct slre slre;
 
-- 
1.7.6.5

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

[U-Boot] [PATCH v2 00/10] usb: Support for TIZEN's THOR download protocol

[Lukasz Majewski]

This patch series provide support for TIZEN's THOR download protocol.

Dedicated program for flashing TIZEN developer devices (TRATS, TRATS2)
is called lthor (or thor for Windows) and can be found at:

git clone git://review.tizen.org/tools/lthor

or for git web:

https://review.tizen.org/git/?p=tools/lthor.git;a=summary


Presented composite USB function acts as a front end to perform
correct USB communication with HOST PC.
To store the received data on the target, the DFU (Device Firmware
Update) code for flashing has been reused.

This means, that the "dfu_alt_info" environment variable is used
to provide information where a received file is stored.

This also means that dfu and thor can co-exists together.
Thor protocol and its implementation has one advantage - it is much
faster than DFU for large files transfers (especially rootfs images).

It applies on: u-boot-denx-usb/next
SHA1: 6928d26b84a5aa4a44706362234ab435bb15a6fb

Test HW: Exynos4210 (TRATS)


Lukasz Majewski (10):
  usb:udc:s3c: Reduce dcache invalidate range for UDC receive buffer
  dfu:core: Find DFU alt setting number by passing its name
  dfu:core: Export dfu_{get|free}_buf functions
  usb:g_dnl: Replace static usb_configuration structure with
dynamically allocated one
  usb:g_dnl: Add name parameter to g_dnl_bind_fixup function
  usb:g_dnl:f_thor: USB download function to support TIZEN's THOR
protocol
  usb:g_dnl: Support for TIZEN's THOR function in generic download code
  cmd:thor: Support for TIZEN's download command (thordown)
  samsung:common:thor: Define common Samsung code to handle THOR usb
descriptor setup
  trats: Update TRATS config to support TIZEN download

 board/samsung/common/Makefile |1 +
 board/samsung/common/thor.c   |   21 +
 board/siemens/common/factoryset.c |2 +-
 common/Makefile   |1 +
 common/cmd_thordown.c |   72 +++
 drivers/dfu/dfu.c |   16 +-
 drivers/usb/gadget/Makefile   |1 +
 drivers/usb/gadget/f_thor.c   | 1003 +
 drivers/usb/gadget/f_thor.h   |  124 
 drivers/usb/gadget/g_dnl.c|   38 +-
 drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |3 +-
 include/configs/trats.h   |   14 +-
 include/dfu.h |3 +
 include/g_dnl.h   |2 +-
 include/thor.h|   27 +
 15 files changed, 1309 insertions(+), 19 deletions(-)
 create mode 100644 board/samsung/common/thor.c
 create mode 100644 common/cmd_thordown.c
 create mode 100644 drivers/usb/gadget/f_thor.c
 create mode 100644 drivers/usb/gadget/f_thor.h
 create mode 100644 include/thor.h

-- 
1.7.10.4

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

[U-Boot] [PATCH v2 02/10] dfu:core: Find DFU alt setting number by passing its name

[Lukasz Majewski]

New function - dfu_get_alt() - has been added to dfu core. If present, it
returns alt setting's number corresponding to passed name.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- None

 drivers/dfu/dfu.c |   12 
 include/dfu.h |1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index f328735..4ec330c 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -440,3 +440,15 @@ struct dfu_entity *dfu_get_entity(int alt)
 
return NULL;
 }
+
+int dfu_get_alt(char *name)
+{
+   struct dfu_entity *dfu;
+
+   list_for_each_entry(dfu, &dfu_list, list) {
+   if (!strncmp(dfu->name, name, strlen(dfu->name)))
+   return dfu->alt;
+   }
+
+   return -ENODEV;
+}
diff --git a/include/dfu.h b/include/dfu.h
index b2ecf1b..b144255 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -126,6 +126,7 @@ const char *dfu_get_layout(enum dfu_layout l);
 struct dfu_entity *dfu_get_entity(int alt);
 char *dfu_extract_token(char** e, int *n);
 void dfu_trigger_reset(void);
+int dfu_get_alt(char *name);
 bool dfu_reset(void);
 int dfu_init_env_entities(char *interface, int dev);
 
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 01/10] usb:udc:s3c: Reduce dcache invalidate range for UDC receive buffer

[Lukasz Majewski]

The s3c udc driver sends data in a max packet size. Therefore the dcache
invalidate range shall be equal to max packet, not the entire
DMA_BUFFER_SIZE.

Signed-off-by: Lukasz Majewski 
Cc: Marek Vasut 

---
Changes for v2:
- ROUND the maxpacket value to invalidate data smaller than cache line size

 drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c 
b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
index d7af5e9..1cbf8f6 100644
--- a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
@@ -117,7 +117,8 @@ static int setdma_rx(struct s3c_ep *ep, struct s3c_request 
*req)
 
invalidate_dcache_range((unsigned long) ep->dev->dma_buf[ep_num],
(unsigned long) ep->dev->dma_buf[ep_num]
-   + DMA_BUFFER_SIZE);
+   + ROUND(ep->ep.maxpacket,
+   CONFIG_SYS_CACHELINE_SIZE));
 
if (length == 0)
pktcnt = 1;
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 04/10] usb:g_dnl: Replace static usb_configuration structure with dynamically allocated one

[Lukasz Majewski]

When the usb_configuration structure is declared as static, it is very
hard to assure, that relevant fields (as e.g. config->interfaces[]) are
cleared out before new call to g_dnl related functions.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- None

 drivers/usb/gadget/g_dnl.c |   24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 40868c0..1aaf78f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -79,6 +79,8 @@ static int g_dnl_unbind(struct usb_composite_dev *cdev)
 {
struct usb_gadget *gadget = cdev->gadget;
 
+   free(cdev->config);
+   cdev->config = NULL;
debug("%s: calling usb_gadget_disconnect for "
"controller '%s'\n", shortname, gadget->name);
usb_gadget_disconnect(gadget);
@@ -105,16 +107,22 @@ static int g_dnl_do_config(struct usb_configuration *c)
 
 static int g_dnl_config_register(struct usb_composite_dev *cdev)
 {
-   static struct usb_configuration config = {
-   .label = "usb_dnload",
-   .bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER,
-   .bConfigurationValue =  CONFIGURATION_NUMBER,
-   .iConfiguration =   STRING_USBDOWN,
+   struct usb_configuration *config;
+   const char *name = "usb_dnload";
 
-   .bind = g_dnl_do_config,
-   };
+   config = memalign(CONFIG_SYS_CACHELINE_SIZE, sizeof(*config));
+   if (!config)
+   return -ENOMEM;
 
-   return usb_add_config(cdev, &config);
+   memset(config, 0, sizeof(*config));
+
+   config->label = name;
+   config->bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER;
+   config->bConfigurationValue = CONFIGURATION_NUMBER;
+   config->iConfiguration = STRING_USBDOWN;
+   config->bind = g_dnl_do_config;
+
+   return usb_add_config(cdev, config);
 }
 
 __weak
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 03/10] dfu:core: Export dfu_{get|free}_buf functions

[Lukasz Majewski]

Define the dfu_get_buf() and dfu_free_buf() as global functions.
They are necessary for zero copy buffer management, when DFU backend is
used for storing data.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- None

 drivers/dfu/dfu.c |4 ++--
 include/dfu.h |2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 4ec330c..4a8804e 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -67,14 +67,14 @@ int dfu_init_env_entities(char *interface, int dev)
 static unsigned char *dfu_buf;
 static unsigned long dfu_buf_size = CONFIG_SYS_DFU_DATA_BUF_SIZE;
 
-static unsigned char *dfu_free_buf(void)
+unsigned char *dfu_free_buf(void)
 {
free(dfu_buf);
dfu_buf = NULL;
return dfu_buf;
 }
 
-static unsigned char *dfu_get_buf(void)
+unsigned char *dfu_get_buf(void)
 {
char *s;
 
diff --git a/include/dfu.h b/include/dfu.h
index b144255..cc14044 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -129,6 +129,8 @@ void dfu_trigger_reset(void);
 int dfu_get_alt(char *name);
 bool dfu_reset(void);
 int dfu_init_env_entities(char *interface, int dev);
+unsigned char *dfu_get_buf(void);
+unsigned char *dfu_free_buf(void);
 
 int dfu_read(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
 int dfu_write(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 07/10] usb:g_dnl: Support for TIZEN's THOR function in generic download code

[Lukasz Majewski]

Support of "thor" function in generic download code (g_dnl.c).

Signed-off-by: Lukasz Majewski 
Cc: Marek Vasut 

---
Changes for v2:
- None

 drivers/usb/gadget/g_dnl.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 98560b8..43f413a 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gadget_chips.h"
 #include "composite.c"
@@ -101,6 +102,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
ret = dfu_add(c);
else if (!strcmp(s, "usb_dnl_ums"))
ret = fsg_add(c);
+   else if (!strcmp(s, "usb_dnl_thor"))
+   ret = thor_add(c);
 
return ret;
 }
@@ -191,8 +194,8 @@ static struct usb_composite_driver g_dnl_driver = {
 
 int g_dnl_register(const char *type)
 {
-   /* We only allow "dfu" atm, so 3 should be enough */
-   static char name[sizeof(shortname) + 3];
+   /* The largest function name is 4 */
+   static char name[sizeof(shortname) + 4];
int ret;
 
if (!strcmp(type, "dfu")) {
@@ -201,6 +204,9 @@ int g_dnl_register(const char *type)
} else if (!strcmp(type, "ums")) {
strcpy(name, shortname);
strcat(name, type);
+   } else if (!strcmp(type, "thor")) {
+   strcpy(name, shortname);
+   strcat(name, type);
} else {
printf("%s: unknown command: %s\n", __func__, type);
return -EINVAL;
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 10/10] trats: Update TRATS config to support TIZEN download

[Lukasz Majewski]

A set of environment variables needs to be updated to provide support for
TIZEN download command (tizendown).

Since DFU is used as a flashing backend, it is also necessary to extent
malloc pool size for DFU buffer allocation.
Moreover, for compatibility reasons (Win vs. Lin) new USB idProduct number
for download gadget had to be added.

Signed-off-by: Lukasz Majewski 
Cc: Marek Vasut 

---
Changes for v2:
- Replace (X << 20) with SZ_XM defines

 include/configs/trats.h |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/configs/trats.h b/include/configs/trats.h
index 24ea06b..f5bb6aa 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -49,8 +49,9 @@
 #define MACH_TYPE_TRATS3928
 #define CONFIG_MACH_TYPE   MACH_TYPE_TRATS
 
+#include 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (16 << 20))
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (80 * SZ_1M))
 
 /* select serial console configuration */
 #define CONFIG_SERIAL2 /* use SERIAL 2 */
@@ -91,12 +92,20 @@
 
 /* USB Composite download gadget - g_dnl */
 #define CONFIG_USBDOWNLOAD_GADGET
+
+/* TIZEN THOR downloader support */
+#define CONFIG_CMD_THOR_DOWNLOAD
+#define CONFIG_THOR_FUNCTION
+
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
 #define CONFIG_DFU_FUNCTION
 #define CONFIG_DFU_MMC
 
 /* USB Samsung's IDs */
 #define CONFIG_G_DNL_VENDOR_NUM 0x04E8
 #define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM
+#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
 #define CONFIG_G_DNL_MANUFACTURER "Samsung"
 
 #define CONFIG_BOOTDELAY   1
@@ -131,7 +140,8 @@
 #define CONFIG_DFU_ALT \
"u-boot mmc 80 400;" \
"uImage ext4 0 2;" \
-   "exynos4210-trats.dtb ext4 0 2\0"
+   "exynos4210-trats.dtb ext4 0 2;" \
+   ""PARTS_ROOT" part 0 5\0"
 
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 05/10] usb:g_dnl: Add name parameter to g_dnl_bind_fixup function

[Lukasz Majewski]

New parameter, namely *name has been added to g_dnl_bind_fixup().
It is necessary (for compatibility reasons) to assign new USB idProduct
and idVendor for different usb functions.

Signed-off-by: Lukasz Majewski 
Cc: Marek Vasut 

---
Changes for v2:
- None

 board/siemens/common/factoryset.c |2 +-
 drivers/usb/gadget/g_dnl.c|4 ++--
 include/g_dnl.h   |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/siemens/common/factoryset.c 
b/board/siemens/common/factoryset.c
index eda9141..fbe7997 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -275,7 +275,7 @@ int factoryset_setenv(void)
return ret;
 }
 
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
 {
put_unaligned(factory_dat.usb_vendor_id, &dev->idVendor);
put_unaligned(factory_dat.usb_product_id, &dev->idProduct);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 1aaf78f..98560b8 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -126,7 +126,7 @@ static int g_dnl_config_register(struct usb_composite_dev 
*cdev)
 }
 
 __weak
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
 {
return 0;
 }
@@ -153,7 +153,7 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)
g_dnl_string_defs[1].id = id;
device_desc.iProduct = id;
 
-   g_dnl_bind_fixup(&device_desc);
+   g_dnl_bind_fixup(&device_desc, cdev->driver->name);
ret = g_dnl_config_register(cdev);
if (ret)
goto error;
diff --git a/include/g_dnl.h b/include/g_dnl.h
index b6c4dd4..de669fb 100644
--- a/include/g_dnl.h
+++ b/include/g_dnl.h
@@ -10,7 +10,7 @@
 
 #include 
 #include 
-int g_dnl_bind_fixup(struct usb_device_descriptor *);
+int g_dnl_bind_fixup(struct usb_device_descriptor *, const char *);
 int g_dnl_register(const char *s);
 void g_dnl_unregister(void);
 
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 09/10] samsung:common:thor: Define common Samsung code to handle THOR usb descriptor setup

[Lukasz Majewski]

Special, common to Samsung, function for altering usb descriptor's
idVendor and idProduct has been added.
For compatibility reasons (Win vs Linux) the THOR idProduct must be
different than the one for DFU/UMS.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- None

 board/samsung/common/Makefile |1 +
 board/samsung/common/thor.c   |   21 +
 2 files changed, 22 insertions(+)
 create mode 100644 board/samsung/common/thor.c

diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index 9e48a7b..ad7564c 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -10,6 +10,7 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)libsamsung.o
 
 COBJS-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
+COBJS-$(CONFIG_THOR_FUNCTION) += thor.o
 
 SRCS:= $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/samsung/common/thor.c b/board/samsung/common/thor.c
new file mode 100644
index 000..1c7630d
--- /dev/null
+++ b/board/samsung/common/thor.c
@@ -0,0 +1,21 @@
+/*
+ *  Copyright (C) 2013 Samsung Electronics
+ *  Lukasz Majewski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
+{
+   if (!strcmp(name, "usb_dnl_thor")) {
+   put_unaligned(CONFIG_G_DNL_THOR_VENDOR_NUM, &dev->idVendor);
+   put_unaligned(CONFIG_G_DNL_THOR_PRODUCT_NUM, &dev->idProduct);
+   } else {
+   put_unaligned(CONFIG_G_DNL_VENDOR_NUM, &dev->idVendor);
+   put_unaligned(CONFIG_G_DNL_PRODUCT_NUM, &dev->idProduct);
+   }
+   return 0;
+}
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 08/10] cmd:thor: Support for TIZEN's download command (thordown)

[Lukasz Majewski]

New command - thordown - has been added to support downloading data
via lthor TIZEN program.
It is similar to dfu command syntax and reuses its code for flashing data.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- Adjust according to new board_usb_init() function semantics.
- do_thor_down() written in a similar way to rewritten do_dfu() function
- Check error condition for board_usb_init()

 common/Makefile   |1 +
 common/cmd_thordown.c |   72 +
 2 files changed, 73 insertions(+)
 create mode 100644 common/cmd_thordown.c

diff --git a/common/Makefile b/common/Makefile
index 288690b..8daca5b 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -168,6 +168,7 @@ COBJS-y += usb.o usb_hub.o
 COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
 COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
+COBJS-$(CONFIG_CMD_THOR_DOWNLOAD) += cmd_thordown.o
 COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
 COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
 COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c
new file mode 100644
index 000..c4b3511
--- /dev/null
+++ b/common/cmd_thordown.c
@@ -0,0 +1,72 @@
+/*
+ * cmd_thordown.c -- USB TIZEN "THOR" Downloader gadget
+ *
+ * Copyright (C) 2013 Lukasz Majewski 
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   if (argc < 4)
+   return CMD_RET_USAGE;
+
+   char *usb_controller = argv[1];
+   char *interface = argv[2];
+   char *devstring = argv[3];
+
+   const char *s = "thor";
+   int ret;
+
+   puts("TIZEN \"THOR\" Downloader\n");
+
+   ret = dfu_init_env_entities(interface, simple_strtoul(devstring,
+ NULL, 10));
+   if (ret)
+   return ret;
+
+   int controller_index = simple_strtoul(usb_controller, NULL, 0);
+   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
+   if (ret) {
+   error("USB init failed: %d", ret);
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+   g_dnl_register(s);
+
+   ret = thor_init();
+   if (ret) {
+   error("THOR DOWNLOAD failed: %d", ret);
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+   ret = thor_handle();
+   if (ret) {
+   error("THOR failed: %d", ret);
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+exit:
+   g_dnl_unregister();
+   dfu_free_entities();
+
+   return ret;
+}
+
+U_BOOT_CMD(thordown, CONFIG_SYS_MAXARGS, 1, do_thor_down,
+  "TIZEN \"THOR\" downloader",
+  "  \n"
+  "  - device software upgrade via LTHOR TIZEN dowload\n"
+  "program via  on device ,\n"
+  "attached to interface \n"
+);
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Jagan Teki]

On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
 wrote:
> This patchset has a set of patches which improves the
> performance of spi on exynos.
> Have combined all individual patches into a single patchset.
> Patches are based on u-boot-spi.git master branch.

Thanks for your patch-set.
Can you confirm, all these were tested against on u-boot-spi.git/master?

-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Rajeshwari Birje]

Hi Jagan,

Yes I have tested them on u-boot-spi.git/master for spi booting.

Regards,
Rajeshwari Shinde.

On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  wrote:
> On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
>  wrote:
>> This patchset has a set of patches which improves the
>> performance of spi on exynos.
>> Have combined all individual patches into a single patchset.
>> Patches are based on u-boot-spi.git master branch.
>
> Thanks for your patch-set.
> Can you confirm, all these were tested against on u-boot-spi.git/master?
>
> --
> Thanks,
> Jagan.
> 
> Jagannadha Sutradharudu Teki,
> E: jagannadh.t...@gmail.com, P: +91-9676773388
> Engineer - System Software Hacker
> U-boot - SPI Custodian and Zynq APSOC
> Ln: http://www.linkedin.com/in/jaganteki
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Jagan Teki]

On Tue, Oct 8, 2013 at 6:11 PM, Rajeshwari Birje
 wrote:
> Hi Jagan,
>
> Yes I have tested them on u-boot-spi.git/master for spi booting.

Sorry for sequence of questions which spi flash parts you tested.?

>
> Regards,
> Rajeshwari Shinde.
>
> On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  wrote:
>> On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
>>  wrote:
>>> This patchset has a set of patches which improves the
>>> performance of spi on exynos.
>>> Have combined all individual patches into a single patchset.
>>> Patches are based on u-boot-spi.git master branch.
>>
>> Thanks for your patch-set.
>> Can you confirm, all these were tested against on u-boot-spi.git/master?
>>
>> --
>> Thanks,
>> Jagan.
>> 
>> Jagannadha Sutradharudu Teki,
>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>> Engineer - System Software Hacker
>> U-boot - SPI Custodian and Zynq APSOC
>> Ln: http://www.linkedin.com/in/jaganteki
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> Regards,
> Rajeshwari Shinde



-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH v2 2/2] ARMV7: OMAP4: Add twl6032 support

[Oleg Kosheliev]

From: Oleg Kosheliev 

Added chip type detection and twl6032
support in the battery control
and charge functions.

Based on Balaji T K  patches for TI u-boot.

Signed-off-by: Oleg Kosheliev 
---
 drivers/power/twl6030.c |   54 +--
 include/twl6030.h   |   20 ++
 2 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
index 6bf1a33..a1c6663 100644
--- a/drivers/power/twl6030.c
+++ b/drivers/power/twl6030.c
@@ -20,6 +20,15 @@ static struct twl6030_data twl6030_info = {
.vbat_shift = TWL6030_VBAT_SHIFT,
 };
 
+static struct twl6030_data twl6032_info = {
+   .chip_type  = chip_TWL6032,
+   .adc_rbase  = TWL6032_GPCH0_LSB,
+   .adc_ctrl   = TWL6032_CTRL_P1,
+   .adc_enable = CTRL_P1_SP1,
+   .vbat_mult  = TWL6032_VBAT_MULT,
+   .vbat_shift = TWL6032_VBAT_SHIFT,
+};
+
 static int twl6030_gpadc_read_channel(u8 channel_no)
 {
u8 lsb = 0;
@@ -115,6 +124,18 @@ int twl6030_get_battery_voltage(void)
 {
int battery_volt = 0;
int ret = 0;
+   u8 vbatch;
+
+   if (twl->chip_type == chip_TWL6030) {
+   vbatch = TWL6030_GPADC_VBAT_CHNL;
+   } else {
+   ret = twl6030_i2c_write_u8(TWL6030_CHIP_ADC,
+  TWL6032_GPSELECT_ISB,
+  TWL6032_GPADC_VBAT_CHNL);
+   if (ret)
+   return ret;
+   vbatch = 0;
+   }
 
/* Start GPADC SW conversion */
ret = twl6030_gpadc_sw2_trigger();
@@ -124,7 +145,7 @@ int twl6030_get_battery_voltage(void)
}
 
/* measure Vbat voltage */
-   battery_volt = twl6030_gpadc_read_channel(7);
+   battery_volt = twl6030_gpadc_read_channel(vbatch);
if (battery_volt < 0) {
printf("Failed to read battery voltage\n");
return ret;
@@ -137,14 +158,35 @@ int twl6030_get_battery_voltage(void)
 
 void twl6030_init_battery_charging(void)
 {
-   u8 stat1 = 0;
+   u8 val = 0;
int battery_volt = 0;
int ret = 0;
 
-   twl = &twl6030_info;
+   ret = twl6030_i2c_read_u8(TWL6030_CHIP_USB, USB_PRODUCT_ID_LSB, &val);
+   if (ret) {
+   puts("twl6030_init_battery_charging(): could not determine 
chip!\n");
+   return;
+   }
+   if (val == 0x30) {
+   twl = &twl6030_info;
+   } else if (val == 0x32) {
+   twl = &twl6032_info;
+   } else {
+   puts("twl6030_init_battery_charging(): unsupported chip 
type\n");
+   return;
+   }
 
/* Enable VBAT measurement */
-   twl6030_i2c_write_u8(TWL6030_CHIP_PM, MISC1, VBAT_MEAS);
+   if (twl->chip_type == chip_TWL6030) {
+   twl6030_i2c_write_u8(TWL6030_CHIP_PM, MISC1, VBAT_MEAS);
+   twl6030_i2c_write_u8(TWL6030_CHIP_ADC,
+TWL6030_GPADC_CTRL,
+GPADC_CTRL_SCALER_DIV4);
+   } else {
+   twl6030_i2c_write_u8(TWL6030_CHIP_ADC,
+TWL6032_GPADC_CTRL2,
+GPADC_CTRL2_CH18_SCALER_EN);
+   }
 
/* Enable GPADC module */
ret = twl6030_i2c_write_u8(TWL6030_CHIP_CHARGER, TOGGLE1, FGS | GPADCS);
@@ -161,10 +203,10 @@ void twl6030_init_battery_charging(void)
printf("Main battery voltage too low!\n");
 
/* Check for the presence of USB charger */
-   twl6030_i2c_read_u8(TWL6030_CHIP_CHARGER, CONTROLLER_STAT1, &stat1);
+   twl6030_i2c_read_u8(TWL6030_CHIP_CHARGER, CONTROLLER_STAT1, &val);
 
/* check for battery presence indirectly via Fuel gauge */
-   if ((stat1 & VBUS_DET) && (battery_volt < 3300))
+   if ((val & VBUS_DET) && (battery_volt < 3300))
twl6030_start_usb_charging();
 
return;
diff --git a/include/twl6030.h b/include/twl6030.h
index 9399737..7898699 100644
--- a/include/twl6030.h
+++ b/include/twl6030.h
@@ -110,15 +110,35 @@
 #define CTRL_P2_EOCP2  (1 << 1)
 #define CTRL_P2_BUSY   (1 << 0)
 
+#define TWL6032_CTRL_P10x36
+#define CTRL_P1_SP1(1 << 3)
+
 #define GPCH0_LSB  0x57
 #define GPCH0_MSB  0x58
 
+#define TWL6032_GPCH0_LSB  0x3b
+
+#define TWL6032_GPSELECT_ISB   0x35
+
+#define USB_PRODUCT_ID_LSB 0x02
+
+#define TWL6030_GPADC_VBAT_CHNL0x07
+#define TWL6032_GPADC_VBAT_CHNL0x12
+
+#define TWL6030_GPADC_CTRL 0x2e
+#define TWL6032_GPADC_CTRL20x2f
+#define GPADC_CTRL2_CH18_SCALER_EN (1 << 2)
+#define GPADC_CTRL_SCALER_DIV4 (1 << 3)
+
 #define TWL6030_VBAT_MULT  40 * 1000
+#define TWL6032_VBAT_MULT  25 * 1000
 
 #define TWL6030_VBAT_SHIFT (10 + 3)
+#define TWL6032_VBAT_SHIFT (12 + 2)
 
 enum twl603x_chip_type{
chip_TWL6030,
+   chip_TWL6032,
chip_TWL6

[U-Boot] [RFC PATCH v2 0/2] ARMV7: OMAP4: Add support for twl6032

[Oleg Kosheliev]

From: Oleg Kosheliev 

TWL6032 is a companion Power Management IC (PMIC) of OMAP4470.
This chip is similar to TWL6030 but has slight difference
in some registers e.g. for GPADC.
In u-boot only TWL6030 is supported now, thus there is no ability to 
boot OMAP4470 with TWL6032 because u-boot hangs when attempts to get
the battery voltage from GPADC using false ctrl register address.
These patches add the detection of the TWL chip type and support
for TWL6032 chip in the battery charger driver.

Changes in v2:
- removed typedef for twl603x_chip_type
- printf replaced with puts

Oleg Kosheliev (2):
  ARMV7: OMAP4: Add struct for twl603x data
  ARMV7: OMAP4: Add twl6032 support

 drivers/power/twl6030.c |   77 +--
 include/twl6030.h   |   38 +++
 2 files changed, 105 insertions(+), 10 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [RFC PATCH v2 1/2] ARMV7: OMAP4: Add struct for twl603x data

[Oleg Kosheliev]

From: Oleg Kosheliev 

The data struct is used to support different
PMIC chip types. It contains the chip type and
the data (e.g. registers addresses, adc multiplier)
which is different for twl6030 and twl6032.
Replaced some hardcoded values with the
structure vars.

Based on Balaji T K  patches for TI u-boot.

Signed-off-by: Oleg Kosheliev 
---
 drivers/power/twl6030.c |   25 -
 include/twl6030.h   |   18 ++
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
index 0858b60..6bf1a33 100644
--- a/drivers/power/twl6030.c
+++ b/drivers/power/twl6030.c
@@ -9,6 +9,17 @@
 
 #include 
 
+static struct twl6030_data *twl;
+
+static struct twl6030_data twl6030_info = {
+   .chip_type  = chip_TWL6030,
+   .adc_rbase  = GPCH0_LSB,
+   .adc_ctrl   = CTRL_P2,
+   .adc_enable = CTRL_P2_SP2,
+   .vbat_mult  = TWL6030_VBAT_MULT,
+   .vbat_shift = TWL6030_VBAT_SHIFT,
+};
+
 static int twl6030_gpadc_read_channel(u8 channel_no)
 {
u8 lsb = 0;
@@ -16,12 +27,12 @@ static int twl6030_gpadc_read_channel(u8 channel_no)
int ret = 0;
 
ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC,
- GPCH0_LSB + channel_no * 2, &lsb);
+ twl->adc_rbase + channel_no * 2, &lsb);
if (ret)
return ret;
 
ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC,
- GPCH0_MSB + channel_no * 2, &msb);
+ twl->adc_rbase + 1 + channel_no * 2, &msb);
if (ret)
return ret;
 
@@ -33,7 +44,8 @@ static int twl6030_gpadc_sw2_trigger(void)
u8 val;
int ret = 0;
 
-   ret = twl6030_i2c_write_u8(TWL6030_CHIP_ADC, CTRL_P2, CTRL_P2_SP2);
+   ret = twl6030_i2c_write_u8(TWL6030_CHIP_ADC,
+  twl->adc_ctrl, twl->adc_enable);
if (ret)
return ret;
 
@@ -41,7 +53,8 @@ static int twl6030_gpadc_sw2_trigger(void)
val =  CTRL_P2_BUSY;
 
while (!((val & CTRL_P2_EOCP2) && (!(val & CTRL_P2_BUSY {
-   ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC, CTRL_P2, &val);
+   ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC,
+ twl->adc_ctrl, &val);
if (ret)
return ret;
udelay(1000);
@@ -116,7 +129,7 @@ int twl6030_get_battery_voltage(void)
printf("Failed to read battery voltage\n");
return ret;
}
-   battery_volt = (battery_volt * 25 * 1000) >> (10 + 2);
+   battery_volt = (battery_volt * twl->vbat_mult) >> twl->vbat_shift;
printf("Battery Voltage: %d mV\n", battery_volt);
 
return battery_volt;
@@ -128,6 +141,8 @@ void twl6030_init_battery_charging(void)
int battery_volt = 0;
int ret = 0;
 
+   twl = &twl6030_info;
+
/* Enable VBAT measurement */
twl6030_i2c_write_u8(TWL6030_CHIP_PM, MISC1, VBAT_MEAS);
 
diff --git a/include/twl6030.h b/include/twl6030.h
index b4035ba..9399737 100644
--- a/include/twl6030.h
+++ b/include/twl6030.h
@@ -113,6 +113,24 @@
 #define GPCH0_LSB  0x57
 #define GPCH0_MSB  0x58
 
+#define TWL6030_VBAT_MULT  40 * 1000
+
+#define TWL6030_VBAT_SHIFT (10 + 3)
+
+enum twl603x_chip_type{
+   chip_TWL6030,
+   chip_TWL603X_cnt
+};
+
+struct twl6030_data{
+   u8 chip_type;
+   u8 adc_rbase;
+   u8 adc_ctrl;
+   u8 adc_enable;
+   int vbat_mult;
+   int vbat_shift;
+};
+
 /* Functions to read and write from TWL6030 */
 static inline int twl6030_i2c_write_u8(u8 chip_no, u8 reg, u8 val)
 {
-- 
1.7.9.5

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

[U-Boot] [PATCH] spi: Add GPL-2.0+ SPDX-License-Identifier for missing ones

[Jagannadha Sutradharudu Teki]

Added GPL-2.0+ SPDX-License-Identifier for missed spi
source files.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
 drivers/spi/sh_spi.c| 14 +-
 drivers/spi/tegra20_slink.c | 20 +++-
 include/spi_flash.h |  7 +--
 3 files changed, 5 insertions(+), 36 deletions(-)

diff --git a/drivers/spi/sh_spi.c b/drivers/spi/sh_spi.c
index 744afe3..07c80bb 100644
--- a/drivers/spi/sh_spi.c
+++ b/drivers/spi/sh_spi.c
@@ -3,19 +3,7 @@
  *
  * Copyright (C) 2011-2012 Renesas Solutions Corp.
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- *
+ * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
diff --git a/drivers/spi/tegra20_slink.c b/drivers/spi/tegra20_slink.c
index 664de6e..697cae0 100644
--- a/drivers/spi/tegra20_slink.c
+++ b/drivers/spi/tegra20_slink.c
@@ -1,24 +1,10 @@
 /*
  * NVIDIA Tegra SPI-SLINK controller
  *
- * Copyright (c) 2010-2013 NVIDIA Corporation
+ * Copyright (c) 2010-2013
+ * NVIDIA Corporation 
  *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
+ * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 1ff5af4..b961213 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -4,12 +4,7 @@
  * Copyright (C) 2008 Atmel Corporation
  * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
  *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program 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. 
+ * SPDX-License-Identifier:GPL-2.0+
  */
 
 #ifndef _SPI_FLASH_H_
-- 
1.8.3


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

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Rajeshwari Birje]

Hi Jagan,

We have  W25Q80BW on smdk5250 board.

Regards,
Rajeshwari.

On Tue, Oct 8, 2013 at 6:14 PM, Jagan Teki  wrote:
> On Tue, Oct 8, 2013 at 6:11 PM, Rajeshwari Birje
>  wrote:
>> Hi Jagan,
>>
>> Yes I have tested them on u-boot-spi.git/master for spi booting.
>
> Sorry for sequence of questions which spi flash parts you tested.?
>
>>
>> Regards,
>> Rajeshwari Shinde.
>>
>> On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  wrote:
>>> On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
>>>  wrote:
 This patchset has a set of patches which improves the
 performance of spi on exynos.
 Have combined all individual patches into a single patchset.
 Patches are based on u-boot-spi.git master branch.
>>>
>>> Thanks for your patch-set.
>>> Can you confirm, all these were tested against on u-boot-spi.git/master?
>>>
>>> --
>>> Thanks,
>>> Jagan.
>>> 
>>> Jagannadha Sutradharudu Teki,
>>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>>> Engineer - System Software Hacker
>>> U-boot - SPI Custodian and Zynq APSOC
>>> Ln: http://www.linkedin.com/in/jaganteki
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>>
>> --
>> Regards,
>> Rajeshwari Shinde
>
>
>
> --
> Thanks,
> Jagan.
> 
> Jagannadha Sutradharudu Teki,
> E: jagannadh.t...@gmail.com, P: +91-9676773388
> Engineer - System Software Hacker
> U-boot - SPI Custodian and Zynq APSOC
> Ln: http://www.linkedin.com/in/jaganteki



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

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Jagan Teki]

On Tue, Oct 8, 2013 at 6:34 PM, Rajeshwari Birje
 wrote:
> Hi Jagan,
>
> We have  W25Q80BW on smdk5250 board.

Great, thanks for quick response.

You missed one more patch http://patchwork.ozlabs.org/patch/247461/
may be you have a plan for sending this later, true?

>
> Regards,
> Rajeshwari.
>
> On Tue, Oct 8, 2013 at 6:14 PM, Jagan Teki  wrote:
>> On Tue, Oct 8, 2013 at 6:11 PM, Rajeshwari Birje
>>  wrote:
>>> Hi Jagan,
>>>
>>> Yes I have tested them on u-boot-spi.git/master for spi booting.
>>
>> Sorry for sequence of questions which spi flash parts you tested.?
>>
>>>
>>> Regards,
>>> Rajeshwari Shinde.
>>>
>>> On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  wrote:
 On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
  wrote:
> This patchset has a set of patches which improves the
> performance of spi on exynos.
> Have combined all individual patches into a single patchset.
> Patches are based on u-boot-spi.git master branch.

 Thanks for your patch-set.
 Can you confirm, all these were tested against on u-boot-spi.git/master?

 --
 Thanks,
 Jagan.
 
 Jagannadha Sutradharudu Teki,
 E: jagannadh.t...@gmail.com, P: +91-9676773388
 Engineer - System Software Hacker
 U-boot - SPI Custodian and Zynq APSOC
 Ln: http://www.linkedin.com/in/jaganteki
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Rajeshwari Shinde
>>
>>
>>
>> --
>> Thanks,
>> Jagan.
>> 
>> Jagannadha Sutradharudu Teki,
>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>> Engineer - System Software Hacker
>> U-boot - SPI Custodian and Zynq APSOC
>> Ln: http://www.linkedin.com/in/jaganteki
>
>
>
> --
> Regards,
> Rajeshwari Shinde



-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3] exynos: spl: Add a custom spi copy function

[Rajeshwari S Shinde]

This patch implements a custom spi_copy funtion to copy u-boot from SF
to RAM. This is faster then iROM spi_copy funtion as this runs spi at
50Mhz and also in WORD mode of operation.

Changed a printf in pinmux.c to debug just to avoid the compilation
error in SPL.

Signed-off-by: Alim Akhtar 
Signed-off-by: Tom Wai-Hong Tam 
Signed-off-by: Rajeshwari S Shinde 
---
Based on following patch yet to be merged:
"[U-Boot] [PATCH 4/4] spi: exynos: Support word transfers"
Changes in V2:
- Corrected the commit message.
- Added a SPI timeout check.
- Corrected the comments.
Changes in V3:
- Rebased on the latest u-boot-spi tree.
 arch/arm/cpu/armv7/exynos/pinmux.c |   2 +-
 arch/arm/cpu/armv7/exynos/spl_boot.c   | 122 -
 arch/arm/include/asm/arch-exynos/spi.h |   1 +
 include/configs/exynos5250-dt.h|   2 +
 4 files changed, 123 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 8002bce..74cc700 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -462,7 +462,7 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_SDMMC1:
case PERIPH_ID_SDMMC3:
case PERIPH_ID_SDMMC4:
-   printf("SDMMC device %d not implemented\n", peripheral);
+   debug("SDMMC device %d not implemented\n", peripheral);
return -1;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c 
b/arch/arm/cpu/armv7/exynos/spl_boot.c
index 3651c00..6faf13f 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -10,8 +10,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "common_setup.h"
 #include "clock_init.h"
@@ -59,6 +62,119 @@ static int config_branch_prediction(int set_cr_z)
 }
 #endif
 
+static void spi_rx_tx(struct exynos_spi *regs, int todo,
+   void *dinp, void const *doutp, int i)
+{
+   uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
+   int rx_lvl, tx_lvl;
+   uint out_bytes, in_bytes;
+
+   out_bytes = todo;
+   in_bytes = todo;
+   setbits_le32(®s->ch_cfg, SPI_CH_RST);
+   clrbits_le32(®s->ch_cfg, SPI_CH_RST);
+   writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
+
+   while (in_bytes) {
+   uint32_t spi_sts;
+   int temp;
+
+   spi_sts = readl(®s->spi_sts);
+   rx_lvl = ((spi_sts >> 15) & 0x7f);
+   tx_lvl = ((spi_sts >> 6) & 0x7f);
+   while (tx_lvl < 32 && out_bytes) {
+   temp = 0x;
+   writel(temp, ®s->tx_data);
+   out_bytes -= 4;
+   tx_lvl += 4;
+   }
+   while (rx_lvl >= 4 && in_bytes) {
+   temp = readl(®s->rx_data);
+   if (rxp)
+   *rxp++ = temp;
+   in_bytes -= 4;
+   rx_lvl -= 4;
+   }
+   }
+}
+
+/*
+ * Copy uboot from spi flash to RAM
+ *
+ * @parma uboot_size   size of u-boot to copy
+ * @param uboot_addr   address in u-boot to copy
+ */
+static void exynos_spi_copy(unsigned int uboot_size, unsigned int uboot_addr)
+{
+   int upto, todo;
+   int i, timeout = 100;
+   struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+
+   set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
+   /* set the spi1 GPIO */
+   exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
+
+   /* set pktcnt and enable it */
+   writel(4 | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
+   /* set FB_CLK_SEL */
+   writel(SPI_FB_DELAY_180, ®s->fb_clk);
+   /* set CH_WIDTH and BUS_WIDTH as word */
+   setbits_le32(®s->mode_cfg, SPI_MODE_CH_WIDTH_WORD |
+   SPI_MODE_BUS_WIDTH_WORD);
+   clrbits_le32(®s->ch_cfg, SPI_CH_CPOL_L); /* CPOL: active high */
+
+   /* clear rx and tx channel if set priveously */
+   clrbits_le32(®s->ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON);
+
+   setbits_le32(®s->swap_cfg, SPI_RX_SWAP_EN |
+   SPI_RX_BYTE_SWAP |
+   SPI_RX_HWORD_SWAP);
+
+   /* do a soft reset */
+   setbits_le32(®s->ch_cfg, SPI_CH_RST);
+   clrbits_le32(®s->ch_cfg, SPI_CH_RST);
+
+   /* now set rx and tx channel ON */
+   setbits_le32(®s->ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON | SPI_CH_HS_EN);
+   clrbits_le32(®s->cs_reg, SPI_SLAVE_SIG_INACT); /* CS low */
+
+   /* Send read instruction (0x3h) followed by a 24 bit addr */
+   writel((SF_READ_DATA_CMD << 24) | SPI_FLASH_UBOOT_POS, ®s->tx_data);
+
+   /* waiting for TX done */
+   while (!(readl(®s->spi_sts) &

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Rajeshwari Birje]

Hi Jagan,

Posted http://patchwork.ozlabs.org/patch/247461/ V3.
Posted it separately as it is arch/arm related.

Regards,
Rajeshwari

On Tue, Oct 8, 2013 at 6:36 PM, Jagan Teki  wrote:
> On Tue, Oct 8, 2013 at 6:34 PM, Rajeshwari Birje
>  wrote:
>> Hi Jagan,
>>
>> We have  W25Q80BW on smdk5250 board.
>
> Great, thanks for quick response.
>
> You missed one more patch http://patchwork.ozlabs.org/patch/247461/
> may be you have a plan for sending this later, true?
>
>>
>> Regards,
>> Rajeshwari.
>>
>> On Tue, Oct 8, 2013 at 6:14 PM, Jagan Teki  wrote:
>>> On Tue, Oct 8, 2013 at 6:11 PM, Rajeshwari Birje
>>>  wrote:
 Hi Jagan,

 Yes I have tested them on u-boot-spi.git/master for spi booting.
>>>
>>> Sorry for sequence of questions which spi flash parts you tested.?
>>>

 Regards,
 Rajeshwari Shinde.

 On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  
 wrote:
> On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
>  wrote:
>> This patchset has a set of patches which improves the
>> performance of spi on exynos.
>> Have combined all individual patches into a single patchset.
>> Patches are based on u-boot-spi.git master branch.
>
> Thanks for your patch-set.
> Can you confirm, all these were tested against on u-boot-spi.git/master?
>
> --
> Thanks,
> Jagan.
> 
> Jagannadha Sutradharudu Teki,
> E: jagannadh.t...@gmail.com, P: +91-9676773388
> Engineer - System Software Hacker
> U-boot - SPI Custodian and Zynq APSOC
> Ln: http://www.linkedin.com/in/jaganteki
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



 --
 Regards,
 Rajeshwari Shinde
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Jagan.
>>> 
>>> Jagannadha Sutradharudu Teki,
>>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>>> Engineer - System Software Hacker
>>> U-boot - SPI Custodian and Zynq APSOC
>>> Ln: http://www.linkedin.com/in/jaganteki
>>
>>
>>
>> --
>> Regards,
>> Rajeshwari Shinde
>
>
>
> --
> Thanks,
> Jagan.
> 
> Jagannadha Sutradharudu Teki,
> E: jagannadh.t...@gmail.com, P: +91-9676773388
> Engineer - System Software Hacker
> U-boot - SPI Custodian and Zynq APSOC
> Ln: http://www.linkedin.com/in/jaganteki



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

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Jagan Teki]

On Tue, Oct 8, 2013 at 6:42 PM, Rajeshwari Birje
 wrote:
> Hi Jagan,
>
> Posted http://patchwork.ozlabs.org/patch/247461/ V3.
> Posted it separately as it is arch/arm related.

OK, not a problem I thought it's pure spi.

I will apply spi patches, thanks for your time.

>
> Regards,
> Rajeshwari
>
> On Tue, Oct 8, 2013 at 6:36 PM, Jagan Teki  wrote:
>> On Tue, Oct 8, 2013 at 6:34 PM, Rajeshwari Birje
>>  wrote:
>>> Hi Jagan,
>>>
>>> We have  W25Q80BW on smdk5250 board.
>>
>> Great, thanks for quick response.
>>
>> You missed one more patch http://patchwork.ozlabs.org/patch/247461/
>> may be you have a plan for sending this later, true?
>>
>>>
>>> Regards,
>>> Rajeshwari.
>>>
>>> On Tue, Oct 8, 2013 at 6:14 PM, Jagan Teki  wrote:
 On Tue, Oct 8, 2013 at 6:11 PM, Rajeshwari Birje
  wrote:
> Hi Jagan,
>
> Yes I have tested them on u-boot-spi.git/master for spi booting.

 Sorry for sequence of questions which spi flash parts you tested.?

>
> Regards,
> Rajeshwari Shinde.
>
> On Tue, Oct 8, 2013 at 6:08 PM, Jagan Teki  
> wrote:
>> On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
>>  wrote:
>>> This patchset has a set of patches which improves the
>>> performance of spi on exynos.
>>> Have combined all individual patches into a single patchset.
>>> Patches are based on u-boot-spi.git master branch.
>>
>> Thanks for your patch-set.
>> Can you confirm, all these were tested against on u-boot-spi.git/master?
>>
>> --
>> Thanks,
>> Jagan.
>> 
>> Jagannadha Sutradharudu Teki,
>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>> Engineer - System Software Hacker
>> U-boot - SPI Custodian and Zynq APSOC
>> Ln: http://www.linkedin.com/in/jaganteki
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> Regards,
> Rajeshwari Shinde



 --
 Thanks,
 Jagan.
 
 Jagannadha Sutradharudu Teki,
 E: jagannadh.t...@gmail.com, P: +91-9676773388
 Engineer - System Software Hacker
 U-boot - SPI Custodian and Zynq APSOC
 Ln: http://www.linkedin.com/in/jaganteki
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Rajeshwari Shinde
>>
>>
>>
>> --
>> Thanks,
>> Jagan.
>> 
>> Jagannadha Sutradharudu Teki,
>> E: jagannadh.t...@gmail.com, P: +91-9676773388
>> Engineer - System Software Hacker
>> U-boot - SPI Custodian and Zynq APSOC
>> Ln: http://www.linkedin.com/in/jaganteki
>
>
>
> --
> Regards,
> Rajeshwari Shinde



-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] spi: exynos: Improve performance

[Jagan Teki]

On Tue, Oct 8, 2013 at 4:20 PM, Rajeshwari S Shinde
 wrote:
> This patchset has a set of patches which improves the
> performance of spi on exynos.
> Have combined all individual patches into a single patchset.
> Patches are based on u-boot-spi.git master branch.
>
> Rajeshwari S Shinde (3):
>   exynos: Export timer_get_us() to get microsecond timer
>   spi: exynos: Support a delay after deactivate
>   spi: exynos: Minimise access to SPI FIFO level
>   spi: exynos: Support word transfers
>
>  arch/arm/include/asm/arch-exynos/spi.h |  11 +++-
>  drivers/spi/exynos_spi.c   | 107 
> +++--
>  include/common.h   |   6 ++
>  3 files changed, 104 insertions(+), 20 deletions(-)

Applied to u-boot-spi/master

-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] env_mmc: fix buffer allocation for armv7

[Tom Rini]

On Mon, Oct 07, 2013 at 03:58:02PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20131007122020.GT15917@bill-the-cat> you wrote:
> > 
> > > But malloc() is drawing from the very same resource as the stack, even
> > > more so: with a buffer on the stack, the memory isfreed completeky
> > > upon return from the fucntion, with no reminders left.  With malloc()
> > > you need to statically allocate the malloc pool size for the whole
> > > runtime, and allocating the buffers may fragment tha area, so even
> > > after freeing the buffers there is less space left for other purposes.
> > > 
> > > Especially in memory-tight situations you want to avoid malloc().
> >
> > Ah, but in these cases we don't have stack room, period.  We have a
> > malloc pool.  So unless we make SPL move its stack pointer into DDR from
> > wherever we set the initial one to, the other option here is to just
> > restrict real env support to NOR (and we already don't allow embedded
> > env, since that's embedded within U-Boot, not SPL).
> 
> Well, if we have DDR such that we can use it for the malloc arena, we
> also should use it for the stack.  Or is there a good reason for not
> doing this?  It would solve all these issues at the root...

Making SPL more complex for everyone?  We would need to do a fairly
good-sized re-jigger of SPL to setup and swap around stack pointers like
we do in full U-Boot.

-- 
Tom


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

Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[FengHua]

> diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
> new file mode 100644
> index 000..47afe0b
> --- /dev/null
> +++ b/tools/relocate-rela.c
> @@ -0,0 +1,185 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+ BSD-2-Clause
> + *
> + * 64-bit and little-endian target only until we need to support a different
> + * arch that needs this.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const bool debug_en;
> +
> +static void debug(const char *fmt, ...)
> +{
> + va_list args;
> +
> + va_start(args, fmt);
> + if (debug_en)
> + vprintf(fmt, args);
> +}
> +
> +static bool supported_rela(Elf64_Rela *rela)
> +{
> + uint64_t mask = 0xULL; /* would be different on 32-bit */
> + uint32_t type = rela->r_info & mask;
> +
> + switch (type) {
> +#ifdef R_AARCH64_RELATIVE
> + case R_AARCH64_RELATIVE:
> + return true;
> +#endif

hi Scott,
 the R_AARCH64_RELATIVE is not deinfed in my system. Whether we should 
define it at somewhere?

David







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

Re: [U-Boot] [Patch v1 1/1] usb:smsx95xx LED activity for USB net driver

[Simon Glass]

+Joe (net maintainer)
+Marek (USB)

Hi Suriyan,

On Mon, Oct 7, 2013 at 9:30 PM, Suriyan Ramasami wrote:

> Add LED activity for SMSX95XX USB Ether driver.
>
> Signed-off-by: “Suriyan Ramasami" 
> ---
>  drivers/usb/eth/smsc95xx.c |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
> index 15fd9a9..7bf0a34 100644
> --- a/drivers/usb/eth/smsc95xx.c
> +++ b/drivers/usb/eth/smsc95xx.c
> @@ -14,6 +14,12 @@
>
>  /* SMSC LAN95xx based USB 2.0 Ethernet Devices */
>
> +/* LED defines */
> +#define LED_GPIO_CFG   (0x24)
> +#define LED_GPIO_CFG_SPD_LED   (0x0100)
> +#define LED_GPIO_CFG_LNK_LED   (0x0010)
> +#define LED_GPIO_CFG_FDX_LED   (0x0001)
> +
>  /* Tx command words */
>  #define TX_CMD_A_FIRST_SEG_0x2000
>  #define TX_CMD_A_LAST_SEG_ 0x1000
> @@ -591,6 +597,14 @@ static int smsc95xx_init(struct eth_device *eth, bd_t
> *bd)
> return ret;
> debug("ID_REV = 0x%08x\n", read_buf);
>
> +   /* Configure GPIO pins as LED outputs */
> +   write_buf = LED_GPIO_CFG_SPD_LED | LED_GPIO_CFG_LNK_LED |
> +   LED_GPIO_CFG_FDX_LED;
> +   ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, write_buf);
> +   if (ret < 0)
> +   return ret;
> +   debug("LED_GPIO_CFG set\n");
> +
>

Seems good.

Acked-by: Simon Glass 


> /* Init Tx */
> write_buf = 0;
> ret = smsc95xx_write_reg(dev, FLOW, write_buf);
> --
> 1.7.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[Scott Wood]

On Tue, 2013-10-08 at 22:22 +0800, FengHua wrote:
> > diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
> > new file mode 100644
> > index 000..47afe0b
> > --- /dev/null
> > +++ b/tools/relocate-rela.c
> > @@ -0,0 +1,185 @@
> > +/*
> > + * Copyright 2013 Freescale Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+ BSD-2-Clause
> > + *
> > + * 64-bit and little-endian target only until we need to support a 
> > different
> > + * arch that needs this.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const bool debug_en;
> > +
> > +static void debug(const char *fmt, ...)
> > +{
> > +   va_list args;
> > +
> > +   va_start(args, fmt);
> > +   if (debug_en)
> > +   vprintf(fmt, args);
> > +}
> > +
> > +static bool supported_rela(Elf64_Rela *rela)
> > +{
> > +   uint64_t mask = 0xULL; /* would be different on 32-bit */
> > +   uint32_t type = rela->r_info & mask;
> > +
> > +   switch (type) {
> > +#ifdef R_AARCH64_RELATIVE
> > +   case R_AARCH64_RELATIVE:
> > +   return true;
> > +#endif
> 
> hi Scott,
>  the R_AARCH64_RELATIVE is not deinfed in my system. Whether we should 
> define it at somewhere?

A newer host elf.h should fix this, but if it's going to be a problem
maybe we should just define it ourselves (value is 1027).

-Scott



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

[U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Tom Rini]

Upon further inspection and review and chatting with kernel folks, what
happens here is that what mmcblk# a device gets is based on probe order.
So a system with an SD card inserted with place eMMC on mmcblk1, but
without an SD card, it will be on mmcblk0.  So U-boot can only provide a
best guess.  In this case, if no SD card is present, we would want to
pass mmcblk0p2 still.  If an SD card is present, it woudl be able to
provide a uEnv.txt that would be loaded (even if the kernel is NOT
there) which can still update mmcroot variable.

This reverts commit 827512fb1154c05c6eb1e2259e936df55c98a535.

Cc: Robert P. J. Day 
Signed-off-by: Tom Rini 
---
 include/configs/am335x_evm.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index e8e5275..f746e48 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -171,7 +171,6 @@
"run mmcboot;" \
"setenv mmcdev 1; " \
"setenv bootpart 1:2; " \
-   "setenv mmcroot /dev/mmcblk1p2 ro; " \
"run mmcboot;" \
"run nandboot;"
 
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Robert P. J. Day]

On Tue, 8 Oct 2013, Tom Rini wrote:

> Upon further inspection and review and chatting with kernel folks, what
> happens here is that what mmcblk# a device gets is based on probe order.
> So a system with an SD card inserted with place eMMC on mmcblk1, but
> without an SD card, it will be on mmcblk0.  So U-boot can only provide a
> best guess.  In this case, if no SD card is present, we would want to
> pass mmcblk0p2 still.  If an SD card is present, it woudl be able to
> provide a uEnv.txt that would be loaded (even if the kernel is NOT
> there) which can still update mmcroot variable.
>
> This reverts commit 827512fb1154c05c6eb1e2259e936df55c98a535.
>
> Cc: Robert P. J. Day 
> Signed-off-by: Tom Rini 
> ---
>  include/configs/am335x_evm.h |1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index e8e5275..f746e48 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h
> @@ -171,7 +171,6 @@
>   "run mmcboot;" \
>   "setenv mmcdev 1; " \
>   "setenv bootpart 1:2; " \
> - "setenv mmcroot /dev/mmcblk1p2 ro; " \
>   "run mmcboot;" \
>   "run nandboot;"
>
> --
> 1.7.9.5

  are you sure about this? note that, in the above, you've *already*
tried to mmcboot off of device mmcblk0 and, for one reason or another,
that failed. so u-boot then *explicitly* switches to mmc dev 1 with:

  setenv mmcdev 1
  setenv bootpart 1:2

why would it not make sense to also switch mmcroot there as well?

rday

-- 


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

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

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

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/08/2013 11:34 AM, Robert P. J. Day wrote:
> On Tue, 8 Oct 2013, Tom Rini wrote:
> 
>> Upon further inspection and review and chatting with kernel folks, what
>> happens here is that what mmcblk# a device gets is based on probe order.
>> So a system with an SD card inserted with place eMMC on mmcblk1, but
>> without an SD card, it will be on mmcblk0.  So U-boot can only provide a
>> best guess.  In this case, if no SD card is present, we would want to
>> pass mmcblk0p2 still.  If an SD card is present, it woudl be able to
>> provide a uEnv.txt that would be loaded (even if the kernel is NOT
>> there) which can still update mmcroot variable.
>>
>> This reverts commit 827512fb1154c05c6eb1e2259e936df55c98a535.
>>
>> Cc: Robert P. J. Day 
>> Signed-off-by: Tom Rini 
>> ---
>>  include/configs/am335x_evm.h |1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
>> index e8e5275..f746e48 100644
>> --- a/include/configs/am335x_evm.h
>> +++ b/include/configs/am335x_evm.h
>> @@ -171,7 +171,6 @@
>>  "run mmcboot;" \
>>  "setenv mmcdev 1; " \
>>  "setenv bootpart 1:2; " \
>> -"setenv mmcroot /dev/mmcblk1p2 ro; " \
>>  "run mmcboot;" \
>>  "run nandboot;"
>>
>> --
>> 1.7.9.5
> 
>   are you sure about this? note that, in the above, you've *already*
> tried to mmcboot off of device mmcblk0 and, for one reason or another,
> that failed. so u-boot then *explicitly* switches to mmc dev 1 with:
> 
>   setenv mmcdev 1
>   setenv bootpart 1:2
> 
> why would it not make sense to also switch mmcroot there as well?

Yes, I'm very sure after talking with the kernel folks and playing with
a tree with all of the EDMA stuff fixed up so we can use modern kernels
again.  But you can see this on the vendor kernel BBB ships with too.
If you have an SD card and eMMC, SD card will be mmcblk0 and eMMC
mmcblk1.  If you however just root from eMMC, it will become mmcblk0.
The only time you have mmcblk1 is when you have both SD card inserted
and eMMC present.

Note that omap5 uevm has a different issue I shall be posting a patch
for soon, need to get the board back into my setup.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSVCqWAAoJENk4IS6UOR1WUtkP+wXraIrib77S9sWFY75230Dd
+Q4+x9HZ7AOsWX3M9SVSpKIzVhAMwrFoJWGEGwkd43YTMfDyTFT8FkJvLYu2jMRd
yk2LhDbEuju5Jy/yabrU8iq5VHCWnFsyNJ8S4dpshDK0H1ZL7mDrsMiPc183C8op
os+fYgN9IEOMf+vUVUBuWMtHGR0/UqyTwtrt+cwBsa2uzJQpOdfewssJ7+WY4B5I
4KZ4TkjxODrD2JGT5TbmU4oVPP4qq+nHOHdw7evOs//KdrPdhWyF/O/pyVKgDCB8
TL4xLTtityCgZF1RjI3p0pSiEVlJWTMq1RdnRWedhfh47Rdz3uZxHNkmFKMWs1sf
lVORRzt+ZYveW3ERcWgiRAycQ7EwfFEV2J/VtI6nh0P7KkjAP7M/fcbe2MM3U9ua
ckeF+w24rsprkXH8VAgU0M+UR+hqUC2me4YIY2oVDfTS0jPhdvw4W9P7SN4J+Lsg
KirIjOLGlG1dOQWDzGu/4DaUG2l0t0N2VBAXUV10R5fJdvVzx+ex6KT/tnMdcpza
PvobZbJAQoDTlf2KaU9fqIjMApQB1DD58WLuAW4XP6ni+ciPC8N2SZTIQnCeAqE+
fLgl6+1kaS0rOo8946GCAelQL8eADF68m4FOIzubzu27In4KGp29E7r1fhlLpBGv
ULxGh0iJeonV6wbLr939
=/UqY
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Tom Warren]

Jagan,


On Mon, Oct 7, 2013 at 11:23 PM, Jagan Teki wrote:

> On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren 
> wrote:
> > Tegra124 is compatible w/T114 SPI, so try to commonize as
> > much as possible.
> >
> > TEST=built all T1x4 boards, tested on Venice1 & 2 OK.
> > There's no real binary change here, just names/includes.
> >
> > Signed-off-by: Tom Warren 
> > ---
> >  .../tegra114_spi.h => arch-tegra/tegra1x4_spi.h}   |  6 +++---
> >  drivers/spi/Makefile   |  2 +-
> >  drivers/spi/fdt_spi.c  | 22
> --
> >  drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} | 22
> --
> >  4 files changed, 12 insertions(+), 40 deletions(-)
> >  rename arch/arm/include/asm/{arch-tegra114/tegra114_spi.h =>
> arch-tegra/tegra1x4_spi.h} (94%)
> >  rename drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} (92%)
> >
> > diff --git a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h
> b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> > similarity index 94%
> > rename from arch/arm/include/asm/arch-tegra114/tegra114_spi.h
> > rename to arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> > index 48197bc..93aa9ac 100644
> > --- a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h
> > +++ b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> > @@ -22,8 +22,8 @@
> >   * MA 02111-1307 USA
> >   */
> >
> > -#ifndef _TEGRA114_SPI_H_
> > -#define _TEGRA114_SPI_H_
> > +#ifndef _TEGRA1x4_SPI_H_
> > +#define _TEGRA1x4_SPI_H_
> >
> >  #include 
> >
> > @@ -38,4 +38,4 @@ void tegra114_spi_cs_deactivate(struct spi_slave
> *slave);
> >  int tegra114_spi_xfer(struct spi_slave *slave, unsigned int bitlen,
> >  const void *data_out, void *data_in, unsigned long
> flags);
> >
> > -#endif /* _TEGRA114_SPI_H_ */
> > +#endif /* _TEGRA1x4_SPI_H_ */
> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > index 91d24ce..8b72cf9 100644
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -37,7 +37,7 @@ COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
> >  COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
> >  COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
> >  COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
> > -COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
> > +COBJS-$(CONFIG_TEGRA114_SPI) += tegra1x4_spi.o
> >  COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o
> >  COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
> >
> > diff --git a/drivers/spi/fdt_spi.c b/drivers/spi/fdt_spi.c
> > index 58f139a..ee1b9f7 100644
> > --- a/drivers/spi/fdt_spi.c
> > +++ b/drivers/spi/fdt_spi.c
> > @@ -1,24 +1,10 @@
> >  /*
> >   * Common fdt based SPI driver front end
> >   *
> > - * Copyright (c) 2013 NVIDIA Corporation
> > + * (C) Copyright 2013
> > + * NVIDIA Corporation 
> >   *
> > - * See file CREDITS for list of people who contributed to this
> > - * project.
> > - *
> > - * This software is licensed under the terms of the GNU General Public
> > - * License version 2, as published by the Free Software Foundation, and
> > - * may be copied, distributed, and modified under those terms.
> > - *
> > - * This program 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.
> > - *
> > - * You should have received a copy of the GNU General Public License
> > - * along with this program; if not, write to the Free Software
> > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> > - * MA 02111-1307 USA
> > + * SPDX-License-Identifier: GPL-2.0+
> >   */
> >
> >  #include 
> > @@ -29,7 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > diff --git a/drivers/spi/tegra114_spi.c b/drivers/spi/tegra1x4_spi.c
> > similarity index 92%
> > rename from drivers/spi/tegra114_spi.c
> > rename to drivers/spi/tegra1x4_spi.c
> > index 4d2af48..2742443 100644
> > --- a/drivers/spi/tegra114_spi.c
> > +++ b/drivers/spi/tegra1x4_spi.c
> > @@ -1,24 +1,10 @@
> >  /*
> >   * NVIDIA Tegra SPI controller (T114 and later)
> >   *
> > - * Copyright (c) 2010-2013 NVIDIA Corporation
> > + * (C) Copyright 2010-2013
> > + * NVIDIA Corporation 
> >   *
> > - * See file CREDITS for list of people who contributed to this
> > - * project.
> > - *
> > - * This software is licensed under the terms of the GNU General Public
> > - * License version 2, as published by the Free Software Foundation, and
> > - * may be copied, distributed, and modified under those terms.
> > - *
> > - * This program 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.
> > - *
> > - * You should have received a copy of the GNU General Public License
> > - * along with this program; if no

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Jagan Teki]

On Tue, Oct 8, 2013 at 9:33 PM, Tom Warren  wrote:
> Jagan,
>
>
> On Mon, Oct 7, 2013 at 11:23 PM, Jagan Teki 
> wrote:
>>
>> On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren 
>> wrote:
>> > Tegra124 is compatible w/T114 SPI, so try to commonize as
>> > much as possible.
>> >
>> > TEST=built all T1x4 boards, tested on Venice1 & 2 OK.
>> > There's no real binary change here, just names/includes.
>> >
>> > Signed-off-by: Tom Warren 
>> > ---
>> >  .../tegra114_spi.h => arch-tegra/tegra1x4_spi.h}   |  6 +++---
>> >  drivers/spi/Makefile   |  2 +-
>> >  drivers/spi/fdt_spi.c  | 22
>> > --
>> >  drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} | 22
>> > --
>> >  4 files changed, 12 insertions(+), 40 deletions(-)
>> >  rename arch/arm/include/asm/{arch-tegra114/tegra114_spi.h =>
>> > arch-tegra/tegra1x4_spi.h} (94%)
>> >  rename drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} (92%)
>> >
>> > diff --git a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h
>> > b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
>> > similarity index 94%
>> > rename from arch/arm/include/asm/arch-tegra114/tegra114_spi.h
>> > rename to arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
>> > index 48197bc..93aa9ac 100644
>> > --- a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h
>> > +++ b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
>> > @@ -22,8 +22,8 @@
>> >   * MA 02111-1307 USA
>> >   */
>> >
>> > -#ifndef _TEGRA114_SPI_H_
>> > -#define _TEGRA114_SPI_H_
>> > +#ifndef _TEGRA1x4_SPI_H_
>> > +#define _TEGRA1x4_SPI_H_
>> >
>> >  #include 
>> >
>> > @@ -38,4 +38,4 @@ void tegra114_spi_cs_deactivate(struct spi_slave
>> > *slave);
>> >  int tegra114_spi_xfer(struct spi_slave *slave, unsigned int bitlen,
>> >  const void *data_out, void *data_in, unsigned long
>> > flags);
>> >
>> > -#endif /* _TEGRA114_SPI_H_ */
>> > +#endif /* _TEGRA1x4_SPI_H_ */
>> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> > index 91d24ce..8b72cf9 100644
>> > --- a/drivers/spi/Makefile
>> > +++ b/drivers/spi/Makefile
>> > @@ -37,7 +37,7 @@ COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
>> >  COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
>> >  COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
>> >  COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
>> > -COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
>> > +COBJS-$(CONFIG_TEGRA114_SPI) += tegra1x4_spi.o
>> >  COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o
>> >  COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
>> >
>> > diff --git a/drivers/spi/fdt_spi.c b/drivers/spi/fdt_spi.c
>> > index 58f139a..ee1b9f7 100644
>> > --- a/drivers/spi/fdt_spi.c
>> > +++ b/drivers/spi/fdt_spi.c
>> > @@ -1,24 +1,10 @@
>> >  /*
>> >   * Common fdt based SPI driver front end
>> >   *
>> > - * Copyright (c) 2013 NVIDIA Corporation
>> > + * (C) Copyright 2013
>> > + * NVIDIA Corporation 
>> >   *
>> > - * See file CREDITS for list of people who contributed to this
>> > - * project.
>> > - *
>> > - * This software is licensed under the terms of the GNU General Public
>> > - * License version 2, as published by the Free Software Foundation, and
>> > - * may be copied, distributed, and modified under those terms.
>> > - *
>> > - * This program 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.
>> > - *
>> > - * You should have received a copy of the GNU General Public License
>> > - * along with this program; if not, write to the Free Software
>> > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> > - * MA 02111-1307 USA
>> > + * SPDX-License-Identifier: GPL-2.0+
>> >   */
>> >
>> >  #include 
>> > @@ -29,7 +15,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > -#include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >
>> > diff --git a/drivers/spi/tegra114_spi.c b/drivers/spi/tegra1x4_spi.c
>> > similarity index 92%
>> > rename from drivers/spi/tegra114_spi.c
>> > rename to drivers/spi/tegra1x4_spi.c
>> > index 4d2af48..2742443 100644
>> > --- a/drivers/spi/tegra114_spi.c
>> > +++ b/drivers/spi/tegra1x4_spi.c
>> > @@ -1,24 +1,10 @@
>> >  /*
>> >   * NVIDIA Tegra SPI controller (T114 and later)
>> >   *
>> > - * Copyright (c) 2010-2013 NVIDIA Corporation
>> > + * (C) Copyright 2010-2013
>> > + * NVIDIA Corporation 
>> >   *
>> > - * See file CREDITS for list of people who contributed to this
>> > - * project.
>> > - *
>> > - * This software is licensed under the terms of the GNU General Public
>> > - * License version 2, as published by the Free Software Foundation, and
>> > - * may be copied, distributed, and modified under those terms.
>> > - *
>> > - * This program 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 P

[U-Boot] [PATCH v2] mmc: sdhci: Avoid commands errors by simple timeout adaptation.

[Przemyslaw Marczak]

Old command timeout value was too small and it caused I/O errors which
led to uncompleted read/write/erase operations and filesystem errors.
Timeout adaptation fixes this issue.

Changes in sdhci_send_command() function:
- change timeout variable to static
- increase default command timeout to 100 ms
- add definition of max command timeout value,
  which can be redefined in each board config file
- wait for card ready state for max defined time
  if it doesn't exceed defined maximum or return COMM_ERR

Once successfully increased timeout value will be used in next function
call. This fix was tested on Goni, Trats, Trats2 boards by testing UMS
on MMC storage.

Changes v2:
- move global variable cmd_timeout into function sdhci_send_command()
- change condition "==" to ">=" when comparing time with timeout
- print information about timeout increasing and card busy timeout

Signed-off-by: Przemyslaw Marczak 
Cc: Pantelis Antoniou 
---
 drivers/mmc/sdhci.c |   35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index dfb2eee..46ae9cb 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -109,6 +109,19 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
return 0;
 }
 
+/*
+ * No command will be sent by driver if card is busy, so driver must wait
+ * for card ready state.
+ * Every time when card is busy after timeout then (last) timeout value will be
+ * increased twice but only if it doesn't exceed global defined maximum.
+ * Each function call will use last timeout value. Max timeout can be redefined
+ * in board config file.
+ */
+#ifndef CONFIG_SDHCI_CMD_MAX_TIMEOUT
+#define CONFIG_SDHCI_CMD_MAX_TIMEOUT   3200
+#endif
+#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   100
+
 int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data)
 {
@@ -117,11 +130,12 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd 
*cmd,
int ret = 0;
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
-   unsigned int timeout, start_addr = 0;
+   unsigned int time = 0, start_addr = 0;
unsigned int retry = 1;
+   int mmc_dev = mmc->block_dev.dev;
 
-   /* Wait max 10 ms */
-   timeout = 10;
+   /* Timeout unit - ms */
+   static unsigned int cmd_timeout = CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT;
 
sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
@@ -132,11 +146,18 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd 
*cmd,
mask &= ~SDHCI_DATA_INHIBIT;
 
while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
-   if (timeout == 0) {
-   printf("Controller never released inhibit bit(s).\n");
-   return COMM_ERR;
+   if (time >= cmd_timeout) {
+   printf("MMC: %d busy ", mmc_dev);
+   if (2 * cmd_timeout <= CONFIG_SDHCI_CMD_MAX_TIMEOUT) {
+   cmd_timeout += cmd_timeout;
+   printf("timeout increasing to: %u ms.\n",
+  cmd_timeout);
+   } else {
+   puts("timeout.\n");
+   return COMM_ERR;
+   }
}
-   timeout--;
+   time++;
udelay(1000);
}
 
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Jagan Teki]

On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren  wrote:
> Tegra124 is compatible w/T114 SPI, so try to commonize as
> much as possible.
>
> TEST=built all T1x4 boards, tested on Venice1 & 2 OK.
> There's no real binary change here, just names/includes.
>
> Signed-off-by: Tom Warren 
> ---
>  .../tegra114_spi.h => arch-tegra/tegra1x4_spi.h}   |  6 +++---
>  drivers/spi/Makefile   |  2 +-
>  drivers/spi/fdt_spi.c  | 22 
> --
>  drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} | 22 
> --
>  4 files changed, 12 insertions(+), 40 deletions(-)
>  rename arch/arm/include/asm/{arch-tegra114/tegra114_spi.h => 
> arch-tegra/tegra1x4_spi.h} (94%)
>  rename drivers/spi/{tegra114_spi.c => tegra1x4_spi.c} (92%)
>
> diff --git a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h 
> b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> similarity index 94%
> rename from arch/arm/include/asm/arch-tegra114/tegra114_spi.h
> rename to arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> index 48197bc..93aa9ac 100644
> --- a/arch/arm/include/asm/arch-tegra114/tegra114_spi.h
> +++ b/arch/arm/include/asm/arch-tegra/tegra1x4_spi.h
> @@ -22,8 +22,8 @@
>   * MA 02111-1307 USA
>   */
>
> -#ifndef _TEGRA114_SPI_H_
> -#define _TEGRA114_SPI_H_
> +#ifndef _TEGRA1x4_SPI_H_
> +#define _TEGRA1x4_SPI_H_
>
>  #include 
>
> @@ -38,4 +38,4 @@ void tegra114_spi_cs_deactivate(struct spi_slave *slave);
>  int tegra114_spi_xfer(struct spi_slave *slave, unsigned int bitlen,
>  const void *data_out, void *data_in, unsigned long 
> flags);
>
> -#endif /* _TEGRA114_SPI_H_ */
> +#endif /* _TEGRA1x4_SPI_H_ */
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 91d24ce..8b72cf9 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -37,7 +37,7 @@ COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
>  COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
>  COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
>  COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
> -COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
> +COBJS-$(CONFIG_TEGRA114_SPI) += tegra1x4_spi.o
>  COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o
>  COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
>
> diff --git a/drivers/spi/fdt_spi.c b/drivers/spi/fdt_spi.c
> index 58f139a..ee1b9f7 100644
> --- a/drivers/spi/fdt_spi.c
> +++ b/drivers/spi/fdt_spi.c
> @@ -1,24 +1,10 @@
>  /*
>   * Common fdt based SPI driver front end
>   *
> - * Copyright (c) 2013 NVIDIA Corporation
> + * (C) Copyright 2013
> + * NVIDIA Corporation 
>   *
> - * See file CREDITS for list of people who contributed to this
> - * project.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> - * MA 02111-1307 USA
> + * SPDX-License-Identifier: GPL-2.0+
>   */
>
>  #include 
> @@ -29,7 +15,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>
> diff --git a/drivers/spi/tegra114_spi.c b/drivers/spi/tegra1x4_spi.c
> similarity index 92%
> rename from drivers/spi/tegra114_spi.c
> rename to drivers/spi/tegra1x4_spi.c
> index 4d2af48..2742443 100644
> --- a/drivers/spi/tegra114_spi.c
> +++ b/drivers/spi/tegra1x4_spi.c
> @@ -1,24 +1,10 @@
>  /*
>   * NVIDIA Tegra SPI controller (T114 and later)
>   *
> - * Copyright (c) 2010-2013 NVIDIA Corporation
> + * (C) Copyright 2010-2013
> + * NVIDIA Corporation 
>   *
> - * See file CREDITS for list of people who contributed to this
> - * project.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> - * MA 02111-1307 USA
> + * SPDX-License-Identifier: GPL-2.0+
>   */
>
>  #include 
> @@ -27,7 +13,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>
> --
> 1.8.1.5

Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[Scott Wood]

On Tue, 2013-10-08 at 10:10 +0200, Albert ARIBAUD wrote:
> Thanks Scott fot the heads-up. I have found the arm64 ABI and traced it
> back to this URL:
> 
> 
> 
> (Somehow the document can be read in Firefox but evince chokes on it)

It works for me in evince 3.6.1.

-Scott



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

Re: [U-Boot] [PATCH] mpc85xx: Fix the offset of register address error

[York Sun]

On 10/07/2013 08:28 PM, Tang Yuantian-B29983 wrote:
>>> diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> b/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> index 3d11884..87bb4a0 100644
>>> --- a/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> +++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> @@ -20,7 +20,7 @@
>>>  static inline void mpc85xx_gpio_set(unsigned int mask,
>>> unsigned int dir, unsigned int val)  {
>>> -   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
>>> +   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
>>>
>>> /* First mask off the unwanted parts of "dir" and "val" */
>>> dir &= mask;
>>> @@ -56,7 +56,7 @@ static inline void mpc85xx_gpio_set_high(unsigned
>>> int gpios)
>>>
>>>  static inline unsigned int mpc85xx_gpio_get(unsigned int mask)  {
>>> -   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
>>> +   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
>>>
>>> /* Read the requested values */
>>> return in_be32(&gpio->gpdat) & mask;
>>>
>>
>> Yuantian,
>>
>> Please go through the base address again. I think some SoCs do use 0xc00
>> offset from 0xF000, for eample P1020, P1023, MPC8572. I only spot checked
>> several.
>>
> 
> Hi York,
> I double checked the offset address of GPIO, I found that the offset 
> addresses of 
> GPIO on the boards you mentioned above are all changed to 0x0, not 0xc00 
> according
> to the newest RM.
> I do found that the offset address is 0xc00 in some old RMs.
> You can find the newest RM here: 
> For MPC8572: 
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223503931/226628079/226445024/MPC8572ERM_Rev3_DRAFT1.pdf?nodeid=226438746&vernum=-2
> For p1023:
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223506436/223521755/223743960/P1023RM_Mark-up.pdf?nodeid=229647544&vernum=-2
> for 1020:
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223506436/223522385/224515312/P1020RM_Rev6_Mark-up.pdf?nodeid=228476444&vernum=-2
> 
> If the offset addresses on these boards were 0xc00, the driver is still 
> wrong, because in that case
> The GPIO address should be: CONFIG_SYS_IMMR + 0xc00, not 
> CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00.
> (CONFIG_SYS_MPC85xx_GPIO_ADDR == CONFIG_SYS_IMMR + 
> CONFIG_SYS_MPC85xx_GPIO_OFFSET).
> 
> So, please apply this patch, I need the GPIO driver to operate GPIO.
> 

Looks you are correct. I find the changed offset on some published
documents as well (please use public link for discussion in the future).

York


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

Re: [U-Boot] [PATCH] mpc85xx: Fix the offset of register address error

[York Sun]

On 10/07/2013 08:28 PM, Tang Yuantian-B29983 wrote:
>>> diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> b/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> index 3d11884..87bb4a0 100644
>>> --- a/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> +++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
>>> @@ -20,7 +20,7 @@
>>>  static inline void mpc85xx_gpio_set(unsigned int mask,
>>> unsigned int dir, unsigned int val)  {
>>> -   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
>>> +   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
>>>
>>> /* First mask off the unwanted parts of "dir" and "val" */
>>> dir &= mask;
>>> @@ -56,7 +56,7 @@ static inline void mpc85xx_gpio_set_high(unsigned
>>> int gpios)
>>>
>>>  static inline unsigned int mpc85xx_gpio_get(unsigned int mask)  {
>>> -   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
>>> +   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
>>>
>>> /* Read the requested values */
>>> return in_be32(&gpio->gpdat) & mask;
>>>
>>
>> Yuantian,
>>
>> Please go through the base address again. I think some SoCs do use 0xc00
>> offset from 0xF000, for eample P1020, P1023, MPC8572. I only spot checked
>> several.
>>
> 
> Hi York,
> I double checked the offset address of GPIO, I found that the offset 
> addresses of 
> GPIO on the boards you mentioned above are all changed to 0x0, not 0xc00 
> according
> to the newest RM.
> I do found that the offset address is 0xc00 in some old RMs.
> You can find the newest RM here: 
> For MPC8572: 
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223503931/226628079/226445024/MPC8572ERM_Rev3_DRAFT1.pdf?nodeid=226438746&vernum=-2
> For p1023:
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223506436/223521755/223743960/P1023RM_Mark-up.pdf?nodeid=229647544&vernum=-2
> for 1020:
> http://compass.freescale.net/livelink/livelink/fetch/2001/3448/223475/200815/108253488/223469393/223506436/223522385/224515312/P1020RM_Rev6_Mark-up.pdf?nodeid=228476444&vernum=-2
> 
> If the offset addresses on these boards were 0xc00, the driver is still 
> wrong, because in that case
> The GPIO address should be: CONFIG_SYS_IMMR + 0xc00, not 
> CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00.
> (CONFIG_SYS_MPC85xx_GPIO_ADDR == CONFIG_SYS_IMMR + 
> CONFIG_SYS_MPC85xx_GPIO_OFFSET).
> 
> So, please apply this patch, I need the GPIO driver to operate GPIO.
> 
>


Please update the commit message to list all SoCs you have confirmed the
offset. And don't say "no reason to add 0xc00". The reason was clear
when the code was written. Reference manuals said so.

York


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

Re: [U-Boot] [PATCH v7 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

[Scott Wood]

On Tue, 2013-10-08 at 05:30 +, Gupta, Pekon wrote:
> > From: Scott Wood [mailto:scottw...@freescale.com]
> > > On Sat, 2013-10-05 at 06:11 +, Gupta, Pekon wrote:
> > > Hi,
> > > Please see the replies inline..
> > >
> > > > From: Scott Wood [mailto:scottw...@freescale.com]
> > > > > On Mon, 2013-09-30 at 19:43 +0530, Pekon Gupta wrote:
> > > > > +Platform specific options
> > > > > +=
> > > > > +
> > > > > +   CONFIG_NAND_OMAP_ECCSCHEME
> > > > > + On OMAP platforms, this specifies NAND ECC scheme.
> > > > > + 1 - HAM1_SW 1-bit Hamming code using software library
> > > > > + (for legacy devices only)
> > > > > + 2 - HAM1_HW 1-bit Hamming code using GPMC hardware engine
> > > > > + (for legacy devices only)
> > > > > + 3 - BCH4_SW 4-bit BCH code (unsupported)
> > > > > + 4 - BCH4_HW 4-bit BCH code (unsupported)
> > > > > + 5 - BCH8_SW 8-bit BCH code with
> > > > > + - ecc calculation using GPMC hardware engine,
> > > > > + - error detection using software library.
> > > > > + - requires CONFIG_BCH to enable software BCH
> > > > library
> > > > > + (For legacy device which do not have ELM h/w
> > > > engine)
> > > > > + 6 - BCH8_HW 8-bit BCH code with
> > > > > + - ecc calculation using GPMC hardware engine,
> > > > > + - error detection using ELM hardware engine.
> > > >
> > > > You should document the symbols, not the numbers that happen to be
> > > > assigned to them.
> > > >
> > > Sorry din't get you. This is based on your below feedback
> > > http://lists.denx.de/pipermail/u-boot/2013-September/162773.html
> > >
> > > Example: "6 - BCH8_HW" means 8-bit BCH ECC scheme using h/w engine.
> > > It is this number is what user needs to specify in include/configs/*.h
> > > Any other internal symbol like "OMAP_ECC_BCH8_CODE_SW" should
> > > not be exposed to user, user-interface should remain constant.
> > 
> > I disagree.  The user should specify OMAP_ECC_BCH8_CODE_SW.  It's more
> > greppable, and it's more likely that the number will change than that
> > the name will.
> > 
> Ok, accepted.
> 
> 
> > >  This is similar to DT binding approach used in linux. Internal symbols 
> > > are not
> > > exposed to users.
> > 
> > This is a shortcoming of device trees that we should not emulate in C
> > code.
> > 
> Don't know if its short-coming of device-tree or difference between
> u-boot and kernel ideologies. But use of internal symbols (enums) in DT
> was  opposed by one of the kernel maintainers. Refer below:
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/047030.html

It's a different situation.  The device tree is supposed to be stable
ABI.  This isn't.  The device tree is also supposed to be OS-independent
and thus taking Linux identifiers as-is is frowned upon (as the Linux
identifiers may change, plus device tree properties use a different
style for naming).

It's not a general difference between U-Boot and Linux.

> > > > > +/**
> > > > > + * omap_select_ecc_scheme - configures driver for particular ecc-
> > scheme
> > > > > + * @nand: NAND chip device structure
> > > > > + * @ecc_scheme: ecc scheme to configure
> > > > > + * @pagesize: number of main-area bytes per page of NAND device
> > > > > + * @oobsize: number of OOB/spare bytes per page of NAND device
> > > > > + */
> > > > > +static int omap_select_ecc_scheme(struct nand_chip *nand, int
> > > > ecc_scheme,
> > > > > + unsigned int pagesize, unsigned int oobsize) {
> > > >
> > > > s/int ecc_scheme/enum omap_ecc ecc_scheme/
> > > >
> > > If this is only the cosmetic change, may be I'll take it separately
> > > in another patch. Also 'omap_select_ecc_scheme()' has default
> > > statement in last, which gracefully handles all un-supported ecc-schemes.
> > >
> > > [snip]
> > >
> > > > > + /* check if NAND spare/OOB has enough bytes to accomodate
> > > > ecclayout */
> > > > > + if ((ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH) > oobsize)
> > > > {
> > > > > + printf("nand: error: insufficient OOB bytes. 
> > > > > require=%d\n", (
> > > > > + ecclayout->eccbytes +
> > > > BADBLOCK_MARKER_LENGTH));
> > > > > + return -EINVAL;
> > > > > + }
> > > >
> > > > Check this before you make any changes to the current ECC setup.
> > > >
> > > 'ecclayout->eccbytes' depends on ECC scheme selected, therefore
> > > this check cannot be done before selecting ECC scheme first.
> > 
> > It certainly can be done before you make any changes to the ECC struct.
> > 
> > You could either do it in each individual case, or you could have two
> > separate switch statements with this code in between them.
> > 
> Having 2 switch statements would clutter the code. Isn't it ?
> (1) first switch-case would do a dry-run to check the ecc requirements.
> (2) seco

Re: [U-Boot] fs/fs.c - error handling needed?

[Simon Glass]

Hi Wolfgang,

On Sat, Oct 5, 2013 at 1:49 PM, Wolfgang Denk  wrote:

> Dear Simon,
>
> with commit a8f6ab5 "fs: Add support for saving data to filesystems"
> you add the function do_save() to U-Boot.  This includes the following
> code (line numbers as of current master):
>
> "fs/fs.c":
>
> ...
> 331 filename = argv[3];
> 332 addr = simple_strtoul(argv[4], NULL, cmdline_base);
> 333 bytes = simple_strtoul(argv[5], NULL, cmdline_base);
> 334 if (argc >= 7)
> 335 pos = simple_strtoul(argv[6], NULL, cmdline_base);
> 336 else
> 337 pos = 0;
>
>
> Should we not perform at least minimal error checking, i. e. verify
> that no garbage arguments have been passed to that function?
>

Do you mean passing an 'endp' parameter instead of NULL to simple_strtoul()
and checking that it processed at least one character? I compared it to
do_load() and it seems similar.

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

Re: [U-Boot] [PATCH 0/5] ARM: Exynos5250: consolidate configuration files

[Simon Glass]

Hi Andre,

On Wed, Sep 25, 2013 at 4:42 AM, Andre Przywara
wrote:

> Hi,
>
> while working on HYP mode support for Exynos 5250 based boards, I
> fixed some shortcomings in their configuration files.
>
> The purpose of this series is to get rid of the elaborate arndale.h
> and replace it mostly by an include of exynos5250-dt.h, which
> currently has an about 90% overlap.
> I couldn't find any prior art, please bear with me if I have missed
> something on the list.
>
> * Patch 1 fixes a bug, where PMIC support would not have been included
> in the Arndale build.
> * Patch 2 removes double definitions.
> Those two should be considered regardless of the others.
> * Patch 3 prepares the consolidation of the config files by moving
> board specific defines out of the generic file.
> * Patch 4 makes keyboard and LCD support board dependent, please have
> a closer look at this. I guess SMDK5250 does not have the EC, but it
> breaks compilation if that is excluded.
> * Patch 5 then finally removes the now redundant defines in arndale.h
> and replaces them with an include of exynos5250-dt.h.
>
> This series is mostly refactoring, though the config options change
> a bit for some boards. I could only compile test it, so please test
> it if you have the hardware.
>

I'd like to adjust the approach slightly. The idea with exynos5250-dt.h is
that it mirrors the exynos5250-dt.c file in the kernel - it is intended
that we can create a U-Boot that will run on any Exynos 5250 board, with an
appropriate device tree file provided. In short I'd like to create an
'exynos5250-dt' board config.

Your series moves towards exynos5250-dt.h just being a common file used by
many boards. So can we rename this file, perhaps to exynos5250-common.h,
before making your changes? Then I can do a patch to add the generic
Exynos5250 board.

Regards,
Simon


>
> Thanks!
> Andre
>
> Signed-off-by: Andre Przywara 
>
>
> Andre Przywara (5):
>   ARM: Exynos5250: rename obsoleted CONFIG_PMIC defines
>   ARM: Exynos5250: remove redundant defines in exynos5250-dt.h
>   ARM: Exynos5250: move feature defines out of generic config file
>   ARM: snow: move defines for Chromebook embedded controller
>   ARM: Arndale: include generic exynos5250-dt.h in arndale.h
>
>  drivers/power/power_fsl.c   |   2 +-
>  include/configs/arndale.h   | 242
> +---
>  include/configs/exynos5250-dt.h |  63 ---
>  include/configs/smdk5250.h  |  11 +-
>  include/configs/snow.h  |  11 +-
>  5 files changed, 47 insertions(+), 282 deletions(-)
>
> --
> 1.7.12.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 3/5] mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes

[Scott Wood]

On Mon, 2013-09-30 at 19:43 +0530, Pekon Gupta wrote:
> + /* ECC scheme specific syndrome customizations */
> + switch (bch->ecc_scheme) {
> + case OMAP_ECC_HAM1_CODE_HW:
> + break;
> + case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
> +#ifdef CONFIG_BCH
> + for (i = 0; i < chip->ecc.bytes; i++)
> + *(ecc_code + i) = *(ecc_code + i) ^
> + bch8_polynomial[i];
> +#endif
> + break;
> + case OMAP_ECC_BCH8_CODE_HW:
> + ecc_code[chip->ecc.bytes - 1] = 0x00;
> + break;
> + default:
> + return -EINVAL;
>   }

Shouldn't "case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:" be inside the
"#ifdef CONFIG_BCH" so that you get -EINVAL if the implementation isn't
there?

-Scott



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

Re: [U-Boot] [PATCH 01/10 V4] EXYNOS5: Create a common board file

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> Create a common board.c file for all functions which are common across
> all EXYNOS5 platforms.
>
> exynos_init function is provided for platform specific code.
>
> Signed-off-by: Rajeshwari S Shinde 
>

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

Re: [U-Boot] [PATCH 02/10 V4] Exynos5420: Add base addresses for 5420

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> Adds base addresses of various IPs and controllers required for
> Exynos5420.
>
> Signed-off-by: Hatim Ali 
> Signed-off-by: Rajeshwari S Shinde 
> Signed-off-by: Akshay Saraswat 
>

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

Re: [U-Boot] [PATCH 05/10 V4] Exynos5420: Add support for 5420 in pinmux and gpio

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> Adds code in pinmux and gpio framework to support Exynos5420.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Akshay Saraswat 
> Signed-off-by: Rajeshwari S Shinde 
>

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

Re: [U-Boot] [PATCH v7 4/5] mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes

[Scott Wood]

On Mon, 2013-09-30 at 19:43 +0530, Pekon Gupta wrote:
> + /* check calculated ecc */
> + for (i = 0; i < chip->ecc.bytes && !ecc_flag; i++)
> + if (calc_ecc[i] != 0x00)
> + ecc_flag = 1;

U-Boot code style wants braces around multi-line bodies.

-Scott



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

Re: [U-Boot] [PATCH 06/10 V4] Exynos5420: Add base patch for SMDK5420

[Simon Glass]

Hi Rajeshwari,

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> Adding the base patch for Exynos based SMDK5420.
> This shall enable compilation and basic boot support for
> SMDK5420.
>
> Signed-off-by: Rajeshwari S Shinde 
> Signed-off-by: Akshay Saraswat 
> ---
> Changes in V2:
> - None
> Changes in V3:
> - None
> Changes in V4:
> - Rebased on latest u-boot-samsung tree.
>  board/samsung/common/board.c  |   2 +
>  board/samsung/smdk5420/Makefile   |  34 +
>  board/samsung/smdk5420/smdk5420.c | 253
> ++
>  board/samsung/smdk5420/smdk5420_spl.c |  52 +++
>  boards.cfg|   1 +
>  tools/Makefile|   2 +
>  6 files changed, 344 insertions(+)
>  create mode 100644 board/samsung/smdk5420/Makefile
>  create mode 100644 board/samsung/smdk5420/smdk5420.c
>  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 7193c90..ce85ddb 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -139,6 +139,7 @@ struct cros_ec_dev *board_get_cros_ec_dev(void)
> return local.cros_ec_dev;
>  }
>
> +#ifdef CONFIG_CROS_EC
>  static int board_init_cros_ec_devices(const void *blob)
>  {
> local.cros_ec_err = cros_ec_init(blob, &local.cros_ec_dev);
> @@ -147,6 +148,7 @@ static int board_init_cros_ec_devices(const void *blob)
>
> return 0;
>  }
> +#endif
>
>  #if defined(CONFIG_POWER)
>  #ifdef CONFIG_POWER_MAX77686
> diff --git a/board/samsung/smdk5420/Makefile
> b/board/samsung/smdk5420/Makefile
> new file mode 100644
> index 000..be538ec
> --- /dev/null
> +++ b/board/samsung/smdk5420/Makefile
> @@ -0,0 +1,34 @@
> +#
> +# Copyright (C) 2013 Samsung Electronics
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB= $(obj)lib$(BOARD).o
> +
> +COBJS  += smdk5420_spl.o
> +
> +ifndef CONFIG_SPL_BUILD
> +COBJS  += smdk5420.o
> +endif
> +
> +SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> +OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
> +
> +ALL:=   $(obj).depend $(LIB)
> +
> +all:   $(ALL)
> +
> +$(LIB):$(OBJS)
> +   $(call cmd_link_o_target, $(OBJS))
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/samsung/smdk5420/smdk5420.c
> b/board/samsung/smdk5420/smdk5420.c
> new file mode 100644
> index 000..cf76455
> --- /dev/null
> +++ b/board/samsung/smdk5420/smdk5420.c
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright (C) 2013 Samsung Electronics
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifdef CONFIG_USB_EHCI_EXYNOS
> +static int board_usb_vbus_init(void)
> +{
> +   struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
> +
> samsung_get_base_gpio_part1();
> +
> +   /* Enable VBUS power switch */
> +   s5p_gpio_direction_output(&gpio1->x2, 6, 1);
> +
> +   /* VBUS turn ON time */
> +   mdelay(3);
> +
> +   return 0;
> +}
> +#endif
> +
> +int exynos_init(void)
> +{
> +#ifdef CONFIG_USB_EHCI_EXYNOS
> +   board_usb_vbus_init();
> +#endif
> +   return 0;
> +}
> +
> +static int decode_sromc(const void *blob, struct fdt_sromc *config)
> +{
> +   int err;
> +   int node;
> +
> +   node = fdtdec_next_compatible(blob, 0,
> COMPAT_SAMSUNG_EXYNOS5_SROMC);
> +   if (node < 0) {
> +   debug("Could not find SROMC node\n");
> +   return node;
> +   }
> +
> +   config->bank = fdtdec_get_int(blob, node, "bank", 0);
> +   config->width = fdtdec_get_int(blob, node, "width", 2);
> +
> +   err = fdtdec_get_int_array(blob, node, "srom-timing",
> config->timing,
> +   FDT_SROM_TIMING_COUNT);
> +   if (err < 0) {
> +   debug("Could not decode SROMC configuration Error: %s\n",
> + fdt_strerror(err));
> +   return -FDT_ERR_NOTFOUND;
> +   }
> +   return 0;
> +}
> +
> +int board_eth_init(bd_t *bis)
> +{
> +#ifdef CONFIG_SMC911X
> +   u32 smc_bw_conf, smc_bc_conf;
> +   struct fdt_sromc config;
> +   fdt_addr_t base_addr;
> +   int node;
> +
> +   node = decode_sromc(gd->fdt_blob, &config);
> +   if (node < 0) {
> +   debug("%s: Could not find sromc configuration\n",
> __func__);
> +   return 0;
> +   }
> +   node = fdtdec_next_compatible(gd->fdt_blob, node,
> COMPAT_SMSC_LAN9215);
> 

Re: [U-Boot] [PATCH 07/10 V4] DTS: Add dts support for SMDK5420

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> This patch adds support for SMDK5420.
> exynos5.dtsi created is a common file which has the nodes common
> to both 5420 and 5250.
>
> Signed-off-by: Akshay Saraswat 
> Signed-off-by: Rajeshwari S Shinde 
>

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

Re: [U-Boot] [PATCH v7 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

[Scott Wood]

On Tue, 2013-10-08 at 11:52 -0500, Scott Wood wrote:
> On Tue, 2013-10-08 at 05:30 +, Gupta, Pekon wrote:
> > Anyways I would take the changes if you wish so..
> > But request you to please provide comments on all the patches, before
> > I send next revision. This would help me consolidate all changes.
> 
> I'm working on it, but I also have a lot of other patches to review, and
> doing nothing but patch reviews all day long can be very draining (not
> to mention starving other tasks that need to be done), and reviewing
> patches for hardware I'm not familiar with is even worse.  I realize
> that the delays can be frustrating from your end, but I only have so
> much time and energy to expend.  Is there nobody else who's familiar
> with this driver that can help review?  Looking at the commit history no
> single person stands out as a logical maintainer for this driver.  It
> would be nice to designate someone.
> 
> > So, should I wait for review of other remaining patches before
> > sending next version v8 of this series ?
> 
> Yes.

OK, I've scanned the rest of the patches and given some minor feedback. 

-Scott



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

Re: [U-Boot] [PATCH 08/10 V4] Config: Add initial config for SMDK5420

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> Adding initial config for SMDK5420 to build and boot U-Boot
> over Exynos based SMDK5420.
>
> Signed-off-by: Rajeshwari S Shinde 
> Signed-off-by: Akshay Saraswat 
>

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

Re: [U-Boot] [PATCH 09/10 V4] SPL: EXYNOS: Prepare for variable size SPL support

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> When variable size SPL is used, the BL1 expects the SPL to be
> encapsulated differently: instead of putting the checksum at a fixed
> offset in the SPL blob, prepend the blob with a header including the
> size and the checksum.
>
> The enhancements include
> - adding a command line option, '--vs' to indicate the need for the
> variable size encapsulation
> - padding the fixed size encapsulated blob with 0xff instead of
> random
> memory contents
> - do not silently truncate the input file, report error instead
> - no need to explicitly closing files/freeing memory, this all
> happens
> on exit; removing cleanups it makes code clearer
> - profuse commenting
> - modify Makefile to allow enabling the new feature per board
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Rajeshwari S Shinde 
>

Acked-by: Simon Glass 

Where is the new BL1 published, please?

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

Re: [U-Boot] [PATCH 10/10 V4] DWMMC: SMDK5420: Disable SMU for eMMC

[Simon Glass]

On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
rajeshwar...@samsung.com> wrote:

> SMDK5420 has a new Security Management Unit added
> for dwmmc driver, hence, configuring the control
> registers to support booting via eMMC.
>
> Signed-off-by: Alim Akhtar 
> Signed-off-by: Rajeshwari Shinde 
>

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

Re: [U-Boot] [PATCH V2 1/6] exynos: Use common pmic_reg_update() definition

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> This function is used by different Exynos platforms, put it in the
> common file.
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Doug Anderson 
>

Acked-by: Simon Glass 

(I'd suggest adding a full comment to pmic_reg_update() if you end up
re-issuing this)


> ---
>  board/samsung/common/board.c |   19 ---
>  drivers/power/power_core.c   |   19 +++
>  include/power/pmic.h |1 +
>  3 files changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index ce85ddb..87ca9de 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -152,25 +152,6 @@ static int board_init_cros_ec_devices(const void
> *blob)
>
>  #if defined(CONFIG_POWER)
>  #ifdef CONFIG_POWER_MAX77686
> -static int pmic_reg_update(struct pmic *p, int reg, uint regval)
> -{
> -   u32 val;
> -   int ret = 0;
> -
> -   ret = pmic_reg_read(p, reg, &val);
> -   if (ret) {
> -   debug("%s: PMIC %d register read failed\n", __func__, reg);
> -   return -1;
> -   }
> -   val |= regval;
> -   ret = pmic_reg_write(p, reg, val);
> -   if (ret) {
> -   debug("%s: PMIC %d register write failed\n", __func__,
> reg);
> -   return -1;
> -   }
> -   return 0;
> -}
> -
>  static int max77686_init(void)
>  {
> struct pmic *p;
> diff --git a/drivers/power/power_core.c b/drivers/power/power_core.c
> index d79971b..2bef594 100644
> --- a/drivers/power/power_core.c
> +++ b/drivers/power/power_core.c
> @@ -205,6 +205,25 @@ int do_pmic(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> return CMD_RET_SUCCESS;
>  }
>
> +int pmic_reg_update(struct pmic *p, int reg, uint regval)
> +{
> +   u32 val;
> +   int ret = 0;
> +
> +   ret = pmic_reg_read(p, reg, &val);
> +   if (ret) {
> +   debug("%s: PMIC %d register read failed\n", __func__, reg);
> +   return -1;
> +   }
> +   val |= regval;
> +   ret = pmic_reg_write(p, reg, val);
> +   if (ret) {
> +   debug("%s: PMIC %d register write failed\n", __func__,
> reg);
> +   return -1;
> +   }
> +   return 0;
> +}
> +
>  U_BOOT_CMD(
> pmic,   CONFIG_SYS_MAXARGS, 1, do_pmic,
> "PMIC",
> diff --git a/include/power/pmic.h b/include/power/pmic.h
> index 0e7aa31..d17dbdc 100644
> --- a/include/power/pmic.h
> +++ b/include/power/pmic.h
> @@ -83,6 +83,7 @@ int pmic_probe(struct pmic *p);
>  int pmic_reg_read(struct pmic *p, u32 reg, u32 *val);
>  int pmic_reg_write(struct pmic *p, u32 reg, u32 val);
>  int pmic_set_output(struct pmic *p, u32 reg, int ldo, int on);
> +int pmic_reg_update(struct pmic *p, int reg, uint regval);
>
>  #define pmic_i2c_addr (p->hw.i2c.addr)
>  #define pmic_i2c_tx_num (p->hw.i2c.tx_num)
> --
> 1.7.10.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/6] power: Explicitly select pmic device's bus

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> The current pmic i2c code assumes the current i2c bus is
> the same as the pmic device's bus. There is nothing ensuring
> that to be true. Therefore, select the proper bus before performing
> a transaction.
>
> Signed-off-by: Aaron Durbin 
> Signed-off-by: Simon Glass 
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Doug Anderson 
>

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

Re: [U-Boot] [PATCH V2 3/6] FDT: Exynos5420: Add compatible srings for PMIC

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> Add required compatible strings for PMIC S2MPS11
>
> Signed-off-by: Leela Krishna Amudala 
>

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

Re: [U-Boot] [PATCH V2 4/6] SMDK5420: S2MPS11: Adds the register settings for S2MPS11

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> Adds the register settings, addresses and voltages associated with S2MPS11
>
> Signed-off-by: Alim Akhtar 
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Vadim Bendebury 
>

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

Re: [U-Boot] [PATCH V2 5/6] exynos: Add a common DT based PMIC driver initialization

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> Most of i2c PMIC drivers follow the same initialization sequence,
> let's generalize it in a common file.
>
> The initialization function finds the PMIC in the device tree, and if
> found - registers it in the list of known PMICs and initializes it,
> iterating through the table of settings supplied by the caller.
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Leela Krishna Amudala 
> Reviewed-by: Doug Anderson 
>

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

Re: [U-Boot] [PATCH V2 6/6] config: SMDK5420: Enable S2MPS11 pmic

[Simon Glass]

On Mon, Oct 7, 2013 at 1:26 AM, Leela Krishna Amudala  wrote:

> configure S2MPS11 pmic on SMDK5420
>
> Signed-off-by: Leela Krishna Amudala 
>

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

Re: [U-Boot] [PATCH] env_mmc: fix buffer allocation for armv7

[Wolfgang Denk]

Dear Tom,

In message <20131008134456.GB15917@bill-the-cat> you wrote:
> 
> > Well, if we have DDR such that we can use it for the malloc arena, we
> > also should use it for the stack.  Or is there a good reason for not
> > doing this?  It would solve all these issues at the root...
> 
> Making SPL more complex for everyone?  We would need to do a fairly
> good-sized re-jigger of SPL to setup and swap around stack pointers like
> we do in full U-Boot.

Hm,  I'm not convinced.  As proposed, we make the code bigger, less
efficient, more error prone and more ugly for everyone, not only for
SPL users.  Aslo, this might not be the only place where buffers or
such may be kept on the stack.  I hope you don't want to change all
these?

Really, if we have the resources, we should use them.  If RAM is
abailable, it should also be used for the stack.  Just using it for
malloc() is neither fish nor fowl.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Have you lived in this village all your life?""No, not yet."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

[Gupta, Pekon]

Hi,

> On Tue, 2013-10-08 at 11:52 -0500, Scott Wood wrote:
> > On Tue, 2013-10-08 at 05:30 +, Gupta, Pekon wrote:
> > Anyways I would take the changes if you wish so..
> > But request you to please provide comments on all the patches, before
> > I send next revision. This would help me consolidate all changes.
>
> I'm working on it, but I also have a lot of other patches to review, and
> doing nothing but patch reviews all day long can be very draining (not
> to mention starving other tasks that need to be done), and reviewing
> patches for hardware I'm not familiar with is even worse.  I realize
> that the delays can be frustrating from your end, but I only have so
> much time and energy to expend.
> 
Firstly my apologies for being bit aggressive in getting patches
reviewed. Yes, I was bit irritated as patch re-submissions were
taking much of my energy and time as well, while lot of other things
are still pending on me to cleanup this driver and add functionality to it.

And I understand the patch reviewing is tough because reviewer
needs to first understand the driver & hardware context, and then
reply from a broader point of view of generic frame-work.


>   Is there nobody else who's familiar
> with this driver that can help review?  Looking at the commit history no
> single person stands out as a logical maintainer for this driver.  It
> would be nice to designate someone.
> 
Currently I'm the only supporting NAND driver in both kernel and
u-boot from omap side. And therefore, I plan to get both u-boot and 
kernel nand drivers cleaned-up and optimized, so that it becomes
scalable for future enhancements.
Aim is to get most of end-users to boot from mainline, so that they
are self dependent and up-to-date to new frameworks.

Once I'm done with my current commitments, I can help you in getting
some enhancements for generic framework.
For example, following patch adds checks for automatic bus-width
detection in generic NAND framework.
http://lists.denx.de/pipermail/u-boot/2013-September/163882.html

Hope such things help reduce some of your load.
And thanks again for the reviews, I'll submit next revision of patch soon.


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

[U-Boot] [PATCH] da850evm.h: Always set CONFIG_CMD_SF, move to by CONFIG_SPI_FLASH

[Tom Rini]

When we have CONFIG_SPI_FLASH set we now require CONFIG_CMD_SF.

Signed-off-by: Tom Rini 
---
 include/configs/da850evm.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index e63d7c4..9845506 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -147,6 +147,7 @@
 #define CONFIG_SPI_FLASH
 #define CONFIG_SPI_FLASH_STMICRO
 #define CONFIG_SPI_FLASH_WINBOND
+#define CONFIG_CMD_SF
 #define CONFIG_DAVINCI_SPI
 #define CONFIG_SYS_SPI_BASEDAVINCI_SPI1_BASE
 #define CONFIG_SYS_SPI_CLK clk_get(DAVINCI_SPI1_CLKID)
@@ -334,7 +335,6 @@
 #undef CONFIG_CMD_IMLS
 #undef CONFIG_CMD_FLASH
 #define CONFIG_CMD_SPI
-#define CONFIG_CMD_SF
 #define CONFIG_CMD_SAVEENV
 #endif
 
-- 
1.7.9.5

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Oct 07, 2013 at 07:52:24PM +0530, Jagannadha Sutradharudu Teki wrote:

> Hi Tom,
> 
> Just released pull request with new sf probe support.
> Tested these changes on stmicro, winbond, spansion and sst.
> 
> --
> Thanks,
> Jagan.
> 
> The following changes since commit f835c77fb7e57508ffe8d8ca3a092ee28add77b2:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-arm (2013-10-04 13:17:48 
> -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 3cfcf774c270ecf6289203d88f859d1f91cb318e:
> 
>   doc: SPI: Update SPI status track (2013-10-07 19:35:10 +0530)
> 
> 
> Jagannadha Sutradharudu Teki (35):
>   sf: Divide spi_flash into multiple parts
>   sf: probe: Add new spi_flash_probe support
>   sf: probe: Add support for M25P* flash parts
>   sf: probe: Add support for EN25Q* flash parts
>   sf: probe: Add support for GD25* flash parts
>   sf: probe: Add support for MX25L* flash parts
>   sf: probe: Add support for W25* flash parts
>   sf: probe: Add support for S25FL* flash parts
>   sf: probe: Add support for SST25* flash parts
>   sf: probe: Add support for AT45DB* flash parts
>   sf: probe: Give proper spacing on flash table params
>   sf: probe: Add support for SST_WP
>   sf: probe: Add support to clear flash BP# bits
>   sf: probe: Add support for erase sector selection flag
>   sf: probe: Add support for flag status polling
>   sf: probe: Simply the BAR configuration logic
>   sf: Add proper comment style on spi_flash structure
>   sf: ramtron: Add support for separate flash driver
>   sf: Remove unneeded flash drivers files
>   sf: probe: Add support for EN25Q64
>   sf: probe: Add support for S25FL256S_256K
>   sf: probe: Add support for S25FL512S_256K
>   sf: probe: Use print_size arg as page_size
>   sf: probe: Print erase_size while printing flash details
>   sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write
>   sf: probe: Add support for MX25L25635F
>   sf: probe: Add support for MX25L51235F
>   sf: Remove spi_flash_do_alloc references
>   sf: spi_flash cleanups
>   spi: spi cleanups
>   sf: Rename spi_flash files
>   doc: SPI: Add status.txt for tracking SPI subsys status
>   sf: Minor cleanups
>   sf: ramtron: Remove page_size print
>   doc: SPI: Update SPI status track
> 
> Matt Porter (3):
>   omap5: add qspi support
>   spi: add TI QSPI driver
>   dra7xx_evm: add SPL API, QSPI, and serial flash support
> 
> Poddar, Sourav (3):
>   armv7: hw_data: change clock divider setting.
>   sf: Add memory mapped read support
>   README: qspi usecase and testing documentation.
> 
> Priyanka Jain (1):
>   sf: probe: Add support for EN25S64
> 
>  arch/arm/cpu/armv7/omap5/hw_data.c |  10 +-
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |   1 +
>  arch/arm/include/asm/arch-omap5/omap.h |   3 +
>  arch/arm/include/asm/arch-omap5/spl.h  |   1 +
>  arch/arm/include/asm/omap_common.h |   1 +
>  board/ti/dra7xx/mux_data.h |  10 +
>  doc/SPI/README.ti_qspi_dra_test|  48 ++
>  doc/SPI/README.ti_qspi_flash   |  47 ++
>  doc/SPI/status.txt |  31 ++
>  drivers/mtd/spi/Makefile   |  15 +-
>  drivers/mtd/spi/atmel.c| 544 --
>  drivers/mtd/spi/eon.c  |  60 --
>  drivers/mtd/spi/gigadevice.c   |  65 ---
>  drivers/mtd/spi/macronix.c |  98 
>  drivers/mtd/spi/ramtron.c  | 122 +++-
>  drivers/mtd/spi/sf.c   |  54 ++
>  .../spi/{spi_flash_internal.h => sf_internal.h}| 140 ++---
>  drivers/mtd/spi/sf_ops.c   | 405 ++
>  drivers/mtd/spi/sf_probe.c | 363 
>  drivers/mtd/spi/spansion.c | 141 -
>  drivers/mtd/spi/spi_flash.c| 615 
> -
>  drivers/mtd/spi/sst.c  | 238 
>  drivers/mtd/spi/stmicro.c  | 202 ---
>  drivers/mtd/spi/winbond.c  | 141 -
>  drivers/spi/Makefile   |   1 +
>  drivers/spi/ti_qspi.c  | 311 +++
>  include/configs/dra7xx_evm.h   |  19 +
>  include/configs/top9000.h  |   1 -
>  include/spi.h  | 100 ++--
>  include/spi_flash.h| 103 ++--
>  30 files changed, 1592 insertions(+), 2298 deletions(-)
>  create mode 100644 doc/SPI/READM

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Tom Rini]

On Tue, Oct 08, 2013 at 11:12:32AM -0400, Tom Rini wrote:

> Upon further inspection and review and chatting with kernel folks, what
> happens here is that what mmcblk# a device gets is based on probe order.
> So a system with an SD card inserted with place eMMC on mmcblk1, but
> without an SD card, it will be on mmcblk0.  So U-boot can only provide a
> best guess.  In this case, if no SD card is present, we would want to
> pass mmcblk0p2 still.  If an SD card is present, it woudl be able to
> provide a uEnv.txt that would be loaded (even if the kernel is NOT
> there) which can still update mmcroot variable.
> 
> This reverts commit 827512fb1154c05c6eb1e2259e936df55c98a535.
> 
> Cc: Robert P. J. Day 
> Signed-off-by: Tom Rini 

Applied to u-boot/master.

-- 
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] Pull request: u-boot-arm/master

[Tom Rini]

On Mon, Oct 07, 2013 at 10:02:08PM +0200, Albert ARIBAUD wrote:

> Hello Tom,
> 
> The following changes since commit
> e261c83aa04ce0396d57aaecf8dfe0970ffac03e:
> 
>   ARM: VExpress: enable ARMv7 virt support for VExpress A15 (2013-10-03
>   21:28:57 +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.De/u-boot-arm master
> 
> for you to fetch changes up to 572886af5984febafa6f083e6b8af0465f4f5764:
> 
>   socfpga: Adding pin mux handoff files (2013-10-07 19:32:30 +0200)
> 
> 
> Albert ARIBAUD (1):
>   omap1510inn: arm925t: remove support
> 
> Andrew Murray (1):
>   usb: Fix error handling in musb_hcd.c
> 
> Chin Liang See (2):
>   socfpga: Adding System Manager driver
>   socfpga: Adding pin mux handoff files
> 
> Enric Balletbo i Serra (1):
>   ARM: IGEP0033: Update timing to run DDR at 400MHz.
> 
> Lars Poeschel (1):
>   pcm051/igep0033: Supply bd_ram_ofs for cpsw driver
> 
> Tom Rini (1):
>   am335x_evm: Switch to zImage as default rather than uImage
> 
>  MAKEALL|   1 -
>  README |   1 -
>  arch/arm/cpu/arm925t/Makefile  |  34 --
>  arch/arm/cpu/arm925t/config.mk |  15 -
>  arch/arm/cpu/arm925t/cpu.c |  50 ---
>  arch/arm/cpu/arm925t/omap925.c |  23 --
>  arch/arm/cpu/arm925t/start.S   | 382
>  -
>  arch/arm/cpu/arm925t/timer.c   | 104 --
>  arch/arm/cpu/armv7/socfpga/Makefile|   2 +-
>  arch/arm/cpu/armv7/socfpga/spl.c   |   6 +
>  arch/arm/cpu/armv7/socfpga/system_manager.c|  27 ++
>  arch/arm/include/asm/arch-am33xx/ddr_defs.h|  24
>  +- .../include/asm/arch-socfpga/socfpga_base_addrs.h  |   1 +
>  arch/arm/include/asm/arch-socfpga/system_manager.h |  22 ++
>  board/altera/socfpga/Makefile  |   4 +-
>  board/altera/socfpga/pinmux_config.c   | 214 
>  board/altera/socfpga/pinmux_config.h   |  54 +++
>  board/isee/igep0033/board.c|   5 +-
>  board/phytec/pcm051/board.c|   1 +
>  board/ti/omap1510inn/Makefile  |  29 --
>  board/ti/omap1510inn/config.mk |  25 --
>  board/ti/omap1510inn/lowlevel_init.S   | 380
>  
>  board/ti/omap1510inn/omap1510innovator.c   | 125 ---
>  boards.cfg |   1 -
>  doc/README.scrapyard   |   3 +-
>  drivers/usb/musb/musb_hcd.c|  10 +-
>  include/arm925t.h  |  11 -
>  include/configs/am335x_evm.h   |  22 +-
>  include/configs/omap1510inn.h  | 166 -
>  include/configs/socfpga_cyclone5.h |   1 + 30 files
>  changed, 363 insertions(+), 1380 deletions(-) delete mode 100644
>  arch/arm/cpu/arm925t/Makefile delete mode 100644
>  arch/arm/cpu/arm925t/config.mk delete mode 100644
>  arch/arm/cpu/arm925t/cpu.c delete mode 100644
>  arch/arm/cpu/arm925t/omap925.c delete mode 100644
>  arch/arm/cpu/arm925t/start.S delete mode 100644
>  arch/arm/cpu/arm925t/timer.c create mode 100644
>  arch/arm/cpu/armv7/socfpga/system_manager.c create mode 100644
>  arch/arm/include/asm/arch-socfpga/system_manager.h create mode 100644
>  board/altera/socfpga/pinmux_config.c create mode 100644
>  board/altera/socfpga/pinmux_config.h delete mode 100644
>  board/ti/omap1510inn/Makefile delete mode 100644
>  board/ti/omap1510inn/config.mk delete mode 100644
>  board/ti/omap1510inn/lowlevel_init.S delete mode 100644
>  board/ti/omap1510inn/omap1510innovator.c delete mode 100644
>  include/arm925t.h delete mode 100644 include/configs/omap1510inn.h

Applied to u-boot/master, 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] config.mk: enable -fstack-usage only when it is desired

[Jeroen Hofstee]

Hello Masahiro,

On 09/30/2013 10:01 AM, Masahiro Yamada wrote:

Hello Jeroen,


diff --git a/config.mk b/config.mk
index 48913f6..177f685 100644
--- a/config.mk
+++ b/config.mk
@@ -117,7 +117,7 @@ CC_TEST_OFILE :=
$(OBJTREE)/include/generated/cc_test_file.o
   -include $(CC_OPTIONS_CACHE_FILE)

   cc-option-sys = $(shell mkdir -p $(dir $(CC_TEST_OFILE)); \
-   if $(CC) $(CFLAGS) $(1) -S -xc /dev/null -o
$(CC_TEST_OFILE) \
+   if $(CC) -Werror $(CFLAGS) $(1) -S -xc /dev/null -o
$(CC_TEST_OFILE) \
  > /dev/null 2>&1; then \
  echo 'CC_OPTIONS += $(strip $1)' >>
$(CC_OPTIONS_CACHE_FILE); \
  echo "$(1)"; fi)



It looks like this was already suggested by Tom too.
See http://patchwork.ozlabs.org/patch/183174/

I tested this patch but unfortunatelly it did not work.


I downloaded bfin-linux-gcc 4.6.3 from
ftp://ftp.kernel.org/pub/tools/crosstool/index.html

I added -Werror to config.mk and I tried:

 CROSS_COMPILE=bfin-linux- ./MAKEALL -a blackfin

The log message was still sprinkled with lots of warnings like
warning: -fstack-usage not supported for this target [enabled by default]

So, I looked into it more closely and
I found gcc can compile the input file /dev/null successfully
even if -fstack-usage is not supported.


 $ bfin-uclinux-gcc -fstack-usage -S -xc /dev/null
 $ echo $?
 0
 $ bfin-uclinux-gcc -Werror -fstack-usage -S -xc /dev/null
 $ echo $?
 0



Instead of /dev/null, I prepared a very simple C source code as an input.

 $ cat test.c
 int test(void)
 {
 return 0;
 }
 $ bfin-uclinux-gcc -fstack-usage -S -xc test.c
 test.c: In function 'test':
 test.c:4:1: warning: -fstack-usage not supported for this target [enabled 
by default]
 $ echo $?
 0
 $ bfin-uclinux-gcc -fstack-usage -Werror -S -xc test.c
 test.c: In function 'test':
 test.c:4:1: error: -fstack-usage not supported for this target [-Werror]
 cc1: all warnings being treated as errors
 $ echo $?
 1

This time we can detect unsupported -fstack-usage by the exit status.

So, along with -Werror, I think /dev/null should also be replaced
with some _REAL_ C source file.
But my concern about this treak is we might go far from Kbuild.
In Linux Kernel, cc-option is impilemented in scripts/Kbuild.include.
It uses /dev/null as input.
I wish U-Boot would someday adopt (not nessarily the same but very
similar) Kbuild.

If you see Linux Kernel top Makefile,
many of optional CFLAGS are provided thru cc-option and
also can be turned on/off by CONFIG_ switch.

That is one reason I suggested to introduce CONFIG_CC_STACKUSAGE option.
But this is just my opinion and I would not necessarily stick to this idea.
Please feel free to suggest your thought.




I tried to google this a bit, one thing I found was
http://sourceware.org/bugzilla/show_bug.cgi?id=5210, but I fail
to (easily) find a reliable gcc reference. Perhaps we should
file a bug? -Werror doesn't work with /dev/null when
-fstack-usage is not supported...

I cannot comment on your concern regarding Kbuild, since I
am unaware of its internals. I just suggested above since
it would be a cleaner approach (if it worked...).

Regards,
Jeroen





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

[U-Boot] [PATCH] SPDX: document dual license notation

[Wolfgang Denk]

In [1] we discussed how we should deal with dual (or, more generally,
multiple) licensed files.  Add this to  Licenses/README  so it's
properly documented.

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/166518

Signed-off-by: Wolfgang Denk 
---
 Licenses/README | 12 
 1 file changed, 12 insertions(+)

diff --git a/Licenses/README b/Licenses/README
index 9f61192..6dd7d5b 100644
--- a/Licenses/README
+++ b/Licenses/README
@@ -37,6 +37,18 @@ replaced by a single line:
 
SPDX-License-Identifier:GPL-2.0+
 
+Ideally, the license terms of all files in the source tree should be
+defined by such License Identifiers; in no case a file can contain
+more than one such License Identifier.
+
+If a "SPDX-License-Identifier:" line references more than one Unique
+License Identifier, then this means that the respective file can be
+used under the terms of either of these licenses, i. e. with
+
+   SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+
+you can chose between GPL-2.0+ and BSD-3-Clause licensing.
+
 We use the SPDX Unique License Identifiers here; these are available
 at [2].
 
-- 
1.8.3.1

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

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Robert P. J. Day]

On Tue, 8 Oct 2013, Tom Rini wrote:

... snip ...

> Applied to u-boot/master.

  dumb question but what does it mean to say "Applied to
u-boot/master" when it clearly has not been applied to master? i can
see posts like that, but doing a "git pull" produces nothing. i am on
the u-boot mainline, and the "master" branch, so what am i
misunderstanding? thanks.

rday

-- 


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

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

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

Re: [U-Boot] [PATCH] SPDX: document dual license notation

[Stephen Warren]

On 10/08/2013 01:53 PM, Wolfgang Denk wrote:
> In [1] we discussed how we should deal with dual (or, more generally,
> multiple) licensed files.  Add this to  Licenses/README  so it's
> properly documented.
> 
> [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/166518
> 
> Signed-off-by: Wolfgang Denk 
> ---
>  Licenses/README | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Licenses/README b/Licenses/README
> index 9f61192..6dd7d5b 100644
> --- a/Licenses/README
> +++ b/Licenses/README
> @@ -37,6 +37,18 @@ replaced by a single line:
>  
>   SPDX-License-Identifier:GPL-2.0+
>  
> +Ideally, the license terms of all files in the source tree should be
> +defined by such License Identifiers; in no case a file can contain
> +more than one such License Identifier.

I assume "one such License Identifier" here is intended to mean: a
source line prefixed with the words "SPDX-License-Identifier:". However,
to me "one such License Identifier" would actually refer to the
"GPL-2.0+" part of the line, since that's what actually identifies the
license. The other text simply introduces a list of license identifiers.
That would then conflict with the rest of the patch that goes on to
explicitly state that multiple licenses are allowed.

In other words, I think that text can be confusing. I think you need to
add "line", "list" or "set" to the end of the sentence to make it
unambiguous.

> +If a "SPDX-License-Identifier:" line references more than one Unique
> +License Identifier, then this means that the respective file can be
> +used under the terms of either of these licenses, i. e. with
> +
> + SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
> +
> +you can chose between GPL-2.0+ and BSD-3-Clause licensing.

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

[U-Boot] [PATCH] arm: Tegra: T114: Use common tegra1x4- includes in arch-tegra

[Tom Warren]

A previous commit created common arch-tegra/tegra1x4-xxx header
files for T124, based on the existing T114 headers (HW is nearly
100% compatible for most blocks). Now that T124 support is in,
move T114 over to use those common headers (which are actually
copies of the T114 headers). Some headers aren't shared, such
as clk_rst.h, gpio.h, pmc.h, etc. as they have extra regs/bits
for T124.

Signed-off-by: Tom Warren 
---
 arch/arm/include/asm/arch-tegra114/ahb.h  |  13 +
 arch/arm/include/asm/arch-tegra114/clock-tables.h |  15 +-
 arch/arm/include/asm/arch-tegra114/clock.h|  21 +-
 arch/arm/include/asm/arch-tegra114/emc.h  |  13 +
 arch/arm/include/asm/arch-tegra114/flow.h |  30 +-
 arch/arm/include/asm/arch-tegra114/funcmux.h  |  15 +-
 arch/arm/include/asm/arch-tegra114/fuse.h |  13 +
 arch/arm/include/asm/arch-tegra114/gp_padctrl.h   |  78 +
 arch/arm/include/asm/arch-tegra114/gpio.h |  15 +-
 arch/arm/include/asm/arch-tegra114/hardware.h |  15 +-
 arch/arm/include/asm/arch-tegra114/pinmux.h   |  15 +-
 arch/arm/include/asm/arch-tegra114/pmc.h  | 343 ++
 arch/arm/include/asm/arch-tegra114/pmu.h  |  18 +-
 arch/arm/include/asm/arch-tegra114/spl.h  |  15 +-
 arch/arm/include/asm/arch-tegra114/sysctr.h   |  30 +-
 arch/arm/include/asm/arch-tegra114/tegra.h|  15 +-
 arch/arm/include/asm/arch-tegra114/usb.h  | 153 +-
 17 files changed, 428 insertions(+), 389 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra114/ahb.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/emc.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/fuse.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pmc.h

diff --git a/arch/arm/include/asm/arch-tegra114/ahb.h 
b/arch/arm/include/asm/arch-tegra114/ahb.h
new file mode 100644
index 000..a65943b
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra114/ahb.h
@@ -0,0 +1,13 @@
+/*
+ * (C) Copyright 2013
+ * NVIDIA Corporation 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _TEGRA114_AHB_H_
+#define _TEGRA114_AHB_H_
+
+#include 
+
+#endif /* _TEGRA114_AHB_H_ */
diff --git a/arch/arm/include/asm/arch-tegra114/clock-tables.h 
b/arch/arm/include/asm/arch-tegra114/clock-tables.h
index 19b8acf..2df960b 100644
--- a/arch/arm/include/asm/arch-tegra114/clock-tables.h
+++ b/arch/arm/include/asm/arch-tegra114/clock-tables.h
@@ -1,17 +1,8 @@
 /*
- * Copyright (c) 2010-2013, NVIDIA CORPORATION.  All rights reserved.
+ * (C) Copyright 2010-2013
+ * NVIDIA Corporation 
  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 /* Tegra114 clock PLL tables */
diff --git a/arch/arm/include/asm/arch-tegra114/clock.h 
b/arch/arm/include/asm/arch-tegra114/clock.h
index abbefcd..b64d803 100644
--- a/arch/arm/include/asm/arch-tegra114/clock.h
+++ b/arch/arm/include/asm/arch-tegra114/clock.h
@@ -1,17 +1,8 @@
 /*
- * Copyright (c) 2010-2013, NVIDIA CORPORATION.  All rights reserved.
+ * (C) Copyright 2013
+ * NVIDIA Corporation 
  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 /* Tegra114 clock control functions */
@@ -19,10 +10,6 @@
 #ifndef _TEGRA114_CLOCK_H_
 #define _TEGRA114_CLOCK_H_
 
-#include 
-
-/* CLK_RST_CONTROLLER_OSC_CTRL_0 */
-#define OSC_FREQ_SHIFT  28
-#define OSC_FREQ_MASK   (0xF << OSC_FREQ_SHIFT)
+#include 
 
 #endif /* _TEGRA114_CLOCK_H_ */
diff --git a/arch/arm/include/asm/arch-tegra114/emc.h 
b/arch/arm/include/asm/arch-tegra114/emc.h
new file mode 100644
index 000..82db639
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra114/emc.h
@@ -0,0 +1,13 @@
+/*
+ * (C) Copyright 2013
+ * NVIDIA Corporation 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _TEGRA114_EMC_H_
+#define _TEGRA114_EMC_H_
+
+#in

[U-Boot] [PATCH] arm: Tegra: Use arch-specific pmc.h where needed, else use common pmc.h

[Tom Warren]

PMC block for T20/T30 is able to use a common header, but T1x4 has
added registers and/or moved registers around, so these SoCs need
a arch-specific pmc.h.

Built all Tegra AOK, tested on T114 Dalmore and T124 Venice OK.

Signed-off-by: Tom Warren 
---
 arch/arm/cpu/arm720t/tegra-common/cpu.c|  2 +-
 arch/arm/cpu/arm720t/tegra114/cpu.c|  4 ++--
 arch/arm/cpu/arm720t/tegra20/cpu.c |  2 +-
 arch/arm/cpu/arm720t/tegra30/cpu.c |  2 +-
 arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c |  2 +-
 arch/arm/cpu/tegra-common/ap.c |  2 +-
 arch/arm/cpu/tegra-common/board.c  |  2 +-
 arch/arm/cpu/tegra20-common/warmboot.c |  2 +-
 arch/arm/cpu/tegra20-common/warmboot_avp.c |  2 +-
 arch/arm/include/asm/arch-tegra124/pmc.h   |  4 ++--
 arch/arm/include/asm/arch-tegra20/pmc.h| 14 ++
 arch/arm/include/asm/arch-tegra30/pmc.h| 15 +++
 board/nvidia/common/board.c|  2 +-
 13 files changed, 42 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra20/pmc.h
 create mode 100644 arch/arm/include/asm/arch-tegra30/pmc.h

diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index fbe553a..aea5c2b 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -10,9 +10,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include "cpu.h"
 
diff --git a/arch/arm/cpu/arm720t/tegra114/cpu.c 
b/arch/arm/cpu/arm720t/tegra114/cpu.c
index 844299b..e55847e 100644
--- a/arch/arm/cpu/arm720t/tegra114/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra114/cpu.c
@@ -19,9 +19,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include "../tegra-common/cpu.h"
 
 /* Tegra114-specific CPU init code */
@@ -211,7 +211,7 @@ static int is_clamp_enabled(u32 mask)
struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
u32 reg;
 
-   /* Get clamp status. TODO: Add pmc_clamp_status alias to pmc.h */
+   /* Get clamp status */
reg = readl(&pmc->pmc_clamp_status);
return (reg & mask) == mask;
 }
diff --git a/arch/arm/cpu/arm720t/tegra20/cpu.c 
b/arch/arm/cpu/arm720t/tegra20/cpu.c
index 2533899..ebd6fbe 100644
--- a/arch/arm/cpu/arm720t/tegra20/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra20/cpu.c
@@ -16,8 +16,8 @@
 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include "../tegra-common/cpu.h"
 
 static void enable_cpu_power_rail(void)
diff --git a/arch/arm/cpu/arm720t/tegra30/cpu.c 
b/arch/arm/cpu/arm720t/tegra30/cpu.c
index e162357..2e7423f 100644
--- a/arch/arm/cpu/arm720t/tegra30/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra30/cpu.c
@@ -18,9 +18,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include "../tegra-common/cpu.h"
 
diff --git a/arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c 
b/arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c
index a94ec93..45f0f4d 100644
--- a/arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c
+++ b/arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c
@@ -26,8 +26,8 @@
  */
 
 #include 
+#include 
 #include 
-#include 
 
 static int do_enterrcm(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
index c2c4a0b..6233305 100644
--- a/arch/arm/cpu/tegra-common/ap.c
+++ b/arch/arm/cpu/tegra-common/ap.c
@@ -10,10 +10,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/cpu/tegra-common/board.c 
b/arch/arm/cpu/tegra-common/board.c
index 2c9613e..b4675c7 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -9,9 +9,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/cpu/tegra20-common/warmboot.c 
b/arch/arm/cpu/tegra20-common/warmboot.c
index 8beba53..0969753 100644
--- a/arch/arm/cpu/tegra20-common/warmboot.c
+++ b/arch/arm/cpu/tegra20-common/warmboot.c
@@ -11,12 +11,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/cpu/tegra20-common/warmboot_avp.c 
b/arch/arm/cpu/tegra20-common/warmboot_avp.c
index b910f78..224d10d 100644
--- a/arch/arm/cpu/tegra20-common/warmboot_avp.c
+++ b/arch/arm/cpu/tegra20-common/warmboot_avp.c
@@ -10,10 +10,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "warmboot_avp.h"
 
diff --git a/arch/arm/include/asm/arch-tegra124/pmc.h 
b/arch/arm/include/asm/arch-tegra124/pmc.h
index fa6ef10..08080e2 100644
--- a/arch/arm/include/asm/arch-tegra124/pmc.h
+++ b/arch/arm/include/asm/arch-tegra124/pmc.h
@@ -1,6 +1,6 @@
 /*
- *  (C) Copyright 2013
- *  NVI

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Robert Nelson]

On Tue, Oct 8, 2013 at 3:39 PM, Robert P. J. Day  wrote:
> On Tue, 8 Oct 2013, Tom Rini wrote:
>
> ... snip ...
>
>> Applied to u-boot/master.
>
>   dumb question but what does it mean to say "Applied to
> u-boot/master" when it clearly has not been applied to master? i can
> see posts like that, but doing a "git pull" produces nothing. i am on
> the u-boot mainline, and the "master" branch, so what am i
> misunderstanding? thanks.

The public git/http server is only synced every 6hours...

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Tegra114: Add support for more clock sources for T1x4 periphs

[Stephen Warren]

On 10/07/2013 01:47 PM, Tom Warren wrote:
> Some T1x4 peripherals can take up to 8 different clock

I would like to avoid "x" in any Tegra naming. Downstream, we've abused
this by calling Tegra114 Tegra11x instead, and I'd like to completely
avoid anything like that abomination upstream. Can we simply say "114"
instead of "1x4" or "114" here. If the "x" really is a wildcard, let's
just write out 114/124 instead, although if such clocks also exist on
Tegra114, there's no need to even mention Tegra124 here, since the
statement is valid even for just Tegra114 alone.

> Change-Id: I396169cd5732ad42aeddefa70fc43f79e969a70d

Upstream doesn't want those.

> diff --git a/arch/arm/cpu/tegra-common/clock.c 
> b/arch/arm/cpu/tegra-common/clock.c
> index 268fb91..c703c40 100644
> --- a/arch/arm/cpu/tegra-common/clock.c
> +++ b/arch/arm/cpu/tegra-common/clock.c
> @@ -304,13 +304,24 @@ static int adjust_periph_pll(enum periph_id periph_id, 
> int source,
>   /* work out the source clock and set it */
>   if (source < 0)
>   return -1;
> - if (mux_bits == 4) {
> - clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> - source << OUT_CLK_SOURCE4_SHIFT);

That implies 4 bits ...

> + switch (mux_bits) {

> + case MASK_BITS_29_28:
> + clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> + source << OUT_CLK_SOURCE4_SHIFT);

... but that implies 2 bits (29, 28). There's some inconsistency in the
naming there.

Can't we use the OUT_CLK_SOURCE4_MASK macros instead of inventing new
MASK_BITS_29_28 macros, or something like that? Or perhaps simply store
the shift and mask values in per-clock data, so there's no need for
conditional code here.

> +int clock_periph_enable(enum periph_id periph_id, enum clock_id parent,
> + int divisor)

This function doesn't seem to be used anywhere. What's it for?

> +{
> + int mux_bits, divider_bits, source;
> +
> + /* Assert reset and enable clock */
> + reset_set_enable(periph_id, 1);
> + clock_enable(periph_id);
> +
> + /* work out the source clock and set it */
> + source = get_periph_clock_source(periph_id, parent, &mux_bits,
> +  ÷r_bits);
> +
> + assert(divisor >= 0);
> + divisor = (divisor - 1) << 1;

Doesn't that assert need to be "> 0" not "> = 0" to avoid underflow in
the "- 1" operation?

> diff --git a/arch/arm/cpu/tegra114-common/clock.c 
> b/arch/arm/cpu/tegra114-common/clock.c

> @@ -122,110 +160,120 @@ static enum clock_type_id 
> clock_periph_type[PERIPHC_COUNT] = {

> - TYPE(PERIPHC_NONE,  CLOCK_TYPE_NONE),
...
> + TYPE(PERIPHC_05h,   CLOCK_TYPE_NONE),

Isn't that an unrelated change? At least the need for this should be
mentioned in the commit description.

>   /* 0x10 */
> - TYPE(PERIPHC_CVE,   CLOCK_TYPE_PDCT),
...
> + TYPE(PERIPHC_10h,   CLOCK_TYPE_NONE),

Why remove that clock?

> - TYPE(PERIPHC_TVDAC, CLOCK_TYPE_PDCT),
...
> + TYPE(PERIPHC_25h,   CLOCK_TYPE_NONE),

Same here.

> - TYPE(PERIPHC_SPEEDO,CLOCK_TYPE_PCMT),
...
> + TYPE(PERIPHC_55h,   CLOCK_TYPE_NONE),

And that. etc.

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

Re: [U-Boot] [PATCH v2 1/4] mtd: nand: add NAND_BUSWIDTH_AUTO to autodetect bus width

[Scott Wood]

On Mon, 2013-09-30 at 23:52 +0530, Pekon Gupta wrote:
> From: Matthieu CASTET 
> 
> This patch is modified version from following linux patch
> http://lists.infradead.org/pipermail/linux-mtd/2012-November/044803.html
> So retaining the authorship to Matthieu CASTET 
> 
> *Modifications from original patch*
> (1) use CONFIG_SYS_NAND_ONFI_DETECTION instead of (chip->options & 
> NAND_BUSWIDTH_AUTO)
> (2) allow re-assigning of callbacks in nand_set_defaults() depending on 
> bus-width
> 
> *Original patch message*
> The driver call nand_scan_ident in 8 bit mode, then
> readid or onfi detection are done (and detect bus width).
> The driver should update its bus width before calling nand_scan_tail.
> 
> This work because readid and onfi are read work 8 byte mode.
> 
> Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID, 
> NAND_CMD_PARAM), address and read data
> The ONFI specificication is not very clear for x16 device if high byte of 
> address should be driven to 0,
> but according to [1] it should be ok to not drive it during autodetection.
> 
> [1]
> 3.3.2. Target Initialization
> 
> [...]
> The Read ID and Read Parameter Page commands only use the lower 8-bits of the 
> data bus.
> The host shall not issue commands that use a word data width on x16 devices 
> until the host
> determines the device supports a 16-bit data bus width in the parameter page.
> 
> Signed-off-by: Pekon Gupta 
> ---
>  drivers/mtd/nand/nand_base.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 9e05cef..4ef0edb 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2514,7 +2514,7 @@ static void nand_set_defaults(struct nand_chip *chip, 
> int busw)
>  
>   if (!chip->select_chip)
>   chip->select_chip = nand_select_chip;
> - if (!chip->read_byte)
> + if ((!chip->read_byte) || (chip->read_byte == nand_read_byte))
>   chip->read_byte = busw ? nand_read_byte16 : nand_read_byte;

Unnecessary parens (and doesn't match equivalent Linux code).

This change corresponds to Linux commit
68e8078072e802e77134664f11d2ffbfbd2f8fbe.

-Scott



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

Re: [U-Boot] [PATCH] Tegra114: spl: Set system clock to clk_m

[Stephen Warren]

On 10/07/2013 03:17 PM, Tom Warren wrote:
> From: Jimmy Zhang 
> 
> Based on Tegra114 TRM, system clock can run up to 275MHz. On power on,

Which exact clock is "system clock"?

> the default sytem clock source is set to pllp_out0. In function
> clock_early_init(), pllp_out0 will be set to 480MHz which is beyond system
> clock's upper limit.
> 
> The fix is to set the system clock to CLK_M before initializing PLLP.
> Tested on A02 dalmore board.

> diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c 
> b/arch/arm/cpu/arm720t/tegra-common/spl.c

> @@ -24,6 +28,9 @@ void spl_board_init(void)
>   /* enable JTAG */
>   writel(0xC0, &pmt->pmt_cfg_ctl);
>  
> + /* use clk_m as avp clock source */
> + set_avp_clock_to_clkm();

Doesn't clk_m run at the crystal frequency, so this is going to make the
AVP run pretty slow, at least for a while? Is that a good thing?

> diff --git a/arch/arm/cpu/arm720t/tegra114/cpu.c 
> b/arch/arm/cpu/arm720t/tegra114/cpu.c

> @@ -127,8 +127,8 @@ void t114_init_clocks(void)
...
>   /*
> -  * Switch system clock to PLLP_OUT4 (108 MHz), AVP will now run
> -  * at 108 MHz. This is glitch free as only the source is changed, no
> +  * Switch system clock to PLLP_OUT4 (204 MHz), AVP will now run
> +  * at 204 MHz. This is glitch free as only the source is changed, no
>* special precaution needed.
>*/

... OK, so hopefully the AVP only runs very slowly for a very short
time. How much code runs between spl_board_init() and
t114_init_clocks()? Should spl_board_init() do all of the AVP clock
source setup to avoid too long a time running at crystal frequency?

> @@ -152,18 +152,11 @@ void t114_init_clocks(void)
>   clock_set_enable(PERIPH_ID_CACHE2, 1);
>   clock_set_enable(PERIPH_ID_GPIO, 1);
>   clock_set_enable(PERIPH_ID_TMR, 1);
> - clock_set_enable(PERIPH_ID_RTC, 1);

This seems entirely unrelated to the intended purpose of this patch. Why
remove all these clock_set_enable() calls? At the very least, this
should be explained in the commit description. Since it seems like a
different logical change, I would expect it to be a separate patch.

> @@ -220,7 +212,7 @@ static int is_clamp_enabled(u32 mask)
>   u32 reg;
>  
>   /* Get clamp status. TODO: Add pmc_clamp_status alias to pmc.h */
> - reg = readl(&pmc->pmc_pwrgate_timer_on);
> + reg = readl(&pmc->pmc_clamp_status);

Again, unrelated?

> +/*
> + * On poweron, AVP clock source (also called system clock) is set to 
> PLLP_out0
> + * with frequency set at 1MHz. Before initializing PLLP, we need to move the
> + * system clock's source to CLK_M temporarily. And then switch it to 
> PLLP_out4
> + * (204MHz) at a later time.
> + */
> +void set_avp_clock_to_clkm(void)

That comment would be better located in spl_board_init() in order to
explain why it calls this function. Any comment for this function would
be better explaining the function itself more than why other code might
call it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Stephen Warren]

On 10/08/2013 12:23 AM, Jagan Teki wrote:
> On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren  wrote:
>> Tegra124 is compatible w/T114 SPI, so try to commonize as
>> much as possible.
... [ large patch quoted]
>
> Is it part of tegra.git?

Please don't quote an entire patch just to ask a one-line question. It
makes people waste their time reading through the entire patch trying to
find out what you said.

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

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Stephen Warren]

On 10/08/2013 10:03 AM, Tom Warren wrote:
> On Mon, Oct 7, 2013 at 11:23 PM, Jagan Teki  wrote:
>> On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren  wrote:
>>> Tegra124 is compatible w/T114 SPI, so try to commonize as
>>> much as possible.
>>>
>>> TEST=built all T1x4 boards, tested on Venice1 & 2 OK.
>>> There's no real binary change here, just names/includes.
...
>> Is it part of tegra.git?
>>
> I'm not sure what you are asking here. This code will go in to
> u-boot-tegra/next when it's Acked, if that's what you mean. It only affects
> Tegra SPI, so it doesn't need to go thru the SPI repo (no functional
> change, just a rename for future SoCs).

SPI patches should be applied to the SPI tree, not the Tegra tree. the
various subsystem trees exist to accept the patches for those subsystems...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Stephen Warren]

On 10/07/2013 03:20 PM, Tom Warren wrote:
> Tegra124 is compatible w/T114 SPI, so try to commonize as
> much as possible.

Please don't do this. It's pointless churn. There's nothing wrong with a
driver for a HW block that was introduced in Tegra114 being named
Tegra114. The new naming isn't any more correct; if we were to introduce
a new Tegra235 chip that shared this IP block, would be have to rename
the files to tegra1x4_235_spi.c?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/4] mtd: nand: add NAND_BUSWIDTH_AUTO to autodetect bus width

[Scott Wood]

On Mon, 2013-09-30 at 23:52 +0530, Pekon Gupta wrote:
> @@ -2575,6 +2575,10 @@ static int nand_flash_detect_onfi(struct mtd_info 
> *mtd, struct nand_chip *chip,
>   int i;
>   int val;
>  
> + if (chip->options & NAND_BUSWIDTH_16) {
> + printf("nand: error: ONFI detection works only in x8 mode\n");
> + return 0;
> + }

This should just fail silently, as I may be trying to probe a non-ONFI
16-bit chip (but don't want to disable ONFI support at compile time).

-Scott



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

Re: [U-Boot] [PATCH v2 2/4] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width

[Scott Wood]

On Mon, 2013-09-30 at 23:52 +0530, Pekon Gupta wrote:
> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SYS_NAND_ONFI_DETECTION)
> + /* device bus-width determined from ONFI params */
> + nand->options   &= ~NAND_BUSWIDTH_16;
> +#else
> + /* device bus-width passed via CONFIG_xx */
> + if (CONFIG_SYS_NAND_DEVICE_WIDTH == 16)
> + nand->options |= NAND_BUSWIDTH_16;
> + else
> + nand->options &= ~NAND_BUSWIDTH_16;
> +#endif

BTW, CONFIG_SYS_NAND_ONFI_DETECTION is misnamed -- it should be
CONFIG_NAND_ONFI_DETECTION and it should only indicate whether we're
building ONFI support, rather than making an assertion about whether the
device actually is ONFI.  You could do what the Linux driver does, and
retry as 16-bit if an 8-bit ident fails.

-Scott



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

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Robert P. J. Day]

On Tue, 8 Oct 2013, Robert Nelson wrote:

> On Tue, Oct 8, 2013 at 3:39 PM, Robert P. J. Day  
> wrote:
> > On Tue, 8 Oct 2013, Tom Rini wrote:
> >
> > ... snip ...
> >
> >> Applied to u-boot/master.
> >
> >   dumb question but what does it mean to say "Applied to
> > u-boot/master" when it clearly has not been applied to master? i can
> > see posts like that, but doing a "git pull" produces nothing. i am on
> > the u-boot mainline, and the "master" branch, so what am i
> > misunderstanding? thanks.
>
> The public git/http server is only synced every 6hours...

  i'm not convinced. i'm looking at this posting from yesterday:

http://lists.denx.de/pipermail/u-boot/2013-October/164517.html

timestamped "Mon, Oct 07, 2013 at 10:02:08PM +0200" which contains a
change i'm interested in and, as of this minute, it doesn't appear in
master.

rday

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

Re: [U-Boot] [PATCH 1/8] Tegra124: Add arch-tegra124 include/header files

[Stephen Warren]

On 10/07/2013 04:42 PM, Tom Warren wrote:
> No real HW change on T124 for 90% of the toys, so just include
> a common T1x4 header file (based on T114 headers), and if a new
> register/bit is needed, add it at the end. Some headers (clk_rst,
> clock-tables, pinmux, etc.) had too many changes in structs,
> devices, etc. added/removed, so they are added as complete new
> files for T124, and can be diffed against T114 headers to see
> what's changed (again, not a lot).
> 
> In a future (RSN) patch I'll point the T114 headers at the
> new common tegra1x4-xxx files, too.

>  arch/arm/include/asm/arch-tegra/tegra1x4_ahb.h |  91 +++
>  arch/arm/include/asm/arch-tegra/tegra1x4_clock.h   |  19 +
>  arch/arm/include/asm/arch-tegra/tegra1x4_emc.h |  76 +++
>  arch/arm/include/asm/arch-tegra/tegra1x4_flow.h|  40 ++
>  arch/arm/include/asm/arch-tegra/tegra1x4_fush.h|  28 +
>  .../include/asm/arch-tegra/tegra1x4_gp_padctrl.h   |  74 +++
>  arch/arm/include/asm/arch-tegra/tegra1x4_pmu.h |  14 +
>  arch/arm/include/asm/arch-tegra/tegra1x4_spi.h |  23 +-
>  arch/arm/include/asm/arch-tegra/tegra1x4_sysctr.h  |  26 +
>  arch/arm/include/asm/arch-tegra/tegra1x4_usb.h | 272 +

For the reasons I mentioned earlier, I'd like to avoid "tegra1x4" in
these filenames too.

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

Re: [U-Boot] [PATCH 3/8] Tegra124: Add SPL/AVP (arm720t) cpu files

[Stephen Warren]

On 10/08/2013 02:13 AM, Thierry Reding wrote:
> On Tue, Oct 08, 2013 at 12:42:53AM +0200, Tom Warren wrote:
>> This provides SPL support for T124 boards - AVP early init, plus
>> CPU (A15) init/jump to main U-Boot.

>> soc_type = tegra_get_chip(); -   if (soc_type ==
>> CHIPID_TEGRA30 || soc_type == CHIPID_TEGRA114) +   if
>> (soc_type == CHIPID_TEGRA30 || soc_type == CHIPID_TEGRA114 || +
>> soc_type == CHIPID_TEGRA124)
> 
> Perhaps:
> 
> if (soc_type >= CHIPID_TEGRA30)

Given that the only exception is Tegra20, wouldn't it be better as:

if (soc_type == CHIPID_TEGRA20)

and then swap the Tegra20/not-Tegra20 branches of the if statement?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."

[Tom Rini]

On Tue, Oct 08, 2013 at 05:28:23PM -0400, Robert P. J. Day wrote:
> On Tue, 8 Oct 2013, Robert Nelson wrote:
> 
> > On Tue, Oct 8, 2013 at 3:39 PM, Robert P. J. Day  
> > wrote:
> > > On Tue, 8 Oct 2013, Tom Rini wrote:
> > >
> > > ... snip ...
> > >
> > >> Applied to u-boot/master.
> > >
> > >   dumb question but what does it mean to say "Applied to
> > > u-boot/master" when it clearly has not been applied to master? i can
> > > see posts like that, but doing a "git pull" produces nothing. i am on
> > > the u-boot mainline, and the "master" branch, so what am i
> > > misunderstanding? thanks.
> >
> > The public git/http server is only synced every 6hours...
> 
>   i'm not convinced. i'm looking at this posting from yesterday:
> 
> http://lists.denx.de/pipermail/u-boot/2013-October/164517.html
> 
> timestamped "Mon, Oct 07, 2013 at 10:02:08PM +0200" which contains a
> change i'm interested in and, as of this minute, it doesn't appear in
> master.

That's when Albert sent his email.  My reply is "Tue Oct 8 21:33:30 CEST
2013", so yes, we haven't hit the re-sync window just  yet.

-- 
Tom


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