On Mon, Aug 13, 2012 at 11:49 AM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
Yes. It's there because on OMAP (most boards that use it anyway) there's no convenient flash storage space to put it, only a FAT partition on an MMC card. Therefore this is a part of U-Boot that is usually stored with the firmware, and in this case it is; on that very same FAT partition. That doesn't mean because its there, its available for change - except in extreme circumstances, I would say.
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!
Sure, the argument prevents nothing, and in any case I advocated this somewhere around here or a little later on in my huge email (sorry). Nothing's stopping that except perhaps the problem that "source" relies on verifying the uImage header so it can find out the length of the script data (otherwise it could parse to the end of memory if given a chance, it has no other clue as to when the script ends, and if you load many scripts to the same address, there may be valid script data after the smallest script you load after the first one..)
Filesystem load commands usually return the amount of data fetched so it could be filled in somewhere and supplied to "source", though, as a fhird argument (right now it's "source $address $fit_section", it could be expanded like bootm or bootz deals with missing ramdisks for device trees and end up as "source $address - $length")
Not really a question for here, but how does hush deal with return values? I never did find a way to read out the last return value to parse it in a script. On bash I'd just use ${?}. It kind of doesn't work here but then I might also be overusing brackets and what I need to do is say $? - we also have a problem with "setenv ramdiskaddr "-"" nuking the hush interpreter for some reason. We use this to autodetect if a ramdisk has been created for the kernel to be highly generic.. without a little hack to modify the ramdiskaddr variable, you end up with two specific scripts or checking if "ramdisk" filename is set which is not a reliable check compared to verifying the image type or checking the number of bytes loaded/error condition for the filesystem load.
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 we cannot expect every U-Boot to know what variables every distro or OS will ever need. You can't be all things to all men without considerable and unending churn, so a bare minimum (base address for scripts to load and source, next-stage-of-boot (kernel, bootloader), filesystem-in-ram, device-tree-blob is the bare minimum) is required. Anything else would have to be distro-specific. Luckily not many distros try to do anything else too fancy. When they do, they could make some educated guesses (if they can parse uEnv.txt, not write it, they can figure out the addresses in use and find places to put other things).
I think this already got defined, but kernel, ramdisk, dtb and possibly base script addresses should be there. Anything else is OS-specific and possibly board-specific. And I'll reiterate my opinion that the kernel address should be entirely different to the default "loadaddr" too if possible just to keep it away from potentially damaging "default" behaviors of mistyped U-Boot commands. That way it can also be used as a seperate, known address for boot.scr code that will not end up trashing the kernel. So you have four addresses an OS can "hijack" for any reason, given some restrictions on the usual sizes of those memory areas (nothing defines how big those areas really are and there's no way to find out from hush just how big the file is without loading it anyway)
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.
Indeed, then mkimage is only required for scripts... which could go away.
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.
Okay.
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
Okay so the flag method is mainlined. That's good. This should definitely be set in every kernel packager that ships a uImage or makes a uImage.
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).
Indeed.
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...
I am always, always advocating using zImages.. but there are all kinds of legacy reasons why distros come with mkimage preinstalled on ARM boxes. You may be building a new U-Boot (Linaro does) for each board, and this box has to build those tools. I find it unlikely that even though we don't require it to make a system boot on Distro A or Distro B, Distro C may have a legacy board to support, or it's required to build at least the boot.scr and therefore, it will therefore never, ever NOT be around..
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.
Right. It remains to be seen how this can be solved. Then maybe mkimage ca go away (but it'd still get built and be in the package repos, right?)
As I said I think the only restriction is that "source" validates a uImage and needs to pass a length to the interpreter to get it to actually parse the thing.