Subject: Re: smp8634 add memory at dram1

From: "James Zipperer" <[email-masked]>
Date: Mon, 3 Mar 2008 16:14:09 -0800

David Kuk" <[email-masked] <mailto:david.kuk%40entone.com> >
wrote:
> Dear YH
> 
> I am sorry i have been disturbed by other issues, the memory problem
seems little bit difficult
> to me. In our case, i saw that in prom.c under mips/tango2, the
function prom_init , it shows
> that :
> memcfg_t
> *m=(memcfg_t*)KSEG1ADDR(MEM_BASE_dram_controller_0+FM_MEMCFG); 

> it's seems the kernel has hard coded to point the starting memory to
DRAM controller 0's
> starting address, if now, i have remap 64mb memory at DRAM controller
1 at remap register
> 4, The problem is come, the kernel will ignore any memory before dram
controller 0's starting
> address. Even i have add 0x0c000000--0x10000000 as boot memory, it
still think it's first
> usable pfn is at 0x10000000. 
> 
> my solution is 3 steps
> 
> 1, modify the compiler, let the linux start address moved to
0x0c000000, 
> 2. modify the YAMON, and map the DRAM 1 controller to remap register4
in YAMON stage
> 3, modify the linux, to set the two piece of memory to the kernel as
boot memory . 
> 
> it's this possible, or it have other better solution ?
> 
> thx a lot for your kindly help !
> 
> 
> best wishes
> David
 
I'm running out of memory in linux on the smp86xx and attempting to
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 call to
add_memory_region 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!
 
-James

---

From: David Daney <[email-masked]>
Date: Mon, 03 Mar 2008 16:26:55 -0800

> Any info/patches are greatly appreciated.  Thanks!

Typically DRAM 1 must be accessed through the TLB as its address lays 
outside of the 512MB window of KSEG[012].

The best way to make this memory available to Linux may still be up for 
debate.

David Daney

---

From: "James Zipperer" <[email-masked]>
Date: Mon, 3 Mar 2008 17:59:11 -0800

>David Daney

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[34]_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[012].  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 'free' command.

Thanks.

-James

---

From: "James Zipperer" <[email-masked]>
Date: Tue, 4 Mar 2008 12:51:03 -0800

>Can remapped addresses (namely CPU_remap[34]_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[012].  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 'free' command.
>-James

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 and DRAM0.
 
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!
 
-James