Hi Nicolas,
On Mon, Nov 7, 2011 at 7:51 PM, Nicolas Pitre <n...@fluxnic.net> wrote:
> On Mon, 7 Nov 2011, Simon Glass wrote:
>
>> On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre <n...@fluxnic.net> wrote:
>>
>> > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
>> >
>> >> Dear Nicolas Pitre,
>> >>
>> >> > We don't want any hardcoded architecture specific address anymore.
>> >> > This is being removed from the kernel as we speak. If I cannot use a
>> >>
>> >> Also for raw images?
>> >
>> > No. The requirements on raw images are unchanged. you can use them if
>> > you wish, but generic ARM distributions can't use that if they want to
>> > target more than one SOC. Therefore raw images are not interesting by
>> > the use case at hand.
>>
>> I will leave you to your discussion, but want to pick up on this point.
>>
>> Can I assume that we have (or can have) a 'make uImage' target or
>> similar in the kernel which can pack together:
>>
>> - a compressed kernel (not zImage, I mean something that U-Boot can
>> decompress), with a rel_offset of 32KB
>
> Yes.
>
>> - a DTB
>
> No.
>
>> - a ramdisk
>
> No. However you can provide a set of files which can be included in an
> initramfs image linked directly into the kernel. But distributors never
> use that facility as they prefer a customized ramdisk created during
> kernel installation.
>
>> and that with Stephen's patch (committed to U-Boot) today, we can, in
>> U-Boot, with a script, load this uImage to somewhere and have U-Boot
>> decompress the kernel and set the bits out nicely in RAM, no matter
>> where that RAM is? The kernel will start at 32KB, and the other bits
>> will be somewhere above that. Then U-Boot can enter the kernel at 32KB
>> and all will be well, yes?
>>
>> Because it seems to me that this approach would work just as well as
>> the zImage approach (it is perhaps more 'pure' from a boot loader
>> point of view), and that the code in the kernel zImage header that
>> figures out where SDRAM is and decompresses the kernel to 32KB could
>> just as well be in U-Boot.
>
> Firstly, there is not just u-Boot out there. And since the layout
> optimization for Linux when decompressing is by definition Linux
> specific, this better live in zImage than be duplicated in every
> bootloaders.
Actually I was talking about the case where U-Boot does the
decompression. You have said it is supported above. I don't suggest
that it be the only option, only that it be an option. Perhaps only
U-Boot will use it, but that is fine. U-Boot is a popular boot loader.
If the boot loader puts the pieces in the right place, decompressed
and ready to go, we could presumably avoid this code in the kernel:
1096 4860 27129 arch/arm/boot/compressed/head.S
13 53 304 arch/arm/boot/compressed/big-endian.S
50 153 1267 arch/arm/boot/compressed/decompress.c
1096 4860 27129 arch/arm/boot/compressed/head.S
47 214 1238 arch/arm/boot/compressed/head-sa1100.S
139 650 3537 arch/arm/boot/compressed/head-shark.S
150 619 3564 arch/arm/boot/compressed/head-sharpsl.S
53 263 1685 arch/arm/boot/compressed/head-shmobile.S
41 179 992 arch/arm/boot/compressed/head-xscale.S
134 571 2868 arch/arm/boot/compressed/ll_char_wr.S
124 324 3011 arch/arm/boot/compressed/Makefile
208 589 3812 arch/arm/boot/compressed/misc.c
260 604 5289 arch/arm/boot/compressed/ofw-shark.c
6 10 145 arch/arm/boot/compressed/piggy.gzip.S
6 10 145 arch/arm/boot/compressed/piggy.lzma.S
6 10 144 arch/arm/boot/compressed/piggy.lzo.S
70 226 1481 arch/arm/boot/compressed/vmlinux.lds.in
2403 9335 56611 total
>
> Secondly, we don't want to pack a DTB with the kernel. For the same
> reasons as for the load address, we want a distributable kernel binary
> which contains no assumption about any specific board or machine. The
> kernel should be generic and be provided a machine specific DTB by the
> boot loader.
Yes, although one way for the boot loader to do that is to use mkimage
to create a FIT image with the kernel and the DTB file. Can the kernel
better facilitate that?
>
>> Then both groups get what they want.
>
> No. For both groups to get what they want, Stephen's latest patches
> should be merged. All they do is to allow for -1 as a load address in
> uImage to mean "never relocate but just use whatever address where
> uImage has been loaded." This cannot be simpler than that.
Quite agree with the latest patch - I tested it.
That gives the kernel what it wants. How can we give U-Boot what it
wants, which is apparently the ability to decompress the kernel itself
and arrange everything in memory at the right place? Wolfgang
complains that patches to do this have been repeatedly rejected in the
kernel. If this is the FIT image, how about adding a 'fitImage' make
target?
These are the targets I can see in the kernel:
Architecture specific targets (arm):
* zImage - Compressed kernel image (arch/arm/boot/zImage)
Image - Uncompressed kernel image (arch/arm/boot/Image)
* xipImage - XIP kernel image, if configured (arch/arm/boot/xipImage)
uImage - U-Boot wrapped zImage
bootpImage - Combined zImage and initial RAM disk
(supply initrd image via make variable INITRD=<path>)
dtbs - Build device tree blobs for enabled boards
install - Install uncompressed kernel
zinstall - Install compressed kernel
Install using (your) ~/bin/installkernel or
(distribution) /sbin/installkernel or
install to $(INSTALL_PATH) and run lilo
There doesn't seem to be a FIT image, but yet this is the 'modern'
image format in U-Boot. It seems odd that uImage says 'U-Boot wrapped
zImage' which suggests that it cannot support U-Boot decompressing the
image.
There seems to be a discussion about it here:
http://permalink.gmane.org/gmane.linux.kbuild.devel/4345
Regards,
Simon
>
>
> Nicolas
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
