Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
On Tue, 9 Nov 2010 23:22:26 +0100 Wolfgang Denk w...@denx.de wrote: 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. It'd still be only a runtime error if you used the wrong one. Whereas by keeping each image's config separate it simply isn't an error -- you will get the right value. Perhaps symbols that aren't safe to use from makefiles/linker scripts shouldn't have the CONFIG_ prefix (and thus not be exported to them). 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. I was just looking for some consistency so I could figure out what is being objected to. When something is rejected for specific reasons, questioning whether those reasons actually imply the conclusion doesn't seem unreasonable. I wasn't trying to pick a fight -- if you feel this strongly about doing it that way, then we can live with it. 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? I do not agree that they are separate purposes. All config symbols make sense only in the context of the image that is being built. I suppose it depends on whether you view SPL as this other bit of code that gets distributed with u-boot and tied into the build system, and reuses some files or a u-boot configuration which is extremely slimmed down and targetting a different boot environment. 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. It is not a single make run. SPL is a separate, recursive invocation of make. As far as I can see the CONFIG_ variables are not exported. 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? That's precisely why I wanted them separate. :-) It keeps the CONFIG_ namespace consistent between C code and makefiles, and avoids interference from one component to the next. 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? Parallel builds should work fine. It would be a separate autoconf.mk file somewhere under nand_spl, not rewriting the same file multiple times during the build process. -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 20101110150307.279a5...@udp111988uds.am.freescale.net you wrote: I was just looking for some consistency so I could figure out what is being objected to. When something is rejected for specific reasons, questioning whether those reasons actually imply the conclusion doesn't seem unreasonable. I fully agree with you on that. And I want to point out that I really appreciate such discussions. I definitely don't claim to be always right (but when I have my mind set it takes really good arguments). I wasn't trying to pick a fight -- if you feel this strongly about doing it that way, then we can live with it. Actually I am not that seriously convinced. I just fear that the other approach introduces a LOT of trouble - way more problems then it ever could solve. I suppose it depends on whether you view SPL as this other bit of code that gets distributed with u-boot and tied into the build system, and reuses some files or a u-boot configuration which is extremely slimmed down and targetting a different boot environment. For me it is just a part of U-Boot. Usually we do not use separate images, resulting from separate builds, but the SPL and the real U-Boot image get bundled into one NAND boot image. So for me it seems obvious that these are all just stages of a single build. 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. It is not a single make run. SPL is a separate, recursive invocation of make. As far as I can see the CONFIG_ variables are not exported. Well, see above. You are argumenting from a low-level, implementation point of view. For the end user this is not transparent at all. He just runs a single make foo_config and a single make all. The end user sees and thinks of just a single configuration and a single build he is running. The fact that we have several build steps is something else. I understand (now, only now!) that you see the SPL part as an independent configuration - such a thought never crossed my mind before. For me it's just a part of the whole build procedure. To provide a consistent and debuggable build environment? That's precisely why I wanted them separate. :-) It keeps the CONFIG_ namespace consistent between C code and makefiles, and avoids interference from one component to the next. I cannot follow you here. I get the creeps when I imagine to have to track down why a build fails when parameters change on the fly. Did you ever have to track down why some boared config can be build nicely in-tree, but out-of-tree builds fail, but only on SMP machines? and only with N cores (or fast disks)? I have been there. And I do not want to imagine that the whole environment might change under my feet before I can grab it. 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? Parallel builds should work fine. It would be a separate autoconf.mk file somewhere under nand_spl, not rewriting the same file multiple times during the build process. Oh... this is another thing I did not grasp yet. But then, how would it become active for common code parts? 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 In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur ___ 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 Wed, 10 Nov 2010 22:28:29 +0100 Wolfgang Denk w...@denx.de wrote: Well, see above. You are argumenting from a low-level, implementation point of view. For the end user this is not transparent at all. He just runs a single make foo_config and a single make all. The end user sees and thinks of just a single configuration and a single build he is running. Well, from the user's perspective hopefully they just build it and it all works. :-) I think this is a question of internals. Parallel builds should work fine. It would be a separate autoconf.mk file somewhere under nand_spl, not rewriting the same file multiple times during the build process. Oh... this is another thing I did not grasp yet. But then, how would it become active for common code parts? Anything in the top-level makefile would get the main u-boot image's config. Common parts such as config.mk operate in the context they're included into -- they're already separately included into the SPL makefile. It looks like there are a few uses of CONFIG_SYS_TEXT_BASE in the toplevel makefile for constructing things like u-boot.img. We don't do that for NAND; if we wanted to, and had a separate autoconf.mk, we'd want to move the final u-boot-nand image assembly into the SPL makefile. -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 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] 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] 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] 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] 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] 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] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Wolfgang, On Sun, 2010-11-07 at 14:31 -0700, Wolfgang Denk wrote: Dear Haiying Wang, In message 1288970062.1855.44.ca...@haiying-laptop you wrote: Wolfgang's latest commit to change all TEXT_BASE to CONFIG_SYS_TEXT_BASE breaks the build for nand_spl. He defined CONFIG_SYS_TEXT_BASE in board Which board(s) / configuration(s) are you talkign about? I meant freescale 8536/8569/p1_p2 boards, and their NAND_config build. header file for CONFIG_NAND, and renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE in nand_spl/board/.../Makefile. Then for u-boot-spl, the CONFIG_SYS_TEXT_BASE is always the value defined in header file, which is, for example, 0xf8f82000 for MPC8536/8569/p1_p2/, not the one defined in nand-spl's Makefile, which is 0xfff0. Thus it It is fundamentally broken to define such settings in a Makefile. They do not belong there, an never did. If you take for example the MPC8536DS_NAND configuration, this defines CONFIG_NAND as indication for the NAND booting config option, so it should be trivial to add some #ifdef CONFIG_NAND #define CONFIG_SYS_TEXT_BASE ... #else #define CONFIG_SYS_TEXT_BASE ... #endif to the respective board config file(s). Before sending last email, I modified the CONFIG_SYS_TEXT_BASE in 8536DS header file like this: #ifdef CONFIG_NAND #ifdef CONFIG_NAND_SPL #define CONFIG_SYS_TEXT_BASE 0xfff0 #else #define CONFIG_SYS_TEXT_BASE 0xf8f82000 #endif #endif but still get 0xf8f82000 for NAND SPL image, which should have 0xfff0 as its CONFIG_SYS_TEXT_BASE. And build log showed me warning: CONFIG_SYS_TEXT_BASE redefined In fact, your change above seems no meaning for NAND _SPL because NAND_SPL also has CONFIG_NAND defined. Can you take a look at it? Defining CONFIG_SYS_TEXT_BASE in header file does impact the TEXT_BASE defined in Makefile for nand_spl. Please remove any such defines from Makefiles. You meant the CONFIG_SYS_TEXT_BASE can only be defined in board header files? But you change all the TEXT_BASE to CONFIG_SYS_TEXT_BASE in the Makefile or config.mk for almost all boards under nand_spl, which I guess you were OK with it.:) I did not understand why old way to define TEXT_BASE in Makefile worked but changing it to CONFIG_SYS_TEXT_BASE doesn't work any more. And as you pointed out, defining CONFIG_SYS_TEXT_BASE in header file is the right way, but it did not work for nans_spl for now. Thanks. 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 1289230710.1900.27.ca...@haiying-laptop you wrote: Before sending last email, I modified the CONFIG_SYS_TEXT_BASE in 8536DS header file like this: #ifdef CONFIG_NAND #ifdef CONFIG_NAND_SPL #define CONFIG_SYS_TEXT_BASE 0xfff0 #else #define CONFIG_SYS_TEXT_BASE 0xf8f82000 #endif #endif This looks broken to me. If you have CONFIG_NAND not defined you have no CONFIG_SYS_TEXT_BASE definition at all. but still get 0xf8f82000 for NAND SPL image, which should have 0xfff0 as its CONFIG_SYS_TEXT_BASE. And build log showed me warning: CONFIG_SYS_TEXT_BASE redefined Well, I guess it also showed where the previous definition came from? In fact, your change above seems no meaning for NAND _SPL because NAND_SPL also has CONFIG_NAND defined. Well, then your bord entry in boards.cfg makes no sense. The NAND-booting board configurations auto-define CONFIG_NAND. If this is not what you want then please feel free to change it. Please remove any such defines from Makefiles. You meant the CONFIG_SYS_TEXT_BASE can only be defined in board header files? But you change all the TEXT_BASE to CONFIG_SYS_TEXT_BASE in the Makefile or config.mk for almost all boards under nand_spl, which I guess you were OK with it.:) If there is any such code left, it should be cleaned up. I did not understand why old way to define TEXT_BASE in Makefile worked but changing it to CONFIG_SYS_TEXT_BASE doesn't work any more. And as you pointed out, defining CONFIG_SYS_TEXT_BASE in header file is the right way, but it did not work for nans_spl for 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. 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 Copy from one, it's plagiarism; copy from two, it's research. ___ 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 Mon, 2010-11-08 at 09:30 -0700, Wolfgang Denk wrote: Dear Haiying Wang, In message 1289230710.1900.27.ca...@haiying-laptop you wrote: Before sending last email, I modified the CONFIG_SYS_TEXT_BASE in 8536DS header file like this: #ifdef CONFIG_NAND #ifdef CONFIG_NAND_SPL #define CONFIG_SYS_TEXT_BASE 0xfff0 #else #define CONFIG_SYS_TEXT_BASE 0xf8f82000 #endif #endif This looks broken to me. If you have CONFIG_NAND not defined you have no CONFIG_SYS_TEXT_BASE definition at all. 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 which should have CONFIG_SYS_TEXT_BASE at 0xfff0, the other is the final uboot image which has CONFIG_SYS_TEXT_BASE at 0xf8f82000. Both CONFIG_SYS_TEXT_BASE are now under the define of CONFIG_NAND. but still get 0xf8f82000 for NAND SPL image, which should have 0xfff0 as its CONFIG_SYS_TEXT_BASE. And build log showed me warning: CONFIG_SYS_TEXT_BASE redefined 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. In fact, your change above seems no meaning for NAND _SPL because NAND_SPL also has CONFIG_NAND defined. Well, then your bord entry in boards.cfg makes no sense. The NAND-booting board configurations auto-define CONFIG_NAND. If this is not what you want then please feel free to change it. Yes, 8356DS's board entry in boards.cfg does make sense. It has CONFIG_NAND defined for MPC8536DS_NAND_config. Again, CONFIG_NAND means two stage uboot image needs to be generated, each of them has different CONFIG_SYS_TEXT_BASE. I think the previous uboot(before your commit to change CONFIG_MK to CONFIG_), CONFIG_MK_NAND was used for NAND_booting board configuration, 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. Please remove any such defines from Makefiles. You meant the CONFIG_SYS_TEXT_BASE can only be defined in board header files? But you change all the TEXT_BASE to CONFIG_SYS_TEXT_BASE in the Makefile or config.mk for almost all boards under nand_spl, which I guess you were OK with it.:) If there is any such code left, it should be cleaned up. Yes, there is such code. I did not understand why old way to define TEXT_BASE in Makefile worked but changing it to CONFIG_SYS_TEXT_BASE doesn't work any more. And as you pointed out, defining CONFIG_SYS_TEXT_BASE in header file is the right way, but it did not work for nans_spl for 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. In summary, the problem is how the 2 uboot images(nand_spl and final uboot image) can get different CONFIG_SYS_TEXT_BASE under the shared CONFIG_NAND. 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 1289240747.1900.58.ca...@haiying-laptop you wrote: Before sending last email, I modified the CONFIG_SYS_TEXT_BASE in 8536DS header file like this: #ifdef CONFIG_NAND #ifdef CONFIG_NAND_SPL #define CONFIG_SYS_TEXT_BASE 0xfff0 #else #define CONFIG_SYS_TEXT_BASE 0xf8f82000 #endif #endif This looks broken to me. If you have CONFIG_NAND not defined you have no CONFIG_SYS_TEXT_BASE definition at all. 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. 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. I think the previous uboot(before your commit to change CONFIG_MK to CONFIG_), CONFIG_MK_NAND was used for NAND_booting board configuration, Correct. 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? 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). In summary, the problem is how the 2 uboot images(nand_spl and final uboot image) can get different CONFIG_SYS_TEXT_BASE under the shared CONFIG_NAND. It seems your actual code looks different from what you showed us above. 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 In Nature there are neither rewards nor punishments, there are conse- quences.-- R.G. Ingersoll ___ 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 1288970062.1855.44.ca...@haiying-laptop you wrote: Wolfgang's latest commit to change all TEXT_BASE to CONFIG_SYS_TEXT_BASE breaks the build for nand_spl. He defined CONFIG_SYS_TEXT_BASE in board Which board(s) / configuration(s) are you talkign about? header file for CONFIG_NAND, and renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE in nand_spl/board/.../Makefile. Then for u-boot-spl, the CONFIG_SYS_TEXT_BASE is always the value defined in header file, which is, for example, 0xf8f82000 for MPC8536/8569/p1_p2/, not the one defined in nand-spl's Makefile, which is 0xfff0. Thus it It is fundamentally broken to define such settings in a Makefile. They do not belong there, an never did. If you take for example the MPC8536DS_NAND configuration, this defines CONFIG_NAND as indication for the NAND booting config option, so it should be trivial to add some #ifdef CONFIG_NAND #define CONFIG_SYS_TEXT_BASE ... #else #define CONFIG_SYS_TEXT_BASE ... #endif to the respective board config file(s). Can you take a look at it? Defining CONFIG_SYS_TEXT_BASE in header file does impact the TEXT_BASE defined in Makefile for nand_spl. Please remove any such defines from Makefiles. 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 All this doesn't alter anything, you know. The world is still full of stupid people. They don't use their brains. They don't seem to want to think straight.- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Hi Scott, Wolfgang's latest commit to change all TEXT_BASE to CONFIG_SYS_TEXT_BASE breaks the build for nand_spl. He defined CONFIG_SYS_TEXT_BASE in board header file for CONFIG_NAND, and renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE in nand_spl/board/.../Makefile. Then for u-boot-spl, the CONFIG_SYS_TEXT_BASE is always the value defined in header file, which is, for example, 0xf8f82000 for MPC8536/8569/p1_p2/, not the one defined in nand-spl's Makefile, which is 0xfff0. Thus it causes the nand_spl image has wrong address from 0xf8f82000. When PAD_TO 0xfff01000, the final u-boot-spl-16k.bin will be 112M bytes. I think 83xx nand_spl might have the similar problem, but as I built 8315erdb's nand, it failed for some other multiple define for undef errors. Can you take a look at it? Defining CONFIG_SYS_TEXT_BASE in header file does impact the TEXT_BASE defined in Makefile for nand_spl. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
