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:Re: memory map

[zzh]

>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
In fact,i am hacking with a motorola 8260 ads board.I download the
mpc8xx to start with.I find it is in fact quite different.The cpm
part is similar,but the core should not use the code in CONFIG_8XX
.I think the memory problem is very important.No i determine to
proceed as follows:
1)Before start_here,map KERNELBASE to 0 with BAT,then can safely call
other function
2)In mapin_ram(),map KERNELBASE to phys mem use paging,i think this is necessary because we need to individually controll the caching property of those pages used by cpm.
3)Map internal memory space with BAT above KERNELBASE.on startup,
my board's IMMR=0f000000,so change this to f0000000 in ROM code
before init dram etc and use it in kernel too.
Do you think this is ok?I learned that you do a 8260 port too,
what is the method you use and how's the status of the work?
                           Best Regard
                           davidzhang


** 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/

MultiPPC - was: memory map

[Geir Frode Raanes]

On Mon, 24 Apr 2000, Dan Malek wrote:

> I think the [8260] implementation is pretty slick, especially when
> you look at the multiprocessor implementation.

Hold it! What multiprocessor implementation? The 8260 contains a
PPC603e CPU kernel. To my knowledge, the 603 does not support
multiprocessor setups. For that you need a 604 or larger.
Is there something different with the 8260 implementation?
Do I need to read up on the datasheet here?

The reason I ask is that I would love to run a 8260 and a 8240
in a multiprocessor setup. But only if there is dedicated hardware
to support it and a Linux kernel capable of handling it. The IBM
405gp is a nice system-on-a-chip with PCI, but I would defenitely
prefer the CPM of 8260. But the 8260 does not come with PCI and
HW DMA channels as yet. I could of cause use a separate PCI
bridge, but if I need a separate chip I would prefer too see
this chip do some useful work too. Only in this kind of setup,
I would need some way of guaranteeing that the correct CPU
issues instructions to onchip peripherials. Guess this ruins it.

BTW, has anyone looked into the possibility of implementing
IEEE-1394 FireWire on a FCC of 8260? Motorola microcode perhaps?
Probabely a no-go as USB was hardwired on the 823, but perhaps
in transparent mode and in combination with a SCC for control
of external FPGA. Food for thought.

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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

Re: MultiPPC - was: memory map

[Dan Malek]

Geir Frode Raanes wrote:

> Hold it! What multiprocessor implementation?
> Do I need to read up on the datasheet here?

You need a little more than a datasheet......

> The reason I ask is that I would love to run a 8260 and a 8240
> in a multiprocessor setup.


Where have you been :-)?  Check out Motorola's web site and other
PowerPC board vendors.  Most use the higher performance 7xx/7xxx
with the 8260, but you could use the 8240 as well.  There are
several custom multiprocessor 8260s running for well known data/telecom
companies.

> .... But only if there is dedicated hardware
> to support it and a Linux kernel capable of handling it.

The hardware is there.  With the 8260 you have some memory/bus options
that you may want to consider as alternate performance designs.  You
may want to run two separate kernels, or you could hack something into
one Linux kernel.  I'm pretty sure you wouldn't get something off-the-
shelf today.


> .... But the 8260 does not come with PCI and
> HW DMA channels as yet. I could of cause use a separate PCI
> bridge, but if I need a separate chip I would prefer too see
> this chip do some useful work too.

Several options here too.

> ... Only in this kind of setup,
> I would need some way of guaranteeing that the correct CPU
> issues instructions to onchip peripherials. Guess this ruins it.

Huh?  Talk about giving up before you ever start.....There isn't
anything that can't be done if you want to do it.


> BTW, has anyone looked into the possibility of implementing
> IEEE-1394 FireWire on a FCC of 8260?

Yes.


> ... Motorola microcode perhaps?

Perhaps.


> Probabely a no-go as USB was hardwired on the 823,

You lost me here.........



	-- 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/

Re: MultiPPC - was: memory map

[Geir Frode Raanes]

On Tue, 25 Apr 2000, Dan Malek wrote:

> Geir Frode Raanes wrote:
>
> > Hold it! What multiprocessor implementation?
> > Do I need to read up on the datasheet here?
>
> You need a little more than a datasheet......

Well yes. But I have to start somewhere and the datasheet
is as good a starting point as any. First you figure out
if it is altogether possible, then you work out the details.

Motorola documentation on the issue so far studied suggested
it was not possible, which made me stop searching any further.
Which has me believe the multiCPU HW is actually retrofitted
to the 603e kernel at a point later than the documentation.

> > The reason I ask is that I would love to run a 8260 and a 8240
> > in a multiprocessor setup.
>
> Where have you been :-)?

In another department mostly. Started up on PowerPC 4 months
ago. My current task is to replace the MBX board nearing it's
end-of-life. It will be replaced with a modest 855T design.

> Check out Motorola's web site and other
> PowerPC board vendors.  Most use the higher performance 7xx/7xxx
> with the 8260, but you could use the 8240 as well.  There are
> several custom multiprocessor 8260s running for well known data/telecom
> companies.

I was not really thinking of large compactPCI cards and defenitely
not of any design including the dreaded PCI-to-ISA bridge - the root
of all digital evil and so forth. Perhaps one of the PPMC boards
though.

Mostly I was playing with the Linux PDA idea, wich requires a
system-on-a-chip core. A 8260 with PCI (and probabely also CardBus32
PCI extensions or else use a TI bridge) Ethernet, FireWire and USB
implemented in microcode would defenitely do the trick. Add a 1/4
VGA LCD and one set of five keys to each side of the box (making up
a stenography keyboard) and we have a excellent, streamlined PDA.

But even if I had to throw a low power 8240 into the mix it would
be worthwhile if Linux could make use of this second CPU. Possibely
putting it to sleep when not needed. But it is only the MBX
replacement I am actually paid to do... And given the sheer size
of the 8260 I can only say Things Take Time.

> > ... Only in this kind of setup,
> > I would need some way of guaranteeing that the correct CPU
> > issues instructions to onchip peripherials. Guess this ruins it.
>
> Huh?  Talk about giving up before you ever start.....There isn't
> anything that can't be done if you want to do it.

OK, ok! A closer inspection of the datasheet reveals that the 8260
in slave mode will snoop bus transactions. Which means that any
onchip memory mapped peripherial will be available from any CPU.
But browsing the 8240 UM did not reveal any corresponding
functionality. Lots on PCI arbitration but little on local
bus arbitration.

> > BTW, has anyone looked into the possibility of implementing
> > IEEE-1394 FireWire on a FCC of 8260?
>
> Yes.
>
> > ... Motorola microcode perhaps?
>
> Perhaps.

Then perhaps I should wait it out on the nearest fence?
Like the 8260 PCI interface?

> > Probabely a no-go as USB was hardwired on the 823,
>
> You lost me here.........

If 12 MBit/s USB could not be implemented in microcode on
a 20 MBit/s 8xx SCC port, then it is not very likely that
400 MBit/s Firewire can be implemented in microcode on a
700 MBit/s FCC port. But of cause, the 8260 DSP is a lot
faster than the 8xx DSP, so maybe now USB is possible on
a 8260 SCC port. That would be nice.

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************

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

Re: MultiPPC - was: memory map

[Dan Malek]

Geir Frode Raanes wrote:

> Mostly I was playing with the Linux PDA idea, wich requires a
> system-on-a-chip core. A 8260 with PCI (and probabely also CardBus32
> PCI extensions or else use a TI bridge) Ethernet, FireWire and USB
> implemented in microcode would defenitely do the trick. Add a 1/4
> VGA LCD and one set of five keys to each side of the box (making up
> a stenography keyboard) and we have a excellent, streamlined PDA.

I know of a company that is building such a thing without a PCI......

> But even if I had to throw a low power 8240 into the mix it would

I don't know if there is a "low power" 8240, at least based upon
the heat sink they put on the things :-).

> Then perhaps I should wait it out on the nearest fence?
> Like the 8260 PCI interface?

I have mixed feelings about using PCI with the 8260.  Yes, I have
seen some designs where that was appropriate, but all to often PCI
is used as (an expensive) crutch to get some I/O that is more than
possible and more efficient within the programmability of the
processor and CPM.  It's like the designers were sold on the features,
then decided it was easier to plunk down hardware rather than learn
something new.


> If 12 MBit/s USB could not be implemented in microcode on
> a 20 MBit/s 8xx SCC port,

But it is implemented and it works......It takes a small microcode
patch (that I just happen to have here in my back pocket) for efficient
host mode, but the original design was only for a function end point.


	-- 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/