Skip to contentSkip to conversation

405GPr ioremap problem

DISCUSSION Felix Radensky 2 participants 3 messages Nov 9, 2004 – Nov 10, 2004

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 16 lines · 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()

Quoted 4 lines

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

#2 lore raw

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.

Quoted 42 lines · Matt Porter
Quoted 16 lines · 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()

Quoted 6 lines

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