Extending U-Boot image format Open issues and Questions
-------------------------------------------------------

- Extensions to DTC syntax may be needed to make DTC accept path
  to 'component' data instead of direct 'component' hexdump inside .dts
  
- Would multiple images of a given type be commonly used, e.g. few kernel
  type 'components' inside one 'container' image?

  If so, then some kind of a "OS configuration" support may be desired.
  Let's assume the following 'container' image structure:

	----------------------------------------
	type = kernel, label = vanilla-2.6.24
	type = ramdisk, label = default-ramdisk
	type = dts, label = dts-some-devices
	type = kernel, label = denx-2.6.24
	type = ramdisk, label = ramdisk-eldk-4.2
	type = dts, label = dts-more-devices
	----------------------------------------

  then "OS configuration" would be a (kernel, ramdisk, dts) triple with a
  label assigned. For the above 'container' we may have two 'os
  configurations':

	'vanilla' = ('vanilla-2.6.24', 'default-ramdisk', 'dts-some-devices')
	'denx' = ('denx-2.6.24', 'ramdisk-eldk-4.2', 'dts-more-devices')

  Such configuration labels might be useful in places like bootm command,
  and would allow to introduce some order into the set of
  images/ramdisks/dts files.

  Implementation for such feature might be a additional type of a FDT
  binding with the support for the following properties:

	- 'os configuration' label property
	- kernel type 'component' label (selecting one of the kernel images)
	- ramdisk type 'component' label
	- dts type 'component' label

  Would such kind of a feature be useful and desired?