Hi Jonas,
On Thu, 17 Aug 2023 at 00:25, Jonas Karlman jonas@kwiboo.se wrote:
Hi Simon,
On 2023-08-17 00:29, Simon Glass wrote:
Hi Jonas,
On Tue, 8 Aug 2023 at 20:03, Simon Glass sjg@chromium.org wrote:
Hi Jonas,
On Sat, 5 Aug 2023 at 07:32, Jonas Karlman jonas@kwiboo.se wrote:
Devices for nodes with e.g. bootph-pre-ram are initialized three times.
- At SPL stage (always bind and probe only if used)
- At U-Boot proper pre-reloc (always bind and probe)
- At U-Boot proper normal (always bind and probe only if used)
Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop with a pre-reloc status only after U-Boot proper pre-relocation stage. This prevents the device from being probed at U-Boot proper pre-reloc.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
I am not sure if U-Boot proper pre-reloc behaves like this by design and if there is some other way to signal that a device should not be probed during U-Boot proper pre-reloc stage if it has been probed at SPL stage.
For my use-case I added bootph-pre-ram prop to my RK8xx device node to make the PMIC usable in SPL. However, I have no need for this device to probe at U-Boot proper pre-reloc stage just after jumping out of TF-A. And moments later bind and probe yet again at U-Boot proper normal stage.
The bootph-pre-ram prop was used to have the device usable in SPL, else I could have used bootph-all or added bootph-some-ram prop to indicate use at U-Boot proper pre-reloc stage.
This is changing how things work...we really need to have something explicit to use this new behaviour. Perhaps we can augment the binding in some way?
I had another look at this. The binding seems to be silent on this point, so I believe this patch is correct.
I agree, the documentation for binding and also for driver model make this a little bit unclear:
""" ... Only drivers marked with DM_FLAG_PRE_RELOC or the device tree ‘bootph-all’ property are initialised prior to relocation. ...
...
It is possible to limit this to specific relocation steps, by using the more specialized ‘bootph-pre-ram’ and ‘bootph-pre-sram’ flags in the device tree node. For U-Boot proper you can use ‘bootph-some-ram’ which means that it will be processed (and a driver bound) in U-Boot proper prior to relocation, but will not be available in SPL or TPL. """
However the documentation for ofnode_pre_reloc contradict this a little:
""" There are 4 settings currently in use
- bootph-some-ram: U-Boot proper pre-relocation only
- bootph-all: all phases
Existing platforms only use it to indicate nodes needed in SPL. Should probably be replaced by bootph-pre-ram for new platforms.
- bootph-pre-ram: SPL and U-Boot pre-relocation
- bootph-pre-sram: TPL and U-Boot pre-relocation
"""
Should I send a v2 of this and drop the "and U-Boot pre-relocation" from function doc comment? And do we need a new Kconfig option to enable or opt-out of this new/changed/fixed behavior?
Yes it needs doc updates but I don't think a new Kconfig option is warranted at this point. We just need to clearly document how these options are used.
Regards, SImon