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 2This 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.
Quoted 7 lines · 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
Quoted 6 lines
This is because tools-only depends on $(version_h), depends on
include/config/uboot.release, dependsinclude/config/auto.conf. I think this is all due to the support forLOCALVERSION(_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.
30.08.2014 04:04, Ian Campbell ?????:
Quoted 2 lines
In the meantime "touch
include/config/auto.conf" lets it build (hardly ideal though!)
Hi, I do
make defconfig
make silentoldconfig
make tools-only
Quoted 10 lines · Matwey V. Kornilov
30.08.2014 04:04, Ian Campbell ?????:
Quoted 2 lines
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,
Quoted 8 lines · Ian Campbell
Quoted 7 lines · Matwey V. Kornilov
30.08.2014 04:04, Ian Campbell ?????:
Quoted 2 lines
In the meantime "touch
include/config/auto.conf" lets it build (hardly ideal though!)Hi, I do
Quoted 7 lines
Quoted 3 lines
make defconfig
make silentoldconfig
make tools-onlyThanks. 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
Quoted 15 lines · Simon Glass
Hi,
Quoted 12 lines · Ian Campbell
Quoted 10 lines · Matwey V. Kornilov
30.08.2014 04:04, Ian Campbell ?????:
Quoted 2 lines
In the meantime "touch
include/config/auto.conf" lets it build (hardly ideal though!)Hi, I do
make defconfig
make silentoldconfig
make tools-only
Quoted 5 lines
Quoted 3 lines
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?
Quoted 2 lines
and builds with
sandbox_defconfigso 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,
Quoted 16 lines · Ian Campbell
Quoted 15 lines · Simon Glass
Hi,
Quoted 12 lines · Ian Campbell
Quoted 10 lines · Matwey V. Kornilov
30.08.2014 04:04, Ian Campbell ?????:
Quoted 2 lines
In the meantime "touch
include/config/auto.conf" lets it build (hardly ideal though!)Hi, I do
make defconfig
make silentoldconfig
make tools-only
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 3 lines
and builds with
sandbox_defconfigso that you get full
functionality (verified boot).
Quoted 8 lines
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 <[email protected]> wrote:
...
Quoted 9 lines
Quoted 5 lines
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.
Signature · 3 lines
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
Hi Otavio,
Quoted 8 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 13 lines · Simon Glass
Quoted 12 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
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 oftools/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?
Signature · 3 lines
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
Hi Otvaio,
Quoted 20 lines · Otavio Salvador
Quoted 13 lines · Simon Glass
Quoted 12 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
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 oftools/mksimage.c. That seem wrong to me - do you know the reason for it?
Quoted 8 lines
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
Quoted 25 lines · Simon Glass
Quoted 24 lines · Otavio Salvador
Quoted 13 lines · Simon Glass
Quoted 12 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
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 oftools/mksimage.c. That seem wrong to me - do you know the reason for it?This is to avoid linking with SSL library[1].
Quoted 7 lines
Quoted 4 lines
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?
Signature · 3 lines
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
Quoted 18 lines · Otavio Salvador
Quoted 17 lines · Simon Glass
Quoted 15 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 9 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
Yes, I see the '#ifdef
CONFIG_MXS' at the top oftools/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.
Quoted 2 lines
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 ;-))
Quoted 1 line
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,
Quoted 38 lines · Marek Vasut
Quoted 18 lines · Otavio Salvador
Quoted 17 lines · Simon Glass
Quoted 15 lines · Otavio Salvador
On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass <[email protected]> wrote:
...Quoted 9 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
Yes, I see the '#ifdef
CONFIG_MXS' at the top oftools/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#l115No, you're wrong. It is not because of linking against SSL library, but to make sure this MXSimage support can be disabled easily.
Quoted 2 lines
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 ;-))
Quoted 5 lines
Quoted 1 line
Do you agree?
I agree this -DCONFIG_MXS and the ifdef can be removed from
Makefileandmxsimage.crespectively, 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.
Signature · 3 lines
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
Quoted 6 lines · Otavio Salvador
Hello,
Quoted 3 lines · Marek Vasut
Quoted 2 lines · Otavio Salvador
Quoted 1 line · Simon Glass
On 2 September 2014 15:44, Otavio Salvador <[email protected]>
Quoted 37 lines · wrote:
Quoted 37 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines · Simon Glass
...
Quoted 9 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
Yes, I see the '#ifdef
CONFIG_MXS' at the top oftools/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#l115No, you're wrong. It is not because of linking against SSL library, but to make sure this MXSimage support can be disabled easily.
Quoted 2 lines
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 ;-))
Quoted 1 line
Do you agree?
Quoted 8 lines
Quoted 3 lines
I agree this -DCONFIG_MXS and the ifdef can be removed from
Makefileandmxsimage.crespectively, 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_MXStoCONFIG_MXSIMAGEand 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,
Quoted 49 lines · Marek Vasut
Quoted 6 lines · Otavio Salvador
Hello,
Quoted 3 lines · Marek Vasut
Quoted 2 lines · Otavio Salvador
Quoted 1 line · Simon Glass
On 2 September 2014 15:44, Otavio Salvador <[email protected]>
Quoted 41 lines · wrote:
Quoted 40 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines · Simon Glass
...
Quoted 9 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
Yes, I see the '#ifdef
CONFIG_MXS' at the top oftools/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#l115No, you're wrong. It is not because of linking against SSL library, but to make sure this MXSimage support can be disabled easily.
Quoted 2 lines
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 ;-))
Quoted 1 line
Do you agree?
I agree this -DCONFIG_MXS and the ifdef can be removed from
Makefileandmxsimage.crespectively, but make sure the result won't break on various platforms.
Quoted 8 lines
Quoted 4 lines
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_MXStoCONFIG_MXSIMAGEand 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.
Signature · 3 lines
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
Quoted 1 line · Otavio Salvador
Hello,
[...]
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
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_MXStoCONFIG_MXSIMAGEand 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