smp8634 add memory at dram1

smp8634 add memory at dram1

[David Kuk]

After study about the memory configuration of sigma smp8634, i found 
some difficult to accomplish the task.

so my question is if have two 128MB ram separately under dram0 and dram1 
controller, where dram0 for linux and dram1 for video decoding. Now the 
situation is the memory for linux is not enough and video decoding can 
not use all of it's 128MB at dram1, what we plan to do is to share 64MB 
at dram1 to the linux kernel as high memory, and only reserved 64MB at 
dram1 for the video decoding.

first, in MIPS architecture, we found that the kseg0 and kseg1 are 
mapped to 0x00000000-0x20000000, which include only dram0 controller, so 
we wish to add the dram1 memory manually to the kernel using function 
add_memory_region at setup.c , after booting up result the warning that 
the memory larger than 512 need to configured the kernel support high 
memory.

then when we configure the kernel to support high memory at menu 
configure, the kernel when booting up will remind us our CPU do not 
support high memory due to cache aliases.

Both way will lead the linux can not boot up normally, so what should we 
do, is there any mis-understanding about the hardware implementation or 
MIPS design? \

Re: smp8634 add memory at dram1

[Ralf Baechle]

On Wed, Nov 14, 2007 at 04:44:27PM +0800, David Kuk wrote:

> After study about the memory configuration of sigma smp8634, i found 
> some difficult to accomplish the task.
> 
> so my question is if have two 128MB ram separately under dram0 and dram1 
> controller, where dram0 for linux and dram1 for video decoding. Now the 
> situation is the memory for linux is not enough and video decoding can 
> not use all of it's 128MB at dram1, what we plan to do is to share 64MB 
> at dram1 to the linux kernel as high memory, and only reserved 64MB at 
> dram1 for the video decoding.
> 
> first, in MIPS architecture, we found that the kseg0 and kseg1 are 
> mapped to 0x00000000-0x20000000, which include only dram0 controller, so 
> we wish to add the dram1 memory manually to the kernel using function 
> add_memory_region at setup.c , after booting up result the warning that 
> the memory larger than 512 need to configured the kernel support high 
> memory.
> 
> then when we configure the kernel to support high memory at menu 
> configure, the kernel when booting up will remind us our CPU do not 
> support high memory due to cache aliases.

This is really a software restriction.  I originally developped highmem for
MIPS on a Sibyte SB1250 which doesn't suffer from aliases so I didn't even
attempt to solve the cache aliasing issue.  The other platforms on whic
highmem used to be used was the E9000 family but it seem by now the users
of these platforms have all moved to full 64-bit kernels, so aside fo the
implementation restrictions has also started to bitrot a little.

What would be necessary to get it to work is to flush the page from cache at
kunmap() rsp.  kunmap_atomic() time.  That should do the trick though there
are significant further optimizations possible.

An alterantive to solve the aliasing issue would be to increase the
page size to 16K.  Again, the combination of highmem and 16K pages is
untested.

I don't know what processor core Sigma is using in this SOC.  In case its a
64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
kernel, it's much less painful than highmem.

  Ralf

Re: smp8634 add memory at dram1

[david]

Quoting Ralf Baechle <ralf@linux-mips.org>:

>
> I don't know what processor core Sigma is using in this SOC.  In case its a
> 64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
> kernel, it's much less painful than highmem.
>
>   Ralf
>
>

It is a MIPS 4KEc core.

Re: smp8634 add memory at dram1

[David Daney]

David Kuk wrote:
> After study about the memory configuration of sigma smp8634, i found 
> some difficult to accomplish the task.
>
> so my question is if have two 128MB ram separately under dram0 and 
> dram1 controller, where dram0 for linux and dram1 for video decoding. 
> Now the situation is the memory for linux is not enough and video 
> decoding can not use all of it's 128MB at dram1, what we plan to do is 
> to share 64MB at dram1 to the linux kernel as high memory, and only 
> reserved 64MB at dram1 for the video decoding.
>
> first, in MIPS architecture, we found that the kseg0 and kseg1 are 
> mapped to 0x00000000-0x20000000, which include only dram0 controller, 
> so we wish to add the dram1 memory manually to the kernel using 
> function add_memory_region at setup.c , after booting up result the 
> warning that the memory larger than 512 need to configured the kernel 
> support high memory.
>
> then when we configure the kernel to support high memory at menu 
> configure, the kernel when booting up will remind us our CPU do not 
> support high memory due to cache aliases.
>
> Both way will lead the linux can not boot up normally, so what should 
> we do, is there any mis-understanding about the hardware 
> implementation or MIPS design?

I think your understanding of the 8634 is at least close to correct.

It may be possible (but I have not tried it yet) to use the remapping
registers to move dram1 into the first 512MB of the memory space.  If it
is possible, you would then have to modify the gbus access functions
accordingly.  Also the 8634 media drivers would probably have to be
changed as well.  I am not sure about the microcode for the media DSPs,
but if it is dependent on the mapping of the DRAM, then you would
probably have to get the vendor's help.

Let me know if you are successful.

Thanks,
David Daney

RE: smp8634 add memory at dram1

[Gustafsson Marcus-MGU001]

 
David Daney wrote
> I think your understanding of the 8634 is at least close to correct.
> 
> It may be possible (but I have not tried it yet) to use the 
> remapping registers to move dram1 into the first 512MB of the 
> memory space.  If it is possible, you would then have to 
> modify the gbus access functions accordingly.  Also the 8634 
> media drivers would probably have to be changed as well.  I 
> am not sure about the microcode for the media DSPs, but if it 
> is dependent on the mapping of the DRAM, then you would 
> probably have to get the vendor's help.
> 
> Let me know if you are successful.
AFAIK the memory bandwith available is not enough for supporting video
decoding and Linux usage at the same dram controller.

/Marcus Gustafsson

RE: smp8634 add memory at dram1

[Gustafsson Marcus-MGU001]

 
David Daney wrote
> I think your understanding of the 8634 is at least close to correct.
> 
> It may be possible (but I have not tried it yet) to use the 
> remapping registers to move dram1 into the first 512MB of the 
> memory space.  If it is possible, you would then have to 
> modify the gbus access functions accordingly.  Also the 8634 
> media drivers would probably have to be changed as well.  I 
> am not sure about the microcode for the media DSPs, but if it 
> is dependent on the mapping of the DRAM, then you would 
> probably have to get the vendor's help.
> 
> Let me know if you are successful.
AFAIK the memory bandwith available is not enough for supporting video
decoding and Linux usage at the same dram controller.

/Marcus Gustafsson

Re: smp8634 add memory at dram1

[David Kuk]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

Thanks you all for helping.

AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) to
remap register 3,
and add the remap register 3 into the BOOT_MEMROY_RAM use the method
add_memory_region.
When i bootup the linux kernel print out that it have totally 176MB ram ,
which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at remap
register3). How ever, This mapping shows that the total memory in the linux
kernel is not contiguous. the OS can run, but as i see the source code, when
the kernel divided these memory into pages, it did not consider  if the
memory is contiguous or not, is it ok ? and  how should i  allocate the
memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all the
176MB memory can be allocate as ZONE[DMA]?


Best wishes
David




On 11/15/07, David Daney <ddaney@avtrex.com> wrote:
>
> David Kuk wrote:
> > After study about the memory configuration of sigma smp8634, i found
> > some difficult to accomplish the task.
> >
> > so my question is if have two 128MB ram separately under dram0 and
> > dram1 controller, where dram0 for linux and dram1 for video decoding.
> > Now the situation is the memory for linux is not enough and video
> > decoding can not use all of it's 128MB at dram1, what we plan to do is
> > to share 64MB at dram1 to the linux kernel as high memory, and only
> > reserved 64MB at dram1 for the video decoding.
> >
> > first, in MIPS architecture, we found that the kseg0 and kseg1 are
> > mapped to 0x00000000-0x20000000, which include only dram0 controller,
> > so we wish to add the dram1 memory manually to the kernel using
> > function add_memory_region at setup.c , after booting up result the
> > warning that the memory larger than 512 need to configured the kernel
> > support high memory.
> >
> > then when we configure the kernel to support high memory at menu
> > configure, the kernel when booting up will remind us our CPU do not
> > support high memory due to cache aliases.
> >
> > Both way will lead the linux can not boot up normally, so what should
> > we do, is there any mis-understanding about the hardware
> > implementation or MIPS design?
>
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the remapping
> registers to move dram1 into the first 512MB of the memory space.  If it
> is possible, you would then have to modify the gbus access functions
> accordingly.  Also the 8634 media drivers would probably have to be
> changed as well.  I am not sure about the microcode for the media DSPs,
> but if it is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
>
> Thanks,
> David Daney
>
>

[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

Re: smp8634 add memory at dram1

[David Kuk]

[-- Attachment #1: Type: text/plain, Size: 4870 bytes --]

Dear all,

thank you very much Lin, for your kindly reply. May I ask you some more
questions ?

1. about your answer 2, it's true that 0x10000000 to 0x10020000 are
reserved,
so what's the way i can sure no one use this area of memory ? because
em86xx_kmem_start is still the dram controller0's.

2. about your answer 3, if i need to enable the PCI host, you mean i will
have no chance to have greater than 112 MB DMA memory start from the
em86xx_kmem_start ? it's seems a dilemma here, I may describe it more
clearly. I have one ram size of 128 at dram0 controller and as well as
another 128 at dram1 controller. previously it's work very well, the
controller0's ram is for linux and controller1's memory is for video decode.
But recently because the grow of code size of grow of both linux as well as
middle ware, we really need more memory for for kernel run, so if in this
situation , what should i do ?

thx a lot for your help
David

On 11/21/07, YH Lin <YH_Lin@sdesigns.com> wrote:
>
>
>
> Hi David,
>
>
>
> We have not done so for SMP8634. But I think it is possible to do this:
>
>
>
>    1. Using remap register 4 instead, there you will have
>    0x0c000000-0x16fe0000 contiguous space, where 0x0c000000-0x0fffffff is
>    mapped to DRAM1 and 0x10000000-0x16fe0000 is in DRAM0.
>    2. You'd probably reserve the memory 0x10000000-0x10020000 since
>    this area is used by other things so it'd be better if no one else is using
>    this portion of memory.
>    3. As for DMA zone or normal zone, that depends. Do you have the
>    need to enable PCI host? If so, the max. size of DMA zone is 112MB, or else
>    it can all be DMA memory (provide that the address translation routines are
>    modified accordingly).
>
>
>
> Regards,
>
> YH
>
>
>  ------------------------------
>
> *From:* linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]
> *On Behalf Of *David Kuk
> *Sent:* Monday, November 19, 2007 8:23 PM
> *To:* David Daney
> *Cc:* linux-mips@linux-mips.org
> *Subject:* Re: smp8634 add memory at dram1
>
>
>
> Thanks you all for helping.
>
> AS Daney suggested, I have map the dram1's first 64 MB memory (total 128)
> to remap register 3,
> and add the remap register 3 into the BOOT_MEMROY_RAM use the method
> add_memory_region.
> When i bootup the linux kernel print out that it have totally 176MB ram ,
> which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at
> remap register3). How ever, This mapping shows that the total memory in the
> linux kernel is not contiguous. the OS can run, but as i see the source
> code, when the kernel divided these memory into pages, it did not consider
> if the memory is contiguous or not, is it ok ? and  how should i  allocate
> the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all
> the 176MB memory can be allocate as ZONE[DMA]?
>
>
> Best wishes
> David
>
>
>
>  On 11/15/07, *David Daney* <ddaney@avtrex.com> wrote:
>
> David Kuk wrote:
> > After study about the memory configuration of sigma smp8634, i found
> > some difficult to accomplish the task.
> >
> > so my question is if have two 128MB ram separately under dram0 and
> > dram1 controller, where dram0 for linux and dram1 for video decoding.
> > Now the situation is the memory for linux is not enough and video
> > decoding can not use all of it's 128MB at dram1, what we plan to do is
> > to share 64MB at dram1 to the linux kernel as high memory, and only
> > reserved 64MB at dram1 for the video decoding.
> >
> > first, in MIPS architecture, we found that the kseg0 and kseg1 are
> > mapped to 0x00000000-0x20000000, which include only dram0 controller,
> > so we wish to add the dram1 memory manually to the kernel using
> > function add_memory_region at setup.c , after booting up result the
> > warning that the memory larger than 512 need to configured the kernel
> > support high memory.
> >
> > then when we configure the kernel to support high memory at menu
> > configure, the kernel when booting up will remind us our CPU do not
> > support high memory due to cache aliases.
> >
> > Both way will lead the linux can not boot up normally, so what should
> > we do, is there any mis-understanding about the hardware
> > implementation or MIPS design?
>
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the remapping
> registers to move dram1 into the first 512MB of the memory space.  If it
> is possible, you would then have to modify the gbus access functions
> accordingly.  Also the 8634 media drivers would probably have to be
> changed as well.  I am not sure about the microcode for the media DSPs,
> but if it is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
>
> Thanks,
> David Daney
>
>
>

[-- Attachment #2: Type: text/html, Size: 8934 bytes --]

Re: smp8634 add memory at dram1

[David Kuk]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1140 bytes --]

Re: smp8634 add memory at dram1

[James Zipperer]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

 
David Kuk" <david.kuk@entone.com <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
 

[-- Attachment #2: Type: text/html, Size: 9405 bytes --]

Re: smp8634 add memory at dram1

[James Zipperer]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

 
David Kuk" <david.kuk@entone.com <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
 

[-- Attachment #2: Type: text/html, Size: 9405 bytes --]

Re: smp8634 add memory at dram1

[David Daney]

James Zipperer wrote:

> 
>  
> 
> 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!
> 
>  
> 

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

RE: smp8634 add memory at dram1

[James Zipperer]

> James Zipperer wrote:
>
>> 
>>  
>> 
>> 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!
>> 
>>  
>> 
>
>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


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

RE: smp8634 add memory at dram1

[James Zipperer]

> James Zipperer wrote:
>
>> 
>>  
>> 
>> 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!
>> 
>>  
>> 
>
>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


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

RE: smp8634 add memory at dram1

[James Zipperer]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

James Zipperer wrote:
>>> 
>>>  
>>> 
>>> 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!
>>> 
>>>  
>>> 
>>
>>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
>>
>
>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

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
 

[-- Attachment #2: Type: text/html, Size: 12775 bytes --]

RE: smp8634 add memory at dram1

[James Zipperer]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

James Zipperer wrote:
>>> 
>>>  
>>> 
>>> 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!
>>> 
>>>  
>>> 
>>
>>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
>>
>
>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

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
 

[-- Attachment #2: Type: text/html, Size: 12775 bytes --]