Re: U-Boot 1.3.4 CONFIG_SILENT_CONSOLE Does Not Work?

On Thursday, September 30, 2010 16:05:49 NB wrote:
> However when I boot my device I see u-boot spiting out the same stuff it
> does even if "silent" isn't selected, as well as linux but I'm focusing on
> getting u- boot working as the README / README.silent suggests first.

ive seen issues depending on the env location.  if the env cannot be loaded 
early, the *default env* is consulted for its silent settings, and then things 
"work" once the saved env is relocated.

might also want to check CONSOLE_IS_IN_ENV is enabled.

otherwise, your options are:
	- trace the code yourself
	- upgrade, and then trace the code yourself
-mike

_______________________________________________
U-Boot mailing list
U-Boot <at> lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH V3 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base

Le 29/09/2010 10:55, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4CA2ECEA.1010002 <at> free.fr>  you wrote:
>>
>>> Do you expect any further work on this, or should we apply this to the
>>> public repo now?
>>
>> As far as Ben, Heiko and myself are concerned, there is not further work
>> expected on this. You may possibly want acks from custodians, Tom for
>> arm changes and Prafulla for orion5x (marvell) ones.
>
> I'm acting as Tom, and as such you have my ACK.
>
> Prafulla, do you agree that we pull this into mainline?
>
> Best regards,
>
> Wolfgang Denk

Prafulla,

Can you ack these patches -- or nak and comment? I've got new board 
support code which is waiting for them to get through.

Wolfgang,

Do you need a formal resubmit against master now that next is gone?

Thanks in advance.

Re: ARM relocation, probably trivial mistake

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4CA4AEFF.3050101 <at> denx.de> you wrote:
>>> 1. should CONFIG_SKIP_RELOCATE_UBOOT be not defined anymore?
>> If TEXT_BASE == relocation address it could be defined,
>> never tested.
> 
> We should point out that this is only intended (and allowed) for
> boards where U-Boot gets loaded into RAM by some other means (like a
> first stage boot loader, say when booting from NAND or SDCard).
> 
> When booting from NOR or some other persistent memory TEXT_BASE will
> point to that address range, and then it is obviously impossible to
> use the same value as relocation address.

Yes, you are right, that just work on boards, which use a preloader ...

bye,
Heiko
--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] ARMV7: OMAP3: Remove unnecessary #undef from Beagle config

Hello Steve,

Steve Sakoman wrote:
> This patch removes #undef CONFIG_SYS_ARM_WITHOUT_RELOC from the
> Beagle config file
> 
> Signed-off-by: Steve Sakoman <steve <at> sakoman.com>
> ---

Thanks, but this is already fixed here:

http://lists.denx.de/pipermail/u-boot/2010-September/077652.html

bye,
Heiko
--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: ARM relocation, probably trivial mistake

Le 01/10/2010 07:25, Heiko Schocher a écrit :
> Hello Wolfgang,
>
> Wolfgang Denk wrote:
>> Dear Heiko Schocher,
>>
>> In message<4CA4AEFF.3050101 <at> denx.de>  you wrote:
>>>> 1. should CONFIG_SKIP_RELOCATE_UBOOT be not defined anymore?
>>> If TEXT_BASE == relocation address it could be defined,
>>> never tested.
>>
>> We should point out that this is only intended (and allowed) for
>> boards where U-Boot gets loaded into RAM by some other means (like a
>> first stage boot loader, say when booting from NAND or SDCard).
>>
>> When booting from NOR or some other persistent memory TEXT_BASE will
>> point to that address range, and then it is obviously impossible to
>> use the same value as relocation address.
>
> Yes, you are right, that just work on boards, which use a preloader ...
>
> bye,
> Heiko

Actually CONFIG_SKIP_RELICATE_UBOOT should become unneeded once all 
boards which use it are made to support relocation, as the code will 
always check if it runs at its intended location and relocate only if 
needed.

Of course, code which is loaded in RAM at a location different from its 

Re: ARM relocation, probably trivial mistake

Hello Albert,

Albert ARIBAUD wrote:
> Le 01/10/2010 07:25, Heiko Schocher a écrit :
>> Hello Wolfgang,
>>
>> Wolfgang Denk wrote:
>>> Dear Heiko Schocher,
>>>
>>> In message<4CA4AEFF.3050101 <at> denx.de>  you wrote:
>>>>> 1. should CONFIG_SKIP_RELOCATE_UBOOT be not defined anymore?
>>>> If TEXT_BASE == relocation address it could be defined,
>>>> never tested.
>>>
>>> We should point out that this is only intended (and allowed) for
>>> boards where U-Boot gets loaded into RAM by some other means (like a
>>> first stage boot loader, say when booting from NAND or SDCard).
>>>
>>> When booting from NOR or some other persistent memory TEXT_BASE will
>>> point to that address range, and then it is obviously impossible to
>>> use the same value as relocation address.
>>
>> Yes, you are right, that just work on boards, which use a preloader ...
>>
>> bye,
>> Heiko
> 
> Actually CONFIG_SKIP_RELICATE_UBOOT should become unneeded once all
> boards which use it are made to support relocation, as the code will
> always check if it runs at its intended location and relocate only if

Re: [PATCH] Kirkwood: dram_init is moved to dram.c

> -----Original Message-----
> From: Heiko Schocher [mailto:hs <at> denx.de] 
> Sent: Thursday, September 30, 2010 9:10 PM
> To: Prafulla Wadaskar
> Cc: u-boot <at> lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c
> 
> Hello Prafulla,
> 
> Prafulla Wadaskar wrote:
> > For all Kirkwood boards so far dram_init function is duplicated
> > dram_init function is moved to dram.c and relevant code from all
> > board specific files removed
> > 
> > If any board needs specific dram init handling than standard one,
> > then, a macro CONFIG_SYS_BOARD_DRAM_INIT should be defined in
> > board config header file and the dram_init function can be put
> > in board specific source file
> > For ex. keymile boards
> > 
> > Signed-off-by: Prafulla Wadaskar <prafulla <at> marvell.com>
> > ---
> >  arch/arm/cpu/arm926ejs/kirkwood/dram.c          |   22 
> ++++++++++++++++++++++
> >  board/Marvell/guruplug/guruplug.c               |   11 -----------
> >  board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |   11 -----------
> >  board/Marvell/openrd_base/openrd_base.c         |   11 -----------
> >  board/Marvell/rd6281a/rd6281a.c                 |   11 -----------
> >  board/Marvell/sheevaplug/sheevaplug.c           |   11 -----------

[PATCH] xyzModem.c Packet buffer dynamic allocate

Hello.

It changes reduce bss usage.
Ymodem receive buffer dinamic allocation.

Signed-off-by: Yoshinori Sato <ysato <at> users.sourceforge.jp>
---
 common/cmd_load.c |    1 +
 common/xyzModem.c |   17 ++++++++++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/common/cmd_load.c b/common/cmd_load.c
index dad0303..f144bf4 100644
--- a/common/cmd_load.c
+++ b/common/cmd_load.c
 <at>  <at>  -992,6 +992,7  <at>  <at>  static ulong load_serial_ymodem (ulong offset)
 						  store_addr, res);
 				if (rc != 0) {
 					flash_perror (rc);
+					xyzModem_stream_close (&err);
 					return (~0);
 				}
 			} else
diff --git a/common/xyzModem.c b/common/xyzModem.c
index 7a46805..5af995d 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
 <at>  <at>  -58,6 +58,7  <at>  <at> 
 #include <xyzModem.h>
 #include <stdarg.h>

Re: [PATCH] Kirkwood: dram_init is moved to dram.c

Hello Prafulla,

Prafulla Wadaskar wrote:
>  
> 
>> -----Original Message-----
>> From: Heiko Schocher [mailto:hs <at> denx.de] 
>> Sent: Thursday, September 30, 2010 9:10 PM
>> To: Prafulla Wadaskar
>> Cc: u-boot <at> lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
>> Subject: Re: [U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c
>>
>> Hello Prafulla,
>>
>> Prafulla Wadaskar wrote:
>>> For all Kirkwood boards so far dram_init function is duplicated
>>> dram_init function is moved to dram.c and relevant code from all
>>> board specific files removed
>>>
>>> If any board needs specific dram init handling than standard one,
>>> then, a macro CONFIG_SYS_BOARD_DRAM_INIT should be defined in
>>> board config header file and the dram_init function can be put
>>> in board specific source file
>>> For ex. keymile boards
>>>
>>> Signed-off-by: Prafulla Wadaskar <prafulla <at> marvell.com>
>>> ---
>>>  arch/arm/cpu/arm926ejs/kirkwood/dram.c          |   22 
>> ++++++++++++++++++++++
>>>  board/Marvell/guruplug/guruplug.c               |   11 -----------