(CC Wei for the release-ack)
Hi Fu Wei,
On 21/04/16 12:07, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patch updates the documentation for allowing detection of an XSM module that lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b.
Signed-off-by: Fu Wei fu.wei@linaro.org
The new version looks good to me:
Acked-by: Julien Grall julien.grall@arm.com
Can a native speaker (Ian, Konrad, George) double-check the wording)?
Wei, this patch only update the doc. I am not sure whether we need your release-ack.
Regards,
v2: Improve the doc, according to the suggestion from Julien Grall.
v1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html The first upstream version submitted in xen-devel mailing list.
docs/misc/arm/device-tree/booting.txt | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..254ba77 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,24 @@ Each node contains the following properties: string (which must always be present).
Xen will assume that the first module which lacks a more
- specific compatible string is a "multiboot,kernel" and that
- the second such is a "multiboot,ramdisk". Any subsequent
- modules which lack a specific compatiblity string will not
- receive any special treatment.
specific compatible string is a "multiboot,kernel".
Xen will check all the modules for the XSM Magic from the second
module that lacks a specific compatible string. According to the
result of the detection:
- if it's a XSM, Xen will assume its compatible string is a
"xen,xsm-policy";
- if it's not a XSM, for the second module that lacks a specific
compatible string, Xen will assume its compatible string is a"multiboot,ramdisk"; for the third and subsequent modules thoselacks a specific compatible string will not receive any specialtreatment.This means if the ramdisk module is present and does not have the
compatible string "multiboot,ramdisk", then it must always be the
second module.
Note: This XSM Magic detection behavior was introduced by Xen 4.7.
Xen 4.6 (and downwards) still requires the XSM module to have the
compatible string "xen,xsm-policy".
Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4