public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Charles Manning <cdhmanning@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
Date: Wed, 12 Mar 2014 08:49:41 +1300	[thread overview]
Message-ID: <201403120849.41243.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <20140311181325.6F1B.AA925319@jp.panasonic.com>

On Tuesday 11 March 2014 22:13:26 you wrote:
> Hello Charles, Gerhard,
>
> > > > Is there any (real, technical) reason why the bzip stuff (the
> > > > CRC-32 calculation that has been made available separately)
> > > > cannot get built and used as a library, and the tools/
> > > > application just gets linked against it as one would expect?
> > >
> > > From my limited understanding, lib/ is not built for the host. It is
> > > only built for the target. That is why we have all these ugly C files:
> > > crc32.c, sha1.c,... in tools/.
> >
> > With Kbuild, is the '#include "../otherdir/source.c" trick still
> > needed?  Would a list of object files with relative path specs
> > work, or can object files in one output directory result from
> > compile units taken out of several source directories?
>
> In this case, object files with relative path such as "../lib/foo.o"
> does not work.
>
> If we write   ../lib/foo.o  in tools/Makefile,
> $(HOSTCC) will compile foo.o into lib/ directory.
> And lator it will be overwritten with the one compiled with $(CC).
>
> I thought this is a simple way to generate two objects from
> one source file,
> one is for hostprogs in tools/ and the other for the target in lib/.

In the long run, I guess splitting the objects something like how SPL is 
handled in parallel to main u-boot is the right thing, but I absolutely agree 
with you that this should be a separate exercise. Mixing adding new features 
and refactoring in one patch is best avoided.

It is a similar issue that makes most of the target side code unavailable for 
the host tools. For example, anything requiring <asm/*> will clearly NOT work 
since the host side processor environment need not be, and indeed seldom is, 
the same as target. Perhaps a split compile could fix that, but it is beyond 
the scope of this exercise.


>
> BTW, I sometimes see #include for "*.c"
> for example, drivers/usb/host/ehci-hcd.c of Linux Kernel,
> although I admit it is ugly.
>
> I agree we need to do something with it,
> but it's beyond the scope of this patch.
>
> > diff --git a/spl/Makefile b/spl/Makefile
> > index 346d0aa..4e0f33f 100644
> > --- a/spl/Makefile
> > +++ b/spl/Makefile
> > @@ -182,6 +182,11 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin
> >
> >  ALL-y	+= $(obj)/$(SPL_BIN).bin
> >
> > +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin
> > +	$(OBJTREE)/tools/mkimage -T socfpgaimage -d $< $@
> > +
> > +ALL-$(CONFIG_SOCFPGA) += $(OBJTREE)/socfpga-signed-preloader.bin
> > +
> >  ifdef CONFIG_SAMSUNG
> >  ALL-y	+= $(obj)/$(BOARD)-spl.bin
> >  endif
>
> Could you re-write this part as follows, please?
>
>
> diff --git a/spl/Makefile b/spl/Makefile
> index bb3d349..9f3893e 100644
> --- a/spl/Makefile
> +++ b/spl/Makefile
> @@ -184,6 +184,12 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin
>
>  ALL-y  += $(obj)/$(SPL_BIN).bin
>
> +MKIMAGEFLAGS_socfpga-signed-preloader.bin := -T socfpgaimage
> +socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin
> +       $(call cmd,mkimage)
> +
> +ALL-$(CONFIG_SOCFPGA) += socfpga-signed-preloader.bin
> +
>  ifdef CONFIG_SAMSUNG
>  ALL-y  += $(obj)/$(BOARD)-spl.bin
>  endif

Thank you. I shall try that.

Thank you for that valuable feedback.

Regards.

-- Charles

      reply	other threads:[~2014-03-11 19:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-23 22:35 [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage Charles Manning
2014-02-24  6:48 ` Wolfgang Denk
2014-02-24 19:18   ` Charles Manning
2014-02-24 21:03     ` Charles Manning
2014-02-27 21:19       ` Wolfgang Denk
2014-02-27 21:46         ` Charles Manning
2014-02-27 21:23       ` Wolfgang Denk
2014-02-27 21:52         ` Charles Manning
2014-02-26  1:17 ` [U-Boot] [PATCH v5] " Charles Manning
2014-02-26  6:16   ` Michal Simek
2014-02-26  7:42     ` Charles Manning
2014-02-26 20:00       ` Dinh Nguyen
2014-02-27  3:49   ` [U-Boot] [PATCH v6] " Charles Manning
2014-02-27 21:57     ` Wolfgang Denk
2014-02-27 22:43       ` Charles Manning
2014-03-05  4:36         ` Charles Manning
2014-02-27 22:34     ` Chin Liang See
2014-03-06  2:40     ` [U-Boot] [PATCH v7] " Charles Manning
2014-03-08 16:51       ` Gerhard Sittig
2014-03-10  3:04         ` Charles Manning
2014-03-10 19:36           ` Gerhard Sittig
2014-03-10 20:50             ` Charles Manning
2014-03-11  9:13             ` Masahiro Yamada
2014-03-11 19:49               ` Charles Manning [this message]

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=201403120849.41243.manningc2@actrix.gen.nz \
    --to=cdhmanning@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox