Initial Value of PCI Mask Register0/1 of MPC8270

[Ohata]

We are using the MPC8270. According to the datasheet, the values of PCI Mask Register0/1 are all 0 right after the power is turned on. However, when checked with a debugger, they appear to be undefined. Could you please explain why this is happening? We are attaching a dump screen near the relevant area immediately after power-on."

We appreciate your assistance in this matter.

[yipingwang]

Can you load/read these values through other means for example uboot or CodeWarrior TAP?I don't understand why Trace32 is not loading the values properly.

[Ohata]

We read it after Uboot booting on a different type of board. As per the attached document, it becomes undefined just like the previous example.
This defect is not individual. Also, the same defect can be confirmed on a different type of board.
From this, we think that the initial values of these registers are not All 0 but undefined.

[yipingwang]

Could you detail the issue you are facing due to uninitialized values?

[Ohata]

There is no actual harm due to the undefined values, we just want to know the facts. What we want to know further is whether there are other places with initial states different from the datasheet besides this register.

The reason for this inquiry is as follows. We believe that the correct sequence is to set the PCIMSK0 register before enabling the Valid bit of PCIBR0, but a software bug was found that sets them in the opposite order. There are cases where it starts up normally and cases where it does not, and we believe that the undefined initial value of PCIMSK0 is the cause, which is why we are confirming this time. (If the initial value is All0, it should never start up)

[Ohata]

I'm currently confirming with the AE team, but if you have a board with the same CPU, you should be able to confirm that the initial value of this register is undefined by turning on the power with the flash in erase state and connecting the debugger.

[yipingwang]

Please refer to the following update from the AE team.

MPC8280 is an old device and we do not have a board or design support to test out.
My suspicion is on the memory attributes of the IMMRBAR space. Ideally the register space should not be cacheable. I am not sure how Lauterbach can be configured to do the read from JTAG as master and not Core.
All I would like to ensure that cache is out of picture when we read these two registers.

[Ohata]

Thank you. I will check on it.

[yipingwang]

Welcome

[Ohata]

The dump screen from Lauterbach was obtained with the cache disabled.

The meaning of "ANC" near the address on the debugger's dump screen is as follows: A=Given address is physical (bypass MMU) NC=No Cache (access with caching inhibited)

[yipingwang]

Got it.

[Ohata]

Are there any discrepancies between the 'initial values' stated in the datasheet and the actual product?

[yipingwang]

Confirming with the AE team.

[yipingwang]

Discussing with the AE team.