On Tue, Jan 18, 2011 at 2:23 AM, Sergey Kvachonok <ravenexp@xxxxxxxxx> wrote:
> 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.
Perhaps you can get a try, as I know uImage does have some problem on
U-boot for U-boot allocates fixed-size memory for the decompressed
kernel image, then, the max size of the vmlinux.bin is limited to the
max size(seems it is only 8M by default), but it may be still safe for
perhaps nobody will get such a big kernel image.
SFX-style doesn't have the above problem for it considers this problem
before linking, but it requires the bootloader to parse the ELF header
to get the right entry point. A known problem of the current vmlinuz
support is some bootloader may don't parse the right entry point from
the ELF header but just load them to a fixed address: the $(load-y)
value defined in arch/mips/Makefile or arch/mips/*/Platform, this will
be fixed asap and the solution is already in my mind.
> U-boot uses it's own decompressor,
Yeah, your new config SYS_SUPPORTS_UBOOT does solve this problem.
> 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. ;)
Adding uImage target to arch/mips/boot/compressed/Makefile doesn't
need the building of vmlinuz, it depends on If you have selected
SYS_SUPPORTS_ZBOOT for your board, just as your reply shows below,
your board can still only select SYS_SUPPORTS_UBOOT without building
the vmlinuz ;-)
>
> 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
Yep, this does solve the problem "U-boot uses it's own decompressor,"
>
> arch/mips/Makefile:
>
> +all-$(CONFIG_SYS_SUPPORTS_UBOOT)+= uImage
>
That's it ;-)
> ...
>
> +# 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.
If CONFIG_SYS_SUPPORTS_ZBOOT is false, vmlinuz will not be compiled
either for we have this line:
all-$(CONFIG_SYS_SUPPORTS_ZBOOT)+= vmlinuz
>
> 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.
Ok, no problem, but why not share the same source code If we can do it
easily and with smaller patch ;-)
> u-boot/Makefile is (almost) architecture independent and can be easily
> adopted by other arch if such need arises.
Yeah, then, the boards can select them like ZBOOT does.
config BOARD_NAME
....
select SYS_SUPPORTS_UBOOT
Then, the other boards will still be independent.
Regards,
Wu Zhangjin
>
> Comments and suggestions welcome.
>
> Regards,
> Sergey
>
