405GPr ioremap problem

405GPr ioremap problem

[Felix Radensky]

Hi, folks

I have a 405GPr based board with 512M of RAM.
My kernel is 2.4.17 from Monta Vista Linux 2.1.
I'm  trying to reserve 64M on boot using mem=448M
and map it later by

ioremap(__pa(high_memory), 64*(1<<20));

This worked fine when system had 256M of RAM,
but now ioremap fails. If I understand the kernel
code correctly, by adding more RAM I've reduced
the vmalloc/ioremap space. I can also see that this
space is reduced dramatically on boot by mappings
done in arch/ppc/kernel/ppc4xx_setup.c:m4xx_map_io()

Is there any way to fix problem ? Is it necessary to have
a 1:1 virtual to physical mappings as its done in m4xx_map_io()
or maybe higher virtual addresses can be used, thus
allowing to save some precious ioremap space.

Thanks a lot in advance.

Please CC me, as I'm not on the list.

Felix.

Re: 405GPr ioremap problem

[Matt Porter]

On Tue, Nov 09, 2004 at 07:27:09PM +0200, Felix Radensky wrote:
> Hi, folks
> 
> I have a 405GPr based board with 512M of RAM.
> My kernel is 2.4.17 from Monta Vista Linux 2.1.
> I'm  trying to reserve 64M on boot using mem=448M
> and map it later by
> 
> ioremap(__pa(high_memory), 64*(1<<20));
> 
> This worked fine when system had 256M of RAM,
> but now ioremap fails. If I understand the kernel
> code correctly, by adding more RAM I've reduced
> the vmalloc/ioremap space. I can also see that this
> space is reduced dramatically on boot by mappings
> done in arch/ppc/kernel/ppc4xx_setup.c:m4xx_map_io()
> 
> Is there any way to fix problem ? Is it necessary to have
> a 1:1 virtual to physical mappings as its done in m4xx_map_io()
> or maybe higher virtual addresses can be used, thus
> allowing to save some precious ioremap space.

This is exactly why the PPC44x ports don't use io_block_map()...
it can interfere with dynamic mappings.  It is not necessary to
have 1:1 virtual to physical mappings nor is it necessary to
have m4xx_map_io() at all. One can use ioremap() to map any
space and let the kernel place things intelligently. In order
to use serial console you'll have to use early_serial_setup()
after you've ioremapped the UART...once you've removed the
io_block_map() call. Look at other ports to see how this is
done.

Someday I might get down my list to cleaning up 40x stuff in 2.6.

-Matt

Re: 405GPr ioremap problem

[Felix Radensky]

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

Hi, Matt

Thanks a lot for replying, your help is very much
appreciated. I've followed your suggestion and now
ioremap works as expected. I've removed ivocation
of m4xx_map_io() replacing it by normal ioremaps
for serial ports, RTC and ethernet adapter.

It would be great to see this stuff cleaned up in 2.6.

Felix.


Matt Porter wrote:

>On Tue, Nov 09, 2004 at 07:27:09PM +0200, Felix Radensky wrote:
>  
>
>>Hi, folks
>>
>>I have a 405GPr based board with 512M of RAM.
>>My kernel is 2.4.17 from Monta Vista Linux 2.1.
>>I'm  trying to reserve 64M on boot using mem=448M
>>and map it later by
>>
>>ioremap(__pa(high_memory), 64*(1<<20));
>>
>>This worked fine when system had 256M of RAM,
>>but now ioremap fails. If I understand the kernel
>>code correctly, by adding more RAM I've reduced
>>the vmalloc/ioremap space. I can also see that this
>>space is reduced dramatically on boot by mappings
>>done in arch/ppc/kernel/ppc4xx_setup.c:m4xx_map_io()
>>
>>Is there any way to fix problem ? Is it necessary to have
>>a 1:1 virtual to physical mappings as its done in m4xx_map_io()
>>or maybe higher virtual addresses can be used, thus
>>allowing to save some precious ioremap space.
>>    
>>
>
>This is exactly why the PPC44x ports don't use io_block_map()...
>it can interfere with dynamic mappings.  It is not necessary to
>have 1:1 virtual to physical mappings nor is it necessary to
>have m4xx_map_io() at all. One can use ioremap() to map any
>space and let the kernel place things intelligently. In order
>to use serial console you'll have to use early_serial_setup()
>after you've ioremapped the UART...once you've removed the
>io_block_map() call. Look at other ports to see how this is
>done.
>
>Someday I might get down my list to cleaning up 40x stuff in 2.6.
>
>-Matt
>
>  
>

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