Re: [U-Boot] "Move do_irqinfo() to common/cmd_irq.c" breaks MVBLUE board...
Peter, > On second thought, this will disable both the 'interrupts' and 'irqinfo' > command for the MVBLUE. Andre, do you mind if the 'interrupts' command > is not available the MVBLUE? > please go ahead - no problem at all. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAKEALL: Fix return value
On Sunday 06 December 2009 03:44:06 Peter Tyser wrote:
> On Sun, 2009-12-06 at 02:45 -0500, Mike Frysinger wrote:
> > On Sunday 06 December 2009 02:09:34 Peter Tyser wrote:
> > > ${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
> > >
> > > | tee ${LOG_DIR}/$target.ERR
> >
> > you could rewrite this to keep POSIX compliance:
> > # need to maintain exit value ourselves as pipes eat it
> > fail=${LOG_DIR}/$target.failed
> > rm -f ${fail}
> > (${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
> >
> > || touch ${fail}) | tee ${LOG_DIR}/$target.ERR
> >
> > [ -e ${fail} ] && : $(( RC += 1 ))
> > rm -f ${fail}
>
> Ahh, clever. It doesn't really matter which way to me. PIPESTATUS
> seems more straightforward, but maintaining POSIX compliance would be
> nice too.
i agree with both points
> > > + # Return how many board compiles failed, assuming 'make' returns 2
> > > + # for builds which failed
> > > + exit $(((RC + 1) / 2))
> >
> > the problem here is that exit statuses have a range of 256 values. so as
> > soon as more than 255 boards fail, this wont work. maybe i'm being
> > overly paranoid though ?
>
> Good point. I can change RC into a bitwise OR of the 'make' return
> values instead of a sum. I think 98% of the time people just want to
> know if any board compile failed, not specifically how many boards
> failed.
right, so maybe something like:
: $(( RC = (RC + 1) / 2 ))
# exit values top out at 255
exit $(( RC > 255 ? 255 : RC ))
not that ive ever looked at the exit status as anything meaningful ... i
always review the ERR files to make sure they're all 0 bytes.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix debug output.
Signed-off-by: Thomas Weber
---
drivers/net/dm9000x.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
index 73dd335..08bd794 100644
--- a/drivers/net/dm9000x.c
+++ b/drivers/net/dm9000x.c
@@ -74,8 +74,8 @@ TODO: external MII is not functional, only internal at the
moment.
#define DM9000_DBG(fmt,args...) printf(fmt, ##args)
#define DM9000_DMP_PACKET(func,packet,length) \
do { \
- int i; \
- printf(func ": length: %d\n", length); \
+ int i; \
+ printf("%s: length: %d\n",func, length);
\
for (i = 0; i < length; i++) { \
if (i % 8 == 0) \
printf("\n%s: %02x: ", func, i);\
--
1.6.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] About the variable environment and default_environment when environment is embedded
Hi all,
I'm working with the u-boot-2009-08.tar.bz2 and find some code I am not very
clear.
My puzzle is about the extern array "environment[]" which declared in
"env_flash.c" as
an array composed by unsigned char. However, it is defined as a env_t struct
in the
"env_embedded.c". So the declaration conflicts with definition, but it can
be compiled
normally, does any one tell me why? Thanks.
Here is the code in ./common/env_flash.c and ./common/env_embedded.c
**
/* In file ./common/env_flash.c */
#ifdef ENV_IS_EMBEDDED
extern uchar environment[];
env_t *env_ptr = (env_t *)(&environment[0]);
#ifdef CMD_SAVEENV
/* static env_t *flash_addr = (env_t *)(&environment[0]);-broken on
ARM-wd-*/
static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
#endif
#else /* ! ENV_IS_EMBEDDED */
env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
#ifdef CMD_SAVEENV
static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
#endif
**
/* In file ./common/env_embedded.c */
#ifdef ENV_IS_EMBEDDED
...
env_t environment __PPCENV__ = {
ENV_CRC,/* CRC Sum */
#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
1,/* Flags: valid */
#endif
{
#if defined(CONFIG_BOOTARGS)
"bootargs="CONFIG_BOOTARGS"\0"
#endif
#if defined(CONFIG_BOOTCOMMAND)
"bootcmd="CONFIG_BOOTCOMMAND"\0"
#endif
.
};
...
#endif
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Microblaze stack clobbered in d4e8ada0f6d51e0e3b80790fb9375ac8910f5352 (Consolidate arch-specific mem_malloc_init() implementations)
Hi Graeme, Graeme Smecher wrote: > 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_SDRAM_SIZEXILINX_RAM_SIZE >#defineCONFIG_SYS_MEMTEST_STARTCONFIG_SYS_SDRAM_BASE >#defineCONFIG_SYS_MEMTEST_END(CONFIG_SYS_SDRAM_BASE + > 0x1000) > >/* global pointer */ >#defineCONFIG_SYS_GBL_DATA_SIZE128 /* size of global data */ >/* start of global data */ >#defineCONFIG_SYS_GBL_DATA_OFFSET(CONFIG_SYS_SDRAM_BASE + > CONFIG_SYS_SDRAM_SIZE - CONFIG_SYS_GBL_DATA_SIZE) > >/* monitor code */ >#defineSIZE0x4 >#defineCONFIG_SYS_MONITOR_LEN(SIZE - > CONFIG_SYS_GBL_DATA_SIZE) >#defineCONFIG_SYS_MONITOR_BASE(CONFIG_SYS_GBL_DATA_OFFSET - > CONFIG_SYS_MONITOR_LEN) >#defineCONFIG_SYS_MONITOR_END(CONFIG_SYS_MONITOR_BASE + > CONFIG_SYS_MONITOR_LEN) >#defineCONFIG_SYS_MALLOC_LENSIZE >#defineCONFIG_SYS_MALLOC_BASE(CONFIG_SYS_MONITOR_BASE - > CONFIG_SYS_MALLOC_LEN) > >/* stack */ >#defineCONFIG_SYS_INIT_SP_OFFSETCONFIG_SYS_MONITOR_BASE > > > This builds a memory map like the following: > >0x47f8 - 0x47fb: malloc region >0x47fc - 0x477f: monitor >0x4780 - 0x47ff: globals > > The initial SP is set to 0x47fc. This collides with the malloc > region, and when the malloc region is cleared during mem_malloc_init(), > the stack is wiped out. This includes the return address from > mem_malloc_init(), among other things. > > Can you confirm that CONFIG_SYS_INIT_SP_OFFSET should be > CONFIG_SYS_MALLOC_BASE instead of CONFIG_SYS_MONITOR_BASE? That agrees > with your memory diagram at include/configs/microblaze-generic.h:103. yes, you are correct. Please create proper patch and I will add it to mainline. Thanks, Michal > > thanks, > Graeme -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix debug output.
your subject line really needs a prefix to narrow down where exactly your fix is going. it also should not have a period. net: dm9000x: fix debug output -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix debug output.
Mike Frysinger schrieb: > your subject line really needs a prefix to narrow down where exactly your fix > is going. it also should not have a period. > > net: dm9000x: fix debug output > -mike > Hello, should i resend the patch with the corrected subject line? Thomas signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix debug output.
Dear Thomas Weber,
In message <1260177679-18337-1-git-send-email-we...@corscience.de> you wrote:
> Signed-off-by: Thomas Weber
> ---
> drivers/net/dm9000x.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
> index 73dd335..08bd794 100644
> --- a/drivers/net/dm9000x.c
> +++ b/drivers/net/dm9000x.c
> @@ -74,8 +74,8 @@ TODO: external MII is not functional, only internal at the
> moment.
> #define DM9000_DBG(fmt,args...) printf(fmt, ##args)
> #define DM9000_DMP_PACKET(func,packet,length) \
> do { \
> - int i; \
> - printf(func ": length: %d\n", length); \
> + int i; \
> + printf("%s: length: %d\n",func, length);
> \
> for (i = 0; i < length; i++) { \
> if (i % 8 == 0) \
> printf("\n%s: %02x: ", func, i);\
Which problem is this supposed to fix?
Actually this patch introduces two new issues (the "int i;" line uses
spaces for indentation, and the '\' are not vertically aligned any
more).
NAK.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A girl with a future avoids the man with a past.
-- Evan Esar, "The Humor of Humor"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix debug output.
Dear Thomas Weber, In message <4b1ce6a5.3080...@corscience.de> you wrote: > > should i resend the patch with the corrected subject line? No, because it needs other fixes (and explanations) anyway. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are no data that cannot be plotted on a straight line if the axis are chosen correctly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Breakage on arm/next
Hi Scott,
> Are they going to be the same on all boards? We let the
> board determine the environment location for other types of storage.
>
OK
> How about just using CONFIG_ENV_ADDR/CONFIG_ENV_SIZE? On
> boards that must dynamically support multiple possibilities,
> define it as an expression that returns the right thing.
>
If the macros are not favoured to get consensus , let the code
use CONFIG_ENV_ADDR/CONFIG_ENV_SIZE and incase of Flex-OneNAND
increase it by one more fold.
something Like
Hunk 1:
env_addr = CONFIG_ENV_ADDR;
+ if (FLEXONENAND(this))
+ env_addr <<= 1;
Hunk 2:
+ if (FLEXONENAND(this)) {
+ env_addr <<= 1;
+ instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ?
+ 2 : 1;
+ }
This should not break any other Board with OneNAND support. Please comment.
(Somehow I still feel Macros can be Cleaner way.)
With Regards
Moorthy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix debug output.
Wolfgang Denk schrieb:
> Dear Thomas Weber,
>
> In message <1260177679-18337-1-git-send-email-we...@corscience.de> you wrote:
>
>> Signed-off-by: Thomas Weber
>> ---
>> drivers/net/dm9000x.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
>> index 73dd335..08bd794 100644
>> --- a/drivers/net/dm9000x.c
>> +++ b/drivers/net/dm9000x.c
>> @@ -74,8 +74,8 @@ TODO: external MII is not functional, only internal at the
>> moment.
>> #define DM9000_DBG(fmt,args...) printf(fmt, ##args)
>> #define DM9000_DMP_PACKET(func,packet,length) \
>> do { \
>> -int i; \
>> -printf(func ": length: %d\n", length); \
>> +int i; \
>> +printf("%s: length: %d\n",func, length);
>> \
>> for (i = 0; i < length; i++) { \
>> if (i % 8 == 0) \
>> printf("\n%s: %02x: ", func, i);\
>>
>
> Which problem is this supposed to fix?
>
> Actually this patch introduces two new issues (the "int i;" line uses
> spaces for indentation, and the '\' are not vertically aligned any
> more).
>
> NAK.
>
> Best regards,
>
> Wolfgang Denk
>
>
Hello,
In commit 60f61e6d7655400bb785a2ef637581679941f6d1 the following calls
where changed.
- DM9000_DMP_PACKET("eth_send", packet, length);
+ DM9000_DMP_PACKET(__func__ , packet, length);
- DM9000_DMP_PACKET("eth_rx", rdptr, RxLen);
+ DM9000_DMP_PACKET(__func__ , rdptr, RxLen);
The identifier __func__ is used to call this macro. Formerly it was a
string "eth_send" for the function name.
printf("eth_send" ":length ...") worked, but printf(__func__ ":length
...") doesn't compile. (tested with gcc-4.4.1)
Sorry, for space and it was the wrong tab space :(
Best Regards.
Thomas Weber
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Stop stack clobbering in microblaze-generic.
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 --- include/configs/microblaze-generic.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index b486c77..9b1569a 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -146,7 +146,7 @@ #defineCONFIG_SYS_MALLOC_BASE (CONFIG_SYS_MONITOR_BASE - CONFIG_SYS_MALLOC_LEN) /* stack */ -#defineCONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_MONITOR_BASE +#defineCONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_MALLOC_BASE /*#define RAMENV */ #defineFLASH -- 1.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, REGRESSION] mpc83xx: provide option to set LCRR early
On Sat, 5 Dec 2009 21:27:30 +0100 Peter Korsgaard wrote: > > "Kim" == Kim Phillips writes: > > Kim> On Fri, 20 Nov 2009 12:42:43 +0100 > Kim> Peter Korsgaard wrote: > > >> E.G. on a 8347 board a bootup time increase of ~600ms has been observed: > > Kim> heh, even more on an 8313! Thanks for this - I hadn't realized the > Kim> difference was so large (or neglected it since the move to init_r was > Kim> done at the last moment). > > OK, why exactly was it moved? What do you want to protect against? I > don't remember seing anyone complaining about the old location. none, really. Just safety from any potential unknown behaviour: http://lists.denx.de/pipermail/u-boot/2009-September/061580.html > >> Fix it by introducing CONFIG_SYS_LCRR_EARLY, and set LCRR in cpu_init_f > >> instead of in cpu_init_r if set. > > Kim> instead of introducing the new CONFIG_SYS_LCRR_EARLY, shouldn't we > Kim> check for something like: > > Kim> !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SYS_RAMBOOT) > > As in do the reconfig early if we're running from RAM right away? > It's not that simple - I have a board which boots from NOR flash. As > that is an async device there isn't any problem in changing the LBC > settings while you're running from flash (as long as you respect the > min access time). I have another design where the flash sits behind a > FPGA (for signal integrity reasons), and there I have to wait until > we're running in RAM before changing the LBC clock. > > On the 2nd design I even have to tell the FPGA to resync (through a GPIO > pin) and wait a bit before I can continue, so I'm doing the LCRR config > in board code (in board_early_init_r). The move to cpu_init_r broke that > as well as the LCRR value is overwritten there. ok let's leave it as _EARLY then. wrt boards in current u-boot, can you add the _EARLY define in their default config files? I'm trying to extend the benefit of the patch to existing boards, not only out-of-tree boards. Speaking of which, new board patches are welcome. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Breakage on arm/next
apgmoorthy wrote:
> Hi Scott,
>
>> Are they going to be the same on all boards? We let the
>> board determine the environment location for other types of storage.
>>
> OK
>
>> How about just using CONFIG_ENV_ADDR/CONFIG_ENV_SIZE? On
>> boards that must dynamically support multiple possibilities,
>> define it as an expression that returns the right thing.
>>
>
> If the macros are not favoured to get consensus , let the code
> use CONFIG_ENV_ADDR/CONFIG_ENV_SIZE and incase of Flex-OneNAND
> increase it by one more fold.
>
> something Like
>
> Hunk 1:
>env_addr = CONFIG_ENV_ADDR;
>+ if (FLEXONENAND(this))
>+ env_addr <<= 1;
>
> Hunk 2:
> + if (FLEXONENAND(this)) {
> + env_addr <<= 1;
> + instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ?
> + 2 : 1;
> + }
>
> This should not break any other Board with OneNAND support. Please comment.
> (Somehow I still feel Macros can be Cleaner way.)
Why is the address automatically doubled on flex? I think this really
needs to be something board-specified.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards
Dear Matthias Kaehlcke,
In message <20091206145444.ge22...@darwin> you wrote:
> Add support for the Cirrus EP93xx platform and EDB93xx boards
In addition to Tom's comments:
> @@ -2429,6 +2429,42 @@ TQM834x_config:unconfig
> vme8349_config: unconfig
> @$(MKCONFIG) $(@:_config=) ppc mpc83xx vme8349 esd
>
> +edb93xx_config \
> +edb9301_config \
> +edb9302_config \
> +edb9302a_config \
> +edb9307_config \
> +edb9307a_config \
> +edb9315a_config: unconfig
Keep all such lists sorted!
> + @if [ "$(findstring 01_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9301" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 02_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9302" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 02a_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9302A" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 07_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9307" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 07a_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9307A" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 12_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9312" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 15_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9315" >> $(obj)include/config.h
> ; \
> + elif [ "$(findstring 15a_,$@)" ] ; then \
> + echo "#defineCONFIG_EDB9315A" >> $(obj)include/config.h
> ; \
> + fi ;
Please don't do scripting in the Makefile. Move this logic into your
board config file instead.
> + @$(MKCONFIG) -a edb93xx arm arm920t edb93xx NULL ep93xx
> + @if [ "$(findstring 01_,$@)" ] || [ "$(findstring 02_,$@)" ]; then \
> + echo "TEXT_BASE = 0x0540" >> $(obj)include/config.mk ; \
> + elif [ "$(findstring 02a_,$@)" ]; then \
> + echo "TEXT_BASE = 0xc540" >> $(obj)include/config.mk ; \
> + elif [ "$(findstring 07_,$@)" ] || [ "$(findstring 12_,$@)" ] || [
> "$(findstring 15_,$@)" ]; then \
> + echo "TEXT_BASE = 0x01f0" >> $(obj)include/config.mk ; \
> + elif [ "$(findstring 07a_,$@)" ] || [ "$(findstring 15a_,$@)" ]; then \
> + echo "TEXT_BASE = 0xc1f0" >> $(obj)include/config.mk ; \
> + fi ;
Ditto.
> + /* Machine number, as defined in linux/arch/arm/tools/mach-types
> + */
> +#ifdef CONFIG_EDB9301
> + gd->bd->bi_arch_number = 462;
> +#elif defined(CONFIG_EDB9302)
> + gd->bd->bi_arch_number = 538;
> +#elif defined(CONFIG_EDB9302A)
> + gd->bd->bi_arch_number = 1127;
> +#elif (defined CONFIG_EDB9307)
> + gd->bd->bi_arch_number = 607;
> +#elif (defined CONFIG_EDB9307A)
> + gd->bd->bi_arch_number = 1128;
> +#elif defined(CONFIG_EDB9312)
> + gd->bd->bi_arch_number = 451;
> +#elif defined(CONFIG_EDB9315)
> + gd->bd->bi_arch_number = 463;
> +#elif defined(CONFIG_EDB9315A)
> + gd->bd->bi_arch_number = 772;
> +#endif
Please use symbolic constants from , and move the
logic into your board config file.
> +int dram_init(void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> + unsigned int *src, *dst;
> + int i;
> +
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE_1;
> +
> +#ifdef PHYS_SDRAM_2
> + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> + gd->bd->bi_dram[1].size = PHYS_SDRAM_SIZE_2;
> +#endif
> +
> +#ifdef PHYS_SDRAM_3
> + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> + gd->bd->bi_dram[2].size = PHYS_SDRAM_SIZE_3;
> +#endif
> +
> +#ifdef PHYS_SDRAM_4
> + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> + gd->bd->bi_dram[3].size = PHYS_SDRAM_SIZE_4;
> +#endif
Make sure to use get_ram_size() on all banks for checking and
auto-sizing.
> diff --git a/board/edb93xx/flash_cfg.S b/board/edb93xx/flash_cfg.S
> new file mode 100644
> index 000..aa61a3c
> --- /dev/null
> +++ b/board/edb93xx/flash_cfg.S
...
> +.globl flash_cfg
> +flash_cfg:
> + /* configure smc bank 6 (Intel TE28F128J3D75 Strata Flash)
> + * ebibrkdis: 0, mw: 0x1 (16 bit), pme: 0, wp: 0, wst2: 2(+1),
> + * wst1: 5(+1), rble: 1, idcy: 2(+1)
> + * TODO: we don't enable page mode for now
> + */
> + ldr r0, =SMC_BCR6
> +
> + ldr r1, =(2 << SMC_BCR_IDCY_SHIFT | 5 << SMC_BCR_WST1_SHIFT | \
> + SMC_BCR_BLE | 2 << SMC_BCR_WST2_SHIFT | 1 << SMC_BCR_MW_SHIFT)
> +
> + str r1, [r0]
> +
> + mov pc, lr
Why is this written in assembler? Please rewrite in C.
> diff --git a/board/edb93xx/pll_cfg.S b/board/edb93xx/pll_cfg.S
> new file mode 100644
> index 000..ae69a7d
> --- /dev/null
> +++ b/board/edb93xx/pll_cfg.S
> @@ -0,0 +1,93 @@
...
> + /* the user's guide recommends to wait at least 1 ms for PLL2 to
> + * stabilize, but Cirrus' Redboot doesn't do that, either
> + */
> +
> + mov pc, lr
Why don't you
Re: [U-Boot] [PATCH] Fix debug output.
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("eth_send", packet, length);
> + DM9000_DMP_PACKET(__func__ , packet, length);
>
> - DM9000_DMP_PACKET("eth_rx", rdptr, RxLen);
> + DM9000_DMP_PACKET(__func__ , rdptr, RxLen);
>
> The identifier __func__ is used to call this macro. Formerly it was a
> string "eth_send" for the function name.
>
> printf("eth_send" ":length ...") worked, but printf(__func__ ":length
> ...") doesn't compile. (tested with gcc-4.4.1)
Well, and exactly this is valuable information which should be
included into the commit message.
Indeed, neither __func__ nor __FUNCTION__ can be concatenated; for
some reason gcc seems to consider these as strings, but not as string
constants. Dunno why; probably there is a good reason for this, but
it looks stupid to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is CONFIG_DATAFLASH_MMC_SELECT actually being used anywhere?
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 can see the commit that did a rename: > > commit 90a92a708d5180a20d600ba0fc2352ec76dc3829 > Author: Jean-Christophe PLAGNIOL-VILLARD > Date: Fri Mar 27 23:26:42 2009 +0100 > > at91: rename DATAFLASH_MMC_SELECT to CONFIG_DATAFLASH_MMC_SELECT > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > > but unless *someone* defines that macro, is it doing anything useful? > or am i just confused? Eventually JC had some patches on his famous stack before he threw in the towel. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I will not say that women have no character; rather, they have a new one every day. -- Heine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] why is the compilation of cmd_pcmcia.c hardcoded?
Dear "Robert P. J. Day", In message you wrote: > > i'm curious as to why common/Makefile hardcodes the compilation of > cmd_pcmcia.c thusly: Historic / hysteric reasons? Please feel free to submit cleanup patches! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only thing necessary for the triumph of evil is for good men to do nothing.- Edmund Burke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix nfs symlink name corruption
Dear Ed Swarthout, In message <1258620448-20960-1-git-send-email-ed.swarth...@freescale.com> you wrote: > An off by one error may cause nfs readlink lookup fail if > nfs_path_buff has non-zero data from a previous use. > > Loading: *** ERROR: File lookup fail > > Signed-off-by: Ed Swarthout > --- > net/nfs.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Ben, I hope this is OK with you. Looked obvious to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't understand it. I can't even understand the people who can understand it.- Queen Juliana of the Netherlands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] difference between V_PROMPT and CONFIG_SYS_PROMPT?
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_PROMPT (which probably should be renamed into CONFIG_PROMPT) is an official, documented configuration option, while V_PROMPT is a private and apparently redundant definition that should be removed. Cleanup patches welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quantum Mechanics is God's version of "Trust me." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix nfs symlink name corruption
Wolfgang Denk wrote: > Dear Ed Swarthout, > > In message <1258620448-20960-1-git-send-email-ed.swarth...@freescale.com> you > wrote: > >> An off by one error may cause nfs readlink lookup fail if >> nfs_path_buff has non-zero data from a previous use. >> >> Loading: *** ERROR: File lookup fail >> >> Signed-off-by: Ed Swarthout >> --- >> net/nfs.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> > > Applied. > > Ben, I hope this is OK with you. Looked obvious to me. > > Best regards, > > Wolfgang Denk > > Fine with me. Thanks for taking care of this. Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nfs: NfsTimeout() updates
Dear Peter Tyser, In message <1257818916-30673-1-git-send-email-pty...@xes-inc.com> you wrote: > From: Evan Samanas > > - NfsTimeout() does not correctly update the NFS timeout value which > results in NfsTimeout() only being called once in certain situations. > This can result in the 'nfs' command hanging indefinetly. For > example, the command: > > nfs 192.168.0.1:/home/user/file > > will not exit until ctrl-c is pressed if 192.168.0.1 does not have an > NFS server running. > > This issue is resolved by reinitializting the NFS timeout value inside > NfsTimeout() when a timeout occurs. > > - Make the 'nfs' command print the 'T' character when a timeout occurs. > Previously there was no indication that timeouts were occuring. > > - Mimic the 'tftpboot' command and when a download fails print "Retry > count exceeded; starting again", and restart the download taking the > 'netretry' environment variable into account. > > Signed-off-by: Evan Samanas > Signed-off-by: Peter Tyser Tested on TQM8xxL. Tested by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I've got a bad feeling about this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x: fix typo in smc911x_handle_mac_address name
Dear Mike Rapoport, In message <1257926592-14782-1-git-send-email-m...@compulab.co.il> you wrote: > Signed-off-by: Mike Rapoport > --- > drivers/net/smc911x.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Ben, this looked so obvious, too. Hope it is OK with you. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always borrow money from a pessimist; they don't expect to be paid back. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] smc911x: update SMC911X related configuration description
Dear Mike Rapoport, In message <6b76074bd24b92947049829d60eff2f5441ac221.1257861401.git.m...@compulab.co.il> you wrote: > Since commit 736fead8fdbf8a8407048bebc373cd551d01ec98 "Convert SMC911X > Ethernet driver to CONFIG_NET_MULTI API" SMC911X configration options > are called CONFIG_SMC911X rather than CONFIG_DRIVER_SMC911X. Update > README to reflect that change. > > Signed-off-by: Mike Rapoport > --- > README | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) Applied, thanks. Ben, I hope this is OK with you. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mpc83xx: Add NAND boot support for MPC8315E-RDB boards
On Tue, 24 Nov 2009 20:12:12 +0300
Anton Vorontsov wrote:
> Here is the updated patch.
>
> MAKEALL |1 +
> Makefile |6 ++-
> board/freescale/mpc8315erdb/config.mk |8 +++
> board/freescale/mpc8315erdb/mpc8315erdb.c | 42 +
> board/freescale/mpc8315erdb/sdram.c |7 ++
> include/configs/MPC8315ERDB.h | 95
> +++--
> 6 files changed, 139 insertions(+), 20 deletions(-)
please add NAND boot instructions to doc/README.mpc8315erdb also.
> diff --git a/MAKEALL b/MAKEALL
> index d63c5c2..821e3e8 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -360,6 +360,7 @@ LIST_83xx=" \
> MPC8313ERDB_33 \
> MPC8313ERDB_NAND_66 \
> MPC8315ERDB \
> + MPC8315ERDB_NAND\
> MPC8323ERDB \
> MPC832XEMDS \
> MPC832XEMDS_ATM \
> diff --git a/Makefile b/Makefile
> index bcb3fe9..13c34f8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2291,8 +2291,12 @@ MPC8313ERDB_NAND_66_config: unconfig
> echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk ; \
> fi ;
>
> +MPC8315ERDB_NAND_config \
> MPC8315ERDB_config: unconfig
> - @$(MKCONFIG) -a MPC8315ERDB ppc mpc83xx mpc8315erdb freescale
> + if [ "$(findstring _NAND_,$@)" ] ; then \
missing leading @ - s/if/@if/.
> + ln -sf mpc8313erdb nand_spl/board/freescale/mpc8315erdb ; \
> + fi ;
can we instead permanently rename
nand_spl/board/freescale/mpc8313erdb to mpc831xerdb...argh, probably
not without merging the non-NAND parts also...
> +++ b/board/freescale/mpc8315erdb/mpc8315erdb.c
...
> +void board_init_f(ulong bootflag)
> +{
> + board_early_init_f();
> + NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500),
> + CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);
> + puts("NAND boot... ");
> + init_timebase();
> + initdram(0);
> + relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC + 0x1, (gd_t *)gd,
use CONFIG_SYS_NAND_U_BOOT_RELOC_SP
meanwhile, 8315 NAND boot doesn't build when applied to u-boot's next
branch:
Configuring for MPC8315ERDB board...
sdram.o: In function `fixed_sdram':
/home/r1aaha/git/u-boot/nand_spl/board/freescale/mpc8313erdb/sdram.c:72:
undefined reference to `udelay'
perhaps due to some confusion with setting CONFIG_SYS_RAMBOOT?
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] help: Correct syntax of nandecc help output.
Dear "Robert P. J. Day", In message you wrote: > > "nandecc" help output should not reproduce the command name, nor have > a trailing newline. > > Signed-off-by: Robert P. J. Day Applied, thanks. Tom, Sandeep, I hope this is OK with you. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10" will parse and generate code creating a variable, DO10I, as follows: "DO10I = 1.10" If that doesn't terrify you, it should. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] LAN91C96: Enable NET_MULTI LAN driver
Nishanth, Nishanth Menon wrote: > This modification is NOT tested on any of the > platforms modified as I dont have them. please > help by testing+building+fixing > > Signed-off-by: Nishanth Menon > Cc: Andrea Scian > Cc: Ben Warren > Cc: Dave Peverley > Cc: George G. Davis > Cc: Kyungmin Park > Cc: Nishant Kamat > Cc: Richard Woodruff > Cc: Rishi Bhattacharya > Cc: Sandeep Paulraj > --- > board/apollon/apollon.c | 12 +++- > include/configs/B2.h |2 +- > include/configs/apollon.h |3 ++- > include/configs/assabet.h |3 ++- > include/configs/gcplus.h |3 ++- > include/configs/lubbock.h |3 ++- > include/configs/omap1510inn.h |3 ++- > include/configs/omap1610h2.h |3 ++- > include/configs/omap1610inn.h |3 ++- > include/configs/omap2420h4.h |3 ++- > include/configs/omap5912osk.h |3 ++- > include/configs/omap730p2.h |3 ++- > include/configs/pleb2.h |6 -- > 13 files changed, 32 insertions(+), 18 deletions(-) > You've update the config files for a bunch of boards, but have not added board_eth_init() functions for them. Am I missing something? If this is indeed the case, I can't push these patches upstream from the net tree because the associated boards will break. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] smc911x: update SMC911X related configuration description
Wolfgang Denk wrote: > Dear Mike Rapoport, > > In message > <6b76074bd24b92947049829d60eff2f5441ac221.1257861401.git.m...@compulab.co.il> > you wrote: > >> Since commit 736fead8fdbf8a8407048bebc373cd551d01ec98 "Convert SMC911X >> Ethernet driver to CONFIG_NET_MULTI API" SMC911X configration options >> are called CONFIG_SMC911X rather than CONFIG_DRIVER_SMC911X. Update >> README to reflect that change. >> >> Signed-off-by: Mike Rapoport >> --- >> README | 10 +- >> 1 files changed, 5 insertions(+), 5 deletions(-) >> > > Applied, thanks. > > Ben, I hope this is OK with you. > > Best regards, > > Wolfgang Denk > > Sure. You're making my to-do list smaller, so, yeah it's OK! regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: Fix help message's sub-command ordering
Dear Peter Tyser, In message <1258592939-26376-1-git-send-email-pty...@xes-inc.com> you wrote: > The help message for the 'bootm' command listed the 'cmdline' and 'bdt' > sub-commands in the wrong order which resulted in the error below when > following the 'help' command's instructions: > > "Trying to execute a command out of order" > > Signed-off-by: Peter Tyser > --- > Feel free to apply this for the upcoming release or -next. I don't think > its a big problem as most users don't currently use the bootm > sub-commands. > > common/cmd_bootm.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A girl with a future avoids the man with a past. -- Evan Esar, "The Humor of Humor" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nfs: NfsTimeout() updates
From: Peter Tyser > Sent: Monday, November 09, 2009 8:09 PM > Subject: [U-Boot] [PATCH] nfs: NfsTimeout() updates Tested on MPC8527DS. Tested by: Ed Swarthout ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] Move lib_ directories to lib/
Dear Peter Tyser, In message <1258943983.9357.20.ca...@ptyser-laptop> you wrote: > > My personal preference would be to take it a step further and organize > like: > > /arch/$ARCH/ > /lib/ > /include/asm/ > /cpu/ > /config.mk (old lib_$ARCH/config.mk) > > /lib/ > / > /libfdt/ > /lzma/ > /lzo/ > > This layout would more closely match the Linux layout and is cleaner > overall in my opinion. What do others think of this idea? I generally agree with the idea, with the exception of /include/asm/ - I really hate this change in the Linux kernel, and still fail to see any advantages of this. Except for that, such a change would be OK with me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "What if" is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, REGRESSION] mpc83xx: provide option to set LCRR early
On Mon, 7 Dec 2009 22:10:49 +0100 Peter Korsgaard wrote: > > "Kim" == Kim Phillips writes: > Kim> ok let's leave it as _EARLY then. wrt boards in current u-boot, can > Kim> you add the _EARLY define in their default config files? > > Sure - But if we're adding _EARLY to all the configs, shouldn't we just > make _EARLY default (or simply get rid of the late variant?) probably the latter. Thanks! > Kim> I'm trying to extend the benefit of the patch to existing boards, > Kim> not only out-of-tree boards. Speaking of which, new board patches > Kim> are welcome. > > Also for specialized (E.G. non-evaluation boards / consumer products) > boards? I have no problem submitting them, I just see very limited added > value for others. sure, why not? It allows me and others to see and allow for such real use-cases, plus you get the benefit of not having to maintain patches externally. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nfs: NfsTimeout() updates
Dear Peter Tyser, In message <1257818916-30673-1-git-send-email-pty...@xes-inc.com> you wrote: > From: Evan Samanas > > - NfsTimeout() does not correctly update the NFS timeout value which > results in NfsTimeout() only being called once in certain situations. > This can result in the 'nfs' command hanging indefinetly. For > example, the command: > > nfs 192.168.0.1:/home/user/file > > will not exit until ctrl-c is pressed if 192.168.0.1 does not have an > NFS server running. > > This issue is resolved by reinitializting the NFS timeout value inside > NfsTimeout() when a timeout occurs. > > - Make the 'nfs' command print the 'T' character when a timeout occurs. > Previously there was no indication that timeouts were occuring. > > - Mimic the 'tftpboot' command and when a download fails print "Retry > count exceeded; starting again", and restart the download taking the > 'netretry' environment variable into account. > > Signed-off-by: Evan Samanas > Signed-off-by: Peter Tyser > --- > net/nfs.c | 11 ++- > 1 files changed, 6 insertions(+), 5 deletions(-) Applied, thanks. Ben, I hope ... etc. :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's another way to survive. Mutual trust -- and help. -- Kirk, "Day of the Dove", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, REGRESSION] mpc83xx: provide option to set LCRR early
> "Kim" == Kim Phillips writes: Hi, Kim> ok let's leave it as _EARLY then. wrt boards in current u-boot, can Kim> you add the _EARLY define in their default config files? Sure - But if we're adding _EARLY to all the configs, shouldn't we just make _EARLY default (or simply get rid of the late variant?) Kim> I'm trying to extend the benefit of the patch to existing boards, Kim> not only out-of-tree boards. Speaking of which, new board patches Kim> are welcome. Also for specialized (E.G. non-evaluation boards / consumer products) boards? I have no problem submitting them, I just see very limited added value for others. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix computation in nand_util.c:get_len_incl_bad
Dear Daniel Hobi,
In message <1259672755-929-1-git-send-email-daniel.h...@schmid-telecom.ch> you
wrote:
> Depending on offset, flash size and the number of bad blocks,
> get_len_incl_bad may return a too small value which may lead to:
>
> 1) If there are no bad blocks, nand_{read,write}_skip_bad chooses the
> bad block aware read/write code. This may hurt performance, but does
> not have any adverse effects.
>
> 2) If there are bad blocks, the nand_{read,write}_skip_bad may choose
> the bad block unaware read/write code (if len_incl_bad == *length)
> which leads to corrupted data.
>
> Signed-off-by: Daniel Hobi
> ---
> @Scott: please review
> @Wolfgang: please consider for 2009.11
>
> diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Intelligence without character is a dangerous thing." - G. Steinem
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 52xx, manroland: add fdt_fixup_memory() in ft_board_setup()
Dear Heiko Schocher, In message <4b1560d7.5020...@denx.de> you wrote: > To update the real memory size in the memory node on the > uc101 and mucmc52 boards call fdt_fixup_memory() in > ft_board_setup(). > > Signed-off-by: Heiko Schocher > --- > board/mucmc52/mucmc52.c |2 ++ > board/uc101/uc101.c |2 ++ > 2 files changed, 4 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What's the sound a name makes when it's dropped? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] Move lib_ directories to lib/
Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1258943983.9357.20.ca...@ptyser-laptop> you wrote: >> My personal preference would be to take it a step further and organize >> like: >> >> /arch/$ARCH/ >> /lib/ >> /include/asm/ >> /cpu/ >> /config.mk (old lib_$ARCH/config.mk) >> >> /lib/ >> / >> /libfdt/ >> /lzma/ >> /lzo/ >> >> This layout would more closely match the Linux layout and is cleaner >> overall in my opinion. What do others think of this idea? > > I generally agree with the idea, with the exception of > /include/asm/ - I really hate this change in the Linux > kernel, and still fail to see any advantages of this. I really like only having one subtree to grep for arch stuff, and it would avoid presenting files that are in git, under a path that git doesn't know about. Plus, the symlink is one less thing that the makefiles would need to keep in sync when arch changes. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] POST: Remove duplicated post_hotkey_pressed() functions
Dear Stefan Roese, In message <1259817870-32585-1-git-send-email...@denx.de> you wrote: > This patch introduces a weak default function for post_hotkey_pressed(), > returning 0, for boards without hotkey support. The long-running tests > won't be started on those boards. This default function was implemented > in many board directories. By implementing this weak default we can > remove all those duplicate versions. > > Boards with hotkey support, can override this weak default function > by defining one in their board specific code. > > Signed-off-by: Stefan Roese > --- > v2: > - Rebased on next again > > board/amcc/katmai/katmai.c| 11 --- > board/amcc/kilauea/kilauea.c | 11 --- > board/amcc/makalu/makalu.c| 11 --- > board/amcc/ocotea/ocotea.c| 12 > board/amcc/sequoia/sequoia.c | 11 --- > board/amcc/taishan/taishan.c | 11 --- > board/amcc/yucca/yucca.c | 11 --- > board/cm5200/cm5200.c |8 > board/esd/pmc440/pmc440.c | 11 --- > board/gen860t/gen860t.c | 11 --- > board/korat/korat.c | 11 --- > board/kup/common/kup.c| 11 --- > board/mpl/mip405/mip405.c | 11 --- > board/netstal/hcu4/hcu4.c | 11 --- > board/netstal/hcu5/hcu5.c | 11 --- > board/netstal/mcu25/mcu25.c | 11 --- > board/netta/netta.c | 11 --- > board/prodrive/alpr/alpr.c| 12 > board/sacsng/sacsng.c | 12 > board/ssv/adnpesc1/adnpesc1.c | 11 --- > board/uc100/uc100.c | 12 > post/post.c | 16 > 22 files changed, 16 insertions(+), 232 deletions(-) Applied to "next", thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A little knowledge is a dangerous thing."- Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH, REGRESSION] mpc83xx: provide option to set LCRR early
> "Kim" == Kim Phillips writes: Hi, >> Sure - But if we're adding _EARLY to all the configs, shouldn't we just >> make _EARLY default (or simply get rid of the late variant?) Kim> probably the latter. Thanks! Great - I'll send an updated patch just doing that then instead. >> Also for specialized (E.G. non-evaluation boards / consumer products) >> boards? I have no problem submitting them, I just see very limited added >> value for others. Kim> sure, why not? It allows me and others to see and allow for such real Kim> use-cases, plus you get the benefit of not having to maintain patches Kim> externally. Ok. I'll sort out what to do with the ancient board/barco directory that already is in the tree, and then submit board/barco/. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] LAN91C96: Enable NET_MULTI LAN driver
Ben Warren had written, on 12/07/2009 03:09 PM, the following: > Nishanth, > > Nishanth Menon wrote: >> This modification is NOT tested on any of the >> platforms modified as I dont have them. please >> help by testing+building+fixing >> >> Signed-off-by: Nishanth Menon >> Cc: Andrea Scian >> Cc: Ben Warren >> Cc: Dave Peverley >> Cc: George G. Davis >> Cc: Kyungmin Park >> Cc: Nishant Kamat >> Cc: Richard Woodruff >> Cc: Rishi Bhattacharya >> Cc: Sandeep Paulraj >> --- >> board/apollon/apollon.c | 12 +++- >> include/configs/B2.h |2 +- >> include/configs/apollon.h |3 ++- >> include/configs/assabet.h |3 ++- >> include/configs/gcplus.h |3 ++- >> include/configs/lubbock.h |3 ++- >> include/configs/omap1510inn.h |3 ++- >> include/configs/omap1610h2.h |3 ++- >> include/configs/omap1610inn.h |3 ++- >> include/configs/omap2420h4.h |3 ++- >> include/configs/omap5912osk.h |3 ++- >> include/configs/omap730p2.h |3 ++- >> include/configs/pleb2.h |6 -- >> 13 files changed, 32 insertions(+), 18 deletions(-) >> > You've update the config files for a bunch of boards, but have not added > board_eth_init() functions for them. Am I missing something? If this > is indeed the case, I can't push these patches upstream from the net > tree because the associated boards will break. I have added the init where they have been previously used for the old lan91c96 driver. I think the only one which was actively using it was apollon, which means the rest of the platforms probably dont use the old lan driver properly in the first place. I have maintained status quo there instead of introducing a change which may break them. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
I generally agree with this patch, but...
> --- a/board/cm5200/cm5200.c
> +++ b/board/cm5200/cm5200.c
> @@ -271,13 +271,6 @@ static void ft_blob_update(void *blob, bd_t *bd)
> if (ret < 0)
> printf("ft_blob_update(): cannot set /model property err:%s\n",
> fdt_strerror(ret));
> -
> - ret = fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
> -
> - if (ret < 0) {
> - printf("ft_blob_update(): cannot set /memory/reg "
> - "property err:%s\n", fdt_strerror(ret));
> - }
Here we do some error checking, which is always a Good Thing (TM).
> diff --git a/cpu/mpc512x/cpu.c b/cpu/mpc512x/cpu.c
> index 42ccd81..dac48db 100644
> --- a/cpu/mpc512x/cpu.c
> +++ b/cpu/mpc512x/cpu.c
> @@ -197,6 +197,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> #ifdef CONFIG_HAS_ETH0
> fdt_fixup_ethernet(blob);
> #endif
> + fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
> }
> #endif
>
> diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c
> index efa64c7..2a28df4 100644
> --- a/cpu/mpc5xxx/cpu.c
> +++ b/cpu/mpc5xxx/cpu.c
> @@ -157,6 +157,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> }
>
> #endif
> + fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
> }
> #endif
May I suggest to add the same error checking in these two files, then?
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
-- J. Finnegan, USC.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][for next] mpc52xx, manroland: add some commands
Dear Heiko Schocher, In message <4b1790fa.10...@denx.de> you wrote: > add the following commands for the manroland boards: > > CONFIG_CMDLINE_EDITING > CONFIG_COMMAND_HISTORY > CONFIG_AUTO_COMPLETE > > Signed-off-by: Heiko Schocher > --- > based against git://git.denx.de/u-boot.git next > > include/configs/manroland/common.h |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Applied to "next", thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED Mini V2 board
Dear Albert ARIBAUD,
In message <4b1a05a9.4040...@free.fr> you wrote:
>
> > No, this is not correct. get_ram_size() is used always on a single
> > bank of memory only.
>
> Do you mean calling get_ram_size() four up to times based on the
> configured number of banks and configured sizes? I then fail to see the
Yes, exactly.
> added value of get_ram_size() wrt using the configured sizes directly.
The added value is that get_ram_size() will detect (1) a lot of common
error situations and (2) will detect the actual size of the respective
memory banks.
Assume you have a system where differentt types of memory chips can be
fit, or where you can insert memory modules. Then you configure for
the largest possible type, and get_ram_size() will detect what's
really present, so you can adjust the configuration. See the README
for details.
> >> However I realize that this code is actually SoC-specific, not
> >> board-specific. It could be moved in cpu/arm926ejs/orion5x/dram.c, and
> >> then orion5x_sdram_{bar,bs} could be made static (or inlined).
> >>
> >> What do you think?
> >
> > Seems to make sense.
>
> All right. Does doing that lift the requirement to use get_ram_size()?
I see no reason yet why you would not want to use get_ram_size() - the
memory test feature alone is useful enough, even if you never intend
to use different RAM sizes.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Build a system that even a fool can use and only a fool will want to
use it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: fix dangling comment in do_i2c_mw()
Dear Heiko Schocher, In message <4b1a3d27.90...@denx.de> you wrote: > commit bd3784df94bfeca43fbf34094df9cb1bd3ecca3b delete > some unused code in do_i2c_mw(), but missed to fix the > inherent commment. This patch fix this comment. > > Signed-off-by: Heiko Schocher > --- > common/cmd_i2c.c |4 > 1 files changed, 0 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The optimum committee has no members. - Norman Augustine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/mkimage: Remove duplicate line of code
Dear Peter Tyser, In message <1260084804-11229-1-git-send-email-pty...@xes-inc.com> you wrote: > Recent commits 1a99de2cb4d08eb3bf9fb3f60a9d533150de8c0e and > 6a590c5f5fd12cdd27f3153522acfac3854590e7 both fixed the same bug in the > same manner. Unfortunately git was "smart" enough to merge both changes > which resulted in some duplicate code. > > Signed-off-by: Peter Tyser > --- > tools/mkimage.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) Thanks, applied - but I decided to reorder the code and comment a bit. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Children are natural mimics who act like their parents despite every effort to teach them good manners. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: Fix return value
Dear Peter Tyser,
In message <1260165508-10052-1-git-send-email-pty...@xes-inc.com> you wrote:
> Previously MAKEALL would always return a value of 0, even if 1 or more
> boards did not compile. This change causes MAKEALL to return 0 if all
> boards were able to build, otherwise 1.
>
> This change also requires changing the script interpreter from sh to
> bash to support bash's PIPESTATUS variable.
>
> Signed-off-by: Peter Tyser
> ---
> Changes since v1:
> - Return only 0 or 1
>
> Mike pointed out that if we want to maintain POSIX compliance we could
> replace the PIPESTATUS usage with:
> # need to maintain exit value ourselves as pipes eat it
> fail=${LOG_DIR}/$target.failed
> rm -f ${fail}
> (${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
> || touch ${fail}) | tee ${LOG_DIR}/$target.ERR
> [ -e ${fail} ] && RC=1
> rm -f ${fail}
>
> Let me know if others prefer POSIX compliance over the more straight-
> forward PIPESATUS usage.
For me, bash is just fine here. Looks more readable and does without
additional temp files.
> MAKEALL | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I will also, for an appropriate fee, certify that your keyboard is
object-oriented, and that the bits on your hard disk are template-
compatible.- Jeffrey S. Haemer in <411akr$...@cygnus.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2009.11-rc2 is out - please help testing!
Hi all, U-Boot v2009.11-rc2 has just been released. >From now we are in strict bug-fix mode, i. e. no new stuff will go into this release any more. If no major show stppers pop up I intend to release v2009.11 in a week from now, i. e. on Dec 14. Please help testing! Note: The "next" branch has also been synced against v2009.11-rc2. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager. - T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Stop stack clobbering in microblaze-generic.
Dear Michal, In message <1260202197-1949-1-git-send-email-graeme.smec...@mail.mcgill.ca> you 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 > --- > include/configs/microblaze-generic.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Please send a pull request if you want this to go into v2009.11 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The universe does not have laws - it has habits, and habits can be broken. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards
hi wolfgang,
thanks a lot for you review, below some comments and questions
El Mon, Dec 07, 2009 at 08:46:29PM +0100 Wolfgang Denk ha dit:
> In message <20091206145444.ge22...@darwin> you wrote:
> > Add support for the Cirrus EP93xx platform and EDB93xx boards
>
> In addition to Tom's comments:
>
> > @@ -2429,6 +2429,42 @@ TQM834x_config: unconfig
> > vme8349_config:unconfig
> > @$(MKCONFIG) $(@:_config=) ppc mpc83xx vme8349 esd
> >
> > +edb93xx_config \
> > +edb9301_config \
> > +edb9302_config \
> > +edb9302a_config \
> > +edb9307_config \
> > +edb9307a_config \
> > +edb9315a_config: unconfig
>
> Keep all such lists sorted!
ok
> > + @if [ "$(findstring 01_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9301" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 02_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9302" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 02a_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9302A" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 07_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9307" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 07a_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9307A" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 12_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9312" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 15_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9315" >> $(obj)include/config.h
> > ; \
> > + elif [ "$(findstring 15a_,$@)" ] ; then \
> > + echo "#defineCONFIG_EDB9315A" >> $(obj)include/config.h
> > ; \
> > + fi ;
>
> Please don't do scripting in the Makefile. Move this logic into your
> board config file instead.
i got the inspiration to handle it this way from the U-Boot Makefile
(Total5100, TQM5200, et al). could you please point me to an example
of a well done multi-board configuration file?
> > + @$(MKCONFIG) -a edb93xx arm arm920t edb93xx NULL ep93xx
> > + @if [ "$(findstring 01_,$@)" ] || [ "$(findstring 02_,$@)" ]; then \
> > + echo "TEXT_BASE = 0x0540" >> $(obj)include/config.mk ; \
> > + elif [ "$(findstring 02a_,$@)" ]; then \
> > + echo "TEXT_BASE = 0xc540" >> $(obj)include/config.mk ; \
> > + elif [ "$(findstring 07_,$@)" ] || [ "$(findstring 12_,$@)" ] || [
> > "$(findstring 15_,$@)" ]; then \
> > + echo "TEXT_BASE = 0x01f0" >> $(obj)include/config.mk ; \
> > + elif [ "$(findstring 07a_,$@)" ] || [ "$(findstring 15a_,$@)" ]; then \
> > + echo "TEXT_BASE = 0xc1f0" >> $(obj)include/config.mk ; \
> > + fi ;
same here, further i don't understand how to set the TEXT_BASE from
the board configuration file. any pointer?
> > + /* Machine number, as defined in linux/arch/arm/tools/mach-types
> > +*/
> > +#ifdef CONFIG_EDB9301
> > + gd->bd->bi_arch_number = 462;
> > +#elif defined(CONFIG_EDB9302)
> > + gd->bd->bi_arch_number = 538;
> > +#elif defined(CONFIG_EDB9302A)
> > + gd->bd->bi_arch_number = 1127;
> > +#elif (defined CONFIG_EDB9307)
> > + gd->bd->bi_arch_number = 607;
> > +#elif (defined CONFIG_EDB9307A)
> > + gd->bd->bi_arch_number = 1128;
> > +#elif defined(CONFIG_EDB9312)
> > + gd->bd->bi_arch_number = 451;
> > +#elif defined(CONFIG_EDB9315)
> > + gd->bd->bi_arch_number = 463;
> > +#elif defined(CONFIG_EDB9315A)
> > + gd->bd->bi_arch_number = 772;
> > +#endif
>
> Please use symbolic constants from , and move the
> logic into your board config file.
ok
> > +int dram_init(void)
> > +{
> > + DECLARE_GLOBAL_DATA_PTR;
> > + unsigned int *src, *dst;
> > + int i;
> > +
> > + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> > + gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE_1;
> > +
> > +#ifdef PHYS_SDRAM_2
> > + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> > + gd->bd->bi_dram[1].size = PHYS_SDRAM_SIZE_2;
> > +#endif
> > +
> > +#ifdef PHYS_SDRAM_3
> > + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> > + gd->bd->bi_dram[2].size = PHYS_SDRAM_SIZE_3;
> > +#endif
> > +
> > +#ifdef PHYS_SDRAM_4
> > + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> > + gd->bd->bi_dram[3].size = PHYS_SDRAM_SIZE_4;
> > +#endif
>
> Make sure to use get_ram_size() on all banks for checking and
> auto-sizing.
ok
> > diff --git a/board/edb93xx/flash_cfg.S b/board/edb93xx/flash_cfg.S
> > new file mode 100644
> > index 000..aa61a3c
> > --- /dev/null
> > +++ b/board/edb93xx/flash_cfg.S
> ...
> > +.globl flash_cfg
> > +flash_cfg:
> > + /* configure smc bank 6 (Intel TE28F128J3D75 Strata Flash)
> > +* ebibrkdis: 0, mw: 0x1 (16 bit), pme: 0, wp: 0, wst2: 2(+1),
> > +* wst1: 5(+1), rble: 1, idcy: 2(+1)
> > +* TODO: we don't enable page mode for now
> > +*/
> > + ldr r0, =SMC_BCR6
> > +
> > + ldr r1, =(2 << SMC_BCR_IDCY_SHIFT | 5 << SMC_BCR_WST1_SHIFT | \
> > +
Re: [U-Boot] [PATCH] ARM: Add support for edb93xx boards
Dear Matthias Kaehlcke, In message <20091207233313.ga31...@darwin> you wrote: > > > Please don't do scripting in the Makefile. Move this logic into your > > board config file instead. > > i got the inspiration to handle it this way from the U-Boot Makefile > (Total5100, TQM5200, et al). could you please point me to an example > of a well done multi-board configuration file? This is the old style, which we want to get rid of. See for example here: 2439 MPC8536DS_NAND_config \ 2440 MPC8536DS_SDCARD_config \ 2441 MPC8536DS_SPIFLASH_config \ 2442 MPC8536DS_36BIT_config \ 2443 MPC8536DS_config: unconfig 2444 @$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale > same here, further i don't understand how to set the TEXT_BASE from > the board configuration file. any pointer? See for example board/freescale/mpc8536ds/config.mk > > 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 feet wet with low level initialization and > supposed sdram setup is always done in assembler. There is no reason for assembly. We almost always do this in C. > > > diff --git a/board/edb93xx/u-boot.lds b/board/edb93xx/u-boot.lds > > > new file mode 100644 > > > index 000..76caef3 > > > --- /dev/null > > > +++ b/board/edb93xx/u-boot.lds > > > > > > This looks pretty generic. Please explain why exactly you think you > > need a board specific linker script here, instead of using the generic > > one? > > the ep93xx expects to find the pattern 'CRUS' (in ASCII) at position > 0x1000. is there a more canonical way to achieve this? This is a processor feature, right? So it's the same for all ep93xx based boards? Then why put that in a board specific directory? > as the header files contain a GPL header i interpreted that it's ok to > submit them without signed-off-by lines from the original authors (what > doesn't mean that i claim authorship on their work): It's OK, but it would be even better if we had their S-o-b's, too. Maybe you can ask them? > > > diff --git a/include/configs/edb93xx.h b/include/configs/edb93xx.h > > > new file mode 100644 > > > index 000..6c4576b > > > --- /dev/null > > > +++ b/include/configs/edb93xx.h > > ... > > > +/* Initial environment and monitor configuration options. */ > > > +#define CONFIG_ETHADDR 08:00:3E:26:0A:5B > > > +#define CONFIG_NETMASK 255.255.255.0 > > > +#define CONFIG_IPADDR192.168.99.225 > > > +#define CONFIG_SERVERIP 192.168.99.1 > > > +#define CONFIG_GATEWAYIP 192.168.99.1 > > > > NAK. We don't allow board specific settings like these. > > hm, a whole bunch of boards do this, so i thought that's the way to > go. what is the correct thing, not defining this values at all? Right. You don't really want to have several boards all using the same MAC address... > i'm not working for cirrus, so i think getting my own set of MAC > address is not really what i'm supposed to do. any further advice? It's up to the hardware manufacturer to provide MAC addresses. > > > +#define CONFIG_ENV_ADDR 0x6004 > > > +#if (defined(CONFIG_EDB9301) || defined(CONFIG_EDB9302) ||\ > > > + defined(CONFIG_EDB9302A)) > > > +#define CONFIG_ENV_SECT_SIZE 0x0002 > > > +#elif (defined(CONFIG_EDB9307) || defined(CONFIG_EDB9307A) ||\ > > > + defined(CONFIG_EDB9312) || defined(CONFIG_EDB9315) ||\ > > > + defined(CONFIG_EDB9315A)) > > > +#define CONFIG_ENV_SECT_SIZE 0x0004 > > > +#endif > > > +#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE) > > > + > > > +#define CONFIG_ENV_SIZE CONFIG_ENV_SECT_SIZE > > > +#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE > > > + > > > +#define CONFIG_SYS_JFFS2_FIRST_BANK 0 > > > +#if (defined(CONFIG_EDB9301) || defined(CONFIG_EDB9302) ||\ > > > + defined(CONFIG_EDB9302A)) > > > +#define CONFIG_SYS_JFFS2_FIRST_SECTOR28 > > > +#elif (defined(CONFIG_EDB9307) || defined(CONFIG_EDB9307A) ||\ > > > + defined(CONFIG_EDB9312) || defined(CONFIG_EDB9315) ||\ > > > + defined(CONFIG_EDB9315A)) > > > +#define CONFIG_SYS_JFFS2_FIRST_SECTOR14 > > > +#endif > > > > Hm... this looks very much like being completely unmaintainable. > > > > Please simplify the code - in your own interest. > > i'm not sure if i understand what you mean bt simplifying in this case > > do you propose something like > > #ifdef CONFIG_EDB9301 > #define CONFIG_ENV_SECT_SIZE 0x0002 > #elif defined(CONFIG_EDB9302) > #define CONFIG_ENV_SECT_SIZE 0x0002 > #elif ... > > #ifdef CONFIG_EDB9301 > #define CONFIG_SYS_JFFS2_FIRST_SECTOR 28 > #elif defined(CONFIG_EDB9302) > #define CONFIG_SYS_JFFS2_FIRST_SECTOR 28 > #elif ... No, that would even be worse. > or even > > #ifdef CONFIG_EDB9301 > #define CONFIG_ENV_SECT_SIZE 0x0002 > #
[U-Boot] copy to flash: Flash not Erased
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
then I try to erase part of the flash, seems ok:
> erase 0x1c04 0x1c8F
> erased 124 sectors
then I use cp.b command, failed with the "Flash not Erased" message
cp.b ${fileaddr} 0x1c04 ${filesize}
> copy to Flash...-Flash not Erased.
and no detailed error message was given.
any idea what could be wrong ?
Thanks for the help in advance.
Howard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove superfluous uses of V_PROMPT macro.
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 this takes care of all of them. include/configs/apollon.h |4 +--- include/configs/omap2420h4.h|8 +++- include/configs/omap3_beagle.h |4 +--- include/configs/omap3_evm.h |4 +--- include/configs/omap3_overo.h |4 +--- include/configs/omap3_pandora.h |4 +--- include/configs/omap3_sdp3430.h |3 +-- include/configs/omap3_zoom1.h |4 +--- 8 files changed, 10 insertions(+), 25 deletions(-) diff --git a/include/configs/apollon.h b/include/configs/apollon.h index 575f60e..891b3ab 100644 --- a/include/configs/apollon.h +++ b/include/configs/apollon.h @@ -183,10 +183,8 @@ /* * Miscellaneous configurable options */ -#defineV_PROMPT"Apollon # " - #defineCONFIG_SYS_LONGHELP /* undef to save memory */ -#defineCONFIG_SYS_PROMPT V_PROMPT +#defineCONFIG_SYS_PROMPT "Apollon # " #defineCONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #defineCONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) diff --git a/include/configs/omap2420h4.h b/include/configs/omap2420h4.h index 9c18842..9c6b6e5 100644 --- a/include/configs/omap2420h4.h +++ b/include/configs/omap2420h4.h @@ -163,14 +163,12 @@ /* * Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ #ifdef CONFIG_APTIX -#define V_PROMPT "OMAP2420 Aptix # " +# define CONFIG_SYS_PROMPT "OMAP2420 Aptix # " #else -#define V_PROMPT "OMAP242x H4 # " +# define CONFIG_SYS_PROMPT "OMAP242x H4 # " #endif - -#define CONFIG_SYS_LONGHELP /* undef to save memory */ -#define CONFIG_SYS_PROMPT V_PROMPT #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 19a5ec9..7fad93b 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -213,12 +213,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "OMAP3 beagleboard.org # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "OMAP3 beagleboard.org # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index a5514ae..c181852 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -194,12 +194,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "OMAP3_EVM # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "OMAP3_EVM # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index ffb515d..745d418 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -199,12 +199,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "Overo # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_PROMPT +#define CONFIG_SYS_PROMPT "Overo # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h index 6f21af3..d2786c0 100644 --- a/include/configs/omap3_pandora.h +++ b/include/configs/omap3_pandora.h @@ -191,12 +191,10 @@ /* * Miscellaneous configurable options */ -#define V_PROMPT "Pandora # " - #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " -#define CONFIG_SYS_PROMPT V_
Re: [U-Boot] [PATCH v2 2/6] Move lib_ directories to lib/
On Mon, 2009-12-07 at 15:42 -0600, Scott Wood wrote: > Wolfgang Denk wrote: > > Dear Peter Tyser, > > > > In message <1258943983.9357.20.ca...@ptyser-laptop> you wrote: > >> My personal preference would be to take it a step further and organize > >> like: > >> > >> /arch/$ARCH/ > >>/lib/ > >>/include/asm/ > >>/cpu/ > >>/config.mk (old lib_$ARCH/config.mk) > >> > >> /lib/ > >> / > >> /libfdt/ > >> /lzma/ > >> /lzo/ > >> > >> This layout would more closely match the Linux layout and is cleaner > >> overall in my opinion. What do others think of this idea? > > > > I generally agree with the idea, with the exception of > > /include/asm/ - I really hate this change in the Linux > > kernel, and still fail to see any advantages of this. > > I really like only having one subtree to grep for arch stuff, and it > would avoid presenting files that are in git, under a path that git > doesn't know about. > > Plus, the symlink is one less thing that the makefiles would need to > keep in sync when arch changes. I agree with Scott, especially the point about grepping for arch stuff in one directory. It also seems like a generally logical separation of arch-specific code/headers. What is the downside of splitting out the headers to arch/ directories? Or the advantage of keeping them in include/asm-? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][RFC][for next] 5xxx, fdt: move fdt_fixup_memory() to cpu.c file
Hello Wolfgang,
Wolfgang Denk wrote:
> 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
>
> I generally agree with this patch, but...
>
>> --- a/board/cm5200/cm5200.c
>> +++ b/board/cm5200/cm5200.c
>> @@ -271,13 +271,6 @@ static void ft_blob_update(void *blob, bd_t *bd)
>> if (ret < 0)
>> printf("ft_blob_update(): cannot set /model property err:%s\n",
>> fdt_strerror(ret));
>> -
>> -ret = fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
>> -
>> -if (ret < 0) {
>> -printf("ft_blob_update(): cannot set /memory/reg "
>> -"property err:%s\n", fdt_strerror(ret));
>> -}
>
> Here we do some error checking, which is always a Good Thing (TM).
Yep!
>> diff --git a/cpu/mpc512x/cpu.c b/cpu/mpc512x/cpu.c
>> index 42ccd81..dac48db 100644
>> --- a/cpu/mpc512x/cpu.c
>> +++ b/cpu/mpc512x/cpu.c
>> @@ -197,6 +197,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>> #ifdef CONFIG_HAS_ETH0
>> fdt_fixup_ethernet(blob);
>> #endif
>> +fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
>> }
>> #endif
>>
>> diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c
>> index efa64c7..2a28df4 100644
>> --- a/cpu/mpc5xxx/cpu.c
>> +++ b/cpu/mpc5xxx/cpu.c
>> @@ -157,6 +157,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>> }
>>
>> #endif
>> +fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
>> }
>> #endif
>
> 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 here ...
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to burn file to sbc8548?
Hi, all: I have a wind river's sbc8548 board and a wind river's ICE SX emulator. I want to run u-boot on the board. My question is: 1. Can I use the ICE SX emulator to burn the bin file? If I can, please tell me some detailed steps. 2. If I can't use ICE SX to burn file, What tool or method can be used to burn the file? Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
