On Tue, Nov 20, 2012 at 4:09 PM, Marek Vasut <[email protected]> wrote: > Dear Otavio Salvador, > >> On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <[email protected]> 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 <[email protected]> >> >>>> >> >>>> One second is enough time for users to react in case they want to stop >> >>>> the booting process. >> >>>> >> >>>> Signed-off-by: Fabio Estevam <[email protected]> >> >>>> --- >> >>>> >> >>>> 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: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
