Access to MPC823 GPCMs from Nto app

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Among the projects on which I’m working is one with a group that is
spinning a CPU board using Moto’s MPC823 for the CPU. The 823 has a
general purpose chip select machine (GPCM) which manages eight chip
select lines on the 823. The hardware group wants to use five of them
for special functions on our board.

Never having done such a thing from Neutrino, I am curious as to whether
Neutrino has any reserved functions in the GPCM of which I should stay
clear, or whether those are programmable by my software. If they are
programmable by software, what is the preferred way to access them?

I imagine that I could use mmap_device_memory to map the 823 registers
directly and program them myself, yes? Is there a better interface (e.g.
an 800-specific driver call I should make)?

Thanks in advance,
Eric

2

In qdn.public.qnxrtp.os Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: Among the projects on which I’m working is one with a group that is
: spinning a CPU board using Moto’s MPC823 for the CPU. The 823 has a
: general purpose chip select machine (GPCM) which manages eight chip
: select lines on the 823. The hardware group wants to use five of them
: for special functions on our board.

: Never having done such a thing from Neutrino, I am curious as to whether
: Neutrino has any reserved functions in the GPCM of which I should stay
: clear, or whether those are programmable by my software. If they are
: programmable by software, what is the preferred way to access them?

: I imagine that I could use mmap_device_memory to map the 823 registers
: directly and program them myself, yes? Is there a better interface (e.g.
: an 800-specific driver call I should make)?

Since the Brx and Orx live in the IMMR space, the mmap_device_memory is
the correct way of accessing the registers.

Your software can safely modify the chip selects. The only chip select of
concern is the one controlling the system memory. Obviously you don’t
want to mess with system memory under Neutrino’s feet.

–
John

3

In article <8u75ru$5u1$1@nntp.qnx.com>, John Wall <jwall@qnx.com>
wrote:

In qdn.public.qnxrtp.os Eric Berdahl <> berdahl@intelligentparadigm.com
wrote:
: Among the projects on which I’m working is one with a group that is
: spinning a CPU board using Moto’s MPC823 for the CPU. The 823 has a
: general purpose chip select machine (GPCM) which manages eight chip
: select lines on the 823. The hardware group wants to use five of them
: for special functions on our board.
[snip]
Since the Brx and Orx live in the IMMR space, the mmap_device_memory is
the correct way of accessing the registers.

Boffo. Thanks for the sanity check.

Your software can safely modify the chip selects. The only chip select
of
concern is the one controlling the system memory. Obviously you don’t
want to mess with system memory under Neutrino’s feet.

That makes perfect sense. On the 823, only /CS0 seems to be dedicated by
the chip. /CS1 through /CS7 are available for OS/application control.
Would I be correct to assume that Neutrino reserves /CS1 for system
memory (referring to your answer above) and that my software should
stick to /CS2 through /CS7? Or does Neutrino do something really clever,
like reprogramming /CS0 to manage system memory?

I’m trying to get a handle on this both from the standpoint of writing
my software and for the purpose of giving my hardware guys a sanity
check so they don’t do something silly when building our board.

Thanks in advance.

4

In qdn.public.qnxrtp.os Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: In article <8u75ru$5u1$1@nntp.qnx.com>, John Wall <jwall@qnx.com>
: wrote:

:> In qdn.public.qnxrtp.os Eric Berdahl <berdahl@intelligentparadigm.com>
:> wrote:
:> : Among the projects on which I’m working is one with a group that is
:> : spinning a CPU board using Moto’s MPC823 for the CPU. The 823 has a
:> : general purpose chip select machine (GPCM) which manages eight chip
:> : select lines on the 823. The hardware group wants to use five of them
:> : for special functions on our board.
: [snip]
:> Since the Brx and Orx live in the IMMR space, the mmap_device_memory is
:> the correct way of accessing the registers.

: Boffo. Thanks for the sanity check.

:> Your software can safely modify the chip selects. The only chip select
:> of
:> concern is the one controlling the system memory. Obviously you don’t
:> want to mess with system memory under Neutrino’s feet.

: That makes perfect sense. On the 823, only /CS0 seems to be dedicated by
: the chip. /CS1 through /CS7 are available for OS/application control.
: Would I be correct to assume that Neutrino reserves /CS1 for system

Neutrino knows nothing about the chips select per se.
The ROM monitor or IPL configure the chip selects. The chip select used
for system memory is dependent on the hardware design. On the most of
the 8xx board I’ve worked with, CS0 (BR0/OR0) is connected to flash
(the reset vector is generally connected to CS0, but not always) and CS1
or CS2 control system memory. You’ll need to look at your hardware manual
or schematics for an accurate picture.


: memory (referring to your answer above) and that my software should
: stick to /CS2 through /CS7? Or does Neutrino do something really clever,
: like reprogramming /CS0 to manage system memory?

Again, Neutrino knows nothing about the chip selects. In the startup
program (e.g. startup-800fads) the amount of ram and location is
setup in the syspage. Neutrino assumes this memory is available and
configured.

Is this a little clearer?

John Wall
QSSL
Custom Engineering Group (R&D)

5

In article <8u97hb$c3t$1@nntp.qnx.com>, John Wall <jwall@qnx.com>
wrote:

Neutrino knows nothing about the chips select per se.
The ROM monitor or IPL configure the chip selects. The chip select used
for system memory is dependent on the hardware design. On the most of
the 8xx board I’ve worked with, CS0 (BR0/OR0) is connected to flash
(the reset vector is generally connected to CS0, but not always) and CS1
or CS2 control system memory. You’ll need to look at your hardware
manual
or schematics for an accurate picture.

Yeah, that’s what I was afraid of. What’s happening behind the scenes is
that my hardware group is supposedly using the 8xxFADS board as a
reference, doing the moral equivalent of taking the magic eraser and
removing the functions we don’t need from the reference design while
adding the functions we do need.

I’m hoping to use Neutrino as the OS on the board (a helluva lot easier
than writing our own OS, and gives us lots of software features for
free).

: memory (referring to your answer above) and that my software should
: stick to /CS2 through /CS7? Or does Neutrino do something really
: clever,
: like reprogramming /CS0 to manage system memory?

Again, Neutrino knows nothing about the chip selects. In the startup
program (e.g. startup-800fads) the amount of ram and location is
setup in the syspage. Neutrino assumes this memory is available and
configured.

Is this a little clearer?

Yes, it is clearer. Thanks. If I could impose to ask one more question…

I’m hoping to use startup-800fads on our board, which I am told will be
the moral equivalent (apply sanity check as appropriate) of the 800fads
board. This will save me from writing a startup program of my own.

The issue is that our hardware guys need to know which chip selects to
use for our private functions and which ones are reserved by the OS. I
understand now that this is not Neutrino, per se, but the startup
program. Am I on the right track? If so, is there documentation
somewhere for which chip selects are used by startup-800fads for various
functions?

Thanks again for your patience and help!

6

In qdn.public.qnxrtp.os Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: In article <8u97hb$c3t$1@nntp.qnx.com>, John Wall <jwall@qnx.com>
: wrote:

:> Neutrino knows nothing about the chips select per se.
:> The ROM monitor or IPL configure the chip selects. The chip select used
:> for system memory is dependent on the hardware design. On the most of
:> the 8xx board I’ve worked with, CS0 (BR0/OR0) is connected to flash
:> (the reset vector is generally connected to CS0, but not always) and CS1
:> or CS2 control system memory. You’ll need to look at your hardware
:> manual
:> or schematics for an accurate picture.

: Yeah, that’s what I was afraid of. What’s happening behind the scenes is
: that my hardware group is supposedly using the 8xxFADS board as a
: reference, doing the moral equivalent of taking the magic eraser and
: removing the functions we don’t need from the reference design while
: adding the functions we do need.

: I’m hoping to use Neutrino as the OS on the board (a helluva lot easier
: than writing our own OS, and gives us lots of software features for
: free).

Should not be a problem.


:> : memory (referring to your answer above) and that my software should
:> : stick to /CS2 through /CS7? Or does Neutrino do something really
:> : clever,
:> : like reprogramming /CS0 to manage system memory?
:>
:> Again, Neutrino knows nothing about the chip selects. In the startup
:> program (e.g. startup-800fads) the amount of ram and location is
:> setup in the syspage. Neutrino assumes this memory is available and
:> configured.
:>
:> Is this a little clearer?

: Yes, it is clearer. Thanks. If I could impose to ask one more question…

: I’m hoping to use startup-800fads on our board, which I am told will be
: the moral equivalent (apply sanity check as appropriate) of the 800fads
: board. This will save me from writing a startup program of my own.


You should be able to use it with very little modification (if any).

: The issue is that our hardware guys need to know which chip selects to
: use for our private functions and which ones are reserved by the OS. I
: understand now that this is not Neutrino, per se, but the startup
: program. Am I on the right track? If so, is there documentation
: somewhere for which chip selects are used by startup-800fads for various
: functions?


The chip selects are configured in the IPL (src/ipl/boards/800fads). This is the
piece of code that grabs the CPU at the reset vector (boot up). Its main job
is to configure the memory controller and clocks. Once the IPL is done
configuring the CPU it hands over control to the startup. The chip selects are
programmed by the IPL. Your hardware people can configure the chip selects
any way they’d like; just make sure the IPL is properly configuring them.


For a more in-depth discussion concernig IPL and Startup please refer to the
“Building Embedded Systems” on-line docs.

–
John Wall
QSSL
Custom Engineering Group (R&D)