Hello Ard,
the commit can be disregarded, as the change was already introduced by Leif since we forked (50e8d39 - ArmPlatformPkg/IntelBds: call BdsLibConnectAll()).
Anyway, I'll explain a bit more so as to address your concerns. In our case, the need to call BdsLibConnectAll() emerged with introduction of I2C and EEPROM drivers. MvI2cDxe implements EFI_I2C_BUS_CONFIGURATION_MANAGEMENT_PROTOCOL, EFI_I2C_MASTER_PROTOCOL and EFI_I2C_ENUMERATE_PROTOCOL, which are required by generic I2C stack. These protocols are installed on a new handle, which should be recognized in I2cHostDriverSupported() call. On bad, without BdsLibConnectAll() this function is not called for newly created handle, hence I2C stack attachment doesn't proceed.
I found no other way to handle that. Please let me know if you know better solution.
Best regards, Bartosz
2016-04-18 9:00 GMT+02:00 Ard Biesheuvel ard.biesheuvel@linaro.org:
On 18 April 2016 at 01:34, Marcin Wojtas mw@semihalf.com wrote:
From: Bartosz Szczepanek bsz@semihalf.com
BdsLibConnectAll() call repeats process of driver-controller connecting after drivers' initialisation. It is required to attach I2cDxe properly (after EFI_I2C_ENUMERATION_PROTOCOL is provided).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bartosz Szczepanek bsz@semihalf.com Signed-off-by: Marcin Wojtas mw@semihalf.com
Platforms/Marvell/Armada/Library/Armada7040BdsLib/Armada7040BdsLib.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/Platforms/Marvell/Armada/Library/Armada7040BdsLib/Armada7040BdsLib.c b/Platforms/Marvell/Armada/Library/Armada7040BdsLib/Armada7040BdsLib.c index 04a5bab..01f7ebd 100644 --- a/Platforms/Marvell/Armada/Library/Armada7040BdsLib/Armada7040BdsLib.c +++ b/Platforms/Marvell/Armada/Library/Armada7040BdsLib/Armada7040BdsLib.c @@ -349,6 +349,7 @@ PlatformBdsPolicyBehavior ( Status = PlatformBdsConnectConsole (); ASSERT_EFI_ERROR (Status);
- BdsLibConnectAll();
BdsLibConnectAll() should not be used in the default boot path, and the fact that you do is usually a symptom of problems elsewhere.
The reason is that, in the default case, the only drivers that you need to connect are the ones that are described by the device path you are trying to boot from, and the shotgun approach of simply connecting everything may cause unbounded boot delays.
Would it be possible to diagnose the issue you are seeing in more detail? It is actually quite likely that there are issues elsewhere in the BDS that are exposed by your implementation.
Thanks, Ard.