James Zipperer wrote:
>>> I'm running out of memory in linux on the smp86xx and
>>> implement this solution. Did you ever get it to work? No luck for me
>>> yet. I'm still a bit unclear why you must
switch linux to run off DRAM
>>> 1 instead of leaving it on DRAM 0 and adding an additional
in prom_init for DRAM 1. But then
again, I haven't
>>> gotten that to work yet either :)
>>> Any info/patches are greatly appreciated. Thanks!
>>Typically DRAM 1 must be accessed through the TLB as its
>>outside of the 512MB window of KSEG.
>>The best way to make this memory available to Linux may still
be up for
>I'm sure this is a dumb question due to the fact that my grasp of
the >problem is less than acceptable...
>Can remapped addresses (namely CPU_remap_addr)
be used for the call to >add_memory_region()? That would allow the address for DRAM 1
to be within >the 512MB window of KSEG. I'm unclear whether the CPU_remap
addresses >count as PHSYICAL or VIRTUAL addresses.
>I'm guessing that my plan won't work since I tried it and it didn't
work. >My results were that the
kernel booted but didn't report any additional >memory available via the
So I think I've got a little better grasp on the problem. Is the reason you can't just remap DRAM
1 to 0x08000000 - 0x1000000000 because this is below the start address of linux 0x10020000?
Can this restriction be worked around easily?
So as far as I can tell, the options are:
1. YH's proposed
solution to use CPU remap registers to map DRAM1 to 0x08000000 - 0x10000000 in
the bootloader, make linux
run from DRAM1, and then add_memory_region for DRAM1
2. YH's other
proposed solution to leave linux running from DRAM0,
enable HIMEM, add_memory_region for DRAM1 using HIMEM,
fix HIMEM issues regarding cache aliasing.
3. Work around adding memory that starts
below linux (not sure if this is even possible).
Are there other options as well? Thanks!