memory map

memory map

[zzh]

Hi,everyone.
I have some questions about the memory map on linux on 8xx and ppc
1)Some area eg BCSR mapped below KERNELBASE,is this safe?
I check some process's vm area,it does not fall in this area,will
it be unsafe under some circumstances?
2)I read mapin_ram() in mm/init.c ,found that phys mem is also mapped
both by bat and page table ,what is this for?
Can someone help me?


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

Re: memory map

[Dan Malek]

zzh wrote:


> 1)Some area eg BCSR mapped below KERNELBASE,is this safe?

If you ioremap() after the kernel VM allocator is initialized, this
is fine.  You then get a kernel virtual address to use that will
map to the physical address.  Don't map this in mm/init.c initialization
as this maps 1:1 because the VM is not initialized yet.  The things
mapped in mm/init.c should be just the minimum to debug or get
the kernel booted.

> I check some process's vm area,it does not fall in this area,will
> it be unsafe under some circumstances?

The "some" circumstances are incorrect mapping during the early
initialization.

> 2)I read mapin_ram() in mm/init.c ,found that phys mem is also mapped
> both by bat and page table ,what is this for?

Physical memory is mapped by BATs, if they exist on the processor.
Since the 8xx doesn't have BATs, the memory is mapped through page
tables.


	-- Dan

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

Re: memory map

[Steve Tarr]

Folks ---

This IMMR  for the MPC8260 is VERY  tricky, especially with respect to the
Hardware  Configuration Word.
Note that the ADS comes with the HWCW in flash setting the IMMR to
0x0f00_0000. However
the documentation for the ADS  memory map says it should be 0x0470_0000.
Now one of the really screwy parts of this
is that if you hose up your flash, such that the HWCW is scrogged, you can't
get at the processor, even
with the JTAG. You have to go with the default config by tying the RSTCONF to
Vcc.
Actually the PILOT boards have documentation on how to wire one of the
SoftwareSwtiches to
connect RSTCONF to Vcc. Just a warning from one poor soul who had to deal with
it.

Cheers --
tarr


Dan Malek wrote:

> zzh wrote:
>
> > In fact,i am hacking with a motorola 8260 ads board.
>
> I just checked in all of my 8260 changes.  You may find them
> helpful.
>
> > ....I download the
> > mpc8xx to start with.I find it is in fact quite different.
>
> Yes, it is quite different.....It is just a 603 with a bigger
> CPM.
>
> > my board's IMMR=0f000000,so change this to f0000000 in ROM code
>
> That's a good thing.  The current configuration assumes the
> IMMR at 0xf0000000.  Map the board BCSRs up in that range and get
> all of it with one BAT.
>
>         -- Dan
>


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

Re: memory map

[Dan Malek]

zzh wrote:

> In fact,i am hacking with a motorola 8260 ads board.

I just checked in all of my 8260 changes.  You may find them
helpful.

> ....I download the
> mpc8xx to start with.I find it is in fact quite different.

Yes, it is quite different.....It is just a 603 with a bigger
CPM.


> my board's IMMR=0f000000,so change this to f0000000 in ROM code

That's a good thing.  The current configuration assumes the
IMMR at 0xf0000000.  Map the board BCSRs up in that range and get
all of it with one BAT.


	-- Dan

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

Re: memory map

[Shuangjun Zhu]

Dan Malek wrote:

>
>zzh wrote:
>
>> In fact,i am hacking with a motorola 8260 ads board.
>
>I just checked in all of my 8260 changes.  You may find them
>helpful.
>


Where can I get the code?

>> ....I download the
>> mpc8xx to start with.I find it is in fact quite different.
>
>Yes, it is quite different.....It is just a 603 with a bigger
>CPM.
>
>
>> my board's IMMR=0f000000,so change this to f0000000 in ROM code
>
>That's a good thing.  The current configuration assumes the
>IMMR at 0xf0000000.  Map the board BCSRs up in that range and get
>all of it with one BAT.
>
>


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

Re: memory map

[Dan Malek]

Steve Tarr wrote:


> This IMMR  for the MPC8260 is VERY  tricky,

I didn't think so.  The only thing different is that it isn't stored
in a special register, so you have to know the current IMMR to change
to a different one. You can read the default setting from the
config word or boot rom, and then change it if you wish.

You have to get the default word from someplace, and that is either
the application choice from the boot rom or by asserting RSTCONF and
using a default when there isn't a boot rom.

I think the implementation is pretty slick, especially when you look
at the multiprocessor implementation.

Just because Motorola screwed up one of their reference boards (again),
doesn't mean it can't work well for others.  The purpose of these reference
boards is to demonstrate the ease of using a processor, and I am just
amazed they consistently build the most difficult to use and unreliable
platform to do that.  Fortunately, there are other choices.


	-- Dan

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

Re: memory map

[Dan Malek]

Shuangjun Zhu wrote:

> Where can I get the code?

Same place as everything else.  It is currently in the fsmlabs BitKeeper
tree, and when Cort merges with Linus it will find its way to kernel.org.


	-- Dan

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

Re: memory map

[Dan Malek]

zzh wrote:

> this should be done as early as possible unless want to set or copy those values again from old to new.

I am going to continue to insist there is lots of processor set up
that must occur before a Linux kernel is started.  The Linux kernel
really should assume some standard entry conditions, and gather some
information necessary for operation, then be on its way.

When I write boot roms for custom boards, all of the processor
initialization is complete and the code builds a board descriptor
structure.  It passes this to the Linux start up code.  The functions
in arch/ppc/mbxboot (the embedded start up) should do minimal set up,
relocate and uncompress the kernel image (like the MBX example).

You have to write all of the processor initialization code in any
case, and I find it reduces the development time if you just create
a small boot rom with a debugger.  You can then use the Linux kernel
software with minimal changes and significantly reduce the turn around
time for images that just test the processor initialization.


> ADS manual say this should be 0x0470-0000 with no obvious reason.

It's historical and part of the package.  Just change the memory
controller values to suit you (Linux) environment.

> I choose to map it to 0xf000-0000 with  BAT.

That's a good choice, then make the memory controller address the BCSR
up in that range as well.  Cover everything with one BAT.



	-- Dan

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

Memory map

[Konstantin Sabodash]

Hello TWG - pat, mark & steve.

I've seen your post to linuxppc-embedded@lists.linuxppc.org  regarding
memory access  from Linux.
Your code works fine.

 "paddr2 = mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x50000000);"

But  page size is 1K and their start addresses  appears in address
space  with increment 0x1000.
So if I put 0x50000400 address it give me segmentation fault. It works
fine in region 0x50000000 ...  0x500003ff  next 0x50001000 ...
0x500103ff and so on.
Question : how can we increase page size to eliminate these holes.
Thanks in advance.

--
Konstantin Sabodash


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

Re: Memory map

[Dan Malek]

Konstantin Sabodash wrote:

>  "paddr2 = mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x50000000);"
>
> But  page size is 1K and their start addresses  appears in address
> space  with increment 0x1000.

No, the Linux page size is 4K.

> So if I put 0x50000400 address it give me segmentation fault. It works
> fine in region 0x50000000 ...  0x500003ff  next 0x50001000 ...
> 0x500103ff and so on.
> Question : how can we increase page size to eliminate these holes.

Fix your hardware.  I don't know what "size" is in your mmap() example,
but just because you map a large space doesn't mean you necessarily have
access to all of it.   If the underlying hardware doesn't respond to
the access, you will get a bus timeout error which is reported to your
program as a segmentation violation (or bus fault violation depending
upon how we map the error today).  It looks to me like your hardware
responds to the first 1K of a selected address space, and the memory
controller is programmed to wrap this on 4K boundaries.

What kind of system is this?  What kind of device is mapped to this
address?


	-- Dan

--

	I like MMUs because I don't have a real life.

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