The OS Mini seems to be using only 256MB of it's 512MB RAM.

I understand about reduced net RAM due to reservations for framebuffers, device drivers, enigma usage etc., but that's not what I'm pointing out here. This seems to be a reduction in gross RAM due to highmem being disabled in the kernel, due to cache aliasing being set for the BMIPS4380 CPU core.

Best I can see, this was a change sometime around Linux 4.0, but I don't know if it's a permanent restriction or just a configuration error. This isn't unique to OpenViX, but presumably everything using the Edision kernel from GitHub, including OpenATV.

I'm posting this here in case anyone reading knows more. It's probably a linux-mips or open-edision problem at its core?

Getting access to the full RAM would be great. Here are my two OS Minis with 10 days uptime:

Code:
root@sat1:~# free
              total        used        free      shared  buff/cache   available
Mem:         248772      192224       37324         816       19224       34244
Swap:             0           0           0
Code:
root@sat2:~# free
              total        used        free      shared  buff/cache   available
Mem:         248772      222664       12216         812       13892        6480
Swap:             0           0           0


I found old references to the BMIPS4380 core addressing working for >256MB in Linux 2.6 and 3.4. Around 2014/2015 there was a tidy-up of BMIPS with respect to HIGHMEM and cache aliasing. Since then, any satellite box dmesg log I can find on Linux 4.0+ seems hard-limited to 256MB gross on BMIPS4380.

Here's an OS Mini under OpenViX 5.0.014:
Code:
Linux version 4.11.0 (vix@ns3044876.ip-51-255-93.eu) (gcc version 6.3.0 (GCC) ) #1 SMP Tue May 16 11:44:48 BST 2017
CPU0 revision is: 0002a065 (Broadcom BMIPS4380)
FPU revision is: 00130001
MIPS: machine is Broadcom BCM97362SVMB
Determined physical RAM map:
 memory: 10000000 @ 00000000 (usable)
Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
Primary data cache 64kB, 4-way, VIPT, cache aliases, linesize 64 bytes
This processor doesn't support highmem. -262144k highmem ignored
Zone ranges:
  Normal   [mem 0x0000000000000000-0x000000000fffffff]
  HighMem  empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x000000000fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff]
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat 80a5ec00, node_mem_map 8100b000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
percpu: Embedded 16 pages/cpu @8120e000 s34192 r8192 d23152 u65536
pcpu-alloc: s34192 r8192 d23152 u65536 alloc=16*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200  ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 248460K/262144K available (8530K kernel code, 330K rwdata, 1700K rodata, 312K init, 303K bss, 13684K reserved, 0K cma-reserved, 0K highmem)

Here you'll see the same on an OS Mini under OpenATV on Linux 4.8.0: https://www.opena.tv/edision-os-mini...-gefunden.html
Code:
Linux version 4.8.0 (oe1@BUILD3) (gcc version 5.3.0 (GCC) ) #1 SMP Wed Oct 5 02:52:13 CEST 2016
CPU0 revision is: 0002a065 (Broadcom BMIPS4380)
FPU revision is: 00130001
MIPS: machine is Broadcom BCM97362SVMB
Determined physical RAM map:
 memory: 10000000 @ 00000000 (usable)
Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes.
Primary data cache 64kB, 4-way, VIPT, cache aliases, linesize 64 bytes
This processor doesn't support highmem. -262144k highmem ignored
Zone ranges:
  Normal   [mem 0x0000000000000000-0x000000000fffffff]
  HighMem  empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x000000000fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff]
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat 809fc980, node_mem_map 8100b000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
percpu: Embedded 14 pages/cpu @8120e000 s25104 r8192 d24048 u57344
pcpu-alloc: s25104 r8192 d24048 u57344 alloc=14*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200  ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 248940K/262144K available (8211K kernel code, 317K rwdata, 1640K rodata, 256K init, 286K bss, 13204K reserved, 0K cma-reserved, 0K highmem)

Searching for "BMIPS4380 highmem" shows a 2015 commit thread for this CPU core https://www.linux-mips.org/archives/.../msg00112.html
...and maybe a description of the underlying issue:
Booting a HIGHMEM MIPS kernel on a system with cache aliases may fail if the system has >256MB of memory.
I found various old BMIPS4380-cored (not OS Mini) kernel bootlogs that weren't hard-restricted to 256Mb: