From: Charles Manning <cdhmanning@gmail.com>
Date: Wed, 12 Mar 2014 08:49:41 +1300
Subject: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to
	mkimage
In-Reply-To: <20140311181325.6F1B.AA925319@jp.panasonic.com>
References: <201403101604.58362.manningc2@actrix.gen.nz>
	<20140310193624.GC3327@book.gsilab.sittig.org>
	<20140311181325.6F1B.AA925319@jp.panasonic.com>
Message-ID: <201403120849.41243.manningc2@actrix.gen.nz>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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