> > It looks that the whole task arises here: a
correct bootloader.
> Aha!! The light went on about what you guys are talking about when you
> say 'boot loader'. Being an old timer, I was taking 'boot
loader' as
> the historical meaning [at least to me]. By definition, a 'bootstrap
> loader' executes on the device being loaded [the DSP in this case]. In
> my terminology, CCS cannot have a 'boot loader' for the DSP - it has
a
> 'loader'. It might seem picky, by my lookup mechanism was not
cross
> referencing 'boot loader' and 'loader'.
Mea culpa, I really mixed it up. For this particular case of booting
via the PCI, the latter one is the correct term.
I am trying to find on the net an open source code that can serve as a base
idea for a C6000 loader and/or a bootstrap loader.
Regards,
Andrew
Reply by Jeff Brower●March 20, 20082008-03-20
Mike-
> > No, I do not think that the direct, byte for byte,
method is the correct one.
> Andrew,
> This thread is a bit hard to follow. Jim's 'image file' is
derived
> from an out file. I assume that it is similar to hex6x but a bit more
> sophisticated that the hex6x 'paper tape' format.
>
> > It looks that the whole task arises here: a correct bootloader.
> Aha!! The light went on about what you guys are talking about when you
> say 'boot loader'. Being an old timer, I was taking 'boot
loader' as
> the historical meaning [at least to me]. By definition, a 'bootstrap
> loader' executes on the device being loaded [the DSP in this case]. In
> my terminology, CCS cannot have a 'boot loader' for the DSP - it has
a
> 'loader'. It might seem picky, by my lookup mechanism was not
cross
> referencing 'boot loader' and 'loader'.
> > CCS should have
> > it internally to parse its input COFF image, then move sections to their
> > corresponding load addresses (which could leap, sections are not supposed
to be
> > placed contiguously!),
>
> Correct. The poor term 'byte for byte' was referring to 'copy
the data
> to the addresses where it is supposed to go'.
> This is all that a simple standalone loader needs to do.
> > perform initialization of static and global variables
> > if it was specified (by the linker's -cr option) to be done on load
time,
>
> The actual initialization is written into the COFF file.
> > then
> > strip any symbolic info if it's not needed, whatever else.
> Actually all symbols are stripped [or ignored], since when they are
> used, they reside on the host.
> This is only true for a simple loader.
Yes, but I would like to add here that a COFF loader that exactly emulates
CCS
download is not easy. The COFF file format itself has a number of esoteric
flags and
"formats within formats", and tricky things -- like strings that become file
indexes
in some cases -- and TI has added to the complexity with some very "TI-only"
specific
stuff.
We have an in-house COFF loader inside some software called DirectDSP, and it
gets
added onto and fixed up every year as either a) we find special combinations or
flag
actions we didn't implement yet, or b) TI makes enhancements in new CCS
releases.
-Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by Michael Dunn●March 20, 20082008-03-20
Andrew and Jim,
On Wed, Mar 19, 2008 at 7:54 PM, Andrew Nesterov
wrote: >
> > Subject: Re: PCI booting of production code
> > Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> > Date: Tue Mar 18, 2008 3:30 pm ((PDT))
> >
> > Jim,
> >
> > On 3/18/08, jim wrote:
> >> On Tuesday 18 March 2008 12:32:14 you wrote:
> >>> Jim,
> >>>
> >>> On 3/18/08, jim wrote:
> >>>> On Tuesday 18 March 2008 08:35:27 you wrote:
> >>>>> Jim,
> >>>>>
> >>>>> On 3/17/08, jim wrote:
> >>>>>> Actually, I am now reading this program in a hex editor since,
upon
> >>>>>> further
> >>>>>> review, I have determined that _c_int00 is a named section that
> >>>>>> should be present someplace in the program file.
> >>>>>>
> >>>>>> Well, I have found it, but the label (which is 8 bytes long) is not
> >>>>>> word aligned.
> >>>>>
> >>>>> This doesn't sound right. It should be word aligned [00 in the
lower 2
> >>>>> bits] at a minimum.
> >>>>> Your previous post indicated that it was -
> >>>>> "_c_int00 (which is supposed to be at 0x14300 in this program)"
> >>>>> Are you sure that it is not your editor?? Are you looking at the
memory
> >>>>> from the Linux PC??
> >>>>> The CCS memory viewer should show you the correct bits and labels.
> >>>>
> >>>> When I load the program using CCS, then look at it using the memory
> >>>> viewer, it shows _c_int00 at 0x14300.
> >>>>
> >>>> When I load the program across the PCI bus from the Linux host,
location
> >>>> 0x14300 (actually all locations) are not labeled and the data/code
found
> >>>> at that location is different than it is when loaded using CCS.
> >>>
> >>> FYI-
> >>> You can do a 'load symbols only' from CCS to provide symbol
info in
> >>> the memory window [of course it will display relative to the addresses
> >>> that CCS expects].
> >>>
> >>> The mismatch is a problem.
> >>> You should get the exact same memory image - no matter how it is
loaded.
> >>>
> >>>> I am loading the same program (the identical .out file) either way.
The
> >>>> program file I am loading is 225,096 bytes, so 0x14300 is certainly
> >>>> within that range.
> >>>>
> >>>> I do all my work in Linux, except for that stuff where I have no
choice
> >>>> (such as using CCS) so the hex editor I am using is khexedit, a Linux
> >>>> package. I am looking at the actual bytes of data in the file; the
label
> >>>> is as I reported it. If, as Andrew stated, this is merely a symbol
table
> >>>> in the executable then the alignment is explained.
> >>>>
> >>>> However, what is not explained is why the contents of 0x14300 are
> >>>> different between a load by CCS and a load across the PCI bus. I
suppose
> >>>> that the boot loader at _c_int00 is rearranging things...
> >>>
> >>> I am not sure exactly how you are loading the program from the host.
> >>> If you are parsing the '.out' file and doing memory writes via
PCI
> >>> [the normal PCI load sequence] you should have the same memory
> >>> contents. The fact that the contents differ, seems to indicate
> >>> different logic in the 2 load paths.
> >>> OUTfile->CCS->JTAG->DSP->Memory
> >>> vs.
> >>> OUTfile->loader->PCIdriver->PCIbus->DSP->Memory
> >>>
> >> Well, this is almost what is happening. In fact, the description of how
I
> >> load from the linux host is accurate, but the description of what is
> >> happening when CCS loads it is missing one step. Should say:
> >>
> >> OUTfile->CCS->JTAG->DSP->Memory->bootloader
> >
> > bootloader?? I am not sure what you mean.
> >
> > CCS works almost the same as your loader.
> > When you do a program load from CCS, the upper level reads a COFF
> > file, parses it, saves the symbols for later use, picks off 'stuff
to
> > be loaded to the target', builds memory write commands, sends them
to
> > the emulation driver, they are then converted to magical JTAG
> > sequences that logic on DSP converts to memory writes. When you do a
> > program load on a 6416 there is no bootloader involved - just a bunch
> > of memory writes.
> >>
> >> Reading the docs tells me that the bootloader will move things around; I
am
> >> guessing (pure guess) that this is what is happening.
> >
> > To what docs are you referring??
> >
> >> After doing a load
> >> from CCS, the moment I try to look at the memory locations that contain
the
> >> code I see tagged sections. _c_int00 is clearly identified as such.
This
> >> means that the bootloader must have run, or if not the bootloader, then
> >> something ran in order to label the code.
> >
> > From the info above - Any time that CCS performs a memory read, he
> > checks the symbol table that he built on the last program load [or
> > symbol load] to see if there are relevant symbols. If you load program
> > A followed by a symbol only load of program B, then display memory,
> > you will see things are 'all messed up' because Program A data
will be
> > displayed but the symbols will be from program B.
> >
> >>
> >> Now, in fact, the low memory (location 0x0 and some distance
forward...not
> >> sure how far forward...) is the same when loaded from CCS or when loaded
from
> >> the host.
> >>
> >> To make this clear, the 32 bit word at 0x14300 in the program file (the
.out
> >> file) contains the values 2b593a5c, which is ASCII values +Y:\ and is part
of
> >> a string that goes like this
> >>
> >> +Y:\port\c60\5_1_0\build\rts_pc\6400\trgdrv.asm:L15:1:1111601720
> >>
> >> Note that any line wraps in that string are introduced by the email
> >> client...it is as written without any returns or breaks in the code.
> >>
> >> Also note that there is an endian issue here; on CCS this would display
as
> >> 5c3a592b, but we can deal with that.
> >>
> >> The location 0x14300 in memory after CCS loads it is as follows:
> >> 0x00000212 which is disassembled as
> >>
> >> B.S2 0x14310
> >>
> >> What are the implications of JTAG? Is this a CCS-only thing? Or does
it
> >> impact the load and lead to things that I need to duplicate with my
loader?
> >
> > No problems with JTAG. In the past I put together a loader that would
> > load from either JTAG or HPI [host port interface]. The only
> > difference was the low level write implementation - feed the
> > address/data to HPI driver or the JTAG driver.
> >
> >>
> >> The C code that actually loads the program into the DSP at the
specified
> >> address is linux userspace code that works as follows:
> >>
> >> char c;
> >> char
*cmdstr="resetdsp;buf0mempage=0x0;buf0setoffset=0x0;setcontext=L;";
> >>
> >> (other code)
> >>
> >> useprog = "dsp_program";
> >> progfile = open(useprog,0);
> >>
> >> (other code)
> >>
> >> cmdfile=fopen("/proc/driver/tidsp","r+");
> >> fwrite(cmdstr,buflen(cmdstr),1,cmdfile);
> >> fclose(cmdfile);
> >> outfile=open("/dev/tidsp0",1);
> >> while((ii = read(progfile,&c,1)) > 0) {
> >> write(outfile,&c,1);
> >> }
> >> close(outfile);
> >> close(progfile);
> >>
> >> For those who do not know linux, a brief explanation.
> >>
> >> /proc/driver/tidsp is the location of the command interface to my linux
> >> driver. I write cmdstr to there to command the driver to do the
following
> >> things: reset the dsp, set up the memory buffer (buffer 0...the one
that
> >> spans the entire memory address space in 4 meg pages) to page 0, set
the
> >> offset within that page to 0 (thus writing starting at location 0x0), and
do
> >> a setcontext, which has meaning to my Linux driver but not to the DSP.
> >>
> >> I then open /dev/tidsp0 which is the linux system's entry point to
the device
> >> that represents the PCI memory locations represented by that 4 meg page
on
> >> the DSP, and I ship the program byte by byte over to the dsp where it
is
> >> indeed being written in the proper location.
> >>
> >>> If the problem is not obvious, like addresses off by n bytes, I
> >>> suggest a simple test program for your loader. I use a C program to
> >>> write and asm program of nothing but '.word nnnnnnnn' s. The
windoze
> >>> code below will generate an asm file that is a sequence of numbers
> >>> with labels. You can compile the file, load the '.out' from
your Linux
> >>> box and load the symbols from CCS. Mismatches are easy to spot.
> >>>
> >>> #include
> >>> int main()
> >>> {
> >>> FILE *fptr;
> >>> unsigned int i;
> >>> static char buf[200];
> >>>
> >>> fptr = fopen("loadfile1.asm", "w");
> >>> fprintf(fptr, "\t.sect\t\".text\"\n");
> >>> for(i=0; i<0x10000; i += 4)
> >>> {
> >>> sprintf(buf, "L_%04X:\n", i);
> >>> fprintf(fptr, buf);
> >>> sprintf(buf, "\t.word\t0x%04X%04X\n", i, i);
> >>> fprintf(fptr, buf);
> >>> }
> >>> fprintf(fptr, "THE_END:\n");
> >>> }
> >>
> >> Ummm...load the program from my loader, but load the symbols from CCS?
How
> >> will that work? CCS will load the symbols from the copy of the .out
file
> >> that it has? How will a mismatch show in this event?
> >>
> >> Actually, I just tried this using my release program. I reset the dsp,
then
> >> loaded my program from the host with the loader. I then connected CCS to
the
> >> dsp and did a symbol-only load.
> >>
> >> The symbol-only load placed the tag _c_int00 at location 0x14300, and the
code
> >> at that location is the same identical code as exists in my source file
> >> (represented in CCS as 0x5c3a592b).
> >>
> >> This is making the problem a lot clearer, I think. CCS is doing
something
> >> OTHER than a byte for byte load of the program, or alternatively the
> >> bootloader that is hidden someplace in that program is doing something
to
> >> rearrange, copy, and initialize things.
> >>
> >> My loader is merely shipping the program disk image, byte for byte, to
the
> >> DSP, and this must be wrong.
> >
> > You are probably doing the right thing - a direct load like CCS does.
> > Are you 100% sure that your disk image is correct??
> >
> > One thought:
> > You can zero memory and load your program via CCS. Go to memory data
> > save and save the first 'n' KB [64k?] of memory into a text file.
You
> > can look at the first few bytes and figure out the bonehead format.
> > Next, write a script or program to convert your 'disk image' into
the
> > same format so that you can diff them.
> >
> >> Some action is being taken along the way to
> >> rearrange this disk image into an executable image, and I don't know
what.
> >> The bootloader, I suppose, but I don't know why the appropriate jumps
are not
> >> being set up by the linker.
> >
> > No. No. No.
> > Either forget about this 'bootloader thing' or let me in on what
it is.
> > I have loaded hundreds of out files [with several different loaders]
> > via CCS or a remote host with no problems.
>
> Most probably the autoinitialization was mentioned, it uses an init table
> in a .out file to set the values of global and static variables, specified
> by the -cr option.
> >> But if my disk image has _c_int00 as a tag in a symbol table only,
exactly
> >> what actions do I need to take to identify the location and point to the
boot
> >> loader?
> >
> > If your disk image has any tags or symbols, it is not correct. No
> > symbolic info resides on the target.
> >
> > mikedunn
>
> No, I do not think that the direct, byte for byte, method is the correct
one. Andrew,
This thread is a bit hard to follow. Jim's 'image file' is
derived
from an out file. I assume that it is similar to hex6x but a bit more
sophisticated that the hex6x 'paper tape' format.
> It looks that the whole task arises here: a correct
bootloader. Aha!! The light went on about what you guys are talking about when you
say 'boot loader'. Being an old timer, I was taking 'boot
loader' as
the historical meaning [at least to me]. By definition, a 'bootstrap
loader' executes on the device being loaded [the DSP in this case]. In
my terminology, CCS cannot have a 'boot loader' for the DSP - it has
a
'loader'. It might seem picky, by my lookup mechanism was not cross
referencing 'boot loader' and 'loader'. > CCS should have
> it internally to parse its input COFF image, then move sections to their
> corresponding load addresses (which could leap, sections are not supposed to
be
> placed contiguously!),
Correct. The poor term 'byte for byte' was referring to 'copy the
data
to the addresses where it is supposed to go'.
This is all that a simple standalone loader needs to do. > perform initialization of static and global
variables
> if it was specified (by the linker's -cr option) to be done on load
time,
The actual initialization is written into the COFF file. > then
> strip any symbolic info if it's not needed, whatever else. Actually all symbols are stripped [or ignored], since when they are
used, they reside on the host.
This is only true for a simple loader. > For the purpose of
> standalone loading, thus a separate bootloader is needed, a hand-coded
one.
>
> I think that the sequence of actions to be done by the bootloader is
described
> in the coff and linker sections of spru186, but I have never dealt with this
so
> far.
>
> There's also an .out to .hex utility (hex6x.exe in my windows CCS
installation)
> that converts a binary image into an ascii file. Actually it coverts a coff file with lots of symbols and debug stuff
into an ASCII file that contains addresses with blocks of data to be
loaded to those addresses. >
> Therefore I think that the bootloader might also have an option to input
and
> parse a .hex file as well and relocate its contents as well as for a
binary
> .out file It would be very difficult to relocate a 'hex' file because it
only
contains addresses and data. You can relocate from a COFF file, but if
you are doing anything significant, you would have to run the
relocatable loader on the target that is sync'd up with the
target's
memory management.
all for now,
mikedunn >
> All is new for me. I'll really appreciate any feedback. Thanks.
>
> Regards,
>
> Andrew
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by Andrew Nesterov●March 20, 20082008-03-20
> Subject: Re: PCI booting of production code
> Posted by: "Michael Dunn" m...@gmail.com mikedunn.0101
> Date: Tue Mar 18, 2008 3:30 pm ((PDT))
>
> Jim,
>
> On 3/18/08, jim wrote:
>> On Tuesday 18 March 2008 12:32:14 you wrote:
>>> Jim,
>>>
>>> On 3/18/08, jim wrote:
>>>> On Tuesday 18 March 2008 08:35:27 you wrote:
>>>>> Jim,
>>>>>
>>>>> On 3/17/08, jim wrote:
>>>>>> Actually, I am now reading this program in a hex editor since, upon
>>>>>> further
>>>>>> review, I have determined that _c_int00 is a named section that
>>>>>> should be present someplace in the program file.
>>>>>>
>>>>>> Well, I have found it, but the label (which is 8 bytes long) is not
>>>>>> word aligned.
>>>>>
>>>>> This doesn't sound right. It should be word aligned [00 in the lower
2
>>>>> bits] at a minimum.
>>>>> Your previous post indicated that it was -
>>>>> "_c_int00 (which is supposed to be at 0x14300 in this program)"
>>>>> Are you sure that it is not your editor?? Are you looking at the memory
>>>>> from the Linux PC??
>>>>> The CCS memory viewer should show you the correct bits and labels.
>>>>
>>>> When I load the program using CCS, then look at it using the memory
>>>> viewer, it shows _c_int00 at 0x14300.
>>>>
>>>> When I load the program across the PCI bus from the Linux host, location
>>>> 0x14300 (actually all locations) are not labeled and the data/code found
>>>> at that location is different than it is when loaded using CCS.
>>>
>>> FYI-
>>> You can do a 'load symbols only' from CCS to provide symbol info
in
>>> the memory window [of course it will display relative to the addresses
>>> that CCS expects].
>>>
>>> The mismatch is a problem.
>>> You should get the exact same memory image - no matter how it is loaded.
>>>
>>>> I am loading the same program (the identical .out file) either way. The
>>>> program file I am loading is 225,096 bytes, so 0x14300 is certainly
>>>> within that range.
>>>>
>>>> I do all my work in Linux, except for that stuff where I have no choice
>>>> (such as using CCS) so the hex editor I am using is khexedit, a Linux
>>>> package. I am looking at the actual bytes of data in the file; the
label
>>>> is as I reported it. If, as Andrew stated, this is merely a symbol
table
>>>> in the executable then the alignment is explained.
>>>>
>>>> However, what is not explained is why the contents of 0x14300 are
>>>> different between a load by CCS and a load across the PCI bus. I
suppose
>>>> that the boot loader at _c_int00 is rearranging things...
>>>
>>> I am not sure exactly how you are loading the program from the host.
>>> If you are parsing the '.out' file and doing memory writes via
PCI
>>> [the normal PCI load sequence] you should have the same memory
>>> contents. The fact that the contents differ, seems to indicate
>>> different logic in the 2 load paths.
>>> OUTfile->CCS->JTAG->DSP->Memory
>>> vs.
>>> OUTfile->loader->PCIdriver->PCIbus->DSP->Memory
>>>
>> Well, this is almost what is happening. In fact, the description of how I
>> load from the linux host is accurate, but the description of what is
>> happening when CCS loads it is missing one step. Should say:
>>
>> OUTfile->CCS->JTAG->DSP->Memory->bootloader
>
> bootloader?? I am not sure what you mean.
>
> CCS works almost the same as your loader.
> When you do a program load from CCS, the upper level reads a COFF
> file, parses it, saves the symbols for later use, picks off 'stuff to
> be loaded to the target', builds memory write commands, sends them to
> the emulation driver, they are then converted to magical JTAG
> sequences that logic on DSP converts to memory writes. When you do a
> program load on a 6416 there is no bootloader involved - just a bunch
> of memory writes.
>>
>> Reading the docs tells me that the bootloader will move things around; I
am
>> guessing (pure guess) that this is what is happening.
>
> To what docs are you referring??
>
>> After doing a load
>> from CCS, the moment I try to look at the memory locations that contain
the
>> code I see tagged sections. _c_int00 is clearly identified as such. This
>> means that the bootloader must have run, or if not the bootloader, then
>> something ran in order to label the code.
>
> From the info above - Any time that CCS performs a memory read, he
> checks the symbol table that he built on the last program load [or
> symbol load] to see if there are relevant symbols. If you load program
> A followed by a symbol only load of program B, then display memory,
> you will see things are 'all messed up' because Program A data will
be
> displayed but the symbols will be from program B.
>
>>
>> Now, in fact, the low memory (location 0x0 and some distance forward...not
>> sure how far forward...) is the same when loaded from CCS or when loaded
from
>> the host.
>>
>> To make this clear, the 32 bit word at 0x14300 in the program file (the
.out
>> file) contains the values 2b593a5c, which is ASCII values +Y:\ and is part
of
>> a string that goes like this
>>
>> +Y:\port\c60\5_1_0\build\rts_pc\6400\trgdrv.asm:L15:1:1111601720
>>
>> Note that any line wraps in that string are introduced by the email
>> client...it is as written without any returns or breaks in the code.
>>
>> Also note that there is an endian issue here; on CCS this would display as
>> 5c3a592b, but we can deal with that.
>>
>> The location 0x14300 in memory after CCS loads it is as follows:
>> 0x00000212 which is disassembled as
>>
>> B.S2 0x14310
>>
>> What are the implications of JTAG? Is this a CCS-only thing? Or does it
>> impact the load and lead to things that I need to duplicate with my
loader?
>
> No problems with JTAG. In the past I put together a loader that would
> load from either JTAG or HPI [host port interface]. The only
> difference was the low level write implementation - feed the
> address/data to HPI driver or the JTAG driver.
>
>>
>> The C code that actually loads the program into the DSP at the specified
>> address is linux userspace code that works as follows:
>>
>> char c;
>> char *cmdstr="resetdsp;buf0mempage=0x0;buf0setoffset=0x0;setcontext=L;";
>>
>> (other code)
>>
>> useprog = "dsp_program";
>> progfile = open(useprog,0);
>>
>> (other code)
>>
>> cmdfile=fopen("/proc/driver/tidsp","r+");
>> fwrite(cmdstr,buflen(cmdstr),1,cmdfile);
>> fclose(cmdfile);
>> outfile=open("/dev/tidsp0",1);
>> while((ii = read(progfile,&c,1)) > 0) {
>> write(outfile,&c,1);
>> }
>> close(outfile);
>> close(progfile);
>>
>> For those who do not know linux, a brief explanation.
>>
>> /proc/driver/tidsp is the location of the command interface to my linux
>> driver. I write cmdstr to there to command the driver to do the following
>> things: reset the dsp, set up the memory buffer (buffer 0...the one that
>> spans the entire memory address space in 4 meg pages) to page 0, set the
>> offset within that page to 0 (thus writing starting at location 0x0), and
do
>> a setcontext, which has meaning to my Linux driver but not to the DSP.
>>
>> I then open /dev/tidsp0 which is the linux system's entry point to the
device
>> that represents the PCI memory locations represented by that 4 meg page on
>> the DSP, and I ship the program byte by byte over to the dsp where it is
>> indeed being written in the proper location.
>>
>>> If the problem is not obvious, like addresses off by n bytes, I
>>> suggest a simple test program for your loader. I use a C program to
>>> write and asm program of nothing but '.word nnnnnnnn' s. The
windoze
>>> code below will generate an asm file that is a sequence of numbers
>>> with labels. You can compile the file, load the '.out' from your
Linux
>>> box and load the symbols from CCS. Mismatches are easy to spot.
>>>
>>> #include
>>> int main()
>>> {
>>> FILE *fptr;
>>> unsigned int i;
>>> static char buf[200];
>>>
>>> fptr = fopen("loadfile1.asm", "w");
>>> fprintf(fptr, "\t.sect\t\".text\"\n");
>>> for(i=0; i<0x10000; i += 4)
>>> {
>>> sprintf(buf, "L_%04X:\n", i);
>>> fprintf(fptr, buf);
>>> sprintf(buf, "\t.word\t0x%04X%04X\n", i, i);
>>> fprintf(fptr, buf);
>>> }
>>> fprintf(fptr, "THE_END:\n");
>>> }
>>
>> Ummm...load the program from my loader, but load the symbols from CCS?
How
>> will that work? CCS will load the symbols from the copy of the .out file
>> that it has? How will a mismatch show in this event?
>>
>> Actually, I just tried this using my release program. I reset the dsp,
then
>> loaded my program from the host with the loader. I then connected CCS to
the
>> dsp and did a symbol-only load.
>>
>> The symbol-only load placed the tag _c_int00 at location 0x14300, and the
code
>> at that location is the same identical code as exists in my source file
>> (represented in CCS as 0x5c3a592b).
>>
>> This is making the problem a lot clearer, I think. CCS is doing something
>> OTHER than a byte for byte load of the program, or alternatively the
>> bootloader that is hidden someplace in that program is doing something to
>> rearrange, copy, and initialize things.
>>
>> My loader is merely shipping the program disk image, byte for byte, to the
>> DSP, and this must be wrong.
>
> You are probably doing the right thing - a direct load like CCS does.
> Are you 100% sure that your disk image is correct??
>
> One thought:
> You can zero memory and load your program via CCS. Go to memory data
> save and save the first 'n' KB [64k?] of memory into a text file.
You
> can look at the first few bytes and figure out the bonehead format.
> Next, write a script or program to convert your 'disk image' into
the
> same format so that you can diff them.
>
>> Some action is being taken along the way to
>> rearrange this disk image into an executable image, and I don't know
what.
>> The bootloader, I suppose, but I don't know why the appropriate jumps
are not
>> being set up by the linker.
>
> No. No. No.
> Either forget about this 'bootloader thing' or let me in on what it
is.
> I have loaded hundreds of out files [with several different loaders]
> via CCS or a remote host with no problems.
Most probably the autoinitialization was mentioned, it uses an init table
in a .out file to set the values of global and static variables, specified
by the -cr option.
>> But if my disk image has _c_int00 as a tag in a
symbol table only, exactly
>> what actions do I need to take to identify the location and point to the
boot
>> loader?
>
> If your disk image has any tags or symbols, it is not correct. No
> symbolic info resides on the target.
>
> mikedunn
No, I do not think that the direct, byte for byte, method is the correct one.
It looks that the whole task arises here: a correct bootloader. CCS should
have
it internally to parse its input COFF image, then move sections to their
corresponding load addresses (which could leap, sections are not supposed to
be
placed contiguously!), perform initialization of static and global variables
if it was specified (by the linker's -cr option) to be done on load time,
then
strip any symbolic info if it's not needed, whatever else. For the purpose
of
standalone loading, thus a separate bootloader is needed, a hand-coded one.
I think that the sequence of actions to be done by the bootloader is
described
in the coff and linker sections of spru186, but I have never dealt with this
so
far.
There's also an .out to .hex utility (hex6x.exe in my windows CCS
installation)
that converts a binary image into an ascii file.
Therefore I think that the bootloader might also have an option to input and
parse a .hex file as well and relocate its contents as well as for a binary
.out file
All is new for me. I'll really appreciate any feedback. Thanks.
Regards,
Andrew
Reply by Andrew Nesterov●March 20, 20082008-03-20
> From: "Michael Dunn" mikedunn.0101
> Date: Tue Mar 18, 2008 7:41 am ((PDT))
>
> BTW, you can specify an alternate entry point [like
> '_RESET_' at address 0] when debugging embedded code.
Somehow I have totally overlooked this option. Well, I found it now:
it is the -e "entry_point" linker option that can be set in the
CCS at Project->Build Options->Linker Tab->Basic->Code Entry Point.
Very helpful; I several times was forced to add both _c_int00 and
_main symbols for debugging an assembly code without C runtime
environment. What can I say... Old age...
Thanks a lot!
Andrew
Reply by Michael Dunn●March 18, 20082008-03-18
Jim,
On 3/18/08, jim wrote: > On Tuesday 18 March 2008 12:32:14 you wrote:
> > Jim,
> >
> > On 3/18/08, jim wrote:
> > > On Tuesday 18 March 2008 08:35:27 you wrote:
> > > > Jim,
> > > >
> > > > On 3/17/08, jim wrote:
> > > > > Actually, I am now reading this program in a hex editor since,
upon
> > > > > further
> > > > > review, I have determined that _c_int00 is a named section that
> > > > > should be present someplace in the program file.
> > > > >
> > > > > Well, I have found it, but the label (which is 8 bytes long) is not
> > > > > word aligned.
> > > >
> > > > This doesn't sound right. It should be word aligned [00 in the
lower 2
> > > > bits] at a minimum.
> > > > Your previous post indicated that it was -
> > > > "_c_int00 (which is supposed to be at 0x14300 in this program)"
> > > > Are you sure that it is not your editor?? Are you looking at the
memory
> > > > from the Linux PC??
> > > > The CCS memory viewer should show you the correct bits and labels.
> > >
> > > When I load the program using CCS, then look at it using the memory
> > > viewer, it shows _c_int00 at 0x14300.
> > >
> > > When I load the program across the PCI bus from the Linux host,
location
> > > 0x14300 (actually all locations) are not labeled and the data/code
found
> > > at that location is different than it is when loaded using CCS.
> >
> > FYI-
> > You can do a 'load symbols only' from CCS to provide symbol info
in
> > the memory window [of course it will display relative to the addresses
> > that CCS expects].
> >
> > The mismatch is a problem.
> > You should get the exact same memory image - no matter how it is loaded.
> >
> > > I am loading the same program (the identical .out file) either way.
The
> > > program file I am loading is 225,096 bytes, so 0x14300 is certainly
> > > within that range.
> > >
> > > I do all my work in Linux, except for that stuff where I have no choice
> > > (such as using CCS) so the hex editor I am using is khexedit, a Linux
> > > package. I am looking at the actual bytes of data in the file; the
label
> > > is as I reported it. If, as Andrew stated, this is merely a symbol
table
> > > in the executable then the alignment is explained.
> > >
> > > However, what is not explained is why the contents of 0x14300 are
> > > different between a load by CCS and a load across the PCI bus. I
suppose
> > > that the boot loader at _c_int00 is rearranging things...
> >
> > I am not sure exactly how you are loading the program from the host.
> > If you are parsing the '.out' file and doing memory writes via
PCI
> > [the normal PCI load sequence] you should have the same memory
> > contents. The fact that the contents differ, seems to indicate
> > different logic in the 2 load paths.
> > OUTfile->CCS->JTAG->DSP->Memory
> > vs.
> > OUTfile->loader->PCIdriver->PCIbus->DSP->Memory
> >
> Well, this is almost what is happening. In fact, the description of how I
> load from the linux host is accurate, but the description of what is
> happening when CCS loads it is missing one step. Should say:
>
> OUTfile->CCS->JTAG->DSP->Memory->bootloader
bootloader?? I am not sure what you mean.
CCS works almost the same as your loader.
When you do a program load from CCS, the upper level reads a COFF
file, parses it, saves the symbols for later use, picks off 'stuff to
be loaded to the target', builds memory write commands, sends them to
the emulation driver, they are then converted to magical JTAG
sequences that logic on DSP converts to memory writes. When you do a
program load on a 6416 there is no bootloader involved - just a bunch
of memory writes. >
> Reading the docs tells me that the bootloader will move things around; I am
> guessing (pure guess) that this is what is happening.
To what docs are you referring??
> After doing a load
> from CCS, the moment I try to look at the memory locations that contain the
> code I see tagged sections. _c_int00 is clearly identified as such. This
> means that the bootloader must have run, or if not the bootloader, then
> something ran in order to label the code.
>From the info above - Any time that CCS performs a
memory read, he checks the symbol table that he built on the last program load [or
symbol load] to see if there are relevant symbols. If you load program
A followed by a symbol only load of program B, then display memory,
you will see things are 'all messed up' because Program A data will
be
displayed but the symbols will be from program B.
>
> Now, in fact, the low memory (location 0x0 and some distance forward...not
> sure how far forward...) is the same when loaded from CCS or when loaded
from
> the host.
>
> To make this clear, the 32 bit word at 0x14300 in the program file (the
.out
> file) contains the values 2b593a5c, which is ASCII values +Y:\ and is part
of
> a string that goes like this
>
> +Y:\port\c60\5_1_0\build\rts_pc\6400\trgdrv.asm:L15:1:1111601720
>
> Note that any line wraps in that string are introduced by the email
> client...it is as written without any returns or breaks in the code.
>
> Also note that there is an endian issue here; on CCS this would display as
> 5c3a592b, but we can deal with that.
>
> The location 0x14300 in memory after CCS loads it is as follows:
> 0x00000212 which is disassembled as
>
> B.S2 0x14310
>
> What are the implications of JTAG? Is this a CCS-only thing? Or does it
> impact the load and lead to things that I need to duplicate with my loader?
No problems with JTAG. In the past I put together a loader that would
load from either JTAG or HPI [host port interface]. The only
difference was the low level write implementation - feed the
address/data to HPI driver or the JTAG driver.
>
> The C code that actually loads the program into the DSP at the specified
> address is linux userspace code that works as follows:
>
> char c;
> char *cmdstr="resetdsp;buf0mempage=0x0;buf0setoffset=0x0;setcontext=L;";
>
> (other code)
>
> useprog = "dsp_program";
> progfile = open(useprog,0);
>
> (other code)
>
> cmdfile=fopen("/proc/driver/tidsp","r+");
> fwrite(cmdstr,buflen(cmdstr),1,cmdfile);
> fclose(cmdfile);
> outfile=open("/dev/tidsp0",1);
> while((ii = read(progfile,&c,1)) > 0) {
> write(outfile,&c,1);
> }
> close(outfile);
> close(progfile);
>
> For those who do not know linux, a brief explanation.
>
> /proc/driver/tidsp is the location of the command interface to my linux
> driver. I write cmdstr to there to command the driver to do the following
> things: reset the dsp, set up the memory buffer (buffer 0...the one that
> spans the entire memory address space in 4 meg pages) to page 0, set the
> offset within that page to 0 (thus writing starting at location 0x0), and
do
> a setcontext, which has meaning to my Linux driver but not to the DSP.
>
> I then open /dev/tidsp0 which is the linux system's entry point to the
device
> that represents the PCI memory locations represented by that 4 meg page on
> the DSP, and I ship the program byte by byte over to the dsp where it is
> indeed being written in the proper location.
>
> > If the problem is not obvious, like addresses off by n bytes, I
> > suggest a simple test program for your loader. I use a C program to
> > write and asm program of nothing but '.word nnnnnnnn' s. The
windoze
> > code below will generate an asm file that is a sequence of numbers
> > with labels. You can compile the file, load the '.out' from your
Linux
> > box and load the symbols from CCS. Mismatches are easy to spot.
> >
> > #include
> > int main()
> > {
> > FILE *fptr;
> > unsigned int i;
> > static char buf[200];
> >
> > fptr = fopen("loadfile1.asm", "w");
> > fprintf(fptr, "\t.sect\t\".text\"\n");
> > for(i=0; i<0x10000; i += 4)
> > {
> > sprintf(buf, "L_%04X:\n", i);
> > fprintf(fptr, buf);
> > sprintf(buf, "\t.word\t0x%04X%04X\n", i, i);
> > fprintf(fptr, buf);
> > }
> > fprintf(fptr, "THE_END:\n");
> > }
>
> Ummm...load the program from my loader, but load the symbols from CCS? How
> will that work? CCS will load the symbols from the copy of the .out file
> that it has? How will a mismatch show in this event?
>
> Actually, I just tried this using my release program. I reset the dsp,
then
> loaded my program from the host with the loader. I then connected CCS to
the
> dsp and did a symbol-only load.
>
> The symbol-only load placed the tag _c_int00 at location 0x14300, and the
code
> at that location is the same identical code as exists in my source file
> (represented in CCS as 0x5c3a592b).
>
> This is making the problem a lot clearer, I think. CCS is doing something
> OTHER than a byte for byte load of the program, or alternatively the
> bootloader that is hidden someplace in that program is doing something to
> rearrange, copy, and initialize things.
>
> My loader is merely shipping the program disk image, byte for byte, to the
> DSP, and this must be wrong.
You are probably doing the right thing - a direct load like CCS does.
Are you 100% sure that your disk image is correct??
One thought:
You can zero memory and load your program via CCS. Go to memory data
save and save the first 'n' KB [64k?] of memory into a text file.
You
can look at the first few bytes and figure out the bonehead format.
Next, write a script or program to convert your 'disk image' into
the
same format so that you can diff them.
> Some action is being taken along the way to
> rearrange this disk image into an executable image, and I don't know
what.
> The bootloader, I suppose, but I don't know why the appropriate jumps are
not
> being set up by the linker.
No. No. No.
Either forget about this 'bootloader thing' or let me in on what it
is.
I have loaded hundreds of out files [with several different loaders]
via CCS or a remote host with no problems. >
> But if my disk image has _c_int00 as a tag in a symbol table only, exactly
> what actions do I need to take to identify the location and point to the
boot
> loader?
If your disk image has any tags or symbols, it is not correct. No
symbolic info resides on the target.
On Tuesday 18 March 2008 12:32:14 you wrote: > Jim,
>
> On 3/18/08, jim wrote:
> > On Tuesday 18 March 2008 08:35:27 you wrote:
> > > Jim,
> > >
> > > On 3/17/08, jim wrote:
> > > > Actually, I am now reading this program in a hex editor since, upon
> > > > further
> > > > review, I have determined that _c_int00 is a named section that
> > > > should be present someplace in the program file.
> > > >
> > > > Well, I have found it, but the label (which is 8 bytes long) is not
> > > > word aligned.
> > >
> > > This doesn't sound right. It should be word aligned [00 in the lower
2
> > > bits] at a minimum.
> > > Your previous post indicated that it was -
> > > "_c_int00 (which is supposed to be at 0x14300 in this program)"
> > > Are you sure that it is not your editor?? Are you looking at the memory
> > > from the Linux PC??
> > > The CCS memory viewer should show you the correct bits and labels.
> >
> > When I load the program using CCS, then look at it using the memory
> > viewer, it shows _c_int00 at 0x14300.
> >
> > When I load the program across the PCI bus from the Linux host, location
> > 0x14300 (actually all locations) are not labeled and the data/code found
> > at that location is different than it is when loaded using CCS.
>
> FYI-
> You can do a 'load symbols only' from CCS to provide symbol info
in
> the memory window [of course it will display relative to the addresses
> that CCS expects].
>
> The mismatch is a problem.
> You should get the exact same memory image - no matter how it is loaded.
>
> > I am loading the same program (the identical .out file) either way. The
> > program file I am loading is 225,096 bytes, so 0x14300 is certainly
> > within that range.
> >
> > I do all my work in Linux, except for that stuff where I have no choice
> > (such as using CCS) so the hex editor I am using is khexedit, a Linux
> > package. I am looking at the actual bytes of data in the file; the label
> > is as I reported it. If, as Andrew stated, this is merely a symbol table
> > in the executable then the alignment is explained.
> >
> > However, what is not explained is why the contents of 0x14300 are
> > different between a load by CCS and a load across the PCI bus. I suppose
> > that the boot loader at _c_int00 is rearranging things...
>
> I am not sure exactly how you are loading the program from the host.
> If you are parsing the '.out' file and doing memory writes via
PCI
> [the normal PCI load sequence] you should have the same memory
> contents. The fact that the contents differ, seems to indicate
> different logic in the 2 load paths.
> OUTfile->CCS->JTAG->DSP->Memory
> vs.
> OUTfile->loader->PCIdriver->PCIbus->DSP->Memory
> Well, this is almost what is happening. In fact, the description of how
I
load from the linux host is accurate, but the description of what is
happening when CCS loads it is missing one step. Should say:
OUTfile->CCS->JTAG->DSP->Memory->bootloader
Reading the docs tells me that the bootloader will move things around; I am
guessing (pure guess) that this is what is happening. After doing a load
from CCS, the moment I try to look at the memory locations that contain the
code I see tagged sections. _c_int00 is clearly identified as such. This
means that the bootloader must have run, or if not the bootloader, then
something ran in order to label the code.
Now, in fact, the low memory (location 0x0 and some distance forward...not
sure how far forward...) is the same when loaded from CCS or when loaded from
the host.
To make this clear, the 32 bit word at 0x14300 in the program file (the .out
file) contains the values 2b593a5c, which is ASCII values +Y:\ and is part of
a string that goes like this
For those who do not know linux, a brief explanation.
/proc/driver/tidsp is the location of the command interface to my linux
driver. I write cmdstr to there to command the driver to do the following
things: reset the dsp, set up the memory buffer (buffer 0...the one that
spans the entire memory address space in 4 meg pages) to page 0, set the
offset within that page to 0 (thus writing starting at location 0x0), and do
a setcontext, which has meaning to my Linux driver but not to the DSP.
I then open /dev/tidsp0 which is the linux system's entry point to the
device
that represents the PCI memory locations represented by that 4 meg page on
the DSP, and I ship the program byte by byte over to the dsp where it is
indeed being written in the proper location.
> If the problem is not obvious, like addresses off by
n bytes, I
> suggest a simple test program for your loader. I use a C program to
> write and asm program of nothing but '.word nnnnnnnn' s. The
windoze
> code below will generate an asm file that is a sequence of numbers
> with labels. You can compile the file, load the '.out' from your
Linux
> box and load the symbols from CCS. Mismatches are easy to spot.
>
> #include
> int main()
> {
> FILE *fptr;
> unsigned int i;
> static char buf[200];
>
> fptr = fopen("loadfile1.asm", "w");
> fprintf(fptr, "\t.sect\t\".text\"\n");
> for(i=0; i<0x10000; i += 4)
> {
> sprintf(buf, "L_%04X:\n", i);
> fprintf(fptr, buf);
> sprintf(buf, "\t.word\t0x%04X%04X\n", i, i);
> fprintf(fptr, buf);
> }
> fprintf(fptr, "THE_END:\n");
> }
Ummm...load the program from my loader, but load the symbols from CCS? How
will that work? CCS will load the symbols from the copy of the .out file
that it has? How will a mismatch show in this event?
Actually, I just tried this using my release program. I reset the dsp, then
loaded my program from the host with the loader. I then connected CCS to the
dsp and did a symbol-only load.
The symbol-only load placed the tag _c_int00 at location 0x14300, and the code
at that location is the same identical code as exists in my source file
(represented in CCS as 0x5c3a592b).
This is making the problem a lot clearer, I think. CCS is doing something
OTHER than a byte for byte load of the program, or alternatively the
bootloader that is hidden someplace in that program is doing something to
rearrange, copy, and initialize things.
My loader is merely shipping the program disk image, byte for byte, to the
DSP, and this must be wrong. Some action is being taken along the way to
rearrange this disk image into an executable image, and I don't know what.
The bootloader, I suppose, but I don't know why the appropriate jumps are
not
being set up by the linker.
But if my disk image has _c_int00 as a tag in a symbol table only, exactly
what actions do I need to take to identify the location and point to the boot
loader?
Reply by Michael Dunn●March 18, 20082008-03-18
Jim,
On 3/18/08, jim wrote: > On Tuesday 18 March 2008 08:35:27 you wrote:
> > Jim,
> >
> > On 3/17/08, jim wrote:
> > > Actually, I am now reading this program in a hex editor since, upon
> > > further
> > > review, I have determined that _c_int00 is a named section that should
be
> > > present someplace in the program file.
> > >
> > > Well, I have found it, but the label (which is 8 bytes long) is not
word
> > > aligned.
> >
> > This doesn't sound right. It should be word aligned [00 in the lower
2
> > bits] at a minimum.
> > Your previous post indicated that it was -
> > "_c_int00 (which is supposed to be at 0x14300 in this program)"
> > Are you sure that it is not your editor?? Are you looking at the memory
> > from the Linux PC??
> > The CCS memory viewer should show you the correct bits and labels.
> >
> When I load the program using CCS, then look at it using the memory viewer,
it
> shows _c_int00 at 0x14300.
>
> When I load the program across the PCI bus from the Linux host, location
> 0x14300 (actually all locations) are not labeled and the data/code found at
> that location is different than it is when loaded using CCS. FYI-
You can do a 'load symbols only' from CCS to provide symbol info in
the memory window [of course it will display relative to the addresses
that CCS expects].
The mismatch is a problem.
You should get the exact same memory image - no matter how it is loaded.
>
> I am loading the same program (the identical .out file) either way. The
> program file I am loading is 225,096 bytes, so 0x14300 is certainly within
> that range.
>
> I do all my work in Linux, except for that stuff where I have no choice
(such
> as using CCS) so the hex editor I am using is khexedit, a Linux package. I
> am looking at the actual bytes of data in the file; the label is as I
> reported it. If, as Andrew stated, this is merely a symbol table in the
> executable then the alignment is explained.
>
> However, what is not explained is why the contents of 0x14300 are different
> between a load by CCS and a load across the PCI bus. I suppose that the
boot
> loader at _c_int00 is rearranging things...
I am not sure exactly how you are loading the program from the host.
If you are parsing the '.out' file and doing memory writes via PCI
[the normal PCI load sequence] you should have the same memory
contents. The fact that the contents differ, seems to indicate
different logic in the 2 load paths.
OUTfile->CCS->JTAG->DSP->Memory
vs.
OUTfile->loader->PCIdriver->PCIbus->DSP->Memory
If the problem is not obvious, like addresses off by n bytes, I
suggest a simple test program for your loader. I use a C program to
write and asm program of nothing but '.word nnnnnnnn' s. The
windoze
code below will generate an asm file that is a sequence of numbers
with labels. You can compile the file, load the '.out' from your
Linux
box and load the symbols from CCS. Mismatches are easy to spot.
#include
int main()
{
FILE *fptr;
unsigned int i;
static char buf[200];
On Tuesday 18 March 2008 08:35:27 you wrote: > Jim,
>
> On 3/17/08, jim wrote:
> > Actually, I am now reading this program in a hex editor since, upon
> > further
> > review, I have determined that _c_int00 is a named section that should be
> > present someplace in the program file.
> >
> > Well, I have found it, but the label (which is 8 bytes long) is not word
> > aligned.
>
> This doesn't sound right. It should be word aligned [00 in the lower 2
> bits] at a minimum.
> Your previous post indicated that it was -
> "_c_int00 (which is supposed to be at 0x14300 in this program)"
> Are you sure that it is not your editor?? Are you looking at the memory
> from the Linux PC??
> The CCS memory viewer should show you the correct bits and labels.
> When I load the program using CCS, then look at it using the memory
viewer, it
shows _c_int00 at 0x14300.
When I load the program across the PCI bus from the Linux host, location
0x14300 (actually all locations) are not labeled and the data/code found at
that location is different than it is when loaded using CCS.
I am loading the same program (the identical .out file) either way. The
program file I am loading is 225,096 bytes, so 0x14300 is certainly within
that range.
I do all my work in Linux, except for that stuff where I have no choice (such
as using CCS) so the hex editor I am using is khexedit, a Linux package. I
am looking at the actual bytes of data in the file; the label is as I
reported it. If, as Andrew stated, this is merely a symbol table in the
executable then the alignment is explained.
However, what is not explained is why the contents of 0x14300 are different
between a load by CCS and a load across the PCI bus. I suppose that the boot
loader at _c_int00 is rearranging things...
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by Michael Dunn●March 18, 20082008-03-18
Jim,
On 3/17/08, jim wrote:
> Actually, I am now reading this program in a hex
editor since, upon
> further
> review, I have determined that _c_int00 is a named section that should be
> present someplace in the program file.
>
> Well, I have found it, but the label (which is 8 bytes long) is not word
> aligned.
>
This doesn't sound right. It should be word aligned [00 in the lower 2
bits]
at a minimum.
Your previous post indicated that it was -
"_c_int00 (which is supposed to be at 0x14300 in this program)"
Are you sure that it is not your editor?? Are you looking at the memory from
the Linux PC??
The CCS memory viewer should show you the correct bits and labels.
mikedunn
> Should I branch the program to the BYTE that
immediately follows the
> label, or
> to the first complete 2 byte WORD that follows the label, or to the first
> 4
> byte LONGWORD that follows the label?
>
> Specifically, this label starts at location 0x3020d and finishes at
> 0x30214.
> So the first byte after the label is 0x30215, which is not correct
> alignment,
> but I do not know if the processor cares. The first word after the label
> is
> 0x30216 and the first longword is 0x30218.
>
> And how do I set the PC from outside anyway?