[U-Boot] [PATCH 2/3] fdt: add fdt_del_node_by_path() API

For removing node easily by path or alias. Signed-off-by: Li Yang --- common/fdt_support.c | 10 ++ include/fdt_support.h |1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index f89a3ee..8f1186e 100644 --- a/common/fd

[U-Boot] [PATCH 3/3] fsl_law: add SRIO2 target id and law_size_bits() macro

Signed-off-by: Li Yang --- include/asm-ppc/fsl_law.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/asm-ppc/fsl_law.h b/include/asm-ppc/fsl_law.h index 31bb754..34c56a2 100644 --- a/include/asm-ppc/fsl_law.h +++ b/include/asm-ppc/fsl_law.h @@ -46,6 +46,8 @@ enu

[U-Boot] [PATCH 1/3] Update Makefile for new dirs to be included in tag list

Signed-off-by: Li Yang --- Makefile |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index bcb3fe9..4d71366 100644 --- a/Makefile +++ b/Makefile @@ -406,6 +406,8 @@ TAG_SUBDIRS += include TAG_SUBDIRS += lib_generic board/$(BOARDDIR) TAG_SUBDIRS += c

Re: [U-Boot] NAND read error on Sequoia

Hi Wolfgang, [Added Scott to Cc] On Tuesday 08 December 2009 23:03:28 Wolfgang Denk wrote: > it seems there is a problem with NAND on Sequoia: > > U-Boot 2009.11-rc2 (Dec 08 2009 - 22:52:34) > ... > NAND: 32 MiB > ... > => nand read 20 0 200 > > NAND

[U-Boot] (no subject)

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

Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet

Hi Ben: Ben Warren wrote: > Please don't top post. > While I agree that the network code should handle this properly, how do > you end up with odd-length packets? U-boot's been around for years and > nobody else has had this problem... I simply ping it with odd length. I also checked the lates

Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet

Hi Greg, Greg Ren wrote: > I must have missed it. The only suggestion that I remember was referring > to how to generate patch using git email. As for technical discussion, > it was ended as "not endianess clean". > > Please don't top post. While I agree that the network code should handle this

Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet

I must have missed it. The only suggestion that I remember was referring to how to generate patch using git email. As for technical discussion, it was ended as "not endianess clean". Greg Ren -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Tuesday,

Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet

> > Ah. I just realize that the endianess can be supported as simple as: > > In stead of this: >xsum += (*p & 0xff00); > Use this: >xsum += (*p & ntohs(0xff00)); Did you look at the suggestion I sent you? I know it works because I use in ospf. Jocke _

Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet

Ah. I just realize that the endianess can be supported as simple as: In stead of this: xsum += (*p & 0xff00); Use this: xsum += (*p & ntohs(0xff00)); Greg Ren -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 03, 2009 3:3

[U-Boot] early delay from C (before stack setup)

hi, i'm writing low-level setup code in C that is executed before the stack is initialized. this code needs to delay execution at several points. it seems to me that the use of udelay() is out of question cause there is no stack to pass the parameter, besides the timer subsystem udelay() depends

Re: [U-Boot] [PATCH RFC] NAND: Improve read performance from Large Page NAND devices

Dear Nick Thompson, In message <4b1e71d9.6080...@ge.com> you wrote: > Improve read performance from Large Page NAND devices. > > This patch produces a ~31% improvement in oob_first read speed (on a > 300MHz ARM9). The time for a mid-buffer 2k page read is now 293us, > 6.99MB/s (was 385us, 5.31MB/

[U-Boot] NAND read error on Sequoia

Hi Stefan, it seems there is a problem with NAND on Sequoia: U-Boot 2009.11-rc2 (Dec 08 2009 - 22:52:34) ... NAND: 32 MiB ... => nand read 20 0 200 NAND read: device 0 whole chip Attempt to read outside the flash area 3355

Re: [U-Boot] [PATCH] move prototype for gunzip() to common.h

Dear Wolfgang Wegner, In message <1260292862-30403-1-git-send-email-w.weg...@astro-kom.de> you wrote: > Prototype for gunzip was only in lib_generic/gunzip.c and thus repeated > in every file using it. This patch moves the prototype to common.h and > removes all prototypes distributed anywhere els

[U-Boot] [PATCH] mpc83xx: boot time regression, move LCRR setup back to cpu_init_f

Commit c7190f02 (retain POR values of non-configured ACR, SPCR, SCCR, and LCRR bitfields) moved the LCRR assignment to after relocation to RAM because of the potential problem with changing the local bus clock while executing from flash. This change unfortunately adversely affects the boot time, a

Re: [U-Boot] [PATCH] Remove superfluous uses of V_PROMPT macro.

Dear "Robert P. J. Day", In message you wrote: > > A number of config files define the V_PROMPT macro for the > command-line prompt, only to immediately use that macro to define > CONFIG_SYS_PROMPT, making V_PROMPT entirely superfluous. > > Signed-off-by: Robert P. J. Day > > --- > > i think

Re: [U-Boot] copy to flash: Flash not Erased

Dear Howard Wang, In message <1f9c78fa-be25-4bdf-8a02-3b2ebb48b...@dsirf.com> you wrote: > Hi, > > I have some problems with using u-boot writing to flash: ( arm 920 > processor ) > > first I use tftp to download the kernel to memory and was successful: > > >tftp 0x80 mImage > > OK >

Re: [U-Boot] [PATCH][RFC][for next] common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL

Dear Heiko Schocher, In message <4b179121.40...@denx.de> you wrote: > There is more and more usage of printing 64bit values, > so enable this feature generally, and delete the > CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL > defines. > > Signed-off-by: Heiko Schocher > --- > based agai

Re: [U-Boot] [PATCH][RFC][for next] 5xxx, fdt: move fdt_fixup_memory() to cpu.c file

Dear Heiko Schocher, In message <4b1790d6.6030...@denx.de> you wrote: > u-boot updates, before starting Linux, the memory node in the > DTS. As this is a "standard" feature, move this functionality > to the cpu.c file for mpc5xxx and mpc512x processors. > > Signed-off-by: Heiko Schocher > --- >

Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards

hi wolfgang, El Tue, Dec 08, 2009 at 09:33:18PM +0100 Wolfgang Denk ha dit: > In message <20091208151358.gd31...@darwin> you wrote: > > > > i am starting to look at this issue and it seems i need some more guidance: > > > > before relocating U-Boot to RAM for ARM920T processors a jump to the >

Re: [U-Boot] [PATCH][RFC][for next] 5xxx, fdt: move fdt_fixup_memory() to cpu.c file

Dear Heiko Schocher, In message <4b1df9b6.3040...@denx.de> you wrote: > > > May I suggest to add the same error checking in these two files, then? > > Hmm.. fdt_fixup_memory() does this error checking (Also in a much > stricter way, than in the board code). So I think, this is not > necessary he

Re: [U-Boot] [PATCH] move prototype for gunzip() to common.h

Dear Wolfgang Wegner, In message <20091208172555.gf16...@leila.ping.de> you wrote: > > sorry I did not know where to put additional comments... Comments go below the "---" line, i. e.: ... Singed-off-by: Wolfgang Wegner --- ===>> Add comments here. board/bf527

Re: [U-Boot] Pull request - microblaze - fixes

Dear Michal Simek, In message <4b1e0ed8.1040...@monstr.eu> you wrote: > Hi Wolfgang, > > Currently is merge window closed and it is RC2 but I think that will be > good to add these two minor changes to mainline repo. > First patch fix stack and malloc region overlap and the second remove > comp

Re: [U-Boot] [PATCH] Fix debug output.

Dear Thomas Weber, In message <4b1eb952.1070...@gmx.li> you wrote: > > should I resend the better formatted patch with a proper subject line > and a more detailed comment? How to name the patch? [Patch V2] ? 2 x yes, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH,

Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards

Dear "kevin.morf...@fearnside-systems.co.uk", In message <4b1e76e9.2050...@fearnside-systems.co.uk> you wrote: > > I would've thought that you need a working stack before you can run > 'C' code so you'd need the RAM timing set up before you could run In general this is correct, but then - what

Re: [U-Boot] [PATCH] Fix debug output.

Wolfgang Denk schrieb: > Dear Thomas Weber, > > In message <4b1cfef3.7080...@corscience.de> you wrote: > >>> Which problem is this supposed to fix? >>> > ... > >> In commit 60f61e6d7655400bb785a2ef637581679941f6d1 the following calls >> where changed. >> >> - DM9000_DMP_PACKET("

Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards

Dear Matthias Kaehlcke, In message <20091208151358.gd31...@darwin> you wrote: > > i am starting to look at this issue and it seems i need some more guidance: > > before relocating U-Boot to RAM for ARM920T processors a jump to the > label *lowlevel_init* is performed, where RAM timings are suppo

Re: [U-Boot] [PATCH] move prototype for gunzip() to common.h

Hi, sorry I did not know where to put additional comments... I tested this patch for compile-cleanness with a powerpc toolchain (CodeSourcery freescale-4.4-78-powerpc-linux-gnu-i686-pc-linux-gnu.tar.bz2 to be exact). The warnings and errors were not significantly different with and without this p

[U-Boot] [PATCH] move prototype for gunzip() to common.h

Prototype for gunzip was only in lib_generic/gunzip.c and thus repeated in every file using it. This patch moves the prototype to common.h and removes all prototypes distributed anywhere else. Singed-off-by: Wolfgang Wegner --- board/bf527-ezkit/video.c |2 -- board/bf533-st

Re: [U-Boot] [PATCH] Stop stack clobbering in microblaze-generic.

Graeme Smecher wrote: > Hi Michal, > > Michal Simek wrote: >> Hi Graeme, >> >> Graeme Smecher wrote: >> >>> From: Graeme Smecher >>> >>> A typo caused the stack and malloc regions to overlap, which prevented >>> mem_malloc_init() from returning. This commit makes the memory layout >>> match >>

Re: [U-Boot] [PATCH] Stop stack clobbering in microblaze-generic.

Hi Michal, Michal Simek wrote: > Hi Graeme, > > Graeme Smecher wrote: > >> From: Graeme Smecher >> >> A typo caused the stack and malloc regions to overlap, which prevented >> mem_malloc_init() from returning. This commit makes the memory layout match >> the example described in include/config

Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards

Matthias Kaehlcke wrote: > Hello Wolfgang, > > El Tue, Dec 08, 2009 at 12:51:47AM +0100 Wolfgang Denk ha dit: > U-Boot uses assembler only when ther eis no reasonable way to implement the code in C, and I don't see any such justification here. Please rewrite all this in C. >>> i'

[U-Boot] [PATCH RFC] NAND: Improve read performance from Large Page NAND devices

Improve read performance from Large Page NAND devices. This patch produces a ~31% improvement in oob_first read speed (on a 300MHz ARM9). The time for a mid-buffer 2k page read is now 293us, 6.99MB/s (was 385us, 5.31MB/s). oob_first is probably the best case improvement. Signed-off-by: Nick Thomp

Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards

Hello Wolfgang, El Tue, Dec 08, 2009 at 12:51:47AM +0100 Wolfgang Denk ha dit: > > > U-Boot uses assembler only when ther eis no reasonable way to > > > implement the code in C, and I don't see any such justification here. > > > Please rewrite all this in C. > > > > i'm just starting to get my f

Re: [U-Boot] How to burn file to sbc8548?

Dear wolfking, In message you wrote: > > 1. Can I use the ICE SX emulator to burn the bin file? I have no idea. > 2. If I can't use ICE SX to burn file, What tool or > method can be used to burn the file? I highly recommend the BDI3000 by Abatron. Best regards, Wolfgang Denk -- D

Re: [U-Boot] is CONFIG_DATAFLASH_MMC_SELECT actually being used anywhere?

On Mon, 7 Dec 2009, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > never afraid to embarrass myself, is the config option > > CONFIG_DATAFLASH_MMC_SELECT actually doing anything useful? > > Not in any mainline code, it seems. i didn't think so, just wanted

[U-Boot] [PATCH] microblaze: Correct ffs regression for Microblaze

From: Michal Simek We are using generic implementation of ffs. This should be part of Simon's commit 0413cfecea35eab5e591a0965c3e3ee0ff00 Here is warning message which this patch removes. In file included from /tmp/u-boot-microblaze/include/common.h:38, from cmd_mtdparts.c:

Re: [U-Boot] difference between V_PROMPT and CONFIG_SYS_PROMPT?

On Mon, 7 Dec 2009, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you wrote: > > > > another beginner-level question, i'm sure, but what's the > > distinction between V_PROMPT and CONFIG_SYS_PROMPT for customizing > > the u-boot prompt? > > The difference is that CONFIG_SYS_PRO

[U-Boot] Pull request - microblaze - fixes

Hi Wolfgang, Currently is merge window closed and it is RC2 but I think that will be good to add these two minor changes to mainline repo. First patch fix stack and malloc region overlap and the second remove compilation warning. (I sent this patch to mailing list some minutes ago). Can you ple

Re: [U-Boot] [PATCH] Stop stack clobbering in microblaze-generic.

Hi Graeme, Graeme Smecher wrote: > From: Graeme Smecher > > A typo caused the stack and malloc regions to overlap, which prevented > mem_malloc_init() from returning. This commit makes the memory layout match > the example described in include/configs/microblaze-generic.h I added your Sign-off-

[U-Boot] [PATCH] mpc83xx: vme8349: Fix power up reset sequence for tsi148

From: Reinhard Arlt Remove PCI reset, if there is a monarch PMC module. Signed-off-by: Reinhard Arlt Signed-off-by: Stefan Roese --- board/esd/vme8349/pci.c| 35 +++ board/esd/vme8349/vme8349pin.h | 36 2 files c

[U-Boot] [PATCH] mpc83xx: Add support for MPC8349 esd caddy2

From: Reinhard Arlt The caddy2 is a variant of the already supported vme8349. So we just add the differences to this board port. To better support those two boards we switched from fixed SDRAM configuration to usage of spd_sdram(). This is done by providing a board specific SPD EEPROM routine wit

[U-Boot] [PATCH v2] mpc83xx: spd_sdram.c: Disable memory controller before initializing

The memory controller could already be enabled, when spd_sdram() is called. This could be the case for example, when the SDRAM is initialized by the JTAG debugger. The "sync" after the register access via the accessor function is still needed, because the macro uses the sync before the real write