Hello,
I noticed that there is a lot of changes in ARM part of u-boot. Especially the
new relocation is a bit tricky. So I'm wondering what and where is the current
ARM development head, especially the at91 part. Is it u-boot master branch or
some other repository/branch?
Best regards,
Alexand
Dear Heiko Schocher,
In message <4cc7c628.70...@denx.de> you wrote:
>
> CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE)
> ^
> 0x4020f800
> CONFIG_SYS_INIT_RAM_SIZE 0x7f0
Why that? From the current settings I would expect somet
On 10/26/2010 12:35 PM, Jason Liu wrote:
>>> static int fec_set_hwaddr(struct eth_device *dev)
>>> @@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
>>> uint32_t base;
>>> struct fec_priv *fec = (struct fec_priv *)dev->priv;
>>>
>>> - /* Initialize MAC addre
Dear Matthias Dunda,
In message <6a334922-e6ee-4dc3-ae44-f43157006...@t1817.greatnet.de> you wrote:
>
> unfortunately I have to push this message, as I received no comment on it,
> yet.
See http://catb.org/esr/faqs/smart-questions.html#id586288
Best regards,
Wolfgang Denk
--
DENX Software
On 10/26/2010 12:29 PM, Jason Liu wrote:
>> As this is a cpu revision and not a board revision, it is not correct.
>> If the board revision cannot be determined correctly at runtime, we
>> should return a fixed value. but certainly not the cpu revision.
>
> Yes, agree. Then we need clean up the co
Dear Alexander Stein,
In message <201010270907.54241.alexander.st...@systec-electronic.com> you wrote:
>
> I noticed that there is a lot of changes in ARM part of u-boot. Especially
> the
> new relocation is a bit tricky. So I'm wondering what and where is the
> current
> ARM development head
Hi list,
the code for clearing bss section for most ARM cores looks like this
or very similar:
clear_bss:
#ifndef CONFIG_PRELOADER
ldr r0, _bss_start_ofs
ldr r1, _bss_end_ofs
ldr r3, _TEXT_BASE /* Text base */
mov r4, r7 /*
2010/10/27 Stefano Babic :
> On 10/26/2010 12:35 PM, Jason Liu wrote:
static int fec_set_hwaddr(struct eth_device *dev)
@@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
uint32_t base;
struct fec_priv *fec = (struct fec_priv *)dev->priv;
Wolfgang Denk wrote:
>Dear Daniel Hellstrom,
>
>In message <4cc54d00.6040...@gaisler.com> you wrote:
>
>
>>Mike Frysinger wrote:
>>
>>
>>
>>>It isn't possible to build any sparc boards without this ...
>>>
>>>
>>>
>>>
>>I'm working on a new patch set with some of the patches going thr
Dear Alexander Stein,
> I noticed that there is a lot of changes in ARM part of u-boot. Especially
> the
> new relocation is a bit tricky. So I'm wondering what and where is the
> current
> ARM development head, especially the at91 part. Is it u-boot master branch or
> some other repository/b
Dear Wolfgang,
Please pull the master branch of the sparc repository.
Thanks,
Daniel
The following changes since commit 11c8dd36edcc82564a19dbd0103302df66d66db0:
Stefano Babic (1):
FAT: buffer overflow with FAT12/16
are available in the git repository at:
git://www.denx.de/git/u-
Hi Matthias,
On Wednesday 27 October 2010 08:55:42 Matthias Dunda wrote:
> unfortunately I have to push this message, as I received no comment on it,
> yet.
>
> Is there a reason why the immap_t is not implemented for mpc85xx?
>
> I tried to copy it from mpc8360 but there are so many dependent m
hi,
On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
> IMO, if relocation is skipped, r4 should be loaded with value of
> _TEXT_BASE, not reloc address?
> It seems like r3 is prepared for this but, it's somehow missing? It's
> not used at all.
> Maybe it could be reason why I'm faci
Hi,
On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu wrote:
> hi,
>
> On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>
>> IMO, if relocation is skipped, r4 should be loaded with value of
>> _TEXT_BASE, not reloc address?
>> It seems like r3 is prepared for this but, it's somehow mis
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 79bc4d9..4f1973c 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -45,7 +45,7 @@
/* ByPass Cache when r
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index cb68d45..f081855 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -152,6 +152,16 @@ int greth_ini
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index f081855..0566e68 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -168,7 +168,7 @@ int greth_init(struct
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c | 78 ---
1 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 788aac8..cb68d45 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c | 66 +++---
1 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 4f1973c..788aac8 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/g
Signed-off-by: Daniel Hellstrom
---
drivers/net/greth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 0566e68..6c32226 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -644,9 +644,9 @@ int greth_initialize(
Out of tree building of the Netstal hcu4 and hcu5 boards failed like
that:
Configuring for mcu25 board...
Assembler messages: Fatal error: can't create
/work/wd/tmp-ppc/board/netstal/mcu25/../common/fixed_sdram.o: No such file or
directory
Assembler messages: Fatal error: can't create
/work/wd/
On 10/27/2010 09:40 AM, Jason Liu wrote:
> Yes, I haved looked it before and I also tested this patch on
> MX51babbage 3.0 board. It will printting some confusing information
> with floating value of MAC address when the board boot up after you
> set the ethaddr enviorment. The reason is that, whe
hi,
On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
> Hi,
>
> On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu
> wrote:
> >
> > Not sure which core are you referring to. I checked for arm926ejs,
> > and we have conditional code inclusion based on the definition of
> > CONFIG_SY
On Wed, Oct 27, 2010 at 11:54 AM, Sughosh Ganu wrote:
> hi,
>
> On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
>> Hi,
>>
>> On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu
>> wrote:
>
>> >
>> > Not sure which core are you referring to. I checked for arm926ejs,
>> > and we have c
Functions to store/retrieve the environment from a SPI flash was not updated
to the new environment code. The non-redundant case was
not working correctly, reporting ""Environment SPI flash not initialized"
and the code was not compiled clean in the redundant case.
The patch fixes these issue and
Name:Country___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Building of NAND based boards failed sometimes (especially on MP
systems) because of incorrect / missing dependencies.
Signed-off-by: Wolfgang Denk
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b50830a..5c83b07 100644
--- a/Makef
Hello Wolfgang,
Wolfgang Denk wrote:
> Building of NAND based boards failed sometimes (especially on MP
> systems) because of incorrect / missing dependencies.
>
> Signed-off-by: Wolfgang Denk
> ---
> Makefile |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Tested on the tx25 boa
On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
> No, there could be several different relocation methods - with and
> without preloader etc.
> There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes
> boot sequence dramatically.
> And it isn't CONFIG_SYS_ARM_WITHOUT_RE
Hi, Stefano,
2010/10/27 Stefano Babic :
> On 10/27/2010 09:40 AM, Jason Liu wrote:
>
>> Yes, I haved looked it before and I also tested this patch on
>> MX51babbage 3.0 board. It will printting some confusing information
>> with floating value of MAC address when the board boot up after you
>> set
After moving the definition of CONFIG_SYS_TEXT_BASE to the respective
board config files, all Marvell kirkwood board have just a single and
common entry in their config.mk files:
KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg
Replace the only reference to KWD_CONFIG in the top lev
From: Prafulla WADASKAR
ARMADA 100 SoCs has NS16550 compatible UART peripheral
This patch enables the same for ARMADA100 platforms
Signed-off-by: Mahavir Jain
Signed-off-by: Prafulla WADASKAR
---
drivers/serial/ns16550.c | 16
drivers/serial/serial.c |3 +++
2 files ch
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board spec
From: Prafulla WADASKAR
ARMADA 100 Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref: http://www.marvell.com/products/processors/applications/armada_100
SoC versions Supported:
1) ARMADA168/88AP168(Aspen P)
2) ARMADA166/88AP166(Aspen M)
3) ARMADA1
This patch series adds basic ARMADA100 support, with minimal drivers
(UART, MFP) support and Aspenite-DB board support for simple boot
Prafulla WADASKAR (3):
arm: Add Support for Marvell ARMADA 100 Familiy SoCs.
Serial: Add UART support for Marvell ARMADA 100 SoCs.
Armada100: Add Board Suppo
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar
---
arch/arm/include/asm/arch-armada100/mfp.h | 218 +
1 files changed, 218 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h
From: Prafulla WADASKAR
Aspenite is a Development Board for ASPEN/ARMADA168 (88AP168) Processor upto
1.2GHz with
* Parallel 1Gb x8 DDR2-1066 MHz
* 16 Mb x16 NOR, 4Gb x8 SLC NAND, footprint for SPI NOR
* Footprints for eMMC/eSD NAND & MMC x8 card
* 4-in-1 card read
Hi Prafulla,
On Wednesday 27 October 2010 15:53:21 Prafulla Wadaskar wrote:
> ARMADA 100 SoCs has NS16550 compatible UART peripheral
> This patch enables the same for ARMADA100 platforms
>
> Signed-off-by: Mahavir Jain
> Signed-off-by: Prafulla WADASKAR
> ---
> drivers/serial/ns16550.c | 16
On Wed, Oct 27, 2010 at 12:09 PM, Sughosh Ganu wrote:
> On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
>
>> No, there could be several different relocation methods - with and
>> without preloader etc.
>> There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes
>> boot s
This patch is to fix build breakage and support new relocatoin
scheme for mx51evk.
- Correct IRAM base address and add size definition
The IRAM starts from 0x1FFE on final revsion i.mx51 than
0x1FFE8000 which is for older revision.
- Include imx-regs.h in mx51evk.h
Definitions like CS
Dear Darius Augulis,
In message you
wrote:
>
> > I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with
> > relocation enabled unless we ensure that the TEXT_BASE would be same
> > as the relocation address.
>
> in case of nand_spl you don't need to to relocation twice because it's
> done
> -Original Message-
> From: Stefan Roese [mailto:s...@denx.de]
> Sent: Wednesday, October 27, 2010 3:24 PM
> To: u-boot@lists.denx.de; Prabhanjan Sarnaik
> Cc: Prafulla Wadaskar; Manas Saksena; Lei Wen; Eric Miao
> Subject: Re: [U-Boot] [PATCH 2/5] Serial: Add UART support for Marvell
>
In message <1288168304-2717-1-git-send-email...@denx.de> you wrote:
> Out of tree building of the Netstal hcu4 and hcu5 boards failed like
> that:
>
> Configuring for mcu25 board...
Please s/hcu4 and hcu5 boards/mcu25 board/ in the first line of
the commit message.
[not resending; will fix w
On 13/10/2010 9:25 PM, Xie Shaohui-B21989 wrote:
> Hi Can,
>
> Are there any differences between your patches and
> http://lists.denx.de/pipermail/u-boot/2009-March/049093.html ?
>
>
> Best Regards,
> Shaohui Xie
>
Hello Shaohui,
Firstly, I apologize for responding so late, we've been having so
On 10/27/2010 01:40 PM, Wolfgang Denk wrote:
> Dear Darius Augulis,
>
> In message you
> wrote:
>>
>>> I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with
>>> relocation enabled unless we ensure that the TEXT_BASE would be same
>>> as the relocation address.
>>
>> in case of nand_spl you
Copy Linaro for comments, as Linaro may be concerned by this patch.
On Mon, Oct 25, 2010 at 11:20 PM, Shawn Guo wrote:
> This patch is to consolidate default mx51evk env for two primary
> boot modes, mmcboot and netboot.
>
> It also cleans some unused env like netdev, uboot and redundant
> env li
On 10/27/2010 12:12 PM, Shawn Guo wrote:
> This patch is to fix build breakage and support new relocatoin
> scheme for mx51evk.
>
> - Correct IRAM base address and add size definition
>
> The IRAM starts from 0x1FFE on final revsion i.mx51 than
> 0x1FFE8000 which is for older revision.
>
2010/10/27 Shawn Guo :
> This patch is to fix build breakage and support new relocatoin
> scheme for mx51evk.
What's change is for the build breakage fix? Please state it clearly.
>
> - Correct IRAM base address and add size definition
>
> The IRAM starts from 0x1FFE on final revsion i.mx51
On Wed, Oct 27, 2010 at 7:29 PM, Jason Liu wrote:
> 2010/10/27 Shawn Guo :
>> This patch is to fix build breakage and support new relocatoin
>> scheme for mx51evk.
>
> What's change is for the build breakage fix? Please state it clearly.
>
The new relocation scheme requires the definition of
CONFI
Dear Darius Augulis,
In message <4cc80609.6040...@gmail.com> you wrote:
>
> > Maybe, maybe not. The preloader is usually very simple and may not be
> > clever enough to adjust the oad address to the avalable memory and
> > such; also, U-Boot features like protected RAM, shared video buffers
> > or
2010/10/27 Shawn Guo :
> On Wed, Oct 27, 2010 at 7:29 PM, Jason Liu wrote:
>> 2010/10/27 Shawn Guo :
>>> This patch is to fix build breakage and support new relocatoin
>>> scheme for mx51evk.
>>
>> What's change is for the build breakage fix? Please state it clearly.
>>
> The new relocation scheme
Dear Shawn Guo,
In message <1288174358-14896-1-git-send-email-shawn@gmail.com> you wrote:
> This patch is to fix build breakage and support new relocatoin
> scheme for mx51evk.
>
> - Correct IRAM base address and add size definition
>
> The IRAM starts from 0x1FFE on final revsion i.mx
On Wed, Oct 27, 2010 at 7:46 PM, Wolfgang Denk wrote:
> Dear Shawn Guo,
>
> In message <1288174358-14896-1-git-send-email-shawn@gmail.com> you wrote:
>> This patch is to fix build breakage and support new relocatoin
>> scheme for mx51evk.
>>
>> - Correct IRAM base address and add size definiti
On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
> Dear Heiko Schocher,
>
> In message <4cc7c628.70...@denx.de> you wrote:
> >
> > CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE)
> > ^
> > 0x4020f800
> > CONFIG_SYS_INIT_RAM_SIZ
On 10/27/2010 01:54 PM, Shawn Guo wrote:
> On Wed, Oct 27, 2010 at 7:46 PM, Wolfgang Denk wrote:
>> Dear Shawn Guo,
>>
>> In message <1288174358-14896-1-git-send-email-shawn@gmail.com> you wrote:
>>> This patch is to fix build breakage and support new relocatoin
>>> scheme for mx51evk.
>>>
>>>
Dear Shawn Guo,
In message you
wrote:
>
> > Please use something like
> >
> > #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE -
> > GENERATED_GBL_DATA_SIZE)
> > #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR +
> > CONFIG_SYS_INIT_SP_OFFSET)
> >
> If the automatic calcul
Hello Steve,
Steve Sakoman wrote:
> On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
>> Dear Heiko Schocher,
>>
>> In message <4cc7c628.70...@denx.de> you wrote:
>>> CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE)
>>> ^
>>> 0x40
On Wed, Oct 27, 2010 at 8:23 PM, Wolfgang Denk wrote:
> Dear Shawn Guo,
>
> In message you
> wrote:
>>
>> > Please use something like
>> >
>> > #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE -
>> > GENERATED_GBL_DATA_SIZE)
>> > #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_
Dear Steve Sakoman,
In message <1288181563.2342.98.ca...@quadra> you wrote:
>
> > Why that? From the current settings I would expect something like
> >
> > CONFIG_SYS_INIT_RAM_ADDR0x4020f800
> > CONFIG_SYS_INIT_RAM_SIZE0x800
> >
> > I see no reason to substract the top 16
Dear Shawn Guo,
In message you
wrote:
>
> > But the stack pointer will not start at the end of the initial ram
> > area, but below the global data area which lies at the end.
> >
> I thought the manual definition of CONFIG_SYS_INIT_SP_ADDR is the near
> term solution, since it will be replaced b
On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote:
> Hello Steve,
>
> Steve Sakoman wrote:
> > On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
> >> Dear Heiko Schocher,
> >>
> >> In message <4cc7c628.70...@denx.de> you wrote:
> >>> CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE)
> >>>
Hi Shawn,
> Let's look at this example. Here is what I see on
> http://lists.denx.de/pipermail/u-boot/2010-October/thread.html.
[...]
> Is this some problem with u-boot mail list threading itself or the gmail
> mailer?
This is a _feature_ of the pipermail component of GNU mailman. It
intenti
Hello Steve,
Steve Sakoman wrote:
> On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote:
>> Hello Steve,
>>
>> Steve Sakoman wrote:
>>> On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
Dear Heiko Schocher,
In message <4cc7c628.70...@denx.de> you wrote:
> CONFIG_SYS_IN
Hi Remy,
On Wed, 1 Sep 2010 10:49:22 +0200
Remy Bohmer wrote:
...
> 2010/8/31 Anatolij Gustschin :
> > Checking the status field of the qTD token in the current code
> > do not take into acount cases where endpoint stall (halted) bit
> > is set together with some other status bits. As a result cl
Default configuration enables multiple features
that are great for intial development work. But
many of them are not useful when time taken to
boot kernel is important - and uboot is frozen.
This patch attempts to reduce the size of u-boot
binary by excluding unused/not-so-commonly used
features/c
Dear Sanjeev Premi,
In message <1288186611-30656-1-git-send-email-pr...@ti.com> you wrote:
> Default configuration enables multiple features
> that are great for intial development work. But
> many of them are not useful when time taken to
> boot kernel is important - and uboot is frozen.
>
> Thi
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Wednesday, October 27, 2010 7:19 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
>
[snip]...[snip]
> > +#undef CONFIG_QUICK_BOOT
> > +#undef CO
This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and
CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and
Heiko Schocher.
Signed-off-by: Steve Sakoman
---
Tested on Overo. Will test on all available boards later today.
diff --git a/include/conf
Commit 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 broke the da850evm build. The
introduction of GENERATED_GBL_DATA_SIZE led to:
$make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error| warning)'
Generating include/autoconf.mk
Generating include/autoconf.mk.dep
awk '(NF && $1 !~ /^#/) {
Hello Steve,
Steve Sakoman wrote:
> This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and
> CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and
> Heiko Schocher.
>
> Signed-off-by: Steve Sakoman
> ---
>
> Tested on Overo. Will test on all avail
This patch fixes the reset command on imx25. The watchdog registers are 16
bits in size and not 32. This patch also adds the service register codes as
constants.
Signed-off-by: Matthias Weisser
---
Changes since V2
- Using 16 bit constants
Changes since V1
- Corrected whitespace
- Leavi
Hello Ben,
Ben Gardiner wrote:
> Commit 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 broke the da850evm build. The
> introduction of GENERATED_GBL_DATA_SIZE led to:
>
> $make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error|
> warning)'
> Generating include/autoconf.mk
> Generating in
Hello Heiko,
On Wed, Oct 27, 2010 at 10:35 AM, Heiko Schocher wrote:
> Hello Ben,
>
> Ben Gardiner wrote:
>> Commit 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 broke the da850evm build. The
>> introduction of GENERATED_GBL_DATA_SIZE led to:
> [...]
> Not necessary, already fixed here:
>
> http://lis
Dear Matthias Weisser,
> struct wdog_regs {
> - u32 wcr;/* Control */
> - u32 wsr;/* Service */
> - u32 wrsr; /* Reset Status */
> - u32 wicr; /* Interrupt Control */
> - u32 wmcr; /* Misc Control */
> + u16 wcr;/* Control */
> +
On Wed, Oct 27, 2010 at 2:37 AM, Wolfgang Denk wrote:
> When copying the "sed" script to generate the asm-offsets.h file from
> the Linux Kbuild script into the make-asm-offsets file I missed the
> fact that the former runs in a "make" context and thus uses double
> "$$" to escape a single "$", wh
[looks like this message got lost, resending]
On 2010/10/24 4:00 PM, Wolfgang Denk wrote:
> The 100MHz configuation of the VoVPN-GW has never been supported, so
> drop it now.
>
> Signed-off-by: Wolfgang Denk
> ---
>
> This commit shows a problem with the concept of the "README.scrapyard"
> fil
>
> Hello Steve,
>
> Steve Sakoman wrote:
> > This patch fixes the issue by defining and using
> CONFIG_SYS_INIT_RAM_SIZE and
> > CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang
> Denk and
> > Heiko Schocher.
> >
> > Signed-off-by: Steve Sakoman
> > ---
> >
> > Tested on Ov
Dear "Premi, Sanjeev",
In message you
wrote:
>
> > This has the additional benefit that you can actually build both
> > configurations without the need to modify any source files.
>
> [sp] Was only concerned about possibility of multiple configurations
> per platform. Keeping them in sync
Dear Rogan Dawes,
In message <4cc83d9d@dawes.za.net> you wrote:
> [looks like this message got lost, resending]
No, it was not lost, just unreplied.
> Include the cmdline at the top of the scrapyard file, and it should be
> fairly self-evident, I would hope.
Agreed that this is one of the p
Dear "Paulraj, Sandeep",
In message <0554bef07d437848af01b9c9b5f0bc5da9d89...@dlee01.ent.ti.com> you
wrote:
>
> > Test this patch on my beagle board, works fine:
> >
> > Tested-by: Heiko Schocher
> >
>
> Should I consider this a bug fix and add it to my tree?
>
> I believe the patch itself
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
> Maybe it could be reason why I'm facing strange problem, when after
> relocating uboot with nand_spl no one command is not working. I
> debugged that command table is empty.
Maybe this is the same problem I reported here (commands
On 2010/10/27 5:10 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
>
> In message <4cc83d9d@dawes.za.net> you wrote:
>> [looks like this message got lost, resending]
>
> No, it was not lost, just unreplied.
Ok, I didn't see it on gmane, so I assumed it had gone astray.
Rogan
__
On 10/20/10 15:50, Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message<4cbdc153.30...@ruggedcom.com> you wrote:
>>
>> It does not work on our platform (similar to MPC8360EMDS). I think this is
>> specific to our platform because
>> we need to initialize i2c and use i2c while still execu
On Wed, Oct 27, 2010 at 5:21 AM, Jason Liu wrote:
> Hi, Stefano,
>
> 2010/10/27 Stefano Babic :
>> On 10/27/2010 09:40 AM, Jason Liu wrote:
>>
>>> Yes, I haved looked it before and I also tested this patch on
>>> MX51babbage 3.0 board. It will printting some confusing information
>>> with floating
Dear John,
In message you
wrote:
>
> The patch fixes the particular case where you have no ethaddr in fuse,
> nor persistent env. The case is a board where the only persistent
> storage is an SD card and you set load a boot script from file in a
Well, if ther eis no MAC address in the fuse, an
In message <1288128370-2556-1-git-send-email...@denx.de> you wrote:
> Commit 7e263ce "post/i2c: Clean up detection logic" added a "const"
> qualifier to the declaration of i2c_addr_list[], missing the fact that
> the list gets modified later in the code, which results in build
> errors like these:
Hi Eric,
On 10/27/2010 06:12 PM, Eric Cooper wrote:
> On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>> Maybe it could be reason why I'm facing strange problem, when after
>> relocating uboot with nand_spl no one command is not working. I
>> debugged that command table is empty.
Dear Wolfgang Denk,
In message <1288168304-2717-1-git-send-email...@denx.de> you wrote:
> Out of tree building of the Netstal hcu4 and hcu5 boards failed like
> that:
>
> Configuring for mcu25 board...
> Assembler messages: Fatal error: can't create
> /work/wd/tmp-ppc/board/netstal/mcu25/../comm
In message <1288161467-2979-1-git-send-email...@denx.de> you wrote:
> When copying the "sed" script to generate the asm-offsets.h file from
> the Linux Kbuild script into the make-asm-offsets file I missed the
> fact that the former runs in a "make" context and thus uses double
> "$$" to escape a s
In message <1288170898-3332-1-git-send-email...@denx.de> you wrote:
> Building of NAND based boards failed sometimes (especially on MP
> systems) because of incorrect / missing dependencies.
>
> Signed-off-by: Wolfgang Denk
> ---
> Makefile |2 +-
> 1 files changed, 1 insertions(+), 1 deleti
Dear Prafulla Wadaskar,
In message <1288187252-3341-1-git-send-email-prafu...@marvell.com> you wrote:
> After moving the definition of CONFIG_SYS_TEXT_BASE to the respective
> board config files, all Marvell kirkwood board have just a single and
> common entry in their config.mk files:
>
>
Dear Prafulla Wadaskar,
In message <1288187604-3371-5-git-send-email-prafu...@marvell.com> you wrote:
> This patch adds the support MFP support for Marvell ARMADA100 SoCs
>
> Signed-off-by: Prafulla Wadaskar
> ---
There is a typo in the Subject: please s/Fnction/Function/
[No need to repost be
Dear Prafulla Wadaskar,
In message <1288187604-3371-6-git-send-email-prafu...@marvell.com> you wrote:
...
> ---
> MAINTAINERS |1 +
> MAKEALL |1 +
> board/Marvell/aspenite/Makefile | 52 ++
> board/Marvell/aspenite/aspenite.
Dear Stefano Babic,
In message <1288170380-32580-1-git-send-email-sba...@denx.de> you wrote:
> Functions to store/retrieve the environment from a SPI flash was not updated
> to the new environment code. The non-redundant case was
> not working correctly, reporting ""Environment SPI flash not initi
Dear Daniel Hellstrom,
In message <4cc7da61.5010...@gaisler.com> you wrote:
>
> The following changes since commit 11c8dd36edcc82564a19dbd0103302df66d66db0:
> Stefano Babic (1):
> FAT: buffer overflow with FAT12/16
>
> are available in the git repository at:
>
> git://www.denx.de/gi
Dear Lei Wen,
In message <1287034691-26278-1-git-send-email-lei...@marvell.com> you wrote:
> Constraint the mmc framework to only send no more than 65535
> blocks in one go during the multi-write command. This constraint
> comes due to the limitation of 16bit width block counter register
> at some
Dear Alessandro Rubini,
In message <20101026214042.ga2...@morgana.i.gnudd.com> you wrote:
> > I am not convinced, as we don't have an array context here.
>
> But sizeof(struct x) doesn't depend on how struct x is used.
> You can declare a pointer and then allocate for an array.
>
> > I don't see
Dear Enric Balletbo i Serra,
In message <1287479602-21721-2-git-send-email-eballe...@iseebcn.com> you wrote:
> Running the onenand command without arguments does nothing, with this
> patch shows the command usage.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> common/cmd_onenand.c |3 +++
Dear Nobuhiro Iwamatsu,
In message you
wrote:
>
> Could you take in these patches?
Are these bug fixes, or can they wait for the "next" branch?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82
On Wed, Oct 27, 2010 at 2:06 PM, Wolfgang Denk wrote:
> Dear John,
>
> In message you
> wrote:
>>
>> The patch fixes the particular case where you have no ethaddr in fuse,
>> nor persistent env. The case is a board where the only persistent
>> storage is an SD card and you set load a boot scrip
1 - 100 of 137 matches
Mail list logo
