Hello Simon,
Am 25.08.2016 um 14:04 schrieb Simon Glass:
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'.
Do you have this patchseries in a public tree, from where I can
pull? So I may find time to start a test with tbot.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
