[U-Boot] [PATCH 1/8] mx28evk: Configure CONFIG_BOOTDELAY to one second

Otavio Salvador otavio at ossystems.com.br
Tue Nov 20 19:19:33 CET 2012


On Tue, Nov 20, 2012 at 4:09 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <sbabic at denx.de> wrote:
>> > On 20/11/2012 00:52, Marek Vasut wrote:
>> >> Dear Stefano Babic,
>> >>
>> >>> On 16/11/2012 16:09, Fabio Estevam wrote:
>> >>>> From: Fabio Estevam <fabio.estevam at freescale.com>
>> >>>>
>> >>>> One second is enough time for users to react in case they want to stop
>> >>>> the booting process.
>> >>>>
>> >>>> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
>> >>>> ---
>> >>>>
>> >>>>  include/configs/mx28evk.h |    2 +-
>> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>>
>> >>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
>> >>>> index 2916c71..8b89b25 100644
>> >>>> --- a/include/configs/mx28evk.h
>> >>>> +++ b/include/configs/mx28evk.h
>> >>>> @@ -238,7 +238,7 @@
>> >>>>
>> >>>>   */
>> >>>>
>> >>>>  #define CONFIG_CMDLINE_TAG
>> >>>>  #define CONFIG_SETUP_MEMORY_TAGS
>> >>>>
>> >>>> -#define CONFIG_BOOTDELAY   3
>> >>>> +#define CONFIG_BOOTDELAY   1
>> >>>>
>> >>>>  #define CONFIG_BOOTFILE    "uImage"
>> >>>>  #define CONFIG_LOADADDR    0x42000000
>> >>>>  #define CONFIG_SYS_LOAD_ADDR       CONFIG_LOADADDR
>> >>>
>> >>> Applied (whole series) to u-boot-imx, thanks.
>> >>
>> >> What about making some generic ... config-mx28.h AND config-fsl.h ...
>> >> and including those in board-specific configs?
>> >
>> > Any clean-up is welcome. Then maybe (and this is not related to i.MX
>> > only) we could have a cpu-config, a vendor config and on the top a board
>> > config.
>> >
>> > #include <cpu-config.h>
>> > #include <vendor-config.h>
>> > #include <board-config.h>
>> >
>> > The main problem is that an exception can breaks our castle, and we are
>> > constrained to add #undef in board configuration file.
>>
>> I support this idea; currently I think we ought to have as much as
>> common code by vendor so it is easy to document things and avoid
>> duplication.
>
> WFM
>
>> Currently we cannot expect a board to have same (or near the same) set
>> of features. Some provide a good default environment, others doesn't.
>
> Let's leave ENV out of this discussion. Moreover, this needs to be done in
> proper incremental steps.

So you prefer it to manage features only, at least for now?

> Furthermore, new thread should be started.

Agreed.

> Just an idea, to avoid undef in board-files, we can have #ifdef CONFIG...
> #define CONFIG... #endif constructions in the CPU-specific files. This will
> allow simple overriding (of course, these files would have to be included at the
> bottom of the board config file then).

So basically a global feature-aware setting file.

> Otavio, any plans to finish u-boot/mx23 soon?

No reply yet from the guy who got it further. I am almost getting onto
it without his patches ...

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br


More information about the U-Boot mailing list