Re: Dealing with holes in CPU address space

[Jiaxun Yang]

On Wed, 8 Apr 2020 05:14:22 +0000
Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx> 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.
> 
> 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

Hi,

Have you tried to enable CONFIG_HIGHMEM?

> 
>   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.

0x1fc00000 should be the Boot ROM's physical address. Probably you
forgot to convert it into virtual address in your platform code?

Check the EPC of exception in vmlinux with addr2line may help. (Don't
forget to compile your kernel with debuginfo). 

> 
> 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
> 
> 

--
Jiaxun Yang