Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Nishanth Menon Sent: Tuesday, November 09, 2010 6:09 AM To: Peter Barada Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX Peter Barada wrote, on 11/05/2010 11:59 PM: Personally I'd like to see the kernel and u-boot disconnect on the Looks like we are getting to a consensus - we all seem to dislike the dependency of u-boot and kernel for mux as of today - can we think about [sp] In my opinion, we need to do minimal and necessary MUX settings in u-boot and let kernel manage itself. This also helps ensure that problems noticed in kernel are easy to replicate on other similar platforms. Last year I spent long time in convincing that wake-up on keypad was not working in Linux kernel; but folks using OMAP3430SDP maintained it worked fine. Root cause - relevant PADCONF was set in u-boot for 3430SDP. (not quoting mail-chain) We may not be able to eliminate such instances altogether - but can have less of such instances. post 2011March as a good time to start pushing the relevant changes in? if that is the case, I will start posting RFCs in the coming weeks so [sp] Can you list what chanages you are trying to propose? ...without going as far as RFC. the mails quoted in previous message are again too long and wide in discussion. A concise list will help. ~sanjeev that we can get the relevant changes ready on time. Ofcourse, if there are others wishing to collaborate, folks are more than welcome :) -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Sebastian, drivers/qe already has an object called qe.o ... renaming qe.a to qe.o doesn't work. I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly. I also don't understand why ftd.c is not depending on CONFIG_QE. That's another question ... but leads to error having your patch applied. Regards, André On 11/08/2010 11:04 PM, Sebastien Carlier wrote: NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB). Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries when linking with recent versions of binutils. As stated in the System V ABI, the link editor does not extract archive members to resolve undefined weak symbols. This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired. The name of each former library archive is preserved except for extensions which change from .a to .o. This commit updates references accordingly where needed, in particular in some linker scripts. This commit reveals board configurations that exclude some module but not all of its dependencies; for example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time. Signed-off-by: Sebastien Carliersebastien.carl...@gmail.com --- Makefile | 118 ++-- api/Makefile |4 +- arch/arm/cpu/arm1136/Makefile |4 +- arch/arm/cpu/arm1136/mx31/Makefile|4 +- arch/arm/cpu/arm1136/omap24xx/Makefile|4 +- arch/arm/cpu/arm1176/Makefile |4 +- arch/arm/cpu/arm1176/s3c64xx/Makefile |4 +- arch/arm/cpu/arm1176/tnetv107x/Makefile |4 +- arch/arm/cpu/arm720t/Makefile |4 +- arch/arm/cpu/arm720t/lpc2292/Makefile |4 +- arch/arm/cpu/arm720t/s3c4510b/Makefile|4 +- arch/arm/cpu/arm920t/Makefile |4 +- arch/arm/cpu/arm920t/a320/Makefile|4 +- arch/arm/cpu/arm920t/at91/Makefile|4 +- arch/arm/cpu/arm920t/at91rm9200/Makefile |4 +- arch/arm/cpu/arm920t/ep93xx/Makefile |4 +- arch/arm/cpu/arm920t/imx/Makefile |4 +- arch/arm/cpu/arm920t/ks8695/Makefile |4 +- arch/arm/cpu/arm920t/s3c24x0/Makefile |4 +- arch/arm/cpu/arm925t/Makefile |4 +- arch/arm/cpu/arm926ejs/Makefile |4 +- arch/arm/cpu/arm926ejs/at91/Makefile |4 +- arch/arm/cpu/arm926ejs/davinci/Makefile |4 +- arch/arm/cpu/arm926ejs/kirkwood/Makefile |4 +- arch/arm/cpu/arm926ejs/mb86r0x/Makefile |4 +- arch/arm/cpu/arm926ejs/mx25/Makefile |4 +- arch/arm/cpu/arm926ejs/mx27/Makefile |4 +- arch/arm/cpu/arm926ejs/nomadik/Makefile |4 +- arch/arm/cpu/arm926ejs/omap/Makefile |4 +- arch/arm/cpu/arm926ejs/orion5x/Makefile |4 +- arch/arm/cpu/arm926ejs/spear/Makefile |4 +- arch/arm/cpu/arm926ejs/versatile/Makefile |4 +- arch/arm/cpu/arm946es/Makefile|4 +- arch/arm/cpu/arm_intcm/Makefile |4 +- arch/arm/cpu/armv7/Makefile |4 +- arch/arm/cpu/armv7/mx5/Makefile |4 +- arch/arm/cpu/armv7/omap-common/Makefile |4 +- arch/arm/cpu/armv7/omap3/Makefile |4 +- arch/arm/cpu/armv7/omap4/Makefile |4 +- arch/arm/cpu/armv7/s5p-common/Makefile|4 +- arch/arm/cpu/armv7/s5pc1xx/Makefile |4 +- arch/arm/cpu/ixp/Makefile |4 +- arch/arm/cpu/ixp/npe/Makefile |4 +- arch/arm/cpu/lh7a40x/Makefile |4 +- arch/arm/cpu/pxa/Makefile |4 +- arch/arm/cpu/s3c44b0/Makefile |4 +- arch/arm/cpu/sa1100/Makefile |4 +- arch/arm/lib/Makefile | 10 +- arch/avr32/cpu/Makefile |4 +- arch/avr32/cpu/at32ap700x/Makefile|4 +- arch/avr32/lib/Makefile |4 +- arch/blackfin/cpu/Makefile|4 +- arch/blackfin/lib/Makefile|4 +- arch/i386/cpu/Makefile|4 +- arch/i386/cpu/sc520/Makefile |4 +- arch/i386/lib/Makefile|4 +- arch/m68k/cpu/mcf5227x/Makefile |4 +- arch/m68k/cpu/mcf523x/Makefile|4 +- arch/m68k/cpu/mcf52x2/Makefile|4 +- arch/m68k/cpu/mcf532x/Makefile|4 +- arch/m68k/cpu/mcf5445x/Makefile |4 +-
Re: [U-Boot] [PATCH 4/4] tools/env: use host build flags
Hi Steve, On 09.11.2010 01:01, Steve Sakoman wrote: On Mon, Nov 8, 2010 at 3:15 PM, Wolfgang Denk w...@denx.de wrote: In message m2k4knd6lx@ohwell.denx.de you wrote: It just occurred to me that this will no longer cross compile the fw_env tool - effectively rendering the tool useless for me. Argh... Indeed, that's broken. I ran into this issue this week too. Reverting is one option. I also tried Daniel Hobi's patch tools/env: cleanup host build flags and that worked for me. You are refering to this WIP patch: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/86236 It makes the fw_env tool Makefile similar to the imls Makefile and solves the errno inclusion problem reported by Detlev. I still think we need a third set of CC, CFLAGS, SRCS, etc defines for compiling tools running on the target. However, we probably can default to the combination CC+HOSTCFLAGS for most platforms. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On 09/11/10 09:04, Sebastien Carlier wrote: NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB). Signed-off-by: Sebastien Carlier sebastien.carl...@gmail.com Patch applies with zero errors or warnings to my x86 branch, builds clean, runs and, as a bonus, allows me to move the sc520 reset_cpu() which has an ugly #ifdef in sc520.c into it's own file (with archives, if the archive contained only overrides of weak functions, they would be skipped - I think the archive needed at least the first function to not be an override of a weak function) So I'm a very happy (one less #ifdef) camper Tested-by: Graeme Russ graeme.r...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Wolfgang, On Mon, 2010-11-08 at 16:36 -0700, Wolfgang Denk wrote: Dear Haiying Wang, Why it looks broken? I do need CONFIG_NAND defined for 8536DS nand build. For building nand uboot, 2 images are needed, one is 4K nand_spl Yes. But there is also MPC8536DS and MPC8536DS_36BIT and MPC8536DS_SDCARD and MPC8536DS_SPIFLASH which do NOT define CONFIG_NAND, but they too need a definition of CONFIG_SYS_TEXT_BASE. MPC8536DS/_36BIT/_SDCARD/_SPIFLASH are in parallel with _NAND. I understand they all need their CONFIG_SYS_TEXT_BASE. But here we talk about the MPC8536DS_NAND_config which need two uboot images, each should have its own CONFIG_SYS_TEXT_BASE. e.g. in u-boot/Makefile $(U_BOOT_NAND): $(NAND_SPL) $(obj)u-boot.bin cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin $(obj)u-boot-nand.bin u-boot-spl-16k.bin needs 0xfff0 as CONFIG_SYS_TEXT_BASE u-boot.bin needs 0xf8f82000 as CONFIG_SYS_TEXT_BASE Well, I guess it also showed where the previous definition came from?. Yes, it showed the first definition of CONFIG_SYS_TEXT_BASE in my example code which is 0xfff0 in MPC8536DS.h was redefined. But in fact, I need that value instead of 0xf8f82000 for nand spl. You did not answer my question. The error message shows _where_ the previous definition came from. Please check this. OK, the error message is: In file included from /home/haiying/Opensource/Kumar/u-boot-mpc85xx/include/config.h:5, from ns16550.c:7: /home/haiying/Opensource/Kumar/u-boot-mpc85xx/include/configs/MPC8536DS.h:40:1: warning: CONFIG_SYS_TEXT_BASE redefined Here are the lines in MPC8536DS.h(using git diff result, so that the changes I made can be seen clearly) diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index 8b8f467..0eb3072 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -36,8 +36,12 @@ 36: #ifdef CONFIG_NAND 37: #define CONFIG_NAND_U_BOOT 1 38: #define CONFIG_RAMBOOT_NAND1 39:+#ifdef CONFIG_NAND_SPL 40:+#define CONFIG_SYS_TEXT_BASE 0xfff0 41:+#else 42: #define CONFIG_SYS_TEXT_BASE 0xf8f82000 43: #endif 44: +#endif CONFIG_NAND was used for the final uboot image, and CONFIG_NAND_SPL was used for nand_spl image. However, after that commit, the CONFIG_NAND combined the usage of CONFIG_MK_NAND and CONFIG_NAND. Right. Why would we need two different defines for the same thing? I need two different defines for generating the different image, which are under the same CONFIG_NAND defines now. Try to find out where that redefine is coming from, and fix that. And fix the ,NAND flag in boards.cfg if this is not what you want. The redefine came from the define of CONFIG_SYS_TEXT_BASE for nand_spl. Sorry, but this makes no sense. If the code looks as above, there is always at most one define of CONFIG_SYS_TEXT_BASE in the board config file (actually it's missing for boards that don't define CONFIG_NAND). Yes, now the problem is only one define of CONFIG_SYS_TEXT_BASE is allowed for one board config,i.e CONFIG_NAND, but two images need to be generated for nand boot, one is u-boot-spl.bin, the other is u-boot.bin. They need different CONFIG_SYS_TEXT_BASE. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT] da850evm: Add RMII support for EMAC
Hi Ben, From: Sudhakar Rajashekhara sudhakar@ti.com This patch is a port of the work by Sudhakar Rajeshekhara in commit ab3effbcad8851cc65dc5241a01c064d2030a3b2 of git://arago-project.org/git/people/sandeep/u-boot-davinci.git. The da850 UI board has on it an RMII PHY which can be used if the MDC line to the MII PHY on the baseboard is disabled and the RMII PHY is enabled by configuring the values of some GPIO pins on the IO expander of the UI board. This patch implements disabling that line via GPIO2[6], configuring the UI board's IO expander and setting only the pinmux settings that are needed for RMII operation. Tested on da850evm by adding a define for CONFIG_DRIVER_TI_EMAC_USE_RMII. Thanks a lot for going ahead and mainline parts which linger for months in TI only trees. While talking about those features - is anybody working on enabling the SPI flash in mainline for da850evm? Thanks Detlev -- Two monks went fishing in an electron river. The first monk drew out his network, and out flopped a hacker. The second monk cried, The poor hacker! How can it live outside of the network? The first monk said, When you have learned to live outside the network, then you will know. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [WIP] tools/env: cleanup host build flags
Hello Daniel, This patch makes tools/env/Makefile more similar to tools/imls: - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works. - include U-Boot headers using -idirafter to prevent picking up u-boot/include/errno.h. - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic). - use the cross compiler again (fw_printenv is intended for a hosted environment on the target). Signed-off-by: Daniel Hobi daniel.h...@schmid-telecom.ch Cc: Mike Frysinger vap...@gentoo.org Cc: Wolfgang Denk w...@denx.de As this indeed fixes the cross-compilation problem: Tested-by: Detlev Zundel d...@denx.de tools/env/Makefile | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) Hi Scott, In commit d984fed0 (makefiles: fixes for building build tools), you suggest that using $(CC) with host flags (HOSTCFLAGS, etc) is the correct way to use the cross compiler to generate binaries for a hosted environment on the target. On the other hand, you use $(HOSTCC) to generate the .depend file in rules.mk which leads to wrong dependencies. I think we need to differentiate three cases: - (free-standing) U-Boot: use CC and CFLAGS - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS - Linux environment on the target (imls, fw_printenv): Can we use CC and HOSTCFLAGS, or do we need a third set of variables for flags? If reusing HOSTCFLAGS: how do we fix dependency generation? I also don't know, but this fixes a bug, so I want the patch in ;) Cheers Detlev -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On 11/08/2010 11:04 PM, Sebastien Carlier wrote: NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB). Your patch applies fine to i.MX branch - boards compile clean, tested on a MX.51 board. Tested-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT] da850evm: Add RMII support for EMAC
On Friday, November 05, 2010 17:11:13 Ben Gardiner wrote: CC: Sandeep Paulraj s-paul...@ti.com spurious quote in this tag -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] ARM: OMAP3/4: proposal: Cleanup MUX
Premi, Sanjeev wrote, on 11/09/2010 02:48 AM:
Peter Barada wrote, on 11/05/2010 11:59 PM:
Personally I'd like to see the kernel and u-boot disconnect on the
Looks like we are getting to a consensus - we all seem to dislike the
dependency of u-boot and kernel for mux as of today - can we
think about
[sp] In my opinion, we need to do minimal and necessary MUX settings
in u-boot and let kernel manage itself.
This also helps ensure that problems noticed in kernel are easy
to replicate on other similar platforms. Last year I spent long
time in convincing that wake-up on keypad was not working in Linux
kernel; but folks using OMAP3430SDP maintained it worked fine.
Root cause - relevant PADCONF was set in u-boot for 3430SDP.
(not quoting mail-chain)
We may not be able to eliminate such instances altogether - but
can have less of such instances.
I definitely agree.
post 2011March as a good time to start pushing the relevant
changes in?
if that is the case, I will start posting RFCs in the coming weeks so
[sp] Can you list what chanages you are trying to propose? ...without
going as far as RFC.
the mails quoted in previous message are again too long and wide
in discussion. A concise list will help.
Have'nt got to the code yet - had no intent of spending those cycles if
the community had no interest in it and without a potential date OR had
some issue which I could not think about. but anyways, here is the
overall idea:
per Soc, have muxes per IP - I did not think it was worthwhile to do a
complex mux (dynamic) as done in linux kernel.
DDR_CS0_MUX
DDR_CS1_MUX
GPMC_MUX - need to think an elegant method to specify CSs to enable
I2C{1,2,3,4,5 - based on SoC}_MUX
MMC{0,1,2,3,4- based on SoC}_MUX
UART{0,1,2,3,4 - based on SoC}_MUX
If bootlogo enabled
DSS_PARALLEL_MUX
DSS_DSI_MUX
if USB OTG enabled
USB_OTG_MUX
if USB Host enabled
USB_EHCI_MUX
GPIO Muxes - need some elegant way to specify which GPIOs map to which
muxed pins..
if SPI enabled,
SPI_MUX
None of the muxing will be wakeup enabled - wakeup is a kernel feature
and should be done there. only mux mode and pull types should be set in
u-boot.
The board file will still call the mux - it will however only call the
ones it needs to boot and load image.
One more additional thought I had was to introduce Mux Scheme per IP -
e.g. DSS lines come out in different pin sequences - we call each
SCHEMEs so that new boards can find it a little easier to enable MUX..
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why cmd_tbl_t is referenced as extern in defining __u_boot_cmd_start?
On Tuesday, November 02, 2010 11:56:31 legendbb wrote: line 64 and 65 in include/command.h extern cmd_tbl_t __u_boot_cmd_start; extern cmd_tbl_t __u_boot_cmd_end; definition of cmd_tbl_t is just one line above these. Why extern is used? basic C question ? if you dont have the extern, you'd be declaring storage for two variables instead of references to the symbols elsewhere. -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] env_mmc: fix compile warning
On Monday, November 08, 2010 01:59:48 Lei Wen wrote: Signed-off-by: Lei Wen lei...@marvell.com --- common/env_mmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/common/env_mmc.c b/common/env_mmc.c index 3d7fceb..7c9392c 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -29,6 +29,7 @@ #include linux/stddef.h #include malloc.h #include mmc.h +#include search.h #include errno.h you really need to mention what warning you're fixing. such as missing foo() prototype or something. -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 1/2] use MAC from environment and add support for new NET_MULTI api in ethernet driver of KS8695
On Thursday, November 04, 2010 06:13:00 Bernstein, Michael wrote:
diff --unified --recursive --new-file
u-boot-2009.11/drivers/net/ks8695eth.c
u-boot-2009.11,new/drivers/net/ks8695eth.c ---
u-boot-2009.11/drivers/net/ks8695eth.c
this is a pretty old tree. you should be using latest mainline tree.
void ks8695_getmac(void)
{
- unsigned char *fp;
- int i;
+ if (!eth_getenv_enetaddr(ethaddr, eth_mac[0])) {
NAK. drivers should not be poking the environment. please read the
documentation in doc/README.drivers.eth.
-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] [RFC] Add 'led' command
On Friday, November 05, 2010 01:50:36 Jason Kridner wrote:
+int do_led ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] )
much of the style of this code is broken. and i cant imagine this code
compiling warning free with current master.
no spaces around the paren, and the argv has been constified.
also, this should be marked static
+ if ((argc != 3)){
space before the brace and useless set of paren here
+ printf(Usage:\n%s\n, cmdtp-usage);
+ return 1;
return cmd_usage(cmdtp);
+ if (strcmp(argv[2], off) == 0) {
+ state = 0;
+ } else if (strcmp(argv[2], on) == 0) {
+ state = 1;
i could have sworn we had a helper somewhere to handle boolean strings ...
+ printf (Usage:\n%s\n, cmdtp-usage);
+ return 1;
return cmd_usage(cmdtp);
+#if defined(STATUS_LED_BIT) defined(CONFIG_BOARD_SPECIFIC_LED)
+ if (strcmp(argv[1], 0) == 0) {
+ mask = STATUS_LED_BIT;
+ __led_set(mask, state);
+ }
+ else
+#endif
+#if defined(STATUS_LED_BIT1) defined(CONFIG_BOARD_SPECIFIC_LED)
+ if (strcmp(argv[1], 1) == 0) {
+ mask = STATUS_LED_BIT1;
+ __led_set(mask, state);
+ }
+ else
+#endif
+#if defined(STATUS_LED_BIT2) defined(CONFIG_BOARD_SPECIFIC_LED)
+ if (strcmp(argv[1], 2) == 0) {
+ mask = STATUS_LED_BIT2;
+ __led_set(mask, state);
+ }
+ else
+#endif
+#if defined(STATUS_LED_BIT3) defined(CONFIG_BOARD_SPECIFIC_LED)
+ if (strcmp(argv[1], 3) == 0) {
+ mask = STATUS_LED_BIT3;
+ __led_set(mask, state);
+ }
+ else
+#endif
i dont know why you need the mask variable here at all
also, these #ifdef trees scream for some sort of unification
+ } else {
+ printf (Usage:\n%s\n, cmdtp-usage);
+ return 1;
return cmd_usage(cmptp);
+
files should not have trailing new lines
-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 2/2] use MAC from environment and add support for new NET_MULTI api in ethernet driver of KS8695
On Thursday, November 04, 2010 06:15:09 Bernstein, Michael wrote: /* + * some defines to allow switching between NET_MULTI and old API + */ +#if defined(CONFIG_NET_MULTI) +#define KS8695_ETH_RESET ks8695_eth_reset +#define KS8695_ETH_HALT ks8695_eth_halt +#define KS8695_ETH_INIT ks8695_eth_init +#define KS8695_ETH_RXks8695_eth_rx +#define KS8695_ETH_SEND ks8695_eth_send +#define KS8695_DRIVERNAME KS8695 +#else +#define KS8695_ETH_RESET eth_reset +#define KS8695_ETH_HALT eth_halt +#define KS8695_ETH_INIT eth_init +#define KS8695_ETH_RXeth_rx +#define KS8695_ETH_SEND eth_send +#endif NAK. only support the NET_MULTI API. the old style is dead. -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 V4 1/2] arm926ejs: fix linker file for newer ld support
Le 04/11/2010 23:27, Albert ARIBAUD a écrit : Le 04/11/2010 23:22, Albert Aribaud a écrit : older ld emitted all ELF relocations in input sections named ..rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaudalbert.arib...@free.fr Tested on openrd_base, boots fine, works fine. Wolfgang, please test with tx25. Alexander, please test above your patches in place of previous patch v3. Others who are willing to test on other ARMs are welcome too. :) Did testers manage to try this patch set? I'd like to make sure it solves current issues with master for ARM relocation. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [WIP] tools/env: cleanup host build flags
On Tue, Nov 9, 2010 at 7:03 AM, Detlev Zundel d...@denx.de wrote: Hello Daniel, This patch makes tools/env/Makefile more similar to tools/imls: - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works. - include U-Boot headers using -idirafter to prevent picking up u-boot/include/errno.h. - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic). - use the cross compiler again (fw_printenv is intended for a hosted environment on the target). Signed-off-by: Daniel Hobi daniel.h...@schmid-telecom.ch Cc: Mike Frysinger vap...@gentoo.org Cc: Wolfgang Denk w...@denx.de As this indeed fixes the cross-compilation problem: Tested-by: Detlev Zundel d...@denx.de Agreed! Tested-by: Steve Sakoman steve.sako...@linaro.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] silly error caused by /usr/local/include/config.h - STD_END_SIZE build failure
http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg07045.html i've tracked down what the problem is, and the fix to avoid the problem occurring in the future is either: a) do as the person says - #include ../config.h not #include config.h b) add -I. to the gcc compile options, to prioritise cwd over /usr/local/include and /usr/include. c) create a gcc spec file (in /usr/lib/gcc/) which doesn't have /usr/local/include or /usr/include this latter is not a serious suggestion. i encountered this exact same problem because i happened to have some fg stupid package install a config.h file in /usr/local/include - but to delete that file is NOT the solution. l. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] [NEXT] da850: Add RMII support for EMAC
From: Sudhakar Rajashekhara sudhakar@ti.com
From: Sudhakar Rajashekhara sudhakar@ti.com
This patch is a port of the work by Sudhakar Rajeshekhara in commit
ab3effbcad8851cc65dc5241a01c064d2030a3b2 of
git://arago-project.org/git/people/sandeep/u-boot-davinci.git.
The da850 UI board has on it an RMII PHY which can be used if the MDC line
to the MII PHY on the baseboard is disabled and the RMII PHY is enabled by
configuring the values of some GPIO pins on the IO expander of the UI board.
This patch implements disabling that line via GPIO2[6], configuring the UI
board's IO expander and setting only the pinmux settings that are needed for
RMII operation.
Tested on da850evm by adding a define for CONFIG_DRIVER_TI_EMAC_USE_RMII.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Sandeep Paulraj s-paul...@ti.com
CC: Ben Warren biggerbadder...@gmail.com
CC: Mike Frysinger vap...@gentoo.org
---
Changes since V1:
* Removeed spurious quote in Sandeep's CC: line
Changes since work of Sudhakar Rajashekhar:
* rebased to 0c0892be0d93a5a892b93739c5eb3bf692fed4ff, resolved conflicts.
* fixup uses of pinmux[x] to pinmux(x)
---
arch/arm/include/asm/arch-davinci/hardware.h |4 +
board/davinci/da8xxevm/common.c | 14 +++
board/davinci/da8xxevm/common.h |3 +
board/davinci/da8xxevm/da850evm.c| 112 +-
drivers/net/davinci_emac.c | 41 +-
include/configs/da850evm.h |1 +
6 files changed, 170 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..da1160a 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -150,6 +150,10 @@ typedef volatile unsigned int *dv_reg_p;
#define DAVINCI_INTC_BASE 0xfffee000
#define DAVINCI_BOOTCFG_BASE 0x01c14000
+#define GPIO_BANK2_REG_DIR_ADDR(DAVINCI_GPIO_BASE +
0x38)
+#define GPIO_BANK2_REG_OPDATA_ADDR (DAVINCI_GPIO_BASE + 0x3c)
+#define GPIO_BANK2_REG_SET_ADDR(DAVINCI_GPIO_BASE +
0x40)
+#define GPIO_BANK2_REG_CLR_ADDR(DAVINCI_GPIO_BASE +
0x44)
#endif /* CONFIG_SOC_DA8XX */
/* Power and Sleep Controller (PSC) Domains */
diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c
index 9cd5204..b33b877 100644
--- a/board/davinci/da8xxevm/common.c
+++ b/board/davinci/da8xxevm/common.c
@@ -53,3 +53,17 @@ int da8xx_configure_lpsc_items(const struct lpsc_resource
*item,
return 0;
}
+
+#if defined(CONFIG_DRIVER_TI_EMAC) defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel)
+{
+ int val;
+
+ val = readl(davinci_syscfg_regs-cfgchip3);
+ if (mode_sel == 0)
+ val = ~(1 8);
+ else
+ val |= (1 8);
+ writel(val, davinci_syscfg_regs-cfgchip3);
+}
+#endif
diff --git a/board/davinci/da8xxevm/common.h b/board/davinci/da8xxevm/common.h
index 7ae63a6..8b564f7 100644
--- a/board/davinci/da8xxevm/common.h
+++ b/board/davinci/da8xxevm/common.h
@@ -26,5 +26,8 @@ struct lpsc_resource {
void irq_init(void);
int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
int n_items);
+#if defined(CONFIG_DRIVER_TI_EMAC) defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel);
+#endif
#endif /* __COMMON_H */
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index c8c5e1b..ac96818 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -54,6 +54,15 @@ static const struct pinmux_config uart_pins[] = {
#ifdef CONFIG_DRIVER_TI_EMAC
static const struct pinmux_config emac_pins[] = {
+#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
+ { pinmux(14), 8, 2 },
+ { pinmux(14), 8, 3 },
+ { pinmux(14), 8, 4 },
+ { pinmux(14), 8, 5 },
+ { pinmux(14), 8, 6 },
+ { pinmux(14), 8, 7 },
+ { pinmux(15), 8, 1 },
+#else /* ! CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(2), 8, 1 },
{ pinmux(2), 8, 2 },
{ pinmux(2), 8, 3 },
@@ -69,10 +78,10 @@ static const struct pinmux_config emac_pins[] = {
{ pinmux(3), 8, 5 },
{ pinmux(3), 8, 6 },
{ pinmux(3), 8, 7 },
+#endif /* CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(4), 8, 0 },
{ pinmux(4), 8, 1 }
};
-#endif /* CONFIG_DRIVER_TI_EMAC */
/* I2C pin muxer settings */
static const struct pinmux_config i2c_pins[] = {
@@ -99,6 +108,13 @@ const struct pinmux_config nand_pins[] = {
};
#endif
+#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
+#define HAS_RMII 1
+#else
+#define HAS_RMII 0
+#endif
+#endif /* CONFIG_DRIVER_TI_EMAC */
+
static const struct pinmux_resource
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 2010-11-09 at 09:23 -0700, Wolfgang Denk wrote: Dear Haiying Wang, Is this all the error messages you get? Normally tehre should be another message, for example: [filename]:[lineno]:[column]: warning: this is the location of the previous definition or, if there was a -DCONFIG_SYS_TEXT_BASE=... on the command line: command-line: warning: this is the location of the previous definition It is in one of the error messages, there are others for the same error. Here is the total message when building tlb.c for nand_spl: powerpc-none-linux-gnuspe-gcc -g -Os -mrelocatable -fPIC -meabi -ffunction-sections -fdata-sections -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xf8f82000 -DRESET_VECTOR_ADDRESS=0xeffc -I/home/haiying/u-boot-mpc85xx/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/lib/gcc/powerpc-none-linux-gnuspe/4.3.2/include -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes -fno-stack-protector -DCONFIG_NAND_SPL -c -o tlb.o tlb.c In file included from /home/haiying/u-boot-mpc85xx/include/config.h:5, from /home/haiying/u-boot-mpc85xx/include/common.h:37, from tlb.c:26: /home/haiying/u-boot-mpc85xx/include/configs/MPC8536DS.h:40:1: warning: CONFIG_SYS_TEXT_BASE redefined command-line: warning: this is the location of the previous definition Here are the lines in MPC8536DS.h(using git diff result, so that the changes I made can be seen clearly)ing This doesn't help, as it doesn't show where the other definition is coming from. The other definition comes from include/autoconf.mk, I think. Haiy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT] da850evm: Add RMII support for EMAC
On Tue, Nov 9, 2010 at 8:43 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday, November 05, 2010 17:11:13 Ben Gardiner wrote: CC: Sandeep Paulraj s-paul...@ti.com spurious quote in this tag -mike Oops. Thanks for catching that, Mike. On Tue, Nov 9, 2010 at 9:42 AM, Detlev Zundel d...@denx.de wrote: Hi Ben, [...] Thanks a lot for going ahead and mainline parts which linger for months in TI only trees. You're welcome / it is my pleasure. While talking about those features - is anybody working on enabling the SPI flash in mainline for da850evm? I can say that I won't be. We're interested in NAND flash support only -- as you may have already guessed from earlier tested-by's. If TI doesn't step-up to add SD and USB (host) support to mainline I plan to also pick up the slack there. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 17:23:43 +0100 Wolfgang Denk w...@denx.de wrote: Yes, now the problem is only one define of CONFIG_SYS_TEXT_BASE is allowed for one board config,i.e CONFIG_NAND, but two images need to be generated for nand boot, one is u-boot-spl.bin, the other is u-boot.bin. They need different CONFIG_SYS_TEXT_BASE. Maybe they should use different variables then, say CONFIG_SYS_TEXT_BASE and CONFIG_SYS_TEXT_BASE_SPL ? Why? It's the same variable, just for a different build. Are we going to have _SPL and non-_SPL variants of all other things that might vary between the two? What about a middle-stage build where we want to use CONFIG_ symbols to pull in files like a regular U-Boot build, but we want to pull in a different set than the final image? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Haiying Wang, In message 1289314359.2168.20.ca...@haiying-laptop you wrote: You did not answer my question. The error message shows _where_ the previous definition came from. Please check this. OK, the error message is: In file included from /home/haiying/Opensource/Kumar/u-boot-mpc85xx/include/config.h:5, from ns16550.c:7: /home/haiying/Opensource/Kumar/u-boot-mpc85xx/include/configs/MPC8536DS.h:40:1: warning: CONFIG_SYS_TEXT_BASE redefined Is this all the error messages you get? Normally tehre should be another message, for example: [filename]:[lineno]:[column]: warning: this is the location of the previous definition or, if there was a -DCONFIG_SYS_TEXT_BASE=... on the command line: command-line: warning: this is the location of the previous definition Here are the lines in MPC8536DS.h(using git diff result, so that the changes I made can be seen clearly) This doesn't help, as it doesn't show where the other definition is coming from. Yes, now the problem is only one define of CONFIG_SYS_TEXT_BASE is allowed for one board config,i.e CONFIG_NAND, but two images need to be generated for nand boot, one is u-boot-spl.bin, the other is u-boot.bin. They need different CONFIG_SYS_TEXT_BASE. Maybe they should use different variables then, say CONFIG_SYS_TEXT_BASE and CONFIG_SYS_TEXT_BASE_SPL ? 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 first 90% of a project takes 90% of the time, the last 10% takes the other 90% of the time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Scott Wood, In message 20101109102643.45d7f...@udp111988uds.am.freescale.net you wrote: Maybe they should use different variables then, say CONFIG_SYS_TEXT_BASE and CONFIG_SYS_TEXT_BASE_SPL ? Why? It's the same variable, just for a different build. Are we going to have _SPL and non-_SPL variants of all other things that might vary between the two? This is a multistage process. Initially, we generate autoconf.mk by parsing the config files; then we include autoconf.mk in the Makefile to export the settings to make. If you change the value of one of the variables in a later stage of the build (like using #ifdef), then tis will not become visible in the Makefile context, i. e. any use of these variables for example in the Linker command will still use the old value. What about a middle-stage build where we want to use CONFIG_ symbols to pull in files like a regular U-Boot build, but we want to pull in a different set than the final image? This is no problem as long as these variables doen't change their values on the fly. 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 We are all agreed that your theory is crazy. The question which divides us is whether it is crazy enough to have a chance of being correct. My own feeling is that it is not crazy enough. - Niels Bohr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Haiying Wang, In message 1289320865.2168.92.ca...@haiying-laptop you wrote: It is in one of the error messages, there are others for the same error. Here is the total message when building tlb.c for nand_spl: ... powerpc-none-linux-gnuspe-gcc -g -Os -mrelocatable -fPIC -meabi -ffunction-sections -fdata-sections -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xf8f82000 -DRESET_VECTOR_ADDRESS=0xeffc ^^^ Here we have it. /home/haiying/u-boot-mpc85xx/include/configs/MPC8536DS.h:40:1: warning: CONFIG_SYS_TEXT_BASE redefined command-line: warning: this is the location of the previous definition OK. Problem is understood. Th problem comes from the value of CONFIG_SYS_TEXT_BASE changing on the fly. I recommend to use CONFIG_SYS_SPLTEXT_BASE or so for the SPL image linking. The other definition comes from include/autoconf.mk, I think. It comes from the command line, which is generated by make, which picks teh values from include/autoconf.mk indeed - which gets build initiall. 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 solution is ... a balance of power. We arm our side with exactly that much more. A balance of power -- the trickiest, most difficult, dirtiest game of them all. But the only one that preserves both sides. -- Kirk, A Private Little War, stardate 4211.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] silly error caused by /usr/local/include/config.h - STD_END_SIZE build failure
geez, this really _isn't_ good - i've found _yet another_ identically-caused error, because i happen to have linux header files installed locally (/usr/include/linux) and the default HOST-CC setup compilation has that taking precedence over ./include/linux in the u-boot sources - so include/linux/mtd/mtd.h is never found. what's going on?? On Tue, Nov 9, 2010 at 3:59 PM, Luke Kenneth Casson Leighton luke.leigh...@gmail.com wrote: http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg07045.html i've tracked down what the problem is, and the fix to avoid the problem occurring in the future is either: a) do as the person says - #include ../config.h not #include config.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Switch from archive libraries to partial linking
Dear André, On 2010-11-09 10:15:31, Andre Schwarz wrote: Date: Tue, 09 Nov 2010 10:15:31 +0100 From: Andre Schwarz andre.schw...@matrix-vision.de To: Sebastien Carlier sebastien.carl...@gmail.com CC: u-boot@lists.denx.de, Timur Tabi ti...@freescale.com, Kim Phillips kim.phill...@freescale.com Subject: Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 Sebastian, drivers/qe already has an object called qe.o ... renaming qe.a to qe.o doesn't work. Thanks! I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly. I did as you suggested, version 2 of the patch is available here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v2.patch I also don't understand why ftd.c is not depending on CONFIG_QE. That's another question ... but leads to error having your patch applied. Right, fdt.c should not be included in the build unless both CONFIG_QE and CONFIG_OF_LIBFDT are defined. Previously this issue was hidden because all of qe.a was discarded by the linker. Would the following be a good fix for this problem? -COBJS-$(CONFIG_OF_LIBFDT) += fdt.o +COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o Regards, -- Sébastien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] silly error caused by /usr/local/include/config.h - STD_END_SIZE build failure
On Tue, Nov 9, 2010 at 5:38 PM, Luke Kenneth Casson Leighton luke.leigh...@gmail.com wrote: geez, this really _isn't_ good - i've found _yet another_ identically-caused error, because i happen to have linux header files installed locally (/usr/include/linux) and the default HOST-CC setup compilation has that taking precedence over ./include/linux in the u-boot sources - so include/linux/mtd/mtd.h is never found. what's going on?? *sigh* i found that latest git master u-boot has this fixed - and a boat-load of other problems fixed in tools/env - as compared to u-boot 1.2.0 which is what the customer is using argh bloody hell off we go, patch or hack :) l. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 18:18:53 +0100 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20101109102643.45d7f...@udp111988uds.am.freescale.net you wrote: Maybe they should use different variables then, say CONFIG_SYS_TEXT_BASE and CONFIG_SYS_TEXT_BASE_SPL ? Why? It's the same variable, just for a different build. Are we going to have _SPL and non-_SPL variants of all other things that might vary between the two? This is a multistage process. Initially, we generate autoconf.mk by parsing the config files; then we include autoconf.mk in the Makefile to export the settings to make. If you change the value of one of the variables in a later stage of the build (like using #ifdef), then tis will not become visible in the Makefile context, i. e. any use of these variables for example in the Linker command will still use the old value. What about a middle-stage build where we want to use CONFIG_ symbols to pull in files like a regular U-Boot build, but we want to pull in a different set than the final image? This is no problem as long as these variables doen't change their values on the fly. It's not on the fly, it's just that each image needs its own autoconf.mk. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 19:24, Daniel Hobi a écrit : Hi Albert, On 04.11.2010 23:22, Albert Aribaud wrote: older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Tested-by: Daniel Hobidaniel.h...@schmid-telecom.ch Thanks Daniel for the test. Thank you. This patch is required to get Kirkwood-based boards working again when using the CodeSourcery 2009q3 toolchain. (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 2010q1 apparently... Can you tell me which gcc and which ld version is used in 2010q3?) I think this V4 of my patchset could be now committed to u-boot-arm/master, and if possible even on u-boot-arm for the december release of u-boot, as it is a bugfix. But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) And on many ARM platforms (including Kirkwood), the timer implementation is still accessing BSS variables before relocation. That is fixed in the orion5x code; a git blame on the timer.c file will tell you which commit of mine did the fix, and from then you can port to kirkwood as the orion5x code comes from the kirkwood one. Is someone working on this? Candidates are: $ git grep static ulong timestamp arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp; arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp; arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp; arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp; arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp; arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp; arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp; arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp; arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp; Normally, the board maintainers should handle this during the window after next version... Dunno if that is practical, but OTOH it would easily show which boards are still maintained and which are not. :) Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 19:47, Albert ARIBAUD a écrit : I think this V4 of my patchset could be now committed to u-boot-arm/master, and if possible even on u-boot-arm for the december release of u-boot, as it is a bugfix. ... even on u-boot, not u-boot-arm, of course. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Scott Wood, In message 20101109122218.13f16...@udp111988uds.am.freescale.net you wrote: This is no problem as long as these variables doen't change their values on the fly. It's not on the fly, it's just that each image needs its own autoconf.mk. For me it is on the fly when running a single make all sees these values changing. 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 Ever try. Ever fail. No matter. Try again. Fail again. Fail better. -- S. Beckett ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 19:59:47 +0100 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20101109122218.13f16...@udp111988uds.am.freescale.net you wrote: This is no problem as long as these variables doen't change their values on the fly. It's not on the fly, it's just that each image needs its own autoconf.mk. For me it is on the fly when running a single make all sees these values changing. In any case, the right answer is a separate autoconf.mk per image. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
On Tue, 2 Nov 2010 10:17:23 +0100 Stefan Roese s...@denx.de wrote: Hi Heiko, On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote: - preloader copies first page of nand (nand_spl code) to 0xbb00 (some cpu internal mem) and jumps to this address - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code) Why is this relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... On PPC4xx we need to copy the code from the original location (4KiB loaded via the ROM IPL boot loader) to SDRAM and continue running it from there. This is necessary since we can't run from the original location (0xfxxx) and use the PPC4xx NAND controller at the same time. We have the same restriction on FSL NAND controllers -- certainly the eLBC, and I think also the NFC which is used on ARM, though I'm less familiar with that one. So there is no relocation to TEXT_BASE on 4xx but only a copy to CONFIG_SYS_NAND_BOOT_SPL_DST. It looks like you do memory init from assembly code to pull that off. On 83xx/85xx we do an actual relocation of the NAND SPL. Not sure about ARM. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Daniel Hobi, Am 09.11.2010 um 19:24 schrieb Daniel Hobi: And on many ARM platforms (including Kirkwood), the timer implementation is still accessing BSS variables before relocation. Is someone working on this? Candidates are: $ git grep static ulong timestamp arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp; arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp; arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp; arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp; arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/ is dead an will be removed soon. arch/arm/cpu/arm920t/at91/ still misses such an implementation but will be something like arch/arm/cpu/arm926ejs/at91/ BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert Ardibaud, Am 09.11.2010 um 19:47 schrieb Albert ARIBAUD: Thank you. This patch is required to get Kirkwood-based boards working again when using the CodeSourcery 2009q3 toolchain. (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 2010q1 apparently... Can you tell me which gcc and which ld version is used in 2010q3?) I think http://www.codesourcery.com/sgpp/lite/arm/portal/release1033 was meant ... regards Andreas Bießmann___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 20:27, Andreas Bießmann a écrit : BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards? Don't know for others, but regarding the timer, there is no need for timestamp before relocation, so it needs not join gd stuff. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on eLBC
On Fri, 5 Nov 2010 10:21:53 +0100 Andre Schwarz andre.schw...@matrix-vision.de wrote: Scott, looks like I made a mistake on current MPC8377 NAND wiring. Nand-Flash write enable is wired to LFWE1 ... I connected each WE to its corresponding CS, i.e. : - CS0/WE0 - Nor Flash - CS1/WE1 - Nand Flash - CS2/WE2 - MRAM Am I assuming right that FCM can only use WE0 ? I think so. It looks like the other lines were meant to be byte selects for NOR/UPM, not anything to do with the chip select. Do you see any issue with connecting all devices to WE0 since they have distinct chip selects ? I guess not, especially if that's the only way the FCM works. But to be sure, maybe ask official Freescale support channels, and/or someone who's more familiar with the hardware side of this stuff. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Scott Wood, In message 20101109130427.5e918...@udp111988uds.am.freescale.net you wrote: For me it is on the fly when running a single make all sees these values changing. In any case, the right answer is a separate autoconf.mk per image. NAK. If different images need to be linked with different text base addresses, they should use separate variables. Having these lists of #ifdef's and needing to know umm, now we're in the context of building FOO image, so TEXT_BASE might be that; oh, wrong, it's the other #if branch actually, it should be this is just what you see right now: a maintenance nightmare. Lets get rid of this mess, and use a separate variable for each separate purpose. Name space is big enough, so we don't have to redefine the meaning of variables like that. 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 Lack of skill dictates economy of style.- Joey Ramone ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 21:13:00 +0100 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20101109130427.5e918...@udp111988uds.am.freescale.net you wrote: For me it is on the fly when running a single make all sees these values changing. In any case, the right answer is a separate autoconf.mk per image. NAK. If different images need to be linked with different text base addresses, they should use separate variables. Having these lists of #ifdef's and needing to know umm, now we're in the context of building FOO image, so TEXT_BASE might be that; oh, wrong, it's the other #if branch actually, it should be this is just what you see right now: a maintenance nightmare. I don't see how #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #else #define CONFIG_SYS_TEXT_BASE yyy #endif is more of a maintenance problem than #define CONFIG_SYS_TEXT_BASE_SPL xxx #define CONFIG_SYS_TEXT_BASE yyy followed by multiple instances of #ifdef NAND_SPL do something with CONFIG_SYS_TEXT_BASE_SPL #else do something with CONFIG_SYS_TEXT_BASE #endif And as I've pointed out, this gets to be an even bigger mess with larger SPLs that want to pull in bigger chunks of U-Boot based on CONFIG_ symbols. Are we going to have to create an SPL version of each of them, too? And a third version of each symbol, for a three-stage boot? Are you going to insist that we rip out all the other CONFIG_ symbols that are conditional on NAND_SPL (but happen to not be referred to in makefiles -- is that really the meaningful semantic difference here)? CONFIG_SYS_HRCW_HIGH versus CONFIG_SYS_HRCW_HIGH_SPL? CONFIG_DEFAULT_IMMR versus CONFIG_DEFAULT_IMMR_SPL? Should we replace CONFIG_NS16550_MIN_FUNCTIONS with directly ifdeffing NAND_SPL in the serial code? Lets get rid of this mess, and use a separate variable for each separate purpose. It is the same purpose. The problem is treating separate, only somewhat related image builds as being the same build and requiring that they have the same config. They have separate makefiles, separate linker scripts, separate everything except some shared code... and autoconf.mk. Just because we got away with it until now does not make it the right thing to do. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Scott Wood, In message 20101109143747.685f9...@udp111988uds.am.freescale.net you wrote: I don't see how #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #else #define CONFIG_SYS_TEXT_BASE yyy #endif is more of a maintenance problem than #define CONFIG_SYS_TEXT_BASE_SPL xxx #define CONFIG_SYS_TEXT_BASE yyy followed by multiple instances of #ifdef NAND_SPL do something with CONFIG_SYS_TEXT_BASE_SPL #else do something with CONFIG_SYS_TEXT_BASE #endif Assuming that your code really needs to know the start address of the image, it should probably do something like this instead: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #else #define CONFIG_SYS_TEXT_BASE yyy #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #endif followed by multiple instances of do something with CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE is a symbos primarily intended for the linker call, i. e. for Makefile context. This is a pretty special situation, that does not apply to normal CONFIG_* settings. And as I've pointed out, this gets to be an even bigger mess with larger SPLs that want to pull in bigger chunks of U-Boot based on CONFIG_ symbols. Are we going to have to create an SPL version of each of them, too? And a third version of each symbol, for a three-stage boot? I don't see why that should be the case? AFAICT so far CONFIG_SYS_TEXT_BASE is one of a very small number of highly special variable definitions that need to be exported to the Makefile context. Are you going to insist that we rip out all the other CONFIG_ symbols that are conditional on NAND_SPL (but happen to not be referred to in makefiles -- is that really the meaningful semantic difference here)? CONFIG_SYS_HRCW_HIGH versus CONFIG_SYS_HRCW_HIGH_SPL? CONFIG_DEFAULT_IMMR versus CONFIG_DEFAULT_IMMR_SPL? Why should I? None of these are needed anywhere in the Makefiles, are they? Should we replace CONFIG_NS16550_MIN_FUNCTIONS with directly ifdeffing NAND_SPL in the serial code? I think you misinterpret the situation. It is the same purpose. The problem is treating separate, only somewhat related image builds as being the same build and requiring that they have the same config. They have separate makefiles, separate linker scripts, separate everything except some shared code... and autoconf.mk. Just because we got away with it until now does not make it the right thing to do. Right - separate makefiles, separate linker scripts, separate everything _and_ separate text base addresses. 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 didn't know it was impossible when I did it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 2010-11-09 at 14:11 -0700, Wolfgang Denk wrote: Dear Scott Wood, In message 20101109143747.685f9...@udp111988uds.am.freescale.net you wrote: I don't see how #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #else #define CONFIG_SYS_TEXT_BASE yyy #endif is more of a maintenance problem than #define CONFIG_SYS_TEXT_BASE_SPL xxx #define CONFIG_SYS_TEXT_BASE yyy followed by multiple instances of #ifdef NAND_SPL do something with CONFIG_SYS_TEXT_BASE_SPL #else do something with CONFIG_SYS_TEXT_BASE #endif Assuming that your code really needs to know the start address of the image, it should probably do something like this instead: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #else #define CONFIG_SYS_TEXT_BASE yyy #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #endif This doesn't make sense if there is still one autoconfig.mk. The value for CONFIG_SYS_TEXT_BASE will always be yyy for NAND_SPL. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Haiying Wang, In message 1289337782.2168.148.ca...@haiying-laptop you wrote: Assuming that your code really needs to know the start address of the image, it should probably do something like this instead: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #else #define CONFIG_SYS_TEXT_BASE yyy #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #endif This doesn't make sense if there is still one autoconfig.mk. The value for CONFIG_SYS_TEXT_BASE will always be yyy for NAND_SPL. right. Sorry, I copied the wrong lines. What I meant was this: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE_SPL xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE_SPL #else #define CONFIG_SYS_TEXT_BASE yyy #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #endif 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 Q: What do you get when you cross an ethernet with an income statement? A: A local area networth. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 22:11:41 +0100 Wolfgang Denk w...@denx.de wrote: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE_SPL xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE_SPL #else #define CONFIG_SYS_TEXT_BASE yyy #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #endif followed by multiple instances of do something with CONFIG_SYS_MONITOR_BASE What, semantically, is the difference between the CONFIG_SYS_TEXT_BASE and CONFIG_SYS_MONITOR_BASE? Just that one is used from linker scripts/makefiles and the other from C/assembly code (and if you get it wrong, you may silently get the wrong value instead of a linker error)? Isn't the whole point of a special CONFIG_ namespace that gets exported to autoconf.mk so that the same symbol could be defined once, possibly based on ifdefs in the board config file, and used for both? CONFIG_SYS_TEXT_BASE is a symbos primarily intended for the linker call, i. e. for Makefile context. This is a pretty special situation, that does not apply to normal CONFIG_* settings. It does apply to normal CONFIG_ settings if we ever want to use them in a makefile, such as to decide which files to pull in. These 4K NAND SPLs are small and simple enough that we generally don't do that now, but I believe Haiying ran into this when trying to create a larger middle stage that runs out of SRAM. I suppose we could have no sharing of makefile fragments with that stage, and rely on the final U-boot's settings going into config.mk -- as long as we don't need to make the file conditional in the middle-stage makefile except in cases where it always matches the final stage config. Not pretty. Are you going to insist that we rip out all the other CONFIG_ symbols that are conditional on NAND_SPL (but happen to not be referred to in makefiles -- is that really the meaningful semantic difference here)? CONFIG_SYS_HRCW_HIGH versus CONFIG_SYS_HRCW_HIGH_SPL? CONFIG_DEFAULT_IMMR versus CONFIG_DEFAULT_IMMR_SPL? Why should I? None of these are needed anywhere in the Makefiles, are they? No, which is why they didn't break anything -- but why does that matter, if your argument is that they semantically should be separate symbols and that the ifdef is the problem? If your argument is that providing a separate autoconf.mk is a pain[1], and you'd rather hack around it with a separate symbol in the one case where it currently matters, I can understand that -- though that leaves pain lurking for the larger middle stage, as noted above. I don't see from a conceptual level, though, why these images should be sharing an autoconf.mk. -Scott [1] How much of a pain is it? It's already a separate make invocation, so pulling the new set of symbols into make shouldn't be a problem, as long as they symbols aren't exported. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Scott Wood, In message 20101109155225.183a3...@udp111988uds.am.freescale.net you wrote: What, semantically, is the difference between the CONFIG_SYS_TEXT_BASE and CONFIG_SYS_MONITOR_BASE? Just that one is used from linker Nothing. scripts/makefiles and the other from C/assembly code (and if you get it wrong, you may silently get the wrong value instead of a linker error)? You are absolutely right. This is the reason why I object against redefining CONFIG_SYS_TEXT_BASE and suggest to use a separate CONFIG_SYS_TEXT_BASE_SPL instead. Isn't the whole point of a special CONFIG_ namespace that gets exported to autoconf.mk so that the same symbol could be defined once, possibly based on ifdefs in the board config file, and used for both? Correct. CONFIG_SYS_TEXT_BASE is a symbos primarily intended for the linker call, i. e. for Makefile context. This is a pretty special situation, that does not apply to normal CONFIG_* settings. It does apply to normal CONFIG_ settings if we ever want to use them in a makefile, such as to decide which files to pull in. These 4K NAND SPLs are small and simple enough that we generally don't do that now, but I believe Haiying ran into this when trying to create a larger middle stage that runs out of SRAM. I suppose we could have no sharing of makefile fragments with that stage, and rely on the final U-boot's settings going into config.mk -- as long as we don't need to make the file conditional in the middle-stage makefile except in cases where it always matches the final stage config. Not pretty. Full agreement. Assume you would accept to use a separate CONFIG_SYS_TEXT_BASE_SPL - which of the problems you listed would remain? No, which is why they didn't break anything -- but why does that matter, if your argument is that they semantically should be separate symbols and that the ifdef is the problem? It seems you are in fighting mood today. I ain't. You try to turn my own arguments against me. I'm not willing to play such a game. If your argument is that providing a separate autoconf.mk is a pain[1], and you'd rather hack around it with a separate symbol in the one case where it currently matters, I can understand that -- though that leaves pain lurking for the larger middle stage, as noted above. Maybe you could be so kind and elucidate why you think that 1) using separate variable names for separate purposes is hacking around? 2) changing make variable settings on the fly during a single make run would be a clean solution? I see a lot of potential problems with that. I don't see from a conceptual level, though, why these images should be sharing an autoconf.mk. To provide a consistent and debuggable build environment? I have zero interest in debugging the Makefiles for such a build for example on a SMP system which attempts to run these steps in parallel. Oh, of course we must not do that, we must serialize everything? You will need really good arguments to convince me that switching the build environment on the fly is conceptually clean or a clever thing to do. [1] How much of a pain is it? It's already a separate make invocation, so pulling the new set of symbols into make shouldn't be a problem, as long as they symbols aren't exported. It will be a pain to debug if there are any problems. What we have now is already complex enough. If you want to improve the code then pelase help making it simpler. Please do not case make it more complex. 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 something is different, it's either better or worse, and usually both.- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_mmc: fix compile warning
On Tuesday, November 09, 2010 10:18:42 Lei Wen wrote: Hi Mike, please dont top post I am sorry for that... Here is the warning: env_mmc.c: In function 'saveenv': env_mmc.c:109: warning: implicit declaration of function 'hexport' please resend your patch with an updated changelog -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] RFC: Aligning arch initialisation sequences
On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote: Should all architectures strive to look as much like one another as possible? Should we accept that maybe this particular issue be thrown in the too hard basket? imo, we should strive to have these things in one common place and not just have the different files look the sam -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] env_mmc: fix compile warning
Hi Mike, Please review this refined patch. From a7c694f84bec6b0db26ece4c77d06585be5a6755 Mon Sep 17 00:00:00 2001 From: Lei Wen lei...@marvell.com Date: Wed, 10 Nov 2010 07:44:03 +0800 Subject: [PATCH] env_mmc: fix compile warning hexport would complain implicit declaration, if we don't add the include file. env_mmc.c: In function 'saveenv': env_mmc.c:109: warning: implicit declaration of function 'hexport' Signed-off-by: Lei Wen lei...@marvell.com --- common/env_mmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/common/env_mmc.c b/common/env_mmc.c index 3d7fceb..7c9392c 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -29,6 +29,7 @@ #include linux/stddef.h #include malloc.h #include mmc.h +#include search.h #include errno.h /* references to names in env_common.c */ -- 1.7.0.4 Best regards, Lei 0001-env_mmc-fix-compile-warning.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_mmc: fix compile warning
On Tuesday, November 09, 2010 18:39:23 Lei Wen wrote: Hi Mike, Please review this refined patch. thanks, this looks much better not that ive ever used env_mmc, so i cant comment on correctness of it -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 V4 1/2] arm926ejs: fix linker file for newer ld support
I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Today, I decided to try out Sebastien Carlier's patch to change to partial linking, and to my surprise it now works. I have the two ELF images in case anyone can suggest what I should look for to see why one is working and the other isn't. But I don't know much about interpreting readelf or objdump output. Also, I'd like to resubmit the latest version of the DockStar patch to the list. Should I base it on the partial-linking patch, or on master (knowing that it may not produce a working build in this case)? -- Eric Cooper e c c @ c m u . e d u ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Commit ecee9... (Program net device MAC addresses after initializing) breakage
On Saturday, November 06, 2010 18:13:08 Graeme Russ wrote: I finally got a few spare hours to do some U-Boot hacking and to my dismay found the build for my board (eNET) had broken. It builds OK, but crashed during Ethernet initialisation. I tried winding back to a last known good commit without much luck. I realised I had upgraded to Ubuntu 10.10 lately, and thought maybe a tool-chain change was the culprit (was running gcc-4.4.1 and binutils 2.19 from source, now running Ubuntu gcc 4.4.5 and Binutils 2.20) But, I think that commit ecee9324d73555e744593f3e0d387bec4c566f55 may be 'not quite right'. My board uses the rtl8139 driver, and the following patch gets my board booting again: Just before this code we see that dev is malloc'd: dev = (struct eth_device *)malloc(sizeof *dev); So there is no guarantee that dev is NULL'd. rtl8139 is broken. it should be clearing its memory. someone posted a whole bunch of patches to memset() net drivers ... I saw discussion a little while ago regarding implementing a version of malloc that returns cleared memory - did this gain any traction? i dont think anyone posted a patch. it would make sense though to generalize the zalloc() code since some places are already doing it. -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] Switch from library archives to partial linking
On Sunday, November 07, 2010 10:11:14 Sebastien Carlier wrote: On 11/07/2010 03:16 PM, Peter Tyser wrote: I'm guessing lots of boards will have this same issue. I imagine its due to include/config_cmd_defaults.h, so maybe if you fix the issue in that one place all the compile issues will go away. The generic fix is to include the following lines somewhere at the end of the config.h generated in the mkconfig script: #ifndef CONFIG_CMD_NET # undef CONFIG_CMD_NFS #endif These lines should probable be put in a new header file; would config_checks.h be an ok name for it? I suppose there might be other cases where a module (that is included by default) needs to be excluded when one of its dependencies is disabled. i dont like this sort of magc undoing of defaults. update the board configs instead to undef NFS. -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] Switch from archive libraries to partial linking
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote: This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired. wish we could integrate this into one place already. all these Makefile's duplicating targets sucks a lot. but guess that could be a future change. the config.mk looks weird: +cmd_link_o_target = $(if $(strip $1),\ + $(LD) -r -o $@ $1 ,\ + rm -f $@; $(AR) rcs $@ ) why do you need the rm/ar ? post/board/lwmon/Makefile |2 +- post/board/lwmon5/Makefile|2 +- post/board/netta/Makefile |2 +- post/board/pdm360ng/Makefile |2 +- post/cpu/mpc83xx/Makefile |2 +- post/cpu/mpc8xx/Makefile |2 +- post/cpu/ppc4xx/Makefile |2 +- post/drivers/Makefile |2 +- post/lib_powerpc/Makefile |2 +- post/lib_powerpc/fpu/Makefile |2 +- post/rules.mk |2 +- these look like useless whitespace changes. a lot of the LIB= changes have similar useless changes. looks like your sed needs a little more smarts to retain whitespace: -e '/^LIB/s:[.]a$:.o:' -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 V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 00:43, Eric Cooper a écrit : I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Today, I decided to try out Sebastien Carlier's patch to change to partial linking, and to my surprise it now works. I have the two ELF images in case anyone can suggest what I should look for to see why one is working and the other isn't. But I don't know much about interpreting readelf or objdump output. Can you make the ELF images available? I'll do the readlf/objdump analysis and feed back on what I find. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
