From patchwork Thu Apr 14 17:06:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fu Wei Fu X-Patchwork-Id: 65841 Delivered-To: patch@linaro.org Received: by 10.140.93.198 with SMTP id d64csp717984qge; Thu, 14 Apr 2016 10:06:21 -0700 (PDT) X-Received: by 10.140.202.81 with SMTP id x78mr20608157qha.15.1460653581387; Thu, 14 Apr 2016 10:06:21 -0700 (PDT) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id j125si33125656qhd.69.2016.04.14.10.06.20; Thu, 14 Apr 2016 10:06:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linaro-uefi-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linaro-uefi-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=linaro-uefi-bounces@lists.linaro.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id B3DDC68612; Thu, 14 Apr 2016 17:06:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,KHOP_BIG_TO_CC, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 7777D685FC; Thu, 14 Apr 2016 17:06:17 +0000 (UTC) X-Original-To: linaro-uefi@lists.linaro.org Delivered-To: linaro-uefi@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 4985D6860F; Thu, 14 Apr 2016 17:06:15 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by lists.linaro.org (Postfix) with ESMTPS id 780B46860E for ; Thu, 14 Apr 2016 17:06:14 +0000 (UTC) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 473987F084; Thu, 14 Apr 2016 17:06:13 +0000 (UTC) Received: from magi-f23.redhat.com (vpn1-4-216.pek2.redhat.com [10.72.4.216]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3EH6722019790; Thu, 14 Apr 2016 13:06:08 -0400 From: fu.wei@linaro.org To: xen-devel@lists.xensource.com, julien.grall@arm.com, sstabellini@kernel.org, dgdegra@tycho.nsa.gov, konrad.wilk@oracle.com, ian.jackson@eu.citrix.com, jbeulich@suse.com, keir@xen.org, tim@xen.org, xen-devel@lists.xen.org Date: Fri, 15 Apr 2016 01:06:05 +0800 Message-Id: <1460653565-17759-1-git-send-email-fu.wei@linaro.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: jcm@redhat.com, linaro-uefi@lists.linaro.org Subject: [Linaro-uefi] [PATCH] docs/arm64: update the documention for loading XSM support X-BeenThere: linaro-uefi@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: linaro-uefi-bounces@lists.linaro.org Sender: "Linaro-uefi" From: Fu Wei This patch updates the documention for loading XSM by the module which lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b Signed-off-by: Fu Wei --- docs/misc/arm/device-tree/booting.txt | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..f45a9c4 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,19 @@ 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 + detect the XSM magic from the second module which lacks of + a specific compatiblity string: + - if it's XSM, Xen will assume that the second such is a + "xen,xsm-policy". and also assume user won't load ramdisk; + - if it's not XSM, Xen will assume that the second such is a + "multiboot,ramdisk". + So if user want to load ramdisk without a specific compatiblity, + it must be the 2nd one. + Xen will also detect the XSM Magic for the following modules + which lack of a specific compatiblity, and assume that the module + is a "xen,xsm-policy" or "multiboot,module", according to the + result of detection. Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4