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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
