Re:Re: memory map

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

[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]

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/

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

Re:Re: memory map

[zzh]

>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.
>
this should be done as early as possible unless want to set or copy those values again from old to new.The value is really unimportant
if decide to map it with  BAT.
ADS manual say this should be 0x0470-0000 with no obvious reason.
At least it is not mandatary.My pilot board cannot read hwconfig
from flash(it took me much time to find this before learned it from Motorola web site),the default IMMR after power on is 0x0f00-0000.
I choose to map it to 0xf000-0000 with  BAT.
>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.
Any other board ? I know there is one from EST with no FCC.
>
>
>	-- Dan


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