* Dealing with holes in CPU address space
@ 2020-04-08 5:14 Chris Packham
2020-04-08 7:29 ` Jiaxun Yang
2020-04-08 20:07 ` Florian Fainelli
0 siblings, 2 replies; 7+ messages in thread
From: Chris Packham @ 2020-04-08 5:14 UTC (permalink / raw)
To: linux-mips; +Cc: linux-kernel, Hamish Martin, devicetree
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-08 5:14 Dealing with holes in CPU address space Chris Packham
@ 2020-04-08 7:29 ` Jiaxun Yang
2020-04-08 21:33 ` Chris Packham
2020-04-08 20:07 ` Florian Fainelli
1 sibling, 1 reply; 7+ messages in thread
From: Jiaxun Yang @ 2020-04-08 7:29 UTC (permalink / raw)
To: Chris Packham; +Cc: linux-mips, linux-kernel, Hamish Martin, devicetree
On Wed, 8 Apr 2020 05:14:22 +0000
Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-08 5:14 Dealing with holes in CPU address space Chris Packham
2020-04-08 7:29 ` Jiaxun Yang
@ 2020-04-08 20:07 ` Florian Fainelli
1 sibling, 0 replies; 7+ messages in thread
From: Florian Fainelli @ 2020-04-08 20:07 UTC (permalink / raw)
To: Chris Packham, linux-mips; +Cc: linux-kernel, Hamish Martin, devicetree
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-08 7:29 ` Jiaxun Yang
@ 2020-04-08 21:33 ` Chris Packham
2020-04-09 4:03 ` Florian Fainelli
0 siblings, 1 reply; 7+ messages in thread
From: Chris Packham @ 2020-04-08 21:33 UTC (permalink / raw)
To: jiaxun.yang; +Cc: linux-kernel, Hamish Martin, linux-mips, devicetree
On Wed, 2020-04-08 at 15:29 +0800, Jiaxun Yang wrote:
> On Wed, 8 Apr 2020 05:14:22 +0000
> Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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?
>
I have but that didn't seem to help. As I understand it HIGHMEM is
intended for situations when you have more physical RAM that can be
addressed (e.g. >4GB on a 32-bit system).
> >
> > 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?
Yes that's right it's the bootroms PA. I'm not intitentionally doing
anything with it but maybe that's the problem.
>
> Check the EPC of exception in vmlinux with addr2line may help. (Don't
> forget to compile your kernel with debuginfo).
>
The full panic is
CPU 0 Unable to handle kernel paging request at virtual address 1fc00000, epc == 800167b8, ra == 800e2860
Oops[#1]:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.5.0-at1 #46
$ 0 : 00000000 00000001 00000001 807e4270
$ 4 : 1fc00000 00000000 1fc00f80 00000001
$ 8 : 83e52a00 83e52a24 807f628c 8080fa00
$12 : ffffffff 00000001 0000000b ffffffff
$16 : 83e52a20 80000000 80870000 83e52a00
$20 : 8080fdd4 807dde00 00000000 8080f9bc
$24 : 8080fb68 ffffff7f
$28 : 807dc000 807ddd38 83e52a00 800e2860
Hi : 00000000
Lo : 00000000
epc : 800167b8 clear_page+0x18/0x128
ra : 800e2860 get_page_from_freelist+0xa94/0xdd4
Status: 11000002 KERNEL EXL
Cause : 4080000c (ExcCode 03)
BadVA : 1fc00000
PrId : 00019749 (MIPS 74Kc)
Modules linked in:
Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=00000000)
*HwTLS: e19f7d3a
Stack : 807e0000 807dde98 80867cd8 80791814 00000001 80687974 807dde18 00000000
807f5ed0 807f628c 807f628c 8080fdd4 80870000 00000001 807e0000 00000044
0000005c 807dde00 00000000 00000001 80810000 8075a660 80870001 00000000
00000100 00000000 807e0000 00000000 00000000 00000001 80860000 808492b4
87d75608 800e3028 00000100 00000000 00000001 80058c08 80870000 80870000
...
Call Trace:
[<800167b8>] clear_page+0x18/0x128
[<800e2860>] get_page_from_freelist+0xa94/0xdd4
[<800e3028>] __alloc_pages_nodemask+0xf4/0xbb8
[<800e3b08>] __get_free_pages+0x1c/0x58
[<80013430>] setup_zero_pages+0x3c/0xe4
[<80826eac>] mem_init+0x40/0x50
[<808219c0>] start_kernel+0x250/0x510
Code: cc9e0040 cc9e0060 cc9e0080 <ac800000> ac800004 ac800008 ac80000c 24840020 ac80fff0
I think this is just the early setup of the pages.
> >
> > 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-08 21:33 ` Chris Packham
@ 2020-04-09 4:03 ` Florian Fainelli
2020-04-09 4:50 ` Chris Packham
0 siblings, 1 reply; 7+ messages in thread
From: Florian Fainelli @ 2020-04-09 4:03 UTC (permalink / raw)
To: Chris Packham, jiaxun.yang
Cc: linux-kernel, Hamish Martin, linux-mips, devicetree
On 4/8/2020 2:33 PM, Chris Packham wrote:
> On Wed, 2020-04-08 at 15:29 +0800, Jiaxun Yang wrote:
>> On Wed, 8 Apr 2020 05:14:22 +0000
>> Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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?
>>
>
> I have but that didn't seem to help. As I understand it HIGHMEM is
> intended for situations when you have more physical RAM that can be
> addressed (e.g. >4GB on a 32-bit system).
On MIPS you may have to enable HIGHMEM as soon as you run out of virtual
kernel address space to map the entire amount of memory that is
populated AFAICT. The kernel has a little under 1GB of virtual address
space that can be mapped via the TLB since the first 512MB are occupied
by KSEG0/1.
>
>>>
>>> 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?
>
> Yes that's right it's the bootroms PA. I'm not intitentionally doing
> anything with it but maybe that's the problem.
If you were accessing this as a virtual address then it would be either
via KSEG0/1 and the addresses would be 0x1fc0_0000 + 0x8000_0000 or
0x1fc0_0000 + 0xa000_0000 but here it looks like the raw physical
address is being accessed which suggests the TLB is incorrectly
programmed somehow.
>
>>
>> Check the EPC of exception in vmlinux with addr2line may help. (Don't
>> forget to compile your kernel with debuginfo).
>>
>
> The full panic is
>
> CPU 0 Unable to handle kernel paging request at virtual address 1fc00000, epc == 800167b8, ra == 800e2860
> Oops[#1]:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.5.0-at1 #46
> $ 0 : 00000000 00000001 00000001 807e4270
> $ 4 : 1fc00000 00000000 1fc00f80 00000001
> $ 8 : 83e52a00 83e52a24 807f628c 8080fa00
> $12 : ffffffff 00000001 0000000b ffffffff
> $16 : 83e52a20 80000000 80870000 83e52a00
> $20 : 8080fdd4 807dde00 00000000 8080f9bc
> $24 : 8080fb68 ffffff7f
> $28 : 807dc000 807ddd38 83e52a00 800e2860
> Hi : 00000000
> Lo : 00000000
> epc : 800167b8 clear_page+0x18/0x128
> ra : 800e2860 get_page_from_freelist+0xa94/0xdd4
> Status: 11000002 KERNEL EXL
> Cause : 4080000c (ExcCode 03)
> BadVA : 1fc00000
> PrId : 00019749 (MIPS 74Kc)
> Modules linked in:
> Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=00000000)
> *HwTLS: e19f7d3a
> Stack : 807e0000 807dde98 80867cd8 80791814 00000001 80687974 807dde18 00000000
> 807f5ed0 807f628c 807f628c 8080fdd4 80870000 00000001 807e0000 00000044
> 0000005c 807dde00 00000000 00000001 80810000 8075a660 80870001 00000000
> 00000100 00000000 807e0000 00000000 00000000 00000001 80860000 808492b4
> 87d75608 800e3028 00000100 00000000 00000001 80058c08 80870000 80870000
> ...
> Call Trace:
> [<800167b8>] clear_page+0x18/0x128
> [<800e2860>] get_page_from_freelist+0xa94/0xdd4
> [<800e3028>] __alloc_pages_nodemask+0xf4/0xbb8
> [<800e3b08>] __get_free_pages+0x1c/0x58
> [<80013430>] setup_zero_pages+0x3c/0xe4
> [<80826eac>] mem_init+0x40/0x50
> [<808219c0>] start_kernel+0x250/0x510
> Code: cc9e0040 cc9e0060 cc9e0080 <ac800000> ac800004 ac800008 ac80000c 24840020 ac80fff0
>
> I think this is just the early setup of the pages.
>
>>>
>>> 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
--
Florian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-09 4:03 ` Florian Fainelli
@ 2020-04-09 4:50 ` Chris Packham
2020-04-09 5:06 ` Jiaxun Yang
0 siblings, 1 reply; 7+ messages in thread
From: Chris Packham @ 2020-04-09 4:50 UTC (permalink / raw)
To: jiaxun.yang, f.fainelli
Cc: linux-kernel, Hamish Martin, linux-mips, devicetree
On Wed, 2020-04-08 at 21:03 -0700, Florian Fainelli wrote:
>
> On 4/8/2020 2:33 PM, Chris Packham wrote:
> > On Wed, 2020-04-08 at 15:29 +0800, Jiaxun Yang wrote:
> > > On Wed, 8 Apr 2020 05:14:22 +0000
> > > Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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?
> > >
> >
> > I have but that didn't seem to help. As I understand it HIGHMEM is
> > intended for situations when you have more physical RAM that can be
> > addressed (e.g. >4GB on a 32-bit system).
>
> On MIPS you may have to enable HIGHMEM as soon as you run out of
> virtual
> kernel address space to map the entire amount of memory that is
> populated AFAICT. The kernel has a little under 1GB of virtual
> address
> space that can be mapped via the TLB since the first 512MB are
> occupied
> by KSEG0/1.
>
My adventures thus far with HIGHMEM have got as far as
This processor doesn't support highmem. 2490368k highmem ignored
Which I think has something to do with the max_low_pfn and highend_pfn
being different.
> >
> > > >
> > > > 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?
> >
> > Yes that's right it's the bootroms PA. I'm not intitentionally
> > doing
> > anything with it but maybe that's the problem.
>
> If you were accessing this as a virtual address then it would be
> either
> via KSEG0/1 and the addresses would be 0x1fc0_0000 + 0x8000_0000 or
> 0x1fc0_0000 + 0xa000_0000 but here it looks like the raw physical
> address is being accessed which suggests the TLB is incorrectly
> programmed somehow.
>
> >
> > >
> > > Check the EPC of exception in vmlinux with addr2line may help.
> > > (Don't
> > > forget to compile your kernel with debuginfo).
> > >
> >
> > The full panic is
> >
> > CPU 0 Unable to handle kernel paging request at virtual address
> > 1fc00000, epc == 800167b8, ra ==
> > 800e2860
> >
> >
> > Oops[#1]:
> >
> >
> >
> > CPU: 0 PID: 0 Comm: swapper Not tainted 5.5.0-at1
> > #46
> >
> >
> > $ 0 : 00000000 00000001 00000001
> > 807e4270
> >
> >
> >
> > $ 4 : 1fc00000 00000000 1fc00f80
> > 00000001
> >
> >
> >
> > $ 8 : 83e52a00 83e52a24 807f628c
> > 8080fa00
> >
> >
> >
> > $12 : ffffffff 00000001 0000000b
> > ffffffff
> >
> >
> >
> > $16 : 83e52a20 80000000 80870000
> > 83e52a00
> >
> >
> >
> > $20 : 8080fdd4 807dde00 00000000
> > 8080f9bc
> >
> >
> >
> > $24 : 8080fb68
> > ffffff7f
> >
> >
> >
> > $28 : 807dc000 807ddd38 83e52a00
> > 800e2860
> >
> >
> >
> > Hi :
> > 00000000
> >
> >
> >
> > Lo :
> > 00000000
> >
> >
> >
> > epc : 800167b8
> > clear_page+0x18/0x128
> >
> >
> >
> > ra : 800e2860
> > get_page_from_freelist+0xa94/0xdd4
> >
> >
> >
> > Status: 11000002 KERNEL
> > EXL
> >
> >
> >
> > Cause : 4080000c (ExcCode
> > 03)
> >
> >
> >
> > BadVA :
> > 1fc00000
> >
> >
> >
> > PrId : 00019749 (MIPS
> > 74Kc)
> >
> >
> >
> > Modules linked
> > in:
> >
> >
> >
> > Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval),
> > tls=00000000)
> >
> >
> > *HwTLS:
> > e19f7d3a
> >
> >
> >
> > Stack : 807e0000 807dde98 80867cd8 80791814 00000001 80687974
> > 807dde18
> > 00000000
> >
> >
> > 807f5ed0 807f628c 807f628c 8080fdd4 80870000 00000001
> > 807e0000
> > 00000044
> >
> >
> > 0000005c 807dde00 00000000 00000001 80810000 8075a660
> > 80870001
> > 00000000
> >
> >
> > 00000100 00000000 807e0000 00000000 00000000 00000001
> > 80860000
> > 808492b4
> >
> >
> > 87d75608 800e3028 00000100 00000000 00000001 80058c08
> > 80870000
> > 80870000
> >
> >
> > ...
> >
> >
> >
> > Call
> > Trace:
> >
> >
> >
> > [<800167b8>]
> > clear_page+0x18/0x128
> >
> >
> >
> > [<800e2860>]
> > get_page_from_freelist+0xa94/0xdd4
> >
> >
> >
> > [<800e3028>]
> > __alloc_pages_nodemask+0xf4/0xbb8
> >
> >
> >
> > [<800e3b08>]
> > __get_free_pages+0x1c/0x58
> >
> >
> >
> > [<80013430>]
> > setup_zero_pages+0x3c/0xe4
> >
> >
> >
> > [<80826eac>]
> > mem_init+0x40/0x50
> >
> >
> >
> > [<808219c0>]
> > start_kernel+0x250/0x510
> >
> >
> >
> > Code: cc9e0040 cc9e0060 cc9e0080 <ac800000>
> > ac800004 ac800008 ac80000c 24840020 ac80fff0
> >
> > I think this is just the early setup of the pages.
> >
> > > >
> > > > 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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dealing with holes in CPU address space
2020-04-09 4:50 ` Chris Packham
@ 2020-04-09 5:06 ` Jiaxun Yang
0 siblings, 0 replies; 7+ messages in thread
From: Jiaxun Yang @ 2020-04-09 5:06 UTC (permalink / raw)
To: Chris Packham
Cc: f.fainelli, linux-kernel, Hamish Martin, linux-mips, devicetree
On Thu, 9 Apr 2020 04:50:23 +0000
Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
> On Wed, 2020-04-08 at 21:03 -0700, Florian Fainelli wrote:
> >
> > On 4/8/2020 2:33 PM, Chris Packham wrote:
> > > On Wed, 2020-04-08 at 15:29 +0800, Jiaxun Yang wrote:
> > > > On Wed, 8 Apr 2020 05:14:22 +0000
> > > > Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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?
> > > >
> > >
> > > I have but that didn't seem to help. As I understand it HIGHMEM is
> > > intended for situations when you have more physical RAM that can
> > > be addressed (e.g. >4GB on a 32-bit system).
> >
> > On MIPS you may have to enable HIGHMEM as soon as you run out of
> > virtual
> > kernel address space to map the entire amount of memory that is
> > populated AFAICT. The kernel has a little under 1GB of virtual
> > address
> > space that can be mapped via the TLB since the first 512MB are
> > occupied
> > by KSEG0/1.
> >
>
> My adventures thus far with HIGHMEM have got as far as
>
> This processor doesn't support highmem. 2490368k highmem ignored
>
> Which I think has something to do with the max_low_pfn and highend_pfn
> being different.
>
You might have cpu_has_dc_aliases defined.
HIGHMEM is unsafe on these systems due to Cache Alias issue.
Here is a comment in mips/kernel/cpu-probe.c:
/*
* Early versions of the 74K do not update the cache tags on a
* vtag miss/ptag hit which can occur in the case of KSEG0/KUSEG
* aliases. In this case it is better to treat the cache as always
* having aliases. Also disable the synonym tag update feature
* where available. In this case no opportunistic tag update will
* happen where a load causes a virtual address miss but a physical
* address hit during a D-cache look-up.
*/
Probably you system have this kind of issue?
You can determine waysize of D-Cache and set a larger pagesize.
--
Jiaxun Yang
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-04-09 5:07 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-08 5:14 Dealing with holes in CPU address space Chris Packham
2020-04-08 7:29 ` Jiaxun Yang
2020-04-08 21:33 ` Chris Packham
2020-04-09 4:03 ` Florian Fainelli
2020-04-09 4:50 ` Chris Packham
2020-04-09 5:06 ` Jiaxun Yang
2020-04-08 20:07 ` Florian Fainelli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).