On 11/07/2011 03:11 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 74CDBE0F657A3D45AFBB94109FB122FF173F9A51AC@HQMAIL01.nvidia.com you wrote:
"Stuck with" isn't really a good description.
It is, IMO.
zImage is a way of booting ARM Linux. There may be others(?), but zImage is certainly a valid and popular mechanism. I don't see any reason to
Well, and uImage is the way of booting any OS on any architecture in U-Boot. It's certainly a valid and popular mechanism.
I agree (well, /a/ way, not /the/ way).
I think the difference here is that I get the impression that people within the U-Boot community would like to do away with zImage in general and replace it with uImage, which simply isn't plausible, whereas I'm perfectly happy for uImage to continue to exist, sometimes as a container for zImage, potentially a container for something else entirely, simply depending on what people want to put in there.
I think a discussion on such a base is not exactly constructive.
But yes, use of zImage in the first place is tangential. People definitely need/want to use zImage, and I think they should be allowed to, and I'm just trying to eliminate some pain points when embedding an ARM zImage within a uImage.
What exactly is wrong with the use of relative (offset) addresses?
And what made you change your mind?
I mentioned this before.
The fundamental problem with uImage having an absolute load address is that there may be no single absolute address that is usable as SDRAM across all ARM SoCs which may be supported by a single ARM Linux kernel. This is the basic problem I tried to solve with both my patch sets.
The reason that placing an SDRAM-relative address in the uImage header doesn't work is fundamentally the same reason, just driven by SW rather than HW memory maps.
People build U-Boot to load/run at all kinds of different addresses; even within NVIDIA we're currently using 0x00e08000 for mainline U-Boot, but would rather use 0x00108000 to fit better with our flashing tools. I have no idea what random addresses U-Boot is typically built for on OMAP, MSM, Exynos, or any other SoC. And this is just U-Boot; what about all the default (or end-user-custom) scripts that U-Boot executes; how do I know what ${loadaddr} is on every single U-boot installation, for each of kernel, initrd, FDT?
Given this, I'm no longer totally convinced that it's possible to pick some location in SDRAM (even specified relative rather absolute) where I can guarantee the kernel can reside.
Note that this location is something a distro vendor would have to pick when creating their distro kernel uImage, but end-users would expect that uImage to work irrespective of how they've hacked their U-Boot scripts - maybe they've changed their scripts to load the initrd or FDT to the place location the distro vendor assumed was free for the kernel. Maybe it isn't reasonable for users to expect this, but avoiding the need to pick such a location will reduce distro's support costs.
Instead, with a "-1" load address meaning "don't copy the kernel" as in my most recent patches, all we care about is that the U-Boot scripts load the kernel somewhere that doesn't overlap with where the initrd or FDT were loaded (or where U-Boot's code is). The decision point for this address is whoever writes/hacks the U-Boot scripts for the board. this is much more decentralized; the distro vendor doesn't have to make this decision, but rather it'd deferred to whatever the end-user or board maintainer picks in their U-Boot scripts. Much more flexible, much less risk of conflict, and any problems should be visible to the person who caused the problem, not the distro vendor.