On Mon, Jan 17, 2011 at 6:34 PM, wu zhangjin <wuzhangjin@xxxxxxxxx> wrote: > Just a friendly reminder: no need to add the algo options in Kconfig > for we already have them in init/Kconfig, you can search LZMA, BZIP2 > ... there. No, I don't have these since my platform (jz4740) does not define SYS_SUPPORTS_ZBOOT. I don't know whether SFX-style compressed kernels work on it, probably nobody tried. U-boot uses it's own decompressor, so it's completely independent of zboot framework (piggy.o building, in-kernel algos). That's why I'm reluctant to merge vmlinuz and uImage build stages: these do completely different things. U-boot may support compression algos not included in the kernel and vice versa. Or some evil perverted person might want to build (un)compressed u-boot image from vmlinuz kernel, and it will probably work. ;) Should I create SYS_SUPPORTS_UBOOT then? Like this: arch/mips/Kconfig: +config SYS_SUPPORTS_UBOOT + bool + select HAVE_KERNEL_GZIP + select HAVE_KERNEL_BZIP2 + select HAVE_KERNEL_LZMA + select HAVE_KERNEL_LZO arch/mips/Makefile: +all-$(CONFIG_SYS_SUPPORTS_UBOOT)+= uImage ... +# u-boot +uImage: vmlinux.bin FORCE + $(Q)$(MAKE) $(build)=arch/mips/boot/u-boot \ + VMLINUX=$(vmlinux-32) VMLINUXBIN=arch/mips/boot/vmlinux.bin \ + VMLINUX_LOAD_ADDRESS=$(load-y) arch/mips/boot/u-boot/$@ Of course install and clean targets will be added as well. This will prevent vmlinuz from building and build uImage with chosen compression algo instead. I intend to keep u-boot/Makefile separate still. Of course it creates some code duplication, but I believe proper functional decoupling is more important in this case. u-boot/Makefile is (almost) architecture independent and can be easily adopted by other arch if such need arises. Comments and suggestions welcome. Regards, Sergey
