Hi Heiko, On 24 August 2016 at 22:30, Heiko Schocher <h...@denx.de> wrote: > Hello Simon, > > > Am 24.08.2016 um 18:51 schrieb Simon Glass: >> >> This series moves all the CONFIG_SPL_..._SUPPORT options to Kconfig and >> fixes up existing boards to continue to build. > >> >> >> It also adds a few small but useful features to moveconfig. >> >> There is existing work going on in this area, so some of these patches may >> be superseded. It has taken me a while to get this building cleanly. But I >> have run out of time so want to get this out. >> >> As mentioned on a recent thread [1] there is some confusion about whether >> an >> option means enabling driver support or media support. Andrew's recent >> series seems like a good vehicle to tidy that up. But I hope this series >> will make it easier. >> >> There are a few strange features of this conversion. The main difficulty >> is >> that some PowerPC boards do things like this in their board config file: >> >> #ifdef CONFIG_TPL_BUILD >> #define CONFIG_SPL_SERIAL_SUPPORT >> #define CONFIG_SPL_ENV_SUPPORT >> #else >> #define CONFIG_SPL_SERIAL_SUPPORT >> #endif >> >> This means that TPL reuses the SPL options. We can't support this in >> Kconfig >> so I have added a small number of CONFIG_TPL_xxx_SUPPORT options to cope >> with this. This made the conversion more painful than it should have been. >> >> A related issue is boards using a common header file and setting options >> only >> for SPL: >> >> #ifdef CONFIG_SPL_BUILD >> #define CONFIG_SPL_SERIAL_SUPPORT >> #endif >> >> This is not noticed by moveconfig so we have to clean it up manually. Also >> there are a few incorrect things where Kconfig options are set with >> #define: >> >> #ifdef CONFIG_SPL_BUILD >> #define CONFIG_SPL_DM >> #endif >> >> Finally, many defconfig files are not ordered correctly, resulting in >> larger >> patches than we might like. It would be great to have a solution for this, >> perhaps with buildman providing a warning. But it might slow down >> development. >> >> The series is fully build-tested (for bisectability) and causes no >> failures >> for the boards that already pass. The following boards fail for me at >> present on mainline (which I have not yet looked at): > > > Thanks! > > Hmm... may you want to check, if your patchserie does not > break any existing board? I wrote a tbot testcase for this, see: > > http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
Yes that sounds like a good idea. I have spent quite a few hours ensuring that the series breaks no boards (and bisectability) but not yet binary compatibility. At present buildman -K can provide information about config changes, but it would be more useful if it ignored the difference between defining an option to '1' and defining it to 'y'. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
