Nicolas, On Mon, Nov 07, 2011 at 10:51:33PM -0500, Nicolas Pitre 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.
exactly, see my comments below. > > 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. > > 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. > > > 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. It sounds like you are intending for distributions to provide uImages. Why can't they provide a generic zImage, and a post-install hook runs mkimage to add the board specific uImage header? Similar to update-grub on x86{_64}. This seems _more_ flexible to me, and fitting with standard conventions distributions are accustomed to. eg, after a kernel upgrade on a debian system, since I had 'apt-get install u-boot' there is a post-kernel install hook that would run a distro provided 'update-uboot' script. This script would read a board specific config file (or, the u-boot environment), add the u-boot header to the kernel, and possibly modify the u-boot environment to now load uImage-3.1-34. The file shipped with the kernel image package was a generic zImage which will now work on the board. Or, maybe I'm missing something... I always thought 'make uImage' was a convenience for developers. hth, Jason. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot