* Octeon CN5010 - Kernel 4.4.92
@ 2017-10-31 16:54 Gabriel Kuri
2017-10-31 17:22 ` David Daney
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 16:54 UTC (permalink / raw)
To: linux-mips
I'm working on getting Kernel 4.4.92 running on a board with a CN5010
processor and 64MB RAM.
The issue I'm running in to is the kernel memory map seems to be
messed up. It's only recognizing 46MB of RAM of the 64MB and only 21MB
are usable of the 46MB it recognizes. Not sure what is wrong, but
could someone give me some guidance on where I could troubleshoot?
Thanks
Below is some relevant kernel output at boot ...
ELF file is 64 bit
Allocated memory for ELF segment: addr: 0x1100000, size 0x16189c8
Loading .text @ 0x81100000 (0x355290 bytes)
Loading __ex_table @ 0x81455290 (0x57c0 bytes)
Loading .rodata @ 0x8145b000 (0xca300 bytes)
Loading .pci_fixup @ 0x81525300 (0x1db8 bytes)
Loading __ksymtab @ 0x815270b8 (0xbdd0 bytes)
Loading __ksymtab_gpl @ 0x81532e88 (0x6710 bytes)
Loading __ksymtab_strings @ 0x81539598 (0x14cfd bytes)
Loading __param @ 0x8154e298 (0x988 bytes)
Clearing __modver @ 0x8154ec20 (0x3e0 bytes)
Loading .data @ 0x8154f000 (0x3cad8 bytes)
Loading .data..page_aligned @ 0x8158c000 (0x4000 bytes)
Loading .init.text @ 0x81590000 (0x2660c bytes)
Loading .init.data @ 0x815b6620 (0x11308 bytes)
Loading .data..percpu @ 0x815c8000 (0x3eb0 bytes)
Clearing .bss @ 0x816d0000 (0x10489c8 bytes)
## Loading OS kernel with entry point: 0x81107920 ...
Bootloader: Done loading app on coremask: 0x1
[ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
(LEDE GCC 5.4.0 r3560-79f57e422d) ) #0 SMP Tue7
[ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
[ 0.000000] Checking for the multiply/shift bug... no.
[ 0.000000] Checking for the daddiu bug... no.
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
[ 0.000000] memory: 00000000016189c8 @ 0000000001100000 (usable)
[ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
[ 0.000000] Using internal Device Tree.
[ 0.000000] software IO TLB [mem 0x0280b000-0x0284b000] (0MB)
mapped at [800000000280b000-800000000284afff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000001100000-0x00000000efffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000001100000-0x0000000002717fff]
[ 0.000000] node 0: [mem 0x0000000002800000-0x0000000003ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000001100000-0x0000000003ffffff]
[ 0.000000] Primary instruction cache 32kB, virtually tagged, 4
way, 64 sets, linesize 128 bytes.
[ 0.000000] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
[ 0.000000] PERCPU: Embedded 13 pages/cpu @8000000002858000 s16048
r8192 d29008 u53248
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 11635
[ 0.000000] Kernel command line: bootoctlinux bed00000
console=ttyS0,9600 bootver=APBoot 1.0.8.3/20343
[ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 20468K/47200K available (3411K kernel code,
261K rwdata, 976K rodata, 1280K init, 16674K bss, )
[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] CONFIG_RCU_FANOUT set to non-default value of 32
[ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
Some relevant output once booted ...
# cat /proc/iomem
01100000-027189c7 : System RAM
01100000-0145528f : Kernel code
01455290-0158ffff : Kernel data
02800000-03ffffff : System RAM
1f400000-1fbfffff : 1f400000.nor
1070000000800-10700000008ff : /soc@0/gpio-controller@1070000000800
1180000000800-118000000083f : serial
1180000000c00-1180000000c3f : serial
1180000001000-11800000011ff : /soc@0/i2c@1180000001000
1180000001800-118000000183f : /soc@0/mdio@1180000001800
1180040000000-118004000000f : octeon_rng
11b00f0000000-11b0130000000 : Octeon PCI MEM
11b00f0000000-11b00f000ffff : 0000:00:03.0
11b00f0010000-11b00f001ffff : 0000:00:04.0
1400000000000-1400000000007 : octeon_rng
# free -m
total used free shared buffers cached
Mem: 21748 19616 2132 32 1012 2196
-/+ buffers/cache: 16408 5340
Swap: 0 0 0
# cat /proc/cpuinfo
system type : CN3010_EVB_HS5 (CN5010p1.1-500-SCP)
machine : Unknown
processor : 0
cpu model : Cavium Octeon+ V0.1
BogoMIPS : 1000.00
wait instruction : yes
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : yes
hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb]
isa : mips1 mips2 mips3 mips4 mips5 mips64r2
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
# cat /proc/meminfo
MemTotal: 21748 kB
MemFree: 2148 kB
MemAvailable: 3256 kB
Buffers: 1012 kB
Cached: 2196 kB
SwapCached: 0 kB
Active: 3168 kB
Inactive: 656 kB
Active(anon): 644 kB
Inactive(anon): 4 kB
Active(file): 2524 kB
Inactive(file): 652 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 628 kB
Mapped: 1320 kB
Shmem: 32 kB
Slab: 8416 kB
SReclaimable: 984 kB
SUnreclaim: 7432 kB
KernelStack: 720 kB
PageTables: 88 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 10872 kB
Committed_AS: 1620 kB
VmallocTotal: 1069547512 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 16:54 Octeon CN5010 - Kernel 4.4.92 Gabriel Kuri
@ 2017-10-31 17:22 ` David Daney
2017-10-31 17:26 ` Gabriel Kuri
2017-10-31 20:15 ` Gabriel Kuri
0 siblings, 2 replies; 10+ messages in thread
From: David Daney @ 2017-10-31 17:22 UTC (permalink / raw)
To: Gabriel Kuri, linux-mips
On 10/31/2017 09:54 AM, Gabriel Kuri wrote:
> I'm working on getting Kernel 4.4.92 running on a board with a CN5010
> processor and 64MB RAM.
>
> The issue I'm running in to is the kernel memory map seems to be
> messed up. It's only recognizing 46MB of RAM of the 64MB and only 21MB
> are usable of the 46MB it recognizes. Not sure what is wrong, but
> could someone give me some guidance on where I could troubleshoot?
>
Look at the command line passed from u-boot.
With some kernels, not all memory is allocated to the kernel unless you
pass "mem=0" on the command line.
Since special Octeon code consumes the "mem=..." parameter, it isn't
available in userspace after the kernel is booted, so you must look at
what is done in u-boot.
> Thanks
>
>
> Below is some relevant kernel output at boot ...
>
>
> ELF file is 64 bit
> Allocated memory for ELF segment: addr: 0x1100000, size 0x16189c8
> Loading .text @ 0x81100000 (0x355290 bytes)
> Loading __ex_table @ 0x81455290 (0x57c0 bytes)
> Loading .rodata @ 0x8145b000 (0xca300 bytes)
> Loading .pci_fixup @ 0x81525300 (0x1db8 bytes)
> Loading __ksymtab @ 0x815270b8 (0xbdd0 bytes)
> Loading __ksymtab_gpl @ 0x81532e88 (0x6710 bytes)
> Loading __ksymtab_strings @ 0x81539598 (0x14cfd bytes)
> Loading __param @ 0x8154e298 (0x988 bytes)
> Clearing __modver @ 0x8154ec20 (0x3e0 bytes)
> Loading .data @ 0x8154f000 (0x3cad8 bytes)
> Loading .data..page_aligned @ 0x8158c000 (0x4000 bytes)
> Loading .init.text @ 0x81590000 (0x2660c bytes)
> Loading .init.data @ 0x815b6620 (0x11308 bytes)
> Loading .data..percpu @ 0x815c8000 (0x3eb0 bytes)
> Clearing .bss @ 0x816d0000 (0x10489c8 bytes)
> ## Loading OS kernel with entry point: 0x81107920 ...
> Bootloader: Done loading app on coremask: 0x1
> [ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
> (LEDE GCC 5.4.0 r3560-79f57e422d) ) #0 SMP Tue7
> [ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
> [ 0.000000] bootconsole [early0] enabled
> [ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
> [ 0.000000] Checking for the multiply/shift bug... no.
> [ 0.000000] Checking for the daddiu bug... no.
> [ 0.000000] Determined physical RAM map:
> [ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
> [ 0.000000] memory: 00000000016189c8 @ 0000000001100000 (usable)
> [ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
> [ 0.000000] Using internal Device Tree.
> [ 0.000000] software IO TLB [mem 0x0280b000-0x0284b000] (0MB)
> mapped at [800000000280b000-800000000284afff]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000001100000-0x00000000efffffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000001100000-0x0000000002717fff]
> [ 0.000000] node 0: [mem 0x0000000002800000-0x0000000003ffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000001100000-0x0000000003ffffff]
> [ 0.000000] Primary instruction cache 32kB, virtually tagged, 4
> way, 64 sets, linesize 128 bytes.
> [ 0.000000] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
> [ 0.000000] PERCPU: Embedded 13 pages/cpu @8000000002858000 s16048
> r8192 d29008 u53248
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 11635
> [ 0.000000] Kernel command line: bootoctlinux bed00000
> console=ttyS0,9600 bootver=APBoot 1.0.8.3/20343
> [ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
> [ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> [ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 20468K/47200K available (3411K kernel code,
> 261K rwdata, 976K rodata, 1280K init, 16674K bss, )
> [ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] Hierarchical RCU implementation.
> [ 0.000000] CONFIG_RCU_FANOUT set to non-default value of 32
> [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>
>
>
> Some relevant output once booted ...
>
> # cat /proc/iomem
> 01100000-027189c7 : System RAM
> 01100000-0145528f : Kernel code
> 01455290-0158ffff : Kernel data
> 02800000-03ffffff : System RAM
> 1f400000-1fbfffff : 1f400000.nor
> 1070000000800-10700000008ff : /soc@0/gpio-controller@1070000000800
> 1180000000800-118000000083f : serial
> 1180000000c00-1180000000c3f : serial
> 1180000001000-11800000011ff : /soc@0/i2c@1180000001000
> 1180000001800-118000000183f : /soc@0/mdio@1180000001800
> 1180040000000-118004000000f : octeon_rng
> 11b00f0000000-11b0130000000 : Octeon PCI MEM
> 11b00f0000000-11b00f000ffff : 0000:00:03.0
> 11b00f0010000-11b00f001ffff : 0000:00:04.0
> 1400000000000-1400000000007 : octeon_rng
>
>
> # free -m
> total used free shared buffers cached
> Mem: 21748 19616 2132 32 1012 2196
> -/+ buffers/cache: 16408 5340
> Swap: 0 0 0
>
> # cat /proc/cpuinfo
> system type : CN3010_EVB_HS5 (CN5010p1.1-500-SCP)
> machine : Unknown
> processor : 0
> cpu model : Cavium Octeon+ V0.1
> BogoMIPS : 1000.00
> wait instruction : yes
> microsecond timers : yes
> tlb_entries : 64
> extra interrupt vector : yes
> hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb]
> isa : mips1 mips2 mips3 mips4 mips5 mips64r2
> ASEs implemented :
> shadow register sets : 1
> kscratch registers : 0
> package : 0
> core : 0
> VCED exceptions : not available
> VCEI exceptions : not available
>
>
> # cat /proc/meminfo
> MemTotal: 21748 kB
> MemFree: 2148 kB
> MemAvailable: 3256 kB
> Buffers: 1012 kB
> Cached: 2196 kB
> SwapCached: 0 kB
> Active: 3168 kB
> Inactive: 656 kB
> Active(anon): 644 kB
> Inactive(anon): 4 kB
> Active(file): 2524 kB
> Inactive(file): 652 kB
> Unevictable: 0 kB
> Mlocked: 0 kB
> SwapTotal: 0 kB
> SwapFree: 0 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 628 kB
> Mapped: 1320 kB
> Shmem: 32 kB
> Slab: 8416 kB
> SReclaimable: 984 kB
> SUnreclaim: 7432 kB
> KernelStack: 720 kB
> PageTables: 88 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 10872 kB
> Committed_AS: 1620 kB
> VmallocTotal: 1069547512 kB
> VmallocUsed: 0 kB
> VmallocChunk: 0 kB
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 17:22 ` David Daney
@ 2017-10-31 17:26 ` Gabriel Kuri
2017-10-31 20:15 ` Gabriel Kuri
1 sibling, 0 replies; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 17:26 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
I'm passing the command line from u-boot. So should I try to set mem=0
and see what happens?
On Tue, Oct 31, 2017 at 10:22 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 10/31/2017 09:54 AM, Gabriel Kuri wrote:
>>
>> I'm working on getting Kernel 4.4.92 running on a board with a CN5010
>> processor and 64MB RAM.
>>
>> The issue I'm running in to is the kernel memory map seems to be
>> messed up. It's only recognizing 46MB of RAM of the 64MB and only 21MB
>> are usable of the 46MB it recognizes. Not sure what is wrong, but
>> could someone give me some guidance on where I could troubleshoot?
>>
>
> Look at the command line passed from u-boot.
>
> With some kernels, not all memory is allocated to the kernel unless you pass
> "mem=0" on the command line.
>
> Since special Octeon code consumes the "mem=..." parameter, it isn't
> available in userspace after the kernel is booted, so you must look at what
> is done in u-boot.
>
>
>
>> Thanks
>>
>>
>> Below is some relevant kernel output at boot ...
>>
>>
>> ELF file is 64 bit
>> Allocated memory for ELF segment: addr: 0x1100000, size 0x16189c8
>> Loading .text @ 0x81100000 (0x355290 bytes)
>> Loading __ex_table @ 0x81455290 (0x57c0 bytes)
>> Loading .rodata @ 0x8145b000 (0xca300 bytes)
>> Loading .pci_fixup @ 0x81525300 (0x1db8 bytes)
>> Loading __ksymtab @ 0x815270b8 (0xbdd0 bytes)
>> Loading __ksymtab_gpl @ 0x81532e88 (0x6710 bytes)
>> Loading __ksymtab_strings @ 0x81539598 (0x14cfd bytes)
>> Loading __param @ 0x8154e298 (0x988 bytes)
>> Clearing __modver @ 0x8154ec20 (0x3e0 bytes)
>> Loading .data @ 0x8154f000 (0x3cad8 bytes)
>> Loading .data..page_aligned @ 0x8158c000 (0x4000 bytes)
>> Loading .init.text @ 0x81590000 (0x2660c bytes)
>> Loading .init.data @ 0x815b6620 (0x11308 bytes)
>> Loading .data..percpu @ 0x815c8000 (0x3eb0 bytes)
>> Clearing .bss @ 0x816d0000 (0x10489c8 bytes)
>> ## Loading OS kernel with entry point: 0x81107920 ...
>> Bootloader: Done loading app on coremask: 0x1
>> [ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
>> (LEDE GCC 5.4.0 r3560-79f57e422d) ) #0 SMP Tue7
>> [ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
>> [ 0.000000] bootconsole [early0] enabled
>> [ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
>> [ 0.000000] Checking for the multiply/shift bug... no.
>> [ 0.000000] Checking for the daddiu bug... no.
>> [ 0.000000] Determined physical RAM map:
>> [ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
>> [ 0.000000] memory: 00000000016189c8 @ 0000000001100000 (usable)
>> [ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
>> [ 0.000000] Using internal Device Tree.
>> [ 0.000000] software IO TLB [mem 0x0280b000-0x0284b000] (0MB)
>> mapped at [800000000280b000-800000000284afff]
>> [ 0.000000] Zone ranges:
>> [ 0.000000] DMA32 [mem 0x0000000001100000-0x00000000efffffff]
>> [ 0.000000] Normal empty
>> [ 0.000000] Movable zone start for each node
>> [ 0.000000] Early memory node ranges
>> [ 0.000000] node 0: [mem 0x0000000001100000-0x0000000002717fff]
>> [ 0.000000] node 0: [mem 0x0000000002800000-0x0000000003ffffff]
>> [ 0.000000] Initmem setup node 0 [mem
>> 0x0000000001100000-0x0000000003ffffff]
>> [ 0.000000] Primary instruction cache 32kB, virtually tagged, 4
>> way, 64 sets, linesize 128 bytes.
>> [ 0.000000] Primary data cache 16kB, 64-way, 2 sets, linesize 128
>> bytes.
>> [ 0.000000] PERCPU: Embedded 13 pages/cpu @8000000002858000 s16048
>> r8192 d29008 u53248
>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 11635
>> [ 0.000000] Kernel command line: bootoctlinux bed00000
>> console=ttyS0,9600 bootver=APBoot 1.0.8.3/20343
>> [ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
>> [ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536
>> bytes)
>> [ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768
>> bytes)
>> [ 0.000000] Memory: 20468K/47200K available (3411K kernel code,
>> 261K rwdata, 976K rodata, 1280K init, 16674K bss, )
>> [ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> [ 0.000000] Hierarchical RCU implementation.
>> [ 0.000000] CONFIG_RCU_FANOUT set to non-default value of 32
>> [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
>> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16,
>> nr_cpu_ids=1
>>
>>
>>
>> Some relevant output once booted ...
>>
>> # cat /proc/iomem
>> 01100000-027189c7 : System RAM
>> 01100000-0145528f : Kernel code
>> 01455290-0158ffff : Kernel data
>> 02800000-03ffffff : System RAM
>> 1f400000-1fbfffff : 1f400000.nor
>> 1070000000800-10700000008ff : /soc@0/gpio-controller@1070000000800
>> 1180000000800-118000000083f : serial
>> 1180000000c00-1180000000c3f : serial
>> 1180000001000-11800000011ff : /soc@0/i2c@1180000001000
>> 1180000001800-118000000183f : /soc@0/mdio@1180000001800
>> 1180040000000-118004000000f : octeon_rng
>> 11b00f0000000-11b0130000000 : Octeon PCI MEM
>> 11b00f0000000-11b00f000ffff : 0000:00:03.0
>> 11b00f0010000-11b00f001ffff : 0000:00:04.0
>> 1400000000000-1400000000007 : octeon_rng
>>
>>
>> # free -m
>> total used free shared buffers cached
>> Mem: 21748 19616 2132 32 1012 2196
>> -/+ buffers/cache: 16408 5340
>> Swap: 0 0 0
>>
>> # cat /proc/cpuinfo
>> system type : CN3010_EVB_HS5 (CN5010p1.1-500-SCP)
>> machine : Unknown
>> processor : 0
>> cpu model : Cavium Octeon+ V0.1
>> BogoMIPS : 1000.00
>> wait instruction : yes
>> microsecond timers : yes
>> tlb_entries : 64
>> extra interrupt vector : yes
>> hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc,
>> 0x0ffb]
>> isa : mips1 mips2 mips3 mips4 mips5 mips64r2
>> ASEs implemented :
>> shadow register sets : 1
>> kscratch registers : 0
>> package : 0
>> core : 0
>> VCED exceptions : not available
>> VCEI exceptions : not available
>>
>>
>> # cat /proc/meminfo
>> MemTotal: 21748 kB
>> MemFree: 2148 kB
>> MemAvailable: 3256 kB
>> Buffers: 1012 kB
>> Cached: 2196 kB
>> SwapCached: 0 kB
>> Active: 3168 kB
>> Inactive: 656 kB
>> Active(anon): 644 kB
>> Inactive(anon): 4 kB
>> Active(file): 2524 kB
>> Inactive(file): 652 kB
>> Unevictable: 0 kB
>> Mlocked: 0 kB
>> SwapTotal: 0 kB
>> SwapFree: 0 kB
>> Dirty: 0 kB
>> Writeback: 0 kB
>> AnonPages: 628 kB
>> Mapped: 1320 kB
>> Shmem: 32 kB
>> Slab: 8416 kB
>> SReclaimable: 984 kB
>> SUnreclaim: 7432 kB
>> KernelStack: 720 kB
>> PageTables: 88 kB
>> NFS_Unstable: 0 kB
>> Bounce: 0 kB
>> WritebackTmp: 0 kB
>> CommitLimit: 10872 kB
>> Committed_AS: 1620 kB
>> VmallocTotal: 1069547512 kB
>> VmallocUsed: 0 kB
>> VmallocChunk: 0 kB
>>
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 17:22 ` David Daney
2017-10-31 17:26 ` Gabriel Kuri
@ 2017-10-31 20:15 ` Gabriel Kuri
2017-10-31 20:21 ` David Daney
1 sibling, 1 reply; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 20:15 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
> With some kernels, not all memory is allocated to the kernel unless you pass
> "mem=0" on the command line.
>
> Since special Octeon code consumes the "mem=..." parameter, it isn't
> available in userspace after the kernel is booted, so you must look at what
> is done in u-boot.
Well, that didn't work out too well (see below).
Do I need to tweak the device tree or
'arch/mips/cavium-octeon/setup.c' for my specific board?
Allocated memory for ELF segment: addr: 0x1100000, size 0x2628a48
Loading .text @ 0x81100000 (0x35ca1c bytes)
Loading __ex_table @ 0x8145ca20 (0x57c0 bytes)
Loading .rodata @ 0x81463000 (0xca880 bytes)
Loading .pci_fixup @ 0x8152d880 (0x1db8 bytes)
Loading __ksymtab @ 0x8152f638 (0xbdd0 bytes)
Loading __ksymtab_gpl @ 0x8153b408 (0x6710 bytes)
Loading __ksymtab_strings @ 0x81541b18 (0x14cfd bytes)
Loading __param @ 0x81556818 (0x988 bytes)
Clearing __modver @ 0x815571a0 (0xe60 bytes)
Loading .data @ 0x81558000 (0x3bbd8 bytes)
Loading .data..page_aligned @ 0x81594000 (0x4000 bytes)
Loading .init.text @ 0x81598000 (0x278b4 bytes)
Loading .init.data @ 0x815bf8c0 (0x12390 bytes)
Loading .data..percpu @ 0x815d2000 (0x3eb0 bytes)
Clearing .bss @ 0x816e0000 (0x2048a48 bytes)
## Loading OS kernel with entry point: 0x81107920 ...
Bootloader: Done loading app on coremask: 0x1
[ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
(LEDE GCC 5.4.0 r3560-79f57e4227
[ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
[ 0.000000] Checking for the multiply/shift bug... no.
[ 0.000000] Checking for the daddiu bug... no.
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000000800000 @ 0000000003800000 (usable)
[ 0.000000] memory: 0000000002628a48 @ 0000000001100000 (usable)
[ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
[ 0.000000] Using internal Device Tree.
[ 0.000000] bootmem alloc of 8388608 bytes failed!
[ 0.000000] Kernel panic - not syncing: Out of memory
[ 0.000000] Rebooting in 1 seconds..
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 20:15 ` Gabriel Kuri
@ 2017-10-31 20:21 ` David Daney
2017-10-31 21:31 ` Gabriel Kuri
0 siblings, 1 reply; 10+ messages in thread
From: David Daney @ 2017-10-31 20:21 UTC (permalink / raw)
To: Gabriel Kuri; +Cc: linux-mips
On 10/31/2017 01:15 PM, Gabriel Kuri wrote:
>> With some kernels, not all memory is allocated to the kernel unless you pass
>> "mem=0" on the command line.
>>
>> Since special Octeon code consumes the "mem=..." parameter, it isn't
>> available in userspace after the kernel is booted, so you must look at what
>> is done in u-boot.
>
> Well, that didn't work out too well (see below).
>
> Do I need to tweak the device tree or
> 'arch/mips/cavium-octeon/setup.c' for my specific board?
What board it it?
>
> Allocated memory for ELF segment: addr: 0x1100000, size 0x2628a48
Why not show the entire logs we could know what you are doing in u-boot?
> Loading .text @ 0x81100000 (0x35ca1c bytes)
> Loading __ex_table @ 0x8145ca20 (0x57c0 bytes)
Archaic version of u-boot being used...
> Loading .rodata @ 0x81463000 (0xca880 bytes)
> Loading .pci_fixup @ 0x8152d880 (0x1db8 bytes)
> Loading __ksymtab @ 0x8152f638 (0xbdd0 bytes)
> Loading __ksymtab_gpl @ 0x8153b408 (0x6710 bytes)
> Loading __ksymtab_strings @ 0x81541b18 (0x14cfd bytes)
> Loading __param @ 0x81556818 (0x988 bytes)
> Clearing __modver @ 0x815571a0 (0xe60 bytes)
> Loading .data @ 0x81558000 (0x3bbd8 bytes)
> Loading .data..page_aligned @ 0x81594000 (0x4000 bytes)
> Loading .init.text @ 0x81598000 (0x278b4 bytes)
> Loading .init.data @ 0x815bf8c0 (0x12390 bytes)
> Loading .data..percpu @ 0x815d2000 (0x3eb0 bytes)
> Clearing .bss @ 0x816e0000 (0x2048a48 bytes)
> ## Loading OS kernel with entry point: 0x81107920 ...
> Bootloader: Done loading app on coremask: 0x1
> [ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
> (LEDE GCC 5.4.0 r3560-79f57e4227
> [ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
> [ 0.000000] bootconsole [early0] enabled
> [ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
> [ 0.000000] Checking for the multiply/shift bug... no.
> [ 0.000000] Checking for the daddiu bug... no.
> [ 0.000000] Determined physical RAM map:
> [ 0.000000] memory: 0000000000800000 @ 0000000003800000 (usable)
> [ 0.000000] memory: 0000000002628a48 @ 0000000001100000 (usable)
> [ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
> [ 0.000000] Using internal Device Tree.
> [ 0.000000] bootmem alloc of 8388608 bytes failed!
> [ 0.000000] Kernel panic - not syncing: Out of memory
> [ 0.000000] Rebooting in 1 seconds..
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 20:21 ` David Daney
@ 2017-10-31 21:31 ` Gabriel Kuri
2017-10-31 21:55 ` David Daney
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 21:31 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
> What board it it?
It's an old Aruba AP-125 wireless access point. We have decommissioned
hundreds of these APs and I'd like to integrate them in to a
University course on embedded operating systems to make use of them.
> Why not show the entire logs we could know what you are doing in u-boot?
Here you go ...
APBoot 1.0.8.3 (build 20343)
Built: 2008-12-27 at 17:03:46
Model: AP-12x
CPU: OCTEON CN50XX-SCP revision: 1
Clock: 500 MHz, DDR clock: 333 MHz (666 Mhz data rate)
Power: POE
POST1: passed
POST2: passed
DRAM: 64 MB
Flash: 16 MB
Clear: done
BIST: passed
PCI: PCI 32-bit; scanning bus 0 ...
dev fn venID devID class rev MBAR0 MBAR1 MBAR2 MBAR3
03 00 168c ff1d 00002 01 80000000 00000000 00000000 00000000
04 00 168c ff1d 00002 01 80010000 00000000 00000000 00000000
Net: en0, en1
Radio: ar9160#0, ar9160#1
apboot> bootoct bed00000 mem=0 console=ttyS0,9600
argv[2]: mem=0
argv[3]: console=ttyS0,9600
ELF file is 64 bit
Allocated memory for ELF segment: addr: 0x1100000, size 0x2628a48
Loading .text @ 0x81100000 (0x35ca1c bytes)
Loading __ex_table @ 0x8145ca20 (0x57c0 bytes)
Loading .rodata @ 0x81463000 (0xca880 bytes)
Loading .pci_fixup @ 0x8152d880 (0x1db8 bytes)
Loading __ksymtab @ 0x8152f638 (0xbdd0 bytes)
Loading __ksymtab_gpl @ 0x8153b408 (0x6710 bytes)
Loading __ksymtab_strings @ 0x81541b18 (0x14cfd bytes)
Loading __param @ 0x81556818 (0x988 bytes)
Clearing __modver @ 0x815571a0 (0xe60 bytes)
Loading .data @ 0x81558000 (0x3bbd8 bytes)
Loading .data..page_aligned @ 0x81594000 (0x4000 bytes)
Loading .init.text @ 0x81598000 (0x278b4 bytes)
Loading .init.data @ 0x815bf8c0 (0x12390 bytes)
Loading .data..percpu @ 0x815d2000 (0x3eb0 bytes)
Clearing .bss @ 0x816e0000 (0x2048a48 bytes)
## Loading OS kernel with entry point: 0x81107920 ...
Bootloader: Done loading app on coremask: 0x1
[ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
(LEDE GCC 5.4.0 r3560-79f57e4227
[ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
[ 0.000000] Checking for the multiply/shift bug... no.
[ 0.000000] Checking for the daddiu bug... no.
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000000800000 @ 0000000003800000 (usable)
[ 0.000000] memory: 0000000002628a48 @ 0000000001100000 (usable)
[ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
[ 0.000000] Using internal Device Tree.
[ 0.000000] bootmem alloc of 8388608 bytes failed!
[ 0.000000] Kernel panic - not syncing: Out of memory
[ 0.000000] Rebooting in 1 seconds..
> Archaic version of u-boot being used...
Yeah, it's Aruba's old version of U-Boot, which they have called
"APBoot". I was trying to avoid compiling a new version of U-Boot for
these boards.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 21:31 ` Gabriel Kuri
@ 2017-10-31 21:55 ` David Daney
2017-10-31 23:19 ` Gabriel Kuri
0 siblings, 1 reply; 10+ messages in thread
From: David Daney @ 2017-10-31 21:55 UTC (permalink / raw)
To: Gabriel Kuri; +Cc: linux-mips
On 10/31/2017 02:31 PM, Gabriel Kuri wrote:
>> What board it it?
>
> It's an old Aruba AP-125 wireless access point. We have decommissioned
> hundreds of these APs and I'd like to integrate them in to a
> University course on embedded operating systems to make use of them.
Interesting. It sounds like a fun project.
>
>> Why not show the entire logs we could know what you are doing in u-boot?
>
> Here you go ...
>
> APBoot 1.0.8.3 (build 20343)
> Built: 2008-12-27 at 17:03:46
>
> Model: AP-12x
> CPU: OCTEON CN50XX-SCP revision: 1
> Clock: 500 MHz, DDR clock: 333 MHz (666 Mhz data rate)
> Power: POE
> POST1: passed
> POST2: passed
> DRAM: 64 MB
> Flash: 16 MB
> Clear: done
> BIST: passed
> PCI: PCI 32-bit; scanning bus 0 ...
> dev fn venID devID class rev MBAR0 MBAR1 MBAR2 MBAR3
> 03 00 168c ff1d 00002 01 80000000 00000000 00000000 00000000
> 04 00 168c ff1d 00002 01 80010000 00000000 00000000 00000000
> Net: en0, en1
> Radio: ar9160#0, ar9160#1
> apboot> bootoct bed00000 mem=0 console=ttyS0,9600
Try:
> bootoctlinux $(loadaddr) endbootargs mem=0 console=ttyS0,9600
When booting Octeon Linux, it is important to use the bootoctlinux command.
> argv[2]: mem=0
> argv[3]: console=ttyS0,9600
> ELF file is 64 bit
> Allocated memory for ELF segment: addr: 0x1100000, size 0x2628a48
> Loading .text @ 0x81100000 (0x35ca1c bytes)
> Loading __ex_table @ 0x8145ca20 (0x57c0 bytes)
> Loading .rodata @ 0x81463000 (0xca880 bytes)
> Loading .pci_fixup @ 0x8152d880 (0x1db8 bytes)
> Loading __ksymtab @ 0x8152f638 (0xbdd0 bytes)
> Loading __ksymtab_gpl @ 0x8153b408 (0x6710 bytes)
> Loading __ksymtab_strings @ 0x81541b18 (0x14cfd bytes)
> Loading __param @ 0x81556818 (0x988 bytes)
> Clearing __modver @ 0x815571a0 (0xe60 bytes)
> Loading .data @ 0x81558000 (0x3bbd8 bytes)
> Loading .data..page_aligned @ 0x81594000 (0x4000 bytes)
> Loading .init.text @ 0x81598000 (0x278b4 bytes)
> Loading .init.data @ 0x815bf8c0 (0x12390 bytes)
> Loading .data..percpu @ 0x815d2000 (0x3eb0 bytes)
> Clearing .bss @ 0x816e0000 (0x2048a48 bytes)
> ## Loading OS kernel with entry point: 0x81107920 ...
> Bootloader: Done loading app on coremask: 0x1
> [ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
> (LEDE GCC 5.4.0 r3560-79f57e4227
> [ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
> [ 0.000000] bootconsole [early0] enabled
> [ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
> [ 0.000000] Checking for the multiply/shift bug... no.
> [ 0.000000] Checking for the daddiu bug... no.
> [ 0.000000] Determined physical RAM map:
> [ 0.000000] memory: 0000000000800000 @ 0000000003800000 (usable)
> [ 0.000000] memory: 0000000002628a48 @ 0000000001100000 (usable)
> [ 0.000000] Wasting 243712 bytes for tracking 4352 unused pages
> [ 0.000000] Using internal Device Tree.
> [ 0.000000] bootmem alloc of 8388608 bytes failed!
> [ 0.000000] Kernel panic - not syncing: Out of memory
> [ 0.000000] Rebooting in 1 seconds..
>
>
>> Archaic version of u-boot being used...
>
> Yeah, it's Aruba's old version of U-Boot, which they have called
> "APBoot". I was trying to avoid compiling a new version of U-Boot for
> these boards.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 21:55 ` David Daney
@ 2017-10-31 23:19 ` Gabriel Kuri
2017-10-31 23:42 ` Gabriel Kuri
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 23:19 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
> Interesting. It sounds like a fun project.
Yep, should be fun.
> Try:
>
> > bootoctlinux $(loadaddr) endbootargs mem=0 console=ttyS0,9600
>
>
> When booting Octeon Linux, it is important to use the bootoctlinux command.
I had to hard code the command line before compiling the kernel, it
wouldn't take the argument in their U-Boot.
But now it panics saying "Incorrect memory mapping". See below.
It seems it thinks it has 0 RAM at location 0x0 according to the output below.
Is there anyway to tell it via the command line to use 64M @ 0x0 ?
APBoot 1.0.8.3 (build 20343)
Built: 2008-12-27 at 17:03:46
Model: AP-12x
CPU: OCTEON CN50XX-SCP revision: 1
Clock: 500 MHz, DDR clock: 333 MHz (666 Mhz data rate)
Power: POE
POST1: passed
POST2: passed
DRAM: 64 MB
Flash: 16 MB
Clear: done
BIST: passed
PCI: PCI 32-bit; scanning bus 0 ...
dev fn venID devID class rev MBAR0 MBAR1 MBAR2 MBAR3
03 00 168c ff1d 00002 01 80000000 00000000 00000000 00000000
04 00 168c ff1d 00002 01 80010000 00000000 00000000 00000000
Net: en0, en1
Radio: ar9160#0, ar9160#1
apboot> bootoctlinux bed00000
ELF file is 64 bit
Allocated memory for ELF segment: addr: 0x1100000, size 0x16186c8
Loading .text @ 0x81100000 (0x34e614 bytes)
Loading __ex_table @ 0x8144e620 (0x57c0 bytes)
Loading .rodata @ 0x81454000 (0xc8280 bytes)
Loading .pci_fixup @ 0x8151c280 (0x1db8 bytes)
Loading __ksymtab @ 0x8151e038 (0xbdc0 bytes)
Loading __ksymtab_gpl @ 0x81529df8 (0x6710 bytes)
Loading __ksymtab_strings @ 0x81530508 (0x14ceb bytes)
Loading __param @ 0x815451f8 (0x898 bytes)
Clearing __modver @ 0x81545a90 (0x570 bytes)
Loading .data @ 0x81546000 (0x3d7d8 bytes)
Loading .data..page_aligned @ 0x81584000 (0x4000 bytes)
Loading .init.text @ 0x81588000 (0x2665c bytes)
Loading .init.data @ 0x815ae660 (0x12300 bytes)
Loading .data..percpu @ 0x815c1000 (0x3eb0 bytes)
Clearing .bss @ 0x816d0000 (0x10486c8 bytes)
## Loading OS kernel with entry point: 0x81107920 ...
Bootloader: Done loading app on coremask: 0x1
[ 0.000000] Linux version 4.4.92 (gkuri@galileo) (gcc version 5.4.0
(LEDE GCC 5.4.0 r3560-79f57e4227
[ 0.000000] CVMSEG size: 2 cache lines (256 bytes)
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 000d0601 (Cavium Octeon+)
[ 0.000000] Checking for the multiply/shift bug... no.
[ 0.000000] Checking for the daddiu bug... no.
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
[ 0.000000] memory: 00000000016186c8 @ 0000000001100000 (usable)
[ 0.000000] User-defined physical RAM map:
[ 0.000000] memory: 0000000000000000 @ 0000000000000000 (usable)
[ 0.000000] Kernel panic - not syncing: Incorrect memory mapping !!!
[ 0.000000] Rebooting in 1 seconds..
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 23:19 ` Gabriel Kuri
@ 2017-10-31 23:42 ` Gabriel Kuri
2017-11-01 0:02 ` David Daney
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel Kuri @ 2017-10-31 23:42 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
>> When booting Octeon Linux, it is important to use the bootoctlinux command.
>
> I had to hard code the command line before compiling the kernel, it
> wouldn't take the argument in their U-Boot.
>
> But now it panics saying "Incorrect memory mapping". See below.
>
> It seems it thinks it has 0 RAM at location 0x0 according to the output below.
>
> Is there anyway to tell it via the command line to use 64M @ 0x0 ?
When mem=0 didn't work, I figured out I could give it mem=64M@0 and
now it thinks it has 64M of RAM, but it's still stuck only using 20MB
of RAM out of the 64M, which goes back to my original issue of the
kernel memory map being messed up?
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
[ 0.000000] memory: 00000000016186c8 @ 0000000001100000 (usable)
[ 0.000000] User-defined physical RAM map:
[ 0.000000] memory: 0000000004000000 @ 0000000000000000 (usable)
[ 0.000000] Using internal Device Tree.
[ 0.000000] software IO TLB [mem 0x02724000-0x02764000] (0MB)
mapped at [8000000002724000-800000000]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000efffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[ 0.000000] Primary instruction cache 32kB, virtually tagged, 4
way, 64 sets, linesize 128 bytes.
[ 0.000000] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
[ 0.000000] PERCPU: Embedded 13 pages/cpu @8000000002771000 s16048
r8192 d29008 u53248
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16160
[ 0.000000] Kernel command line: bootoctlinux bed00000
console=ttyS0,9600 mtdparts=phys_mapped_fla0
[ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 21392K/65536K available (3384K kernel code,
264K rwdata, 968K rodata, 1312K ini)
# cat /proc/iomem
00000000-03ffffff : System RAM
01100000-0144e613 : Kernel code
0144e614-01587fff : Kernel data
1f400000-1fbfffff : 1f400000.nor
1070000000800-10700000008ff : /soc@0/gpio-controller@1070000000800
1180000000800-118000000083f : serial
1180000000c00-1180000000c3f : serial
1180000001000-11800000011ff : /soc@0/i2c@1180000001000
1180000001800-118000000183f : /soc@0/mdio@1180000001800
1180040000000-118004000000f : octeon_rng
11b00f0000000-11b0130000000 : Octeon PCI MEM
11b00f0000000-11b00f000ffff : 0000:00:03.0
11b00f0010000-11b00f001ffff : 0000:00:04.0
1400000000000-1400000000007 : octeon_rng
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Octeon CN5010 - Kernel 4.4.92
2017-10-31 23:42 ` Gabriel Kuri
@ 2017-11-01 0:02 ` David Daney
0 siblings, 0 replies; 10+ messages in thread
From: David Daney @ 2017-11-01 0:02 UTC (permalink / raw)
To: Gabriel Kuri; +Cc: linux-mips
On 10/31/2017 04:42 PM, Gabriel Kuri wrote:
>>> When booting Octeon Linux, it is important to use the bootoctlinux command.
>>
>> I had to hard code the command line before compiling the kernel, it
>> wouldn't take the argument in their U-Boot.
>>
>> But now it panics saying "Incorrect memory mapping". See below.
>>
>> It seems it thinks it has 0 RAM at location 0x0 according to the output below.
>>
>> Is there anyway to tell it via the command line to use 64M @ 0x0 ?
>
> When mem=0 didn't work, I figured out I could give it mem=64M@0 and
> now it thinks it has 64M of RAM, but it's still stuck only using 20MB
> of RAM out of the 64M, which goes back to my original issue of the
> kernel memory map being messed up?
>
Octeon memory allocation doesn't work like most other Linux. And,
neither does the built-in command line.
I would recommend looking at arch/mips/cavium-octeon/setup.c (prom_init)
You might try a local patch to force max_memory to a value larger than
the amount of memory physically present on the board. That should cause
it to attempt to allocate all memory that was not reserved for other
purposes by the bootloader.
>
> [ 0.000000] Determined physical RAM map:
> [ 0.000000] memory: 0000000001800000 @ 0000000002800000 (usable)
> [ 0.000000] memory: 00000000016186c8 @ 0000000001100000 (usable)
> [ 0.000000] User-defined physical RAM map:
> [ 0.000000] memory: 0000000004000000 @ 0000000000000000 (usable)
> [ 0.000000] Using internal Device Tree.
> [ 0.000000] software IO TLB [mem 0x02724000-0x02764000] (0MB)
> mapped at [8000000002724000-800000000]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000efffffff]
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
> [ 0.000000] Primary instruction cache 32kB, virtually tagged, 4
> way, 64 sets, linesize 128 bytes.
> [ 0.000000] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
> [ 0.000000] PERCPU: Embedded 13 pages/cpu @8000000002771000 s16048
> r8192 d29008 u53248
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 16160
> [ 0.000000] Kernel command line: bootoctlinux bed00000
> console=ttyS0,9600 mtdparts=phys_mapped_fla0
> [ 0.000000] PID hash table entries: 256 (order: -1, 2048 bytes)
> [ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> [ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 21392K/65536K available (3384K kernel code,
> 264K rwdata, 968K rodata, 1312K ini)
>
>
>
> # cat /proc/iomem
> 00000000-03ffffff : System RAM
> 01100000-0144e613 : Kernel code
> 0144e614-01587fff : Kernel data
> 1f400000-1fbfffff : 1f400000.nor
> 1070000000800-10700000008ff : /soc@0/gpio-controller@1070000000800
> 1180000000800-118000000083f : serial
> 1180000000c00-1180000000c3f : serial
> 1180000001000-11800000011ff : /soc@0/i2c@1180000001000
> 1180000001800-118000000183f : /soc@0/mdio@1180000001800
> 1180040000000-118004000000f : octeon_rng
> 11b00f0000000-11b0130000000 : Octeon PCI MEM
> 11b00f0000000-11b00f000ffff : 0000:00:03.0
> 11b00f0010000-11b00f001ffff : 0000:00:04.0
> 1400000000000-1400000000007 : octeon_rng
>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-01 0:02 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-31 16:54 Octeon CN5010 - Kernel 4.4.92 Gabriel Kuri
2017-10-31 17:22 ` David Daney
2017-10-31 17:26 ` Gabriel Kuri
2017-10-31 20:15 ` Gabriel Kuri
2017-10-31 20:21 ` David Daney
2017-10-31 21:31 ` Gabriel Kuri
2017-10-31 21:55 ` David Daney
2017-10-31 23:19 ` Gabriel Kuri
2017-10-31 23:42 ` Gabriel Kuri
2017-11-01 0:02 ` David Daney
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.