From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752897Ab1ARVnQ (ORCPT ); Tue, 18 Jan 2011 16:43:16 -0500 Received: from mail-gx0-f174.google.com ([209.85.161.174]:47348 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512Ab1ARVnN convert rfc822-to-8bit (ORCPT ); Tue, 18 Jan 2011 16:43:13 -0500 MIME-Version: 1.0 In-Reply-To: References: <20110118195933.13011.56098.stgit@localhost6.localdomain6> <20110118202902.13011.68847.stgit@localhost6.localdomain6> From: Grant Likely Date: Tue, 18 Jan 2011 14:42:52 -0700 X-Google-Sender-Auth: 4PWPqMtH_AdgY24GGc8gp43vcDk Message-ID: Subject: Re: [PATCH 1/8] arm/dt: Make __vet_atags also accept a dtb image To: Nicolas Pitre Cc: linux-arm-kernel@lists.infradead.org, Russell King , Catalin Marinas , devicetree-discuss@lists.ozlabs.org, lkml , Olof Johansson , Jeremy Kerr , John Linn , Lennert Buijtenhek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nicolas, On Tue, Jan 18, 2011 at 2:26 PM, Nicolas Pitre wrote: > On Tue, 18 Jan 2011, Grant Likely wrote: > >> The dtb is passed to the kernel via register r2, which is the same >> method that is used to pass an atags pointer.  This patch modifies >> __vet_atags to not clear r2 when it encounters a dtb image. >> >> Signed-off-by: Grant Likely >> --- >>  arch/arm/kernel/head-common.S |   19 +++++++++++++------ >>  arch/arm/kernel/head.S        |    8 ++++---- >>  2 files changed, 17 insertions(+), 10 deletions(-) >> >> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S >> index 8f57515..d9a9105 100644 >> --- a/arch/arm/kernel/head-common.S >> +++ b/arch/arm/kernel/head-common.S >> @@ -14,6 +14,7 @@ >>  #define ATAG_CORE 0x54410001 >>  #define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2) >>  #define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2) >> +#define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ > > ARM can be big endian too.  Would be nice to make this endian > independent, or at least list this limitation in the commit log. How about: #ifdef CONFIG_CPU_BIG_ENDIAN #define OF_DT_MAGIC 0xd00dfeed #else #define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ #endif Or is there a better way for loading and comparing big endian values in ARM? > >>  /* >>   * Exception handling.  Something went wrong and we can't proceed.  We >> @@ -105,22 +106,28 @@ __lookup_machine_type_data: >> >>  /* Determine validity of the r2 atags pointer.  The heuristic requires >>   * that the pointer be aligned, in the first 16k of physical RAM and >> - * that the ATAG_CORE marker is first and present.  Future revisions >> + * that the ATAG_CORE marker is first and present.  If CONFIG_OF_FLATTREE >> + * is selected, then it will also accept a dtb pointer.  Future revisions >>   * of this function may be more lenient with the physical address and >>   * may also be able to move the ATAGS block if necessary. >>   * >>   * r8  = machinfo >>   * >>   * Returns: >> - *  r2 either valid atags pointer, or zero >> + *  r2 either valid atags pointer, valid dtb pointer, or zero >>   *  r5, r6 corrupted >>   */ >>  __vet_atags: >>       tst     r2, #0x3                        @ aligned? >>       bne     1f >> >> -     ldr     r5, [r2, #0]                    @ is first tag ATAG_CORE? >> -     cmp     r5, #ATAG_CORE_SIZE >> +#ifdef CONFIG_OF_FLATTREE >> +     ldr     r5, [r2, #0]                    @ is it a DTB? >> +     ldr     r6, =OF_DT_MAGIC >> +     cmp     r5, r6 >> +     beq     2f >> +#endif >> +     cmp     r5, #ATAG_CORE_SIZE             @ is first tag ATAG_CORE? > > The "ldr r5 ..." is now done only within #ifdef CONFIG_OF_FLATTREE.  So > if CONFIG_OF_FLATTREE is undefined then r5 will contain garbage. Oops, that was a silly oversight. Fixed now. g. > > > Nicolas > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH 1/8] arm/dt: Make __vet_atags also accept a dtb image Date: Tue, 18 Jan 2011 14:42:52 -0700 Message-ID: References: <20110118195933.13011.56098.stgit@localhost6.localdomain6> <20110118202902.13011.68847.stgit@localhost6.localdomain6> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Nicolas Pitre Cc: Russell King , Catalin Marinas , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, lkml , Lennert Buijtenhek , Jeremy Kerr , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org Hi Nicolas, On Tue, Jan 18, 2011 at 2:26 PM, Nicolas Pitre w= rote: > On Tue, 18 Jan 2011, Grant Likely wrote: > >> The dtb is passed to the kernel via register r2, which is the same >> method that is used to pass an atags pointer. =A0This patch modifies >> __vet_atags to not clear r2 when it encounters a dtb image. >> >> Signed-off-by: Grant Likely >> --- >> =A0arch/arm/kernel/head-common.S | =A0 19 +++++++++++++------ >> =A0arch/arm/kernel/head.S =A0 =A0 =A0 =A0| =A0 =A08 ++++---- >> =A02 files changed, 17 insertions(+), 10 deletions(-) >> >> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common= .S >> index 8f57515..d9a9105 100644 >> --- a/arch/arm/kernel/head-common.S >> +++ b/arch/arm/kernel/head-common.S >> @@ -14,6 +14,7 @@ >> =A0#define ATAG_CORE 0x54410001 >> =A0#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2) >> =A0#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2) >> +#define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ > > ARM can be big endian too. =A0Would be nice to make this endian > independent, or at least list this limitation in the commit log. How about: #ifdef CONFIG_CPU_BIG_ENDIAN #define OF_DT_MAGIC 0xd00dfeed #else #define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ #endif Or is there a better way for loading and comparing big endian values in ARM? > >> =A0/* >> =A0 * Exception handling. =A0Something went wrong and we can't proceed. = =A0We >> @@ -105,22 +106,28 @@ __lookup_machine_type_data: >> >> =A0/* Determine validity of the r2 atags pointer. =A0The heuristic requi= res >> =A0 * that the pointer be aligned, in the first 16k of physical RAM and >> - * that the ATAG_CORE marker is first and present. =A0Future revisions >> + * that the ATAG_CORE marker is first and present. =A0If CONFIG_OF_FLAT= TREE >> + * is selected, then it will also accept a dtb pointer. =A0Future revis= ions >> =A0 * of this function may be more lenient with the physical address and >> =A0 * may also be able to move the ATAGS block if necessary. >> =A0 * >> =A0 * r8 =A0=3D machinfo >> =A0 * >> =A0 * Returns: >> - * =A0r2 either valid atags pointer, or zero >> + * =A0r2 either valid atags pointer, valid dtb pointer, or zero >> =A0 * =A0r5, r6 corrupted >> =A0 */ >> =A0__vet_atags: >> =A0 =A0 =A0 tst =A0 =A0 r2, #0x3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0@ aligned? >> =A0 =A0 =A0 bne =A0 =A0 1f >> >> - =A0 =A0 ldr =A0 =A0 r5, [r2, #0] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0@ is first tag ATAG_CORE? >> - =A0 =A0 cmp =A0 =A0 r5, #ATAG_CORE_SIZE >> +#ifdef CONFIG_OF_FLATTREE >> + =A0 =A0 ldr =A0 =A0 r5, [r2, #0] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0@ is it a DTB? >> + =A0 =A0 ldr =A0 =A0 r6, =3DOF_DT_MAGIC >> + =A0 =A0 cmp =A0 =A0 r5, r6 >> + =A0 =A0 beq =A0 =A0 2f >> +#endif >> + =A0 =A0 cmp =A0 =A0 r5, #ATAG_CORE_SIZE =A0 =A0 =A0 =A0 =A0 =A0 @ is f= irst tag ATAG_CORE? > > The "ldr r5 ..." is now done only within #ifdef CONFIG_OF_FLATTREE. =A0So > if CONFIG_OF_FLATTREE is undefined then r5 will contain garbage. Oops, that was a silly oversight. Fixed now. g. > > > Nicolas > -- = Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@secretlab.ca (Grant Likely) Date: Tue, 18 Jan 2011 14:42:52 -0700 Subject: [PATCH 1/8] arm/dt: Make __vet_atags also accept a dtb image In-Reply-To: References: <20110118195933.13011.56098.stgit@localhost6.localdomain6> <20110118202902.13011.68847.stgit@localhost6.localdomain6> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Nicolas, On Tue, Jan 18, 2011 at 2:26 PM, Nicolas Pitre wrote: > On Tue, 18 Jan 2011, Grant Likely wrote: > >> The dtb is passed to the kernel via register r2, which is the same >> method that is used to pass an atags pointer. ?This patch modifies >> __vet_atags to not clear r2 when it encounters a dtb image. >> >> Signed-off-by: Grant Likely >> --- >> ?arch/arm/kernel/head-common.S | ? 19 +++++++++++++------ >> ?arch/arm/kernel/head.S ? ? ? ?| ? ?8 ++++---- >> ?2 files changed, 17 insertions(+), 10 deletions(-) >> >> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S >> index 8f57515..d9a9105 100644 >> --- a/arch/arm/kernel/head-common.S >> +++ b/arch/arm/kernel/head-common.S >> @@ -14,6 +14,7 @@ >> ?#define ATAG_CORE 0x54410001 >> ?#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2) >> ?#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2) >> +#define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ > > ARM can be big endian too. ?Would be nice to make this endian > independent, or at least list this limitation in the commit log. How about: #ifdef CONFIG_CPU_BIG_ENDIAN #define OF_DT_MAGIC 0xd00dfeed #else #define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ #endif Or is there a better way for loading and comparing big endian values in ARM? > >> ?/* >> ? * Exception handling. ?Something went wrong and we can't proceed. ?We >> @@ -105,22 +106,28 @@ __lookup_machine_type_data: >> >> ?/* Determine validity of the r2 atags pointer. ?The heuristic requires >> ? * that the pointer be aligned, in the first 16k of physical RAM and >> - * that the ATAG_CORE marker is first and present. ?Future revisions >> + * that the ATAG_CORE marker is first and present. ?If CONFIG_OF_FLATTREE >> + * is selected, then it will also accept a dtb pointer. ?Future revisions >> ? * of this function may be more lenient with the physical address and >> ? * may also be able to move the ATAGS block if necessary. >> ? * >> ? * r8 ?= machinfo >> ? * >> ? * Returns: >> - * ?r2 either valid atags pointer, or zero >> + * ?r2 either valid atags pointer, valid dtb pointer, or zero >> ? * ?r5, r6 corrupted >> ? */ >> ?__vet_atags: >> ? ? ? tst ? ? r2, #0x3 ? ? ? ? ? ? ? ? ? ? ? ?@ aligned? >> ? ? ? bne ? ? 1f >> >> - ? ? ldr ? ? r5, [r2, #0] ? ? ? ? ? ? ? ? ? ?@ is first tag ATAG_CORE? >> - ? ? cmp ? ? r5, #ATAG_CORE_SIZE >> +#ifdef CONFIG_OF_FLATTREE >> + ? ? ldr ? ? r5, [r2, #0] ? ? ? ? ? ? ? ? ? ?@ is it a DTB? >> + ? ? ldr ? ? r6, =OF_DT_MAGIC >> + ? ? cmp ? ? r5, r6 >> + ? ? beq ? ? 2f >> +#endif >> + ? ? cmp ? ? r5, #ATAG_CORE_SIZE ? ? ? ? ? ? @ is first tag ATAG_CORE? > > The "ldr r5 ..." is now done only within #ifdef CONFIG_OF_FLATTREE. ?So > if CONFIG_OF_FLATTREE is undefined then r5 will contain garbage. Oops, that was a silly oversight. Fixed now. g. > > > Nicolas > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.