[U-Boot] porting u-boot, few final questions

Nikolay Dimitrov picmaster at mail.bg
Mon Nov 10 18:54:40 CET 2014


Hi gents,

On 11/10/2014 06:04 PM, Fabio Estevam wrote:
> On Mon, Nov 10, 2014 at 1:47 PM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear Fabio Estevam,
>>
>> In message <CAOMZO5AiJtDt_CZrO6gzU=JiPp_2-etPiGFcK7ZhFhNNzxp3_A at mail.gmail.com> you wrote:
>>>
>>>> 1. How come setenv is not working in the board file? I tried setenv in
>>>> different locations of board_early_init_f(), board_init(), board_late_init()
>>>> and checkboard(), but it's not working. Did something change?
>>>
>>> Haven't tried it, but if this does not work, then it is a bug that
>>> needs to be fixed. Do you have access to a mx53 qsb board? Does it
>>> work there?
>>
>> Suffix _f trditionally means "running from flash", i. e. this is
>> before relocation to RAM. Here we have usually only a read-ony data
>> segment, no BSS at all, and only limted stack.  All complicated stuff
>> like setenv is only supposed to be available after relocation.
>
> Just tested on real hardware and the below change works:
>
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -404,6 +404,12 @@ int board_late_init(void)
>          return 0;
>   }
>
> +int misc_init_r(void)
> +{
> +       setenv("myvar", "123456");
> +       return 0;
> +}
> +
>   int checkboard(void)
>   {
>          puts("Board: MX53 LOCO\n");
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index a74508c..8f692d7 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -29,6 +29,7 @@
>
>   #define CONFIG_BOARD_EARLY_INIT_F
>   #define CONFIG_BOARD_LATE_INIT
> +#define CONFIG_MISC_INIT_R
>   #define CONFIG_MXC_GPIO
>   #define CONFIG_REVISION_TAG
>
>>
>>> On mx6 we have several boards calling setenv from the board files.
>>
>> Actual behaviour is hardware-dependent, but it's better not to make
>> any such guesses.
>
> Yes, but not sure how a mx6 can differ from a mx5 in getting setenv to work.

Please correct me if I'm wrong, but setting env-vars shouldn't work
before the environment is initialized. This initialization happens when
the initr_env() is called according the order in init_sequence_r[].

@Dave - the easiest way to verify when your code (which tries to work
with the env-vars) is executed and when the actual environment is
initialized, is to enable debugging in
lib/initcall.c:initcall_run_list(), see the pointers of the called
functions and check them in the System.map. The env is initialized in
the call tree below initr_env(), so your code should use the env after
that.

Regards,
Nikolay


More information about the U-Boot mailing list