A few basic c6727 HPI bootloader &AIS Interpreter questions

Sorry for the lag in response time.  Better late than never?

Dave Kissel said:

We’re going to be booting a C6727 DSP from a PPC440 using multiplexed full-word addressing mode.

How have you configured CFGHPI[BYTEAD]?  Generally speaking this should be set to 1 so you don't have to convert the addresses from byte addresses to word addresses.

Dave Kissel said:

We found the HPIAW (UHPI section 3.16) and HPIAR (UHPI section 3.17) registers, but could find no mention of the “HPID” register in any of the document’s DSP register tables. Where is the address of this register specified? Does it exist, or is it only necessary to load the word address into the HPIA register, then do a normal HPI bus read or write cycle (with a “don’t care address) to read or write the data?

The HCNTL pins are used at the interface to select between HPIA, HPID, HCNTL.  It's not accessible from the DSP side which is why it's not memory mapped.

Dave Kissel said:

Next, before beginning the AIS interpreter on the host, we’d like to test and confirm communication with the DSP over the HPI bus by reading the “BTLDR_REVSN_REG” register at ROM address 0x0C and confirming a revision value of “0xC9230C10.”

Back up... HPI boot mode is NOT an AIS boot mode.  The host is expected to write all the code/data directly to the appropriate memory of the DSP.  It would not format anything into the AIS image.

Dave Kissel said:

Finally, if you can point us to any application examples of the HPI AIS Interpreter implementation for the C6727, or any additional documents that provide a detailed description of the process, we’d appreciate it.

You'll want to use the hex conversion utility to format the out file into an image to be loaded by your host.  Make sure to use the -boot option to format your out file into a nice table.  See the Assembly Language Tools Guide for more info.

Hi Brad,

Hope you had a good weekend.

"Better late than never" certainly works for me! Thanks for eliminating the "AIS script confusion" and all the other info you provided. There's only one point of confusion at this time. I understand you to say above that we should set CFGHPI.BYTEAD=1 for full-word addressing. However, section 1.8.3.1 of TI_spru719a (below) seems to say it should be 0 for our mode. Can you please confirm which is correct?

Finally, I was relieved to learn that use of the AIS interpreter was not needed for HPI bus booting of the DSP, although the documentation on this point seems confusing to me. Section 1 of the TI_spraa69d "bootloader" document lists "HPI" as the first item in the "list of boot modes supported by the bootloader," and section 3 says that "the bootloader accepts boot information in the form of a script, called application image script (AIS)." After reading this, I thought use of the AIS was required. If possible, can you please point me to documentation that describes how the HPI should be used to write data directly into DSP memory?

Thanks,

Dave

"By selecting CFGHPI.BYTEAD = 0, the UHPI interprets the HPIAW and HPIAR registers as word aligned addresses. For example, if HPIAW were to contain the value 0x0000_0001 then this would be interpreted as byte address 0x0000_0004 in the DSP memory space."

FYI, I'm on vacation this week so I probably won't reply with any further info until next week.  I didn't want to leave you hanging though.  Hopefully this will be enough to get you over the hump, or else someone else can perhaps chime in.

Dave Kissel said:

"By selecting CFGHPI.BYTEAD = 0, the UHPI interprets the HPIAW and HPIAR registers as word aligned addresses. For example, if HPIAW were to contain the value 0x0000_0001 then this would be interpreted as byte address 0x0000_0004 in the DSP memory space."

Another example would be that if you load HPIAW = 0x10000000 (start of RAM) then the data will actually get written to address 0x40000000.  That is NOT what most people want to do.  The wording may be a bit confusing.  The difference between BYTEAD=0 and BYTEAD=1 is nothing to do with alignment, but rather to do with the element size.  So if you select BYTEAD=0 then each address will represent a word (4 bytes), which is why the word address is always equivalent to the byte address left shifted by two.

Dave Kissel said:

I was relieved to learn that use of the AIS interpreter was not needed for HPI bus booting of the DSP, although the documentation on this point seems confusing to me.

Dave Kissel said:

If possible, can you please point me to documentation that describes how the HPI should be used to write data directly into DSP memory?

I assume you already have the mechanics of reading and writing memory through the HPI in place, right?

Next you need to make take your output file (*.out) and convert it to a form more suitable for loading from your host processor.  Please see the Assembly Language Tools Guide.  In particular look at the chapter on the hex conversion utility.  It will take your *.out file and convert to a different file type.  Make sure to use the --boot option to make a boot table.  On that particular topic you might also want to read parts of this thread:

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/11700/45722.aspx#45722

In particular I discussed some of the hex conversion options as well as how to parse the corresponding output.  It was a slightly different scenario there but most of the discussion is still relevant.

A different way of tackling this issue is to use cg_xml to convert the *.out file into a C file and header file which can be compiled into your host processor.  See this thread for a modified version of the bootimage utility that will likely be helpful:

http://e2e.ti.com/support/development_tools/compiler/f/343/p/99421/348928.aspx#348928

Finally, once you have the file in a proper format where you can read and write to the 6727 you will need to file the steps outlined in section 2.1 of the bootloader doc.

Best regards,
Brad

Hi Brad,

Hope your vacation last week was nice.

In the meantime, I tried both of the methods you provided above for generating a file I can use to boot our DSPs via the HPI bus. I understand the output from both the hex6x program (the .hex file with the "boot table" up-front), and the bootimage tool (the .c and .h files with the arrays for all of the boot segments in the boot table). The latter is exactly what I was looking for. I've created an image table in my code with the bootimage array info and will use it to boot our DSPs. At this point, I can think of only 2 minor issues that remain, so I'll ask for your thoughts on them.

First, the C arrays created by bootimage are byte arrays, but I'll be pulling data from them using a pointer cast to UINT32*. Both our processor and the DSPs are operating in little-endian mode, so I presume there's no problem with byte ordering in doing this (but since we don't have real hardware yet and I'm simulating all of this on the uP, I may provide provisions to swap endian-ness just-in-case, say, using the VxWorks "htonl()" or "ntohl()" functions). Someone must have already written the bootimage arrays this way and proven it works, right?

Finally, I noticed that the ".const" memory segment of one of our DSPs does *not* have an integer number of 4 byte words in it (there's one byte left over). This means that the code that copies the image will have to check to see if there's from 1 to 3 "leftover" bytes following the "last" word write. Otherwise, up-to 3 bytes could overwrite the following memory segment. However, I didn't think I could write single bytes to the DSP (we're using mux'd 32 bit mode on the HPI bus). Is this a real concern, or are all the DSP memory segments forced to be on word boundaries, making it a non-issue?

Thanks for all the extremely useful information! I'll be clicking the "green" button on your next response.

Dave

Hi TI,

Hope your holiday was nice. Just a quick follow-up question or 2 on our C6727 implementation. We're now able to successfully boot a heartbeat program into the DSP, but after we set the "XFRDONE" bit, we can't talk to the DSP any longer over the HPI. We just read-back the last address accessed in the HPIC, HPIA, and HPID registers. We presume that this is potentially a problem in our HW, and that the HPI should continue to work with the DSP running, correct?

Next, we also need to boot code into external DSP SDRAM over the EMIF. To do this, we need to give the DRAM a clock by first programming the PLL registers appropriately. However, the spru879a PLL document says in section 3.1 "the HPI should not be used to directly access the PLL controller registers," which seems like a catch-22. How can we boot into SDRAM if we can't set-up the PLL controller registers to give this subsystem the clock it needs? The only solution we can think-of is to load a secondary boot configuration program into the DSP, let it configure PLL regs, then take-over again from the uP side to set-up the SDRAM controller registers. Any comments or pointers to more info on this would be appreciated, as this seems like an unnecessary step.

Thanks again! Also please note that my corporate email is now dkissel@broadreachengineering.com, so please use this on subsequent replies.

Dave

Thanks Brad. The CFGHPI register was indeed getting reset to 0x0 when we hit the XFRDONE button. The stage 2 bootloader now restores it and we're off-and-running (and on to much more difficult problems...). Glad we asked, as some other posts on the subject indicated it was probably an issue with our HPI HW.

Happy Holidays!

Dave