All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan John Simon <Brendan.Simon@ctam.com.au>
To: linuxppc-embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: mpc8xx-2.2.13 kernel hangs during boot.
Date: Wed, 02 Feb 2000 10:09:11 +1100	[thread overview]
Message-ID: <38976797.F621D0A9@ctam.com.au> (raw)
In-Reply-To: 38968BC0.6FD6E801@netx4.com


Dan Malek wrote:

> Brendan John Simon wrote:
>
> > Sorry about my ignornace but why can't I use the address range
> > 0x80000000-0xBFFFFFFF for my peripherals ?
> > Is 0xC0000000-0xFFFFFFFF ok ?  What address range would be recommended ?
>
> I posted this before.....I hope this matches previous messages :-).
>
> If you map (i.e. ioremap()) physical memory prior to the
> kernel VM initialization, the mapping is 1:1 virtual to physical.
> This happens in mm/init.c for things like the IMMR and some
> other board control registers.  In this case, mapping below
> something like 0xd0000000 causes problems with VM collision in
> kernel or user process space.
>
> After the kernel VM is initialized, you can ioremap() any
> physical space, as the mapping isn't 1:1.

The memory controller is setup in my boot loader.  It knows nothing about VMA, only
PMA.
I currently have CS0 mapped to 0xFF800000 for flash, CS1/2 mapped to 0x00000000 and
CS4 to 0x80000000 for DRAM.
Both Dan and Wolfgang have suggested that all peripherals should be at 0xD0000000
and above.  I am happy with this but am not sure what the DRAM address should be.
Should I map CS1 and CS2 to 0x00000000 or 0xC0000000 ?

I have not changed any code in the linux source tree with regards to memory
mapping.  ie. not use of ioremap as I do not use any of the peripherals yet.  I've
got a very vague idea of what ioremap() does and will read more on it.  I sounds
like I will probably need it to access my peripherals from within linux.  Is this
correct ?


> At this stage, nothing beats a simple rom monitor that can display
> memory after a processor reset.

I'll look into adding this support to my bootloader.

Thanks,
Brendan Simon.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2000-02-01 23:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200002010035.BAA26304@denx.local.net>
2000-02-01 12:16 ` mpc8xx-2.2.13 kernel hangs during boot Brendan John Simon
     [not found]   ` <38968BC0.6FD6E801@netx4.com>
2000-02-01 23:09     ` Brendan John Simon [this message]
2000-02-01 16:07       ` Dan Malek
     [not found] ` <0001311713560A.00776@alan.corp.packetengines.com>
2000-02-01 12:58   ` Brendan John Simon
2000-02-01  1:49     ` Alan Mimms
2000-02-01 13:38       ` Brendan John Simon
2000-02-01  3:42         ` Alan Mimms
     [not found] <48256878.00018A59.00@mail.zhongxing.com>
2000-02-01 11:47 ` Brendan John Simon
2000-02-01  7:32   ` Dan Malek
2000-02-01 10:00 Brendan John Simon
2000-01-31 23:40 ` Dan Malek
2000-02-01 11:09   ` Brendan John Simon
2000-02-17 11:05     ` dony

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=38976797.F621D0A9@ctam.com.au \
    --to=brendan.simon@ctam.com.au \
    --cc=linuxppc-embedded@lists.linuxppc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.