All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] tools-only build broken
Date: Fri, 17 Oct 2014 00:17:16 +0200	[thread overview]
Message-ID: <201410170017.16843.marex@denx.de> (raw)
In-Reply-To: <CAP9ODKrxWY5+y_HQFE_=LF8LajsabE-BusjRtr0fie_ttbWg3A@mail.gmail.com>

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

  reply	other threads:[~2014-10-16 22:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 20:07 [U-Boot] tools-only build broken Ian Campbell
2014-08-30  0:04 ` Ian Campbell
2014-08-30  9:40   ` Matwey V. Kornilov
2014-08-31  2:44     ` Ian Campbell
2014-09-01  4:54       ` Simon Glass
2014-09-02  9:22         ` Ian Campbell
2014-09-02 19:19           ` Simon Glass
2014-09-02 21:44             ` Otavio Salvador
2014-09-02 23:14               ` Simon Glass
2014-09-03  1:44                 ` Otavio Salvador
2014-09-03  1:46                   ` Simon Glass
2014-09-03  2:20                     ` Otavio Salvador
2014-09-03  9:25                   ` Marek Vasut
2014-10-16 18:24                     ` Otavio Salvador
2014-10-16 22:17                       ` Marek Vasut [this message]
2014-10-17 15:35                         ` Otavio Salvador
2014-10-17 15:46                           ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201410170017.16843.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.