C6657 boot up question

The Ibl in the eeprom need to be changed to big endian format. If you go through the user guide, they would have mentioned that we first go and execute IBL and then branch to PCIe boot. The IBL we have is compiled for little endian. So if you move to big endian, flash the eeprom with the IBL's big endian version and try.

Thanks,

Arun.

thanks Arun.

Why do we have to use IBL? My understanding is, if we set the bootmode pins on the DSP, the ROM bootloader will init PCIe and monitor the BOOT MAGIC ADDR.

The host will push all the code and data to internal memory, such as MSMC/L2, then update hte BOOT MAGIC ADDR. DSP will load it into PC when it is non-zero and we can start the next stage bootloading if we need to configure external DDR3. I do not see any need for using an additional IBL to use PCIe. Is this IBL EVM specific or does its FPGA does anything to force it to do an I2C boot first, then PCIe boot?

I still do not understand that how can we boot both big endian and small endian from the same ROM bootloader location, as the binary are different for small and big endian in memory, right. Could you please elaborate?

thanks

Weichun

We are designing new hardware with the C6657 and would like to know if we need to have the IBL (EEPROM) on board in order to use PCIe boot mode.

An answer to the previous post would be great.

Thanks

Dhar

Dhar,

If you are using the EVM, you indeed need the IBL to boot in PCIe boot. The reason for this is that the FPGA in the EVM is programmed to boot to I2C no matter what boot mode is set and then jumps to the PCIe boot. If you are working on a custom board you don't need to have the IBL. Hope this helps.

Thanks,

Arun.

Arun,

1)  Is there any known errata on C6657 (SPRZ381) requiring an IBL for a custom design?

2)  In a custom design with the C6657 (non EVM) will the RBL directly boot the DSP per the Bootmode pins without issue?

3)  Assuming custom C6657 design, can RBL directly SPI boot to DDR3 the example you provided in E2E link http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/229915.aspx?pi70912=3   ?

As you know we've successfully demonstrated that example SPI Boot to DDR3 on an EVM C6657, but will it work on a custom design assuming same memory, etc.?  Are there any changes to this SPI Boot to DDR3 example for a custom design?

4)  Assuming custom C6657 design, can RBL directly PCIe-EP boot to DDR3 from a host PCIe-RC as jumpered by the bootmode pins only?

With the help of Steven Ji and others I have successfully booted one EVM C6657 PCIe-EP (modified IBL) from another EVM C6657 PCIe-RC using a custom PCIe backplane as described within E2E link http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/234593.aspx?pi70912=1  , and I understand that PCIe-EP EVM performs an I2C 0x51 IBL before actually entering PCIe-EP boot.  My interest is with a custom design C6657 and boot it PCIe-EP without IBL?

Assuming the answer to 4) is yes

5)  Is the PCIe Boot Parameter table (Table 3-12 SPRUGY5B) needed if the host PCIe-RC performs all the necessary configuration steps?  This suggest the host PCIe-RC needs to configure DDR3 memory and load all the boot application code/data sections into PCIe-EP memory directly which is what I'd expect.  Correct?

3.4 PCI Express (PCIe) Bootloader Operation

3.4.1 Basic Boot Operation

In the PCIe boot mode, the host configures memory and loads all the sections directly

to the memory. The bootloader configures the base address registers, the number of

windows, and their size. The PCIe power-up is configured through the external pin

PCIESSEN. PCIe boot code can configure the PCIe registers either by getting the values

from the I2C or the default values from the boot parameter table (Table 3-12).

5)  This last sentence suggests that the PCIe Boot Parameter Table (Table 3-12) to be optional by the use of the word *can*.  Is this correct?

If used and not via I2C how is this PCIe Boot Parameter table provided?  Can the PCIe-RC write it into the RBL parameter table area within the PCIe-EP's L2 memory?  What address is this table to be written to in order for the RBL to process?

Since the RBL is idle spinning on the BOOT_MAGIC_ADDRESS (0x008FFFFC) to become non-zero, what is the trigger mechanism for the RBL to recognize and process this PCIe Boot Parameter Table?

6)  The following paragraph from PCIe Boot section within SPRUGY5B (pg 3-10) suggests that the PCIe Boot Parameter Table is not required if PCIe boot is the primary boot mode.  In this case the BAR size config is derived from the bootmode pins themselves.  Is this correct?

If the PCIe boot is the primary boot, the BAR size configuration is driven by the BAR

config fields listed in Table 3-13 (PCIe Boot Mode Device Configuration) and Table 3-14.

7)  Other than configuring the DDR3 memory via loading "pcieboot_ddrinit" as in the PCIe boot example (see E2E link above), are there alternate methods?  Programming DDR registers directly is possible, but is it possible to enlist the RBL to perform the DDR Config by interpreting and processing a DDR_Config table (from SPI Boot example link above) written into 0x008FFD20?  If so, what is the trigger mechanism needing to be used for the RBL to perform this DDR initialization?

Thanks,

-George

Arun,

We are investigating the scope of work to direct boot the C6657 via PCIe-EP in a custom design.  We need to understand fully the questions posted on my previous post before commiting to our custom design.

Are there known issues with directly booting PCIe-EP on the C6657, i.e. without an IBL from I2c/SPI?

Thanks,

-George

Hi George,

When we boot the board from another C66x device, we have no issues. But when booting from a desktop host, we seethe boot fails. We are trying to see what is the real issue. Will update the post once we corner out the issue.

thanks,

arun.

we are trying to use PCIe to boot our own board (not using EVM). The PCIe on dsp is configured as EP and host has configured the PCIe registers on C6657 and downloaded the code to L2 of core 0. Host also wrote the entry address _c_int00 into BOOT_MAGIC 0x8FFFFC, but the global variable I set in main is not changed. In fact the entry in BOOT_MAGIC is not changed, still has the entry address host wrote.

I then connected jtag, PC is still in the rom bootloader. I checked the DEVSTAT@0x2620020 and it is 0x0001 1808, so my understanding is PCIESSEN is 1 (pcie enabled), PCIESSMODE=00 (EP), LENDIAN=0 (big endian). BOOTMODE=0110 00 0000 100, so PCIe boot is chosen. It looks right to me.

Now, the interesting part: using jtag, I changed PC to start of ROM boot loader (0x20B00000), and let the dsp run after I load the symbole file in dsp and set breakpoint in both _c_int00 and main. Neither breakpoint were hit, I did not see the global variable changed. But interestingly, the BOOT_MAGIC at 0x8FFFFC is cleared to 0 and PC is still in bootloader region.

I must have missed something somewhere. Any one could give me a tip?

thanks

Weichun

Hi Weichun

You need to post an MSI interrupt to the DSP after loading from the host.

Thank you very much Dhar.

Do I have to send a specific MSI interrupts or any of the 32 MSI interrupts could work?

According to sprugy5a-1, "After the host transfers the boot table directly to the
memory location and if the BOOT MAGIC ADDRESS register is non-zero, the ROM
code copies the start address of the application from the BOOT MAGIC ADDRESS to
the program counter wakes up the DSP through an interrupt generated by poking the
MSI application register and executes the application loaded. If the BOOT MAGIC
ADDRESS register is still zero the ROM code keeps the DSP in idle till the value is
non-zero."

It does not specify the interrupts to use. Does that mean that any one would work?

I tried MSI interrupt 0 and 8, but none of them seem to have any effect. It is also interesting to notice that in file mcsdk_2_01_01_4/tools/boot_loader/examples/pcie/linux/pciedemo.c, the function setBootAddrIpcgr made sure that the entry point is aligned to 10 bits boundary. Is this a special requirement? Do we have to do the KICK_UNLOCK before we write to BOOT_MAGIC?

I am trying to follow the function setBootAddrIpcgr, but could not understand what the line

myIowrite32(1, pReg + IPCGR(core)/4);

in function setBootAddrIpcgr does, for instance, which interrupt does it send.

thanks

Weichun

Hi, Dhar,

the setBootAddrIpcgr  in mcsdk_2_01_01_4/tools/boot_loader/examples/pcie/linux/pciedemo.c seems to be part of the local reset, and it writes the KICK_UNLOCKS, then write the entry point DSP_BOT_ADDR0 in Device State Control as well as the interrupt. Then, it does a local dsp core unreset.

I've done a simple test:

1. remove Global_Default_Setup_Silent from function of OnTargetConnect of the gel file so that I do not touch dsp when I connect

2. bring dsp out of reset and connect to core 0

3. now pc is pointing to 0x20B010B0, in bootrom.

4. DEVSTATE# 0x02620020 is 0x00011808, with PCIESSEN=1, PCIESSMODE=00 (EP), PCIe boot

5. I just write address 0x800000 into BOOTMAGIC (0x008FFFFC), set break point at this 0x800000, which contains just garbage, and let the dsp run.

6. The dsp does not hit the break point

I think, I should be able to hit the break point. Is there anything I miss?

thanks

Weichun

Hi Weichun,

Did you resolve this issue? I have the exact issue you describe (PC points to 0x20B010B0) and am at a bit of a loss. I am trying to get my Host PC to enumerate the EVM6657, but it is not showing up.... I tried 2 different hosts, without success.

Edit: I should add that I am running in Little Endian mode and that I loaded the I2C EEPROM (address 0x51) with the latest IBL (from MCSDK mcsdk_2_01_02_06) with the PCIe PLL lock workaround. When I hookup an emulator I see the following values:

PC = 0x20B010B0 (In the Boot ROM)

DEVSTAT(0x2620020)  = 0x00011809

BOOTMAGIC (0x8FFFFC) = 0x00000000

PCIE_SERDES_STS  (0x0262015C) = 0x00000001 (so PLL is LOCKed)

I appreciate your help!

Cheers,

Dirk

Hi, Dirk,

I think after pushing the code and data into L2, I wrote BOOT_MAGIC with entry, then send a PCIE_MSI interrupt to dsp core 0 to tell it to start at BOOT_MAGIC.

Could you please try this?

thanks

Thanks for your fast reply!

I just tried a third host PC and there the EVM board enumerates! The problem is that on the other 2 machines when I do an "lspci", the board does not show up which means the host PC failed to enumerate the EVM board. 

I assume you are talking about pushing the code and data into L2 after enumeration. However, I am not yet at this stage. The question I am struggling with is why does my board fail to enumerate on some PCs and not on others?

I should add that to be able to successfully enumerate I had to power the board externally, such that the card is booted before the host PC starts enumeration. Without external Power it did not enumerate....

Any thoughts on this? I'll try to get some more results to figure out what the exact issue is.

Cheers,
Dirk