From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Wed, 2 Dec 2015 19:04:56 -0800 Subject: [U-Boot] [PATCH v6 2/2] armv8: fsl-layerscape: Make DDR non secure in MMU tables In-Reply-To: References: <1447869701-1409-1-git-send-email-yorksun@freescale.com> <1447869701-1409-3-git-send-email-yorksun@freescale.com> <565F158F.2010503@freescale.com> Message-ID: <565FB158.4030305@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/02/2015 06:48 PM, Hou Zhiqiang-B48286 wrote: > > >> -----Original Message----- >> From: York Sun [mailto:yorksun at freescale.com] >> Sent: 2015?12?3? 0:00 >> To: Hou Zhiqiang-B48286; U-Boot Mailing List >> Cc: Pan Lijun-B44306; Hu Mingkai-B21284; Sharma Bhupesh-B45370; Gong >> Qianyu-B52263; Tom Rini; Li Yang-Leo-R58472; Albert Aribaud; Kushwaha >> Prabhakar-B32579; Wang Huan-B18965 >> Subject: Re: [PATCH v6 2/2] armv8: fsl-layerscape: Make DDR non secure in >> MMU tables >> >> >> >> On 12/01/2015 10:38 PM, Hou Zhiqiang-B48286 wrote: >> >> >> >>>> /* Invalidate all table entries */ >>>> memset(level0_table, 0, PGTABLE_SIZE); @@ -269,6 +344,22 @@ static >>>> inline void final_mmu_setup(void) >>>> &final_mmu_table[i]); >>>> } >>>> } >>>> + /* Set the secure memory to secure in MMU */ #ifdef >>>> +CONFIG_SYS_MEM_RESERVE_SECURE >>>> + if (gd->secure_ram & MEM_RESERVE_SECURE_MAINTAINED) { #ifdef >>>> +CONFIG_FSL_LSCH3 >>>> + level2_table_secure = level2_table1 + 512; #elif >>>> +defined(CONFIG_FSL_LSCH2) >>>> + level2_table_secure = level2_table2 + 512; #endif >>>> + /* update tlb pointer */ >>>> + gd->arch.tlb_addr = gd->secure_ram & ~0x3; >>> >>> The memory reserved for mmu table was lost? If it's better to record it >> and use for non-sec mmu table? >> >> That can be arranged. >> >>> >>> If this func is called from non-secure state, for example EL2, the >> secure memory cannot be accessed and the PMD_SECT_NS bit should be >> cleared. >> >> We need to setup secure memory at EL3 to have secure memory to begin with. >> But you have a point here. Will look into it. >> > > Yes, this func is called at EL3 for now, it is a assumption for this func. > I mean we'd better make it a API that can be invoked at both EL3 and EL2 > to setup the MMU table. And do you know if the EL1 should be taken into > account in u-boot? We don't need to differentiate this function for EL2 or EL1 if we ever need to run at. The only difference is EL3 can handle secure access. So adding a detection of exception level before setting secure bit will suffice. York