The CFI driver does not reset the device's watchdog, so long-running
flash operations will cause the watchdog timer to expire. A comment in
flash_status_check() suggests that udelay() is expected to reset the
watchdog, but I can't find any architecture where it does.
Signed-off-by: Ingo van Lil
-
Hi Ingo,
On Friday 02 October 2009 12:34:17 Ingo van Lil wrote:
> The CFI driver does not reset the device's watchdog, so long-running
> flash operations will cause the watchdog timer to expire. A comment in
> flash_status_check() suggests that udelay() is expected to reset the
> watchdog, but I c
On Sunday 27 September 2009 23:56:12 Felix Radensky wrote:
> Reorganize DDR2 ECC handling to use common code for
> SPD DIMMs and soldered SDRAM. Also, use common code
> to display SDRAM info (ECC, CAS latency) for SPD and
> soldered SDRAM variants.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
On Tuesday 29 September 2009 08:39:28 Stefan Roese wrote:
> This patch merges the ECC handling (ECC parity byte writing) into one
> file (ecc.c) for all PPC4xx SDRAM controllers except for PPC440EPx/GRx.
> This exception is because only those PPC's use the completely different
> Denali SDRAM contro
On Wednesday 30 September 2009 11:55:04 Matthias Fuchs wrote:
> This patch adds support to detect the amount of DDR2 SDRAM
> on PMC440 modules. Detection is done by probing through
> a list of available and supported hardware configurations
> from 1GByte down to 256MB.
>
> The static TLB entry is
The following changes since commit 1d96cfe8f5eebfc6ea39d1a387f35ca4499e6b67:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Felix Radensky (1):
ppc4xx: Reorganiz
On 10/02/2009 01:06 PM, Stefan Roese wrote:
>> The CFI driver does not reset the device's watchdog, so long-running
>> flash operations will cause the watchdog timer to expire. A comment in
>> flash_status_check() suggests that udelay() is expected to reset the
>> watchdog, but I can't find any ar
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> This patch adds the initial support for DM6467 EVM.
> Other features like NET and NAND support will be added as follow up patches.
>
> Signed-off-by: Sandeep Paulraj
> ---
> There are multiple flavours of the DM646x. The newest DM646x SOC can
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> This patch fixes a compilation warning while compiling
> the DM355 EVM.
>
> Signed-off-by: Sandeep Paulraj
> ---
> board/davinci/dm355evm/dm355evm.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/davin
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> This patch fixes a compilation warning while compiling
> the DM365 EVM.
>
> Signed-off-by: Sandeep Paulraj
> ---
> board/davinci/dm365evm/dm365evm.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/davin
Dear Ingo van Lil,
In message <20091002103417.ga9...@zaphod.peppercon.de> you wrote:
> The CFI driver does not reset the device's watchdog, so long-running
> flash operations will cause the watchdog timer to expire. A comment in
> flash_status_check() suggests that udelay() is expected to reset th
This message is printed upon PCIe bus scan, not only upon error, but also
if no PCIe device is detected at all. Since this is not an error, let's
remove this message in this case. We already have the message
"link is not up." if there is no PCIe device present.
Signed-off-by: Stefan Roese
---
bo
Dear Stefan Roese,
In message <1254486916-3040-1-git-send-email...@denx.de> you wrote:
> This message is printed upon PCIe bus scan, not only upon error, but also
> if no PCIe device is detected at all. Since this is not an error, let's
> remove this message in this case. We already have the messa
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> The EMAC IP on DM365 and DM646x is slightly different from
> that on DM644x. This patch updates the DaVinci EMAC driver
> so that EMAC becomes operational on DM365 in U-Boot.
> A flag 'CONFIG_DAVINCI_EMAC_VERSION2' is used in the driver.
> This
Hi Wolfgang,
On Friday 02 October 2009 14:41:58 Wolfgang Denk wrote:
> But looking at this patch, it seems that larger parts in this
> (supposedly) board-specific code are actually more or less identical.
>
> Should we not factor out such common code?
Yes, this could (should) be done. But there
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> The flag "CONFIG_DAVINCI_EMAC_VERSION2" is used by
> the DaVinci EMAC driver to differentiate between
> different versions of the IP.
>
> Signed-off-by: Sandeep Paulraj
> ---
> include/configs/davinci_dm365evm.h |1 +
> 1 files changed, 1
> > Patches will also be sent to enable EMAC, NAND and other features.
> > Makefile|3 +
>
> Needs an addition to MAKEALL and optionally Maintainers
Ok I will add
> > diff --git a/include/configs/davinci_dm6467evm.h
> b/include/configs/davinci_dm6467evm.h
> > ne
Paulraj, Sandeep wrote:
>
>
>>> +
>>> +/* SoC Configuration */
>>> +#define CONFIG_ARM926EJS /* arm926ejs CPU */
>>> +#define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0
>>> */
>> Is there a logical register #define you could use instead of the
On Thu, 01 Oct 2009 20:27:11 +0200
Wolfgang Denk wrote:
> > > > > -PLATFORM_CPPFLAGS += -march=armv5te
> > > > > +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
>
> I have to admit that I really hesitate ifwe should add this - the
> longer I think about it, the more I tend to say no.
>
> I ca
Hi All,
I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a
Freescale mxc platform. Looks like the device code used in the NAND
"read id" operation is already a part of the
drivers/mtd/nand/nand_ids.c, looking at line "{"NAND 1GiB 3,3V 8-bit",
0xD3, 0, 1024, 0, LP_OPTIONS},)
Hi
2009/10/2 alfred steele :
> Hi All,
>
> I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a
> Freescale mxc platform. Looks like the device code used in the NAND
> "read id" operation is already a part of the
> drivers/mtd/nand/nand_ids.c, looking at line "{"NAND 1GiB 3,3V 8
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the
relevant HW configuration registers (address, symbolic name, content).
This allows to easily detect errors in *.h files and changes in the HW
configuration.
It is split in the following parts:
- Cleanup some HW register names:
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the
relevant HW configuration registers (address, symbolic name, content).
This allows to easily detect errors in *.h files and changes in the HW
configuration.
It is split in the following parts:
- Cleanup some HW register names:
Signed-off-by: Niklaus Giger
---
include/4xx_i2c.h |2 +-
include/ppc405.h |4 +-
include/ppc440.h | 179 ++--
include/ppc4xx_enet.h | 220 +
4 files changed, 216 insertions(+), 189 deletio
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the
relevant HW configuration registers (address, symbolic name, content).
This allows to easily detect errors in *.h files and changes in the HW
configuration.
Signed-off-by: Niklaus Giger
---
common/cmd_reginfo.c | 158 +--
On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote:
> Ingo van Lil wrote:
> > The CFI driver does not reset the device's watchdog, so long-running
> > flash operations will cause the watchdog timer to expire. A comment in
> > flash_status_check() suggests that udelay() is expected to reset the
Dear Mike Frysinger,
In message <200910021431.23079.vap...@gentoo.org> you wrote:
>
> Blackfin is missing it as well as i really had no idea it was supposed to be
> there. certainly no doc states this requirement. perhaps it'd make sense to
> break apart the common stuff to a common udelay() t
Signed-off-by: Peter Tyser
---
This should be squashed with the top-most commit in the
reloc branch.
Ideally we could fold
"[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups"
into the reloc branch too so we don't have to increment XF_VERSION
again in the next release. I have no
Mike Frysinger wrote:
> On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote:
>
>> Ingo van Lil wrote:
>>
>>> The CFI driver does not reset the device's watchdog, so long-running
>>> flash operations will cause the watchdog timer to expire. A comment in
>>> flash_status_check() suggests t
Hi,
We have a situation when we want to display an image towards the end of
Uboot's execution, before we boot Linux. I have that already.
However, my issue is that while Linux boots it mallocs a new frame buffer
and reinitializes the LCD controller with a new memory address. At the
moment in Uboo
Thanks Magnus!
> Which MXC platform are you using and does it support 4K page size? And
> does mxc_nand.c support 4K page size?
I am using mx35 and the NAND flash controller therein supports 4K page
operations as evident from the manual.
from the code in "mxc_nand.c" it looks like it checks for whe
Minkyu Kang wrote:
> Dear kevin Morfitt
>
> sorry for blank message
>
> 2009/9/30 Minkyu Kang :
>> Dear Kevin Morfitt
>>
>> 2009/9/26 kevin.morf...@fearnside-systems.co.uk
>> :
>>> Changes since v1:
>>> - re-formatted patch to remove line wrapping
>>>
>>> Note that patch 2/4 of this series has
I can fix this problem not but I really don't understand how the problem
happens in the first place. I found gp got changed in relocate_code in
file start.S.
In relocate_code "function", the $gp is adjusted to point to the new
location, but somehow before program jumps to the relocated place, $gp
Dear "J. William Campbell",
In message <4ac660e3.4010...@comcast.net> you wrote:
>
> At this point it might be appropriate to ask if including such a reset
> in udelay() is a good idea. The way it is, no "infinite loop" in u-boot
> that contains a udelay() will ever allow the watchdog to time ou
Dear Steven Zedeck,
In message <25722060.p...@talk.nabble.com> you wrote:
>
> We have a situation when we want to display an image towards the end of
> Uboot's execution, before we boot Linux. I have that already.
>
> However, my issue is that while Linux boots it mallocs a new frame buffer
> an
The basic memtest function tries to watch for ^C after each
pattern pass as an escape mechanism, but if things are horribly
wrong, we'll be stuck in an inner loop flooding the console with
error messages and never check for ^C. To make matters worse,
if the user waits for all the error messages to
This is an orphaned legacy leftover that is just polluting
the config file namespace.
Signed-off-by: Paul Gortmaker
---
include/configs/MPC8610HPCD.h |2 --
include/configs/MPC8641HPCN.h |2 --
include/configs/sbc8641d.h|2 --
3 files changed, 0 insertions(+), 6 deletions(-)
dif
commit 6d0f6bcf337c5261c08fabe12982178c2c489d76 did the big
rename of CFG_ macros to CONFIG_SYS macros. But it missed
a couple of instances within comments.
Signed-off-by: Paul Gortmaker
---
include/configs/sbc8349.h |2 +-
include/configs/vme8349.h |2 +-
2 files changed, 2 insertions(
ping?
On Mon, Sep 28, 2009 at 12:04:00PM +0200, Daniel Mack wrote:
> The current fatload code has a problem together with the way the DOS
> partition parser is implemented.
>
> This hit me when I tried to load a file from a USB stick which had no
> partition table but a FAT16 directly written to
On Friday 02 October 2009 18:18:33 Paul Gortmaker wrote:
> The basic memtest function tries to watch for ^C after each
> pattern pass as an escape mechanism, but if things are horribly
> wrong, we'll be stuck in an inner loop flooding the console with
> error messages and never check for ^C. To ma
On Friday 02 October 2009 16:08:54 Peter Tyser wrote:
> Signed-off-by: Peter Tyser
> ---
> This should be squashed with the top-most commit in the
> reloc branch.
if it doesnt get squashed, the changelog should mention the exact reason for
bumping the version ...
-mike
signature.asc
Descriptio
41 matches
Mail list logo
