Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message <4b126f68.9020...@free.fr> you wrote:
>>> Cannot you use get_ram_size() for auto-sizing and checking?
>> The SoC allows for up to 4 banks of DRAM, not necessarily contiguous.
>> Granted, this is not a frequent configuration, however I'
Dear Wolfgang,
2009/12/5 Wolfgang Denk :
> Dear Minkyu Kang,
>
> In message <1f3430fb0912031616t6910a3d9yce8621afe0631...@mail.gmail.com> you
> wrote:
>>
> ...
>> applied to u-boot-samsung
>
> Thanks for clean9ing up the original poster's mess of a commit
> message. But please feel free to reject
On Fri, 4 Dec 2009 09:51:45 +0100
Stefan Roese wrote:
> 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.
>
> Signed-off-by: Stefan Roese
> Cc: Reinhard Arlt
> Cc: Kim Phillips
On Fri, 20 Nov 2009 12:42:43 +0100
Peter Korsgaard wrote:
> E.G. on a 8347 board a bootup time increase of ~600ms has been observed:
heh, even more on an 8313! Thanks for this - I hadn't realized the
difference was so large (or neglected it since the move to init_r was
done at the last moment).
Dear Kevin,
In message <4b19905d.8040...@fearnside-systems.co.uk> you wrote:
>
> On 02/12/2009 22:09, Wolfgang Denk wrote:
> > Hi Kevin,
> >
> > looking at the code resulting from commit 9ebfdc20 again, I see that
> > you keep a LOT of uppercase variable names, which are not allowed as
> > per
Dear Minkyu Kang,
In message <1f3430fb0912031616t6910a3d9yce8621afe0631...@mail.gmail.com> you
wrote:
>
...
> applied to u-boot-samsung
Thanks for clean9ing up the original poster's mess of a commit
message. But please feel free to reject such horribly formatted
submissions.
Best regards,
Wol
Dear Seunghyeon Rhee,
In message <4b17094d.2090...@lpmtec.com> you wrote:
>
> > Dear Seunghyeon Rhee,
> >
> > 2009/11/28 "Seunghyeon Rhee" :
> >
> >> The MSB of DMC1_MEM_CFG can be set to '1' for separate CKE control
> >> for S3C6400. In the configuration of SMDK6400, however, two 16-bit
> >> m
Dear Kim,
In message <20091204185150.1e2939e8.kim.phill...@freescale.com> you wrote:
>
> > It seems Kim is on vacation or something like that.
>
> I was, but I'm back now.
I hope you had a good time. Welcome back.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfga
Dear Peter Tyser,
In message <1259972321.23828.13300.ca...@localhost.localdomain> you wrote:
>
> Thanks for applying patches 2 and 3. Stefano Babic noticed that this
> change was already submitted by Remy and was merged in
> 6a590c5f5fd12cdd27f3153522acfac3854590e7, so 1/3 shouldn't be necessary.
Dear Mike Frysinger,
In message <1259922915-22943-1-git-send-email-vap...@gentoo.org> you wrote:
> The Linux kernel build system changed how it compresses things with LZMA
> such that the header no longer contains the filesize (it is instead set to
> all F's). So if we get a LZMA image that has -
On Sat, 5 Dec 2009 01:29:25 +0100
Wolfgang Denk wrote:
> Dear Peter Korsgaard,
>
> In message <87pr7472vw@macbook.be.48ers.dk> you wrote:
> > > "Peter" == Peter Korsgaard writes:
> >
> > Peter> Commit c7190f02 (retain POR values of non-configured ACR, SPCR,
> > SCCR,
> > Peter> and
Dear Detlev Zundel,
In message <1259684179-25173-1-git-send-email-...@denx.de> you wrote:
> Two later additions to the Configuration Option section unfortunately
> split the description of Show boot progress and the list of its call outs.
>
> Signed-off-by: Detlev Zundel
> ---
> README | 40 +
Dear Scott Wood,
In message <20091201235510.ga19...@loki.buserror.net> you wrote:
>
> > @Scott: please review
> > @Wolfgang: please consider for 2009.11
>
> Applied to next. I think it's too late for 2009.12, since it's supposed to
> be released tomorrow according to http://www.denx.de/wiki/U-Bo
Dear Marcos Cunha,
In message <4b1425de.6030...@atlantico.com.br> you wrote:
>
> Content-Type: image/gif
> Content-Transfer-Encoding: base64
...
> Content-Type: image/gif
> Content-Transfer-Encoding: base64
...
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-E
Dear Albert ARIBAUD,
In message <4b1236f3.4010...@free.fr> you wrote:
>
> These files are derived from their kirkwood counterparts, which are GPL
> v2 only, so I don't have the right to simply change that to "v2 or any
> later version", I believe, unless the originals' copyright owner allows
>
Dear Albert ARIBAUD,
In message <4b126f68.9020...@free.fr> you wrote:
>
> > Cannot you use get_ram_size() for auto-sizing and checking?
>
> The SoC allows for up to 4 banks of DRAM, not necessarily contiguous.
> Granted, this is not a frequent configuration, however I'd like to
> support it co
Dear Joakim Tjernlund,
In message <1258633364-20805-1-git-send-email-joakim.tjernl...@transmode.se>
you wrote:
> This patch optimizes the direct copy procedure.
> Uses get_unaligned() but only in one place.
> The copy loop just above this one can also use this
> optimization, but I havn't done so
Dear Peter Korsgaard,
In message <1258627071-24531-1-git-send-email-jac...@sunsite.dk> you wrote:
> Add lzop decompression support to the existing lzo bitstream handling
> (think gzip versus zlib), and support it for uImage decompression if
> CONFIG_LZO is enabled.
>
> Lzop doesn't compress as go
Dear Peter Korsgaard,
In message <87pr7472vw@macbook.be.48ers.dk> you wrote:
> > "Peter" == Peter Korsgaard writes:
>
> Peter> Commit c7190f02 (retain POR values of non-configured ACR, SPCR, SCCR,
> Peter> and LCRR bitfields) moved the LCRR assignment to after relocation
> Peter> to R
Dear Alessandro Rubini,
In message <20091126091722.ga14...@mail.gnudd.com> you wrote:
> I'm sorry I forgot a few extra prints in there:
>
> > + printf("%s:%s - %i %i %i %i\n", __FILE__, __func__,
> > + regno, red, green, blue);
>
> > + printf("%s:%s\n", __FILE__, __func__);
>
> [an
Dear "Hiremath, Vaibhav",
In message <19f8576c6e063c45be387c64729e739404370d7...@dbde02.ent.ti.com> you
wrote:
>
> > > #define CONTROL_PADCONF_D2D_SBUSFLAG 0x0260
> > > #define CONTROL_PADCONF_SDRC_CKE00x0262
> > > #define CONTROL_PADCONF_SDRC_CKE10x0264
> > > +/* AM3517 sp
Dear "Hiremath, Vaibhav",
In message <19f8576c6e063c45be387c64729e739404370d7...@dbde02.ent.ti.com> you
wrote:
>
...
> > > +#ifndef __ASSEMBLY__
> > > +extern struct gpmc *gpmc_cfg;
> > > +extern unsigned int boot_flash_base;
> > > +extern volatile unsigned int boot_flash_env_addr;
> > > +extern
On Sat, 2009-12-05 at 01:13 +0100, Wolfgang Denk wrote:
> Dear Peter Tyser,
>
> In message <1259102530-32071-1-git-send-email-pty...@xes-inc.com> you wrote:
> > When building a Flattened Image Tree (FIT) the image type needs to be
> > "flat_dt". Commit 89a4d6b12fd6394898b8a454cbabeaf1cd59bae5 int
Dear Peter Tyser,
In message <1259102530-32071-3-git-send-email-pty...@xes-inc.com> you wrote:
> Previously, there was no indication to the user that a FIT image was
> successfully created after executing mkimage. For example:
>
> $ mkimage -f uImage.its uImage.itb
> DTC: dts->dtb on file "
Dear Peter Tyser,
In message <1259102530-32071-1-git-send-email-pty...@xes-inc.com> you wrote:
> When building a Flattened Image Tree (FIT) the image type needs to be
> "flat_dt". Commit 89a4d6b12fd6394898b8a454cbabeaf1cd59bae5 introduced a
> regression which caused the user to need to specify th
Dear Peter Tyser,
In message <1259102530-32071-2-git-send-email-pty...@xes-inc.com> you wrote:
> The FIT fit_set_header() function was copied from the standard uImage's
> image_set_header() function during mkimage reorganization. However, the
> fit_set_header() function is not used since FIT imag
Dear Dimitar Dimitrov,
In message <200911242147.04900.dinu...@gmail.com> you wrote:
>
> I can regenerate the patches for the latest GIT. If someone is willing to try
> them please let me know.
>
> Unfortunately I don't have the boards anymore so I can't verify that the new
> patches and new u-
Dear Ingo van Lil,
In message <20091124130921.ga...@zaphod.peppercon.de> you wrote:
> According to the PPC reference implementation the udelay() function is
> responsible for resetting the watchdog timer as frequently as needed.
> Most other architectures do not meet that requirement, so long-runn
Dear Graeme Russ,
In message <1259053461-9215-11-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> board/eNET/config.mk |2 +
> board/eNET/eNET.c | 17 +++--
> board/eNET/u-boot.lds | 34 +++--
> cpu/i386/cpu.c
Dear Graeme Russ,
In message <1259053461-9215-10-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> include/asm-i386/u-boot-i386.h |6 --
> lib_i386/bios_setup.c |6 ++
> lib_i386/board.c | 11 ---
> lib_i386/
Dear Graeme Russ,
In message <1259053461-9215-9-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> board/eNET/eNET_start16.S |2 +
> cpu/i386/cpu.c|2 +
> cpu/i386/interrupts.c |4 ++
> lib_i386/bios.S | 70
>
Dear Graeme Russ,
In message <1259053461-9215-8-git-send-email-graeme.r...@gmail.com> you wrote:
> --===1692275119==
>
> In preperation for full relocation
>
> Signed-off-by: Graeme Russ
> ---
> cpu/i386/Makefile |2 +-
> cpu/i386/cpu.c |1 -
>
Dear Graeme Russ,
In message <1259053461-9215-7-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> cpu/i386/sc520/sc520_timer.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
Applied to "next", thanks.
Best regards,
Wolfgang Denk
Dear Graeme Russ,
In message <1259053461-9215-5-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> lib_i386/Makefile |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
Applied to "next", thanks.
Best regards,
Wolfgang Denk
--
DENX Softw
Dear Graeme Russ,
In message <1259053461-9215-4-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> board/eNET/config.mk |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied to "next", thanks.
Best regards,
Wolfgang Denk
--
DENX Software
Dear Graeme Russ,
In message <1259053461-9215-3-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> common/dlmalloc.c |6 --
> include/configs/eNET.h|2 +-
> include/configs/sc520_cdp.h |2 +-
> include/configs/sc520_spun
Dear Graeme Russ,
In message <1259053461-9215-2-git-send-email-graeme.r...@gmail.com> you wrote:
>
> Signed-off-by: Graeme Russ
> ---
> board/eNET/config.mk |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied to "next", thanks.
Best regards,
Wolfgang Denk
--
DENX Software
Dear Michael Brandt,
In message <4b0938f7.8080...@emsyso.de> you wrote:
> From: Michael Brandt
>
> extfs.c assumes that there is always a valid inode_size field in the
> superblock. But this is not true for ext2fs rev 0. Such ext2fs images are for
> instance generated by genext2fs. Symptoms on A
Hi Michal,
It appears there's a problem with the default memory map in u-boot's
"microblaze-generic" configuration. We have (from
include/configs/microblaze-generic.h):
/* ddr sdram - main memory */
#defineCONFIG_SYS_SDRAM_BASEXILINX_RAM_START
#defineCONFIG_SYS_SDRA
9136703
m: 07939 126277
e: kevin.morf...@fearnside-systems.co.uk
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4661 (20091204) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
joe zhou wrote:
> Hi,
>
> I am using 9G20 and set eccmode NAND_ECC_NONE in u-boot, but when I try to
> write some data from memory into flash with u-boot interface, it failed.
> (sam-ba can not read this page back from nand flash, it says a bad block).
> but I use NAND_ECC_SOFT, it is successful.
Hi,
I am using 9G20 and set eccmode NAND_ECC_NONE in u-boot, but when I try to
write some data from memory into flash with u-boot interface, it failed.
(sam-ba can not read this page back from nand flash, it says a bad block).
but I use NAND_ECC_SOFT, it is successful.
why? anyone can give some h
Dear Stefan Roese,
In message <200912031154.39962...@denx.de> you wrote:
>
> The board maintainer, Travis Sawyer, doesn't work for Sandburst (acquired by
> Broadcom some time ago?) any more. So we can't get his comments on this. Not
> sure what to do with those Sandburst boards now. They are no
Dear Kumar Gala,
In message you wrote:
>
> > Andy/Kumar: I hope it's OK with you that I take this directky.
...
> no issue, will drop it from my 'next' branch.
You don't really have to - git will sort this out.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang
Dear Heiko,
In message <4b175f3f.2060...@denx.de> you wrote:
>
> > Applied, thanks.
> >
> > Heiko, I hope this is OK with you.
>
> Hmm.. not really, my last comment on this was:
Ouch, sorry.
> http://lists.denx.de/pipermail/u-boot/2009-November/064245.html
I missed that, sorry. This was in a
Dear Wolfgang,
In message <4b19116d.11160.b40...@w.wegner.astro-kom.de> you wrote:
>
> The implementation is in lib_generic/gunzip.c, and it is used by 19 other
> files.
> I could add it to a header but have (at least) two problems with it:
> - I do not know which header would be appropriate (ge
On 4 Dec 2009 at 11:16, Wolfgang Denk wrote:
[...]
> Yes, but we don't add one without the other. There have been too many
> cases where people asked for fancy features for specific boards that
> were out-of-tree ports without any attempts to get merged, so we now
> always wait for actual use cas
Dear Wolfgang Denk,
On 2 Dec 2009 at 22:43, Wolfgang Denk wrote:
> Dear Wolfgang Wegner,
>
> In message <1256916625-30792-1-git-send-email-w.weg...@astro-kom.de> you
> wrote:
> > imxtract currently can not handle compressed images. This patch adds
> > handling for bzip2 and zip compression. In
Fred Fan wrote:
> Dear wolfgang,
> I almost fixed all of your comments.
Hi Fred,
I have already tested your patch on the babbage2 board and I would ask
you about the status. The boot loader does not start (I have tried
flashing the SPI NOR, and this seems ok. The code seems loaded from the
f
The Linux kernel build system changed how it compresses things with LZMA
such that the header no longer contains the filesize (it is instead set to
all F's). So if we get a LZMA image that has -1 for the 64bit field,
let's just assume that the decompressed size is unknown and continue on.
Signed-
Dear w.weg...@astro-kom.de,
In message <4b18e5c5.22102.97...@w.wegner.astro-kom.de> you wrote:
>
> > Where is this block write function being implemented?
> >
> > I don't see it anywhere in the patch, nor any code that actually uses
> > it?
>
> sorry, my wording was probably wrong.
> This curren
> 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.
>
> Signed-off-by: Stefan Roese
> Cc: Reinhard Arlt
> Cc: Kim Phillips
Acked-by: Dave Liu
__
Dear Wolfgang Denk,
On 2 Dec 2009 at 22:44, Wolfgang Denk wrote:
> Dear Wolfgang Wegner,
>
> In message <1256918102-3760-1-git-send-email-w.weg...@astro-kom.de> you wrote:
> > Using seperate function calls for each bit-bang of slave serial
> > load can be painfully slow. This patch adds the poss
From: Reinhard Arlt
This chip is equipped for example on the esd PMC-ETH2-GB board. So let's
add it to the list of supported chips to the e1000 driver.
Signed-off-by: Reinhard Arlt
Signed-off-by: Stefan Roese
Cc: Ben Warren
---
drivers/net/e1000.c |1 +
include/pci_ids.h |1 +
2 fi
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.
Signed-off-by: Stefan Roese
Cc: Reinhard Arlt
Cc: Kim Phillips
---
cpu/mpc83xx/spd_sdram.c |7 +++
1 files changed, 7 inse
55 matches
Mail list logo
