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