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