linux-kernel - Dealing with holes in CPU address space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Apr 2020 05:14:22 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hamish Martin" <Hamish.Martin@...iedtelesis.co.nz>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Dealing with holes in CPU address space

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

  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.

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