Re: [U-Boot] Virtex 4 with XMD

[Rommel Custodio]

Dear Frank,

>Frank Lombardo  gmail.com> writes:

> So, that leaves me with the following questions:
> 1) Is the lack of flash memory causing THIS problem?
> 2) Am I missing some config items?
> 3) Does anybody have any advice on how I can debug this?

I'm on an ML507 and I use the default configuration for u-boot. So try the 
defaults (SYS_TEXT_BASE and RESET_VECTOR_ADDRESS) first.

I used the instructions here when I used XMD:

Just change the kernel ELF file for the u-boot ELF file.


There are two targets for all the u-boot supported Xilinx boards in the 
boards.cfg. The one for Flash has "_flash" so it's very easy to differentiate.

All the best,
Rommel


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

Re: [U-Boot] [PATCH] MIPS: start.S: remove obsolete 64 bit handling in setup_c0_status

[Gabor Juhos]

Hi Daniel,

> From: Daniel Schwierzeck 
> 
> Signed-off-by: Daniel Schwierzeck 

Looks good.

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

Re: [U-Boot] Virtex 4 with XMD

[Rommel Custodio]

Rommel Custodio  gmail.com> writes:

> 
> Dear Frank,
> 
> >Frank Lombardo  gmail.com> writes:
> 
> > So, that leaves me with the following questions:
> > 1) Is the lack of flash memory causing THIS problem?
> > 2) Am I missing some config items?
> > 3) Does anybody have any advice on how I can debug this?
> 
> I'm on an ML507 and I use the default configuration for u-boot. So try the 
> defaults (SYS_TEXT_BASE and RESET_VECTOR_ADDRESS) first.

Sorry, the defaults won't work in your case. I didn't notice that you only have 
64Mb earlier.

> 
> I used the instructions here when I used XMD:
> 
> Just change the kernel ELF file for the u-boot ELF file.
> 
> There are two targets for all the u-boot supported Xilinx boards in the 
> boards.cfg. The one for Flash has "_flash" so it's very easy to differentiate.

After successfully downloading the u-boot ELF to RAM, dump the first few words 
at the load address (SYS_TEXT_BASE). It should be a jump to _start. You could 
also disassemble your u-boot.

I built xilinx-ppc405-generic as a test and the first instruction is not a jump 
to _start. In ppc440 RAM boot (ie for use in XMD) the first instruction is a 
jump to _start_440 as this emulates going through the reset vector. IMHO, at 
the 
moment, it seems 405 is broken for RAM boot.


I hope my understanding is correct. Would like to hear from the PowerPC guys in 
the list.

All the best,
Rommel


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

Re: [U-Boot] [PATCH] MIPS: start.S: unify and simplify reset vector handling

[Gabor Juhos]

Hi Daniel,

> From: Daniel Schwierzeck 
> 
> Adopt reset vector handling from Yamon.
> 
> Signed-off-by: Daniel Schwierzeck 
> ---
>  arch/mips/cpu/mips32/start.S | 185 
> +--
>  arch/mips/cpu/mips64/start.S |  55 +++--
>  2 files changed, 64 insertions(+), 176 deletions(-)
> 
> diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S
> index 65acf7d..a7cd2c4 100644
> --- a/arch/mips/cpu/mips32/start.S
> +++ b/arch/mips/cpu/mips32/start.S
> @@ -47,19 +47,16 @@
>   .setpop
>   .endm
>  
> -#define RVECENT(f,n) \
> -   b f; nop
> -#define XVECENT(f,bev) \
> -   b f ;   \
> -   li k0,bev
> -
>   .set noreorder
>  
>   .globl _start
>   .text
>  _start:
> - RVECENT(reset,0)# U-boot entry point
> - RVECENT(reset,1)# software reboot
> + /* U-boot entry point */
> + b   reset
> +  nop
> +  nop
> +  nop
>  #ifdef CONFIG_SYS_XWAY_EBU_BOOTCFG

We should use '.org 0x010' here, that would make it it consistent with the rest
of the code. Additionally, that would make it possible to remove the last two
'nop' instructions before the ifdef.

>   /*
>* Almost all Lantiq XWAY SoC devices have an external bus unit (EBU) to
> @@ -71,139 +68,40 @@ _start:
>   .word CONFIG_SYS_XWAY_EBU_BOOTCFG
>   .word 0x
>  #else
> - RVECENT(romReserved,2)
> + .word 0x
> + .word 0x

I assume that Yamon uses these two words to ensure that there will be no
instructions at this address because this overlaps with the REVISION register on
the MIPS boards. U-Boot does not support MIPS development boards yet, so
strictly speaking we don't need this at the moment.

>  #endif

<...>

> - /*
> -  * We hope there are no more reserved vectors!
> -  * 128 * 8 == 1024 == 0x400
> -  * so this is address R_VEC+0x400 == 0xbfc00400
> -  */
> +.org 0x200

The indentation of this looks weird. All other pseudo op-codes are preceded by a
tab. It would be more consistent to add a tab before each '.org'.

> + /* TLB refill, 32 bit task */
> +1:   b   1b
> +  nop

<...>

> diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S
> index 1522594..0628211 100644
> --- a/arch/mips/cpu/mips64/start.S
> +++ b/arch/mips/cpu/mips64/start.S
> @@ -52,40 +52,44 @@
>   .globl _start
>   .text
>  _start:
> - .org 0x000
> + /* U-boot entry point */
>   b   reset
>nop
> - .org 0x080
> - b   romReserved
>nop
> - .org 0x100
> - b   romReserved
>nop
> - .org 0x180
> - b   romReserved
> + .word 0x
> + .word 0x

These two words and the preceding two nop instructions should be removed as 
well.

> +
> +.org 0x200
> + /* TLB refill, 32 bit task */
> +1:   b   1b
>nop
> - .org 0x200

The previous comment for the '.org' op-codes applies here as well. Even the
patch would be a bit simpler if you would not remove the leading tabs.

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

Re: [U-Boot] [PATCH] env: Allow accessing non-mtd devices

[Lubomir Rintel]

On Thu, 2013-01-31 at 07:48 +0100, Wolfgang Denk wrote:
> Dear Lubomir Rintel,
> 
> In message <1359589584-19846-1-git-send-email-lkund...@v3.sk> you wrote:
> > In certain cases, memory device is present as flat file or block device (via
> > mmc or mtdblock layer). Do not attempt MTD operations against it.
> 
> What exactly would be such cases?

Mine is a Kobo Mini e-book reader, which is basically Freescale MX50
with the only storage there being an MMC/SD card (removable from a slot
if disassembled), which contains uboot and its environment as well as
partition table, root and storage volume.

Apart from wiring a serial console, running fw_* tools seems to be about
the only way to modify kernel command line on that device. Also, I can
imagine that it would be useful to prepare a flat file image on a
different computer and copy it to the image afterwards.

> Please also make sure to run your patch through checkpatch - it
> catches a number of "space prohibited between function name and open
> parenthesis" warnings

I tried to stick with the coding style already present in the file. No
problem though, I'll follow up with an updated patch later.

> and tells you that your Signed-off-by: line is
> missing.

Noted, will fix.

Thank you!

Lubo

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

[U-Boot] [U-boot] mkimage -F parameter

[TigerLiu]

Hi, experts:

It seems mkimage has supported signing a image.

So, I have a question about signed linux kernel image:

1.   if kernel image is signed by mkimage tool.

Could uboot verify this signed linux kernel image bf jumping to its
entry point function?

2.   if uboot could verify the signed linux kernel image

how to management these different vendors' public keys in uboot code?
Using env variable?

 

Best wishes,

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

Re: [U-Boot] [PATCH] mmc: support the correct card version for eMMC

[Jaehoon Chung]

Hi Rommel,

Could you review or test for this?

Best Regards,
Jaehoon Chung

On 01/30/2013 02:31 PM, Jaehoon Chung wrote:
> eMMC vesrion is supported up to v4.5.
> But bootloader isn't saw the exact eMMC version.
> After applied this patch,
> if use the mmcinfo command, then can see the exactly mmc version.
> 
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park 
> ---
>  common/cmd_mmc.c  |2 +-
>  drivers/mmc/mmc.c |   18 ++
>  include/mmc.h |   21 +
>  3 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 7dacd51..9e8d293 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -106,7 +106,7 @@ static void print_mmcinfo(struct mmc *mmc)
>   printf("Rd Block Len: %d\n", mmc->read_bl_len);
>  
>   printf("%s version %d.%d\n", IS_SD(mmc) ? "SD" : "MMC",
> - (mmc->version >> 4) & 0xf, mmc->version & 0xf);
> + (mmc->version >> 8) & 0xf, mmc->version & 0xff);
>  
>   printf("High Capacity: %s\n", mmc->high_capacity ? "Yes" : "No");
>   puts("Capacity: ");
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 72e8ce6..3b3317e 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1029,6 +1029,24 @@ static int mmc_startup(struct mmc *mmc)
>   mmc->capacity = capacity;
>   }
>  
> + switch (ext_csd[EXT_CSD_REV]) {
> + case 1:
> + mmc->version = MMC_VERSION_4_1;
> + break;
> + case 2:
> + mmc->version = MMC_VERSION_4_2;
> + break;
> + case 3:
> + mmc->version = MMC_VERSION_4_3;
> + break;
> + case 5:
> + mmc->version = MMC_VERSION_4_41;
> + break;
> + case 6:
> + mmc->version = MMC_VERSION_4_5;
> + break;
> + }
> +
>   /*
>* Check whether GROUP_DEF is set, if yes, read out
>* group size from ext_csd directly, or calculate
> diff --git a/include/mmc.h b/include/mmc.h
> index a13e2bd..d0ec744 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -30,16 +30,21 @@
>  #include 
>  
>  #define SD_VERSION_SD0x2
> -#define SD_VERSION_2 (SD_VERSION_SD | 0x20)
> -#define SD_VERSION_1_0   (SD_VERSION_SD | 0x10)
> -#define SD_VERSION_1_10  (SD_VERSION_SD | 0x1a)
> +#define SD_VERSION_2 (SD_VERSION_SD | 0x200)
> +#define SD_VERSION_1_0   (SD_VERSION_SD | 0x100)
> +#define SD_VERSION_1_10  (SD_VERSION_SD | 0x10a)
>  #define MMC_VERSION_MMC  0x1
>  #define MMC_VERSION_UNKNOWN  (MMC_VERSION_MMC)
> -#define MMC_VERSION_1_2  (MMC_VERSION_MMC | 0x12)
> -#define MMC_VERSION_1_4  (MMC_VERSION_MMC | 0x14)
> -#define MMC_VERSION_2_2  (MMC_VERSION_MMC | 0x22)
> -#define MMC_VERSION_3(MMC_VERSION_MMC | 0x30)
> -#define MMC_VERSION_4(MMC_VERSION_MMC | 0x40)
> +#define MMC_VERSION_1_2  (MMC_VERSION_MMC | 0x102)
> +#define MMC_VERSION_1_4  (MMC_VERSION_MMC | 0x104)
> +#define MMC_VERSION_2_2  (MMC_VERSION_MMC | 0x202)
> +#define MMC_VERSION_3(MMC_VERSION_MMC | 0x300)
> +#define MMC_VERSION_4(MMC_VERSION_MMC | 0x400)
> +#define MMC_VERSION_4_1  (MMC_VERSION_MMC | 0x401)
> +#define MMC_VERSION_4_2  (MMC_VERSION_MMC | 0x402)
> +#define MMC_VERSION_4_3  (MMC_VERSION_MMC | 0x403)
> +#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
> +#define MMC_VERSION_4_5  (MMC_VERSION_MMC | 0x405)
>  
>  #define MMC_MODE_HS  0x001
>  #define MMC_MODE_HS_52MHz0x010
> 

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

[U-Boot] [PATCH] fw_env.config: Correct "fw_saveenv" to "fw_setenv".

[Robert P. J. Day]

Fix a comment in the fw_env.config file, no functional change.

Signed-off-by: Robert P. J. Day 

---

diff --git a/tools/env/fw_env.config b/tools/env/fw_env.config
index 8e21d5a..9d3b1a4 100644
--- a/tools/env/fw_env.config
+++ b/tools/env/fw_env.config
@@ -1,4 +1,4 @@
-# Configuration file for fw_(printenv/saveenv) utility.
+# Configuration file for fw_(printenv/setenv) utility.
 # Up to two entries are valid, in this case the redundant
 # environment sector is assumed present.
 # Notice, that the "Number of sectors" is ignored on NOR and SPI-dataflash.

-- 


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

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

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

[U-Boot] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?

[Robert P. J. Day]

  i want to do pretty much what's described here:

https://github.com/DFE/HidaV/wiki/Safe-Update-and-boot-fallbacks

that is, a single u-boot and config in flash, followed by a pair of
kernel/rootfs partitions, that is remotely upgradeable by, from
userspace, determining the "older" (backup) of the pairs, overwriting
that pair with a new pair, then flipping the switch in the u-boot
configuration to always boot the newer kernel and rootfs (with an
emergency revert to the backup pair under circumstances i haven't
imagined yet).

  it *looks* fairly straightforward, but while that's a nice write-up,
it does warn right up front that it hasn't been implemented so if
anyone has done something like this they care to share, that would be
delightful.

  FYI, i'm using this pdlogic zoom am1808 experimenter kit:

http://www.logicpd.com/products/system-on-modules/zoom-am1808/

for testing and, at the very end, the only change i would have to make
is modify the solution to handle NOR flash that will be on the
production board.

  if there's a writeup on this out there somewhere, that would be
great.  if not, if i can get this done, i'll be happy to write it up
and post it publicly on my wiki for others.

  at the moment, i'm using openembedded to build a bootable
kernel/rootfs pair for this board, and starting by adding the
u-boot-fw-utils package so i have fw_{printenv/setenv} onboard.
thanks for any pointers.

rday

p.s.  i do have the bootable SD card that came with the kit, it's
based on the arago project so i know i have something that boots to
userspace as a starting point -- always good to know.

-- 


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] [U-boot] mkimage -F parameter

[Wolfgang Denk]

Dear tiger...@viatech.com.cn,

In message  you 
wrote:
>
> It seems mkimage has supported signing a image.

Does it?

The mainline code does not know any '-F' option...

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
"We don't care.  We don't have to.  We're the Phone Company."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?

[Wolfgang Denk]

Dear Robert,

In message  you wrote:
> 
> that is, a single u-boot and config in flash, followed by a pair of
> kernel/rootfs partitions, that is remotely upgradeable by, from
> userspace, determining the "older" (backup) of the pairs, overwriting
> that pair with a new pair, then flipping the switch in the u-boot
> configuration to always boot the newer kernel and rootfs (with an
> emergency revert to the backup pair under circumstances i haven't
> imagined yet).

The emergency revert usually relies on two things:

- Watchdog support that will reset (reboot) the system reliably in
  case the Linux kernel does not boot or does not manage to start the
  user space control application that will trigger the watchdog.

- The "boot counter" feature that will allow to run an alternativce
  boot command (i. e. booting from the backup) in case the number of
  boot attempts exceeds the set limit.

>   it *looks* fairly straightforward, but while that's a nice write-up,
> it does warn right up front that it hasn't been implemented so if
> anyone has done something like this they care to share, that would be
> delightful.

Things like that have been done a number of times before; the fact
that such features as watchdog support and boot counter were added to
U-Boot are an indication for this.  However, in the cases known to me,
the actual implementation was done as shell scripts (i. e. environment
settings) which were not published.

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
The price one pays for pursuing any profession,  or  calling,  is  an
intimate knowledge of its ugly side.  - James Baldwin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] env: Allow accessing non-mtd devices

[Wolfgang Denk]

Dear Lubomir Rintel,

In message <1359630144.16475.6.camel@hobbes> you wrote:
>
> Mine is a Kobo Mini e-book reader, which is basically Freescale MX50
> with the only storage there being an MMC/SD card (removable from a slot
> if disassembled), which contains uboot and its environment as well as
> partition table, root and storage volume.

OK - but you do not comment on my remarks about the actual code?

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
The amount of time between slipping on the peel and  landing  on  the
pavement is precisely 1 bananosecond.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?

[Robert P. J. Day]

On Thu, 31 Jan 2013, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you wrote:
> >
> > that is, a single u-boot and config in flash, followed by a pair of
> > kernel/rootfs partitions, that is remotely upgradeable by, from
> > userspace, determining the "older" (backup) of the pairs, overwriting
> > that pair with a new pair, then flipping the switch in the u-boot
> > configuration to always boot the newer kernel and rootfs (with an
> > emergency revert to the backup pair under circumstances i haven't
> > imagined yet).
>
> The emergency revert usually relies on two things:
>
> - Watchdog support that will reset (reboot) the system reliably in
>   case the Linux kernel does not boot or does not manage to start the
>   user space control application that will trigger the watchdog.
>
> - The "boot counter" feature that will allow to run an alternativce
>   boot command (i. e. booting from the backup) in case the number of
>   boot attempts exceeds the set limit.
>
> >   it *looks* fairly straightforward, but while that's a nice write-up,
> > it does warn right up front that it hasn't been implemented so if
> > anyone has done something like this they care to share, that would be
> > delightful.
>
> Things like that have been done a number of times before; the fact
> that such features as watchdog support and boot counter were added to
> U-Boot are an indication for this.  However, in the cases known to me,
> the actual implementation was done as shell scripts (i. e. environment
> settings) which were not published.

  ok, i'm going to clear my schedule for the day and just read the
u-boot manual cover to cover finally -- it will probably resolve a lot
of my questions.  if it's all right, i might update some of the manual
wiki pages, like this one that corresponds to the patch i just
submitted:

http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux

where that comment should read:

# Configuration file for fw_(printenv/setenv) utility.

if it's anything more than just a trivial fix, i'll ask first.

rday

p.s.  just edited that page, hope i did it correctly.  onward ...

-- 


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

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

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

[U-Boot] [PATCH] arm: fix bug on relocation address

[Luca Ellero]

If (N. SDRAM banks > 1) and they are not contiguous, don't relocate
u-boot at (CONFIG_SYS_SDRAM_BASE + gd->ram_size), which is a bug.
Instead use the end of 2nd bank (even if there are more than 2 banks)

Signed-off-by: Luca Ellero 
Cc: Albert Aribaud 
Cc: Heiko Schocher 
---

On ARM architectures there is a bug getting top of SDRAM (where u-boot 
will be relocated). Top of SDRAM will always be:

CONFIG_SYS_SDRAM_BASE + gd->ram_size

anyway this can be wrong since SDRAM can be composed by more that one 
bank in not-contiguous address space.
(CONFIG_SYS_SDRAM_BASE + gd->ram_size) can land to not existent SDRAM 
addresses and can be very dangerous since it can potentially corrupt 
real SDRAM (in most cases SDRAM is aliased so writing to some 
not-existent address can write to real address).
Some arch use more than 2 banks but implementing all macros checks to 
PHYS_SDRAM_* leads to very ugly code, so I think using 2nd bank is good 
and does not generates bloated code


 arch/arm/lib/board.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 9f861cc..98634ab 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -333,7 +333,19 @@ void board_init_f(ulong bootflag)
gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
 #endif
 
+#if defined(PHYS_SDRAM_2) && defined(PHYS_SDRAM_2_SIZE)
+   if (CONFIG_NR_DRAM_BANKS > 1 &&
+   (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE) != PHYS_SDRAM_2)
+   addr =  PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE;
+   else
+   addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
+#else
addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
+#endif
+
+
+
+
 
 #ifdef CONFIG_LOGBUFFER
 #ifndef CONFIG_ALT_LB_ADDR
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH] vfat: Fix mkcksum argument sizes

[Joe Hershberger]

On Fri, Jan 11, 2013 at 7:35 AM, Marek Vasut  wrote:
> In case a function argument is known/fixed size array in C, the argument is
> still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore
> calling sizeof on the function argument will result in the size of the 
> pointer,
> not the size of the array.
>
> The VFAT code contains such a bug, this patch fixes it.
>
> Reported-by: Aaron Williams 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Aaron Williams 
> ---
>  fs/fat/fat.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 393c378..25d3318 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -569,9 +569,9 @@ static __u8 mkcksum(const char name[8], const char ext[3])
>
> __u8 ret = 0;
>
> -   for (i = 0; i < sizeof(name); i++)
> +   for (i = 0; i < 8; i++)
> ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + name[i];
> -   for (i = 0; i < sizeof(ext); i++)
> +   for (i = 0; i < 3; i++)
> ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + ext[i];
>
> return ret;


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

Re: [U-Boot] [PATCH 1/7] ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 12:51 AM, R Sricharan wrote:
> From: Lokesh Vutla 
> 
> Now SDRAM initialization is done on the basis of omap revision. 
> Instead this should be done on basis of SDRAM type read from 
> EMIF_SDRAM_CONFIG register. This will be helpful to avoid 
> unnessecary cpu checks for new boards
> 
> Signed-off-by: R Sricharan  Signed-off-by: 
> Lokesh Vutla 

Does this mean the ROM is already doing some basic EMIF programming
here?  I swear I looked down this path before, when I wanted to share
this code with am33xx and the problem is that while the registers
aren't reset on warm boot, on cold boot they always come up in a
default value, for both DDR2 and DDR3.

Or are you able to get by as the platforms come up with different
default values?

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

iQIcBAEBAgAGBQJRCpwGAAoJENk4IS6UOR1WpawP/jJE1GjmUCSDyC5yFyF2nRc2
gMxvIOni2Dl/y8EbvQyRMkJunzjHLxHmUqQLXLsauAalyx2xnBQ3WRhYNFR7G5jX
vOlvsn4h5L2FdQL97/5pnsKNxdgXACw2HSidIFDGQ5/o9e53Tn3ZU7BN8bYaNEep
AS7vF/ewOIbPlcavf4ov7DoICLpp8RMGPOQ+7yHAsEWfPnH3ZlfLNcUjxKzNTVpU
PGeNbka50rliEaSTbNFklpy3E09O3kNvskk6TdGnRPL6/+CR2Z9jAqeVOSGnZYTr
fagd9hlBB5HTfdBm8l2f2RRAce+t0lbvxl5wjqo+Wo+HZkf+c3/QBNe8jeDRblF5
OOixfQGq92LuqpF+HWlwnmV7R5TyF9CbuHRuDLGMux7h3YT4dsLuvUasRIAhKyUp
NyMgdw5Ytn39kE5CT3jjYbqhiYk6O1Wo1GO6xoP2N7Zn4SqK7tkX62YDPkBw8B/v
3yI5TMmuy/tTqSUsP3xevk6yf8uPFDZwNX1yIbWBmm3acX8kShIAZsXWPC42V3Pc
h3RbgBpTAU7XE9kFOSK5epk6OlipjiEdlo9Auh35yZ976bwmQsfdT5eFzLSsBO+g
f9c9KZPgg/oC82vMPOZ479a4DqapuLCdR3wTtgxaycvhqLDVSxoKbgZSyE6RAuSt
bXLDlFS0Lx4jqAuCWnE4
=l/qE
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/7] ARM: OMAP4+: Change the PRCM structure prototype common for all Socs

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 12:52 AM, R Sricharan wrote:
> The current PRCM structure prototype directly matches the hardware
>  register layout. So there is a need to change this for every new 
> silicon revision which has register space changes.
> 
> Avoiding this by making the prototye generic and populating the 
> register addresses seperately for all Socs.
> 
> Signed-off-by: R Sricharan 
[snip]
> arch/arm/cpu/armv7/omap4/prcm-regs.c   |  267 
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |  278 
> +

These two are missing license information, please fix.

Otherwise, I like the concept and I think it all looks fine.  We stay
about the same, binary size wise with all of this, correct?

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

iQIcBAEBAgAGBQJRCp5zAAoJENk4IS6UOR1WVbwQAJ5oRqFDxGIfBG3Z17BoUWcv
NI6A09ay83lss+pnL8hsETx4hc0IWyZKDvHIYMvvdGUk0Cn1mXpmVSOqyZwGQIAI
RDOhOE4xdZuaCN39CrNHwmOejC3CgDft25wVuc2AwdfeqOqhdoO8k9aBq78CYgGQ
i1xY/bAy0wAu1sxOvFgUlHqkGX+YSn+yCq3FNXgNJ3j+hJ/kemNSurEoeHUDXtwR
9zd16DGiApuywImuMI0qwfXBDTXYm3Rjv+Wsz5QfLNBkNkx0+O1bWsPhZFpB0Ygr
EGggUAUYuS4H/ubrH2/j3951apLAuNGdiC/1gFbg8bov6RBSiFP9gXpLKKytTu5H
WptzpxvGnNGbNgM8IHDqhUtFnmKg6azOgZilUQl6TO0gBmOi/o6fNvrg9fR2Em5C
Eq+/whFsdypHxUkiqGrG57uD3xO7FCuu63yg4NkTX1jn70dGNd+V5Ad/u63Uejzx
ut2sr0S9iAc611z1A10pUZGq4pnQCERtiBIZwOJOGPmv0O1oYatP2JNNctmDQs3U
LR1/S3KvO9yl7ncpnKDwmO/Cn/RzBZ+xp8VvnwXeB/upVwMWkn9IhyLL1aYQDl4W
a6i1oN55Sz911j65d8G66CT4rUMcG9tkcXmH0JQQTunF8O+Gzk8+ImQ5HuFz9qsz
TYhk4OvsZeSZXiVVFFBI
=p87D
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] ARM: OMAP4+: Cleanup the clocks layer

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 12:52 AM, R Sricharan wrote:
> Currently there is quite a lot of code which is duplicated in the
> clocks code for OMAP 4 and 5 Socs. Avoiding this here by moving the
> clocks data to a SOC specific place and the sharing the common
> code.
> 
> This helps in addition of a new Soc with minimal changes.
> 
> Signed-off-by: R Sricharan 

Reviewed-by: Tom Rini 

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

iQIcBAEBAgAGBQJRCp8NAAoJENk4IS6UOR1WTDAP/2u9KQ/Y7eNzHL/yEHPhhuIw
JVXUopXjUk/ZtZWO3pQnb7JrioLqJbjuZfdvDbLxyfzJH5oJGLbQW59tKajS+zLn
sE47/n9bJZ58yF93HQzpqje8w6RfCZ0fgQAuzUg6IG5grTSUShbMNrwZfM4bZG5C
vTz41BUpt2pSb0epb33Q4tc4pz3jgq8FrNFDy7kO63GEGzbeAwxE553/Cylo8AJ/
kVDhNXm2zseGmrf/q4acBL5ryWXjd7WncDIAF8nY/N1nsv4Hcp7G3kykn9oe9zXM
GzX/OUN1R5nJ9aeHBiXhg1195quJAmHI8N4AC1ReeRjkI48Pv0xIT91VsMuvQApe
Rjoh4P/QMUuIJlZgWez0t4waoU9a5N4F/Svx/aRaJ/AgH4KallNoMRVzHvx4W9aT
+nc0GhGuHHdW57iSM2FdNgQc/E0Iu1VG1eNAdooKZcGDpKS1dIGWwfr4PSwP6Plp
QvkDZpBKN2wTqN/e35TA2R9rR6EZmLktB+xRUu4HH1VXpqpf+L+KY4DypTyNDgjz
ApWcC1Irb4617BM2WgbHh81X0XJ+CjAP+tq3RfKzZCl07lXXXjI561L5gXn0PtlH
DNQbmJiRJ7caN3bm6zEnY/Ap2NQ5FGQD4Fd7af9wFhQsFfCiHTqrlUrwMwdwkLJd
UDzXcWPPTvO1uRKyJQls
=fkAc
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] ARM: OMAP4+: Clean up the pmic code

[Tom Rini]

On Thu, Jan 31, 2013 at 11:22:02AM +0530, R Sricharan wrote:

> The pmic code is duplicated for OMAP 4 and 5.
> Instead move the data to Soc specific place and
> share the code.
> 
> Signed-off-by: R Sricharan 
[snip]
> +++ b/arch/arm/cpu/armv7/omap4/hw_data.c
[snip]
> +struct vcores_data omap4430_volts_es1 = {
> + .mpu.value = 1325, .mpu.addr = SMPS_REG_ADDR_VCORE1,
> +.mpu.pmic = &twl6030_4430es1,

Here and in omap5/hw_data.c, split these up into multiple lines.

-- 
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 5/7] ARM: OMAP4+: Cleanup emif specific files

[Tom Rini]

On Thu, Jan 31, 2013 at 11:22:03AM +0530, R Sricharan wrote:

> From: Lokesh Vutla 
> 
> Removing the duplicated code in ddr3 initialization.
> Also creating structure for lpddr2 mode registers to
> avoid unnessecary revision checks.
> 
> These change reduces code addition for future Socs.
> 
> Signed-off-by: R Sricharan 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/7] ARM: OMAP4+: Make control module register structure generic

[Tom Rini]

On Thu, Jan 31, 2013 at 11:22:04AM +0530, R Sricharan wrote:

> From: Lokesh Vutla 
> 
> A seperate omap_sys_ctrl_regs structure is defined for
> omap4 & 5. If there is any change in control module for
> any of the ES versions, a new structure needs to be created.
> In order to remove this dependency, making the register
> structure generic for all the omap4+ boards.
> 
> Signed-off-by: R Sricharan 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 7/7] ARM: OMAP5: Clean up iosettings code

[Tom Rini]

On Thu, Jan 31, 2013 at 11:22:05AM +0530, R Sricharan wrote:

> From: Lokesh Vutla 
> 
> There is some code duplication in the ddr io settings code.
> This is avoided by moving the data to a Soc specific place and
> letting the code generic.
> 
> This avoids unnessecary code addition for future socs.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.

[Tom Rini]

On Thu, Jan 31, 2013 at 11:32:26AM +0530, R Sricharan wrote:

> Adding the CPU detection suport for OMAP5430 and
> OMAP5432 ES2.0 SOCs.
> 
> Signed-off-by: R Sricharan 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/5] ARM: OMAP5: clock: Add the prcm register changes required for ES2.0

[Tom Rini]

On Thu, Jan 31, 2013 at 11:32:27AM +0530, R Sricharan wrote:

> PRCM register addresses are changed from ES1.0 to ES2.0 due to
> PER power domain getting moved to CORE power domain.
> 
> So adding the nessecary register changes for the same.
> 
> Signed-off-by: R Sricharan 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/5] ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc

[Tom Rini]

On Thu, Jan 31, 2013 at 11:32:28AM +0530, R Sricharan wrote:

> Change OPP settings as per the latest 0.4 version of
> addendum for OMAP5430 ES2.0
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: R Sricharan 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 4/5] ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs

[Tom Rini]

On Thu, Jan 31, 2013 at 11:32:29AM +0530, R Sricharan wrote:

> From: Lokesh Vutla 
> 
> Add pre calculated timing settings of LPDDR2 and DDR3 memories
> present in OMAP5430 and OMAP5432 ES2.0 versions.
> 
> Also adding the DDR pad io settings required for
> OMAP543X SOCs here.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: R Sricharan 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 5/5] ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup

[Tom Rini]

On Thu, Jan 31, 2013 at 11:32:30AM +0530, R Sricharan wrote:

> From: Lokesh Vutla 
> 
> After power-up SRCOMP cells are by-passed by default in OMAP5.
> Software has to enable these SRCOMP sells.
> For ES2: All 5 SRCOMP cells needs to be enabled.
> For ES1: Only 4 SRCOMP cells in core power domain are enabled.
>The 1 in wkup domain is not enabled because smart i/os
>of wkup domain work with default compensation code.
> 
> Signed-off-by: R Sricharan 
> Signed-off-by: Lokesh Vutla 

With the caveat that a few formatting things looked odd, but I'm
assuming you ran this series past checkpatch.pl and it's clean:

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] patman changes?

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 01:32 PM, Doug Anderson wrote:
> Hi,
> 
> I posted a bunch of patman changes a bit ago and they've all been
> acked by Simon.  Any chance of them landing?  They're all visible
> here 
> 
> ...I think some of the changes have lost their acks on patchwork
> (I forgot to include Simon's v1 ack on my v2 changes).  I'm happy
> to repost with his acks if that helps.

With the caveat that I only just now gave it a 30sec skim, I can take
the bundle or a pull request from Simon from the x86 tree.  Got a
preference Simon?

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

iQIcBAEBAgAGBQJRCrpSAAoJENk4IS6UOR1WCSoP/ig9Magz1m+IY3nx36vZidfO
jNQmt68a1G84neBBSaXzO0y9QaUsYJbKbKTlc6nBYs65l2dbMK8/rupkANFFpGw4
85XOeYyn0I2AJ0kLvvAnth55poXC615hFCqQj3ztaNf20ROOmlgcN/WNiKU2dPpd
gm6OU1CUNteNQhHw378gY6LvYxjLWlPvypNiqJ31fwMRbQssMxoX/CCLbBgSm5m6
vHJ9U16Tk7B1l0Cmj/GHqa/4TYLuzVLsg0QhaxscS53MYrWtuFQfajkKsnxn9iy2
/fOVVLYy9iI9G99VI7XszYkeGKiX5QnQXL1HzhoJAUM1Rjv0Wqfjlt2moTf2T2M9
d6jLrUA7NoY9seKLH7NCfM0Htw63FVDIjowWyMBR6y/bO9yd1fiJwppkAT9AspHN
zwgXpwCMx2djwpLrcIZb7yA18yHVHKfWf+cPhARZ/iLBFjSUZk7WmaxKvbqIe/72
SayTZmGcV3noJVnnBtyGNCg6Sluz5HZoiNKr75lgm2W5G7rHY1RSNTn06qG+MyG6
l1v+sSPBuE05DBKaT8ekqB5kDdEX/Y4IAfqcH+eOLDkJ/S6u+XqqKLIDEcUA+oV4
iYI7IglQPsQEu5QEaHCRa8oKSvEL4OJAPZYPIIGjt1xkxMPld2imTYNMxCykvPW+
EN8JOkGhVbqGwHtXSWOJ
=Bp9L
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] patman changes?

[Doug Anderson]

Hi,

I posted a bunch of patman changes a bit ago and they've all been acked by
Simon.  Any chance of them landing?  They're all visible here <
http://patchwork.ozlabs.org/bundle/dianders/patman/>

...I think some of the changes have lost their acks on patchwork (I forgot
to include Simon's v1 ack on my v2 changes).  I'm happy to repost with his
acks if that helps.

Thanks!  :)

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

Re: [U-Boot] [U-Boot,v2 6/6] sf: Set QUAD enable bit support

[Jagan Teki]

Hi Mike/Simon,

Any further comments on this.

I have tested on real h/w target as well.

Thanks,
Jagan.

On Sun, Dec 23, 2012 at 11:23 PM, Jagan Teki  wrote:
> Tested on real hardware, works fine.
>
> Tested-by: Jagannadha Sutradharudu Teki 
>
> Thanks,
> Jagan.
>
> On Wed, Dec 19, 2012 at 9:57 PM, Jagannadha Sutradharudu Teki
>  wrote:
>> This patch provides support to set the QUAD enable bit on flash.
>>
>> QUAD enable bit needs to set before performing any QUAD IO operations
>> on respective SPI flashes.
>>
>> User need to use spi_flash_set_quad_enable_bit() to set the
>> QUAD enable bit based on their usage.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>> ---
>> Changes in v2:
>> Improved code logic
>>
>>  drivers/mtd/spi/spi_flash.c  |   31 +++
>>  drivers/mtd/spi/spi_flash_internal.h |4 
>>  2 files changed, 35 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
>> index 5bddde4..675a0bf 100644
>> --- a/drivers/mtd/spi/spi_flash.c
>> +++ b/drivers/mtd/spi/spi_flash.c
>> @@ -329,6 +329,37 @@ int spi_flash_cmd_read_config(struct spi_flash *flash, 
>> void *data)
>> return 0;
>>  }
>>
>> +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
>> +{
>> +   u8 data = 0, write_done = 0;
>> +   int ret, pass;
>> +
>> +   for (pass = 0; pass < 2; pass++) {
>> +   ret = spi_flash_cmd_read_config(flash, (void *)&data);
>> +   if (ret < 0) {
>> +   debug("SF: fail to read config register\n");
>> +   return ret;
>> +   }
>> +
>> +   if (data & STATUS_QEB) {
>> +   debug("SF: quad enable bit is set.\n");
>> +   return ret;
>> +   } else if (write_done != 1) {
>> +   debug("SF: need to set quad enable bit\n");
>> +
>> +   write_done = 1;
>> +   ret = spi_flash_cmd_write_config(flash, STATUS_QEB);
>> +   if (ret < 0) {
>> +   debug("SF: fail to write quad enable bit\n");
>> +   return ret;
>> +   }
>> +   }
>> +   }
>> +
>> +   debug("SF: fail to set quad enable bit\n");
>> +   return -1;
>> +}
>> +
>>  /*
>>   * The following table holds all device probe functions
>>   *
>> diff --git a/drivers/mtd/spi/spi_flash_internal.h 
>> b/drivers/mtd/spi/spi_flash_internal.h
>> index 844e82e..15c7ac4 100644
>> --- a/drivers/mtd/spi/spi_flash_internal.h
>> +++ b/drivers/mtd/spi/spi_flash_internal.h
>> @@ -31,6 +31,7 @@
>>
>>  /* Common status */
>>  #define STATUS_WIP 0x01
>> +#define STATUS_QEB 0x02
>>
>>  /* Send a single-byte command to the device and read the response */
>>  int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t 
>> len);
>> @@ -87,6 +88,9 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
>> cr);
>>  /* Read the config register */
>>  int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
>>
>> +/* Set the QUAD enable bit */
>> +int spi_flash_set_quad_enable_bit(struct spi_flash *flash);
>> +
>>  /*
>>   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
>>   * bus. Used as common part of the ->read() operation.
>> --
>> 1.7.0.4
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?

[Wolfgang Denk]

Dear Robert,

In message  you wrote:
> 
>   ok, i'm going to clear my schedule for the day and just read the
> u-boot manual cover to cover finally -- it will probably resolve a lot

Don't hold your breath that it will cover all topics.  There are way
too many cases where customers are not willing to also pay for public
documentation of the stuff they asked for;  we're already happy that
almost all code goes into mainline.

> of my questions.  if it's all right, i might update some of the manual
> wiki pages, like this one that corresponds to the patch i just
> submitted:

All such reductional work is highly welcome.

> p.s.  just edited that page, hope i did it correctly.  onward ...

Looks fine, thanks.

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
Our business is run on trust.  We trust you will pay in advance.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: fix bug on relocation address

[Jeroen Hofstee]

Hello Luca,

On 01/31/2013 03:29 PM, Luca Ellero wrote:

If (N. SDRAM banks > 1) and they are not contiguous, don't relocate
u-boot at (CONFIG_SYS_SDRAM_BASE + gd->ram_size), which is a bug.
Instead use the end of 2nd bank (even if there are more than 2 banks)

Signed-off-by: Luca Ellero 
Cc: Albert Aribaud 
Cc: Heiko Schocher 
---

On ARM architectures there is a bug getting top of SDRAM (where u-boot
will be relocated). Top of SDRAM will always be:

CONFIG_SYS_SDRAM_BASE + gd->ram_size

anyway this can be wrong since SDRAM can be composed by more that one
bank in not-contiguous address space.

I don't think this is a valid use case since the README says:

"The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks."

Regards,
Jeroen


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

Re: [U-Boot] vfat: Fix mkcksum argument sizes

[Tom Rini]

On Fri, Jan 11, 2013 at 03:35:48AM -, Marek Vasut wrote:

> In case a function argument is known/fixed size array in C, the argument is
> still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore
> calling sizeof on the function argument will result in the size of the 
> pointer,
> not the size of the array.
> 
> The VFAT code contains such a bug, this patch fixes it.
> 
> Reported-by: Aaron Williams 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Aaron Williams 
> Tested-by: Michal Simek 
> Reviewed-by: Joe Hershberger 

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

[U-Boot] [PATCH] nand/mxc: set host->page_addr for NAND_CMD_READOOB

[Scott Wood]

Without this, all OOB reads are from the last page normally read
(or zero at boot).  This results in bad block scans failing to look
in the right place, and so no bad blocks are found.

Signed-off-by: Scott Wood 
---
>From IRC discussion with a2cypher.  Compile-tested only; testing
would be appreciated.

 drivers/mtd/nand/mxc_nand.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index d0ded48..32ba340 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -1021,6 +1021,7 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned 
command,
break;
 
case NAND_CMD_READOOB:
+   host->page_addr = page_addr;
host->col_addr = column;
host->spare_only = true;
if (host->pagesize_2k)
-- 
1.7.9.5

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

[U-Boot] call env print from uboot environment

[John Stile]

I am finally on uboot-2013.01.
I having issue using: env import

I have at91bootstrap reading an uboot environment from an address
location in NAND to RAM address 0x2000.

The environment uboot is compiled to load by default has one set of
variables, but the environment loaded into ram by  at91bootstrap is
different.

I hope to see the change by using: env print.


>From the uboot prompt, I can see the proper environment in memory.
U-Boot> md.b 0x2000 0x200
I see the new environment in memory (which includes the CRC).
Example:
2000: 00 00 00 00 00 65 74 68 61 64 64 72 3d 33 61 3a.ethaddr=3a:
2010: 31 66 3a 33 34 3a 30 38 3a 35 34 3a 35 34 00 741f:34:08:54:54.t
2020: 69 6d 65 73 74 61 6d 70 3d 31 32 33 35 00 62 6fimestamp=1235.bo
2030: 6f 74 64 65 6c 61 79 3d 33 00 62 61 75 64 72 61otdelay=3.baudra
...
21f0: 30 20 30 78 30 30 32 30 30 30 30 30 20 30 78 300 0x0020 0x0

I can also see the default environment with:
U-Boot> env print

I try to load the environment from RAM:
U-Boot> env import -t 0x2000 0x200


However, when I try to print the environment again, I see the default
values, and the new imported environment has no effect on the
environment.
U-Boot> env print

What am I doing wrong.

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

Re: [U-Boot] [PATCH] nand/mxc: set host->page_addr for NAND_CMD_READOOB

[Benoît Thébaudeau]

Hi Scott,

On Thursday, January 31, 2013 8:47:55 PM, Scott Wood wrote:
> Without this, all OOB reads are from the last page normally read
> (or zero at boot).  This results in bad block scans failing to look
> in the right place, and so no bad blocks are found.
> 
> Signed-off-by: Scott Wood 
> ---
> From IRC discussion with a2cypher.  Compile-tested only; testing
> would be appreciated.
> 
>  drivers/mtd/nand/mxc_nand.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index d0ded48..32ba340 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -1021,6 +1021,7 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned
> command,
>   break;
>  
>   case NAND_CMD_READOOB:
> + host->page_addr = page_addr;
>   host->col_addr = column;
>   host->spare_only = true;
>   if (host->pagesize_2k)

For which NFC version and NAND Flash page size is this?

Do you have a means of duplicating the issue?

I wonder if the appropriate fix would not rather be to replace all occurrences
of "host->page_addr" with "page", except in mxc_nand_correct_data() and
mxc_nand_command(). Otherwise, it looks like there will still be weird things
going on with this variable.

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

Re: [U-Boot] vfat: Fix mkcksum argument sizes

[Marek Vasut]

Dear Tom Rini,

> On Fri, Jan 11, 2013 at 03:35:48AM -, Marek Vasut wrote:
> > In case a function argument is known/fixed size array in C, the argument
> > is still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and
> > therefore calling sizeof on the function argument will result in the
> > size of the pointer, not the size of the array.
> > 
> > The VFAT code contains such a bug, this patch fixes it.
> > 
> > Reported-by: Aaron Williams 
> > Signed-off-by: Marek Vasut 
> > Cc: Tom Rini 
> > Cc: Aaron Williams 
> > Tested-by: Michal Simek 
> > Reviewed-by: Joe Hershberger 
> 
> Applied to u-boot/master, thanks!

Can we have a bugfix release 2013.02 or something ? This is a grave bug.

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

[U-Boot] [ANNOUNCE] Release v2013.01.01

[Tom Rini]

Hey all,

Bugs happen, even to the best of us.  So with that said, I'm neither
proud nor ashamed to announce that v2013.01.01 has been released (branch
u-boot-2013.01.y pushed, along with tag).  It includes:

$ git log --oneline v2013.01..
e8ae0fa Prepare v2013.01.01
bc8f446 vfat: Fix mkcksum argument sizes
ad394e0 arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README

Wolfgang, can you please do the FTP side of things?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] Davinci: Make MAC address offset in EEPROM configurable, CONFIG_MAC_EEPROM_ADDR

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 03:10 AM, Kim Bøndergaard Poulsen wrote:
> Hi Tom
> 
> 
>> -Original Message- From: Tom Rini [mailto:tr...@ti.com] 
>> Sent: 29. januar 2013 21:32 To: Kim Bøndergaard Poulsen Cc: 
>> u-boot@lists.denx.de; vap...@gentoo.org; manjunath.ha...@ti.com 
>> Subject: Re: [PATCH 1/2] Davinci: Make MAC address offset in 
>> EEPROM configurable, CONFIG_MAC_EEPROM_ADDR
>> 
> On 01/29/2013 02:28 AM, Kim B￸ndergaard wrote:
 --- arch/arm/cpu/arm926ejs/davinci/misc.c | 5 - 1 file 
 changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c 
 b/arch/arm/cpu/arm926ejs/davinci/misc.c index 
 c310c69..d0389a4 100644 --- 
 a/arch/arm/cpu/arm926ejs/davinci/misc.c +++ 
 b/arch/arm/cpu/arm926ejs/davinci/misc.c @@ -55,11 +55,14 @@ 
 void dram_init_banksize(void) * Read ethernet MAC address 
 from EEPROM for DVEVM compatible boards. * Returns 1 if 
 found, 0 otherwise. */ +#ifndef CONFIG_MAC_EEPROM_ADDR 
 +#define
> CONFIG_MAC_EEPROM_ADDR
 0x7F00 +#endif int dvevm_read_mac_address(uint8_t *buf) { 
 #ifdef CONFIG_SYS_I2C_EEPROM_ADDR /* Read MAC address. */ - 
 if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0x7F00, + if 
 (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR,
> CONFIG_MAC_EEPROM_ADDR,
 CONFIG_SYS_I2C_EEPROM_ADDR_LEN, (uint8_t *) &buf[0], 6))
 goto i2cerr;
> 
> Lets use CONFIG_SYS_I2C_EEPROM_MAC_OFFSET and just set it in all
> of the davinci configs (yes, that's touching more files).  Thanks!
> 
> 
>> So what you suggest is to add a #define 
>> CONFIG_SYS_I2C_EEPROM_MAC_OFFSET 0x7F00
> 
>> in all DAVINCI related include/configs/*.h ?
> 
>> Also I assume you want me to remove the #ifdef 
>> CONFIG_SYS_I2C_EEPROM_MAC_OFFSET in misc.c?
> 
>> My only problem is that I don't know if it makes sense to define 
>> it for all boards
> 
>> grep -l DAVINCI * in include/configs gives me the following 
>> files: calimain.h cam_enc_4xx.h da830evm.h da850evm.h 
>> davinci_dm355evm.h davinci_dm355leopard.h davinci_dm365evm.h 
>> davinci_dm6467evm.h davinci_dvevm.h davinci_schmoogie.h 
>> davinci_sffsdr.h davinci_sonata.h ea20.h enbw_cmc.h hawkboard.h 
>> tnetv107x_evm.h
> 
>> Anyone who knows if they all have I2C eeproms

The subset of these with CONFIG_SYS_I2C_EEPROM set to start with,
should as they have been reading there already.  Cc'ing the various
board maintainers with the patch would be good.

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

iQIcBAEBAgAGBQJRCu/WAAoJENk4IS6UOR1WKBcP/3bE685l64rhKRGhsVp7zdsT
3XsD4oKMqIeFiHwiSiiS5PXuRibgt3h3aLgbbJnrhMGKBrXsDkEvb9Mjg3f/2yqg
duuWIiER6utP2WW16PzjwR5Y/RNjjttzBHfDKsZCOtoZqA8v2+MmnMNrcBZmGI48
foimzTD2VikxO63UElzX3vB83JyFkBaicNfk06vjE73wU2dRR1dnPi5+ufbyMp8r
ra9BI5++xVQHBmeZiGngRkO2tESll+L6L9HiTp3NNcNU3TWvV0675lwTnmXXHYy5
yoQHCI4wXQteBixPybp/903p3BhFbw8jRnAok0icSP2chcp8Dvjt8z8n29/JCxYZ
1ZOJdfbrPQXg68Un9+AQnXIoP1wby0ldkVnUfySVNL+ZzKXNA249idx8aY4s1V/K
8jBwP9xMhEaCVirP/DnLV3MetXNKy8hiE9pXqMUhuRn1xe3GwUGV4VUC0EgHJNfx
iK8Ne/p68Oeol8WHrWqG3gG9UMZgSzUqWKMSeSIILclLoo8DXLNRM2HM630rfgdA
E1MMzpBHPp4XB7RArlWXmibbh9A+ZLFraUZzCp75+OF3Ox0Tdn+vPKyMkf5qXV8w
WMZSKZBQbFI2xAYzi6YlcqBP2jC/6e2zOwFXvehQErRI51H5gLMsv0MoPnPx54t4
sUbq0r0V0EdaH2LCS2iM
=zDPr
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] call env print from uboot environment

[Wolfgang Denk]

Dear John Stile,

In message <1359663873.7974.308.camel@genx> you wrote:
>
> I see the new environment in memory (which includes the CRC).
> Example:
> 2000: 00 00 00 00 00 65 74 68 61 64 64 72 3d 33 61 3a.ethaddr=3a:
> 2010: 31 66 3a 33 34 3a 30 38 3a 35 34 3a 35 34 00 741f:34:08:54:54.t
> 2020: 69 6d 65 73 74 61 6d 70 3d 31 32 33 35 00 62 6fimestamp=1235.bo
> 2030: 6f 74 64 65 6c 61 79 3d 33 00 62 61 75 64 72 61otdelay=3.baudra
> ...
> 21f0: 30 20 30 78 30 30 32 30 30 30 30 30 20 30 78 300 0x0020 0x0

Your CRC is 0x - this looks bogus to me.

And you have set up for redundant environment, and the flag is 0x00.

Where exactly is this data coming from?  It does not appear to hav
ebeen stored by U-Boot...

> I try to load the environment from RAM:
> U-Boot> env import -t 0x2000 0x200

"-t" means text format.  This is not what you have.

> What am I doing wrong.

Try instead:

env import -b 2005

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
Substitute "damn" every time you're inclined to write "very"; your
editor will delete it and the writing will be just as it should be.
- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] nand/mxc: set host->page_addr for NAND_CMD_READOOB

[Scott Wood]

On 01/31/2013 02:45:02 PM, Benoît Thébaudeau wrote:

Hi Scott,

On Thursday, January 31, 2013 8:47:55 PM, Scott Wood wrote:
> Without this, all OOB reads are from the last page normally read
> (or zero at boot).  This results in bad block scans failing to look
> in the right place, and so no bad blocks are found.


Looking more closely, the calls to send_addr() use page_addr rather  
than host->page_addr, and the oob page read uses "page" in the call to  
cmdfunc, so maybe it's just the debug output that was wrong?



> Signed-off-by: Scott Wood 
> ---
> From IRC discussion with a2cypher.  Compile-tested only; testing
> would be appreciated.
>
>  drivers/mtd/nand/mxc_nand.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/nand/mxc_nand.c  
b/drivers/mtd/nand/mxc_nand.c

> index d0ded48..32ba340 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -1021,6 +1021,7 @@ void mxc_nand_command(struct mtd_info *mtd,  
unsigned

> command,
>break;
>
>case NAND_CMD_READOOB:
> +  host->page_addr = page_addr;
>host->col_addr = column;
>host->spare_only = true;
>if (host->pagesize_2k)

For which NFC version and NAND Flash page size is this?


All, presumably.


Do you have a means of duplicating the issue?


Not personally; it was found during an IRC discussion with a2cypher.

I wonder if the appropriate fix would not rather be to replace all  
occurrences
of "host->page_addr" with "page", except in mxc_nand_correct_data()  
and
mxc_nand_command(). Otherwise, it looks like there will still be  
weird things

going on with this variable.


Hmm, what's going on in mxc_nand_read_page_raw_syndrome()?  The caller  
of that calls cmdfunc, then the mxc_nand_read_page_raw_syndrome() calls  
it again, using host->page_addr that was set the first time cmdfunc was  
called? :-P


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

Re: [U-Boot] [PATCH] nand/mxc: set host->page_addr for NAND_CMD_READOOB

[Benoît Thébaudeau]

On Thursday, January 31, 2013 11:36:11 PM, Scott Wood wrote:
> On 01/31/2013 02:45:02 PM, Benoît Thébaudeau wrote:
> > Hi Scott,
> > 
> > On Thursday, January 31, 2013 8:47:55 PM, Scott Wood wrote:
> > > Without this, all OOB reads are from the last page normally read
> > > (or zero at boot).  This results in bad block scans failing to look
> > > in the right place, and so no bad blocks are found.
> 
> Looking more closely, the calls to send_addr() use page_addr rather
> than host->page_addr, and the oob page read uses "page" in the call to
> cmdfunc, so maybe it's just the debug output that was wrong?

Looks like.

> > > Signed-off-by: Scott Wood 
> > > ---
> > > From IRC discussion with a2cypher.  Compile-tested only; testing
> > > would be appreciated.
> > >
> > >  drivers/mtd/nand/mxc_nand.c |1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/mtd/nand/mxc_nand.c
> > b/drivers/mtd/nand/mxc_nand.c
> > > index d0ded48..32ba340 100644
> > > --- a/drivers/mtd/nand/mxc_nand.c
> > > +++ b/drivers/mtd/nand/mxc_nand.c
> > > @@ -1021,6 +1021,7 @@ void mxc_nand_command(struct mtd_info *mtd,
> > unsigned
> > > command,
> > >   break;
> > >
> > >   case NAND_CMD_READOOB:
> > > + host->page_addr = page_addr;
> > >   host->col_addr = column;
> > >   host->spare_only = true;
> > >   if (host->pagesize_2k)
> > 
> > For which NFC version and NAND Flash page size is this?
> 
> All, presumably.

My i.MX platforms with NFC v2.1 and v3 can detect bad blocks (both true ones,
and the fake ones created at the end of the NAND for the BBT), so there is
something else going on if a2cypher had an issue.

> > Do you have a means of duplicating the issue?
> 
> Not personally; it was found during an IRC discussion with a2cypher.

OK.

> > I wonder if the appropriate fix would not rather be to replace all
> > occurrences
> > of "host->page_addr" with "page", except in mxc_nand_correct_data()
> > and
> > mxc_nand_command(). Otherwise, it looks like there will still be
> > weird things
> > going on with this variable.
> 
> Hmm, what's going on in mxc_nand_read_page_raw_syndrome()?  The caller
> of that calls cmdfunc, then the mxc_nand_read_page_raw_syndrome() calls
> it again, using host->page_addr that was set the first time cmdfunc was
> called? :-P

Indeed. Whatever the caller does, it's supposed to pass the right page to
mxc_nand_read_page_raw_syndrome(), so let's use the passed "page" everywhere,
and use "host->page_addr" only to keep track of accessed pages for
mxc_nand_correct_data(), so that there is no dependency between calls?

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

Re: [U-Boot] [PATCH 1/6] imx: mx6q DDR3 init: Fix tMRD

[Eric Nelson]

On 01/30/2013 02:19 PM, Benoît Thébaudeau wrote:

MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.

For all DDR3 speed bins:
   tMRD(min) = 4 nCK
   tMOD(min) = max(12 nCK, 15 ns)

Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12 nCK
at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].

Signed-off-by: Benoît Thébaudeau 
---
  board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg 
b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
index c86cd40..9ac8027 100644
--- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
+++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
@@ -110,7 +110,7 @@ DATA 4 0x021b0018 0x00081740

  DATA 4 0x021b001c 0x8000
  DATA 4 0x021b000c 0x555A7975
-DATA 4 0x021b0010 0xFF538E64
+DATA 4 0x021b0010 0xFF538F64
  DATA 4 0x021b0014 0x01FF00DB
  DATA 4 0x021b002c 0x26D2




Hi Benoît,

I've been able to confirm operation of this complete patch set
on a SABRE Lite here, but only that (boots normally).

I'll try to scare up a board we can place on an extended burn-in.

What prompted you to walk the list? Was there a specific failure
that this addressed?

Please advise,


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

Re: [U-Boot] patman changes?

[Simon Glass]

Hi Tom,

On Fri, Feb 1, 2013 at 7:39 AM, Tom Rini  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/31/2013 01:32 PM, Doug Anderson wrote:
>> Hi,
>>
>> I posted a bunch of patman changes a bit ago and they've all been
>> acked by Simon.  Any chance of them landing?  They're all visible
>> here 
>>
>> ...I think some of the changes have lost their acks on patchwork
>> (I forgot to include Simon's v1 ack on my v2 changes).  I'm happy
>> to repost with his acks if that helps.
>
> With the caveat that I only just now gave it a 30sec skim, I can take
> the bundle or a pull request from Simon from the x86 tree.  Got a
> preference Simon?

I'll bring them in, do another test and then send out a pull request.

Regards,
Simon

>
> - --
> Tom
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRCrpSAAoJENk4IS6UOR1WCSoP/ig9Magz1m+IY3nx36vZidfO
> jNQmt68a1G84neBBSaXzO0y9QaUsYJbKbKTlc6nBYs65l2dbMK8/rupkANFFpGw4
> 85XOeYyn0I2AJ0kLvvAnth55poXC615hFCqQj3ztaNf20ROOmlgcN/WNiKU2dPpd
> gm6OU1CUNteNQhHw378gY6LvYxjLWlPvypNiqJ31fwMRbQssMxoX/CCLbBgSm5m6
> vHJ9U16Tk7B1l0Cmj/GHqa/4TYLuzVLsg0QhaxscS53MYrWtuFQfajkKsnxn9iy2
> /fOVVLYy9iI9G99VI7XszYkeGKiX5QnQXL1HzhoJAUM1Rjv0Wqfjlt2moTf2T2M9
> d6jLrUA7NoY9seKLH7NCfM0Htw63FVDIjowWyMBR6y/bO9yd1fiJwppkAT9AspHN
> zwgXpwCMx2djwpLrcIZb7yA18yHVHKfWf+cPhARZ/iLBFjSUZk7WmaxKvbqIe/72
> SayTZmGcV3noJVnnBtyGNCg6Sluz5HZoiNKr75lgm2W5G7rHY1RSNTn06qG+MyG6
> l1v+sSPBuE05DBKaT8ekqB5kDdEX/Y4IAfqcH+eOLDkJ/S6u+XqqKLIDEcUA+oV4
> iYI7IglQPsQEu5QEaHCRa8oKSvEL4OJAPZYPIIGjt1xkxMPld2imTYNMxCykvPW+
> EN8JOkGhVbqGwHtXSWOJ
> =Bp9L
> -END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot repository mirror and gerrit on Google inftrastructure

[Vadim Bendebury]

Just wanted to let everybody know that there has been a mirror set up
on Google infrastructure which polls git://git.denx.de/u-boot.git
every 5 minutes.

 URL for  browsing is https://u-boot.googlesource.com, and
https://u-boot-review.googlesource.com is actually a gerrit instance
ready to be used if ever decided.

It is an extremely high availability service with replicas in six
google datacenters across the globe. For those interested, here are
some slides describing a similar setup hosting android repositories:
https://sites.google.com/site/gerritsummit2012/program/Sunday-android.googlesource.com.pdf?attredirects=0&d=1

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

Re: [U-Boot] [PATCH 1/6] imx: mx6q DDR3 init: Fix tMRD

[Benoît Thébaudeau]

Hi Eric,

On Friday, February 1, 2013 12:14:53 AM, Eric Nelson wrote:
> On 01/30/2013 02:19 PM, Benoît Thébaudeau wrote:
> > MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.
> >
> > For all DDR3 speed bins:
> >tMRD(min) = 4 nCK
> >tMOD(min) = max(12 nCK, 15 ns)
> >
> > Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12
> > nCK
> > at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].
> >
> > Signed-off-by: Benoît Thébaudeau 
> > ---
> >   board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> > b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> > index c86cd40..9ac8027 100644
> > --- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> > +++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> > @@ -110,7 +110,7 @@ DATA 4 0x021b0018 0x00081740
> >
> >   DATA 4 0x021b001c 0x8000
> >   DATA 4 0x021b000c 0x555A7975
> > -DATA 4 0x021b0010 0xFF538E64
> > +DATA 4 0x021b0010 0xFF538F64
> >   DATA 4 0x021b0014 0x01FF00DB
> >   DATA 4 0x021b002c 0x26D2
> >
> >
> 
> Hi Benoît,
> 
> I've been able to confirm operation of this complete patch set
> on a SABRE Lite here, but only that (boots normally).

Great.

> I'll try to scare up a board we can place on an extended burn-in.

That'd be good.

> What prompted you to walk the list? Was there a specific failure
> that this addressed?

No specific failure. The only issue that I get from time to time is errors in
the Linux SD driver, but this is probably unrelated.

The only reason was that I was looking for possible better performance on the
RAM side because I am working on very intensive RAM accessing applications. So I
checked the init code to see if it was optimal, and I found these issues besides
the small possible performance gain.

So far, the default mtest passed on my board. The alternate mtest and more Linux
stress tests might be interesting too.

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

Re: [U-Boot] [PATCH v4] patman: Allow use outside of u-boot tree

[Simon Glass]

On Fri, Jan 11, 2013 at 6:29 AM, Vadim Bendebury  wrote:
> On Thu, Jan 10, 2013 at 9:05 AM, Simon Glass  wrote:
>> Hi Vadim,
>>
>> On Wed, Jan 9, 2013 at 6:00 PM, Vadim Bendebury  wrote:
>>> To make it usable in git trees not providing a patch checker
>>> implementation, add a command line option, allowing to suppress patch
>>> check. While we are at it, sort debug options alphabetically.
>>>
>>> Also, do not raise an exception if checkpatch.pl is not found - just
>>> print an error message suggesting to use the new option, and return
>>> nonzero status.
>>>
>>>. unit test passes:
>>> $ ./patman  -t
>>> 
>>>. successfully used patman in the autotest tree to generate a patch
>>>  email (with --no-check option)
>>>. successfully used patman in the u-boot tree to generate a patch
>>>  email
>>>. `patman --help' now shows command line options ordered
>>>  alphabetically
>>>
>>> Signed-off-by: Vadim Bendebury 
>>
>> Acked-by: Simon Glass 

Applied to u-boot-x86, thanks.

>>
>> BTW what is this patch against - it doesn't seem to apply to mainline for me.
>>
>
> Right, it depends on the previous patches which still have not been
> applied to the upstream ToT.
>
> cheers,
> /vb
>
>>> ---
>>> Changes in v4:
>>>   . now properly corrected typo in the error message
>>>
>>> Changes in v3:
>>>   . corrected typo in the error message
>>>
>>> Changes in v2:
>>>   . addressed comments WRT use of double negative
>>>   . added code to gracefully handle absence of checkpatch.cl
>>>
>>>  tools/patman/checkpatch.py |   10 +-
>>>  tools/patman/patman.py |   14 ++
>>>  2 files changed, 15 insertions(+), 9 deletions(-)
>> [snip]
>>
>> Regards,
>> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] patman: Add spaces back into patman test

[Simon Glass]

On Thu, Nov 29, 2012 at 12:47 PM, Simon Glass  wrote:
> On Mon, Nov 26, 2012 at 5:21 PM, Doug Anderson  wrote:
>> The patman test code was failing because some extra spaces got
>> stripped when it was applied.  These spaces are critical to the test
>> code working.
>>
>> Signed-off-by: Doug Anderson 
>
> Acked-by: Simon Glass 

Applied to u-boot-x86, thanks.

>
>>
>> ---
>>  tools/patman/test.py |6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/patman/test.py b/tools/patman/test.py
>> index cf42480..f801ced 100644
>> --- a/tools/patman/test.py
>> +++ b/tools/patman/test.py
>> @@ -119,8 +119,8 @@ index 6f3748d..f9e4e65 100644
>>  --- a/README
>>  +++ b/README
>>  @@ -2026,6 +2026,17 @@ The following options need to be configured:
>> -   example, some LED's) on your board. At the moment,
>> -   the following checkpoints are implemented:
>> +   example, some LED's) on your board. At the moment,
>> +   the following checkpoints are implemented:
>>
>>  +- Time boot progress
>>  +  CONFIG_BOOTSTAGE
>> @@ -134,7 +134,7 @@ index 6f3748d..f9e4e65 100644
>>  +  You can add calls to bootstage_mark() to set time markers.
>>  +
>>   - Standalone program support:
>> -   CONFIG_STANDALONE_LOAD_ADDR
>> +   CONFIG_STANDALONE_LOAD_ADDR
>>
>>  diff --git a/common/bootstage.c b/common/bootstage.c
>>  new file mode 100644
>> --
>> 1.7.7.3
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] patman: Allow tests to run even if patman is in the path

[Simon Glass]

On Thu, Nov 29, 2012 at 12:50 PM, Simon Glass  wrote:
> On Mon, Nov 26, 2012 at 5:21 PM, Doug Anderson  wrote:
>> Several of the patman doctests assume that patman was run with:
>>   ./patman
>>
>> Fix them so that they work even if patman is run with just "patman"
>> (because patman is in the path).
>>
>> Signed-off-by: Doug Anderson 
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] patman: Look for checkpatch in the scripts directory

[Simon Glass]

On Thu, Nov 29, 2012 at 12:46 PM, Simon Glass  wrote:
> On Mon, Nov 26, 2012 at 5:23 PM, Doug Anderson  wrote:
>> The Linux kernel stores checkpatch.pl in the scripts directory.  Add
>> that to the search path to make things more automatic for kernel
>> development.
>>
>> Signed-off-by: Doug Anderson 
>
> Acked-by: Simon Glass 

Applied to u-boot-x86, thanks.

>
>>
>> ---
>>  tools/patman/checkpatch.py |4 +++-
>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
>> index d831087..f72f8ee 100644
>> --- a/tools/patman/checkpatch.py
>> +++ b/tools/patman/checkpatch.py
>> @@ -26,10 +26,12 @@ import re
>>  import terminal
>>
>>  def FindCheckPatch():
>> +top_level = gitutil.GetTopLevel()
>>  try_list = [
>>  os.getcwd(),
>>  os.path.join(os.getcwd(), '..', '..'),
>> -os.path.join(gitutil.GetTopLevel(), 'tools'),
>> +os.path.join(top_level, 'tools'),
>> +os.path.join(top_level, 'scripts'),
>>  '%s/bin' % os.getenv('HOME'),
>>  ]
>>  # Look in current dir
>> --
>> 1.7.7.3
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] patman: Cache the CC list from MakeCcFile() for use in ShowActions()

[Simon Glass]

On Tue, Dec 4, 2012 at 1:40 PM, Doug Anderson  wrote:
> Currently we go through and generate the CC list for patches twice.
> This gets slow when (in a future CL) we add a call to
> get_maintainer.pl on Linux.  Instead of doing things twice, just cache
> the CC list when it is first generated.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2: None

Applied to u-boot-x86, thanks.

>
>  tools/patman/patman.py |6 --
>  tools/patman/series.py |   13 +
>  2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/tools/patman/patman.py b/tools/patman/patman.py
> index cfe06d0..de8314a 100755
> --- a/tools/patman/patman.py
> +++ b/tools/patman/patman.py
> @@ -140,14 +140,16 @@ else:
>  options.count + options.start):
>  ok = False
>
> +cc_file = series.MakeCcFile(options.process_tags)
> +
>  # Email the patches out (giving the user time to check / cancel)
>  cmd = ''
>  if ok or options.ignore_errors:
> -cc_file = series.MakeCcFile(options.process_tags)
>  cmd = gitutil.EmailPatches(series, cover_fname, args,
>  options.dry_run, cc_file)
> -os.remove(cc_file)
>
>  # For a dry run, just show our actions as a sanity check
>  if options.dry_run:
>  series.ShowActions(args, cmd, options.process_tags)
> +
> +os.remove(cc_file)
> diff --git a/tools/patman/series.py b/tools/patman/series.py
> index d2971f4..ad8288d 100644
> --- a/tools/patman/series.py
> +++ b/tools/patman/series.py
> @@ -46,6 +46,11 @@ class Series(dict):
>  self.notes = []
>  self.changes = {}
>
> +# Written in MakeCcFile()
> +#  key: name of patch file
> +#  value: list of email addresses
> +self._generated_cc = {}
> +
>  # These make us more like a dictionary
>  def __setattr__(self, name, value):
>  self[name] = value
> @@ -109,10 +114,7 @@ class Series(dict):
>  for upto in range(len(args)):
>  commit = self.commits[upto]
>  print col.Color(col.GREEN, '   %s' % args[upto])
> -cc_list = []
> -if process_tags:
> -cc_list += gitutil.BuildEmailList(commit.tags)
> -cc_list += gitutil.BuildEmailList(commit.cc_list)
> +cc_list = list(self._generated_cc[commit.patch])
>
>  # Skip items in To list
>  if 'to' in self:
> @@ -202,6 +204,8 @@ class Series(dict):
>  def MakeCcFile(self, process_tags):
>  """Make a cc file for us to use for per-commit Cc automation
>
> +Also stores in self._generated_cc to make ShowActions() faster.
> +
>  Args:
>  process_tags: Process tags as if they were aliases
>  Return:
> @@ -216,6 +220,7 @@ class Series(dict):
>  list += gitutil.BuildEmailList(commit.tags)
>  list += gitutil.BuildEmailList(commit.cc_list)
>  print >>fd, commit.patch, ', '.join(list)
> +self._generated_cc[commit.patch] = list
>
>  fd.close()
>  return fname
> --
> 1.7.7.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] patman: Add all CC addresses to the cover letter

[Simon Glass]

On Tue, Dec 4, 2012 at 1:54 PM, Simon Glass  wrote:
> On Mon, Dec 3, 2012 at 4:40 PM, Doug Anderson  wrote:
>> If we're sending a cover letter make sure to CC everyone that we're
>> CCing on each of the individual patches.
>>
>> Signed-off-by: Doug Anderson 
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2 1/4] patman: Add a call to get_maintainer.pl if it exists

[Simon Glass]

On Tue, Dec 4, 2012 at 1:43 PM, Doug Anderson  wrote:
> For Linux the best way to figure out where to send a patch is with the
> "get_maintainer.pl" script.  Add support for calling it from patman.
> Support is added unconditionally for "scripts/get_maintainer.pl" in
> case it is helpful for any other projects.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2: None

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

Re: [U-Boot] [PATCH v2 2/4] patman: Add support for settings in .patman

[Simon Glass]

On Tue, Dec 4, 2012 at 1:43 PM, Doug Anderson  wrote:
> This patch adds support for a [settings] section in the .patman file.
> In this section you can add settings that will affect the default
> values for command-line options.
>
> Support is added in a generic way such that any setting can be updated
> by just referring to the "dest" of the option that is passed to the
> option parser.  At the moment options that would make sense to put in
> settings are "ignore_errors", "process_tags", and "verbose".  You
> could override them like:
>
>  [settings]
>  ignore_errors: True
>  process_tags: False
>  verbose: True
>
> The settings functionality is also used in a future change which adds
> support for per-project settings.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2: None

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

Re: [U-Boot] [PATCH v2 3/4] patman: Add the concept of multiple projects

[Simon Glass]

On Tue, Dec 4, 2012 at 1:55 PM, Simon Glass  wrote:
> On Mon, Dec 3, 2012 at 4:43 PM, Doug Anderson  wrote:
>> There are cases that we want to support different settings (or maybe
>> even different aliases) for different projects.  Add support for this
>> by:
>> * Adding detection for two big projects: U-Boot and Linux.
>> * Adding default settings for Linux (U-Boot is already good with the
>>   standard patman defaults).
>> * Extend the new "settings" feature in .patman to specify per-project
>>   settings.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>> Changes in v2:
>> - Added requested short option: '-p'.
>
> Acked-by: Simon Glass 
>

Applied to u-boot-x86, thanks.

>>
>>  tools/patman/README  |   13 
>>  tools/patman/patman.py   |9 +++-
>>  tools/patman/project.py  |   43 +
>>  tools/patman/settings.py |  147 
>> +-
>>  4 files changed, 208 insertions(+), 4 deletions(-)
>>  create mode 100644 tools/patman/project.py
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] patman: Add settings to the list of modules to doctest

[Simon Glass]

On Tue, Dec 4, 2012 at 1:43 PM, Doug Anderson  wrote:
> The settings modules now has doctests, so run them.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2: None

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

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

[Simon Glass]

Hi Tom,

Here are the patman changes. I have left that ones that buildman
requires for now, since they are not needed for patman.

The following changes since commit 6ad77d88e57f6ab815ec7e85c5ac329054318c73:

  vfat: Fix mkcksum argument sizes (2013-01-31 14:43:01 -0500)

are available in the git repository at:

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

for you to fetch changes up to 99adf6eda7bed1beb3fa3e18951342f67b108db7:

  patman: Allow use outside of u-boot tree (2013-01-31 15:23:40 -0800)


Doug Anderson (9):
  patman: Add spaces back into patman test
  patman: Allow tests to run even if patman is in the path
  patman: Look for checkpatch in the scripts directory
  patman: Cache the CC list from MakeCcFile() for use in ShowActions()
  patman: Add all CC addresses to the cover letter
  patman: Add a call to get_maintainer.pl if it exists
  patman: Add support for settings in .patman
  patman: Add the concept of multiple projects
  patman: Add settings to the list of modules to doctest

Vadim Bendebury (1):
  patman: Allow use outside of u-boot tree

 tools/patman/README|  43 +-
 tools/patman/checkpatch.py |  14 ++--
 tools/patman/get_maintainer.py |  63 +++
 tools/patman/gitutil.py|  13 ++-
 tools/patman/patman.py |  29 +--
 tools/patman/project.py|  43 ++
 tools/patman/series.py |  27 +--
 tools/patman/settings.py   | 180 -
 tools/patman/test.py   |   6 +-
 9 files changed, 389 insertions(+), 29 deletions(-)
 create mode 100644 tools/patman/get_maintainer.py
 create mode 100644 tools/patman/project.py

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

Re: [U-Boot] call env print from uboot environment

[Rommel Custodio]

Dear Wolfgang,

Wolfgang Denk  denx.de> writes:

> 
> > What am I doing wrong.
> 
> Try instead:
> 
>   env import -b 2005
Skipping the CRC ... maybe "2004" is the correct address.

"env import -c 0x2000 0x200" if you want the CRC verified.


All the best,

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

Re: [U-Boot] [U-Boot,v2 6/6] sf: Set QUAD enable bit support

[Simon Glass]

Hi,

On Thu, Jan 31, 2013 at 10:49 AM, Jagan Teki  wrote:
> Hi Mike/Simon,
>
> Any further comments on this.

No further comment. It looks OK to me.

For all the other patches, it might be worth putting them in a single
series and sending them again once comments are addressed.

Acked-by: Simon Glass 

Regards,
Simon

>
> I have tested on real h/w target as well.
>
> Thanks,
> Jagan.
>
> On Sun, Dec 23, 2012 at 11:23 PM, Jagan Teki  wrote:
>> Tested on real hardware, works fine.
>>
>> Tested-by: Jagannadha Sutradharudu Teki 
>>
>> Thanks,
>> Jagan.
>>
>> On Wed, Dec 19, 2012 at 9:57 PM, Jagannadha Sutradharudu Teki
>>  wrote:
>>> This patch provides support to set the QUAD enable bit on flash.
>>>
>>> QUAD enable bit needs to set before performing any QUAD IO operations
>>> on respective SPI flashes.
>>>
>>> User need to use spi_flash_set_quad_enable_bit() to set the
>>> QUAD enable bit based on their usage.
>>>
>>> Signed-off-by: Jagannadha Sutradharudu Teki 
>>> ---
>>> Changes in v2:
>>> Improved code logic
>>>
>>>  drivers/mtd/spi/spi_flash.c  |   31 +++
>>>  drivers/mtd/spi/spi_flash_internal.h |4 
>>>  2 files changed, 35 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
>>> index 5bddde4..675a0bf 100644
>>> --- a/drivers/mtd/spi/spi_flash.c
>>> +++ b/drivers/mtd/spi/spi_flash.c
>>> @@ -329,6 +329,37 @@ int spi_flash_cmd_read_config(struct spi_flash *flash, 
>>> void *data)
>>> return 0;
>>>  }
>>>
>>> +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
>>> +{
>>> +   u8 data = 0, write_done = 0;
>>> +   int ret, pass;
>>> +
>>> +   for (pass = 0; pass < 2; pass++) {
>>> +   ret = spi_flash_cmd_read_config(flash, (void *)&data);
>>> +   if (ret < 0) {
>>> +   debug("SF: fail to read config register\n");
>>> +   return ret;
>>> +   }
>>> +
>>> +   if (data & STATUS_QEB) {
>>> +   debug("SF: quad enable bit is set.\n");
>>> +   return ret;
>>> +   } else if (write_done != 1) {
>>> +   debug("SF: need to set quad enable bit\n");
>>> +
>>> +   write_done = 1;
>>> +   ret = spi_flash_cmd_write_config(flash, STATUS_QEB);
>>> +   if (ret < 0) {
>>> +   debug("SF: fail to write quad enable 
>>> bit\n");
>>> +   return ret;
>>> +   }
>>> +   }
>>> +   }
>>> +
>>> +   debug("SF: fail to set quad enable bit\n");
>>> +   return -1;
>>> +}
>>> +
>>>  /*
>>>   * The following table holds all device probe functions
>>>   *
>>> diff --git a/drivers/mtd/spi/spi_flash_internal.h 
>>> b/drivers/mtd/spi/spi_flash_internal.h
>>> index 844e82e..15c7ac4 100644
>>> --- a/drivers/mtd/spi/spi_flash_internal.h
>>> +++ b/drivers/mtd/spi/spi_flash_internal.h
>>> @@ -31,6 +31,7 @@
>>>
>>>  /* Common status */
>>>  #define STATUS_WIP 0x01
>>> +#define STATUS_QEB 0x02
>>>
>>>  /* Send a single-byte command to the device and read the response */
>>>  int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t 
>>> len);
>>> @@ -87,6 +88,9 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, 
>>> u8 cr);
>>>  /* Read the config register */
>>>  int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
>>>
>>> +/* Set the QUAD enable bit */
>>> +int spi_flash_set_quad_enable_bit(struct spi_flash *flash);
>>> +
>>>  /*
>>>   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
>>>   * bus. Used as common part of the ->read() operation.
>>> --
>>> 1.7.0.4
>>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot repository mirror and gerrit on Google inftrastructure

[Wolfgang Denk]

Dear Vadim Bendebury,

In message  
you wrote:
> Just wanted to let everybody know that there has been a mirror set up
> on Google infrastructure which polls git://git.denx.de/u-boot.git
> every 5 minutes.

Every 5 minutes?  Are you crazy???  Please stop doing this now!
You are just putting a lot of load on our server, thus hampering
regular work.

And it makjes zero sense, as the data on the public server get updated
only every 6 hours.

>  URL for  browsing is https://u-boot.googlesource.com, and
> https://u-boot-review.googlesource.com is actually a gerrit instance
> ready to be used if ever decided.

We discussed this in the past, and decided not to, as it does not fit
at all into our mainly e-mail based work flow.


So please STOP sabotaging our server!

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
You said you  didn't  want  to  use  CGI.pm,  but  methinks  you  are
needlessly reinventing the wheel, one spoke at a time. Either you are
masochistic,  or  you  just haven't seen enough of what CGI.pm can do
for you. -- Randal L. Schwartz in <8cyb81rg81@gadget.cscaper.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest stable u-boot-ppc4xx tree for ppc405

[Wolfgang Denk]

Dear Frank Lombardo,

In message  
you wrote:
>
> Is there a stable u-boot-ppc4xx tree to support a board with a Virtex 4
> (ppc405)?  The latest tag I see for that is U-Boot-1_2_0 which is 6 years
> old.  If not, what is the best way to get u-boot running on our custom
> Virtex 4 board?

Just use mainline...

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
Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht ge-
nug zu wollen, man muß auch tun.   -- Goethe, Maximen und Reflexionen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] call env print from uboot environment

[Wolfgang Denk]

Dear Rommel Custodio,

In message  you wrote:
> Dear Wolfgang,
> 
> Wolfgang Denk  denx.de> writes:
> 
> > 
> > > What am I doing wrong.
> > 
> > Try instead:
> > 
> > env import -b 2005
> Skipping the CRC ... maybe "2004" is the correct address.

No.  As I mentioned before, this environment was set up for redundant
env, and has a flag byte after the CRC. So you must start at offset 5.

> "env import -c 0x2000 0x200" if you want the CRC verified.

Which will not work, as there is no valid CRC in his environment.

You should actually read what I wrote before trying to correct me.

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
A good marriage would be between a blind wife and deaf husband.
   -- Michel de Montaigne
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/7 V3] EXYNOS5: Add audio support for Snow

[Rajeshwari Shinde]

This patch set creats a new configuration file and DTS file for Snow.
Driver for MAX98095 is added and support for same is incorporated in
sound driver and Snow Board.
This patchset is based on top of 
"[U-Boot] [PATCH 0/2 V2] SMDK5250: Set Initial PMIC Values"

Changes in V2:
- Corrected multi-line comment style
Changes in V3:
- Removed non DT support for MAX98095
- Config for both MAX98095 and WM8994 added in
exynos5 config file.

Rajeshwari Shinde (7):
  EXYNOS5: Add function to enable XXTI clock source
  Sound: MAX98095: Add the driver for codec
  Sound: Support for MAX98095 codec in driver
  EXYNOS5: GPIO to enable MAX98095
  EXYNOS5: FDT: Add compatible strings for MAX98095
  EXYNOS5: Add initial DTS file for Snow.
  EXYNOS5: Snow: Add a configuration file

 arch/arm/cpu/armv7/exynos/power.c|   11 +
 arch/arm/include/asm/arch-exynos/power.h |   11 +
 board/samsung/dts/exynos5250-snow.dts|   69 
 board/samsung/smdk5250/smdk5250.c|   15 +
 boards.cfg   |1 +
 drivers/sound/Makefile   |1 +
 drivers/sound/max98095.c |  550 ++
 drivers/sound/max98095.h |  311 +
 drivers/sound/sound.c|   10 +-
 include/configs/exynos5250-dt.h  |1 +
 include/configs/snow.h   |   33 ++
 include/fdtdec.h |1 +
 include/sound.h  |1 +
 lib/fdtdec.c |1 +
 14 files changed, 1014 insertions(+), 2 deletions(-)
 create mode 100644 board/samsung/dts/exynos5250-snow.dts
 create mode 100644 drivers/sound/max98095.c
 create mode 100644 drivers/sound/max98095.h
 create mode 100644 include/configs/snow.h

-- 
1.7.4.4

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

[U-Boot] [PATCH 1/7 V3] EXYNOS5: Add function to enable XXTI clock source

[Rajeshwari Shinde]

This patch adds funtion to enable XXTI clock source
required by MAX98095 codec.

Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Changes in V2:
- Corrected multi-line comment style
Chnages in V3:
- None
 arch/arm/cpu/armv7/exynos/power.c|   11 +++
 arch/arm/include/asm/arch-exynos/power.h |   11 +++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/power.c 
b/arch/arm/cpu/armv7/exynos/power.c
index 8572cfd..8de30c1 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -105,3 +105,14 @@ void power_ps_hold_setup(void)
setbits_le32(&power->ps_hold_control,
EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
 }
+
+
+void power_enable_xclkout(void)
+{
+   struct exynos5_power *power =
+   (struct exynos5_power *)samsung_get_base_power();
+
+   /* use xxti for xclk out */
+   clrsetbits_le32(&power->pmu_debug, PMU_DEBUG_CLKOUT_SEL_MASK,
+   PMU_DEBUG_XXTI);
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h 
b/arch/arm/include/asm/arch-exynos/power.h
index 85e2cd9..9afd3ed 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -872,4 +872,15 @@ void set_dp_phy_ctrl(unsigned int enable);
  * (e.g. power button).
  */
 void power_ps_hold_setup(void);
+
+/* PMU_DEBUG bits [12:8] = 0x1000 selects XXTI clock source */
+#define PMU_DEBUG_XXTI  0x1000
+/* Mask bit[12:8] for xxti clock selection */
+#define PMU_DEBUG_CLKOUT_SEL_MASK   0x1f00
+
+/*
+ * Pmu debug is used for xclkout, enable xclkout with
+ * source as XXTI
+ */
+void power_enable_xclkout(void);
 #endif
-- 
1.7.4.4

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

[U-Boot] [PATCH 2/7 V3] Sound: MAX98095: Add the driver for codec

[Rajeshwari Shinde]

This patch adds the driver for codec MAX98095 required by Snow
Board

Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Chnages in V2:
- None
Changes in V3:
- None
 drivers/sound/Makefile   |1 +
 drivers/sound/max98095.c |  550 ++
 drivers/sound/max98095.h |  311 ++
 3 files changed, 862 insertions(+), 0 deletions(-)
 create mode 100644 drivers/sound/max98095.c
 create mode 100644 drivers/sound/max98095.h

diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 8fdffb1..1987ca1 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -28,6 +28,7 @@ LIB   := $(obj)libsound.o
 COBJS-$(CONFIG_SOUND)  += sound.o
 COBJS-$(CONFIG_I2S)+= samsung-i2s.o
 COBJS-$(CONFIG_SOUND_WM8994)   += wm8994.o
+COBJS-$(CONFIG_SOUND_MAX98095) += max98095.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/sound/max98095.c b/drivers/sound/max98095.c
new file mode 100644
index 000..0beee56
--- /dev/null
+++ b/drivers/sound/max98095.c
@@ -0,0 +1,550 @@
+/*
+ * max98095.c -- MAX98095 ALSA SoC Audio driver
+ *
+ * Copyright 2011 Maxim Integrated Products
+ *
+ * Modified for uboot by R. Chandrasekar (rcse...@samsung.com)
+ *
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2s.h"
+#include "max98095.h"
+
+enum max98095_type {
+   MAX98095,
+};
+
+struct max98095_priv {
+   enum max98095_type devtype;
+   unsigned int sysclk;
+   unsigned int rate;
+   unsigned int fmt;
+};
+
+static struct sound_codec_info g_codec_info;
+struct max98095_priv g_max98095_info;
+unsigned int g_max98095_i2c_dev_addr;
+
+/* Index 0 is reserved. */
+int rate_table[] = {0, 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000,
+   88200, 96000};
+
+/*
+ * Writes value to a device register through i2c
+ *
+ * @param reg  reg number to be write
+ * @param data data to be writen to the above registor
+ *
+ * @return int value 1 for change, 0 for no change or negative error code.
+ */
+static int max98095_i2c_write(unsigned int reg, unsigned char data)
+{
+   debug("%s: Write Addr : 0x%02X, Data :  0x%02X\n",
+   __func__, reg, data);
+   return i2c_write(g_max98095_i2c_dev_addr, reg, 1, &data, 1);
+}
+
+/*
+ * Read a value from a device register through i2c
+ *
+ * @param reg  reg number to be read
+ * @param data address of read data to be stored
+ *
+ * @return int value 0 for success, -1 in case of error.
+ */
+static unsigned int max98095_i2c_read(unsigned int reg, unsigned char *data)
+{
+   int ret;
+
+   ret = i2c_read(g_max98095_i2c_dev_addr, reg, 1, data, 1);
+   if (ret != 0) {
+   debug("%s: Error while reading register %#04x\n",
+   __func__, reg);
+   return -1;
+   }
+
+   return 0;
+}
+
+/*
+ * update device register bits through i2c
+ *
+ * @param reg  codec register
+ * @param mask register mask
+ * @param valuenew value
+ *
+ * @return int value 0 for success, non-zero error code.
+ */
+static int max98095_update_bits(unsigned int reg, unsigned char mask,
+   unsigned char value)
+{
+   int change, ret = 0;
+   unsigned char old, new;
+
+   if (max98095_i2c_read(reg, &old) != 0)
+   return -1;
+   new = (old & ~mask) | (value & mask);
+   change  = (old != new) ? 1 : 0;
+   if (change)
+   ret = max98095_i2c_write(reg, new);
+   if (ret < 0)
+   return ret;
+
+   return change;
+}
+
+/*
+ * codec mclk clock divider coefficients based on sampling rate
+ *
+ * @param rate sampling rate
+ * @param value address of indexvalue to be stored
+ *
+ * @return 0 for success or negative error code.
+ */
+static int rate_value(int rate, u8 *value)
+{
+   int i;
+
+   for (i = 1; i < ARRAY_SIZE(rate_table); i++) {
+   if (rate_table[i] >= rate) {
+   *value = i;
+   return 0;
+   }
+   }
+   *value = 1;
+
+   return -1;
+}
+
+/*
+ * Sets hw params for max98095
+ *
+ * @param max98095 max98095 information pointer
+ * @param rate Sampling rate
+ * @param bits_per_sample  Bits per sample
+ *
+ * @return -1 for error  and 0  Success.
+ */
+static int max98095_hw_params(struct max98095_priv *max98095,
+   unsigned int rate, unsigned int bits_per_sample)
+{
+   u8 regval;
+   int error;
+
+   switch (bits_per_sample) {
+   case 16:
+   error = max98095_update_bits(M98095_034_DAI2_FORMAT,
+   M98095_DAI_WS, 0);
+   break;
+   case 24:
+   err

[U-Boot] [PATCH 3/7 V3] Sound: Support for MAX98095 codec in driver

[Rajeshwari Shinde]

This patchs adds support for MAX98095 codec in
sound driver.

Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- None
Chnages in V3:
- Removed non DT support for MAX98095
 drivers/sound/sound.c |9 +++--
 include/sound.h   |1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/sound/sound.c b/drivers/sound/sound.c
index fa8432d..a4bf4ad 100644
--- a/drivers/sound/sound.c
+++ b/drivers/sound/sound.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include "wm8994.h"
+#include "max98095.h"
 
 /* defines */
 #define SOUND_400_HZ 400
@@ -149,11 +150,15 @@ static int codec_init(const void *blob, struct i2stx_info 
*pi2s_tx)
pi2s_tx->samplingrate,
(pi2s_tx->samplingrate * (pi2s_tx->rfs)),
pi2s_tx->bitspersample, pi2s_tx->channels);
+   } else if (!strcmp(codectype, "max98095")) {
+   ret = max98095_init(blob, pi2s_tx->samplingrate,
+   (pi2s_tx->samplingrate * (pi2s_tx->rfs)),
+   pi2s_tx->bitspersample);
} else {
-   debug("%s: Unknown code type %s\n", __func__,
- codectype);
+   debug("%s: Unknown codec type %s\n", __func__, codectype);
return -1;
}
+
if (ret) {
debug("%s: Codec init failed\n", __func__);
return -1;
diff --git a/include/sound.h b/include/sound.h
index d73839d..94922f6 100644
--- a/include/sound.h
+++ b/include/sound.h
@@ -28,6 +28,7 @@
 enum en_sound_codec {
CODEC_WM_8994,
CODEC_WM_8995,
+   CODEC_MAX_98095,
CODEC_MAX
 };
 
-- 
1.7.4.4

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

[U-Boot] [PATCH 5/7 V3] EXYNOS5: FDT: Add compatible strings for MAX98095

[Rajeshwari Shinde]

Add required compatible information for MAX98095 codec

Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Chnages in V2:
- None
Changes in V3:
- None
 include/fdtdec.h |1 +
 lib/fdtdec.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..e76cdc1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -79,6 +79,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY,  /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+   COMPAT_MAXIM_98095_CODEC,   /* MAX98095 Codec */
 
COMPAT_COUNT,
 };
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..a5f770f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -54,6 +54,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, "samsung,exynos-ehci"),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, "samsung,exynos-usb-phy"),
COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
+   COMPAT(MAXIM_98095_CODEC, "maxim,max98095-codec"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
-- 
1.7.4.4

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

[U-Boot] [PATCH 4/7 V3] EXYNOS5: GPIO to enable MAX98095

[Rajeshwari Shinde]

This patch sets high a GPIO to enable the codec MAX98095

Signed-off-by: Rajeshwari Shinde 
Acked-by: Simon Glass 
---
Changes in V2:
- None
Changes in V3:
- None
 board/samsung/smdk5250/smdk5250.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index 12cc03e..6f2e067 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -56,6 +56,18 @@ int board_usb_vbus_init(void)
 }
 #endif
 
+#ifdef CONFIG_SOUND_MAX98095
+static void  board_enable_audio_codec(void)
+{
+   struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
+   samsung_get_base_gpio_part1();
+
+   /* Enable MAX98095 Codec */
+   s5p_gpio_direction_output(&gpio1->x1, 7, 1);
+   s5p_gpio_set_pull(&gpio1->x1, 7, GPIO_PULL_NONE);
+}
+#endif
+
 int board_init(void)
 {
gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
@@ -65,6 +77,9 @@ int board_init(void)
 #ifdef CONFIG_USB_EHCI_EXYNOS
board_usb_vbus_init();
 #endif
+#ifdef CONFIG_SOUND_MAX98095
+   board_enable_audio_codec();
+#endif
return 0;
 }
 
-- 
1.7.4.4

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

[U-Boot] [PATCH 6/7 V3] EXYNOS5: Add initial DTS file for Snow.

[Rajeshwari Shinde]

This patch adds the DTS file for Snow Board.

Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
-None
Changes in V3:
- None
 board/samsung/dts/exynos5250-snow.dts |   69 +
 1 files changed, 69 insertions(+), 0 deletions(-)
 create mode 100644 board/samsung/dts/exynos5250-snow.dts

diff --git a/board/samsung/dts/exynos5250-snow.dts 
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..af788a6
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG SMDK5250 board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+   model = "Google Snow";
+   compatible = "google,snow", "samsung,exynos5250";
+
+   aliases {
+   i2c0 = "/i2c@12c6";
+   i2c1 = "/i2c@12c7";
+   i2c2 = "/i2c@12c8";
+   i2c3 = "/i2c@12c9";
+   i2c4 = "/i2c@12ca";
+   i2c5 = "/i2c@12cb";
+   i2c6 = "/i2c@12cc";
+   i2c7 = "/i2c@12cd";
+   spi0 = "/spi@12d2";
+   spi1 = "/spi@12d3";
+   spi2 = "/spi@12d4";
+   spi3 = "/spi@131a";
+   spi4 = "/spi@131b";
+   };
+
+   sromc@1225 {
+   bank = <1>;
+   srom-timing = <1 9 12 1 6 1 1>;
+   width = <2>;
+   lan@500 {
+   compatible = "smsc,lan9215", "smsc,lan";
+   reg = <0x500 0x100>;
+   phy-mode = "mii";
+   };
+   };
+
+   sound@12d6 {
+   samsung,i2s-epll-clock-frequency = <19200>;
+   samsung,i2s-sampling-rate = <48000>;
+   samsung,i2s-bits-per-sample = <16>;
+   samsung,i2s-channels = <2>;
+   samsung,i2s-lr-clk-framesize = <256>;
+   samsung,i2s-bit-clk-framesize = <32>;
+   samsung,codec-type = "max98095";
+   };
+
+   i2c@12cd {
+   soundcodec@22 {
+   reg = <0x22>;
+   compatible = "maxim,max98095-codec";
+   };
+   };
+
+   i2c@12c6 {
+   pmic@9 {
+   reg = <0x9>;
+   compatible = "maxim,max77686_pmic";
+   };
+   };
+};
-- 
1.7.4.4

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

[U-Boot] [PATCH 7/7 V3] EXYNOS5: Snow: Add a configuration file

[Rajeshwari Shinde]

This patch adds the configuration file for Snow Board and
defines the same in boards.cfg.

Signed-off-by: Rajeshwari Shinde 
---
Changes in V2:
- None.
Changes in V3:
- Moved CONFIG_SOUND_MAX98095 to exynos5250-dt.h
 boards.cfg  |1 +
 include/configs/exynos5250-dt.h |1 +
 include/configs/snow.h  |   33 +
 3 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 include/configs/snow.h

diff --git a/boards.cfg b/boards.cfg
index e4b0d44..f247b03 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -283,6 +283,7 @@ s5p_goni arm armv7   goni   
 samsung
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
 origen  arm armv7   origen  
samsungexynos
 s5pc210_universalarm armv7   universal_c210  
samsungexynos
+snowarm armv7   smdk5250
samsungexynos
 smdk5250arm armv7   smdk5250
samsungexynos
 smdkv310arm armv7   smdkv310
samsungexynos
 tratsarm armv7   trats   
samsungexynos
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index a01fb96..b1b24a9 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -298,6 +298,7 @@
 #define CONFIG_SOUND
 #define CONFIG_I2S
 #define CONFIG_SOUND_WM8994
+#define CONFIG_SOUND_MAX98095
 #endif
 
 /* Enable devicetree support */
diff --git a/include/configs/snow.h b/include/configs/snow.h
new file mode 100644
index 000..1dc491b
--- /dev/null
+++ b/include/configs/snow.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ *
+ * Configuration settings for the SAMSUNG SMDK5250 board.
+ *
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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
+ */
+
+#ifndef __CONFIG_SMDK_H
+#define __CONFIG_SMDK_H
+
+#include 
+
+#undef CONFIG_DEFAULT_DEVICE_TREE
+#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow
+
+#endif /* __CONFIG_SMDK_H */
-- 
1.7.4.4

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

Re: [U-Boot] [U-Boot,v2 6/6] sf: Set QUAD enable bit support

[Jagan Teki]

Hi Simon,

On Fri, Feb 1, 2013 at 10:00 AM, Simon Glass  wrote:
> Hi,
>
> On Thu, Jan 31, 2013 at 10:49 AM, Jagan Teki  wrote:
>> Hi Mike/Simon,
>>
>> Any further comments on this.
>
> No further comment. It looks OK to me.
>
> For all the other patches, it might be worth putting them in a single
> series and sending them again once comments are addressed.

Thanks for your quick response.

I will pack all the patches in one series and send.

Thanks,
Jagan.

>
> Acked-by: Simon Glass 
>
> Regards,
> Simon
>
>>
>> I have tested on real h/w target as well.
>>
>> Thanks,
>> Jagan.
>>
>> On Sun, Dec 23, 2012 at 11:23 PM, Jagan Teki  
>> wrote:
>>> Tested on real hardware, works fine.
>>>
>>> Tested-by: Jagannadha Sutradharudu Teki 
>>>
>>> Thanks,
>>> Jagan.
>>>
>>> On Wed, Dec 19, 2012 at 9:57 PM, Jagannadha Sutradharudu Teki
>>>  wrote:
 This patch provides support to set the QUAD enable bit on flash.

 QUAD enable bit needs to set before performing any QUAD IO operations
 on respective SPI flashes.

 User need to use spi_flash_set_quad_enable_bit() to set the
 QUAD enable bit based on their usage.

 Signed-off-by: Jagannadha Sutradharudu Teki 
 ---
 Changes in v2:
 Improved code logic

  drivers/mtd/spi/spi_flash.c  |   31 
 +++
  drivers/mtd/spi/spi_flash_internal.h |4 
  2 files changed, 35 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 5bddde4..675a0bf 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -329,6 +329,37 @@ int spi_flash_cmd_read_config(struct spi_flash 
 *flash, void *data)
 return 0;
  }

 +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
 +{
 +   u8 data = 0, write_done = 0;
 +   int ret, pass;
 +
 +   for (pass = 0; pass < 2; pass++) {
 +   ret = spi_flash_cmd_read_config(flash, (void *)&data);
 +   if (ret < 0) {
 +   debug("SF: fail to read config register\n");
 +   return ret;
 +   }
 +
 +   if (data & STATUS_QEB) {
 +   debug("SF: quad enable bit is set.\n");
 +   return ret;
 +   } else if (write_done != 1) {
 +   debug("SF: need to set quad enable bit\n");
 +
 +   write_done = 1;
 +   ret = spi_flash_cmd_write_config(flash, 
 STATUS_QEB);
 +   if (ret < 0) {
 +   debug("SF: fail to write quad enable 
 bit\n");
 +   return ret;
 +   }
 +   }
 +   }
 +
 +   debug("SF: fail to set quad enable bit\n");
 +   return -1;
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 844e82e..15c7ac4 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -31,6 +31,7 @@

  /* Common status */
  #define STATUS_WIP 0x01
 +#define STATUS_QEB 0x02

  /* Send a single-byte command to the device and read the response */
  int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t 
 len);
 @@ -87,6 +88,9 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, 
 u8 cr);
  /* Read the config register */
  int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);

 +/* Set the QUAD enable bit */
 +int spi_flash_set_quad_enable_bit(struct spi_flash *flash);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the ->read() operation.
 --
 1.7.0.4

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

Re: [U-Boot] [PATCH 1/7] ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register

[R Sricharan]

On Thursday 31 January 2013 09:59 PM, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 12:51 AM, R Sricharan wrote:

From: Lokesh Vutla 

Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards

Signed-off-by: R Sricharan  Signed-off-by:
Lokesh Vutla 


Does this mean the ROM is already doing some basic EMIF programming
here?  I swear I looked down this path before, when I wanted to share
this code with am33xx and the problem is that while the registers
aren't reset on warm boot, on cold boot they always come up in a
default value, for both DDR2 and DDR3.

Or are you able to get by as the platforms come up with different
default values?


 Not the ROMCODE, the default value for SDRAM_CONFIG register is
 exported from control module register based on efuse settings. We did
 see that this default value was correct depending upon LPDDR2 or DDR3
 in the case of OMAP.

 So does this mean that am3xx did not have the logic to
 load this register dynamically based on efuse settings ?
 If that is the only exception, then we can hardcode the register
 during startup only in that case. Except for this, where you able
 to use the emif-common driver in your case ?

Regards,
 Sricharan

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

[U-Boot] patchwork issue???

[Xie Shaohui-B21989]

Can anyone help? Thanks!

My patches sent since Jan are not showing in patch work, but I can find them in
http://lists.denx.de/pipermail/u-boot/2013-January/date.html#145232

I sent patches like I did in past and it worked well before Jan-2013.
what could be wrong?


Best Regards,
Shaohui Xie

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

Re: [U-Boot] [PATCH 2/7] ARM: OMAP4+: Change the PRCM structure prototype common for all Socs

[R Sricharan]

On Thursday 31 January 2013 10:10 PM, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 12:52 AM, R Sricharan wrote:

The current PRCM structure prototype directly matches the hardware
  register layout. So there is a need to change this for every new
silicon revision which has register space changes.

Avoiding this by making the prototye generic and populating the
register addresses seperately for all Socs.

Signed-off-by: R Sricharan 

[snip]

arch/arm/cpu/armv7/omap4/prcm-regs.c   |  267 
  arch/arm/cpu/armv7/omap5/prcm-regs.c   |  278
+


These two are missing license information, please fix.


 Sorry for missing this. Will send a V2

Otherwise, I like the concept and I think it all looks fine.  We stay
about the same, binary size wise with all of this, correct?

 Yes,i checked this after the change.The spl size for OMAP4 is still 
29KB and less than the limit (32KB). The size is never an issue with OMAP5


Regards,
 Sricharan

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

Re: [U-Boot] [PATCH 4/7] ARM: OMAP4+: Clean up the pmic code

[R Sricharan]

Hi Tom,

On Thursday 31 January 2013 10:31 PM, Tom Rini wrote:

On Thu, Jan 31, 2013 at 11:22:02AM +0530, R Sricharan wrote:


The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.

Signed-off-by: R Sricharan 

[snip]

+++ b/arch/arm/cpu/armv7/omap4/hw_data.c

[snip]

+struct vcores_data omap4430_volts_es1 = {
+   .mpu.value = 1325, .mpu.addr = SMPS_REG_ADDR_VCORE1,
+  .mpu.pmic = &twl6030_4430es1,


Here and in omap5/hw_data.c, split these up into multiple lines.


Thanks for reviewing all. Will correct this and send a consolidated
V2.

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

Re: [U-Boot] u-boot repository mirror and gerrit on Google inftrastructure

[Vadim Bendebury]

On Thu, Jan 31, 2013 at 9:23 PM, Wolfgang Denk  wrote:
> Dear Vadim Bendebury,
>
> In message 
>  you 
> wrote:
>> Just wanted to let everybody know that there has been a mirror set up
>> on Google infrastructure which polls git://git.denx.de/u-boot.git
>> every 5 minutes.
>
> Every 5 minutes?  Are you crazy???  Please stop doing this now!
> You are just putting a lot of load on our server, thus hampering
> regular work.
>
> And it makjes zero sense, as the data on the public server get updated
> only every 6 hours.
>
>>  URL for  browsing is https://u-boot.googlesource.com, and
>> https://u-boot-review.googlesource.com is actually a gerrit instance
>> ready to be used if ever decided.
>
> We discussed this in the past, and decided not to, as it does not fit
> at all into our mainly e-mail based work flow.
>
>
> So please STOP sabotaging our server!
>

Well, I should have asked for details and share the plans before
setting this up. As briefly discussed offline, I will change this to
poll once in six hours soon after each public server update.

cheers,
/vb

> 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
> You said you  didn't  want  to  use  CGI.pm,  but  methinks  you  are
> needlessly reinventing the wheel, one spoke at a time. Either you are
> masochistic,  or  you  just haven't seen enough of what CGI.pm can do
> for you. -- Randal L. Schwartz in <8cyb81rg81@gadget.cscaper.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: fix bug on relocation address

[Heiko Schocher]

Hello Luca,

on 31.01.2013 15:29, Luca Ellero wrote:
> If (N. SDRAM banks > 1) and they are not contiguous, don't relocate
> u-boot at (CONFIG_SYS_SDRAM_BASE + gd->ram_size), which is a bug.
> Instead use the end of 2nd bank (even if there are more than 2 banks)
> 
> Signed-off-by: Luca Ellero 
> Cc: Albert Aribaud 
> Cc: Heiko Schocher 
> ---
> 
> On ARM architectures there is a bug getting top of SDRAM (where u-boot 
> will be relocated). Top of SDRAM will always be:
> 
> CONFIG_SYS_SDRAM_BASE + gd->ram_size
> 
> anyway this can be wrong since SDRAM can be composed by more that one 
> bank in not-contiguous address space.
> (CONFIG_SYS_SDRAM_BASE + gd->ram_size) can land to not existent SDRAM 
> addresses and can be very dangerous since it can potentially corrupt 
> real SDRAM (in most cases SDRAM is aliased so writing to some 
> not-existent address can write to real address).
> Some arch use more than 2 banks but implementing all macros checks to 
> PHYS_SDRAM_* leads to very ugly code, so I think using 2nd bank is good 
> and does not generates bloated code

This is not a valid use case for U-Boot! Look in the README
section "Memory Management". This is not so trivial as it looks,
as for example the stack pointer starts somewhere near the end
of RAM and grows downwards. If you now have RAM with gaps, it maybe
reaches an address, which is not valid ...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/1] Davinci: Make MAC address offset in EEPROM configurable

[Kim Bøndergaard]

Like subjects say, offset of MAC adress in EEPROM changed from hardcoded value 
to 
a per board configurable value

The following changes since commit 79af5f82d78b8bbc5fe81302b8a4b7fb5d880f25:

  Davinci: Fix, console output confusing while setting MAC address (2013-02-01 
07:04:12 +)

are available in the git repository at:

  git://gitorious.org/~kibo/u-boot-shr/kibos-u-boot kibo-master
  http://gitorious.org/~kibo/u-boot-shr/kibos-u-boot/commits/kibo-master

Kim Bøndergaard (1):
  Davinci: Make MAC address offset in EEPROM configurable 
CONFIG_SYS_I2C_EEPROM_MAC_OFFSET

 arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +-
 include/configs/da830evm.h| 1 +
 include/configs/davinci_dm365evm.h| 1 +
 include/configs/davinci_dm6467evm.h   | 1 +
 include/configs/davinci_dvevm.h   | 1 +
 include/configs/davinci_sffsdr.h  | 1 +
 include/configs/davinci_sonata.h  | 1 +
 7 files changed, 7 insertions(+), 1 deletion(-)

-- 
1.8.0.3

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

[U-Boot] [PATCH 1/1] Davinci: Make MAC address offset in EEPROM configurable CONFIG_SYS_I2C_EEPROM_MAC_OFFSET

[Kim Bøndergaard]

---
 arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +-
 include/configs/da830evm.h| 1 +
 include/configs/davinci_dm365evm.h| 1 +
 include/configs/davinci_dm6467evm.h   | 1 +
 include/configs/davinci_dvevm.h   | 1 +
 include/configs/davinci_sffsdr.h  | 1 +
 include/configs/davinci_sonata.h  | 1 +
 7 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c 
b/arch/arm/cpu/arm926ejs/davinci/misc.c
index 7e5728c..3e82d9a 100644
--- a/arch/arm/cpu/arm926ejs/davinci/misc.c
+++ b/arch/arm/cpu/arm926ejs/davinci/misc.c
@@ -59,7 +59,7 @@ int dvevm_read_mac_address(uint8_t *buf)
 {
 #ifdef CONFIG_SYS_I2C_EEPROM_ADDR
/* Read MAC address. */
-   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0x7F00,
+   if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 
CONFIG_SYS_I2C_EEPROM_MAC_OFFSET,
CONFIG_SYS_I2C_EEPROM_ADDR_LEN, (uint8_t *) &buf[0], 6))
goto i2cerr;
 
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index f7ac256..2fa4a79 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -80,6 +80,7 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  6
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 
 /*
  * Network & Ethernet Configuration
diff --git a/include/configs/davinci_dm365evm.h 
b/include/configs/davinci_dm365evm.h
index 6a331aa..72ec862 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -53,6 +53,7 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  6
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 
 /* Network Configuration */
 #define CONFIG_DRIVER_TI_EMAC
diff --git a/include/configs/davinci_dm6467evm.h 
b/include/configs/davinci_dm6467evm.h
index 366c77f..93da788 100644
--- a/include/configs/davinci_dm6467evm.h
+++ b/include/configs/davinci_dm6467evm.h
@@ -48,6 +48,7 @@ extern unsigned int davinci_arm_clk_get(void);
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  6
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 
 /* Memory Info */
 #define CONFIG_SYS_MALLOC_LEN  (1 << 20)   /* 1 MiB */
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index ab9cedd..c7917b4 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -67,6 +67,7 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  6
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 /*=*/
 /* Memory Info */
 /*=*/
diff --git a/include/configs/davinci_sffsdr.h b/include/configs/davinci_sffsdr.h
index 958b19a..d150f9e 100644
--- a/include/configs/davinci_sffsdr.h
+++ b/include/configs/davinci_sffsdr.h
@@ -39,6 +39,7 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  5
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 /* Memory Info */
 #define CONFIG_SYS_MALLOC_LEN  (0x1 + 256*1024)/* malloc() len 
*/
 #define CONFIG_SYS_MEMTEST_START   0x8000  /* memtest start 
address */
diff --git a/include/configs/davinci_sonata.h b/include/configs/davinci_sonata.h
index 3d8d392..fdec085 100644
--- a/include/configs/davinci_sonata.h
+++ b/include/configs/davinci_sonata.h
@@ -69,6 +69,7 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  6
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
+#define CONFIG_SYS_I2C_EEPROM_MAC_OFFSET   0x7F00
 /*=*/
 /* Memory Info */
 /*=*/
-- 
1.8.0.3

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

Re: [U-Boot] [U-boot] mkimage -F parameter

[TigerLiu]

Dear Denk:
Here is the web page that describing -F / -K parameter for mkimage:
http://patchwork.ozlabs.org/patch/209634/
http://patchwork.ozlabs.org/patch/209610/

so, will these patches be merged into mainline code?

Best wishes,

-邮件原件-
发件人: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] 代表 
Wolfgang Denk
发送时间: 2013年1月31日 21:55
收件人: Tiger Liu
抄送: u-boot@lists.denx.de
主题: Re: [U-Boot] [U-boot] mkimage -F parameter

Dear tiger...@viatech.com.cn,

In message  you 
wrote:
>
> It seems mkimage has supported signing a image.

Does it?

The mainline code does not know any '-F' option...

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
"We don't care.  We don't have to.  We're the Phone Company."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] call env print from uboot environment

[Rommel Custodio]

Dear Wolfgang,

Wolfgang Denk  denx.de> writes:

> 
> Dear Rommel Custodio,
> 
:
:
> 
> You should actually read what I wrote before trying to correct me.
Apologies kind sir. 

All the best,
Rommel


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