> On Jan 23, 2019, at 8:27 AM, Tomas Pilar (tpilar) <tpi...@solarflare.com>
> wrote:
>
>
>> The set of devices connected during BDS is platform policy. It is not
>> the "network stack" that calls Snp.Start(), but the platform BDS code
>> that calls gBS->ConnectController() on the device, possibly without a
>> good reason (e.g. without the device being present in a UEFI boot
>> option). The network stack only "reacts" to that connection request.
> Indeed, but even if a SNP handle is present as a boot option in a boot
> manager, surely the Snp.Start() should be deferred until the user actually
> chooses to boot from that handle.
>
Tom,
You don't need to call gBS->ConnectController() on all possible boot options,
just the one you are currently trying to boot.
I mostly muck around in a non edk2 BDS, but in general what you do in a BDS is:
1) Connect your graphics console(s) (usually involves ConOut NVRAM)
3) Connect any serial consoles (ConIn/ConOut NVRAM).
2) Connect any built in keyboard, maybe SPI etc. (ConIn NVRAM).
4) Connect any hot pluggable console devices (Connect any existing USB HID
devices).
5) Connect any other device required in the boot path (like the example entropy
device.
The platform can have policy to force values into ConIn/ConOut. For example on
a laptop maybe you always want the built in keyboard active.
As you attempt to boot a boot option you can recursively connect the device
path for that boot option and attempt to boot it. If that option fails you can
fall back to the next boot option and try to connect that device path and boot.
Thus you don't need to start things before you are ready.
If you launch Firmware Setup that usually does a Connect All. The same things
happen when you launch the Shell.
Also some drivers connect extra stuff. For example when you try to connect a
specific PCI device all the PCI IO handles get created. This is just how you
have to enumerate PCI. But the recursive connect should only happen on the PCI
IO handle you care about.
Thanks,
Andrew Fish
> A workaround that we have in the legacy implementation doesn't start the
> underlying hardware datapath until the platform tries to send the first
> packet (since PXE boot is always initiated by the client) but that is a
> horrible hack that should not be necessary. The distinction between
> Snp.Initialize() and Snp.Start() is there exactly for that reason, no?
>
> In other words, ConnectController() should not immediately result in
> Snp.Start() being called.
>
> Cheers,
> Tom
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
