From: Felix Radensky <felix@allot.com>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 405GPr ioremap problem
Date: Wed, 10 Nov 2004 20:37:16 +0200 [thread overview]
Message-ID: <41925FDC.1060308@allot.com> (raw)
In-Reply-To: <20041109111707.A14471@home.com>
[-- 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 --]
prev parent reply other threads:[~2004-11-10 20:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 17:27 405GPr ioremap problem Felix Radensky
2004-11-09 18:17 ` Matt Porter
2004-11-10 18:37 ` Felix Radensky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41925FDC.1060308@allot.com \
--to=felix@allot.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=mporter@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).