armv8 mmu limitation?

Folks,
We are working with a device that has 8GB DDR.

Using the basic mmu_config_range() call, twice, like this:

mmu_config_range((void *)0x080000000, DRAMSIZE, UNCACHED_MEM);
    mmu_config_range((void *)0x180000000, DRAMSIZE, UNCACHED_MEM);

print messages from Coreboot suggest the mmu calls are happy:

Mapping address range [0000000080000000:0000000180000000) as 
non-cacheable | read-write | non-secure | normal
Mapping address range [0000000180000000:0000000280000000) as 
non-cacheable | read-write | non-secure | normal

The debugger is not convinced and believes only 6GB got mapped.

I'm guessing tables are overflowing and perhaps granule or page sizes 
need to be changed or?
As mmu_init() takes no parameters, what mmu options are easily 
configurable within Coreboot?
Any pointers to correct code to look at is appreciated.

Cheers,
T.mike

On 2018-03-06 12:57, [e-mail] wrote:
> Folks,
> We are working with a device that has 8GB DDR.
>
> Using the basic mmu_config_range() call, twice, like this:
>
> mmu_config_range((void *)0x080000000, DRAMSIZE, UNCACHED_MEM);
>    mmu_config_range((void *)0x180000000, DRAMSIZE, UNCACHED_MEM);
>
> print messages from Coreboot suggest the mmu calls are happy:
>
> Mapping address range [0000000080000000:0000000180000000) as
> non-cacheable | read-write | non-secure | normal
> Mapping address range [0000000180000000:0000000280000000) as
> non-cacheable | read-write | non-secure | normal
>
> The debugger is not convinced and believes only 6GB got mapped.

This came back to BITS_PER_VA being hard-coded to 33 which is currently 
being discussed in another thread.
If we change to 34 we see full 8GB mapping that we were expecting.
> I'm guessing tables are overflowing and perhaps granule or page sizes
> need to be changed or?
> As mmu_init() takes no parameters, what mmu options are easily
> configurable within Coreboot?
> Any pointers to correct code to look at is appreciated.
>
> Cheers,
> T.mike