[U-Boot] [PATCH] env: don't generate callback list entries for SPL
SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations.
A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings.
Signed-off-by: Scott Wood scottwood@freescale.com --- include/env_callback.h | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/include/env_callback.h b/include/env_callback.h index 47fdc6f..c583120 100644 --- a/include/env_callback.h +++ b/include/env_callback.h @@ -68,8 +68,16 @@ void env_callback_init(ENTRY *var_entry); * when associated through the ".callbacks" environment variable, the callback * will be executed any time the variable is inserted, overwritten, or deleted. */ +#ifdef CONFIG_SPL_BUILD +#define U_BOOT_ENV_CALLBACK(name, callback) \ + static inline void _u_boot_env_noop_##name(void) \ + { \ + (void)callback; \ + } +#else #define U_BOOT_ENV_CALLBACK(name, callback) \ ll_entry_declare(struct env_clbk_tbl, name, env_clbk, env_clbk) = \ {#name, callback} +#endif
#endif /* __ENV_CALLBACK_H__ */
Hi Scott,
On Fri, Dec 14, 2012 at 6:54 PM, Scott Wood scottwood@freescale.com wrote:
SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations.
A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings.
Signed-off-by: Scott Wood scottwood@freescale.com
Sorry about that.
Acked-by: Joe Hershberger joe.hershberger@ni.com
On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote:
SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations.
SPL with networking support uses the environment, so you need to toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not an interactive environment and this might push that area over the size limit too (in the USB case, which is already pretty tight).
On 12/17/2012 08:52:59 AM, Tom Rini wrote:
On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote:
SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will
look at
the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations.
SPL with networking support uses the environment, so you need to toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not an interactive environment and this might push that area over the size limit too (in the USB case, which is already pretty tight).
OK, I saw "env_*" stuff in the "ifndef CONFIG_SPL_BUILD" section, but later some of it shows up in "ifdef CONFIG_SPL_BUILD" as well.
So, do you want a v2, or is it OK because it's not interactive? In the latter case should env_callback.o be removed from the SPL build?
Also, env_nvedit.o, env_common.o, and env_flash.o are included for SPL regardless of CONFIG_SPL_NET_SUPPORT. In fact it looks like env_nvedit.o will be included twice if CONFIG_SPL_NET_SUPPORT is enabled. :-P
-Scott
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/17/12 13:53, Scott Wood wrote:
On 12/17/2012 08:52:59 AM, Tom Rini wrote:
On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote:
SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will
look at
the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations.
SPL with networking support uses the environment, so you need to toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not an interactive environment and this might push that area over the size limit too (in the USB case, which is already pretty tight).
OK, I saw "env_*" stuff in the "ifndef CONFIG_SPL_BUILD" section, but later some of it shows up in "ifdef CONFIG_SPL_BUILD" as well.
So, do you want a v2, or is it OK because it's not interactive? In the latter case should env_callback.o be removed from the SPL build?
Lets do a v2 (since the commit message would have been wrong) and add in a comment saying SPL doesn't have interactive environment, so we don't need this code.
Also, env_nvedit.o, env_common.o, and env_flash.o are included for SPL regardless of CONFIG_SPL_NET_SUPPORT. In fact it looks like env_nvedit.o will be included twice if CONFIG_SPL_NET_SUPPORT is enabled. :-P
Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's filtering out the dupes unless we don't really need it afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious now, so I'm poking it.
- -- Tom
Dear Tom,
In message 50CF6EA8.4050200@ti.com you wrote:
Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's filtering out the dupes unless we don't really need it afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious now, so I'm poking it.
Wrong assumption.
RTFM shows:
`$(sort LIST)' Sorts the words of LIST in lexical order, removing duplicate words. The output is a list of words separated by single spaces. Thus,
$(sort foo bar lose)
returns the value `bar foo lose'.
Incidentally, since `sort' removes duplicate words, you can use it for this purpose even if you don't care about the sort order.
Best regards,
Wolfgang Denk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/17/12 14:55, Wolfgang Denk wrote:
Dear Tom,
In message 50CF6EA8.4050200@ti.com you wrote:
Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's filtering out the dupes unless we don't really need it afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious now, so I'm poking it.
Wrong assumption.
RTFM shows:
`$(sort LIST)' Sorts the words of LIST in lexical order, removing duplicate words. The output is a list of words separated by single spaces. Thus,
$(sort foo bar lose)
returns the value `bar foo lose'.
Incidentally, since `sort' removes duplicate words, you can use it for this purpose even if you don't care about the sort order.
Which means the Makefile is just a tad messy instead, thanks.
- -- Tom
Hi Tom,
On Mon, Dec 17, 2012 at 1:58 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/17/12 14:55, Wolfgang Denk wrote:
Dear Tom,
In message 50CF6EA8.4050200@ti.com you wrote:
Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's filtering out the dupes unless we don't really need it afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious now, so I'm poking it.
Wrong assumption.
RTFM shows:
`$(sort LIST)' Sorts the words of LIST in lexical order, removing duplicate words. The output is a list of words separated by single spaces. Thus,
$(sort foo bar lose)
returns the value `bar foo lose'.
Incidentally, since `sort' removes duplicate words, you can use it for this purpose even if you don't care about the sort order.
Not only can you, that's the only reason it's added to those Makefiles.
Which means the Makefile is just a tad messy instead, thanks.
-Joe
participants (4)
-
Joe Hershberger -
Scott Wood -
Tom Rini -
Wolfgang Denk