Hi,
we are currently struggling with an issue related to PCI autoinitialization using an external 24C1024 eeprom connected to the C6454. The C6454 is connected through an XIO2001 PCIe bridge to a Patsburg (Sandy bridge) chipset on the other end. What we observe is that when the eeprom is correctly programmed with a correct checksum according to SPRUE60 chapter 12.4, then autoinitalization works correctly, and the device appears on the PC side with our SubVEN + SubDID as intended and the Vendor+ Device is also correct as 0x104C / 0xB000. The bootmode used is 14 (for PCI boot).
Reading out the JTAG device registers, we see Mfg ID=0x0017,Part=0x008A, variant=0x0002, which according to the SPRZ234 table 3 corresponds to silicon revision 2.1. The PCI bus is clocked at 66 MHz.
Now, before the eeprom has been programmed, it normally contains all FF (or random data) which means that the checksum of the PCI autoinitialization data will be wrong, and the DSP will reread the eeprom contents 50 (!) times before loading the default PCI configuration into the PCI config space. In our application, CLKIN1=50 MHz, and according to SPRUEC6G this means that the I2C bus is clocked at CLKIN1/6600 = 7.57 kHz. At 50 retries, the default PCI configuration will not be loaded until close to 10 seconds has passed !!!
During those 10 seconds, any attempt to access the PCI config space over the PCI bus (during BIOS enumeration of PCI devices) will lock up the PCI bus causing the PC to hang indefinitely - i.e. beyond those 10 seconds. No BIOS will (or should) wait for 10 seconds before trying to enumerate PCI devices, thus this is a major problem for the PCI boot mode.
Again, according to SPRUEC6G, table 8, it seems the I2C clock was clocked at a more reasonable 113 kHz (at CLKIN=50 MHz) for silicon revision 1.1 when using bootmode 14, but that this was changed when making silicon revision 2.1.
What we would like to do is to detect a "default PCI config" during PC enumeration, and then download a small program to configure the eeprom with the correct values to be used for autoinitilization. This currently seems impossible, unless there is a way to increase the default speed of the I2C bus for PCI init (bootmode 14) or reduce the number of retries from 50 to something more reasonable, like 0, 1 or 2. So, to my questions:
How can we reduce the time before the default PCI configuration is loaded upon PCI eeprom checksum failure?
How can we avoid the PCI and the PCIe buses being hung when the DSP does not respond to config space accesses while the eeprom is being re-read by the builtin bootloader?
Thanks ,Torbjorn
Torbjorn BakkeHow can we reduce the time before the default PCI configuration is loaded upon PCI eeprom checksum failure?
I've been reading through the bootloader documentation trying to figure out something to help you. I'm not positive, but I think I may have found a way.
Based on my reading of the doc (sorry, I have not actually tried a "fancy" boot like this one) it appears that it should start with I2C boot, reconfigure I2C for 400 kHz, and then reboot to the PCI auto-init mode but now with 400 kHz I2C.
Hopefully I'm not steering you wrong here -- I was hesitant to reply but since you've not gotten any other replies I thought I would go for it... Another option would be to use the I2C to directly load a small, simple bootloader to memory. Your bootloader code could then configure the I2C at the appropriate speed and setup the PCI in a more timely manner.
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Thank you for getting back to me on this, it is much appreciated.
I agree that if we switch to I2C boot mode for the initial boot, it may perhaps be possible to increase the I2C frequency for a subsequent pci boot. However, getting back to the initial issue which was related to starting with an unprogrammed eeprom and downloading a software snippet to program it, it wouldn't help much. The only difference would really be that we would have to pre-program the eeprom with the I2C bootloader instead of the PCI config space data.
I guess this means that the programming of the I2C eeprom will have to be done during boundary scan testing and that it cannot be deferred to a later test stage by downloading a "eeprom-initialization" program to the dsp. In that case, we might as well program the PCI config space data directly instead of making a more complex boot sequence.
If the eeprom is corrupted for some reason (however unlikely), the resulting PCI hang will limit our ability to detect the root cause of booting errors in our end product (at a customer site), but it will be manageable.
It seems to me that this should have been working fine on silicon revision 1.1, but that the mechanism was broken with the updated bootloader that was introduced with silicon revisions 2.1 and 3.1 (because of the reduced I2C clock frequency in PCI boot mode).
In my opinion, the C6454/C6455 errata (SPRZ234) should be updated to describe this behaviour, and that PCI / PCIe hangs may occur on the host as a result.
Thank you for your support :)
Ok, now your scenario makes more sense to me. I was a bit confused by why the EEPROM was blank in the first place, but now I get it. I agree that it would be best to avoid the scenario altogether by programming the PCI init values into the EEPROM during manufacturing. That should also make the complex bootloader unnecessary.