u-boot.git/include/dm, branch v2022.07 Unnamed repository; edit this file 'description' to name the repository. dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag 2022-04-28T13:26:43+00:00 Marek Vasut marex@denx.de 2022-04-22T13:15:53+00:00 9cc32bfa49d23a4d1bed9e6119255f2e78e20232 Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or uclass in .bind(), to indicate such driver instance should be probe()d once binding of all devices is complete. This is useful in case the driver determines that hardware initialization is mandatory on boot, and such initialization happens only in probe(). This also solves the inability to call device_probe() from .bind(). Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> 
Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
uclass in .bind(), to indicate such driver instance should be probe()d
once binding of all devices is complete.

This is useful in case the driver determines that hardware initialization
is mandatory on boot, and such initialization happens only in probe().
This also solves the inability to call device_probe() from .bind().

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Steven Lawrance <steven.lawrance@softathome.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Merge branch '2022-04-25-initial-implementation-of-stdboot' 2022-04-25T20:02:27+00:00 Tom Rini trini@konsulko.com 2022-04-25T20:02:27+00:00 8cfac237b9814d52c843e939a05fc211ba3906de To quote the author: The bootflow feature provide a built-in way for U-Boot to automatically boot an Operating System without custom scripting and other customisation. This is called 'standard boot' since it provides a standard way for U-Boot to boot a distro, without scripting. It introduces the following concepts: - bootdev - a device which can hold a distro - bootmeth - a method to scan a bootdev to find bootflows (owned by U-Boot) - bootflow - a description of how to boot (owned by the distro) This series provides an implementation of these, enabled to scan for bootflows from MMC, USB and Ethernet. It supports the existing distro boot as well as the EFI loader flow (bootefi/bootmgr). It works similiarly to the existing script-based approach, but is native to U-Boot. With this we can boot on a Raspberry Pi 3 with just one command: bootflow scan -lb which means to scan, listing (-l) each bootflow and trying to boot each one (-b). The final patch shows this. With a standard way to identify boot devices, booting become easier. It also should be possible to support U-Boot scripts, for backwards compatibility only. ... The design is described in these two documents: https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing 
To quote the author:
The bootflow feature provide a built-in way for U-Boot to automatically
boot an Operating System without custom scripting and other customisation.
This is called 'standard boot' since it provides a standard way for
U-Boot to boot a distro, without scripting.

It introduces the following concepts:

   - bootdev - a device which can hold a distro
   - bootmeth - a method to scan a bootdev to find bootflows (owned by
                U-Boot)
   - bootflow - a description of how to boot (owned by the distro)

This series provides an implementation of these, enabled to scan for
bootflows from MMC, USB and Ethernet. It supports the existing distro
boot as well as the EFI loader flow (bootefi/bootmgr). It works
similiarly to the existing script-based approach, but is native to
U-Boot.

With this we can boot on a Raspberry Pi 3 with just one command:

   bootflow scan -lb

which means to scan, listing (-l) each bootflow and trying to boot each
one (-b). The final patch shows this.

With a standard way to identify boot devices, booting become easier. It
also should be possible to support U-Boot scripts, for backwards
compatibility only.

...

The design is described in these two documents:

https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing

https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing
bootstd: Add the bootmeth uclass and helpers 2022-04-25T14:00:04+00:00 Simon Glass sjg@chromium.org 2022-04-25T05:31:08+00:00 a950d31abe980ba40a0a94fbf41136550187f8cd A bootmeth is a method of locating an operating system. For now, just add the uclass itself. Drivers for particular bootmeths are added later. If no bootmeths devices are included in the devicetree, create them automatically. This avoids the need for boilerplate in the devicetree files. Signed-off-by: Simon Glass <sjg@chromium.org> 
A bootmeth is a method of locating an operating system. For now, just
add the uclass itself. Drivers for particular bootmeths are added later.

If no bootmeths devices are included in the devicetree, create them
automatically. This avoids the need for boilerplate in the devicetree
files.

Signed-off-by: Simon Glass <sjg@chromium.org>
bootstd: Add the bootdev uclass 2022-04-25T14:00:04+00:00 Simon Glass sjg@chromium.org 2022-04-25T05:31:07+00:00 201417d700a2ab09f247c1be9952176970c0f6bd A 'bootdev' is a device which can be used to boot an operating system. It is a child of the media device (e.g. MMC) which handles reading files from that device, such as a bootflow file. Add a uclass for bootdev and the various helpers needed to make it work. Also add a binding file, empty for now. Signed-off-by: Simon Glass <sjg@chromium.org> 
A 'bootdev' is a device which can be used to boot an operating system.
It is a child of the media device (e.g. MMC) which handles reading files
from that device, such as a bootflow file.

Add a uclass for bootdev and the various helpers needed to make it
work. Also add a binding file, empty for now.

Signed-off-by: Simon Glass <sjg@chromium.org>
bootstd: Add the bootstd uclass and core implementation 2022-04-25T14:00:04+00:00 Simon Glass sjg@chromium.org 2022-04-25T05:31:06+00:00 ef5e3891f57e6fc863fabbc94b1d7da79d1940bb The 'bootstd' device provides the central information about U-Boot standard boot. Add a uclass for bootstd and the various helpers needed to make it work. Also add a binding file. Signed-off-by: Simon Glass <sjg@chromium.org> 
The 'bootstd' device provides the central information about U-Boot
standard boot.

Add a uclass for bootstd and the various helpers needed to make it
work. Also add a binding file.

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: core: Allow finding a uclass device by partial name 2022-04-25T14:00:03+00:00 Simon Glass sjg@chromium.org 2022-04-25T05:31:00+00:00 4e0710a2d007032c8a82ef3af45a0e6e9176a2a7 In some cases two devices are related and the only way to tell is to check that the names partially patch. Add a way to check this without needing to create a new string for the comparison. Fix the comment for device_find_child_by_namelen() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> 
In some cases two devices are related and the only way to tell is to
check that the names partially patch. Add a way to check this without
needing to create a new string for the comparison.

Fix the comment for device_find_child_by_namelen() while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: core: Rename and fix uclass_get_by_name_len() 2022-04-25T14:00:03+00:00 Simon Glass sjg@chromium.org 2022-04-25T05:30:59+00:00 6aa4fe39122a85ce1ef559139518fa5042406186 It seems that namelen is more common in U-Boot. Rename this function to fit in better. Also fix a bug where it breaks the operation of uclass_get_by_name() and add a test. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reported-by: Tim Harvey <tharvey@gateworks.com> 
It seems that namelen is more common in U-Boot. Rename this function to
fit in better. Also fix a bug where it breaks the operation of
uclass_get_by_name() and add a test.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reported-by: Tim Harvey <tharvey@gateworks.com>
dm: disk: add UCLASS_PARTITION 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:09+00:00 43855fdb2c99eae0cdc9b3c54c2d719262d3b3eb NOTE: probably we have to update config dependencies, in particular, SPL/TPL_PRINTF? With this new function, UCLASS_PARTITION devices will be created as child nodes of UCLASS_BLK device. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
NOTE: probably we have to update config dependencies,
in particular, SPL/TPL_PRINTF?

With this new function, UCLASS_PARTITION devices will be created as
child nodes of UCLASS_BLK device.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
dm: core: Deal with a wrinkle with linker lists 2022-04-18T21:53:56+00:00 Simon Glass sjg@chromium.org 2022-03-27T20:26:20+00:00 cdd73e7215b838095984f02554fc1bc4186124af When every member of a linker list is aligned by the compiler, we can no longer rely on the sizeof of the struct to determine the number of entries. For example, if the struct size is 0x90 but every entry is aligned to 0xa0 by the compiler, the linker list entries takes more space in memory and the calculation of the number of entries is incorrect. For example, we may see 0x12 entries when there are only 0x11. This is a real problem. There may be a general solution, although I cannot currently think of one. So far it only bites with OF_PLATDATA_RT which creates a pointer to each entry of the 'struct udevice' linker_list. This does not happen without that option, so it only affects SPL. Work around it by manually calculating the aligned size of struct udevice, then using that for the n_ent calculation. Note: the alignment fix to linker list was here: 0b2fa98aa5e linker_lists: Fix alignment issue Signed-off-by: Simon Glass <sjg@chromium.org> 
When every member of a linker list is aligned by the compiler, we can no
longer rely on the sizeof of the struct to determine the number of
entries.

For example, if the struct size is 0x90 but every entry is aligned to 0xa0
by the compiler, the linker list entries takes more space in memory and
the calculation of the number of entries is incorrect. For example, we may
see 0x12 entries when there are only 0x11.

This is a real problem. There may be a general solution, although I cannot
currently think of one. So far it only bites with OF_PLATDATA_RT which
creates a pointer to each entry of the 'struct udevice' linker_list. This
does not happen without that option, so it only affects SPL.

Work around it by manually calculating the aligned size of struct udevice,
then using that for the n_ent calculation.

Note: the alignment fix to linker list was here:

   0b2fa98aa5e linker_lists: Fix alignment issue

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: core: Allow devres to be disabled in SPL 2022-04-18T21:53:56+00:00 Simon Glass sjg@chromium.org 2022-03-27T20:26:19+00:00 092d5c2a83b730844aeaa5ac300ddc7f13a75f49 At present if devres is enabled in U-Boot proper it is enabled in SPL. We don't normally want it there, so disable it. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Angus Ainslie <angus@akkea.ca> 
At present if devres is enabled in U-Boot proper it is enabled in SPL.
We don't normally want it there, so disable it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Angus Ainslie <angus@akkea.ca>