On Mon, 13 Sep 2010, Wolfgang Denk wrote: > Dear Nicolas, > > In message <alpine.lfd.2.00.1009122338310.19...@xanadu.home> you wrote: > > > > > Maybe this should/could be addressed on the Linux side then? We don't > > > have such problems on PwerPC, for example. > > > > On the Linux side, we currently have a fully position independent > > zImage. So you already can load it anywhere in RAM and branch to it > > with an offset of 0 from where it is loaded. > > It has to be started in RAM, i. e. we cannmot run it from a ROM > location?
If you want a ROMable zImage then you need to configure the kernel build for that case. So it's either zImage in ROM with a fixed address, or position independent zImage in RAM. > So your problem could be solved if we were able to specify a relative > load address (relative to the start of system RAM), and relative > entry point address (offset into image) ? Yes, that would work. > Why do we have to include the uncompression and relocating code in > each Linux kernel image, when we already have it in U-Boot? > I would like to be able to omit this on resource-restricted systems. Because U-Boot is not the only bootloader out there. And all the other bootloaders (lilo, grub, syslinux, redboot, etc.) rely on the zImage's ability to self-decompress, and no bootloader specific tool like mkimage is required to postprocess the result. Yet the reverse argument could be made about U-Boot: why include the decompression code in U-Boot when we already have it in zImage? Still, you have the possibility to use the Image result (without the z) which is uncompressed and non-relocatable (has to be loaded at the appropriate address), and encapsulate that into a uImage if you wish for U-Boot to decompress. > > And even better: rather than decompressing a ramdisk from flash, this is > > even more efficient to set an MTD partition for it and use the ramdisk > > content directly from flash as needed through the mtdblock device and > > not pin down memory for it needlessly. > > This may work in some cases. I agree that in almost all cases a > classical ramdisk image is not an optimal solution. However, it has > the charm that the underlying storage (the partition in flash) is not > used while the system is running, so you can overwrite it with a new > image. Few other setups allow this. I wouldn't trust such a setup with regards to resilience against unexpected power failure. But that's a topic for another discussion. Nicolas _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
