Initial Value of PCI Mask Register0/1 of MPC8270

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Initial Value of PCI Mask Register0/1 of MPC8270

2,939 次查看
Ohata
Contributor I

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.

标记 (1)
0 项奖励
回复
13 回复数

2,839 次查看
yipingwang
NXP TechSupport
NXP TechSupport

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.

0 项奖励
回复

2,803 次查看
Ohata
Contributor I

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.

0 项奖励
回复

2,699 次查看
yipingwang
NXP TechSupport
NXP TechSupport

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

0 项奖励
回复

2,675 次查看
Ohata
Contributor I

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)

0 项奖励
回复

2,544 次查看
Ohata
Contributor I

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.

0 项奖励
回复

2,529 次查看
yipingwang
NXP TechSupport
NXP TechSupport

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.

0 项奖励
回复

2,526 次查看
Ohata
Contributor I

Thank you. I will check on it.

0 项奖励
回复

2,523 次查看
yipingwang
NXP TechSupport
NXP TechSupport

Welcome

0 项奖励
回复

2,493 次查看
Ohata
Contributor I

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)

0 项奖励
回复

2,671 次查看
yipingwang
NXP TechSupport
NXP TechSupport

Got it.

0 项奖励
回复

2,588 次查看
Ohata
Contributor I

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

0 项奖励
回复

2,584 次查看
yipingwang
NXP TechSupport
NXP TechSupport

Confirming with the AE team.

0 项奖励
回复

2,874 次查看
yipingwang
NXP TechSupport
NXP TechSupport

Discussing with the AE team.

0 项奖励
回复