On 11/07/2011 04:08 PM, Wolfgang Denk wrote:
> In message <4eb85bf3.8030...@nvidia.com> you [Stephen Warren] wrote:
...
>> 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.
>
> But this is actually a non-issue. See the
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/115774/focus=115881
>
> If you wrap a zImage, there is a _guarantee_ that such a single
> working address exists, but it is not an absolute address, it is
> relative to the start of system RAM. If we chose an offset of 32 KiB
> this will work on all systems.
In the thread linked from that link you gave above, there are specific
examples where the value isn't 32K-from-start-of-SDRAM.
Even if that weren't true, putting the zImage there is actually the
absolute worst place it could be.
The uncompressed image needs to end up at 32K-from-start-of-SDRAM (or
whatever SoC-specific value the kernel defines). If U-Boot puts the
zImage at that same location, the first thing the U-Boot decompressor
must do is copy the compressed image somewhere else in SDRAM, so that
when the decompressed kernel is written to 32K (or wherever), it doesn't
overwrite the compressed image it's decompressing.
>> 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.
>
> I'm missing an explanation why you think a "SDRAM-relative address in
> the uImage header doesn't work". Please elucidate.
The paragaphs immediately following the one you quoted were that
explanation.
>> 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
>
> You mean you don't put U-Boot at the end of physical RAM? Well, I
> guess you must have your reasons for deviating from what is considered
> standard in mainline.
I keep forgetting that U-Boot typically relocates itself to high memory,
so the location it runs from initially isn't always relevant.
Still, this is an optional feature, so I don't think it's good practice
to rely on it absolutely.
As background, this feature is enabled for Tegra20 in the mainline
U-Boot repository, but not in our internal Tegra30 repositories for
example. I believe we eventually intend to enable this option for
Tegra30 too, but there's some bug that causes the relocation to fail at
the moment.
>> 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?
>
> I can understand that you don't have such knowledge. But I don't see
> how this is in any way related with the topic we're discussing here?
It's the central point of the discussion!
The issue is: When a distro vendor creates a uImage, can they pick an
address (be it absolute, relative, or whatever) where the bootm command
can copy the zImage to, and be 100% guaranteed that address won't
conflict with U-Boot code, wherever the U-Boot environment loaded the
initrd, or wherever the U-Boot environment loaded the FDT, or ...?
Given that anyone can tweak the U-Boot environment to ext/fat/...load
the initrd and FDT to any address whatsoever, I believe the answer to
this question is no.
And given the answer is no: We need a solution where U-Boot can be told
to just leave the zImage wherever the U-Boot environment happened to
load it, and use it in place. Presumably whoever constructed the
environment has the most detailed knowledge of the HW's and U-Boot
environment's expected memory layout for that particular board.
(I honestly feel like I've repeated myself on this point many times. I'm
not sure how to restate it any differently.)
>> 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.
>
> It appears ARM is the only architecture to ever have such a problem.
> For everybody else this has been working without any problems for
> over a decade.
>
>> 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
>
> So what? See above - we've been doing this for many, many years
> already. This has never been a problem anywhere. Execpt on ARM.
It's quite possible that there's more standardization on other
architectures. I'm not familiar enough with e.g. PPC to know why there
aren't issues there.
--
nvpublic
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
