[U-Boot] tools-only build broken

[U-Boot] tools-only build broken

[Ian Campbell]

The tools-only target is currently broken:
        $ make CROSS_COMPILE=arm-linux-gnueabihf- tools-only 
          CHK     include/config/uboot.release
        /bin/sh: 1: cannot open include/config/auto.conf: No such file
        Makefile:1052: recipe for target 'include/config/uboot.release' failed
        make: *** [include/config/uboot.release] Error 2
        
This is because tools-only depends on $(version_h), depends on
include/config/uboot.release, depends include/config/auto.conf. I think
this is all due to the support for LOCALVERSION(_AUTO).

I'm not sure how to reconcile this, since the version stuff
fundamentally needs the .config. Perhaps sandbox could be used?

Ian.

[U-Boot] tools-only build broken

[Ian Campbell]

On Fri, 2014-08-29 at 21:07 +0100, Ian Campbell wrote:
> The tools-only target is currently broken:
>         $ make CROSS_COMPILE=arm-linux-gnueabihf- tools-only 
>           CHK     include/config/uboot.release
>         /bin/sh: 1: cannot open include/config/auto.conf: No such file
>         Makefile:1052: recipe for target 'include/config/uboot.release' failed
>         make: *** [include/config/uboot.release] Error 2
>         
> This is because tools-only depends on $(version_h), depends on
> include/config/uboot.release, depends include/config/auto.conf. I think
> this is all due to the support for LOCALVERSION(_AUTO).
> 
> I'm not sure how to reconcile this, since the version stuff
> fundamentally needs the .config. Perhaps sandbox could be used?

In the meantime "touch include/config/auto.conf" lets it build (hardly
ideal though!)

Ian.

[U-Boot] tools-only build broken

[Matwey V. Kornilov]

30.08.2014 04:04, Ian Campbell ?????:

> In the meantime "touch include/config/auto.conf" lets it build (hardly
> ideal though!)

Hi, I do

make defconfig
make silentoldconfig
make tools-only

[U-Boot] tools-only build broken

[Ian Campbell]

On Sat, 2014-08-30 at 13:40 +0400, Matwey V. Kornilov wrote:
> 30.08.2014 04:04, Ian Campbell ?????:
> 
> > In the meantime "touch include/config/auto.conf" lets it build (hardly
> > ideal though!)
> 
> Hi, I do
> 
> make defconfig
> make silentoldconfig
> make tools-only

Thanks. I feared that would be baking some sort of non-default defconfig
(IYSWIM) stuff into the tools build. Perhaps that worry is unfounded
though.

Ian.

[U-Boot] tools-only build broken

[Simon Glass]

Hi,

On 30 August 2014 19:44, Ian Campbell <ijc@hellion.org.uk> wrote:
> On Sat, 2014-08-30 at 13:40 +0400, Matwey V. Kornilov wrote:
>> 30.08.2014 04:04, Ian Campbell ?????:
>>
>> > In the meantime "touch include/config/auto.conf" lets it build (hardly
>> > ideal though!)
>>
>> Hi, I do
>>
>> make defconfig
>> make silentoldconfig
>> make tools-only
>
> Thanks. I feared that would be baking some sort of non-default defconfig
> (IYSWIM) stuff into the tools build. Perhaps that worry is unfounded
> though.

That works, and builds with sandbox_defconfig so that you get full
functionality (verified boot).

Regards,
Simon

[U-Boot] tools-only build broken

[Ian Campbell]

On Sun, 2014-08-31 at 21:54 -0700, Simon Glass wrote:
> Hi,
> 
> On 30 August 2014 19:44, Ian Campbell <ijc@hellion.org.uk> wrote:
> > On Sat, 2014-08-30 at 13:40 +0400, Matwey V. Kornilov wrote:
> >> 30.08.2014 04:04, Ian Campbell ?????:
> >>
> >> > In the meantime "touch include/config/auto.conf" lets it build (hardly
> >> > ideal though!)
> >>
> >> Hi, I do
> >>
> >> make defconfig
> >> make silentoldconfig
> >> make tools-only
> >
> > Thanks. I feared that would be baking some sort of non-default defconfig
> > (IYSWIM) stuff into the tools build. Perhaps that worry is unfounded
> > though.
> 
> That works,

You mean that "make defconfig" is (now) the recommended way to get
tools-only to build?

>  and builds with sandbox_defconfig so that you get full
> functionality (verified boot).

Not sure what you mean here. Verified in what way? What is booting that
way, this should only build tools, not something which can boot.

We are using tools-only as part of the Debian packaging, what we are
trying to build is a usable generic version of mkimage (and potentially
other tools in the future) which can be placed in a generic u-boot-tools
package which is separate from the u-boot package(s) which contain(s)
u-boot binaries.

Ian.

[U-Boot] tools-only build broken

[Simon Glass]

Hi Ian,

On 2 September 2014 03:22, Ian Campbell <ijc@hellion.org.uk> wrote:
> On Sun, 2014-08-31 at 21:54 -0700, Simon Glass wrote:
>> Hi,
>>
>> On 30 August 2014 19:44, Ian Campbell <ijc@hellion.org.uk> wrote:
>> > On Sat, 2014-08-30 at 13:40 +0400, Matwey V. Kornilov wrote:
>> >> 30.08.2014 04:04, Ian Campbell ?????:
>> >>
>> >> > In the meantime "touch include/config/auto.conf" lets it build (hardly
>> >> > ideal though!)
>> >>
>> >> Hi, I do
>> >>
>> >> make defconfig
>> >> make silentoldconfig
>> >> make tools-only
>> >
>> > Thanks. I feared that would be baking some sort of non-default defconfig
>> > (IYSWIM) stuff into the tools build. Perhaps that worry is unfounded
>> > though.
>>
>> That works,
>
> You mean that "make defconfig" is (now) the recommended way to get
> tools-only to build?

I mean that it builds sandbox, which is the best thing to build.

>
>>  and builds with sandbox_defconfig so that you get full
>> functionality (verified boot).
>
> Not sure what you mean here. Verified in what way? What is booting that
> way, this should only build tools, not something which can boot.
>
> We are using tools-only as part of the Debian packaging, what we are
> trying to build is a usable generic version of mkimage (and potentially
> other tools in the future) which can be placed in a generic u-boot-tools
> package which is separate from the u-boot package(s) which contain(s)
> u-boot binaries.

mkimage has additional support for verified/secure boot, but only if
enabled at build time. It is enabled for sandbox. So if you want full
functionality you should use that build.

Regards,
Simon

[U-Boot] tools-only build broken

[Otavio Salvador]

On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
...
>> We are using tools-only as part of the Debian packaging, what we are
>> trying to build is a usable generic version of mkimage (and potentially
>> other tools in the future) which can be placed in a generic u-boot-tools
>> package which is separate from the u-boot package(s) which contain(s)
>> u-boot binaries.
>
> mkimage has additional support for verified/secure boot, but only if
> enabled at build time. It is enabled for sandbox. So if you want full
> functionality you should use that build.

However there are exceptions for it. For example MX28 has special
mxsimage support when it is in use.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] tools-only build broken

[Simon Glass]

Hi Otavio,

On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
> ...
>>> We are using tools-only as part of the Debian packaging, what we are
>>> trying to build is a usable generic version of mkimage (and potentially
>>> other tools in the future) which can be placed in a generic u-boot-tools
>>> package which is separate from the u-boot package(s) which contain(s)
>>> u-boot binaries.
>>
>> mkimage has additional support for verified/secure boot, but only if
>> enabled at build time. It is enabled for sandbox. So if you want full
>> functionality you should use that build.
>
> However there are exceptions for it. For example MX28 has special
> mxsimage support when it is in use.

Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
That seem wrong to me - do you know the reason for it?

Regards,
Simon

[U-Boot] tools-only build broken

[Otavio Salvador]

On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
> On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
>> ...
>>>> We are using tools-only as part of the Debian packaging, what we are
>>>> trying to build is a usable generic version of mkimage (and potentially
>>>> other tools in the future) which can be placed in a generic u-boot-tools
>>>> package which is separate from the u-boot package(s) which contain(s)
>>>> u-boot binaries.
>>>
>>> mkimage has additional support for verified/secure boot, but only if
>>> enabled at build time. It is enabled for sandbox. So if you want full
>>> functionality you should use that build.
>>
>> However there are exceptions for it. For example MX28 has special
>> mxsimage support when it is in use.
>
> Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
> That seem wrong to me - do you know the reason for it?

This is to avoid linking with SSL library[1].

1. http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e966d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115

However now we have FIT signature I think we can enable it and drop
the MXS special usage.

Do you agree?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] tools-only build broken

[Simon Glass]

Hi Otvaio,

On 2 September 2014 18:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
>> On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
>>> ...
>>>>> We are using tools-only as part of the Debian packaging, what we are
>>>>> trying to build is a usable generic version of mkimage (and potentially
>>>>> other tools in the future) which can be placed in a generic u-boot-tools
>>>>> package which is separate from the u-boot package(s) which contain(s)
>>>>> u-boot binaries.
>>>>
>>>> mkimage has additional support for verified/secure boot, but only if
>>>> enabled at build time. It is enabled for sandbox. So if you want full
>>>> functionality you should use that build.
>>>
>>> However there are exceptions for it. For example MX28 has special
>>> mxsimage support when it is in use.
>>
>> Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
>> That seem wrong to me - do you know the reason for it?
>
> This is to avoid linking with SSL library[1].
>
> 1. http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e966d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115
>
> However now we have FIT signature I think we can enable it and drop
> the MXS special usage.
>
> Do you agree?

I agree (not sure about others). For sandbox we have SSL anyway so it
should be fine.

Regards,
Simon

[U-Boot] tools-only build broken

[Otavio Salvador]

On Tue, Sep 2, 2014 at 10:46 PM, Simon Glass <sjg@chromium.org> wrote:
> On 2 September 2014 18:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
>>> On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> ...
>>>>>> We are using tools-only as part of the Debian packaging, what we are
>>>>>> trying to build is a usable generic version of mkimage (and potentially
>>>>>> other tools in the future) which can be placed in a generic u-boot-tools
>>>>>> package which is separate from the u-boot package(s) which contain(s)
>>>>>> u-boot binaries.
>>>>>
>>>>> mkimage has additional support for verified/secure boot, but only if
>>>>> enabled at build time. It is enabled for sandbox. So if you want full
>>>>> functionality you should use that build.
>>>>
>>>> However there are exceptions for it. For example MX28 has special
>>>> mxsimage support when it is in use.
>>>
>>> Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
>>> That seem wrong to me - do you know the reason for it?
>>
>> This is to avoid linking with SSL library[1].
>>
>> 1. http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e966d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115
>>
>> However now we have FIT signature I think we can enable it and drop
>> the MXS special usage.
>>
>> Do you agree?
>
> I agree (not sure about others). For sandbox we have SSL anyway so it
> should be fine.

I will wait Marek to comment here and if he agrees I prepare a patch
for it. Marek?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] tools-only build broken

[Marek Vasut]

On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote:
> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
> > On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
> >> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
> >> ...
> >> 
> >>>> We are using tools-only as part of the Debian packaging, what we are
> >>>> trying to build is a usable generic version of mkimage (and
> >>>> potentially other tools in the future) which can be placed in a
> >>>> generic u-boot-tools package which is separate from the u-boot
> >>>> package(s) which contain(s) u-boot binaries.
> >>> 
> >>> mkimage has additional support for verified/secure boot, but only if
> >>> enabled at build time. It is enabled for sandbox. So if you want full
> >>> functionality you should use that build.
> >> 
> >> However there are exceptions for it. For example MX28 has special
> >> mxsimage support when it is in use.
> > 
> > Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
> > That seem wrong to me - do you know the reason for it?
> 
> This is to avoid linking with SSL library[1].
> 
> 1.
> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e9
> 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115

No, you're wrong. It is not because of linking against SSL library, but to make 
sure this MXSimage support can be disabled easily.

> However now we have FIT signature I think we can enable it and drop
> the MXS special usage.

This claim is wrong too, the signed fitImage support was in U-Boot before the 
MXSimage support. (I remember I looked at this fitImage signature when I was 
integrating the mxsimage into U-Boot ;-))

> Do you agree?

I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and 
mxsimage.c respectively, but make sure the result won't break on various 
platforms.

Best regards,
Marek Vasut

[U-Boot] tools-only build broken

[Otavio Salvador]

Hello,

On Wed, Sep 3, 2014 at 6:25 AM, Marek Vasut <marex@denx.de> wrote:
> On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote:
>> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
>> > On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> >> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
>> >> ...
>> >>
>> >>>> We are using tools-only as part of the Debian packaging, what we are
>> >>>> trying to build is a usable generic version of mkimage (and
>> >>>> potentially other tools in the future) which can be placed in a
>> >>>> generic u-boot-tools package which is separate from the u-boot
>> >>>> package(s) which contain(s) u-boot binaries.
>> >>>
>> >>> mkimage has additional support for verified/secure boot, but only if
>> >>> enabled at build time. It is enabled for sandbox. So if you want full
>> >>> functionality you should use that build.
>> >>
>> >> However there are exceptions for it. For example MX28 has special
>> >> mxsimage support when it is in use.
>> >
>> > Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
>> > That seem wrong to me - do you know the reason for it?
>>
>> This is to avoid linking with SSL library[1].
>>
>> 1.
>> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e9
>> 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115
>
> No, you're wrong. It is not because of linking against SSL library, but to make
> sure this MXSimage support can be disabled easily.
>
>> However now we have FIT signature I think we can enable it and drop
>> the MXS special usage.
>
> This claim is wrong too, the signed fitImage support was in U-Boot before the
> MXSimage support. (I remember I looked at this fitImage signature when I was
> integrating the mxsimage into U-Boot ;-))
>
>> Do you agree?
>
> I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and
> mxsimage.c respectively, but make sure the result won't break on various
> platforms.

I have looked at this and I am unsure I still think removing it is a
good idea. I think the way to go is to change CONFIG_MXS to
CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think?
We would maintain the possibility to disable it if needed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] tools-only build broken

[Marek Vasut]

On Thursday, October 16, 2014 at 08:24:21 PM, Otavio Salvador wrote:
> Hello,
> 
> On Wed, Sep 3, 2014 at 6:25 AM, Marek Vasut <marex@denx.de> wrote:
> > On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote:
> >> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
> >> > On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br> 
wrote:
> >> >> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
> >> >> ...
> >> >> 
> >> >>>> We are using tools-only as part of the Debian packaging, what we
> >> >>>> are trying to build is a usable generic version of mkimage (and
> >> >>>> potentially other tools in the future) which can be placed in a
> >> >>>> generic u-boot-tools package which is separate from the u-boot
> >> >>>> package(s) which contain(s) u-boot binaries.
> >> >>> 
> >> >>> mkimage has additional support for verified/secure boot, but only if
> >> >>> enabled at build time. It is enabled for sandbox. So if you want
> >> >>> full functionality you should use that build.
> >> >> 
> >> >> However there are exceptions for it. For example MX28 has special
> >> >> mxsimage support when it is in use.
> >> > 
> >> > Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
> >> > That seem wrong to me - do you know the reason for it?
> >> 
> >> This is to avoid linking with SSL library[1].
> >> 
> >> 1.
> >> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90
> >> e9 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115
> > 
> > No, you're wrong. It is not because of linking against SSL library, but
> > to make sure this MXSimage support can be disabled easily.
> > 
> >> However now we have FIT signature I think we can enable it and drop
> >> the MXS special usage.
> > 
> > This claim is wrong too, the signed fitImage support was in U-Boot before
> > the MXSimage support. (I remember I looked at this fitImage signature
> > when I was integrating the mxsimage into U-Boot ;-))
> > 
> >> Do you agree?
> > 
> > I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and
> > mxsimage.c respectively, but make sure the result won't break on various
> > platforms.
> 
> I have looked at this and I am unsure I still think removing it is a
> good idea. I think the way to go is to change CONFIG_MXS to
> CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think?
> We would maintain the possibility to disable it if needed.

Nonsense, we should have as little amount of configurations as possible when
it comes to mkimage. I would be all for enabling both signed fitImage and MXS
image format by default and be done with it.

Best regards,
Marek Vasut

[U-Boot] tools-only build broken

[Otavio Salvador]

Hello,

On Thu, Oct 16, 2014 at 7:17 PM, Marek Vasut <marex@denx.de> wrote:
> On Thursday, October 16, 2014 at 08:24:21 PM, Otavio Salvador wrote:
>> Hello,
>>
>> On Wed, Sep 3, 2014 at 6:25 AM, Marek Vasut <marex@denx.de> wrote:
>> > On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote:
>> >> On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass <sjg@chromium.org> wrote:
>> >> > On 2 September 2014 15:44, Otavio Salvador <otavio@ossystems.com.br>
> wrote:
>> >> >> On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <sjg@chromium.org> wrote:
>> >> >> ...
>> >> >>
>> >> >>>> We are using tools-only as part of the Debian packaging, what we
>> >> >>>> are trying to build is a usable generic version of mkimage (and
>> >> >>>> potentially other tools in the future) which can be placed in a
>> >> >>>> generic u-boot-tools package which is separate from the u-boot
>> >> >>>> package(s) which contain(s) u-boot binaries.
>> >> >>>
>> >> >>> mkimage has additional support for verified/secure boot, but only if
>> >> >>> enabled at build time. It is enabled for sandbox. So if you want
>> >> >>> full functionality you should use that build.
>> >> >>
>> >> >> However there are exceptions for it. For example MX28 has special
>> >> >> mxsimage support when it is in use.
>> >> >
>> >> > Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c.
>> >> > That seem wrong to me - do you know the reason for it?
>> >>
>> >> This is to avoid linking with SSL library[1].
>> >>
>> >> 1.
>> >> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90
>> >> e9 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115
>> >
>> > No, you're wrong. It is not because of linking against SSL library, but
>> > to make sure this MXSimage support can be disabled easily.
>> >
>> >> However now we have FIT signature I think we can enable it and drop
>> >> the MXS special usage.
>> >
>> > This claim is wrong too, the signed fitImage support was in U-Boot before
>> > the MXSimage support. (I remember I looked at this fitImage signature
>> > when I was integrating the mxsimage into U-Boot ;-))
>> >
>> >> Do you agree?
>> >
>> > I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and
>> > mxsimage.c respectively, but make sure the result won't break on various
>> > platforms.
>>
>> I have looked at this and I am unsure I still think removing it is a
>> good idea. I think the way to go is to change CONFIG_MXS to
>> CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think?
>> We would maintain the possibility to disable it if needed.
>
> Nonsense, we should have as little amount of configurations as possible when
> it comes to mkimage. I would be all for enabling both signed fitImage and MXS
> image format by default and be done with it.

Ok, if we accept to have FIT enabled I am fine with it. I have the
patch in my local tree for it and I will send it tomorrow.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] tools-only build broken

[Marek Vasut]

On Friday, October 17, 2014 at 05:35:58 PM, Otavio Salvador wrote:
> Hello,

[...]

> >> I have looked at this and I am unsure I still think removing it is a
> >> good idea. I think the way to go is to change CONFIG_MXS to
> >> CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think?
> >> We would maintain the possibility to disable it if needed.
> > 
> > Nonsense, we should have as little amount of configurations as possible
> > when it comes to mkimage. I would be all for enabling both signed
> > fitImage and MXS image format by default and be done with it.
> 
> Ok, if we accept to have FIT enabled I am fine with it. I have the
> patch in my local tree for it and I will send it tomorrow.

I'd say give it a week or so until people return from ELCE proper.

Best regards,
Marek Vasut