MCF54455 PCI Class Code Help Needed

[michaelthorson]

We have a board that was made by a contract engineering house.  It is a PCI board powered by a MCF54455.  The PCI board will sometimes cause the PC to hang at the initial BIOS screen.

One thing that we have noticed is that the board is using PCI Class Code 0x08_8000 (System peripheral).  I am seeing the same on a Linux OS and on a Windows 7 OS.

According to the MCF54455 Reference Manual, Section 22.3.1.3 Revision ID/Class Code Register (PCICCRIR)—PCI Dword 2:

Bits 31–8 = Class Code     This field is read-only and represents the PCI Class Code assigned to processor. Its value is: 0x06_8000. (Other bridge device).

PCICCRIR is not set anywhere in my project (and it is read-only), so I would assume it would take the chip default of 0x06_8000, but it is not.

Can anyone help me fix this?

[michaelthorson]

So I am a complete novice at this, but I am learning quickly...

I have now found out that the class code is being changed by a serial bootloader file being loaded by UBoot.  I have confirmed that the original programmer changed the class code.  Now I have to figure out how to change the config file.

[miduo]

Change the Uboot config is not so easy as TomE metioned.  Actually I do not think that the PCI board sometimes cause the PC to hang at the initial BIOS screen is really because the PCI class itself.

[TomE]

I assume it is being changed from "Other Bridge Device" to "System Peripheral" on purpose.

I'm guessing the Coldfire chip is running Linux of some sort. Some modern distributions of Linux come with tools that let you change the U-Boot configuration from Linux. If your one doesn't have that, you have to change the configuration from U-Boot.

Which generally talks over a Serial Console. One of the UARTs on the CPU is probably set up for a serial console. It may not have the RS232 level converters on board - it is more common to have a "3.3V TTL RS232" and a socket for an external board that has the converter (or connects to a standard USB to 3.3V RS232 converter).

So find the port, connect to it at 115,200, start hammering Control-C and turn the thing on. Then type "help".

U-Boot is as complicated as some operating systems. It is an operating system, with lots of commands, a scripting language, network connectivity and so on.

WebHome < U-Boot < DENX

> The PCI board will sometimes cause the PC to hang at the initial BIOS screen.

Have you tried different (including older) PCs? I'm thinking of one that is SLOWER to start up.

I've had a read through the MCF54455 PCI chapter and am having trouble working out how the PCI card starts up fast enough for the PC to work with it. As far as I can see there's a race between the PCI card reset running U-Boot and changing that ID (and setting up other hardware) and then running the Application on that card and the PC's boot starting and then hunting through the PCI cards to see what's there. The PCI Bus has a reset INPUT to the card, but the MCF54455 documents that pin as an OUTPUT for when it is the "bus master" controlling the other devices. Maybe it tried to keep the PCI bus reset until it has woken up and the PC's boot doesn't like that.

Maybe when used as an "agent" there has to be a different connection to the PCI Reset signal. Your schematics should show how this works.

Table 11-4 in the manual documents CCR[PCIMODE], which selects "host or agent mode". I'm guessing your board has to be an agent. In that case "22.1.4 Modes of Operation" details that "Target retries are automatically issued for any incoming PCI configuration accesses to allow for initialization software to set up the BAR configuration before PCI enumeration." That must be the mechanism that forces the PC to delay until the PCI card is up. Maybe there's a limit on how long it will wait, or maybe it never comes up (and that is what is stalling the PC Boot).

Tom