From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Mon, 22 Feb 2016 11:42:23 -0700
Subject: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic
In-Reply-To: <1456106232-233210-3-git-send-email-agraf@suse.de>
References: <1456106232-233210-1-git-send-email-agraf@suse.de>
 <1456106232-233210-3-git-send-email-agraf@suse.de>
Message-ID: <56CB568F.4030407@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 02/21/2016 06:57 PM, Alexander Graf wrote:
> The idea to generate our pages tables from an array of memory ranges
> is very sound. However, instead of hard coding the code to create up
> to 2 levels of 64k granule page tables, we really should just create
> normal 4k page tables that allow us to set caching attributes on 2M
> or 4k level later on.
>
> So this patch moves the full_va mapping code to 4k page size and
> makes it fully flexible to dynamically create as many levels as
> necessary for a map (including dynamic 1G/2M pages). It also adds
> support to dynamically split a large map into smaller ones when
> some code wants to set dcache attributes.
>
> With all this in place, there is very little reason to create your
> own page tables in board specific files.

> +/* Returns the estimated required size of all page tables */
> +u64 get_page_table_size(void)
> +{
> +	int i;
> +	u64 one_pt = MAX_PTE_ENTRIES * sizeof(u64);
> +	u64 size = 0;
> +
> +	/* root page table */
> +	size += one_pt;
> +
> +	for (i = 0; i < ARRAY_SIZE(mem_map); i++) {
> +		struct mm_region *map = &mem_map[i];
> +
> +		/* Account for Lv0 page tables */
> +		size += one_pt * ((map->size >> 39) + 1);
> +
> +		/* 1GB aligned pages fit already, so count the others */
> +		if (map->size & 0x3fffffffULL)
> +			size += one_pt;
> +		if (map->base & 0x3fffffffULL)
> +			size += one_pt;

One more comment here: The two conditions should check start and end, 
not start and size. The reason is that for a region with aligned size 
but unaligned start, the end is not aligned and hence needs a next-level 
page table allocated to correctly represent that. That won't be 
accounted for in the current code, but would be if end (==start+size) 
was used instead.

> +	}
> +
> +	/* Assume we may have to split up to 4 more page tables off */
> +	size += one_pt * 4;
> +
> +	return size;
> +}