On 08/09/2012 12:00 PM, Matt Sealey wrote:
On Thu, Aug 9, 2012 at 11:23 AM, Brendan Conoboy blc@redhat.com wrote:
On 08/08/2012 08:37 PM, Matt Sealey wrote:
uEnv.txt and boot.scr aren't the same thing. uEnv.txt is the U-Boot environment usually on a fat partition. boot.scr is loaded by a readily loaded environment... You either predefined your environment and boot from it or you're using values from that environment. I wouldn't use uEnv.txt to replace a boot.scr on any system..
I don't think that is entirely accurate- uboots such as those for OMAP rely on uEnv.txt for everything. Sure, you can daisy-chain load a boot.scr, but why do so when uEnv.txt can perform both functions?
Seperation.
Apologies if I re-hash any part of the conversation I missed, but this is my understanding of what is required and what the current situation is;
uEnv.txt or the SPI NOR or MMC raw blocks or the default environment in U-Boot encoded at compile-time then run-time is the thing that should define the absolute fixed definitions of the board. This is, after all, the environment you want every time you boot.
I think all you're arguing here is that the specific file uEnv.txt is an alternative to storing the environment in raw NOR/eMMC/NAND/... and hence uEnv.txt shouldn't be hacked about by operating systems; it's more part of the firmware.
However, I don't see that argument as preventing (discussion of) replacing a uImage-encoded boot.scr with a plain-text file instead. Such a change would make life easier for people to modify the file (i.e. not needing mkimage). The only issue here is that such a file couldn't be called uEnv.txt because its purpose is different. Perhaps boot.txt instead of boot.scr? There's plenty of bike-shedding opportunity here!
The address to load to is probably properly defined in the environment, but if it's not this is a good reason to redefine uEnv.txt. In the case of a fixed memory start and size, the memory map is defined in U-Boot but could be done in the script just as well since the distro will know what location to boot from.
I disagree with "could be done" here; I believe that U-Boot must provide a complete set of environment variables to boot.scr (or whatever script file) that describe all load addresses. We really can't expect every OS/distro to know the legal memory layout for every board of every SoC, and hence to be able to ship or synthesize a boot.scr that encodes all the various load addresses. Given that we need such variables in some cases, we may as well make all cases work this way for consistency and simplicity.
In this sense, what should really happen is people quit using bootm to source uImage files, and just use zImage and raw ramdisks.
Recent U-Boot has a bootz command for ARM that allows this.
Or fix U-Boot to take a perfectly invalid "load address" or "entry point" in a uImage header to mean "don't relocate me", or
That specific approach (an address in the uImage header meaning "don't relocate me") was explicitly rejected by Wofgang Denk.
define a flag in the uImage format that says "do not relocate this under any circumstances".
Recent U-Boot has a new uImage type IH_TYPE_KERNEL_NOLOAD which indicates a kernel image that does not get loaded (loaded meaning copying the image to the address defined by the uImage header "load address" field in this case). I forget if one can achieve this for initrds. Raw .dtb files can be used for the device tree, to ensure they don't get relocated (or perhaps fdt_high set in a way that prevents relocation).
that can perform all bootup initialization is preferable- no need to regenerate boot.scr, which is sometimes not practical (EG, you're creating installations on a system without mkimage, or you're half-booted and in emergency recovery shell and your initramfs didn't include mkimage).
Why would you be creating installations on a system without mkimage? How would you prep your kernel?
You were just advocating above to use raw zImages rather than a uImage for the kernel...
So, raw zImage plus raw initrd plus raw DTB means no need for mkimage. It'd be nice if boot.scr/... also didn't need mkimage.