Re: Dealing with holes in CPU address space

[Florian Fainelli]

On 4/7/2020 10:14 PM, Chris Packham wrote:
> Hi All,
> 
> I'm trying to port an old Broadcom MIPS CPU (BCM53003) to a shiny new
> kernel. I have some old historic source from a long forgotten Broadcom
> LDK but I'd prefer to do things the modern way with device-trees.

This is a MIPS74Kc CPU, right?

> 
> The problem I've been grappling with is trying to open up access to all
> of the RAM on the board. It has 512MB of DDR2. The CPU has two areas
> where this appears. The first 128MB is from 0 to 0x07ffffff the second
> area is from 0x88000000 to 0x9fffffff.
> 
> SoC peripherals are at 0x18000000 and there is an IO window for flash
> at 0x20000000.
> 
> The old code has some custom tlb initialisation to deal with this but I
> figured it should be possible with the following dts snippet.
> 
>         memory@0 {
>                 device_type = "memory";
>                 reg = <0x00000000 0x08000000
>                        0x88000000 0x18000000>;
>         };
> 
> I end up with only 128MB available. This appears to be
> because the default HIGHMEM_START of 0x20000000 stops the rest from
> being made available. If I add an override of HIGHMEM_START to
> 0xffffffff I seem to have the full 512MB avaiable but then I get a
> kernel panic

Given the SoC supports 128MB or 256MB of EBI space, I suppose you could
try setting HIGHMEM_START to 0x2000_0000 + 256MB = 0x3000_0000 and see
if it works better. There is also this comment in
arch/mips/include/asm/mach-malta/spaces.h regarding the last 64KB of
HIGHMEM:

 * The last 64KB of physical memory are reserved for correct HIGHMEM
 * macros arithmetics.

#define HIGHMEM_START   _AC(0xffff0000, UL)

> 
>   CPU 0 Unable to handle kernel paging request at virtual address 1fc00000, epc == 800167b8, ra == 800e2860
> 
> 0x1fc00000 is in the range where the SoC peripherals are so I'm
> thinking that is the problem. But then again that is a virtual address
> so maybe it's just a co-incidence.

0x1fc0_0000 should be accessed via KSEG0/1 since the physical address is
within the first 512MB of physical memory so it should not cause a
translation fault since it is unmapped.

> 
> Anyway I'd really appreciate any guidance that anyone could provide on
> this. Even if it's just "go look at this SoC".
> 
> Thanks,
> Chris
> 
> 

-- 
Florian