[U-Boot] tools-only build broken
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.
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.
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.
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
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.
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
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.
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
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=90e966...
However now we have FIT signature I think we can enable it and drop the MXS special usage.
Do you agree?
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].
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
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].
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?
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].
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
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].
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.
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].
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
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].
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.
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
participants (5)
-
Ian Campbell -
Marek Vasut -
Matwey V. Kornilov -
Otavio Salvador -
Simon Glass