mirror of
https://github.com/brain-hackers/u-boot-brain
synced 2024-06-09 23:36:03 +09:00
4afc4f37c7
** Introduction There are currently four ways to load an OS image with u-boot 1. SPL -> u-boot -> bootm 2. SPL blue falcon mode 3. "Basic" FIT image (CONFIG_LOAD_FIT) 4. "Full-featured" FIT image (CONFIG_LOAD_FIT_FULL) These four code paths were developed independently, and share very little code. (3) and (4), behave very differently, are littered with special cases. They even have different DTS syntax and properties. The cause of this divergence is that the FIT format specification leaves a number of things open to interpretation. The purpose of this change is to enable the reduction of code size, duplication, and complexity by updating and streamlining the FIT format. We are only marginally concerned with backwards compatibility, because we don't have inter-compatibility. For example, CONFIG_LOAD_FIT is able to load images that CONFIG_LOAD_FIT_FULL won't. This is a direct result of the incompatible syntax between the two implementations. Ideally, these changes would enable "simple" FIT to be a subset of the "full" fit implementation, and share most code. These changes should also eliminate the need for falcon mode (although we are not advocating for the removal of falcon mode at this time). ** Description of changes * The "configurations" node is now mandatory Guessing how to load components based on their "os" and "type" invites confusion and superfluous heuristics. Instead, require each FIT image to be explicit on how components should be loaded. * Eliminate "ramdisk", "setup", "standalone", and "fpga" properties Having too many special purpose properties requires special-casing FIT loading code. When a special property can be handled by another property, it is redundant. - A "ramdisk" is identical to a loadable. Thus ramdisk images should be placed under "loadables". - A "setup" node can be achieved by using a "kernel" or "firmware" property instead. - "standalone" is used for u-boot nodes. The correct property to use in this case is "firmware". - "fpga" is a loadable * Prioritize control between "firmware" and "kernel" "firmware" and "kernel" are special nodes in that control is passed to the "entry-point" of the image. Both can be present, for example, an OP-TEE firmware with a linux kernel. When both are present, control is passed to the "firmware" image. ** Further generalizations (not included herein) The "firmware" and "kernel" properties could be generalized as a "next-boot-stage", or similar name. This "next" stage would be special in that it is both executable, and is the stage that is passed control. For example, "next-stage" could be an op-tee image, with linux as a loadable, or a u-boot image. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> |
||
|---|---|---|
| .. | ||
| beaglebone_vboot.txt | ||
| command_syntax_extensions.txt | ||
| howto.txt | ||
| kernel_fdt.its | ||
| kernel_fdts_compressed.its | ||
| kernel.its | ||
| multi_spl.its | ||
| multi-with-fpga.its | ||
| multi-with-loadables.its | ||
| multi.its | ||
| overlay-fdt-boot.txt | ||
| sec_firmware_ppa.its | ||
| sign-configs.its | ||
| sign-images.its | ||
| signature.txt | ||
| source_file_format.txt | ||
| uefi.its | ||
| update_uboot.its | ||
| update3.its | ||
| verified-boot.txt | ||
| x86-fit-boot.txt | ||