u-boot: 2015.07 - fix creation of .config

Due to recent changes in U-Boot, see
http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
re-creation of .config from defconfig by "make oldconfig" happened
incorrectly.

Default prompt for target selection was set as No that lead to missing platform
selection by automated scripts like that:
------------------>8------------------
"yes "" | make oldconfig" on defconfig
------------------>8------------------

And that lead to build failure:
------------------>8------------------
$ make
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/config.h
  UPD     include/config.h
  GEN     include/autoconf.mk
In file included from ./include/common.h:18:0:
include/config.h:5:22: fatal error: configs/.h: No such file or directory
 #include <configs/.h>
                      ^
compilation terminated.
scripts/Makefile.autoconf:72: recipe for target 'include/autoconf.mk' failed
make[1]: *** [include/autoconf.mk] Error 1
------------------>8------------------

This patch reverts mentioned change making possible to build U-Boot
2015.07 in Buildroot.

Note there's a probability that this particular patch won't make its way
in upstream U-Boot and better solution will be found there. But for now
we need to fix U-Boot building in Buildroot anyways.

Hopefully for the next release this patch won't be necessary.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...rch-Make-board-selection-choices-optional.patch | 742 +++++++++++++++++++++
 1 file changed, 742 insertions(+)
 create mode 100644 boot/uboot/2015.07/0001-Revert-arch-Make-board-selection-choices-optional.patch

Alexey,

On Fri, 31 Jul 2015 17:04:35 +0300, Alexey Brodkin wrote:
> Due to recent changes in U-Boot, see
> http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
> re-creation of .config from defconfig by "make oldconfig" happened
> incorrectly.

Hum, reverting an upstream patch doesn't really seem like a proper
solution for the problem. Also, it will only fix the problem for those
using exactly U-Boot 2015.07, but not for the majority of users who
have to use a vendor-specific U-Boot version (unfortunately).

So I believe we need to fix this properly, not by reverting an upstream
patch.

Thomas

Hi Thomas,

On Fri, 2015-07-31 at 16:18 +0200, Thomas Petazzoni wrote:
> Alexey,
> 
> On Fri, 31 Jul 2015 17:04:35 +0300, Alexey Brodkin wrote:
> > Due to recent changes in U-Boot, see
> > http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
> > re-creation of .config from defconfig by "make oldconfig" happened
> > incorrectly.
> 
> Hum, reverting an upstream patch doesn't really seem like a proper
> solution for the problem. Also, it will only fix the problem for those
> using exactly U-Boot 2015.07, but not for the majority of users who
> have to use a vendor-specific U-Boot version (unfortunately).
> 
> So I believe we need to fix this properly, not by reverting an upstream
> patch.

To be honest I think that revert will happen upstream as well.
Recently I started discussion on that regard here http://lists.denx.de/pipermail/u-boot/2015-July/221101.html

The point is that problem has to be resolved upstream anyways in that or another way and I'll make sure
it happens sooner [I hope] or later. Because you know we prefer to stick to upstream and so we do care upstream
projects work for us.

And if [I hope] discussed problem is gone before the next release of Buildroot do we really care
how the problem is solved in Buildroot for existing release?

Note that problem I'm attempting to fix doesn't really affect U-Boot compilation or execution.
This is only related to its buildsystem. As a developers of U-Boot we [even though it was not I in person
behind that patch but I saw this and didn't recognize upcoming problem with oldconfig] wanted to make
life of U-Boot users a bit easier [see commit message to the original commit] but that attempt
caused problems for those who builds U-Boot in non-standard way [I mean not via "make xxx_defconfig && make"].

Hopefully that comment makes sense.

If not do you think there's a better way to fix a failure on attempt to build vanilla U-Boot v2015.07?

BTW speaking about vendor-specific U-Boot versions I think it's now mostly our legacy now.
If I'm not mistaken lots of boards may use vanilla U-Boot. For example Cubieboards and Wandboards
(I own these boards and tried vanilla U-boot on them) and many more ARM boards supported in Fedora
for ARM like Pandaboard, Olinuxinos etc. So it's just a matter of maintainers of those boards
(if we have them at all) to try latest vanilla U-Boot and update defconfigs then if all works.

-Alexey

Hi Thomas,

On Fri, 2015-07-31 at 18:14 +0300, Alexey Brodkin wrote:
> Hi Thomas,
> 
> On Fri, 2015-07-31 at 16:18 +0200, Thomas Petazzoni wrote:
> > Alexey,
> > 
> > On Fri, 31 Jul 2015 17:04:35 +0300, Alexey Brodkin wrote:
> > > Due to recent changes in U-Boot, see
> > > http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
> > > re-creation of .config from defconfig by "make oldconfig" happened
> > > incorrectly.
> > 
> > Hum, reverting an upstream patch doesn't really seem like a proper
> > solution for the problem. Also, it will only fix the problem for those
> > using exactly U-Boot 2015.07, but not for the majority of users who
> > have to use a vendor-specific U-Boot version (unfortunately).
> > 
> > So I believe we need to fix this properly, not by reverting an upstream
> > patch.
> 
> To be honest I think that revert will happen upstream as well.
> Recently I started discussion on that regard here http://lists.denx.de/pipermail/u-boot/2015-July/221101.html
> 
> The point is that problem has to be resolved upstream anyways in that or another way and I'll make sure
> it happens sooner [I hope] or later. Because you know we prefer to stick to upstream and so we do care upstream
> projects work for us.
> 
> And if [I hope] discussed problem is gone before the next release of Buildroot do we really care
> how the problem is solved in Buildroot for existing release?
> 
> Note that problem I'm attempting to fix doesn't really affect U-Boot compilation or execution.
> This is only related to its buildsystem. As a developers of U-Boot we [even though it was not I in person
> behind that patch but I saw this and didn't recognize upcoming problem with oldconfig] wanted to make
> life of U-Boot users a bit easier [see commit message to the original commit] but that attempt
> caused problems for those who builds U-Boot in non-standard way [I mean not via "make xxx_defconfig && make"].
> 
> Hopefully that comment makes sense.
> 
> If not do you think there's a better way to fix a failure on attempt to build vanilla U-Boot v2015.07?
> 
> BTW speaking about vendor-specific U-Boot versions I think it's now mostly our legacy now.
> If I'm not mistaken lots of boards may use vanilla U-Boot. For example Cubieboards and Wandboards
> (I own these boards and tried vanilla U-boot on them) and many more ARM boards supported in Fedora
> for ARM like Pandaboard, Olinuxinos etc. So it's just a matter of maintainers of those boards
> (if we have them at all) to try latest vanilla U-Boot and update defconfigs then if all works.

Looks like resolution in upstream U-Boot will be with specification of default "platform" for each architecture.
See http://lists.denx.de/pipermail/u-boot/2015-August/221418.html, 
http://lists.denx.de/pipermail/u-boot/2015-August/221417.html

Still this will take quite some time to update all affected 54 Kconfigs.

So probably proposed patch with revert in Buildroot makes perfect sense as we only build U-Boot but not
adding new "platforms" etc i.e. proposed patch IMHO won't hurt.

-Alexey

Hi Thomas,

On Mon, 2015-08-03 at 14:15 +0300, Alexey Brodkin wrote:
> Hi Thomas,
> 
> On Fri, 2015-07-31 at 18:14 +0300, Alexey Brodkin wrote:
> > Hi Thomas,
> > 
> > On Fri, 2015-07-31 at 16:18 +0200, Thomas Petazzoni wrote:
> > > Alexey,
> > > 
> > > On Fri, 31 Jul 2015 17:04:35 +0300, Alexey Brodkin wrote:
> > > > Due to recent changes in U-Boot, see
> > > > http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
> > > > re-creation of .config from defconfig by "make oldconfig" happened
> > > > incorrectly.
> > > 
> > > Hum, reverting an upstream patch doesn't really seem like a proper
> > > solution for the problem. Also, it will only fix the problem for those
> > > using exactly U-Boot 2015.07, but not for the majority of users who
> > > have to use a vendor-specific U-Boot version (unfortunately).
> > > 
> > > So I believe we need to fix this properly, not by reverting an upstream
> > > patch.
> > 
> > To be honest I think that revert will happen upstream as well.
> > Recently I started discussion on that regard here http://lists.denx.de/pipermail/u-boot/2015-July/221101.html
> > 
> > The point is that problem has to be resolved upstream anyways in that or another way and I'll make sure
> > it happens sooner [I hope] or later. Because you know we prefer to stick to upstream and so we do care upstream
> > projects work for us.
> > 
> > And if [I hope] discussed problem is gone before the next release of Buildroot do we really care
> > how the problem is solved in Buildroot for existing release?
> > 
> > Note that problem I'm attempting to fix doesn't really affect U-Boot compilation or execution.
> > This is only related to its buildsystem. As a developers of U-Boot we [even though it was not I in person
> > behind that patch but I saw this and didn't recognize upcoming problem with oldconfig] wanted to make
> > life of U-Boot users a bit easier [see commit message to the original commit] but that attempt
> > caused problems for those who builds U-Boot in non-standard way [I mean not via "make xxx_defconfig && make"].
> > 
> > Hopefully that comment makes sense.
> > 
> > If not do you think there's a better way to fix a failure on attempt to build vanilla U-Boot v2015.07?
> > 
> > BTW speaking about vendor-specific U-Boot versions I think it's now mostly our legacy now.
> > If I'm not mistaken lots of boards may use vanilla U-Boot. For example Cubieboards and Wandboards
> > (I own these boards and tried vanilla U-boot on them) and many more ARM boards supported in Fedora
> > for ARM like Pandaboard, Olinuxinos etc. So it's just a matter of maintainers of those boards
> > (if we have them at all) to try latest vanilla U-Boot and update defconfigs then if all works.
> 
> Looks like resolution in upstream U-Boot will be with specification of default "platform" for each architecture.
> See http://lists.denx.de/pipermail/u-boot/2015-August/221418.html, 
> http://lists.denx.de/pipermail/u-boot/2015-August/221417.html
> 
> Still this will take quite some time to update all affected 54 Kconfigs.
> 
> So probably proposed patch with revert in Buildroot makes perfect sense as we only build U-Boot but not
> adding new "platforms" etc i.e. proposed patch IMHO won't hurt.
> 
> -Alexey

Any chance for this one to be applied?
Note without this change or anything similar U-Boot from snsp_axs10x_defconfig fails to config.

-Alexey

Dear Alexey Brodkin,

On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:

> Any chance for this one to be applied?
> Note without this change or anything similar U-Boot from
> snsp_axs10x_defconfig fails to config.

I haven't had the time to look into this in detail. It would be great
if Yann, or Jörg could have a look. I remain unhappy with solving such
a problem by using a patch against U-Boot 2015.07, because it means
anyone specifying a slightly different U-Boot version (but based on
2015.07) will still have the problem.

Best regards,

Thomas

Hi Thomas, Alexey,

On Mi, 2015-08-12 at 10:23 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> 
> > Any chance for this one to be applied?
> > Note without this change or anything similar U-Boot from
> > snsp_axs10x_defconfig fails to config.
> 
> I haven't had the time to look into this in detail. It would be great
> if Yann, or Jörg could have a look. I remain unhappy with solving
> such
> a problem by using a patch against U-Boot 2015.07, because it means
> anyone specifying a slightly different U-Boot version (but based on
> 2015.07) will still have the problem.

It looks like upstream [1] does not revert this patch but fixes the
problem with this patch [2]. Alexey, does this patch solves your
problem?

Best regards
Jörg Krause


[1]
https://www.mail-archive.com/u-boot@lists.denx.de/msg179681.html 

[2]
http://patchwork.ozlabs.org/patch/502793/

Hi Jorg,

On Sun, 2015-08-16 at 23:43 +0200, Jörg Krause wrote:
> Hi Thomas, Alexey,
> 
> On Mi, 2015-08-12 at 10:23 +0200, Thomas Petazzoni wrote:
> > Dear Alexey Brodkin,
> > 
> > On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> > 
> > > Any chance for this one to be applied?
> > > Note without this change or anything similar U-Boot from
> > > snsp_axs10x_defconfig fails to config.
> > 
> > I haven't had the time to look into this in detail. It would be great
> > if Yann, or Jörg could have a look. I remain unhappy with solving
> > such
> > a problem by using a patch against U-Boot 2015.07, because it means
> > anyone specifying a slightly different U-Boot version (but based on
> > 2015.07) will still have the problem.
> 
> It looks like upstream [1] does not revert this patch but fixes the
> problem with this patch [2]. Alexey, does this patch solves your
> problem?
> 
> Best regards
> Jörg Krause
> 
> 
> [1]
> https://www.mail-archive.com/u-boot@lists.denx.de/msg179681.html 
> 
> [2]
> http://patchwork.ozlabs.org/patch/502793/

The thing is [2] solves problem only for ARM, while other arches are still
affected. And that means ARC is not cured by that patch.

Indeed proper fix is to patch all arches in the same way,
i.e. select default option for each and every architecture in U-Boot.

But speaking about Buildroot that approach has at least 2 downsides:
 1) Not all arches are fixed upstream so in Buildroot we'll have patches
    that are not there in upstream yet.

 2) We'll have quite a few patches in Buildroot for U-boot each fixing
    a separate arch.

If (1) and (2) are OK for Buildroot I'll try to come up with those patches ASAP.

My initial approach was IMHO the cleanest and simplest. But if it doesn't work
we'll do another fix :)

-Alexey

Alexey, All,

On 2015-08-17 06:37 +0000, Alexey Brodkin spake thusly:
> On Sun, 2015-08-16 at 23:43 +0200, Jörg Krause wrote:
> > Hi Thomas, Alexey,
> > 
> > On Mi, 2015-08-12 at 10:23 +0200, Thomas Petazzoni wrote:
> > > Dear Alexey Brodkin,
> > > 
> > > On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> > > 
> > > > Any chance for this one to be applied?
> > > > Note without this change or anything similar U-Boot from
> > > > snsp_axs10x_defconfig fails to config.
> > > 
> > > I haven't had the time to look into this in detail. It would be great
> > > if Yann, or Jörg could have a look. I remain unhappy with solving
> > > such
> > > a problem by using a patch against U-Boot 2015.07, because it means
> > > anyone specifying a slightly different U-Boot version (but based on
> > > 2015.07) will still have the problem.
> > 
> > It looks like upstream [1] does not revert this patch but fixes the
> > problem with this patch [2]. Alexey, does this patch solves your
> > problem?
> > 
> > Best regards
> > Jörg Krause
> > 
> > 
> > [1]
> > https://www.mail-archive.com/u-boot@lists.denx.de/msg179681.html 
> > 
> > [2]
> > http://patchwork.ozlabs.org/patch/502793/
> 
> The thing is [2] solves problem only for ARM, while other arches are still
> affected. And that means ARC is not cured by that patch.
> 
> Indeed proper fix is to patch all arches in the same way,
> i.e. select default option for each and every architecture in U-Boot.
> 
> But speaking about Buildroot that approach has at least 2 downsides:
>  1) Not all arches are fixed upstream so in Buildroot we'll have patches
>     that are not there in upstream yet.
> 
>  2) We'll have quite a few patches in Buildroot for U-boot each fixing
>     a separate arch.
> 
> If (1) and (2) are OK for Buildroot I'll try to come up with those patches ASAP.
> 
> My initial approach was IMHO the cleanest and simplest. But if it doesn't work
> we'll do another fix :)

OK, chiming in...

I guess removing the "optional" keywork would be the simplest solution,
indeed.

But then I'm afraid that defconfig files bundled with U-Boot will no
longer work. If they still work, then I'm OK for having a local patch
that reverts upstream's (until upstream fixes all of their archs).

Regards,
Yann E. MORIN.

Hi Yann,

On Mon, 2015-08-17 at 11:31 +0200, Yann E. MORIN wrote:
> Alexey, All,
> 
> On 2015-08-17 06:37 +0000, Alexey Brodkin spake thusly:
> > On Sun, 2015-08-16 at 23:43 +0200, Jörg Krause wrote:
> > > Hi Thomas, Alexey,
> > > 
> > > On Mi, 2015-08-12 at 10:23 +0200, Thomas Petazzoni wrote:
> > > > Dear Alexey Brodkin,
> > > > 
> > > > On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> > > > 
> > > > > Any chance for this one to be applied?
> > > > > Note without this change or anything similar U-Boot from
> > > > > snsp_axs10x_defconfig fails to config.
> > > > 
> > > > I haven't had the time to look into this in detail. It would be great
> > > > if Yann, or Jörg could have a look. I remain unhappy with solving
> > > > such
> > > > a problem by using a patch against U-Boot 2015.07, because it means
> > > > anyone specifying a slightly different U-Boot version (but based on
> > > > 2015.07) will still have the problem.
> > > 
> > > It looks like upstream [1] does not revert this patch but fixes the
> > > problem with this patch [2]. Alexey, does this patch solves your
> > > problem?
> > > 
> > > Best regards
> > > Jörg Krause
> > > 
> > > 
> > > [1]
> > > https://www.mail-archive.com/u-boot@lists.denx.de/msg179681.html 
> > > 
> > > [2]
> > > http://patchwork.ozlabs.org/patch/502793/
> > 
> > The thing is [2] solves problem only for ARM, while other arches are still
> > affected. And that means ARC is not cured by that patch.
> > 
> > Indeed proper fix is to patch all arches in the same way,
> > i.e. select default option for each and every architecture in U-Boot.
> > 
> > But speaking about Buildroot that approach has at least 2 downsides:
> >  1) Not all arches are fixed upstream so in Buildroot we'll have patches
> >     that are not there in upstream yet.
> > 
> >  2) We'll have quite a few patches in Buildroot for U-boot each fixing
> >     a separate arch.
> > 
> > If (1) and (2) are OK for Buildroot I'll try to come up with those patches ASAP.
> > 
> > My initial approach was IMHO the cleanest and simplest. But if it doesn't work
> > we'll do another fix :)
> 
> OK, chiming in...
> 
> I guess removing the "optional" keywork would be the simplest solution,
> indeed.
> 
> But then I'm afraid that defconfig files bundled with U-Boot will no
> longer work. If they still work, then I'm OK for having a local patch
> that reverts upstream's (until upstream fixes all of their archs).

Ok that's probably another mystery of Kconfig but defconfigs bundled with
U-Boot do work. They worked both before reverted patch and after.

What doesn't work is "make oldconfig".
See in U-Boot (let's forget about Buildroot for a minute) we usually build stuff
with defconfigs this way "make xxx_defconfig". And it worked and it works still.

But in Buildroot what we do we take "xxx_deconfig", copy it from "configs" folder
to the root of U-Boot build folder as .config, do changes we need and then to get
correctly expanded .config for building we finally do "make oldconfig".

And that's where the problem happens. Kconfig just skips items marked as optional
and so platforms are not set properly and build fails.

In other words I would blame Kconfig and I even spent some time trying to
figure out if there's a way to fix Kconfig simply. But to no avail. And so
I decided to work-around Kconfig issue.

Hope that comment makes sense.

-Alexey

On 08/12/2015 10:23 AM, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> 
>> Any chance for this one to be applied?
>> Note without this change or anything similar U-Boot from
>> snsp_axs10x_defconfig fails to config.
> 
> I haven't had the time to look into this in detail. It would be great
> if Yann, or Jörg could have a look. I remain unhappy with solving such
> a problem by using a patch against U-Boot 2015.07, because it means
> anyone specifying a slightly different U-Boot version (but based on
> 2015.07) will still have the problem.

 I assume the problem will be fixed soon upstream, so the chance that some chip
vendor releases a U-Boot based on 2015.07 is not that high. And if someone is
making their own modified git copy of 2015.07, they'll notice _very_ quickly
that it fails and with any luck they'll notice the patch in buildroot.

 Not fixing the problem at all in 2015.08 is obviously worse.

 We could do a sed independent of the U-Boot version, but that runs the risk of
breaking some other random non-2015.07 version completely.

 The problem is in fact in Kconfig (as noted in Tom Rini's comment in
http://patchwork.ozlabs.org/patch/502793/ ) so a fundamental solution is not easy.

 Regards,
 Arnout

Hi Thomas,

On Sun, 2015-08-23 at 00:57 +0200, Arnout Vandecappelle wrote:
> On 08/12/2015 10:23 AM, Thomas Petazzoni wrote:
> > Dear Alexey Brodkin,
> > 
> > On Tue, 11 Aug 2015 12:20:01 +0000, Alexey Brodkin wrote:
> > 
> > > Any chance for this one to be applied?
> > > Note without this change or anything similar U-Boot from
> > > snsp_axs10x_defconfig fails to config.
> > 
> > I haven't had the time to look into this in detail. It would be great
> > if Yann, or Jörg could have a look. I remain unhappy with solving such
> > a problem by using a patch against U-Boot 2015.07, because it means
> > anyone specifying a slightly different U-Boot version (but based on
> > 2015.07) will still have the problem.
> 
>  I assume the problem will be fixed soon upstream, so the chance that some chip
> vendor releases a U-Boot based on 2015.07 is not that high. And if someone is
> making their own modified git copy of 2015.07, they'll notice _very_ quickly
> that it fails and with any luck they'll notice the patch in buildroot.
> 
>  Not fixing the problem at all in 2015.08 is obviously worse.
> 
>  We could do a sed independent of the U-Boot version, but that runs the risk of
> breaking some other random non-2015.07 version completely.
> 
>  The problem is in fact in Kconfig (as noted in Tom Rini's comment in
> http://patchwork.ozlabs.org/patch/502793/ ) so a fundamental solution is not easy.

So we're well beyond rc2 and release will inevitably happen from day to day still
this problem is not resolved. Anything else we're going to consider here?

-Alexey

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

>> I haven't had the time to look into this in detail. It would be great
 >> if Yann, or Jörg could have a look. I remain unhappy with solving such
 >> a problem by using a patch against U-Boot 2015.07, because it means
 >> anyone specifying a slightly different U-Boot version (but based on
 >> 2015.07) will still have the problem.

 >  I assume the problem will be fixed soon upstream, so the chance that some chip
 > vendor releases a U-Boot based on 2015.07 is not that high. And if someone is
 > making their own modified git copy of 2015.07, they'll notice _very_ quickly
 > that it fails and with any luck they'll notice the patch in buildroot.

 >  Not fixing the problem at all in 2015.08 is obviously worse.

Agreed.

 >  We could do a sed independent of the U-Boot version, but that runs the risk of
 > breaking some other random non-2015.07 version completely.

Yeah, that sounds a bit scary.

>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:

 > Due to recent changes in U-Boot, see
 > http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
 > re-creation of .config from defconfig by "make oldconfig" happened
 > incorrectly.

 > Default prompt for target selection was set as No that lead to missing platform
 > selection by automated scripts like that:
 ------------------> 8------------------
 > "yes "" | make oldconfig" on defconfig
 ------------------> 8------------------

 > And that lead to build failure:
 ------------------> 8------------------
 > $ make
 > scripts/kconfig/conf --silentoldconfig Kconfig
 >   CHK     include/config.h
 >   UPD     include/config.h
 >   GEN     include/autoconf.mk
 > In file included from ./include/common.h:18:0:
 > include/config.h:5:22: fatal error: configs/.h: No such file or directory
 >  #include <configs/.h>
 >                       ^
 > compilation terminated.
 > scripts/Makefile.autoconf:72: recipe for target 'include/autoconf.mk' failed
 > make[1]: *** [include/autoconf.mk] Error 1
 ------------------> 8------------------

 > This patch reverts mentioned change making possible to build U-Boot
 > 2015.07 in Buildroot.

 > Note there's a probability that this particular patch won't make its way
 > in upstream U-Boot and better solution will be found there. But for now
 > we need to fix U-Boot building in Buildroot anyways.

 > Hopefully for the next release this patch won't be necessary.

 > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
 > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed, thanks.

While doing a test build I noticed that u-boot nowadays needs dtc:

  CHK     include/generated/timestamp_autogenerated.h
  UPD     include/generated/timestamp_autogenerated.h
./scripts/dtc-version.sh: line 17: dtc: command not found
./scripts/dtc-version.sh: line 18: dtc: command not found
*** Your dtc is too old, please upgrade to dtc 1.4 or newer
Makefile:1297: recipe for target 'checkdtc' failed
make[1]: *** [checkdtc] Error 1
make[1]: *** Waiting for unfinished jobs....
  UPD     include/config/uboot.release
make[1]: *** wait: No child processes.  Stop.
package/pkg-generic.mk:156: recipe for target '/home/peko/source/buildroot/output/build/uboot-2015.07/.stamp_built' failed

So perhaps we should consider adding host support to our dtc package and add
host-dtc to the uboot dependencies?

Hi Peter,

On Sun, 2015-08-30 at 22:51 +0200, Peter Korsgaard wrote:
> > > > > > "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
> 
>  > Due to recent changes in U-Boot, see
>  > http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
>  > re-creation of .config from defconfig by "make oldconfig" happened
>  > incorrectly.
> 
>  > Default prompt for target selection was set as No that lead to missing platform
>  > selection by automated scripts like that:
>  ------------------> 8------------------
>  > "yes "" | make oldconfig" on defconfig
>  ------------------> 8------------------
> 
>  > And that lead to build failure:
>  ------------------> 8------------------
>  > $ make
>  > scripts/kconfig/conf --silentoldconfig Kconfig
>  >   CHK     include/config.h
>  >   UPD     include/config.h
>  >   GEN     include/autoconf.mk
>  > In file included from ./include/common.h:18:0:
>  > include/config.h:5:22: fatal error: configs/.h: No such file or directory
>  >  #include <configs/.h>
>  >                       ^
>  > compilation terminated.
>  > scripts/Makefile.autoconf:72: recipe for target 'include/autoconf.mk' failed
>  > make[1]: *** [include/autoconf.mk] Error 1
>  ------------------> 8------------------
> 
>  > This patch reverts mentioned change making possible to build U-Boot
>  > 2015.07 in Buildroot.
> 
>  > Note there's a probability that this particular patch won't make its way
>  > in upstream U-Boot and better solution will be found there. But for now
>  > we need to fix U-Boot building in Buildroot anyways.
> 
>  > Hopefully for the next release this patch won't be necessary.
> 
>  > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
>  > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> Committed, thanks.
> 
> While doing a test build I noticed that u-boot nowadays needs dtc:
> 
>   CHK     include/generated/timestamp_autogenerated.h
>   UPD     include/generated/timestamp_autogenerated.h
> ./scripts/dtc-version.sh: line 17: dtc: command not found
> ./scripts/dtc-version.sh: line 18: dtc: command not found
> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
> Makefile:1297: recipe for target 'checkdtc' failed
> make[1]: *** [checkdtc] Error 1
> make[1]: *** Waiting for unfinished jobs....
>   UPD     include/config/uboot.release
> make[1]: *** wait: No child processes.  Stop.
> package/pkg-generic.mk:156: recipe for target '/home/peko/source/buildroot/output/build/uboot-2015.07/.stamp_built'
> failed
> 
> So perhaps we should consider adding host support to our dtc package and add
> host-dtc to the uboot dependencies?

Indeed that will help on older machines.
I haven't seen that failure just because I'm on latest Fedora so DTC is pretty recent.

I'll take a look at how to enable host DTC.

-Alexey