another POST-related bit of pedantry, but i'm curious about the best
way to deal with the question in the subject.
i can see in include/post.h the logic involved in assigning a value
to the macro _POST_WORD_ADDR. first, deal with the trivial case:
#ifndef CONFIG_POST_EXTERNAL_WORD_FUNCS
#ifdef CONFIG_SYS_POST_WORD_ADDR
#define _POST_WORD_ADDR CONFIG_SYS_POST_WORD_ADDR
#else
...
at which point the subsequent preprocessor directives try to set
_POST_WORD_ADDR based on the target processor, as in:
#ifdef CONFIG_MPC5xxx
#define _POST_WORD_ADDR (MPC5XXX_SRAM + MPC5XXX_SRAM_POST_SIZE)
#elif defined(CONFIG_MPC512X)
#define _POST_WORD_ADDR \
(CONFIG_SYS_SRAM_BASE + CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
... and so on and so on ...
but here's the oddity.
as best as i can tell, all of those conditional assignments assign a
value to _POST_WORD_ADDR based on macros that have values based on
that target arch, until you get here:
#elif defined(CONFIG_MPC8260)
#include <asm/cpm_8260.h>
#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR)
#elif defined(CONFIG_MPC8360)
#include <linux/immap_qe.h>
#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR)
now the check for MPC8260 looks fine, since CONFIG_SYS_IMMR will
have a value, and the macro CPM_POST_WORD_ADDR is defined in
<asm/cpm_8260.h>, so no problem.
but in the next check for MPC8360, while that check includes the
header file <linux/immap_qe.h>, that header file does *not* define a
value for CPM_POST_WORD_ADDR. in fact, why is a check for MPC8360
making any reference to a CPM-related macro at all? that macro does
not seem to be assigned any value in the context of MPC8360. how can
that possibly expand correctly?
i puzzled over this for a bit wondering how it could *ever* work
until i stumbled over the following example in
include/configs/km8360.h:
/* enable POST tests */
#define CONFIG_POST (CONFIG_SYS_POST_MEMORY|CONFIG_SYS_POST_MEM_REGIONS)
#define CONFIG_POST_EXTERNAL_WORD_FUNCS /* use own functions, not generic */
#define CPM_POST_WORD_ADDR CONFIG_SYS_MEMTEST_END
well, ok, *now* it makes sense but that seems disgustingly hacky --
reusing a variable from 8260 and earlier that has no relevance to
MPC8360. there's certainly nothing in the README or elsewhere to warn
the developer that, for MPC8360, one might trip over that.
is there no cleaner way to do this? thoughts?
rday
p.s. i notice one other solution is what blackfin does in the header
file arch/blackfin/include/asm/config.h:
#ifndef CONFIG_SYS_POST_WORD_ADDR
# define CONFIG_SYS_POST_WORD_ADDR (L1_DATA_B_SRAM + L1_DATA_B_SRAM_SIZE - 4)
#endif
which seems perfectly reasonable.
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
