On Thu, Jul 26, 2012, Alexander Graf wrote:

It might however be an interesting idea to have a similar split to coreboot / tianocore in the u-boot world. U-boot could still be the bit implementing the initial initialization and maybe even device i/o drivers, while a uefi capable payload could then implement all the uefi layering on top. Then we could either load Linux directly from u-boot like we do today, or bootstrap outselves into a uefi implementation that would allow for generic booting across the board.

Exactly; my point about an UEFI boot cmd in U-Boot was to try to store this UEFI-implementing payload in an UEFI-compatible place itself as much as possible, and then have U-Boot discover it.

It's a bit chicken-and-egg though :-)

Loïc Minier wrote:

On Wed, Jul 25, 2012, David Marlin wrote: [...]

...

Other boards provide similar features, including some (e.g., Trim-Slice) that 'scan' through a list of devices until a boot.scr is found, load it, and then boot using that script, but the load addresses are literals.

That's definitely a great feature which kinds of mimic the behavior of the SoC or of a BIOS to try to boot from multiple bootable devices.

...

Does anyone else think it would be useful to include a 'standard' set of such definitions in U-Boot (default) that could be used to abstract the board/vendor specific details and provide a more consistent user experience? If so, could this list be used to help define such a set, and encourage its use across ARM systems and distros?

Definitely; thanks for starting this!

There are various difficulties along the way:

• even if we get the changes into upstream U-Boot and if OEMs ship it unmodified, we will have to deal with older U-Boot builds, custom configs etc. for years to come -- except if we are also providing the U-Boot binaries

Agreed, but if we want such changes we have to start sometime. If users of 'legacy' devices choose, they can update U-Boot or their U-Boot environment to match any agreed upon settings.

• it's unlikely that we get the default bootcmd changed for all ARM boards in a consistent manner due to different maintainers having different tastes, or even due to the set of features (such as CONFIG_HUSH) which are enabled in each board's config; one possibility is to introduce a different command (e.g. "autoboot") that would emulate some kind of boot device and boot files research and that people could use in their bootcmd or not

Understood. I'm not sure how much of a 'standard' would be applied by all maintainers, but it would be nice to have a standard to reference for those who choose to implement it. Hopefully most would, if it existed. Are many of the current U-Boot maintainers involved on this list? Getting their input and agreement would be the best way to see any standard implemented.

• there's probably not an universal boot order for devices, so that this needs to remain configurable; it might be valid to try booting from the network and fallback to flash for some use cases, and it might be inappropriate in other cases, or the same story with SD/MMC vs. SATA etc.; this is probably the hardest problem; in some cases you might event want the end-user to be able to chose the method / boot order interactively (e.g. by pressing a button on beagleboards or by chosing from a menu on the serial console etc.)

Agreed, there is probably no one universal boot order for all devices, but having "a" boot order defined for each device, and as you mentioned some way for the user to select or override it, should be doable.

Now please pardon this small diversion, but perhaps it's relevant to think about UEFI. UEFI defines the format of the partition table, expected locations of vendor extensions, a boot protocol etc. Perhaps we could leverage the UEFI boot protocol for U-Boot's implementation; for instance, U-Boot already has support for GPT partition tables, perhaps it could be extended to support an "uefiboot" command that would mimic the behavior of an UEFI firmware. This would allow using UEFI as the standard both for U-Boot's behavior and as a standard for the format/layout of bootable images and of the installed system for distros and OEMs.

UEFI is definitely on the radar, but I was thinking smaller in scope at this time. Just getting some standard definitions in the U-Boot environment would go a long way toward improving the user and developer experience across platforms, IMHO.

Thank you for your input,

d.marlin =======

Loïc Minier wrote:

On Thu, Jul 26, 2012, David A. Marlin wrote:

...

Understood. I'm not sure how much of a 'standard' would be applied by all maintainers, but it would be nice to have a standard to reference for those who choose to implement it. Hopefully most would, if it existed. Are many of the current U-Boot maintainers involved on this list? Getting their input and agreement would be the best way to see any standard implemented.

I don't think we have many U-Boot maintainers on this list; you'd want to put up a proposal for the U-Boot mailing-list, but it's a high-traffic list for development typically in the form of patch reviews. (IOW, it's perhaps best to send a concrete proposal there rather than open-ended questions.)

Understood. So maybe we have enough user experience here to come up with a general consensus to post to that list as a starting point, and let the maintainers on that list refine it (if they have the time and inclination/interest)?

d.marlin

On 07/26/2012 04:12 AM, Loïc Minier wrote:

On Wed, Jul 25, 2012, David Marlin wrote: [...]

...

Other boards provide similar features, including some (e.g., Trim-Slice) that 'scan' through a list of devices until a boot.scr is found, load it, and then boot using that script, but the load addresses are literals.

That's definitely a great feature which kinds of mimic the behavior of the SoC or of a BIOS to try to boot from multiple bootable devices.

...

Does anyone else think it would be useful to include a 'standard' set of such definitions in U-Boot (default) that could be used to abstract the board/vendor specific details and provide a more consistent user experience? If so, could this list be used to help define such a set, and encourage its use across ARM systems and distros?

Definitely; thanks for starting this!

There are various difficulties along the way:

...

• there's probably not an universal boot order for devices, so that this needs to remain configurable; it might be valid to try booting from the network and fallback to flash for some use cases, and it might be inappropriate in other cases, or the same story with SD/MMC vs. SATA etc.; this is probably the hardest problem; in some cases you might event want the end-user to be able to chose the method / boot order interactively (e.g. by pressing a button on beagleboards or by chosing from a menu on the serial console etc.)

The approach I took on Tegra was to have a U-Boot environment variable that defines the boot order. An example setting might be:

boot_targets=dhcp mmc1 mmc0 usb0

For details, see "4878343 tegra: bootcmd enhancements" in git://git.denx.de/u-boot-tegra.git master

With such a variable, one could have a completely standardized core bootcmd that iterates over boot_targets, with boot_targets being defined initially by the per-board U-Boot configuration file (to limit it to the set of devices the board has and apply default boot order policy) but which can also be over-ridden by the user by editing/saving the environment for customization. Perhaps we could even allow customization using an interactive menu system (I vaguely recall someone may have ported/been-porting barebox's menu system to U-Boot?)

On Wednesday 08 August 2012 16:25:51 Rob Herring wrote:

Stephen Warren <swarren@...> writes:

...

Related to this topic also are:

93d87d5 tegra: define fdt_load/fdt_high variables 4878343 tegra: bootcmd enhancements

I do like this and it's similar to what I've done for highbank. Actually, yours is a bit more flexible. We have the additional need to select a boot source by a boot device selection register which is set via ipmi.

So how do we combine these and have some level of enforcement? There's not much concept of common/minimum environment in u-boot. The default environment is entirely optional. I worry leaving it as just environment settings does not "encourage" people to use it.

we can document a "standard" in u-boot itself that for linux distros, and encourage board porters to follow that

you're right that we can't force people to do this, but simply documenting it in u-boot and making it the suggested default goes a long way i think -mike

On Mon, Aug 13, 2012 at 11:52 AM, Stephen Warren swarren@wwwdotorg.org wrote:

On 08/08/2012 02:25 PM, Rob Herring wrote:

...

Stephen Warren <swarren@...> writes:

...

Related to this topic also are:

93d87d5 tegra: define fdt_load/fdt_high variables 4878343 tegra: bootcmd enhancements

I do like this and it's similar to what I've done for highbank. Actually, yours is a bit more flexible. We have the additional need to select a boot source by a boot device selection register which is set via ipmi.

So how do we combine these and have some level of enforcement? There's not much concept of common/minimum environment in u-boot. The default environment is entirely optional. I worry leaving it as just environment settings does not "encourage" people to use it.

Perhaps the issue isn't so much enforcement at a U-Boot level, but more that we create some standard for what boot.scr/... can expect to exist in the environment, and say:

distros: this is what you can rely upon in your boot.scr.

board vendors: this is what you need to provide in order for common Linux distros to work out-of-the-box.

Hopefully that's enough incentive for people to make their U-Boots work?

Thats all you can hope for, but its one of those hopes that is fairly realistic.

If we can nail it pretty fast we can ship Efika MX updates with the next update that make the cross-distro stuff work. We'd be so happy for it to actually get used. Too late, though, and it's not possible to update the environment to match without some hideous messing around (we plan to disable saving the environment permanently, but even if we didn't, it would require MTD access to SPI NOR, and some more U-Boot tools. If you thought shipping mkimage was bad, the env tools are worse in my mind..)

On 08/08/2012 12:30 PM, Rob Herring wrote:

David Marlin <dmarlin@...> writes:

...

Some vendors already provide U-Boot environment variables for the load addresses, and some for the load commands themselves, but I have not found much consistency between them. One example is the Genesi Efika MX (mx51), which provides:

${loadcmd} ${kerneladdr} ${ramdiskaddr}

By providing the kernel and initrd U-Boot images in a boot.scr, you can load and boot the desired kernel with no other board specific knowledge (specific addresses or devices).

Highbank provides some similar load address definitions, but with different names, i.e.,

${ramdisk_addr_r} ${kernel_addr_r} ${fdt_addr_r}

Just FYI, these are already the standard, documented variable names.

Interesting. The U-Boot README isn't very strongly worded about those being standard though:

*Note* - these variables don't have to be defined for all boards, some boards currenlty use other variables for these purposes, and some boards use these variables for other purposes.

Image File Name RAM Address Flash Location

---

u-boot u-boot u-boot_addr_r u-boot_addr Linux kernel bootfile kernel_addr_r kernel_addr device tree blob fdtfile fdt_addr_r fdt_addr ramdisk ramdiskfile ramdisk_addr_r ramdisk_addr

Perhaps we could make that wording more forceful and less "but you can do whatever you want"?

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..

Matt Sealey matt@genesi-usa.com Product Development Analyst, Genesi USA, Inc.

On Aug 8, 2012, at 3:41 PM, Brendan Conoboy blc@redhat.com wrote:

On 08/08/2012 11:30 AM, Rob Herring wrote:

...

Standardizing on boot.scr vs. raw text file for scripts would also help. Right now, ubuntu uses the former and fedora the later.

Not sure what you mean here- boot.scr vs uEnv.txt perhaps? In Fedora we use uEnv.txt where the uboot binary supports it (OMAP for instance), but otherwise boot.scr. If we were going to standardize these things I'd liek to see:

Move to uEnv.txt instead of boot.scr

Make zboot standard

Make hush shell standard

-- Brendan Conoboy / Red Hat, Inc. / blc@redhat.com

---

cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro

It might not be limited to FAT but uboot definitely has a flag for considering an environment file on an MMC fat partition - maybe there's an ext2 one too, I didn't check. But it's to solve the problem of having to store u-boot environment otherwise on raw blocks which means reserving space (pain in the backside on OMAP as MLO/X-Loader etc. are notoriously finicky). Since it knows FAT, or a restricted subset of FAT, the uEnv.txt gets put with the rest of the loader files...

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. The reason it's a text file on OMAP is because on OMAP all they have is a FAT partition and it's less intrusive to read that file of that filename out from the disk. It is not to make life for distros more convenient by negating the need to write boot scripts; especially since every other ARM, PPC, MIPS, et al architecture might actually need the boot script. Why differentiate? uEnv.txt needs to be there to load a DIFFERENT environment, but there's also one compiled into U-Boot anyway. 99% of the time they're identical. If you need to dynamically change the booted environment from the default, you can; for instance to fix some errata that makes booting not work, or write a register or modify the way the thing boots without modifying the U-Boot compile, but on OMAP.. you have access to the binary anyway, it's in the same FAT partition :)

Since uEnv.txt isn't there on all boards, nor required, you could just do away with uEnv.txt completely, and trust the one compiled into U-Boot which would be standardized anyway, and just trust the boot.scr process to do any changes you need to make. That way all the boards boot one way; U-Boot comes with a standardized environment compiled in, and boot.scr is the thing it loads to further the boot process in a distribution-specific way.

boot.scr, as above, is the part that is distribution-specific. It needs to load from a certain device, the one U-Boot found it on or was directed to boot from. In environments where there is only one boot method (for instance, a single SD card slot) bootcmd may just be a loop through several valid filesystems, culminating in some environment being set (temporarily, please never saveenv in boot.scr!) which allows boot.scr to know

a) how to load other files from that media where it can be applied to common argument list for another command b) what to load and where to load it

e.g.

setenv loadcmd "${fs}load ${device} ${unit}:${part}" ${loadcmd} ${address_to_load_to} ${filename_to_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. In the case of a dynamic memory start (MX6 does this, it can be 0x10000000 or 0x80000000) or size (with SO-DIMM for example) the script should not be playing with this value, so it makes sense not to define this in the script, but to use a standard set of environment variables to define these addresses, and importantly define these SEPERATELY from the U-Boot standard ${loadaddr} which means a very specific thing and has very specific actions - it is the DEFAULT address to load to, if you for example say "mmc dev 0; mmc part 1; fatload uImage" it will fill in the blanks for missing device, unit, partition from the currently selected entities, and use ${loadaddr} to put the file. This is NOT ALWAYS the place you want your kernel! The example is a good reason to define ${loadcmd} with specific device, unit and partition entries too since otherwise the device unit and partition is basically undefined, random and/or dependent on user fiddling before running "run bootcmd" if they paused the autoboot process.

So what you'd need are basically an address defined ${kerneladdr}, ${ramdiskaddr}, ${dtbaddr} or so which are the arguments for common bootm or bootz. These need to be set to safe places in the memory map and these should be hardcoded into U-Boot or provided in a known-to-be-safe uEnv.txt. The names aren't important, but they're the places these things are *to be loaded to* and they SHOULD be the same as the addresses *to be relocated to* in the event they do not match the configuration. In this sense, what should really happen is people quit using bootm to source uImage files, and just use zImage and raw ramdisks. 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 define a flag in the uImage format that says "do not relocate this under any circumstances". U-Boot has no idea about what it's doing to the file in regards to ANY other file you're loading into memory, nor the constraints around the addresses you want those files at, so relocation can give non-deterministic behavior, and it also involves memory copies which slow down boot. U-Boot and Distro would need to "cooperate" on their use of addresses passed to mkimage to reduce this if possible. Distro SHOULD also endeavour to not compress any uImage since in the vast majority of cases, the kernel is pre-compressed (gzip, lzo, bzip, xz, whatever) and decompresses itself. -C none should be the default in mkimage for distros. Ramdisks are almost always compressed, and the kernel will either decompress it fully (gzipped cpio archive or so) on it's own terms or do it on the fly (squashfs or so). Either way it has much better compression options than U-Boot can support (gzip, and that's it). So -C none makes no sense here anyway unless you are architecturally bound to gzip, and it would also force a kind of relocation (decompression to another location than the load address) which is therefore both redundant and somewhat non-deterministic too. Compressing boot.scr files only makes sense if your script is absolutely massive, otherwise most of them check out at about 900 bytes maximum (the biggest we've ever made was still less than a memory page) - saving yourself 30% on 4KiB isn't going to save you from any noticable disk access. At the end of the day though as long as U-Boot is safe within itself in terms of decompressing the script (i.e. if it does it (and it does currently) from top of memory and you define your addresses in the low part) "source" will run it fine and this decompression is quite safe. The Distro should determine whether compressing a boot.scr is a good idea. Device trees... also not a lot of point but it COULD happen, but where it decompresses to MUST be 16-byte (or is it 16KiB?) aligned or __vet_atags will NULL the pointer. It could also be decompressed to a place the kernel can't reach or overwrites at random (during decompression of kernel image). It's safer not to.

And that's it.. other operating systems should either write custom boot.scr scripts with custom addresses OR re-use kernel, ramdisk, dtb addr variables for it's own use (or for cleanliness, copy dtbaddr to a well-named one and use that as the third argument to bootm or bootz, assuming of course that it follows the Linux kernel entry convention) or if it is a wonderfully smart or integrated operating system, just kerneladdr or loadaddr and it can find the rest of the system on it's own or from it's filesystem or so (Solaris used to do this, Windows does this, MacOS does this).

The one thing I have never been able to resolve writing bootloaders is what the memory map should be. Usually what I end up with is, a place to put the boot script (lets call this scriptaddr), a place for device tree, place for kernel, place for ramdisk - in that order, in the low memory map. We usually need to keep 0x100 upwards to a reasonable amount of memory for legacy ATAGs for the board. So the first address (where the boot script is loaded to) is usually 32KiB into the memory map. We add 32KiB and put the dtb there. We add 64KiB (can a device tree really get that big?) and then the kernel goes there. Add 16MiB and put the ramdisk there. The ramdisk is a pretty arbitrarily sized thing, putting it before the kernel means you end up with "I cant' load ramdisks bigger than n MiB" problems which we've experienced before. It would be unheard of for a COMPRESSED Linux kernel to be more than 16MiB though. I find it hard to believe you could have one uncompressed amassing that amount of code, either (with all the modules and the kernel image I think my linux-virtual image on VMWare is about 32MiB added together, though. That's with EVERY module Ubuntu tries to do, and would assume they are linked into the kernel to be bigger than 16MiB. Unless Ubuntu want to do static, super-monolithic kernels, it will never happen IMO...). Your ramdisk is then just bounded by the limits of the kernel, if I'm putting my kernel at 64KiB and have 16MiB space for it, and my ramdisk loads there.. automatic zrel address location requires the kernel entry point to be less than 128MiB into the memory map but I think this is before decompression (right?) so it's just got to not overwrite the U-Boot stack (probably around 16MiB at the top of memory including all the binaries, segments, malloc space and stack). If it's done after decompression my ramdisk is limited to 128MiB-16MiB-64KiB-SizeOfDecompressedKernel so it can actually be inside that 128MiB. I'll have to look into that again... but who's going to make a 100MiB ramdisk anyway, boot from SD card and NOT use the SD card filesystem? It seems to rare to care about.

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?

I think what you're really talking about here is a way for U-Boot to load a boot.scr file that isn't encoded inside a uImage header, all it needs to know at this point though is the length of the file so that "source" knows where it can stop parsing (otherwise it will run the risk of not having a null terminator and it running into otherwise unprotected but unwise to access memory).

Like I said, the way we do it on the Efika MX is that the U-Boot environment (old U-Boot, stored in NOR; new U-Boot, built-in to U-Boot and not changeable) defines the bootcmd string and that's it. That's all U-Boot knows as standard apart from loadaddr. There is no bootmmc, booteth, bootsata, or other env to "run," and it does not really need them. If you start coding those you have to take into account the configurability, for instance bootmmc would need variables in the environment to know which device and partition to use, the filename, the load addresses for each component shouldn't be hardcoded into the bootmmc variable. What could be quite simple standardizing the environment for these variables implies and infers more environment variables, some unique to some systems and some common, but definitely not ALL common and standardizable.

As I understand this, the discussion is just talking about how to make life easier on Linux distributions so they don't have to know about non-standard U-Boot messes, but this just isn't possible. flash-kernel on Debian worked fine and could be JUST more modular but, no offense Loic, making it data driven is what is driving this discussion as a whole. What should have been less work is now a cross-distro discussion of why it doesn't really meet real life. What would make flash-kernel cleaner is if everyone updated their U-Boot.. which is unlikely. If Linaro have their U-Boot work then they can engineer them all to boot the same way. We already did this at Genesi, we took a hint from the Marvell Dove code that was embedded into flash-kernel and embedded it into our U-Boot so that we didn't have to restrict everyone to putting boot.scr on a single device (since U-Boot is capable of scripting looking for it). So Marvell Dove can do it too, if it worked from boot.scr it will work from bootcmd. OMAP, the same way. MX6Q SabreLite, we were disappointed that it went halfway and then bailed and then called the script "6q_bootscript". We fixed that internally here, now it boots from microSD, SD, SATA in that order without changing any "boot option registers" or flashing anything to SPI NOR (although we will have to eventually, the way the i.MX series works means all we need is a USB cable to load our own U-Boot from any old system with a USB port. Thanks Troy, Eric for imx_usb_loader so we don't need Windows anymore :)

What we should do is not pick around talking but collect all the relevant environments and boot.scr implementations and find the common points. But I guarantee they all have at least one boot source soldered to the board that is user-accessible (SD card, SATA drive, USB port), where they have two it will be easy to dynamically search for the right file in the right place, and if we fixate on the Linaro SD card format (partition 1 == for U-Boot on OMAP or other devices, partition 2 == /boot, partition 3 == /) and copy this for every expected-to-be-bootable-device for the distro, that's the kind of standardization we can achieve. The distro just needs the above, and the ability to write a boot.scr, and we might want to fix U-Boot-Linaro to be able to load a plaintext boot script instead of encoding it with mkimage, and to ignore relocation with uImages anyway at certain flags or impossible values (0xffffffff for example, since this would nearly always be the top of the memory map if not far beyond the end of RAM, except on 64-bit, but we'll get to that later), right?

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.

On 08/08/2012 12:30 PM, Rob Herring wrote: ...

Making u-boot more intelligent discovering things also helps here. For example, booting from the disk partition with the bootable flag set. I've submitted patches for this a while back.

That sounds like these:

http://www.mail-archive.com/u-boot@lists.denx.de/msg79100.html

Is it likely these will make it into U-Boot? Nobody seems to have replied to your patches.

I just recently proposed a "partuuid" command to extract a partition's UUID, but I've since re-written it to be a "part" command with a "uuid" sub-command. Adding a "get-bootable" sub-command to retrieve the flag your patch sets would be a good idea. Should I pull your patches into my series to do this?

Your series only implements bootable flag retrieval for MSDOS/MBR partitions. I wonder what flag one should key off for EFI/GPT partition tables? Looking at parted/gparted, the following options exist:

A parted flag called "boot", which sets the partition's type UUID. This appears to have been supported since before parted was in git (i.e. 2006 some time).

A parted flag called "legacy_boot", which actually sets a single bit in the partition attributes. This feature is available in parted v2.4 and later, which isn't even in Ubuntu Quantal yet, although it was released a while ago. This seems to be the more correct option, although not very available to users.

Perhaps either case should trigger U-Boot to consider the partition bootable?

On 08/21/2012 10:58 PM, Stephen Warren wrote:

On 08/08/2012 12:30 PM, Rob Herring wrote: ...

...

Making u-boot more intelligent discovering things also helps here. For example, booting from the disk partition with the bootable flag set. I've submitted patches for this a while back.

That sounds like these:

http://www.mail-archive.com/u-boot@lists.denx.de/msg79100.html

Is it likely these will make it into U-Boot? Nobody seems to have replied to your patches.

Not likely, they've bit-rotted and there's at least one issue I've fixed. I need to repost the series, but the overwhelming response on the first posting doesn't motivate me.

I just recently proposed a "partuuid" command to extract a partition's UUID, but I've since re-written it to be a "part" command with a "uuid" sub-command. Adding a "get-bootable" sub-command to retrieve the flag your patch sets would be a good idea. Should I pull your patches into my series to do this?

Your series only implements bootable flag retrieval for MSDOS/MBR partitions. I wonder what flag one should key off for EFI/GPT partition tables? Looking at parted/gparted, the following options exist:

A parted flag called "boot", which sets the partition's type UUID. This appears to have been supported since before parted was in git (i.e. 2006 some time).

A parted flag called "legacy_boot", which actually sets a single bit in the partition attributes. This feature is available in parted v2.4 and later, which isn't even in Ubuntu Quantal yet, although it was released a while ago. This seems to be the more correct option, although not very available to users.

Perhaps either case should trigger U-Boot to consider the partition bootable?

I only briefly looked at EFI partitioning. My conclusion was some EFI variable gets set to point to the boot loader, but if there's bootable flags that's better for u-boot. I haven't worried about it because I can't even get debian installer to use EFI partitions. It's partitioning config basically says if the arch is arm, use DOS partitions.

Rob

On 08/22/2012 04:40 PM, Steve McIntyre wrote:

On Wed, Aug 22, 2012 at 02:11:56PM -0500, Rob Herring wrote:

...

I only briefly looked at EFI partitioning. My conclusion was some EFI variable gets set to point to the boot loader, but if there's bootable flags that's better for u-boot. I haven't worried about it because I can't even get debian installer to use EFI partitions. It's partitioning config basically says if the arch is arm, use DOS partitions.

It does for now, yes. It's reasonably easy to tweak and rebuild - I've just been doing that for amd64/efi in the last couple of weeks. If you'd like some help with it, please shout! :-)

Not to wander too far off-topic, but:

I found that simply grabbing an ubuntu-core pre-installed filesystem tar file, untar'ing that onto an SD card (or other built-in storage), and then apt-get'ing the rest of the required packages works quite well; no need for these fancy installer things:-) A few small tweaks are required (like ubuntu-core doesn't include enough packages to set up networking) but they're fairly easy to overcome; see:

http://www.omappedia.com/wiki/OMAP_Ubuntu_Core#Chroot.27ing_into_the_Ubuntu_...

(thanks to Ogra on #ac100 IRC for the link)

On 08/22/2012 01:11 PM, Rob Herring wrote:

On 08/21/2012 10:58 PM, Stephen Warren wrote:

...

On 08/08/2012 12:30 PM, Rob Herring wrote: ...

...

Making u-boot more intelligent discovering things also helps here. For example, booting from the disk partition with the bootable flag set. I've submitted patches for this a while back.

That sounds like these:

http://www.mail-archive.com/u-boot@lists.denx.de/msg79100.html

Is it likely these will make it into U-Boot? Nobody seems to have replied to your patches.

Not likely, they've bit-rotted and there's at least one issue I've fixed. I need to repost the series, but the overwhelming response on the first posting doesn't motivate me.

Do you want me to pick them up (i.e. do the rebase, etc.)?

...

I just recently proposed a "partuuid" command to extract a partition's UUID, but I've since re-written it to be a "part" command with a "uuid" sub-command. Adding a "get-bootable" sub-command to retrieve the flag your patch sets would be a good idea. Should I pull your patches into my series to do this?

Your series only implements bootable flag retrieval for MSDOS/MBR partitions. I wonder what flag one should key off for EFI/GPT partition tables? Looking at parted/gparted, the following options exist:

A parted flag called "boot", which sets the partition's type UUID. This appears to have been supported since before parted was in git (i.e. 2006 some time).

A parted flag called "legacy_boot", which actually sets a single bit in the partition attributes. This feature is available in parted v2.4 and later, which isn't even in Ubuntu Quantal yet, although it was released a while ago. This seems to be the more correct option, although not very available to users.

Perhaps either case should trigger U-Boot to consider the partition bootable?

I only briefly looked at EFI partitioning. My conclusion was some EFI variable gets set to point to the boot loader, but if there's bootable flags that's better for u-boot. I haven't worried about it because I can't even get debian installer to use EFI partitions. It's partitioning config basically says if the arch is arm, use DOS partitions.

I'm more talking about pure EFI/GPT partitions on a disk here, rather than a full EFI environment. In other words, U-Boot is the entirety of the firmware, and it's reading the partition table directly.

On Aug 24, 2012, at 10:01 AM, Rob Herring robherring2@gmail.com wrote:

On 08/22/2012 06:12 PM, Stephen Warren wrote:

...

On 08/22/2012 01:11 PM, Rob Herring wrote:

...

On 08/21/2012 10:58 PM, Stephen Warren wrote:

...

On 08/08/2012 12:30 PM, Rob Herring wrote: ...

...

Making u-boot more intelligent discovering things also helps here. For example, booting from the disk partition with the bootable flag set. I've submitted patches for this a while back.

That sounds like these:

http://www.mail-archive.com/u-boot@lists.denx.de/msg79100.html

Is it likely these will make it into U-Boot? Nobody seems to have replied to your patches.

Not likely, they've bit-rotted and there's at least one issue I've fixed. I need to repost the series, but the overwhelming response on the first posting doesn't motivate me.

Do you want me to pick them up (i.e. do the rebase, etc.)?

...

...

I just recently proposed a "partuuid" command to extract a partition's UUID, but I've since re-written it to be a "part" command with a "uuid" sub-command. Adding a "get-bootable" sub-command to retrieve the flag your patch sets would be a good idea. Should I pull your patches into my series to do this?

Your series only implements bootable flag retrieval for MSDOS/MBR partitions. I wonder what flag one should key off for EFI/GPT partition tables? Looking at parted/gparted, the following options exist:

A parted flag called "boot", which sets the partition's type UUID. This appears to have been supported since before parted was in git (i.e. 2006 some time).

A parted flag called "legacy_boot", which actually sets a single bit in the partition attributes. This feature is available in parted v2.4 and later, which isn't even in Ubuntu Quantal yet, although it was released a while ago. This seems to be the more correct option, although not very available to users.

Perhaps either case should trigger U-Boot to consider the partition bootable?

I only briefly looked at EFI partitioning. My conclusion was some EFI variable gets set to point to the boot loader, but if there's bootable flags that's better for u-boot. I haven't worried about it because I can't even get debian installer to use EFI partitions. It's partitioning config basically says if the arch is arm, use DOS partitions.

I'm more talking about pure EFI/GPT partitions on a disk here, rather than a full EFI environment. In other words, U-Boot is the entirety of the firmware, and it's reading the partition table directly.

Right. But I'm just wondering how typical the boot or legacy boot flags are. If those are not used in a "standard" boot process, then it's probably not worth getting u-boot to use them

It would be nice to be able to have U-Boot tell what the bootable partition is (saves searching for boot.scr on multiple partitions and drives) but for legacy that search will have to happen anyway.

I don't think the process of going over 3 or 4 partitions per drive looking for a file takes all that long; here it's not noticeable on Efika or Beagle.

I've also got a tiny problem with defaulting to EFI partitioning; i.MX booting from SD card or SATA requires the boot loader at 1024 bytes and that won't be possible since EFI needs at least 17KiB (with 512 byte blocks) for the partition table. It doesn't affect Efika but it would affect most of the MX53/MX6 boards if set to boot from SD with a Linaro-provided U-Boot.

On Fri, Aug 24, 2012 at 11:13 AM, Rob Herring robherring2@gmail.com wrote:

Unfortunately, my crazy idea to follow/honor industry standard drive booting/partitioning in the iMX bootrom fell on deaf ears. At least they skipped over the MBR.

Indeed, I must have submitted this change request to various places about 10 times since MX51.

It really impedes low-cost design of things like ChromeBooks (which need EFI partitions) without adding in some kind of internal boot ROM to get the system running. If you can save even $1.50 for SPI NOR on every board by simply making the offset 32KiB, and not having to solder fixed-size NAND to the board for motherboard production, it's worth it. Maybe for MX7 *fingers crossed*.

Problem is this is a vicious circle - if nobody makes a system that requires EFI partitions they won't think it's worth it, and if the SoC can't support EFI partitions, nobody will make them.