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
prev parent 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