diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/bootstd/overview.rst | 21 | ||||
| -rw-r--r-- | doc/develop/driver-model/design.rst | 17 |
2 files changed, 37 insertions, 1 deletions
diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index a2913cd47be..e3ce97cc4f5 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -453,7 +453,7 @@ drivers are bound automatically. Command interface ----------------- -Three commands are available: +Four commands are available: `bootdev` Allows listing of available bootdevs, selecting a particular one and @@ -468,6 +468,25 @@ Three commands are available: Allow listing of available bootmethds, setting the order in which they are tried and bootmeth specific configuration. See :doc:`/usage/cmd/bootmeth` +`bootstd` + Allow access to standard boot itself, so far only for listing images across + all bootflows. See :doc:`/usage/cmd/bootstd` + +Images +------ + +Standard boot keeps track of images which can or have been loaded. These are +kept in a list attached to each bootflow. They can be listed using the +``bootstd images`` command (see :doc:`/usage/cmd/bootstd`). + +For now most bootmeths load their images when scanning. Over time, some may +adjust to load them only when needed, but in this case the images will still +be visible. + +Once a bootflow has been selected, images for those that are not selected can +potentially be dropped from the memory map. For now, this is not implemented. + + .. _BootflowStates: Bootflow states diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst index 8c2c81d7ac9..92f638a0204 100644 --- a/doc/develop/driver-model/design.rst +++ b/doc/develop/driver-model/design.rst @@ -842,6 +842,23 @@ steps (see device_probe()): cause the uclass to do some housekeeping to record the device as activated and 'known' by the uclass. +For some platforms, certain devices must be probed to get the platform into +a working state. To help with this, drivers marked with DM_FLAG_PROBE_AFTER_BIND +will be probed immediately after all devices are bound. For now, this happens in +SPL, before relocation and after relocation. See the call to ``dm_autoprobe()`` +for where this is done. + +The auto-probe feature is tricky because it bypasses the normal ordering of +probing. General, if device A (e.g. video) needs device B (e.g. clock), then +A's probe() method uses ``clk_get_by_index()`` and B is probed before A. But +A is only probed when it is used. Therefore care should be taken when using +auto-probe, limiting it to devices which truly are essential, such as power +domains or critical clocks. + +See here for more discussion of this feature: + +:Link: https://patchwork.ozlabs.org/project/uboot/patch/20240626235717.272219-1-marex@denx.de/ + Running stage ^^^^^^^^^^^^^ |