Received: by 10.223.164.202 with SMTP id h10csp96931wrb; Tue, 14 Nov 2017 11:45:52 -0800 (PST) X-Google-Smtp-Source: AGs4zMasgLcO7bkyi9oYsSXsLMwLdBhoT8xNiLPJTZ3JRXoE37mJX0ui8pV/Uf/A6v1NG1As0tLP X-Received: by 10.98.95.197 with SMTP id t188mr14693376pfb.230.1510688752531; Tue, 14 Nov 2017 11:45:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510688752; cv=none; d=google.com; s=arc-20160816; b=W2pp42nwstdOVVDuN481s93JfhC+tuJ5zdDML600B+6XCU9LMHsPBk/ZbfW9HjR3xb CDixPHucx0ML+sryddc+hBQtmOrzf7lyKIbOb3RWy55TKBvCloGr1w6IvhGuvpca6elE 9G+ssvPb8zt5921KMPGarWFNAbL65PSO3Ho9tjqQpF33KgKeKgCqxINU1KMb8OR4cg8f z2aqc0ftP+M6Zt8IhTwWoXDbJUoe0ksvP49qjIEJNHyX3IJQkdYoBpc8XjFY1i4WwSFm wgd1CX3SuE/kPN8ZCINOlTnaS7RgzM1dqQvFgz06iMGxiUUigXnnPQqdE5cUpsB6dwI6 SvFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=2lULVLS3KJfzCouw66EYwsx4MXv8VP52HEPqhaw2G/c=; b=PcPfXRlGFJPnlkC3UaW2olahcsKqJ/+twPa9H1LSWKVghu47dd/lzsOe+gaP6+oWVB x+oaqiSA49uP+ZDH3mlPF+zfDXYkEzQSA8FDVcuCIL92IJO+eg64KSTC/Mq38XXvzspS 8gco79jhqA7PVRSJiyuaZ2Rt8EyAFggSiwyP5bpWREJbhL8YNZR8xMlDmsMbyhuhrwBN Ad9E+Bl0dLXhY5Nu7ld6eYryH/pa40RGJUQirtKbl0wccA19gBT4hkzsBjVAtPr2cMjv FSIgvbntDK9lhRvSp0fsvA7SsAo2Iwtq0POwzGjFuNLJfmt3l+S3uCghijfBRa15boOD r1BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=FXhF/UOc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j3si15906142pgp.748.2017.11.14.11.45.40; Tue, 14 Nov 2017 11:45:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=FXhF/UOc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756413AbdKNTfs (ORCPT + 88 others); Tue, 14 Nov 2017 14:35:48 -0500 Received: from fllnx209.ext.ti.com ([198.47.19.16]:57724 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755362AbdKNTfj (ORCPT ); Tue, 14 Nov 2017 14:35:39 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id vAEJVdrp009305; Tue, 14 Nov 2017 13:31:39 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1510687899; bh=eht7OA9vGi6duQGa0N03NjtA1kj4ziCKSgvwulXevnQ=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=FXhF/UOczZRzJ7REh0oI52B/rtsSrvV+iLlr16q0QYucb4lkE4icpaQwZ8OVqtOjk lCpD+FJr1x8N8iGCyHhLYTq0zW5ypBkPgsYk3r8tv7LO+/IamUN9nyQE3Jq/7PLti3 oduiMPltG+tyPUCIgeZ16UGEqgDSNi5JKIHuakwg= Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id vAEJVYhs010037; Tue, 14 Nov 2017 13:31:34 -0600 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 14 Nov 2017 13:31:33 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend Transport; Tue, 14 Nov 2017 13:31:33 -0600 Received: from [127.0.0.1] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id vAEJVPNZ029202; Tue, 14 Nov 2017 13:31:26 -0600 Subject: Re: n900 in next-20170901 To: Tony Lindgren , Joonsoo Kim CC: Pavel Machek , , , kernel list , linux-arm-kernel , , , , , , , , "Aneesh Kumar K.V" , Vlastimil Babka , Andrew Morton , Stephen Rothwell , Russell King References: <20171109000801.GA23982@js1304-P5Q-DELUXE> <20171109001113.GZ28152@atomide.com> <20171109003639.GB23982@js1304-P5Q-DELUXE> <20171109035031.GA24383@js1304-P5Q-DELUXE> <20171109150854.GC28152@atomide.com> <20171110001315.GA29669@js1304-P5Q-DELUXE> <20171110032610.GJ28152@atomide.com> <20171110063727.GA32073@js1304-P5Q-DELUXE> <20171110153620.GO28152@atomide.com> <20171114063724.GA16969@js1304-P5Q-DELUXE> <20171114173719.GA28152@atomide.com> From: Tero Kristo Message-ID: <5c885f60-bc8c-5f8e-dc81-57eacc57abc8@ti.com> Date: Tue, 14 Nov 2017 21:31:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171114173719.GA28152@atomide.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/11/17 19:37, Tony Lindgren wrote: > * Joonsoo Kim [171114 06:34]: >> On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: >>> * Joonsoo Kim [171110 06:34]: >>>> On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: >>>>> +#define OMAP34XX_SRAM_PHYS 0x40200000 >>>>> +#define OMAP34XX_SRAM_VIRT 0xd0010000 >>>>> +#define OMAP34XX_SRAM_SIZE 0x10000 >>>> >>>> For my testing environment, vmalloc address space is started at >>>> roughly 0xe0000000 so 0xd0010000 would not be valid. >>> >>> Well we can map it anywhere we want, got any preferences? >> >> My testing environment is a beagle-(xm?) for QEMU. It is configured by >> CONFIG_VMSPLIT_3G=y so kernel address space is started at 0xc0000000. >> And, it has 512 MB memory so 0xc0000000 ~ 0xdff00000 is used for >> direct mapping. See below. >> >> [ 0.000000] Memory: 429504K/522240K available (11264K kernel code, >> 1562K rwdata, 4288K rodata, 2048K init, 405K bss, 27200K reserved, >> 65536K cma-reserved, 0K highmem) >> [ 0.000000] Virtual kernel memory layout: >> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) >> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) >> [ 0.000000] vmalloc : 0xe0000000 - 0xff800000 ( 504 MB) >> [ 0.000000] lowmem : 0xc0000000 - 0xdff00000 ( 511 MB) >> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) >> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) >> [ 0.000000] .text : 0xc0208000 - 0xc0e00000 (12256 kB) >> [ 0.000000] .init : 0xc1300000 - 0xc1500000 (2048 kB) >> [ 0.000000] .data : 0xc1500000 - 0xc1686810 (1563 kB) >> [ 0.000000] .bss : 0xc168fc68 - 0xc16f512c ( 406 kB) >> >> Therefore, if OMAP34XX_SRAM_VIRT is 0xd0010000, direct mapping is >> broken and the system doesn't work. I guess that we should use more >> stable address like as 0xf0000000. > > OK. Let's forget about adding static mappings and my earlier > patches to attempt to fix this. Below is what I now think we should > merge as a fix before merging Joonsoo's patches. Please all review > and test, adding Tero to Cc also. > > Regards, > > Tony > > 8< ----------------------- > From tony Mon Sep 17 00:00:00 2001 > From: Tony Lindgren > Date: Mon, 13 Nov 2017 13:23:33 -0800 > Subject: [PATCH] ARM: OMAP2+: Fix SRAM virt to phys translation for > save_secure_ram_context > > With the CMA changes from Joonsoo Kim , it > was noticed that n900 stopped booting. After investigating it turned > out that n900 save_secure_ram_context does some whacky virtual to > physical address translation for the SRAM data address. > > As we now only have minimal parts of omap3 idle code copied to SRAM, > running save_secure_ram_context() in SRAM is not needed. It only gets > called on PM init. And it seems there's no need to ever call this from > SRAM idle code. > > So let's just keep save_secure_ram_context() in DDR, and pass it the > physical address of the parameters. We can do everything else in > omap-secure.c like we already do for other secure code. > > And since we don't have any documentation, I still have no clue what > the values for 0, 1 and 1 for the parameters might be. If somebody has > figured it out, please do send a patch to add some comments. > > Debugged-by: Joonsoo Kim > Signed-off-by: Tony Lindgren > --- > arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++ > arch/arm/mach-omap2/omap-secure.h | 4 ++++ > arch/arm/mach-omap2/pm.h | 4 ---- > arch/arm/mach-omap2/pm34xx.c | 13 ++++--------- > arch/arm/mach-omap2/sleep34xx.S | 26 ++++---------------------- > 5 files changed, 31 insertions(+), 35 deletions(-) I guess you could just use rx51_secure_dispatcher and ditch the save_secure_ram_context call completely (and most of the other related code)? That one would handle the cache also in a clean manner. Something like: rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4, __pa(omap3_secure_ram_storage), 0, 1, 1); Can't test it myself as I don't have omap3 secure HW. -Tero > > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c > --- a/arch/arm/mach-omap2/omap-secure.c > +++ b/arch/arm/mach-omap2/omap-secure.c > @@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base(void) > return omap_secure_memblock_base; > } > > +u32 omap3_save_secure_ram(void __iomem *addr, int size) > +{ > + u32 ret; > + u32 param[5]; > + > + if (size != OMAP3_SAVE_SECURE_RAM_SZ) > + return OMAP3_SAVE_SECURE_RAM_SZ; > + > + param[0] = 4; /* Number of arguments */ > + param[1] = __pa(addr); /* Physical address for saving */ > + param[2] = 0; > + param[3] = 1; > + param[4] = 1; > + > + ret = save_secure_ram_context(__pa(param)); > + > + return ret; > +} > + > /** > * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls > * @idx: The PPA API index > diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h > --- a/arch/arm/mach-omap2/omap-secure.h > +++ b/arch/arm/mach-omap2/omap-secure.h > @@ -31,6 +31,8 @@ > /* Maximum Secure memory storage size */ > #define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K) > > +#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F > + > /* Secure low power HAL API index */ > #define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a > #define OMAP4_HAL_SAVEHW_INDEX 0x1b > @@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u32 pargs); > extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs); > extern phys_addr_t omap_secure_ram_mempool_base(void); > extern int omap_secure_ram_reserve_memblock(void); > +extern u32 save_secure_ram_context(u32 args_pa); > +extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size); > > extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, > u32 arg1, u32 arg2, u32 arg3, u32 arg4); > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h > --- a/arch/arm/mach-omap2/pm.h > +++ b/arch/arm/mach-omap2/pm.h > @@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz; > /* ... and its pointer from SRAM after copy */ > extern void (*omap3_do_wfi_sram)(void); > > -/* save_secure_ram_context function pointer and size, for copy to SRAM */ > -extern int save_secure_ram_context(u32 *addr); > -extern unsigned int save_secure_ram_context_sz; > - > extern void omap3_save_scratchpad_contents(void); > > #define PM_RTA_ERRATUM_i608 (1 << 0) > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -48,6 +48,7 @@ > #include "prm3xxx.h" > #include "pm.h" > #include "sdrc.h" > +#include "omap-secure.h" > #include "sram.h" > #include "control.h" > #include "vc.h" > @@ -66,7 +67,6 @@ struct power_state { > > static LIST_HEAD(pwrst_list); > > -static int (*_omap_save_secure_sram)(u32 *addr); > void (*omap3_do_wfi_sram)(void); > > static struct powerdomain *mpu_pwrdm, *neon_pwrdm; > @@ -121,8 +121,8 @@ static void omap3_save_secure_ram_context(void) > * will hang the system. > */ > pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON); > - ret = _omap_save_secure_sram((u32 *)(unsigned long) > - __pa(omap3_secure_ram_storage)); > + ret = omap3_save_secure_ram(omap3_secure_ram_storage, > + OMAP3_SAVE_SECURE_RAM_SZ); > pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state); > /* Following is for error tracking, it should not happen */ > if (ret) { > @@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) > * > * The minimum set of functions is pushed to SRAM for execution: > * - omap3_do_wfi for erratum i581 WA, > - * - save_secure_ram_context for security extensions. > */ > void omap_push_sram_idle(void) > { > omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz); > - > - if (omap_type() != OMAP2_DEVICE_TYPE_GP) > - _omap_save_secure_sram = omap_sram_push(save_secure_ram_context, > - save_secure_ram_context_sz); > } > > static void __init pm_errata_configure(void) > @@ -553,7 +548,7 @@ int __init omap3_pm_init(void) > clkdm_add_wkdep(neon_clkdm, mpu_clkdm); > if (omap_type() != OMAP2_DEVICE_TYPE_GP) { > omap3_secure_ram_storage = > - kmalloc(0x803F, GFP_KERNEL); > + kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL); > if (!omap3_secure_ram_storage) > pr_err("Memory allocation failed when allocating for secure sram context\n"); > > diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S > --- a/arch/arm/mach-omap2/sleep34xx.S > +++ b/arch/arm/mach-omap2/sleep34xx.S > @@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_restore) > ENDPROC(enable_omap3630_toggle_l2_on_restore) > > /* > - * Function to call rom code to save secure ram context. This gets > - * relocated to SRAM, so it can be all in .data section. Otherwise > - * we need to initialize api_params separately. > + * Function to call rom code to save secure ram context. > + * > + * r0 = physical address of the parameters > */ > - .data > - .align 3 > ENTRY(save_secure_ram_context) > stmfd sp!, {r4 - r11, lr} @ save registers on stack > - adr r3, api_params @ r3 points to parameters > - str r0, [r3,#0x4] @ r0 has sdram address > - ldr r12, high_mask > - and r3, r3, r12 > - ldr r12, sram_phy_addr_mask > - orr r3, r3, r12 > + mov r3, r0 @ physical address of parameters > mov r0, #25 @ set service ID for PPA > mov r12, r0 @ copy secure service ID in r12 > mov r1, #0 @ set task id for ROM code in r1 > @@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context) > nop > nop > ldmfd sp!, {r4 - r11, pc} > - .align > -sram_phy_addr_mask: > - .word SRAM_BASE_P > -high_mask: > - .word 0xffff > -api_params: > - .word 0x4, 0x0, 0x0, 0x1, 0x1 > ENDPROC(save_secure_ram_context) > -ENTRY(save_secure_ram_context_sz) > - .word . - save_secure_ram_context > - > - .text > > /* > * ====================== > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From 1584064295150883632@xxx Tue Nov 14 17:43:53 +0000 2017 X-GM-THRID: 1577552291468010502 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread