Add explicit support for multi-step loading #28
Conversation
✅ Deploy Preview for fluffy-chebakia-3fa329 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| .. _load_only: | ||
|
|
||
| load-only | ||
| Indicates that this configuration does not contain an executable image, |
There was a problem hiding this comment.
If a configuration marked by the 'load-only', is meant to neither contain a kernel nor a firmware property than this label would be superfluous. It would be sufficient to create a configuration without neither of these properties.
There was a problem hiding this comment.
Yes, but how can we tell if this is correct or not? We need some signal that it is intentional, otherwise a bad FIT will be loaded and the device will just sit at the prompt doing nothing.
| load-only | ||
| Indicates that this configuration does not contain an executable image, | ||
| i.e. kernel or firmware. The configuration may be loaded into memory for | ||
| use by the executable image, which comes from another configuration or FIT. |
There was a problem hiding this comment.
Configurations are never loaded. The images specified by a configuration are loaded.
| kernel or firmware | ||
| Unit name of the corresponding :index:`kernel` or :index:`firmware` | ||
| (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified, | ||
| control is passed to the firmware image. | ||
| control is passed to the firmware image. For `load_only`_ images, these two | ||
| properties are optional. |
There was a problem hiding this comment.
This contradicts the description of load_only below which states that load-only must not contain an executable image.
There was a problem hiding this comment.
Yes, I fixed that statement above
| kernel or firmware), nor should it try to boot with this configuration. Booting | ||
| then becomes a two-step process: load one FIT to obtain the devicetree, then | ||
| another to obtain the OS. Only the second FIT is booted. | ||
|
|
There was a problem hiding this comment.
Obviously if a configuration does not contain anything executable it can not be executed. The new property load_only is not needed to describe a device-tree only FIT image configuration. What is the use case for the property?
How would the discovery of the multiple FIT images work? Will there be an extra configuration file in the firmware specifying locations of FIT images and the configurations to be used? Where would the format of such a file be defined?
There was a problem hiding this comment.
For the first point, it must be determinisitic, so we know whether the boot can proceed or not, as noted above.
For the second point, I haven't figured that out yet. Within U-Boot it will need to be part of the bootmeth, perhaps with a separate file, etc.
There are cases where multiple FITs must be loaded to complete a boot, e.g. where the first FIT contains devicetrees and the second contains the OS. At present this is not permitted, since every FIT must contain a bootable kernel (or firmware). Add a new 'load-only' property to indicate that a configuration can be loaded but not booted. Describe how this works in the 'usage' section. Signed-off-by: Simon Glass <[email protected]>
There are cases where multiple FITs must be loaded to complete a boot, e.g. where the first FIT contains devicetrees and the second contains the OS.
At present this is not permitted, since every FIT must contain a bootable kernel (or firmware).
Add a new 'load-only' property to indicate that a configuration can be loaded but not booted. Describe how this works in the 'usage' section.