finding out the processor frequency

finding out the processor frequency

[Leisner, Martin]

What exactly do we mean by "timebase"?

There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
processor frequency (derived from the dts).  But its not exported.

There's also ppc_tb_freq.

marty

Re: finding out the processor frequency

[Scott Wood]

On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> What exactly do we mean by "timebase"?
> 
> There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> processor frequency (derived from the dts).  But its not exported.
> 
> There's also ppc_tb_freq.

The timebase is the rate at which the timebase and decrementer registers
tick.  It is not the same as the CPU core frequency.

-Scott

Re: finding out the processor frequency

[Josh Boyer]

On Thu, 6 Sep 2007 13:43:08 -0500
Scott Wood <scottwood@freescale.com> wrote:

> On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> > What exactly do we mean by "timebase"?
> > 
> > There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> > processor frequency (derived from the dts).  But its not exported.
> > 
> > There's also ppc_tb_freq.
> 
> The timebase is the rate at which the timebase and decrementer registers
> tick.  It is not the same as the CPU core frequency.

Unless your timebase and decrementer clock source is tied to the CPU
clock. :)

So it depends on the board, and it can even depend on how the board is
initialized.  Some boards can change the timebase clock source on the
fly.

josh

PCI target implementation on AMCC PPC CPUs

[Leonid]

Hi:

Does somebody have any experience of using AMCC PPC chips (such as
PPC440ep) or any other PPC at all as PCI target (slave)? PPC440ep has
PCI-PLB bridge which certainly can be configured as slave. CPU will need
to do configuration and then I assume another CPU (PCI host) will be
able to access all memories via the bridge including peripherals'
controllers. Slave CPU involvement would be minimal then.

Can anybody point me to design like this or to that end to any SW design
where PPC CPU works as PCI slave?

Thanks,

Leonid.

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Leonid,

> Does somebody have any experience of using AMCC PPC chips (such as
> PPC440ep) or any other PPC at all as PCI target (slave)? PPC440ep has
> PCI-PLB bridge which certainly can be configured as slave. CPU will need
> to do configuration and then I assume another CPU (PCI host) will be
> able to access all memories via the bridge including peripherals'
> controllers. Slave CPU involvement would be minimal then.
> 
> Can anybody point me to design like this or to that end to any SW design
> where PPC CPU works as PCI slave?

I have an application where I want to communicate with up
to 20 cPCI slaves per cPCI chassis, where the slave devices
each use a PowerPC based processor. (The masters happen
to be x86 CPUs; because I have them).

I looked at the 440EP using the Yosemite board

http://www.ovro.caltech.edu/~dwh/powerpc_440ep.pdf

and the Freescale MPC8349E

http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

I had some trouble the with AMCC chips; the DMA controller
operation was weird, and AMCC tech support was pretty
much useless.

Freescale's technical (design) support is great, and they
(the software developers; Kim, Timur, etc) are actively
maintaining/contributing to git trees for u-boot and Linux.
If you can change processors, I'd recommend any Freescale
part over an AMCC part.

I'm working on a cPCI board design at the moment, you're
welcome to look at the design;

  * PowerPC
  * Altera Stratix II FPGAs
  * dual 8-bit 1GHz ADCs

http://www.ovro.caltech.edu/~dwh/carma_board/

Regards,
Dave

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Leonid,

In case they are not in the document:

There are several fundamental problems with the AMCC 440EP
acting as a PCI target/slave;

1. As a PCI target, there is only one way to generate
    an interrupt to a host; you basically toggle the
    interrupt pin. This makes it tricky to develop a
    host-to-slave communications protocol, eg. its
    hard to use the single interrupt to indicate various
    interrupt states, eg. target-to-host buffer has
    data versus host-to-target buffer has been emptied.
    Ideally AMCC should have implemented mailboxes and/or
    doorbell registers like any other sane PCI target
    device (eg. some the Freescale processors, or any of
    the PLX technologies chips).

2. Look in the data sheet and see if you can figure out
    how the host processor can generate an interrupt to
    the PowerPC core ... oops, you can't. That kind of
    makes it difficult to work with doesn't it.

    A work around would be to have the host write to the
    GPIO register and wire a GPIO pin back to an external
    interrupt pin. Then you would not be able to use any
    other GPIO pin in that GPIO register since there is
    no way to arbitrate host access versus PowerPC core
    access.

This was the other reason I ditched the AMCC part in
favor of the Freescale part.

If you are looking at other parts, make sure you look
in the PCI configuration space of the processor reference
manual. Many processors have the interrupt pin register
hardwired to zero, i.e., they can not be used as target
devices, only hosts. In that case you'd have to add an
intel 21555 non-transparent bridge to make the device
a target.

Cheers,
Dave

Re: PCI target implementation on AMCC PPC CPUs

[Wolfgang Denk]

In message <46E05FFD.3020605@ovro.caltech.edu> you wrote:
> 
> Freescale's technical (design) support is great, and they
> (the software developers; Kim, Timur, etc) are actively
> maintaining/contributing to git trees for u-boot and Linux.
> If you can change processors, I'd recommend any Freescale
> part over an AMCC part.

But then,  a  lot  of  people  with  in-depth  experience  with  AMCC
processors hang out on the lists and on IRC, too. AMCC is pretty well
supported at least as far as U-Boot and Linux (and the ELDK) go.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a group of N persons implements a COBOL compiler,  there  will  be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Wolfgang,

>> Freescale's technical (design) support is great, and they
>> (the software developers; Kim, Timur, etc) are actively
>> maintaining/contributing to git trees for u-boot and Linux.
>> If you can change processors, I'd recommend any Freescale
>> part over an AMCC part.
> 
> But then,  a  lot  of  people  with  in-depth  experience  with  AMCC
> processors hang out on the lists and on IRC, too. AMCC is pretty well
> supported at least as far as U-Boot and Linux (and the ELDK) go.

Thats good to know.

I was just trying to relay my experience with the two
company's support and with two comparable processors
(440EP vs MPC8349EA).

The nice thing about this group, and open-source in
general, is the 'open' part, everyone can share their
experiences :)

Cheers,
Dave

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi guys,

> You want to say  PPC440GP cannot be PCI slave without
> this non-transparent bridge because as David said
> its "interrupt pin register hardwired to zero" or
> there other reasons?  I'm trying to use
> PPC440ep(or epx) and from its datasheet I don't
> see anything about this zero hardwiring.
> Does it mean "vanilla" PPC440ep will work?

Look in the user manual p562

https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440GP/PPC440GP_UM2002_v1_11.pdf

The processor can generate INTA#.

> I have been finished an application using AMCC
> PPC440GP as PCI target(slave) in the last 2 month.
> I use a non-transparent bridge(AMCC PCI6466) to
> make the device a target(slave) like david has said.

However in this case, the bridge was not required
to make the processor target-capable. Most likely
the board required a local PCI bus, and so the
non-transparent bridge is used to hide the board
PCI devices from the other PCI host.

In this type of design the processor is acting
a *host* on the target board. When a host wants
to interrupt the target, it asserts an interrupt
in the bridge, and that interrupt asserts an
interrupt input on the processor.

When the target processor wants to interrupt the
host it writes to a register in the bridge and
the bridge interrupt the host using its INTA#.

In both cases the bridge is the target and the
processors are both hosts.

:)

Dave

Re: PCI target implementation on AMCC PPC CPUs

[Matthias Fuchs]

Hi David,

we build a couple of PCI target designs using AMCC PowerPCs.
You are right that some things could be better. But ..

On Thursday 06 September 2007 22:26, David Hawkins wrote:
> There are several fundamental problems with the AMCC 440EP
> acting as a PCI target/slave;
> 
> 2. Look in the data sheet and see if you can figure out
>     how the host processor can generate an interrupt to
>     the PowerPC core ... oops, you can't. That kind of
>     makes it difficult to work with doesn't it.
You CAN! You can generate an interrupt to the PowerPC from the host
CPU bei writing to the PCI command register. You have to read the user manual
carefully. Perhaps it not that obvious.

Matthias

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Matthias,

> we build a couple of PCI target designs using AMCC PowerPCs.
> You are right that some things could be better. But ..
> 
> On Thursday 06 September 2007 22:26, David Hawkins wrote:
>> There are several fundamental problems with the AMCC 440EP
>> acting as a PCI target/slave;
>>
>> 2. Look in the data sheet and see if you can figure out
>>     how the host processor can generate an interrupt to
>>     the PowerPC core ... oops, you can't. That kind of
>>     makes it difficult to work with doesn't it.
>
> You CAN! You can generate an interrupt to the PowerPC from the host
> CPU bei writing to the PCI command register. You have to read the user manual
> carefully. Perhaps it not that obvious.

Really!? Someone should tell AMCC tech support then.
When I failed to find a method (other than hooking up
an external GPIO), I contacted them and they came to
the same conclusion (on the 440EP anyway).

I'll look in the latest user manual to be sure ...

PPC440EP_UM2000_v1_23.pdf

p394 has their 'cheesy' implementation of PCI INTA# control;
toggle a single bit.

Then backing up a little, p388 has the PCI command register ...
Nope, no comment there that a write causes an interrupt to
the PowerPC core.

Ok, so going back to the UIC in Chapter 10, p224.

Ah-ha, PCI CMD write generates an interrupt 5!

So, I stand corrected; the host can generate an interrupt to
the PowerPC core, and the method is 'cheesier' than the PCI
INTA# control.

And my experience with AMCC's tech support is now a notch
lower, as even they did not offer this as a solution :)

I sure am glad I changed to a Freescale processor ;)

Cheers,
Dave

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Matthias,
> 
>> we build a couple of PCI target designs using AMCC PowerPCs.
>> You are right that some things could be better. But ..

Since you build a couple of target designs, I assume you
(or someone working with you) must have written some host
to target communication device drivers.

The reason I refer to the AMCC interrupt solution as
'cheesy' is that there is only one way to generate
an interrupt; this is distinct from the fact that
there is one interrupt signal (in each direction).

The PCI-to-local bus bridges from PLX, and the messaging
units found in other processors still only have one
interrupt signal between the target and the host
(an INTA# PCI line), and a host-to-target interrupt
by way of some interrupt controller line internal to the
SoC. However, these devices have multiple bits to
assert the interrupt signals.

The nicest feature I've used for developing a host-to-target
communications mechanism is the mailbox registers.
A mailbox register can be written by the host using
write-1 to set, and then cleared by the target using
write-1 to clear. Its important that a write-1 interface
is used, if read-modify-write was used, then interrupts
could be missed.

I wrote up the method I used to create an interprocessor
handshake (used much like a mutex)

http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf

The host processor and the target processor use this
protocol for protecting access to a common resource; the
read and write data buffers. The buffers are transferred
using DMA.

Page 8-10 of the document shows a simplified version analogous
to the serial ports of a UART.

A key part of the protocol described is that, analogous to
a serial port, two interrupt sources are required;
  * transmitter empty
  * receiver ready

The host CPU writes to a transmitter ready bit to generate
a receiver ready interrupt at the target, and once the
target has moved the transmitter data out of the transmit
buffer, it writes to the transmitter empty bit to generate
a transmitter empty interrupt to the host. And the
analogous operation happens for the target to host
transmissions. Hence there are two mailbox bits that
the devices write to to generate an interrupt to the other
processor, and two mailbox bits that generate interrupts,
so are cleared by each processor.

The two interprocessor data paths are independent and
asynchronous with respect to each other, and no polling
is required; upon receiving a mailbox interrupt the
ISR can schedule a receive task, or a transmit task,
or both, depending on the state of the mailbox bits.

How then with only one interrupt source do you implement
a robust interprocessor handshake with the AMCC
single-interrupt, without resorting to polling anywhere
in a driver?

Obviously the above driver was just my take on how to
create such an interface. After I wrote it, I had a look
around and found Micheal Barr had created something similar
(not in the context of a linux driver though).

BTW; I'm not trying to start a flame-war of AMCC verus
Freescale. This just happened to be a downside to this
processor for my specific application. I found plenty
of downsides with Coldfire's, and PowerQuiccIIs and IIIs
too.

Cheers,
Dave

Re: PCI target implementation on AMCC PPC CPUs

[Matthias Fuchs]

Hi David,

I must admit, that the AMCC PowerPC's PCI interrupt capabilities could
be better:-) In both directions the host CPU has to do PCI
configuration cycles either to generate or acknowledge an interrupt.
The later is problematic for some OS coming from Redmond: you 
have to do pci configuration cycles from interrupt level - and
these OS do not 'like' that. 

In later designs and where possible we also switched to alternative
interrupt mechanisms (GPIO for target to host and gated flags in FPGA
registers for the other direction). Multiple interrupt sources 
are identified by messages that are written to the other sides
memory.

I think we should stop this discussion because its a little bit
off-topic on this list.

Matthias


On Tuesday 11 September 2007 19:32, David Hawkins wrote:
> Hi Matthias,
> 
> > we build a couple of PCI target designs using AMCC PowerPCs.
> > You are right that some things could be better. But ..
> > 
> > On Thursday 06 September 2007 22:26, David Hawkins wrote:
> >> There are several fundamental problems with the AMCC 440EP
> >> acting as a PCI target/slave;
> >>
> >> 2. Look in the data sheet and see if you can figure out
> >>     how the host processor can generate an interrupt to
> >>     the PowerPC core ... oops, you can't. That kind of
> >>     makes it difficult to work with doesn't it.
> >
> > You CAN! You can generate an interrupt to the PowerPC from the host
> > CPU bei writing to the PCI command register. You have to read the user manual
> > carefully. Perhaps it not that obvious.
> 
> Really!? Someone should tell AMCC tech support then.
> When I failed to find a method (other than hooking up
> an external GPIO), I contacted them and they came to
> the same conclusion (on the 440EP anyway).
> 
> I'll look in the latest user manual to be sure ...
> 
> PPC440EP_UM2000_v1_23.pdf
> 
> p394 has their 'cheesy' implementation of PCI INTA# control;
> toggle a single bit.
> 
> Then backing up a little, p388 has the PCI command register ...
> Nope, no comment there that a write causes an interrupt to
> the PowerPC core.
> 
> Ok, so going back to the UIC in Chapter 10, p224.
> 
> Ah-ha, PCI CMD write generates an interrupt 5!
> 
> So, I stand corrected; the host can generate an interrupt to
> the PowerPC core, and the method is 'cheesier' than the PCI
> INTA# control.
> 
> And my experience with AMCC's tech support is now a notch
> lower, as even they did not offer this as a solution :)
> 
> I sure am glad I changed to a Freescale processor ;)
> 
> Cheers,
> Dave

Re: PCI target implementation on AMCC PPC CPUs

[David Hawkins]

Hi Matthias,

> I must admit, that the AMCC PowerPC's PCI interrupt capabilities could
> be better:-) In both directions the host CPU has to do PCI
> configuration cycles either to generate or acknowledge an interrupt.
> The later is problematic for some OS coming from Redmond: you 
> have to do pci configuration cycles from interrupt level - and
> these OS do not 'like' that. 

Yikes. I'm sure there were some headaches there.

> In later designs and where possible we also switched to alternative
> interrupt mechanisms (GPIO for target to host and gated flags in FPGA
> registers for the other direction). Multiple interrupt sources 
> are identified by messages that are written to the other sides
> memory.
> 
> I think we should stop this discussion because its a little bit
> off-topic on this list.

I think this particular piece of info is important on
this list. It'll help those looking for processor options
that happen to search back through the list messages.

I'm done now, I just wanted to satisfy my curiosity
(and I did learn how the host can interrupt the core!).

I know that Leonid has hardware with these CPUs on them,
and he wanted some feedback on the AMCCs as target processor.
I'd eliminated the processor before getting it fully into
a design; so your experience is a little further on.

However, the conclusion remains the same; try to avoid
using the 440EP as a PCI target device.

Cheers,
Dave