Re: [U-Boot] [IXP42x PATCH series v5 06/17] support CONFIG_SYS_LDSCRIPT on ARM

Am 05/23/2011 02:42 AM, schrieb Marek Vasut: > On Monday, May 23, 2011 12:00:02 AM Michael Schwingen wrote: >> Signed-off-by: Michael Schwingen >> --- > Honestly, I don't really understand this one ... Wolfgang, is this one OK to > merge ? The idea was to be able to define the LD_SCRIPT variable

[U-Boot] Pull request: u-boot-arm

Hi Wolfgang, The following changes since commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3: .gitignore: update list of u-boot.* files and add *.bin (2011-05-22 23:46:26 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master David Müller (ELSOFT AG) (1): V

Re: [U-Boot] AT91: CFI support broken

Hi Jens, On Friday 20 May 2011 15:01:21 Jens Scharsig wrote: > >> u-boot/drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer' > >> > >> I think this patch should be revert, as long as other modules need the > >> reset_timer function. > >> > >> Can anybody confirm this > > > > I thi

Re: [U-Boot] AT91: CFI support broken

On Monday, May 23, 2011, Stefan Roese wrote: > Hi Jens, > > On Friday 20 May 2011 15:01:21 Jens Scharsig wrote: >> >> u-boot/drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer' >> >> >> >> I think this patch should be revert, as long as other modules need the >> >> reset_timer functi

Re: [U-Boot] [STATUS] v2011.06-rc1 released

Dear Albert ARIBAUD, On 23 May 2011 15:50, Albert ARIBAUD wrote: >> 3. a pull request for >> >> http://git.denx.de/u-boot-samsung.git >> >> to fix >> >> s5p_mmc.c: In function 's5p_mmc_initialize': >> s5p_mmc.c:469: error: 'struct mmc' has no member named 'm_bmax' >> >> by >> >> >> http://git.den

[U-Boot] [PATCH] common/cmd_fdt.c: fix wrong data displayed in fdt print

From: Haojian Zhuang All data in dtb is big endian. Some ARM devices are little-endian. In print_data(), it displays data with big-endian format. For ARM device, data should be converted to little-endian first. Signed-off-by: Haojian Zhuang Cc: Gerald Van Baren --- common/cmd_fdt.c |2 +-

[U-Boot] [PATCH] powerpc/85xx: Add NAND boot support for P3041/P5020DS

When booting from NAND we get the environment from NAND. Signed-off-by: Shaohui Xie Signed-off-by: Kumar Gala --- boards.cfg |2 ++ include/configs/corenet_ds.h | 29 +++-- 2 files changed, 25 insertions(+), 6 deletions(-) diff --git a/boards.cfg

[U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

In some cases (e.g. bootm with a elf payload which is already at the right position) there is a in place copy of data to the same address. Catching this saves some ms while booting. Signed-off-by: Matthias Weisser --- Changes since V1: - Made subject more informative - Removed the optimizatio

[U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

In some cases (e.g. bootm with a elf payload which is already at the right position) there is a in place copy of data to the same address. Catching this saves some ms while booting. Signed-off-by: Matthias Weisser --- arch/arm/lib/memcpy.S |3 +++ 1 files changed, 3 insertions(+), 0 deletion

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

Am 23.05.2011 11:06, schrieb Matthias Weisser: > In some cases (e.g. bootm with a elf payload which is already at the right > position) there is a in place copy of data to the same address. Catching this > saves some ms while booting. > > Signed-off-by: Matthias Weisser > --- > arch/arm/lib/memcp

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

Am 23.05.2011 11:30, schrieb Alexander Holler: > Am 23.05.2011 11:06, schrieb Matthias Weisser: >> In some cases (e.g. bootm with a elf payload which is already at the right >> position) there is a in place copy of data to the same address. Catching this >> saves some ms while booting. >> >> Signed

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

Le 23/05/2011 11:30, Alexander Holler a écrit : > Am 23.05.2011 11:06, schrieb Matthias Weisser: >> In some cases (e.g. bootm with a elf payload which is already at the right >> position) there is a in place copy of data to the same address. Catching this >> saves some ms while booting. >> >> Signe

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

Am 23.05.2011 11:46, schrieb Matthias Weißer: >> The standard clearly say to both memory regions should not overlap when >> memcpy() is used, so I would say this is the wrong place to fix that. > > Well, real world applications do this. And these two instructions > shouldn't hurt a lot. Real bugs

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

Hello, Am 23.05.2011 11:49, schrieb Albert ARIBAUD: >> The standard clearly say to both memory regions should not overlap when >> memcpy() is used, so I would say this is the wrong place to fix that. > > I think the intent here is not to enforce the standard but to handle an > actual, and degener

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 23/05/11 16:29, Albert ARIBAUD wrote: > Hi all, > > Sorry, could not follow the discussion although I find it very > interesting, so I will handle the task of coming in late and asking the > silly questions. > > Le 23/05/2011 07:25, Graeme Russ a écrit : > >> On Mon, May 23, 2011 at 3:02 PM

[U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

There is no need to use get_timer() and reset_timer() and there are build breakages occuring because of them (specifically cfi_flash). Remove any usage outside arch/ to fix build breakages and to prepare for complete removal Signed-off-by: Graeme Russ --- checkpatch complains about long lines and

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, sorry for jumping in late here (was busy with the ELDK 5.0 release). In message you wrote: > OK, so in summary, we can (in theory) have: > - A timer API in /lib/ with a single u32 get_timer(u32 base) function > - A HAL with two functions >- u32 get_raw_ticks() What des t

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear "J. William Campbell", In message <4dd8b3ed.4000...@comcast.net> you wrote: > ... >This statement, as written, is false. While it is true that the > power PC (and others) have a 64 bit counter that runs at a many > megahertz rate, it is NOT true that all 64 bits must be used to obta

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Hi Graeme, Graeme Russ wrote: > There is no need to use get_timer() and reset_timer() and there are build I must have missed something WRT reset_timer() -- my apologies if I'm covering old ground. When the timestamp is incremented using an interrupt that occurs with a period greater than 1 ms, w

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 23/05/11 22:09, Wolfgang Denk wrote: > Dear Graeme Russ, > > sorry for jumping in late here (was busy with the ELDK 5.0 release). I thought you were a bit quite on such a 'touchy' subject ;) > > In message you wrote: >> OK, so in summary, we can (in theory) have: >> - A timer API in /lib/

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Am 2011-05-23 13:54, schrieb Graeme Russ: > There is no need to use get_timer() and reset_timer() and there are build > breakages occuring because of them (specifically cfi_flash). Remove any > usage outside arch/ to fix build breakages and to prepare for complete > removal > > Signed-off-by: Grae

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 23/05/11 22:19, Scott McNutt wrote: > Hi Graeme, > > Graeme Russ wrote: >> There is no need to use get_timer() and reset_timer() and there are build > > I must have missed something WRT reset_timer() -- my apologies > if I'm covering old ground. > > When the timestamp is incremented using an

[U-Boot] [PATCH v3] powerpc/85xx: Fix compile errors if CONFIG_SYS_DPAA_QBMAN isn't set

Add ifdef protection for qp_info and liodn associated with Q/BMan. Also rearrange setting of _tbl_sz variables to utilize existing ifdef protection for things like FMAN. Also add protection around setup_portals() call in corenet_ds board code. Signed-off-by: Kumar Gala --- v3: * Fixed typo of #

Re: [U-Boot] [PATCH] powerpc/85xx: Add NAND boot support for P3041/P5020DS

On May 23, 2011, at 2:40 AM, Shaohui Xie wrote: > > diff --git a/boards.cfg b/boards.cfg > index 9f2b118..21182b9 100644 > --- a/boards.cfg > +++ b/boards.cfg > @@ -574,12 +574,14 @@ P2020RDB_SPIFLASHpowerpc mpc85xx > p1_p2_rdb freesca > P3041DS

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Dear Graeme, Graeme Russ wrote: > On 23/05/11 22:19, Scott McNutt wrote: >> Hi Graeme, >> >> Graeme Russ wrote: >>> There is no need to use get_timer() and reset_timer() and there are build >> I must have missed something WRT reset_timer() -- my apologies >> if I'm covering old ground. >> >> When

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, In message <4dda5334.4060...@gmail.com> you wrote: > > >> - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks() > >>and get_tick_rate() to correctly maintain the ms counter used by > >>get_timer() - This function can be weak (so next point) > > > > Di

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Dear Jens Scharsig, In message <4dda53b7.7020...@bus-elektronik.de> you wrote: > Am 2011-05-23 13:54, schrieb Graeme Russ: > > There is no need to use get_timer() and reset_timer() and there are build > > breakages occuring because of them (specifically cfi_flash). Remove any > > usage outside arc

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Am 2011-05-23 13:54, schrieb Graeme Russ: > There is no need to use get_timer() and reset_timer() and there are build > breakages occuring because of them (specifically cfi_flash). Remove any > usage outside arch/ to fix build breakages and to prepare for complete > removal > > Signed-off-by: Grae

[U-Boot] Formal acks and patchwork (was: [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/)

Le 23/05/2011 15:22, Wolfgang Denk a écrit : > Can you please send a formal Acked-by: message? > > Note that this is NOT nitpicking: Patchwork will automatically add > such correct Acked-by: lines to the patch, so we don't have to track > thse manually - this saves a LOT of time to the maintainer

Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement

Hi Simon, [...] >>> I believe I have covered this ground very thoroughly and would like >>> advice please on what to do next. The options I can see are: >> >> As Graeme points out, you got enough positive feedback that I encourage >> you to continue and address the comments. > > OK, it would be n

[U-Boot] [PATCH v5 3/4] MX5: Introduce a function for setting the chip select size

Signed-off-by: Fabio Estevam --- Changes since v4: - No changes Changes since v3: - Print the chip size in the case of error arch/arm/cpu/armv7/mx5/soc.c | 30 + arch/arm/include/asm/arch-mx5/imx-regs.h |5 arch/arm/include/asm/arch-mx5/sys_pr

[U-Boot] [PATCH v5 1/4] MX5: Make the weim structure complete

Signed-off-by: Fabio Estevam --- Changes since v4: - Change the definition of WEIM single-bit field Changes since v3: - No changes Changes since v2: - Add CS1_BASE_ADDR for MX51 - Add WEIM Registers arch/arm/include/asm/arch-mx5/imx-regs.h | 131 -- 1 files changed, 1

[U-Boot] [PATCH v5 2/4] MX5: Add iomux structure

Signed-off-by: Fabio Estevam --- Changes since v4: - No changes Changes since v3: - No changes Changes since v2: - Distinguish iomuxc struct between MX51 and MX53 arch/arm/include/asm/arch-mx5/imx-regs.h | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --gi

[U-Boot] [PATCH v5 4/4] MX53: Add initial support for MX53ARD

Signed-off-by: Fabio Estevam --- Changes since v4: - Changed the weim cs1 settings for the single-bit fields - Removed unused 'reg' variable inside weim_smc911x_iomux() - Made void weim_cs1_settings() and weim_smc911x_iomux() static Changes since v3: - No changes Changes since v2: - Use macros for

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 5/22/2011 11:29 PM, Albert ARIBAUD wrote: Hi all, Sorry, could not follow the discussion although I find it very interesting, so I will handle the task of coming in late and asking the silly questions. I am glad you are looking at our discussion. I am sure we are going to need all the help/o

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 5/23/2011 6:19 AM, Wolfgang Denk wrote: Dear Graeme Russ, In message<4dda5334.4060...@gmail.com> you wrote: - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks() and get_tick_rate() to correctly maintain the ms counter used by get_timer() - This function can be

[U-Boot] [PATCH v2] ARMV7: Vexpress: Add missing MMC header

From: Dirk Behme Add a header file with the missing function prototype to fix ca9x4_ct_vxp.c: In function 'cpu_mmc_init': ca9x4_ct_vxp.c:93: warning: implicit declaration of function 'arm_pl180_mmci_init' introduced by commit "ARMV7: Vexpress: Add MMC support" (f0c64526b7e51ba997a0f1baf9e74e6d

Re: [U-Boot] [STATUS] v2011.06-rc1 released

On 23.05.2011 08:50, Albert ARIBAUD wrote: > Hi all, > > Le 21/05/2011 09:07, Dirk Behme a écrit : > >> I'd like >> >> 1. to get >> >> http://patchwork.ozlabs.org/patch/95661/ >> >> applied to fix >> >> ca9x4_ct_vxp.c: In function 'cpu_mmc_init': >> ca9x4_ct_vxp.c:93: warning: implicit declaration

Re: [U-Boot] [RFC] Review of U-Boot timer API

Le 23/05/2011 19:30, J. William Campbell a écrit : >> Did you have a look at the PowerPC implementation? I'd like to see >> this used as reference. > I have looked at it as a reference. However, there is one disadvantage > in using the PPC code as a reference. It has a 64 bit timestamp. Many > sy

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 5/23/2011 6:19 AM, Wolfgang Denk wrote: > Dear Graeme Russ, > This is what PPC is doing. And I understand that Reinhard did the same > in software for AT91. Hi All, My apologies for being a little (perhaps more than a little) dense. As they say, "after further review", I think the key as

[U-Boot] [PATCH 2/3] common/cmd_nand.c: add ifdef protection for do_bootm

Right now we do not check if do_bootm is actually built into this u-boot. Instead check define and only call do_bootm if it's actually available. Signed-off-by: Matthew McClintock --- common/cmd_nand.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/common/cmd_nand.c b/

[U-Boot] [PATCH 1/2] command/cmd_cache.c: Add optional flush arguments

It might be desirable to have the ability to flush icache/dcache within u-boot, this patch gives each arch the ability to provide a flush_dcache/flush_icache function to let u-boot flush caches from the prompt Signed-off-by: Matthew McClintock --- There are some checkpatch.pl warnings for formatt

[U-Boot] [PATCH 2/2] powerpc/85xx: provide 85xx flush_icache for cmd_cache

This provides a function that will override the weak function flush_icache to let 85xx boards to flush the icache cc: Kumar Gala Signed-off-by: Matthew McClintock --- arch/powerpc/cpu/mpc85xx/start.S |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/mpc8

[U-Boot] [PATCH 3/3] common/cmd_ximg.c: add ifdef protection for gzip uncompression

Print a message if we do not have the ability to uncompress a gzip image. Before, u-boot would just assume the routines were available Signed-off-by: Matthew McClintock --- common/cmd_ximg.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/common/cmd_ximg.c b/common/

Re: [U-Boot] Formal acks and patchwork (was: [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/)

Dear Albert ARIBAUD, In message <4dda69a1.1070...@aribaud.net> you wrote: > > > Note that this is NOT nitpicking: Patchwork will automatically add > > such correct Acked-by: lines to the patch, so we don't have to track > > thse manually - this saves a LOT of time to the maintainers. > > One qu

[U-Boot] [PATCH 1/3] disk/part.c: Make features optional

If we don't want to build support for any partition types we can now add #undef CONFIG_PARTITIONS in a board config file to keep this from being compiled in. Otherwise boards assume this is compiled in by default Signed-off-by: Matthew McClintock --- common/cmd_mmc.c |2 ++ disk/Mak

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear "J. William Campbell", In message <4dda99bc.80...@comcast.net> you wrote: > > >> The library function acts as a pre-scaler using a 'raw tick counter' and a > >> 'raw tick rate' supplied by the low level architecture. We define this weak > > What are "raw" ticks? And what are "cooked" ticks,

Re: [U-Boot] Formal acks and patchwork

Le 23/05/2011 20:44, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4dda69a1.1070...@aribaud.net> you wrote: >> >>> Note that this is NOT nitpicking: Patchwork will automatically add >>> such correct Acked-by: lines to the patch, so we don't have to track >>> thse manually - this s

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear "J. William Campbell", In message <4ddaa705.1040...@comcast.net> you wrote: > > My apologies for being a little (perhaps more than a little) > dense. As they say, "after further review", I think the key aspect of > the PPC timer system is that it uses the decrementer register to > ge

Re: [U-Boot] Formal acks and patchwork

Dear Albert ARIBAUD, In message <4ddab341.20...@aribaud.net> you wrote: > > > For example, instead of applying a patch directly from my mailbox I > > use this file only to get the hash value for the PW entry, and then > > use pwclient to apply it and to update it's state: > > > > HASH=$(p

Re: [U-Boot] bank8 in OMAP-L138 ?

On Sun, May 22, 2011 at 9:55 PM, Ran Shalit wrote: > Hello, > > It seems that bank 8 is missing in > [u-boot.git] / > arch / > arm

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 24/05/11 00:00, Andrew Dyer wrote: > On Mon, May 23, 2011 at 06:54, Graeme Russ wrote: >> There is no need to use get_timer() and reset_timer() and there are build > > shouldn't the above say set_timer() instead of get_timer()? > Yes, thanks Regards, Graeme

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 24/05/11 04:29, Scott McNutt wrote: > Hi Bill, > > J. William Campbell wrote: >> On 5/23/2011 6:12 AM, Scott McNutt wrote: >>> Dear Graeme, >>> >>> Graeme Russ wrote: On 23/05/11 22:19, Scott McNutt wrote: > Hi Graeme, > > Graeme Russ wrote: >> There is no need to use get_t

Re: [U-Boot] Formal acks and patchwork

Le 23/05/2011 21:42, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4ddab341.20...@aribaud.net> you wrote: >> >>> For example, instead of applying a patch directly from my mailbox I >>> use this file only to get the hash value for the PW entry, and then >>> use pwclient to apply it

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 5/23/2011 12:33 PM, Wolfgang Denk wrote: Dear "J. William Campbell", In message<4ddaa705.1040...@comcast.net> you wrote: My apologies for being a little (perhaps more than a little) dense. As they say, "after further review", I think the key aspect of the PPC timer system is that it

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 23/05/11 23:19, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4dda5334.4060...@gmail.com> you wrote: >> - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks() and get_tick_rate() to correctly maintain the ms counter used by get_timer() - This f

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 5/23/2011 1:10 PM, Graeme Russ wrote: > On 24/05/11 04:29, Scott McNutt wrote: >> Hi Bill, >> >> J. William Campbell wrote: >>> On 5/23/2011 6:12 AM, Scott McNutt wrote: Dear Graeme, Graeme Russ wrote: > On 23/05/11 22:19, Scott McNutt wrote: >> Hi Graeme, >> >> Gr

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 24/05/11 06:49, J. William Campbell wrote: > On 5/23/2011 1:10 PM, Graeme Russ wrote: >> On 24/05/11 04:29, Scott McNutt wrote: >>> Hi Bill, >>> >>> J. William Campbell wrote: On 5/23/2011 6:12 AM, Scott McNutt wrote: > Dear Graeme, > > Graeme Russ wrote: >> On 23/05/11 22:1

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

Hello, Am 23.05.2011 11:03, schrieb Matthias Weisser: > In some cases (e.g. bootm with a elf payload which is already at the right > position) there is a in place copy of data to the same address. Catching this > saves some ms while booting. > > Signed-off-by: Matthias Weisser > --- > Changes sinc

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On 5/23/2011 2:02 PM, Graeme Russ wrote: > On 24/05/11 06:49, J. William Campbell wrote: >> On 5/23/2011 1:10 PM, Graeme Russ wrote: >>> On 24/05/11 04:29, Scott McNutt wrote: Hi Bill, J. William Campbell wrote: > On 5/23/2011 6:12 AM, Scott McNutt wrote: >> Dear Graeme,

Re: [U-Boot] [PATCH 1/3] disk/part.c: Make features optional

On May 23, 2011, at 1:29 PM, Matthew McClintock wrote: > If we don't want to build support for any partition types we can now > add #undef CONFIG_PARTITIONS in a board config file to keep this from > being compiled in. Otherwise boards assume this is compiled in by > default > > Signed-off-by: M

[U-Boot] [PATCH v2 1/3] disk/part.c: Make features optional

If we don't want to build support for any partition types we can now add #undef CONFIG_PARTITIONS in a board config file to keep this from being compiled in. Otherwise boards assume this is compiled in by default Signed-off-by: Matthew McClintock --- v2: Fix patch to apply to current tree Note:

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear "J. William Campbell", In message <4ddac2f5.7060...@comcast.net> you wrote: > > Does that sound right? I think so. > --000308010205050804040502 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit Could you please stop posting HTML? Thanks. Best re

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Dear "J. William Campbell", In message <4ddac866.1050...@comcast.net> you wrote: > > > Is there any reason why we cannot silently perform a reset_timer() any time > > set_timer() is called with a parameter of 0? > Hi All, > I assume you mean get_timer(0)? In principle, you cannot do this >

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

Dear Alexander Holler, In message <4ddacc8b.6090...@ahsoftware.de> you wrote: > > > --- a/lib/string.c > > +++ b/lib/string.c > > @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count) > > unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src; > > cha

[U-Boot] China Daily (European edition, weekly, in English) advertising now open for the first time

Hi there We know how busy you are, so just a quick note, if we may, to let you know about China Daily European Edition, advertising in which is now available for the first time ever! As you might see, it's a brand new and exciting opportunity, especially if your organisation is intending to ex

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

Am 23.05.2011 23:55, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4ddacc8b.6090...@ahsoftware.de> you wrote: >> >>> --- a/lib/string.c >>> +++ b/lib/string.c >>> @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count) >>> unsigned long *dl = (unsigned lon

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

Dear Alexander Holler, In message <4ddadbb6.30...@ahsoftware.de> you wrote: > > So you I will look forward to checks for NULL pointers and similiar in > all C standard functions implemented in u-boot to circumvent tons of > possible real world bugs in all callers of strcpy, strlen, mem* and > w

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

Am 24.05.2011 00:22, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4ddadbb6.30...@ahsoftware.de> you wrote: >> >> So you I will look forward to checks for NULL pointers and similiar in >> all C standard functions implemented in u-boot to circumvent tons of >> possible real world b

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

Hi Wolfgang, On Tue, May 24, 2011 at 7:53 AM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message <4ddac866.1050...@comcast.net> you wrote: >> >> > Is there any reason why we cannot silently perform a reset_timer() any time >> > set_timer() is called with a parameter of 0? >> Hi All

Re: [U-Boot] SPI flash and release

On Saturday, May 21, 2011 07:25:01 Simon Guinot wrote: > Do you plan to push your 'sf' branch into the current release ? i mentioned in one of the threads that i was going to push it after the 2011.06 release. the branch/changes were done after the 2011.06 merge window closed, so i wasnt comfor

Re: [U-Boot] [PATCH] [FIX] cmd_nand: fix help of nand erase subcommand

there's no need to specify "[FIX]" in the summary -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] command/cmd_cache.c: Add optional flush arguments

On Monday, May 23, 2011 14:38:52 Matthew McClintock wrote: > There are some checkpatch.pl warnings for formatting issues. In this case > I choose to keep the same formatting as was used in the file already: this is fine i think. otherwise, you'd send another patch to first fix the formatting and

Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement

On Monday, May 23, 2011 11:22:18 Detlev Zundel wrote: > >>> I believe I have covered this ground very thoroughly and would like > >> > >>> advice please on what to do next. The options I can see are: > >> As Graeme points out, you got enough positive feedback that I encourage > >> you to continue

Re: [U-Boot] [PATCH v2] .gitignore: update list of u-boot.* files and add *.bin

On Sunday, May 22, 2011 17:46:36 Wolfgang Denk wrote: > Eric Cooper wrote: > > This patch adds additional u-boot.* files mentioned in Makefile, > > and adds *.bin since these are deleted as part of "make clean". > > > > Signed-off-by: Eric Cooper > > --- > > Changes since v1: > > > > Added more

[U-Boot] [PATCH][v2] powerpc/85xx: Add NAND boot support for P3041/P5020DS

When booting from NAND we get the environment from NAND. Signed-off-by: Shaohui Xie Signed-off-by: Kumar Gala --- changes for v2: move _NAND up to sorted by alpha. boards.cfg |2 ++ include/configs/corenet_ds.h | 29 +++-- 2 files changed, 25 ins

Re: [U-Boot] [PATCH v2 1/3] disk/part.c: Make features optional

On Monday, May 23, 2011 17:49:42 Matthew McClintock wrote: > --- a/common/cmd_mmc.c > +++ b/common/cmd_mmc.c > @@ -180,7 +180,9 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, > char * const argv[]) mmc_dev = mmc_get_dev(curr_device); > if (mmc_dev != NULL && >

Re: [U-Boot] [PATCH 3/3] common/cmd_ximg.c: add ifdef protection for gzip uncompression

On Monday, May 23, 2011 14:29:13 Matthew McClintock wrote: > --- a/common/cmd_ximg.c > +++ b/common/cmd_ximg.c > break; > case IH_COMP_GZIP: > +#ifdef CONFIG_GZIP > printf (" Uncompressing part %d ... ", part); > if (

Re: [U-Boot] [PATCH 2/3] common/cmd_nand.c: add ifdef protection for do_bootm

On Monday, May 23, 2011 14:29:12 Matthew McClintock wrote: > Right now we do not check if do_bootm is actually built into this > u-boot. Instead check define and only call do_bootm if it's actually > available. basic idea is sound ... > --- a/common/cmd_nand.c > +++ b/common/cmd_nand.c > @@ -806,

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On Monday, May 23, 2011 18:44:33 Graeme Russ wrote: > I think this might break stand alone applications - I am sure get_timer() > is exported. the export list has a rev associated with it. see XF_VERSION in include/exports.h. u-boot will detect the mismatch at runtime and bail forcing people t

[U-Boot] [PATCH 2/7] Blackfin: use on-chip reset func with newer parts

Turns out the documentation is wrong and doing "RAISE 1" does not result in a software reset, only a core reset. So when the on-chip rom has a functioning reset helper, use it. Signed-off-by: Mike Frysinger --- arch/blackfin/cpu/reset.c | 70 ++--- 1 fi

[U-Boot] [PATCH 1/7] Blackfin: use common LDSCRIPT logic

Now that common code is a bit smarter when it comes to default LDSCRIPT values, rename the default Blackfin file and drop the Blackfin-specific config.mk logic. Signed-off-by: Mike Frysinger --- arch/blackfin/config.mk|4 arch/blackfin/{lib/u-boot.lds.S => cp

[U-Boot] [PATCH 6/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support

From: Harald Krapfenbauer These boards have an mmc/sd slot on them connected over SPI, so enable the driver. Signed-off-by: Harald Krapfenbauer Signed-off-by: Mike Frysinger --- include/configs/cm-bf537e.h | 17 - include/configs/cm-bf537u.h | 16 +++- include/

[U-Boot] [PATCH 5/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings

From: Harald Krapfenbauer These boards can have an addon card plugged onto them, so enable support for it. Signed-off-by: Harald Krapfenbauer Signed-off-by: Mike Frysinger --- board/cm-bf537e/cm-bf537e.c | 34 ++ board/cm-bf537u/cm-bf537u.c | 39 +++

[U-Boot] [PATCH 0/7] Blackfin fixes for 2011.06

Mostly a few simple fixes noticed after the 2011.06 merge window, or due to patches merged in that period. Harald Krapfenbauer (3): Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support Blackfin: cm-bf537e/cm-bf537u/t

[U-Boot] [PATCH 4/7] Blackfin: boards: build zlib dir with -O2

Now that the zlib code has been relocated to a dedicated subdir, make sure we still build it with -O2 for boards that want speed over size. Signed-off-by: Mike Frysinger --- board/bct-brettl2/config.mk |1 + board/bf518f-ezbrd/config.mk |1 + board/bf526-ezbrd/config.mk

[U-Boot] [PATCH 3/7] Blackfin: bf548-ezkit/bf561-ezkit: update env location

Relocate the env to one of the small end sectors to avoid issues with embedding it, such as support being broken (by recent commit ea882baf9c1), and for taking a while to save updates. Signed-off-by: Mike Frysinger --- include/configs/bf548-ezkit.h | 10 +- include/configs/bf561-ezkit.

[U-Boot] [PATCH 7/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings

From: Harald Krapfenbauer The recent commit ea882baf9c1 broke embedding environments in the middle of a sector, so relocate it to the start of the 2nd sector. Signed-off-by: Harald Krapfenbauer Signed-off-by: Mike Frysinger --- include/configs/cm-bf537e.h | 11 +-- include/configs/c

[U-Boot] Pull request u-boot-blackfin.git

The following changes since commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3: .gitignore: update list of u-boot.* files and add *.bin (2011-05-22 23:46:26 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Harald Krapfenbauer (3): Blackfin:

Re: [U-Boot] [RFC] Review of U-Boot timer API

On Saturday, May 21, 2011 08:38:29 Graeme Russ wrote: > NOTE: http://lists.denx.de/pipermail/u-boot/2010-June/073024.html appears > to imply the following implementation of get_timer() is wrong: > > ulong get_timer(ulong base) > { > return get_timer_masked() - base; >

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

On Monday, May 23, 2011 18:38:49 Alexander Holler wrote: > Am 24.05.2011 00:22, schrieb Wolfgang Denk: > > Alexander Holler wrote: > >> So you I will look forward to checks for NULL pointers and similiar in > >> all C standard functions implemented in u-boot to circumvent tons of > >> possible real

Re: [U-Boot] [RFC] Review of U-Boot timer API

Hi All, OK, here goes - A much more in-depth generic analysis for a timer API I hope this highlights why the current discussion thread has ended up where is has Regards, Graeme Definitions: 'register' - A storage element - Can be: - A dedicated CPU register - A location in memory (as de

[U-Boot] DSN: failed (Returned mail: Data format error)

This is a Delivery Status Notification (DSN). I was unable to deliver your message to aust...@msdirectservices.com. I said RCPT TO: And they gave me the error; 550 5.1.1 : Recipient address rejected: undeliverable address: host frontend.servicemail24.de[84.17.190.240] said: 550 aust...@m

Re: [U-Boot] [RFC] Review of U-Boot timer API

rather than inventing our own set of terms, how about piggybacking what Linux has already done ? they have "cycle counters" and "timer counters" (which bubble up into "clock sources", but i dont think we need those). further, Linux probably already has implementations we can steal for the arch-

Re: [U-Boot] [RFC] Review of U-Boot timer API

Mike, On Tue, May 24, 2011 at 2:24 PM, Mike Frysinger wrote: > rather than inventing our own set of terms, how about piggybacking what Linux > has already done ?  they have "cycle counters" and "timer counters" (which > bubble up into "clock sources", but i dont think we need those). I only put

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

On Tue, May 24, 2011 at 7:02 AM, Graeme Russ wrote: [snip] > > Well, we have no control over the argument in cfi driver (unless you plan > to put #ifdef NIOS all over the place) > > Maybe we could round up the parameter inside get_timer() itself? Wow, what was I on! - Oh, thats right, no coffee

Re: [U-Boot] [RFC] Review of U-Boot timer API

I know its futile to repeat what I suggested about 9 months ago... Since get_timer() is only used (to my knowledge) to break out of loops that do not terminate normally because an expected event does not occur, the following API would be simpler and take less time per loop: (I use the names A and

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Reinhard, On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer wrote: > I know its futile to repeat what I suggested about 9 months ago... > > Since get_timer() is only used (to my knowledge) to break out of > loops that do not terminate normally because an expected event does > not occur, the fo

Re: [U-Boot] [RFC] Review of U-Boot timer API

Le 24/05/2011 07:43, Graeme Russ a écrit : > Dear Reinhard, > > On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer > wrote: >> I know its futile to repeat what I suggested about 9 months ago... >> >> Since get_timer() is only used (to my knowledge) to break out of >> loops that do not terminate norm

[U-Boot] cannot jump to stage 2 -start_armboot routine

Hye all, Does any one facing this kind of problem. The hardware initilization is done, but somehow the code doesn't jump into the c code. Any setting involved? Thanks in advance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/

  1   2   >