f



PCI Auto config ??

When I do call pciAutoCfg I can only get thru the first pass down
inside.  It seems that when we call ibmPciConfigRead and it uses
address 0xDEC80000 (bus 0) that pass works.  Its on the second pass
using address 0xDEC00004 it just locks up and never returns from the
call?  Need some help on whats wrong with the auto config ?/

Thanks
Gary

0
glblock (22)
3/7/2005 8:19:08 PM
comp.os.vxworks 5954 articles. 1 followers. motamedi24 (67) is leader. Post Follow

20 Replies
519 Views

Similar Articles

[PageSpeed] 33

>From  the register addresses you've given, I can deduce that you're
probably using a 440gp or similar.
There is almost certainly nothing wrong the PCI auto configuration
code, it is quite mature and well proven.
The problem is very likely in your BSP and/or your target hardware.
Please provide a little more detail.
What is the specific processor you have?
Is your board a custom design?
How do you know what the code is doing when it hangs - i.e., are you
using a JTAG assisted debugger?

0
gvarndell (209)
3/7/2005 10:49:54 PM
There's almost certainly nothing wrong with PCI auto config code - it's
pretty stable.
I could guess that you're using a 440gp or similar, but I don't like
guessing.
What is your CPU, board, etc?
Where did you get your BSP?

0
gvarndell (209)
3/8/2005 6:45:54 AM
gvarndell wrote:
> There's almost certainly nothing wrong with PCI auto config code -
it's
> pretty stable.
> I could guess that you're using a 440gp or similar, but I don't like
> guessing.
> What is your CPU, board, etc?
> Where did you get your BSP?

PPC 440gx, the board is ours and I am using a template from WRS for
starters.  I have all the PHY / ETH ports working, memory is readable
and writable.  We have one DSP chip on the PCI bus.  We seem to be able
to read and write to the 0xDEC00000 address (PCIX0_CFG_PAIR_ADRS ) but
when we read the 0xDEC00004 address (PCIX0_CFG_PAIR_DATA ) it hangs.
According to the PPC440 user manual we must write to the PAIR_ADRS and
then read from the PAIR_DATA ..

> sniplet from the ppc440gx.h file..
/*
 * The following register pair is used to generate configuration cycles
 * on the PCI bus.  This region can be mapped with a single 4KB page in
the MMU.
 */
#define PCIX0_CFG_PAIR_ADRS         (PCIX0_BASE + 0x0EC00000)
#define PCIX0_CFG_PAIR_DATA         (PCIX0_BASE + 0x0EC00004)

Thanks
Gary
>

0
glblock (22)
3/8/2005 12:44:48 PM
No PCI transaction occurs when you write to the ADRS register.
When you read from (or write to) the DATA register, a transaction will
be attempted.
Make sure you don't try to access bus 0, device 0.
Try to get the BSP for the Ocotea board.
Failing that, get the BSP for the Ebony board.
In either case, roll up your sleeves, you've got a learning curve
ahead. ;)

0
gvarndell (209)
3/8/2005 2:05:58 PM
gvarndell wrote:
> No PCI transaction occurs when you write to the ADRS register.
> When you read from (or write to) the DATA register, a transaction
will
> be attempted.
> Make sure you don't try to access bus 0, device 0.
> Try to get the BSP for the Ocotea board.
> Failing that, get the BSP for the Ebony board.
> In either case, roll up your sleeves, you've got a learning curve
> ahead. ;)

Well at least I am not locking up any more but my latest error is as
follows

machine check
Exception next instruction address: 0x000232f8
Machine Status Register: 0x00001210
Condition Register: 0x20004084
Bus Error Address Register: 0x2_0ec00004
Bus Error origin code: 0x010c0000
    Bus Error Address is physical
    PLB master 1 [D-cache fill] timeout error on write
Machine Check Status Register: 0xa0000000
    MCSR bits:  MCS DRPLBE

149bb4 vxTaskEntry    +64 : shell ()
116eec shell          +184: 116f18 ()
117108 shell          +3a0: execute ()
117288 execute        +d4 : yyparse ()
1330b0 yyparse        +704: 131510 ()
13168c yystart        +8e8: pciAutoCfg (185c4c)
 186f0 pciAutoCfg     +48 : 18e9c (185c4c)
 18f68 pciAutoCfgCtl  +73c: 18fc0 (185c4c, fd09454)
 19080 pciAutoCfgCtl  +854: 19714 (185c4c, 0)
 197dc pciAutoBusNumberSet+6a8: pciConfigInLong (0, 1, 0, 0, fd093c4)
 1fc68 pciConfigInLong+e0 : ibmPciConfigRead (0, 1, 0, 0, 4, fd09364)
shell restarted.

0
glblock (22)
3/8/2005 5:24:42 PM
Believe it or not, you made progress here.
Read the Error Handling section of the PLB-PCIX bridge controller
chapter of the 440gx manual. Actually, you should read that entire
chapter -- twice.
Now you need to figure out how to configure the bridge to not bother
the processor with certain errors.

0
gvarndell (209)
3/8/2005 5:41:36 PM
gvarndell wrote:
> Believe it or not, you made progress here.
> Read the Error Handling section of the PLB-PCIX bridge controller
> chapter of the 440gx manual. Actually, you should read that entire
> chapter -- twice.
> Now you need to figure out how to configure the bridge to not bother
> the processor with certain errors.


Hmm, all errors are off.  It must be a tlb issue as I can view the PCI
memory from 0x0EC80000 to 0x0ECFFFE with no problem.  However when I go
to view the 4th byte after the bridge area, it gives the above error?..
I can
   d 0x0EC00000, 1 <--- WORKS
   d 0x0EC00001, 1 <--- WORKS
   d 0x0EC00002, 1 <--- WORKS
   d 0x0EC00003, 1 <--- WORKS

   BUT
   d 0xEC000004, 1 errors ?  this is suppose to be at least 8 bytes
long.

NOTE:  0xD0000000 tlb 0x2 0x00000000

-> d 0xDEC0000 , 4
0dec0000:  378f e59f 55c4 7dde                       *7...U.}.........*
value = 21 = 0x15


 d 0xDEC00004 , 1
dec00000:
machine check
Exception next instruction address: 0x000fb434
Machine Status Register: 0x00029210
Condition Register: 0x20004084
Bus Error Address Register: 0x2_0ec00004
Bus Error origin code: 0x010c0000
    Bus Error Address is physical
    PLB master 1 [D-cache fill] timeout error on write
Machine Check Status Register: 0xa0000000
    MCSR bits:  MCS DRPLBE

149bfc vxTaskEntry    +64 : shell ()
116f34 shell          +184: 116f60 ()
117150 shell          +3a0: execute ()
1172d0 execute        +d4 : yyparse ()
1330f8 yyparse        +704: 131558 ()
1316d4 yystart        +8e8: d ()
12297c d              +214: printf ()
shell restarted.

0
glblock (22)
3/9/2005 9:20:50 PM
Seem to of broken my sword on this one, but I have moved to just doing
a display memory at the vxWorks prompt.  I can display the first 4
bytes of the PCI  External Configuration Registers but not any after
that ?? They run from 0x0EC00000 to 0x0EC00007  NOTE: I have 0xD0000000
  TLB entry at   0x2  0x00000000

-> d 0xDEC00003,1
dec00000:       0000                                 *    ............*
value = 21 = 0x15

but this fails ??

-> d 0xDEC00004, 1
dec00000:
machine check
Exception next instruction address: 0x000fb434
Machine Status Register: 0x00029210
Condition Register: 0x20004084
Bus Error Address Register: 0x2_0ec00004
Bus Error origin code: 0x010c0000
    Bus Error Address is physical
    PLB master 1 [D-cache fill] timeout error on write
Machine Check Status Register: 0xa0000000
    MCSR bits:  MCS DRPLBE

149bfc vxTaskEntry    +64 : shell ()
116f34 shell          +184: 116f60 ()
117150 shell          +3a0: execute ()
1172d0 execute        +d4 : yyparse ()
1330f8 yyparse        +704: 131558 ()
1316d4 yystart        +8e8: d ()
12297c d              +214: printf ()
shell restarted.

0
glblock (22)
3/9/2005 10:20:14 PM
This is not meant to mean spirited, but you stand almost no chance of
figuring this stuff out by using vxWorks shell commands.
It's too deep for that.
You need low-level JTAG debug support for this kind of effort.
If you don't have one, get a Wind River ICE or Probe.
BTW, the 'd' shell command displays 16-bit words, not bytes.

0
gvarndell (209)
3/10/2005 11:52:47 AM
You stand little chance of figuring this out using vxWorks shell
commands.
Do you have a Wind River ICE or Probe?
If not, you need to get one or the other and use it to help you through
this.
It really is too complex to debug the way you're going about it.
BTW, the 'd' command, at least the way you're using it, displays 16-bit
words, not bytes.

0
gvarndell (209)
3/10/2005 2:24:54 PM
On 10 Mar 2005, gvarndell@hotmail.com wrote:

> ..., but you stand almost no chance of figuring this stuff out by
> using vxWorks shell commands.  It's too deep for that.  You need
> low-level JTAG debug support for this kind of effort...

I don't necessarily agree.  You do make a good point that the 'd'
command only performs word accesses.  The 'm' command is far better and
punching registers.  After the address, you can specify a width (1,2,4
for byte, 16 and 32 bits).  The unfortunate part is there is no
"write-only" mode.  There are some registers/hardware that require
that you don't read them; well, reading has a side effect of changing
the value.

It is also possible that the registers have some sort of timing
restriction.  If this is the case, I would write a small function to
perform the time critical portion of the setup.

I have done this dozens of time with different hardware.  The total
process might take longer, given a highly proficient JTAG/driver
developer.  However, I find that the 

  1) JTAG/BDM devices are rarely used as a percent of development time.
     This creates a demand for good storage of the JTAG/BDM.  I have had
     more than one "disappear".

  2) The JTAG/BDM often need to be upgraded to support a newer device.  
     This is often the reason for hunting for the thing.

  3) The JTAG/BDM environment is never the same as regular debugging, so
     you have to go and configure things, often using different tools.

  4) The JTAG/BDM that I have used don't operate with the vxWorks
     kernel.  Ie, you will step through kernel as it handles
     interrupts, etc.  The are good for startup code only.

  5) That money can be spent elsewhere.  A wiggler might be $50, but
     it is generally torture to use.  The quality devices can easily
     run 3-10k and the vxWorks support is often bad.

Ok, that is enough.  I have never used the WRS ICE/probe you
recommend, so maybe many of the issues I have are not relevant.
However, I haven't found hardware where you absolutely *NEED* a
JTAG/BDM/ICE.  They can be helpful.  However, often you need full-time
staff to tend to them; they did this at IBM/Motorola/NT.  Most people
can't afford to do that.

Anyways, it should be possible to use the shell, but the OP is going
about it in the wrong way.  I just figured out how to use an AcroMag
PMC I/O board on an MVE2600.  I did this by using the shell.  Hitting
registers from the shell worked, but not from code.  This is obviously
timing.  I then began to dig and realized that "eieio" and "sync"
instructions are needed.  The datasheet was correct otherwise.  The
code supplied by the vendor was not.  The 'm' command is much better
and you should be aware of registers with read side effects.

fwiw,
Bill Pringlemeir.

-- 
Two wrongs don't make a right, but three lefts do.

vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
0
spam_account (239)
3/10/2005 2:46:34 PM
No doubt, there are sw engineers who can bring up new hardware, even
something as complex as a custom 440gx board, using nothing more than
LEDs and a crude, low-level, printf -- and maybe you are one of them.
For someone so talented, getting to the point where enough stuff works
that s/he can start using the vxWorks shell is almost the same as being
finished.
But these 440 SOCs are complex as hell and getting the PCI/-X interface
working for the first time on a custom board is a lot different than
getting a COTS PMC module up on a COTS VME board that already has a
mature, functional BSP.
Does anyone NEED JTAG assistance? Not if your really talented. Not if
your time isn't costing someone money.
But you are absolutley correct in your fifth point -- and the money is
often spent to pay overtime.
One month of even a relatively junior engineer's time costs more than a
Wind River probe.

Instead of posting separately to apologize for the double post, let me
do it now.
Sorry about the double post.
Google seems to be loosing my posts lately and I thought the first one
fell into the bit bucket.

0
gvarndell (209)
3/10/2005 8:35:31 PM
I have the visionICE II JTAG connection on this board.
PPC440gx Rev B
128MRam
64 MFlash
Emacs0,2,3
1 serial
1 FPGA chip
1 Dual port Ram
all is up and running, all memory checks out, except the TI DSP chip on
the pci bus.  I do see the chip is wired strapped as device 0 which,
for bus 0 is the bridge?

I have run the >m 0xDEC00000 , 1 successfully up to 0xDEC0004 which
still fails.
I have run the setup with the JTAG disconnected and booting from
bootrom and not visionICE all with same results.

4 bytes from 0xDEC00000 is the PCI configuration address register
4 bytes from 0xDEC00004 is the PIC configuration data register

The PCI is in conventional mode.  The DSP chip is wired to the PIC bus.

Gary

0
glblock (22)
3/10/2005 8:59:00 PM
Some more info I have .from the PLB0_BESR reg..0xC000000

In the visionICE if i   dml 0xDEC00000 we get teh PLB0_BESR error

master 1 timeout error
master 1 was a read
master 1 bear is locked.

Gary

0
glblock (22)
3/10/2005 9:13:38 PM
On 10 Mar 2005, glblock@rockwellcollins.com wrote:

> 4 bytes from 0xDEC00000 is the PCI configuration address register
> 4 bytes from 0xDEC00004 is the PIC configuration data register

Are you sure that you don't need to write something to these registers
so that the full set becomes available on the device?  I know that
PCMCIA behaves this way for most cards.  If the card doesn't respond
to other address lines because it may conflict with other hardware
sharing the same bus/decoding.  That is part of the "beauty" of plug
and play.  Maybe the BSP has already mapped this.  Are you sure of
that?

fwiw,
Bill Pringlemeir.

-- 
My cousin  is an agoraphobic homosexual,  which makes it  kind of hard
for him to come out of the closet. - Bill Kelly
 
vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
0
spam_account (239)
3/10/2005 11:30:13 PM
On 10 Mar 2005, gvarndell@hotmail.com wrote:

> No doubt, there are sw engineers who can bring up new hardware, even
> something as complex as a custom 440gx board, using nothing more
> than LEDs and a crude, low-level, printf -- and maybe you are one of
> them.  For someone so talented, getting to the point where enough
> stuff works that s/he can start using the vxWorks shell is almost
> the same as being finished.  But these 440 SOCs are complex as hell
> and getting the PCI/-X interface working for the first time on a
> custom board is a lot different than getting a COTS PMC module up on
> a COTS VME board that already has a mature, functional BSP.  Does
> anyone NEED JTAG assistance? 

Thanks for such a back handed compliment.  I have done many custom
BSPs.  I guess to each his own.  I have also used many JTAGs and most
are crap, in my opinion.  I would rather have a shell and a logic
analyzer or a DSO.

Many times I created polled mode "boot loader" that would allow some
debugging of the vxWorks startup code.  I didn't realize that the OP
was trying to get the PCI HW functioning while booting.  I would stop
doing that.

It sounds like you are having a bad day or something.  I didn't mean
to start some flame war.  I was hoping that you would tell me that WRS
JTAG was leaps and bounds better than any other JTAG on the planet.
Anyways, I am sure that JTAG can help if you have it.

fwiw,
Bill Pringlemeir.

-- 
It's Not What You Know That Matters... It's Knowing What You Don't.  -
Hannu Poropudas.

vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
0
spam_account (239)
3/10/2005 11:40:10 PM
Why are you reading the configuration address register? What are you
trying to accomplish by doing so?
Do you realize that  'dml <addr>' tries to display (and thus reads) a
bunch of words, not just the word at the address you entered?

PCI config reads/writes are done by *writing* a value containing the
bus, device, function, and register offset numbers (and a bit for type
0 or 1) to the configuration address register.
This write should then be followed by a read/write from/to the
configuration data register.

Maybe this excerpt (below) from the gx user manual will help. Pay
attention to the note below. Have you enabled the bridge PCI mastering?
Have you configured the bridge at all? If so, where did you get the
initialization code? Did you get, or are you currently using, the BSPs
I mentioned earlier?

19.5.1.1 CONFIG_ADDRESS Register
This register controls what type of cycle is generated when CONFIG_DATA
is accessed. Its fields are shown in Figure 19-3.
  << the graphic didn't paste, but you have the manual, right?>>
See PCI Specification, Version 2.3 for details about how the fields are
used. Bits 31 to 24 are reserved and
always return a 0 when read. Bit 0 determines whether the configuration
cycle is Type 0 or Type 1.

19.5.1.2 CONFIG_DATA Register
Accesses to CONFIG_DATA cause one of two things to occur depending on
the value of CONFIG_ADDRESS:
=B7 Generate a Type 0 configuration cycle on the PCI bus. This happens
when the Type bit (bit 0) is low. During
the address phase of the configuration cycle, pci_ad[16] is asserted if
the Device Number is 0,
pci_ad[17] is asserted if the Device Number is 1, pci_ad[18] is
asserted if the Device Number is 2, and so
forth. pci_ad[16] through pci_ad[31] are all low if the device number
is 16 through 31.
=B7 Generate a Type 1 Configuration Cycle on the PCI bus. This happens
when the Type bit (bit 1) is high.

NOTE: The PLB-PCIX Bridge will not respond as a PLB slave to accesses
to the CONFIG_DATA register if
the PCI Master Enable bit in the PCI command register is zero because
accesses to the CONFIG_DATA register
require the PLB-PCIX Bridge to become a PCI master.

0
gvarndell (209)
3/11/2005 11:57:03 AM
I wasn't trying to compliment or flame you -- back handed or otherwise.
Sorry you took it that way. You enaged me in debate and I debated back.
I had a great day yesterday.

0
gvarndell (209)
3/11/2005 12:00:34 PM
Answers to your questions:
Yes I have the 440gx manual and have read, an read, it. Obviously I
must be missing something.

 I am running pciAutoCfg and it crashes when tring to query bus 0
device 1 function 0.

I was hoping that with the   >m 0xdec00004 , 1       call I could at
least see if one byte could be read.

I double checked all my #defines and found the PCIX0_CMD[PME] bit was
being set to 0 and not 1 in the bridge configuration, all the other bit
defines seem ok.  Changing this keeps my problem at the same location
the only difference is the call now never returns.  I dont get the
memory timeout error but it never returns...arg!.. It is a Type 0
cycle.  I am hoping that the PCI is not waiting for an answer, it would
seem the auto config should be very fast.  The template is based on the
WRS /  ocotea PPC440 code , we just have a few HW changes and this DSP
chip..The pciAutoCfg is WRS code recommended to configure the PIC bus.
I was hoping it would find the DSP chip.

0
glblock (22)
3/11/2005 1:42:49 PM
Hhhmmm, I'm about at the end of what I can do here.
Are you using an external arbiter? If not, double check internal
arbiter settings.
What about PCI clocking? I suppose the bridge might hang if there's no
PCI clock.
Check for applicable errata. Try to get a PCI bus analyzer. Or a
hardware person armed with a logic analyzer.

0
gvarndell (209)
3/11/2005 2:32:38 PM
Reply: