RadStone PPC2A-604e & VxWorks 5.3.1
Sandeep Neema
We have a RadStone PPC2A-604e board with VxWorks 5.3.1. I am new to
both VxWorks and PPC. We have a Mizar 7772 DSP board on the same rack.
The board is mapped to address 0xA0000000 in the A32 VME space.
As per the Mizar documentation I added this address in the
SysPhysMemAdrs
array in the SysLib.c so that the MMU does not translate this address.
Further the Mizar
documentation claims that if I dump the memory at that address I should
see their
signature. However I get a "machine check" exception instead.
I have couple of questions with reference to the above:
1) Is there something obvious that I am missing here?
2) Do I need to use sysBusToLocalAdrs/sysLocalToBusAdrs?
3) How can I determine the exact cause of a "machine check" exception?
AFAIK a
"machine check" exception could be caused by number of reasons.
Thanks for your patience in reading this far.
I would appreciate any help.
Cheers,
Sandeep
mailto:nee...@vuse.vanderbilt.edu
--
------------------------------------------------------------------------
Sandeep Neema
511 Chesterfield Avenue, #9D
Nashville, TN37212
Res: 615-297-6053 Off: 615-343-7566
-------------------------------------------------------------------------
rcwa...@my-dejanews.com
I have similar problems on my system. I cannot "see" any of the VME or PCI
boards from within the VxWorks system. That is, I cannot successfully
execute the D or M commands.
I *can* however read and write to the boards under program control; if fact,
I wrote my own Peek and Poke functions that access these boards.
It seems odd to me that I can read and write from within the Tornado shell,
just not with the Wind River supplied tools.
The only change to VxWorks I made was to syslib.c, the sysPhysMemDesc table.
Ron Wagner
r...@dynresSPAM.com
(remove caps to reply)
In article <35D34856...@vuse.vanderbilt.edu>,
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Stephen A Walsh
>Hello VxWorks,
>
>We have a RadStone PPC2A-604e board with VxWorks 5.3.1. I am new to
>both VxWorks and PPC. We have a Mizar 7772 DSP board on the same rack.
>The board is mapped to address 0xA0000000 in the A32 VME space.
>As per the Mizar documentation I added this address in the
>SysPhysMemAdrs
>array in the SysLib.c so that the MMU does not translate this address.
>Further the Mizar
>documentation claims that if I dump the memory at that address I should
>see their
>signature. However I get a "machine check" exception instead.
>
>I have couple of questions with reference to the above:
>1) Is there something obvious that I am missing here?
As well as using the functions below it would be advisable to
check the settings in config.h for you VME windows.
It should probably look something like this for you setup
#define VME_A32_MSTR_SIZE 0x10000000 /* Size of A32 Window */
#define VME_A32_MSTR_BUS 0xA0000000 /* First Bus Address */
For more info on VME windows try downloading Windriver Technical
Note 44 from thier website.
Note: There is a limit to the size of VME_A32_MSTR_SIZE but i'm
not quite sure what it is (I think it may be 0x30000000 but it
may be less).
>2) Do I need to use sysBusToLocalAdrs/sysLocalToBusAdrs?
Yes this is very important.
>3) How can I determine the exact cause of a "machine check" exception?
>AFAIK a
> "machine check" exception could be caused by number of reasons.
>
I'm not sure about this one.
Hope this helps,
Steve
************************************
Opinions, etc are as always my own
************************************
Gus DiPierro
>
> Sandeep Neema <nee...@vuse.vanderbilt.edu> wrote:
> >Hello VxWorks,
> >
> >We have a RadStone PPC2A-604e board with VxWorks 5.3.1. I am new to
> >both VxWorks and PPC. We have a Mizar 7772 DSP board on the same rack.
> >The board is mapped to address 0xA0000000 in the A32 VME space.
The address here is a vme address. The addresses that go into the
sysLib.c file are PPC local addresses.( Don't forget you are going
through 2 bridges to get to the VME.)
So take 0xa0000000 out of the syslib.c. The radstone BSP already takes
the pci mapping into account. (I believe it is put into the BAT
registers)
> >As per the Mizar documentation I added this address in the
> >SysPhysMemAdrs
> >array in the SysLib.c so that the MMU does not translate this address.
> >Further the Mizar
> >documentation claims that if I dump the memory at that address I should
> >see their
> >signature. However I get a "machine check" exception instead.
> >
> >I have couple of questions with reference to the above:
> >1) Is there something obvious that I am missing here?
>
> As well as using the functions below it would be advisable to
> check the settings in config.h for you VME windows.
>
> It should probably look something like this for you setup
>
> #define VME_A32_MSTR_SIZE 0x10000000 /* Size of A32 Window */
> #define VME_A32_MSTR_BUS 0xA0000000 /* First Bus Address */
>
> For more info on VME windows try downloading Windriver Technical
> Note 44 from thier website.
>
> Note: There is a limit to the size of VME_A32_MSTR_SIZE but i'm
> not quite sure what it is (I think it may be 0x30000000 but it
> may be less).
>
The problem with the size is that the VME address space is mapped
directly on the PCI address space. Since the ppc's window into the PCI
is only from 0xc0880000 - 0xfeffffff (ppc local), it does not leave you
alot to play with.
> >2) Do I need to use sysBusToLocalAdrs/sysLocalToBusAdrs?
>
> Yes this is very important.
It is the only way for the processor to figure out the local address
equivalent of the vme address.
>
> >3) How can I determine the exact cause of a "machine check" exception?
> >AFAIK a
> > "machine check" exception could be caused by number of reasons.
> >
> I'm not sure about this one.
The reason you are getting a machine check is because you are probably
trying to access the 0xa0000000 address locally which should be in the
pci I/O space "weeds" and you are getting a bus error.
In short, you need to setup the config.h file's vme address windows and
use the sysBusToLocalAdrs function.
For vme accesses the universeII can do either coupled or posted writes
and only coupled reads. On a coupled access, the pci bus is not
released until the vme transaction is done. If there is a vme bus error
during this time the universeII will signal a target abort on the pci
bus. The ppc/pci bridge is set up to send a machine check exception to
the PPC if this happens.
Also you can use vxMemProbe with the address you get from
sysBusToLocalAdrs. This will test for a vme response to the address
without receiving a Machine check exception if there is an error.
--
_______________________
Gus DiPierro
Mail Stop M113 E-mail: gdip...@fallschurch.esys.com
RAYTHEON Systems Company dipi...@erols.com (personal)
7700 Arlington Blvd. Voice: (703) 560-5000 ext. 2937
Falls Church, VA 22042 Fax: (703) 280-4627
Paul Chien
I am using the Radstone PPC1A-604e, but the BSP is very similar to yours
> 1) Is there something obvious that I am missing here?
Check up the following files from Radstone for the Universe II PCI-VME
bridge, they will lead you to some insights:
$(WIND_BASE)\target\src\drv\vme\vmeUniverse.c
$(WIND_BASE)\target\h\drv\vme\vmeUniverse.h
I had to cross-reference with the Tundra Universe Maunal for the VME
settings. You can get it from Tundra's website if you need it.
The sysVmeInit() routine from vmeUniverse.c sets up the PCI-VME mappings
according to VME_A32_MSTR_SIZE, VME_A32_MSTR_BUS etc, as defined in
config.h, but you still have sets up the sysPhysMemDesc[] in sysLib.c.
I think the default Radstone BSP setting only enbales the first 16Mb
(16/64) of Universe's Special PCI Slave Image (SLSI), which is a mixture
of A16 and A24 space sitting at 0xF4000000 to 0xF4FFFFFF.
A24: 0xF4000000 to 0xF4FEFFFF with max data width of D32
A16: 0xF4FF0000 to 0xF4FFFFFF with max data width of D32
I had to modify in $(WIND_BASE)\target\src\drv\vme\vmeUniverse.c to make
sure Universe does not try to talk D32 to my A24/D16 target, by limiting
the max data width to 16.
> 3) How can I determine the exact cause of a "machine check" exception?
I used excHookAdd () to check the cause of the exception,
\target\h\arch\ppc\excPpcLib.h defines the exceptions. The WRS www
archive also contains an demo code of checking exceptions with signal.
Cheers
Paul
Sandeep Neema wrote:
>
> Hello VxWorks,
>
> We have a RadStone PPC2A-604e board with VxWorks 5.3.1. I am new to
> both VxWorks and PPC. We have a Mizar 7772 DSP board on the same rack.
> The board is mapped to address 0xA0000000 in the A32 VME space.
> As per the Mizar documentation I added this address in the
> SysPhysMemAdrs
> array in the SysLib.c so that the MMU does not translate this address.
> Further the Mizar
> documentation claims that if I dump the memory at that address I should
> see their
> signature. However I get a "machine check" exception instead.
>
> I have couple of questions with reference to the above:
> 1) Is there something obvious that I am missing here?
> 2) Do I need to use sysBusToLocalAdrs/sysLocalToBusAdrs?
> 3) How can I determine the exact cause of a "machine check" exception?
> AFAIK a
> "machine check" exception could be caused by number of reasons.
>
> Thanks for your patience in reading this far.
> I would appreciate any help.
>
> Cheers,
> Sandeep
>
> mailto:nee...@vuse.vanderbilt.edu
> --
> ------------------------------------------------------------------------
>
> Sandeep Neema
> 511 Chesterfield Avenue, #9D
> Nashville, TN37212
>
> Res: 615-297-6053 Off: 615-343-7566
> -------------------------------------------------------------------------
--
----------------------------------------------------------------------
| Paul Chien Mecalc (Pty) Ltd
| Project Engineer Wind River Systems Distributor, South Africa.
| Tel: +27-12-665-1480 P.O.Box 7958, Centurion 0046, South Africa.
| Fax: +27-12-665-1495 86 Oak Avenue, Highveld Technopark, Centurion.
| pa...@mecalc.co.za http://www.mecalc.co.za
----------------------------------------------------------------------