PPC General Purpose Register Question

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

Hello,

I am trying to modify the Sandpoint BSP IPL to get it working on our custom
hardware, but I am experienceing some difficulties. So I decided to write a
small assembly program that just loads the General Purpose Registers with
some data. However I am finding that all the data does not get stuffed into
the registers. The processor is a PPC 8245 that is on our own custom
hardware board. The program, which is running out of a am29f040 flash
device, looks like this:
…file “except2.s”
…text
…align 2
…space (0x100) // 0 —> 0x100
…global entry_vec
entry_vec:
b system_reset // 0x100

system_reset:
//All registers should be filled with 0xABCD1234
lis 0, 0xABCD //do for all 31 GPR’s
ori 0,0, 0x1234
lis 1, 0xABCD
ori 1,1, 0x1234
… //copy an paste code so all lines are identical except for the
GPR number
lis 30, 0xABCD
ori 30,30, 0x1234
lis 31, 0xABCD
ori 31,31, 0x1234
I then go and read the GPR registers through the JTAG interface using a
Mcgregior Wiggler JTAG device and the registers are set as follows:
GPR0 ABCD0000 GPR1 ABCD1234
GPR2 ABCD0000 GPR3 ABCD1234
GPR4 ABCD0000 GPR5 ABCD1234
GPR6 ABCD0000 GPR7 ABCD1234
GPR8 ABCD0000 GPR9 ABCD1234
GPR10 ABCD0000 GPR11 ABCD1234
GPR12 ABCD0000 GPR13 ABCD1234
GPR14 ABCD0000 GPR15 ABCD1234
GPR16 ABCD0000 GPR17 ABCD1234
GPR18 ABCD0000 GPR19 ABCD1234
GPR20 ABCD0000 GPR21 ABCD1234
GPR22 ABCD0000 GPR23 ABCD1234
GPR24 ABCD0000 GPR25 ABCD1234
GPR26 ABCD0000 GPR27 ABCD1234
GPR28 ABCD0000 GPR29 ABCD1234
GPR30 ABCD0000 GPR31 ABCD1234
Just to give an idea of what else I have seen here is another output:
GPR0 ABCD1234 GPR1 ABCD0000
GPR2 ABCD1234 GPR3 ABCD0000
GPR4 ABCD1234 GPR5 FEC01234
GPR6 FEE00000 GPR7 ABCD0000
GPR8 ABCD1234 GPR9 ABCD0000
GPR10 ABCD1234 GPR11 ABCD0000
GPR12 ABCD1234 GPR13 ABCD0000
GPR14 ABCD1234 GPR15 ABCD0000
GPR16 ABCD1234 GPR17 ABCD0000
GPR18 ABCD1234 GPR19 ABCD0000
GPR20 ABCD1234 GPR21 ABCD0000
GPR22 ABCD1234 GPR23 ABCD0000
GPR24 ABCD1234 GPR25 ABCD0000
GPR26 ABCD1234 GPR27 ABCD0000
GPR28 ABCD1234 GPR29 ABCD0000
GPR30 ABCD1234 GPR31 ABCD0000
From the SW side of things I should just be able to write to these registers
at any point correct? I.E. I don’t need to set the processor up to write to
the GPR. (Just checking)
From the HW side of things this is on a custom board that is currently being
debugged along with the firmware. So could it be some sort of hardware
problem, power, clocking or whatever?
Does anyone have any ideas why this could be acting this way?

Thanks in advance.
Mike

2

lis 0, 0xABCD file://do for all 31 GPR’s
ori 0,0, 0x1234

The convention to load a register with a 32bit quantity is generally:

addis r3, r0, 0xABCD
ori r3, r3, 0x1234

From the SW side of things I should just be able to write to these
registers
at any point correct? I.E. I don’t need to set the processor up to write
to
the GPR. (Just checking)

yes.

From the HW side of things this is on a custom board that is currently
being
debugged along with the firmware. So could it be some sort of hardware
problem, power, clocking or whatever?
Does anyone have any ideas why this could be acting this way?

Does the same code have the same behaviour on the reference sandpoint board?

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

3

The convention to load a register with a 32bit quantity is generally:

addis r3, r0, 0xABCD
ori r3, r3, 0x1234

Actually, lis is a synthetic instruction for exactly what I posted (addis) -
sorry.

From the HW side of things this is on a custom board that is currently
being
debugged along with the firmware. So could it be some sort of hardware
problem, power, clocking or whatever?
Does anyone have any ideas why this could be acting this way?

Another thing to look at might be the memory controller - The executing code
might not be executing quite the way you think it is.

Have you steped through the code with the BDM (not just looking at the
results)? To see if what you think is occuring, really is.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

4

Hi Adam,

Sorry went on a short vacation.

I found out today that the code is not executing the way I thought it was,
but I don’t know why?

I am finding that the order in which code execution occurs is different
between running from FLASH and running from RAM.

From RAM the code executes as follows:

  1. b  system_reset (Instruction 2)
  2. lis 0,0xABCD
  3. ori 0,0,0x1234
  4. lis 1,0xABCD
  5. ori 1,1,0x1234


    However when I run it from FLASH I am finding that the code is not executed
    in the correct sequence. It is pulled from flash and executed as follows:
  6. b system_reset (Instruction 2)
  7. ori 0,0,0x1234
  8. lis 0, 0xABCD
  9. lis 1,0xABCD
  10. ori 1,1,0x1234

I have no idea why is the code is executed differently from flash and ram,
or how I can get the code to execute sequentially from flash?

Thanks,
Mike



“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ajgqj2$om5$1@nntp.qnx.com…

The convention to load a register with a 32bit quantity is generally:

addis r3, r0, 0xABCD
ori r3, r3, 0x1234

Actually, lis is a synthetic instruction for exactly what I posted
(addis) -
sorry.

From the HW side of things this is on a custom board that is currently
being
debugged along with the firmware. So could it be some sort of hardware
problem, power, clocking or whatever?
Does anyone have any ideas why this could be acting this way?

Another thing to look at might be the memory controller - The executing
code
might not be executing quite the way you think it is.

Have you steped through the code with the BDM (not just looking at the
results)? To see if what you think is occuring, really is.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

5

“Mike Toreno” <no.spam@address.com> wrote in message
news:ak1ali$8u0$1@nntp.qnx.com…

Hi Adam,

Sorry went on a short vacation.

I found out today that the code is not executing the way I thought it was,
but I don’t know why?

I am finding that the order in which code execution occurs is different
between running from FLASH and running from RAM.

From RAM the code executes as follows:

  1. b  system_reset (Instruction 2)
  2. lis 0,0xABCD
  3. ori 0,0,0x1234
  4. lis 1,0xABCD
  5. ori 1,1,0x1234


    However when I run it from FLASH I am finding that the code is not
    executed
    in the correct sequence. It is pulled from flash and executed as follows:
  6. b system_reset (Instruction 2)
  7. ori 0,0,0x1234
  8. lis 0, 0xABCD
  9. lis 1,0xABCD
  10. ori 1,1,0x1234

I have no idea why is the code is executed differently from flash and ram,
or how I can get the code to execute sequentially from flash?

Have you taken a look at the contents of flash w/ your code in it? Does a
disassembly of the memory area match (flash needs to be linearly
addressable) what you expect it to? How are you burning your program to
flash?

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

6

My code is burned sequentially into the flash chip. I.E. I read the flash
chip back through the programmer and I can see that the instruction order
and the address at which the instruction is placed is correct:
Flash Address Instruction
0xfff00100 b sys_rst (104)
0xfff00104 lis 0, 0xABCD
0xfff00108 ori 0, 0, 0x1234
0xfff0010c lis 1, 0xABCD
0xfff00120 ori 1, 1, 0x1234

But when I look at the flash chip when it is on my board the instructions
are listed out of sequence. That is the address in which the data is burned
into flash does not match the address in which the data is pulled from the
chip and executed. Listed below is how the instructions are stored on the
chip (Flash Address) and how they are really pulled from the flash and
executed by the processor (Execution Address).
Flash Address Instruction ExecutionAddress
0xfff00100 b sys_rst (104) 0xfff00100 (1st instruction
executed)
0xfff00104 lis 0, 0xABCD 0xfff00108 (3rd instruction executed)
0xfff00108 ori 0, 0, 0x1234 0xfff00104 (2nd instruction
executed)
0xfff0010c lis 1, 0xABCD 0xfff0010C (4th instruction executed)
0xfff00120 ori 1, 1, 0x1234 0xfff00120 (5th instruction
executed)

What we don’t follow is why the processor pulls and executes the
instructions out of order.

Mike

“Mike Toreno” <no.spam@address.com> wrote in message
news:ajdsgm$3tk$1@nntp.qnx.com…

Hello,

I am trying to modify the Sandpoint BSP IPL to get it working on our
custom
hardware, but I am experienceing some difficulties. So I decided to write
a
small assembly program that just loads the General Purpose Registers with
some data. However I am finding that all the data does not get stuffed
into
the registers. The processor is a PPC 8245 that is on our own custom
hardware board. The program, which is running out of a am29f040 flash
device, looks like this:
.file “except2.s”
.text
.align 2
.space (0x100) // 0 —> 0x100
.global entry_vec
entry_vec:
b system_reset // 0x100

system_reset:
//All registers should be filled with 0xABCD1234
lis 0, 0xABCD //do for all 31 GPR’s
ori 0,0, 0x1234
lis 1, 0xABCD
ori 1,1, 0x1234
… //copy an paste code so all lines are identical except for the
GPR number
lis 30, 0xABCD
ori 30,30, 0x1234
lis 31, 0xABCD
ori 31,31, 0x1234
I then go and read the GPR registers through the JTAG interface using a
Mcgregior Wiggler JTAG device and the registers are set as follows:
GPR0 ABCD0000 GPR1 ABCD1234
GPR2 ABCD0000 GPR3 ABCD1234
GPR4 ABCD0000 GPR5 ABCD1234
GPR6 ABCD0000 GPR7 ABCD1234
GPR8 ABCD0000 GPR9 ABCD1234
GPR10 ABCD0000 GPR11 ABCD1234
GPR12 ABCD0000 GPR13 ABCD1234
GPR14 ABCD0000 GPR15 ABCD1234
GPR16 ABCD0000 GPR17 ABCD1234
GPR18 ABCD0000 GPR19 ABCD1234
GPR20 ABCD0000 GPR21 ABCD1234
GPR22 ABCD0000 GPR23 ABCD1234
GPR24 ABCD0000 GPR25 ABCD1234
GPR26 ABCD0000 GPR27 ABCD1234
GPR28 ABCD0000 GPR29 ABCD1234
GPR30 ABCD0000 GPR31 ABCD1234
Just to give an idea of what else I have seen here is another output:
GPR0 ABCD1234 GPR1 ABCD0000
GPR2 ABCD1234 GPR3 ABCD0000
GPR4 ABCD1234 GPR5 FEC01234
GPR6 FEE00000 GPR7 ABCD0000
GPR8 ABCD1234 GPR9 ABCD0000
GPR10 ABCD1234 GPR11 ABCD0000
GPR12 ABCD1234 GPR13 ABCD0000
GPR14 ABCD1234 GPR15 ABCD0000
GPR16 ABCD1234 GPR17 ABCD0000
GPR18 ABCD1234 GPR19 ABCD0000
GPR20 ABCD1234 GPR21 ABCD0000
GPR22 ABCD1234 GPR23 ABCD0000
GPR24 ABCD1234 GPR25 ABCD0000
GPR26 ABCD1234 GPR27 ABCD0000
GPR28 ABCD1234 GPR29 ABCD0000
GPR30 ABCD1234 GPR31 ABCD0000
From the SW side of things I should just be able to write to these
registers
at any point correct? I.E. I don’t need to set the processor up to write
to
the GPR. (Just checking)
From the HW side of things this is on a custom board that is currently
being
debugged along with the firmware. So could it be some sort of hardware
problem, power, clocking or whatever?
Does anyone have any ideas why this could be acting this way?

Thanks in advance.
Mike

7

“Mike Toreno” <no.spam@address.com> wrote in message
news:ak2p69$369$1@nntp.qnx.com…

But when I look at the flash chip when it is on my board the instructions
are listed out of sequence. That is the address in which the data is
burned
into flash does not match the address in which the data is pulled from the
chip and executed. Listed below is how the instructions are stored on the
chip (Flash Address) and how they are really pulled from the flash and
executed by the processor (Execution Address).
Flash Address Instruction ExecutionAddress
0xfff00100 b sys_rst (104) 0xfff00100 (1st instruction
executed)
0xfff00104 lis 0, 0xABCD 0xfff00108 (3rd instruction
executed)
0xfff00108 ori 0, 0, 0x1234 0xfff00104 (2nd instruction
executed)
0xfff0010c lis 1, 0xABCD 0xfff0010C (4th instruction
executed)
0xfff00120 ori 1, 1, 0x1234 0xfff00120 (5th instruction
executed)

While watching the execution, (looking at the PC register) is the execution
address in your listing really what your PC is doing (ie. PC = 0xfff00100,
then PC=0xfff00108, then PC=0xfff00104)?

If so, then perhaps the flashchip your using on your board isn’t matching
the spec of what the board expects. Or the flashchip isn’t wired properly
on the board and your address lines aren’t correct. Do you see the same
pattern occuring if the program is longer, triggering the same lower address
lines?

Also, perhaps check the voltage you’re supplying your flash - the AMD29F040
requires 5 volts, and wierd stuff happens to flash when it’s under/over
powered.

If you didn’t manufacture your custom board, I’d speak to the manufacturer.

What we don’t follow is why the processor pulls and executes the
instructions out of order.

The CPU is allowed to execute instructions out of order, speculatively, and
do branch folding. That said the instruction effects are commited and
visable in program order (otherwise not much would work on PPC :slight_smile: ).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

8

Adam Thanks a bunch for the help. It turned ot that the hardware guy wired
up the bus lines (bits 2&3) backwards. That is what was causing the problem,
just like you mentioned.
Thanks again for the assistance,
Mike

“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ak2skf$7f5$1@nntp.qnx.com…

“Mike Toreno” <> no.spam@address.com> > wrote in message
news:ak2p69$369$> 1@nntp.qnx.com> …

snip
But when I look at the flash chip when it is on my board the
instructions
are listed out of sequence. That is the address in which the data is
burned
into flash does not match the address in which the data is pulled from
the
chip and executed. Listed below is how the instructions are stored on
the
chip (Flash Address) and how they are really pulled from the flash and
executed by the processor (Execution Address).
Flash Address Instruction ExecutionAddress
0xfff00100 b sys_rst (104) 0xfff00100 (1st instruction
executed)
0xfff00104 lis 0, 0xABCD 0xfff00108 (3rd instruction
executed)
0xfff00108 ori 0, 0, 0x1234 0xfff00104 (2nd instruction
executed)
0xfff0010c lis 1, 0xABCD 0xfff0010C (4th instruction
executed)
0xfff00120 ori 1, 1, 0x1234 0xfff00120 (5th instruction
executed)

While watching the execution, (looking at the PC register) is the
execution
address in your listing really what your PC is doing (ie. PC =
0xfff00100,
then PC=0xfff00108, then PC=0xfff00104)?

If so, then perhaps the flashchip your using on your board isn’t matching
the spec of what the board expects. Or the flashchip isn’t wired properly
on the board and your address lines aren’t correct. Do you see the same
pattern occuring if the program is longer, triggering the same lower
address
lines?

Also, perhaps check the voltage you’re supplying your flash - the
AMD29F040
requires 5 volts, and wierd stuff happens to flash when it’s under/over
powered.

If you didn’t manufacture your custom board, I’d speak to the
manufacturer.

What we don’t follow is why the processor pulls and executes the
instructions out of order.

The CPU is allowed to execute instructions out of order, speculatively,
and
do branch folding. That said the instruction effects are commited and
visable in program order (otherwise not much would work on PPC > :slight_smile: > ).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

9

Mike Toreno <no.spam@address.com> wrote in message
news:ak5pel$pma$1@nntp.qnx.com…

Adam Thanks a bunch for the help. It turned ot that the hardware guy wired
up the bus lines (bits 2&3) backwards. That is what was causing the
problem,
just like you mentioned.
Thanks again for the assistance,

NP. Our hardware guys gave me that idea. I’m sure if you made the program
long enough, you would have see the address line issue, since the pattern
would repeat itself.

Hope the rest of the board is wired to the bus properly :wink:

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

10

Good call Adam!

“Mike Toreno” <no.spam@address.com> wrote in message
news:ak5pel$pma$1@nntp.qnx.com…

Adam Thanks a bunch for the help. It turned ot that the hardware guy wired
up the bus lines (bits 2&3) backwards. That is what was causing the
problem,
just like you mentioned.
Thanks again for the assistance,
Mike

“Adam Mallory” <> amalloryNOSPAM@NOSPAMqnx.com> > wrote in message
news:ak2skf$7f5$> 1@nntp.qnx.com> …
“Mike Toreno” <> no.spam@address.com> > wrote in message
news:ak2p69$369$> 1@nntp.qnx.com> …

snip
But when I look at the flash chip when it is on my board the
instructions
are listed out of sequence. That is the address in which the data is
burned
into flash does not match the address in which the data is pulled from
the
chip and executed. Listed below is how the instructions are stored on
the
chip (Flash Address) and how they are really pulled from the flash and
executed by the processor (Execution Address).
Flash Address Instruction ExecutionAddress
0xfff00100 b sys_rst (104) 0xfff00100 (1st instruction
executed)
0xfff00104 lis 0, 0xABCD 0xfff00108 (3rd instruction
executed)
0xfff00108 ori 0, 0, 0x1234 0xfff00104 (2nd instruction
executed)
0xfff0010c lis 1, 0xABCD 0xfff0010C (4th instruction
executed)
0xfff00120 ori 1, 1, 0x1234 0xfff00120 (5th instruction
executed)

While watching the execution, (looking at the PC register) is the
execution
address in your listing really what your PC is doing (ie. PC =
0xfff00100,
then PC=0xfff00108, then PC=0xfff00104)?

If so, then perhaps the flashchip your using on your board isn’t
matching
the spec of what the board expects. Or the flashchip isn’t wired
properly
on the board and your address lines aren’t correct. Do you see the same
pattern occuring if the program is longer, triggering the same lower
address
lines?

Also, perhaps check the voltage you’re supplying your flash - the
AMD29F040
requires 5 volts, and wierd stuff happens to flash when it’s under/over
powered.

If you didn’t manufacture your custom board, I’d speak to the
manufacturer.

What we don’t follow is why the processor pulls and executes the
instructions out of order.

The CPU is allowed to execute instructions out of order, speculatively,
and
do branch folding. That said the instruction effects are commited and
visable in program order (otherwise not much would work on PPC > :slight_smile: > ).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
\

11

Bill Caroselli (Q-TPS) <QTPS@EarthLink.net> wrote in message
news:ak5vtu$41k$1@inn.qnx.com…

Good call Adam!

Thanks, but it was a team effort :wink:

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>