On 12.05.2017 21:59, Arthur Heymans wrote: > Hi > > In the latest CCM[1] the question was raised whether someone still uses > the configuration option baud_rate from RTC nvram (CMOS) and if not > maybe think about removing this. > > The issues raised with this code were: > * they are an extra burden to maintain since console init is done over > multiple stages and needs different code paths over ROMCC and GCC; > * Its not buildtested so easy to miss breakages; > * Many boards don't have an cmos.defaults so it often ends up at weird > settings. > > Granted many of these issues need separate fixing anyway: we need > cmos.default on each board that has cmos.layout, default Kconfig options > could be changed to build test this.
Are there any objections to enable USE_OPTION_TABLE by default if a cmos.default is available? That way we would spare us the hassle to maintain additional configs for build tests. > > So the question is: is someone still using the possibility to configure > uart baud rates from rtc nvram. (Keep in mind that is still possible to > set the default baud rate from Kconfig options) That we have two places to configure it, also creates confusion. Espe- cially because the Kconfig option is more visible but the NVRAM option overrides it. A good way to fix this would be to patch the cmos.default with the Kconfig choice. Even if we decide to remove `baud_rate` there are still other options (at least `debug_level`) that suffer from the same problem. Nico > > I already created a RFC patch that removes it: > https://review.coreboot.org/#/c/19682/ > > [1] https://mail.coreboot.org/pipermail/coreboot/2017-May/084266.html > CCM report > > > Kind regards > ------------ > > Arthur > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot