On 09/01/2016 11:40 PM, Heyi Guo wrote:
在 8/31/2016 6:39 PM, Leif Lindholm 写道:
On Wed, Aug 31, 2016 at 10:31:36AM +0100, Ard Biesheuvel wrote:
(+ Charles, Leif)
On 29 August 2016 at 08:45, Heyi Guo heyi.guo@linaro.org wrote:
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone please provide the answers or some ideas?
- In SBSA it says that I/O virtualization property should be expressed by
system firmware data. Then how to express this information by ACPI? Is only IORT table related? Or is there any examples?
Pass. Graeme?
- In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access" include both "read" and "write"? If write is also included, I'm afraid there might be some critical configuration registers which will cause unpredicted behavior or even system hang due to unintended random write.
' Populated or not' means it could be memory, MMIO or nothing at all.
If a write to a system register causes a deadlock as a side effect, that is fine. This section simply stipulates that the write *itself* should complete in finite time.
What the section is explicitly about is unpopulated regions. Due to the nature of AXI, all transactions must complete - so historically most systems have included a "default slave", to which all accesses not covered by any explicit address decoding are routed.
Some AArch64 systems trigger an interrupt (and presumably don't deadlock) instead of generating this abort.
That's not contradicting Ard, only providing background.
- In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it is
not used for boot in UEFI, and is mainly used for loading PCIe option ROM in EDK2 implementation. So why is this protocol required while PCIe is not mandatory for ARM server?
My guess is that this is an oversight. If PCIe is not mandatory, then this protocol should not be mandatory either.
Interestingly, looking into this exposes a UEFI spec error: "In the case of EFI_LOAD_FILE2_PROTOCOL, the behavior is the same as above, except that it is only used if BootOption is FALSE"
(There is no BootOption, only BootPolicy.)
But EFI_LOAD_FILE2_PROTOCOL can also be used by anything wishing to load an image from a RAM location without describing it as a device path. So I think it needs to remain mandatory regardless.
(Although why isn't PCIe mandatory...?)
I didn't see anything in SBSA saying that PCIe is mandatory; it always says that "if PCIe is supported, ...", so I suppose PCIe is not mandatory in ARM server. Please correct me if I'm wrong.
I would have to double check the document, but there are several levels of SBSA compliance. IIRC, the lowest level may not require PCIe. So, you end up with clunky wording when trying to describe all levels of compliance. Perhaps the "if PCIe is supported" means "if the level of SBSA compliance you want to implement is greater than level 0 such that PCIe is required, then...".
In EDK2 implementation, EFI_LOAD_FILE2_PROTOCOL is installed to PCI IO device handle, so if there is no PCIe support in UEFI, there will not be this protocol instance and it will become not compliant to SBBR.
- In SBBR, for IPv6 related protocols, it is said that they are optional
on platforms that do not support networking. The question is, on platforms that *do* support networking, do IPv6 protocols become mandatory? Or is it allowed for only supporting IPv4 protocols?
Charles, Leif?
I don't see a value in shipping a system today that does not support IPv6, and the SBBR seems to agree :)
If a specific hardware component (for some reason) could not be made to support IPv6, it would still be possible for the platform to be compliant as long as the relevant protocols were supported by the firmware, so that a plug-in card could still make use of IPv6.
Also from the view of implementation, shall we switch to network stack modules from NetworkPkg instead of MdeModulePkg? I think only the ones in NetworkPkg support IPv6.
Thanks.
Heyi
Regards,
Leif
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi