From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 23 Feb 2016 10:29:07 -0700 Subject: [U-Boot] [PATCH 4/9] tegra: Replace home grown mmu code with generic table approach In-Reply-To: <56CC365A.3010300@xilinx.com> References: <1456106232-233210-1-git-send-email-agraf@suse.de> <1456106232-233210-5-git-send-email-agraf@suse.de> <56CB5332.8010300@wwwdotorg.org> <56CC365A.3010300@xilinx.com> Message-ID: <56CC96E3.7020308@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/23/2016 03:37 AM, Michal Simek wrote: > On 22.2.2016 19:28, Stephen Warren wrote: >> On 02/21/2016 06:57 PM, Alexander Graf wrote: >>> Now that we have nice table driven page table creating code that gives >>> us everything we need, move to that. >> >>> diff --git a/include/configs/tegra210-common.h >>> b/include/configs/tegra210-common.h >> >>> +#define CONFIG_SYS_FULL_VA >>> +#define CONFIG_SYS_MEM_MAP { \ >>> + { \ >>> + .base = 0x0UL, \ >>> + .size = 0x80000000UL, \ >>> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | \ >>> + PTE_BLOCK_NON_SHARE | \ >>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN \ >>> + }, { \ >>> + .base = 0x80000000UL, \ >>> + .size = 0xff80000000UL, \ >>> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | \ >>> + PTE_BLOCK_INNER_SHARE \ >>> + }, \ >>> + } >> >> I'd prefer a layout that didn't align the closing } for different >> nesting levels in the same column. To avoid indenting everything a lot, >> it seems simplest to pull the final } back into the first column. >> >> I believe the .size field of the second entry in the array only needs to >> be 0x80000000. Testing with a PCIe Ethernet card on p2371-2180 (the >> driver for which sets up noncached entries in the page tables, hence >> should exercise all this code) confirms that. >> >> While recent Tegra systems do support more than 2GB of RAM, U-Boot will >> itself only use the first 2GB, so that PAs over 4GB are not used. See >> board_get_usable_ram_top() in arch/arm/mach-tegra/board2.c. That's >> because some peripherals can only access 32-bit PAs, and the simplest >> way to accommodate that is to ignore any RAM above the 32-bit limit. > > Didn't you use mtest to test memory above of 2GB? It looks like we don't have mtest enabled. However, I was able to use itest to confirm that RAM > 4GB PA does work with this patch. I suppose we may as well leave it enabled then.