On Mon, 7 Nov 2011, Wolfgang Denk wrote: > Dear Marek Vasut, > > In message <201111072204.41980.marek.va...@gmail.com> you wrote: > > > > You have that runtime patching stuff in linux-arm-kernel now, there should > > be no > > problem with that anymore actually. So basically I understood there was an > > agreement to make special uImage/fitImage which ... oh doh, here is where > > I'm > > getting lost. Is it that the kernel will still be copied to address, but a > > relative one to where uImage is loaded -- and the entrypoint will be > > relative to > > that same address? > > Relative to the start of the system RAM. > > See > http://thread.gmane.org/gmane.linux.ports.arm.kernel/117512/focus=119281 > > There are to interesting pieces of information nicely summarized: > > 1) zImages are are relocatable. They should be loaded and started at > offsets between 32 KiB and 128 MiB in system RAM. > > 2) Raw images (without the preloader) have to be started at a fixed > address, virt_to_phys(PAGE_OFFSET + TEXT_OFFSET), which usually is > at an offset of 32 KiB in system RAM (with very few exzceptions). > > Both sitations can be handled perfectly find with offset addresses in > the images.
No. Please, we're trying to remove _all_ hardcoded addresses from the kernel boot process, absolute or relative. This is why zImage can be loaded at practically any address. If uImage insists on having a relative offset encoded into it, this is slightly better than the absolute address but not by much. Having the ability to use the _same_ uImage file and load it at _different_ addresses as specified by an argument to the load command is highly desirable. Pure zImage can do it already, so only u-Boot is imposing restrictions here. > When building the images from the kernel Makefiles, we can also make > sure that such architecture specific addresses are correctly set. 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 totally generic way to not specify a load address (using -1 for example) with mkimage soon, I'll be forced to remove the uImage makefile target from Linux as it will simply be broken otherwise. > This allows to boot such images without additional configuration or > adjustment of load and start addresses in the boot loader. This allows to boot such image on only one specific architecture if uImage must contain architecture specific addresses, be that absolute or relative. Granted, a relative offset is less problematic than an absolute address, but it is a problem nevertheless. Such architecture specific information must live with the boot loader (ideally as a script) and not embodied into an image that could otherwise be totally generic. > With Stephen's new approach, we could only use the zImage approach, > and we have to add additional configuration information to the boot > loader. Absolutely! That is where that configuration information must be. The bootloader is not generic since it must initialize a very specific piece of hardware. It therefore makes sense to associate the per architecture details such as the best kernel load address with the bootloader, not in the image itself. OTOH, the kernel must become as generic as possible. Using DT plays a big role in this. But not having a load address/offset encoded in the image is also part of this. Think of what mess a Linux distribution for ARM would otherwise have to carry when it must know that configuration information for each device it intends to support. Having a single kernel binary for as many ARM devices as possible is what we're aiming for, and currently u-Boot is one of the obstacles. Nicolas _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
