Hi MFM,
> what gzip got to do with the mkimage, do we have to compress the kernel before
> uploading it to flash?
Compressing the kernel is up to you ... if you're operating in an embedded environment, it may
become a requirement if you have limited non-volatile memory resources.
When you generate for example, bzImage, the kernel is already compressed and includes its
own decompression/relocation code. In this case you would tell u-boot that the image has
compression 'None' since
u-boot is not required to perform the decompression.
If you choose to compress the kernel yourself (e.g. using gzip) then you should tell u-boot
that the image compression is "gzip" -- then u-boot will decompress the kernel as it copies
it to its load address.
So why not just let the kernel make scripts generate a compressed image? Well, for
uClinux/Nios-II it really doesn't matter since (the last time I looked), the uClinux kernel
doesn't expect any parameters to be passed into it by the bootloader. In some other
architectures (like PowerPC), however, the kernel expects parameters to be passed in
(such as the kernel command line, a pointer to a compressed ramdisk image, etc) -- usually
referred to as "residual data". When you build a compressed kernel image, the "boot" code
that decompresses the kernel usually does not expect any bootloader parameters and
instead hard codes the residual data. This eliminates some nice features in u-boot (most
notably the kernel command line).
So there's a long-winded explanation -- sorry for rambling. But here's the bottom line:
The preferred u-boot way: Generate an uncompressed kernel image from the kernel make.
Then compress it yourself with bzip/gzip and tell mkimage it's compressed.
The Nios-II way: right now it doesn't matter.
I do things the u-boot way ... but to be honest, it's only because of habit. If you're using
buildroot, there's no need to do things the u-boot way since everything is a single image
(with ramdisk) -- so just tell mkimage that compression = 'None'.
Regards,
--Scott