powerpc startup

Frank,

here is how to debug the setup.

First of all, an opcode 4BFF7FE4 at address -4 (aka 0xfffffffc) as

(gdb) x/x -4

0xfffffffc: 0x4bff7fe4

will resolve to the following instruction

(gdb) x/i -4

0xfffffffc: b 0xffff7fe0

In other words, assuming your boot peripheral is correct, the processor will jump to 0xffff7fe0. That's where you need to map the .boot0 section or more correctly _boot0.

Now, to see what's happening you should bring the DEBUG_HALT signal of the PPC to a user IO pin, for example one of the push buttons on the board. The DEBUG_HALT signal allows stopping the processor, i.e. keep it at the reset vector after a reset or after loading the FPGA bitstream. Assert the DEBUG_HALT signal and load the bitstream. Connect with XMD. Deassert DEBUG_HALT. The PPC is still stopped because of the debugger. Single-step the processor. By following the PC you will be able to see what the PPC is doing. If something in your setup is wrong you will most likely end up at address 0x????0700, the exception vector address for an invalid instruction exception.

To monitor the bus transactions instantiate ChipScope (BTW, instead of bringing the DEBUGH_HALT signal above to a user IO pin you could hook it up to a Virtual IO port) and trigger on the PLB request signal.

If you try to minimize the boot code, i.e. not use a BRAM at the reset vector, you might want to have a look at application note XAPP571

- Peter

Frank van Eijkelenburg wrote:

Hi Peter,

I am not able to use the debug halt signal. I am using a customized board and it does not have buttons which I can use (I will give it a try by using virtual IO with chipscope). I understand that the principle of starting up like I described should work?! If I convert the generated .elf file to a binary file, I see that the boot0 section is laid at the correct address. I can also see here what value my user peripheral should return ("4BFF7FE4"). It is still not working, I checked the peripheral by placing it to another location and have brams from 0xffff0000 till 0xffffffff. So a normal startup is done and software is running fine. Then I do a 32-bits read action to my peripheral and I read what I expected to read. What could be wrong?

Frank

When you wrote your peripheral did you take into account that it has to handle four-word cache line transactions? The instruction side of the processor will issue such a transaction to the peripheral when it comes out of reset.

- Peter

Frank van Eijkelenburg wrote:

No I didn't. Can you give me more details about this? Does this mean that the peripheral should support also bursts, or only bursts. What is the data width of the peripheral. At this moment it is 32 bits, should this be 64 bits?

Frank

Cacheline and bursts are two different type of transactions. The processor can only generate single word, four word cacheline, and eight word cacheline transactions but not burst transactions.

Eight word cacheline transactions are generated for memory areas that are cacheable. Four word cacheline transactions are generated for non-cacheable memory on the instruction side. Single word transactions are generated for non-cacheable memory on the data side.

Now, as for the data width - it depends. If your peripheral is on the PLB it can be either 32 bits or 64 bits wide. If your peripheral is on the OPB it has to be 32 bits wide. In any case you need to make sure that during the data phase the wdaddr input signals on the PLB are created correctly. Otherwise the processor will hang waiting for the transaction to complete and deliver data to all four words.

The PPC405 processor block reference guide explains the different transaction types and the signals on the PPC core.

- Peter

Frank van Eijkelenburg wrote:

Hi Peter,

many thanks for the information, it's working now.

Frank