[U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board.
The error message on build is -
board.c: In function '__dram_init_banksize': board.c:468: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) board.c:468: error: (Each undeclared identifier is reported only once board.c:468: error: for each function it appears in.) board.c: In function 'board_init_f': board.c:514: error: 'CONFIG_SYS_INIT_SP_ADDR' undeclared (first use in this function) board.c:547: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/devel/git-work/denx-uboot/arch/arm/lib' make: *** [arch/arm/lib/libarm.a] Error 2
The root-cause is-
+#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
The above definition is missing in all (zoom1, zoom2, evm, am3517evm, sdp3430, overo, Pandora) config files.
Am I missing something here? Just wanted to cross-check before posting patch to the list.
Thanks, Vaibhav
Le 03/10/2010 12:50, Hiremath, Vaibhav a écrit :
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board.
The error message on build is -
board.c: In function '__dram_init_banksize': board.c:468: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) board.c:468: error: (Each undeclared identifier is reported only once board.c:468: error: for each function it appears in.) board.c: In function 'board_init_f': board.c:514: error: 'CONFIG_SYS_INIT_SP_ADDR' undeclared (first use in this function) board.c:547: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/devel/git-work/denx-uboot/arch/arm/lib' make: *** [arch/arm/lib/libarm.a] Error 2
The root-cause is-
+#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
The above definition is missing in all (zoom1, zoom2, evm, am3517evm, sdp3430, overo, Pandora) config files.
Am I missing something here? Just wanted to cross-check before posting patch to the list.
This is due to the introduction of relocation on ARM platforms -- see Wolfgang's recent release announcement.
Note that adding the definition may not be sufficient to get relocation working.
Amicalement,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: Sunday, October 03, 2010 4:37 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Le 03/10/2010 12:50, Hiremath, Vaibhav a écrit :
Hi All,
I think the current denx/matser is broken and is not building up for
OMAP3 platforms except Beagle board.
The error message on build is -
board.c: In function '__dram_init_banksize': board.c:468: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in
this function)
board.c:468: error: (Each undeclared identifier is reported only once board.c:468: error: for each function it appears in.) board.c: In function 'board_init_f': board.c:514: error: 'CONFIG_SYS_INIT_SP_ADDR' undeclared (first use in
this function)
board.c:547: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in
this function)
make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/devel/git-work/denx-
uboot/arch/arm/lib'
make: *** [arch/arm/lib/libarm.a] Error 2
The root-cause is-
+#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK -
CONFIG_SYS_GBL_DATA_SIZE)
The above definition is missing in all (zoom1, zoom2, evm, am3517evm,
sdp3430, overo, Pandora) config files.
Am I missing something here? Just wanted to cross-check before posting
patch to the list.
This is due to the introduction of relocation on ARM platforms -- see Wolfgang's recent release announcement.
[Hiremath, Vaibhav] Yes that's correct. I am aware of that.
Note that adding the definition may not be sufficient to get relocation working.
[Hiremath, Vaibhav] But atleast it will make code to compile cleanly. I feel, at any cost we should not add such patches which will break compilation, the code should build always.
Thanks, Vaibhav
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear "Hiremath, Vaibhav",
In message 19F8576C6E063C45BE387C64729E739404AA21C4AC@dbde02.ent.ti.com you wrote:
Note that adding the definition may not be sufficient to get relocation working.
[Hiremath, Vaibhav] But atleast it will make code to compile cleanly. I feel, at any cost we should not add such patches which will break compilation, the code should build always.
If the code compiles without problems, but then fails to run, the situation would be only worse.
It is MUCH BETTER to roar a clear and unmistakable error message into the face of the user so everybody gets aware that some work needs to be done to fix these boards rather than to hush up the problems, in which case nobody would do anything, and a much bigger turmoil would start when the feature removel time comes and all these broken boards get removed from the tree,
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, October 04, 2010 12:08 AM To: Hiremath, Vaibhav Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Dear "Hiremath, Vaibhav",
In message 19F8576C6E063C45BE387C64729E739404AA21C4AC@dbde02.ent.ti.com you wrote:
Note that adding the definition may not be sufficient to get
relocation
working.
[Hiremath, Vaibhav] But atleast it will make code to compile cleanly. I
feel,
at any cost we should not add such patches which will break compilation, the code should build always.
If the code compiles without problems, but then fails to run, the situation would be only worse.
[Hiremath, Vaibhav] I agree that the situation in both the case is going to be only worst, but I feel we should not merge the patches which breaks other platforms.
Anyway I will test this for AM3517, OMAP3EVM and submit the patch shortly.
Thanks, Vaibhav
It is MUCH BETTER to roar a clear and unmistakable error message into the face of the user so everybody gets aware that some work needs to be done to fix these boards rather than to hush up the problems, in which case nobody would do anything, and a much bigger turmoil would start when the feature removel time comes and all these broken boards get removed from the tree,
[Hiremath, Vaibhav] I
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: wd@denx.de Was heißt Windows auf Indianisch? - "Weißer Mann, der auf Sanduhr wartet!"
Hello Hiremath,
Hiremath, Vaibhav wrote:
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board.
but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC
or compile with:
"CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board"
But be aware, this option wil be removed ...
bye, Heiko
On 2010/10/04 8:00 AM, Heiko Schocher wrote:
Hello Hiremath,
Hiremath, Vaibhav wrote:
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board.
but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC
or compile with:
"CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board"
But be aware, this option wil be removed ...
bye, Heiko
For what it is worth, would it be possible to have a more verbose error message that actually provides a reference to what needs to be done, rather than simply failing with an obscure message about DRAM configuration?
I ended up bisecting the tree to find the commit, and suitable references for what needs to be done to get a board working again, after searching "git log -p" for "SDRAM" got me nowhere.
Surely having e.g.
#if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif
would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords?
Regards,
Rogan
Hello Rogan,
Rogan Dawes wrote:
On 2010/10/04 8:00 AM, Heiko Schocher wrote:
Hello Hiremath,
Hiremath, Vaibhav wrote:
Hi All,
I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board.
but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC
or compile with:
"CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board"
But be aware, this option wil be removed ...
bye, Heiko
For what it is worth, would it be possible to have a more verbose error message that actually provides a reference to what needs to be done, rather than simply failing with an obscure message about DRAM configuration?
I ended up bisecting the tree to find the commit, and suitable references for what needs to be done to get a board working again, after searching "git log -p" for "SDRAM" got me nowhere.
Surely having e.g.
#if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif
would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords?
but that would result in editing *all* config files, which are not coverted.
bye, Heiko
Hi Heiko,
[...]
Surely having e.g.
#if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif
would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords?
but that would result in editing *all* config files, which are not coverted.
Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing?
Cheers Detlev
Dear Detlev Zundel,
In message m2hbh2ruux.fsf@ohwell.denx.de you wrote:
but that would result in editing *all* config files, which are not coverted.
Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing?
Any central place would catch _all_ files, but we need to make a difference between those that have already been converted, and those that have not yet. This _is_ indeed a board specific thing.
Best regards,
Wolfgang Denk
Hello Detlev,
Detlev Zundel wrote:
Hi Heiko,
[...]
Surely having e.g.
#if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif
would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords?
but that would result in editing *all* config files, which are not coverted.
Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing?
How would you detect there, if the config file (board.h) is converted for relocation and working or not? This help should only be printed if CONFIG_SYS_ARM_WITHOUT_RELOC is not defined and compiling fails ...
bye, Heiko
Hi Heiko,
Hello Detlev,
Detlev Zundel wrote:
Hi Heiko,
[...]
Surely having e.g.
#if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif
would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords?
but that would result in editing *all* config files, which are not coverted.
Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing?
How would you detect there, if the config file (board.h) is converted for relocation and working or not? This help should only be printed if CONFIG_SYS_ARM_WITHOUT_RELOC is not defined and compiling fails ...
Ok, I was only trying to be sure that this worthwhile thing is not easily possible.
To be honest, for me (as a bystander to this thread) I do not have a clear idea of the conditions to tell the cases apart so I cannot (easily) answer this question for myself.
Cheers Detlev
On Mon, 04 Oct 2010 08:40:36 +0200, Rogan Dawes rogan@dawes.za.net wrote:
For what it is worth, would it be possible to have a more verbose error message that actually provides a reference to what needs to be done, rather than simply failing with an obscure message about DRAM configuration?
Maybe something like a file called e.g. CommonErrors containing common build and runtime errors and an explanation what might be the problem. A simple grep in this file for a few keywords shown in the build or run failure might provide helpful info then.
Regards,
participants (7)
-
Albert ARIBAUD -
Bas Mevissen -
Detlev Zundel -
Heiko Schocher -
Hiremath, Vaibhav -
Rogan Dawes -
Wolfgang Denk