Dear Stephen Warren, In message <4eb87122.3050...@nvidia.com> you wrote: > > 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.
Good. You confirm my understanding that only the zImages are relocatable, while the raw images are not. > > 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. No, this is not an optinal feature. That's how it is supposed to work, and how it actually works on all ARM systems in mainline U-Boot. > 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. I cannot and will not comment on out-of-tree code. > 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 ...? The chaos results from two systems working against each other: U-Boot is capable of loading linux kernel images in place and start them, but instead of letting it do what it can, you load a zImage, which includes it's own wrapper, copy code, gzip code and all that stuff. Agreed, that may be useful on simple boot loaders. but in U-Boot it is not only not useful, it creates all the problems you are complaining about. If you just wrap a raw kernel image instead into a uImage (like we for example do on Power), then you have everythign you want: you can load the uImage at semi-random addresses in RAM, or you can even directly boot ir from NOR flash. > (I honestly feel like I've repeated myself on this point many times. I'm > not sure how to restate it any differently.) Repeating the stuff does not make it more convincing to me. > > 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. On PPC we simple do not use the image wrapper when building uImages. It's only ARM that insists it must always only zImages, and everthing else is inherently bad. Patches to wrap raw kernel images instead have been submitted a number of times before (I think starting with 2.4.17 or something like that) but have always been rejected. Drop the wrapper in uImages, and the problem goes away. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am an atheist, thank God! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
