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