Sign in
Search c6x
Subscribe to c6x
c6x by Keywords
AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560
Discussion Groups
Discussion Groups | TMS320C6x | BOOT LOADER
Technical discussions about the TI C6000 DSPs (including the c62x, c64x and c67x DSPs).
BOOT LOADER - adee...@gmail.com - Nov 9 8:22:54 2006
hi i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA Please guide me in how to write bootloader??? What setting are required in writing bootloader?? What is algorithm of bootlaoding ??? Sequence of operations needed by DSP after reset and power on related to bootloading????
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: BOOT LOADER - William C Bonner - Nov 9 18:39:51 2006
I believe that I know some of the things that would be involved, and
would be interested in having source for my own personal boot loader,
but I don't have time to write my own just now.
Steps I'd like my boot loader to do.
1. initialize the basic hardware setup. (RAM access and Flash Access)
2. verify a valid COFF object file exists in flash.
3. load a COFF file from flash into RAM, interpreting all of the
relocation entries correctly and adjusting them as needed.
4. transfer control to the loaded image.
That's what I believe I'd like a boot loader to do. As an extension I
want the boot loader to be able to do the following:
* Failing to find a valid image in flash, attempt to transfer a
valid image via a verified transport over either a serial port or
a network port, either loading directly into ram and transferring
control, or writing to flash and then starting the sequence from
the time. (When I say verified transport I mean something like
Xmodem / Ymodem / Zmodem that uses block checking via CRCs on the
whole file, so that control wouldn't be transferred until the
whole image was verified as being transferred.)
* allow choosing from multiple images in flash.
After listing my collection of "wants" I'm interested in knowing how
much of what I want normally falls into what a boot loader does?
a...@gmail.com wrote:
> hi
> i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA
>
> Please guide me in
> how to write bootloader???
>
> What setting are required in writing bootloader??
>
> What is algorithm of bootlaoding ???
>
> Sequence of operations needed by DSP after reset and power on related to bootloading????
>
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: BOOT LOADER - skuz...@tx.rr.com - Nov 9 18:42:53 2006
Greetings, It seems to me that you want to start your system booting from a device on the EMIF I/F. >From C6713 data sheet, SPRS186J EMIF boot (using default ROM timings) Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally “stalled”. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the “stalled” state and start running from address 0. Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format. If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU. Good luck. hi >i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA > >Please guide me in >how to write bootloader??? > >What setting are required in writing bootloader?? > >What is algorithm of bootlaoding ??? > >Sequence of operations needed by DSP after reset and power on related to bootloading????
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - Jeff Brower - Nov 10 10:22:38 2006
Adeel Shahze- I would add to Skuzbary's comments that for the secondary bootloader, there are lots of app notes and source examples to follow given by TI for other DSPs. Most of the 54xx and 55xx families have very full-featured internal bootloaders stored in internal chip ROM, and tyically TI posts bootloader source code for those devices somewhere. The code is in asm, but typically almost commented line-by-line. Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which is the standard TI utility for generating bootloadable files / images for C6x devices. -Jeff s...@tx.rr.com wrote: > > Greetings, > > It seems to me that you want to start your system booting from a device on the EMIF I/F. > > From C6713 data sheet, SPRS186J > > EMIF boot (using default ROM timings) > > Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally “stalled”. The data should be stored in the endian format that the system is using. The boot process also lets you choose the width of the ROM. In this case, the EMIF automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from the ROM to address 0. After completion of the block transfer, the CPU is released from the “stalled” state and start running from address 0. > > Your code generation is capable of generating FLASH code that is compatible with this EMIF Boot using TI's COFF format. > > If you elect to write your own bootloader, which will be secondary bootloader, and will execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give it control of the CPU. > > Good luck. > > hi > >i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through EDMA > > > >Please guide me in > >how to write bootloader??? > > > >What setting are required in writing bootloader?? > > > >What is algorithm of bootlaoding ??? > > > >Sequence of operations needed by DSP after reset and power on related to bootloading????
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - skuz...@tx.rr.com - Nov 12 16:33:29 2006
Greetings,
Here is an example done for the 6xxx, which is applicable tour your case too. You may need to
mod the addresses for your device and memory map.
;EMIFA Register Addresses for c6xxx family
EMIFA_GCTL .equ 0x01800000 ;EMIFA global control
EMIFA_CE1 .equ 0x01800004 ;EMIFA CE1 control
; EMIFA Register Values specifically for Custom Board
EMIFA_GCTL_V .equ 0x00012778 ;
EMIFA_CE1_V .equ 0x42A4CA02 ;EMIFA CE1 default value
unused .macro id
.global unused:id:
unused:id:
b unused:id: ; nested branches to block interrupts
nop 4
nop
nop
nop
nop
nop
nop
.endm
.ref _c_int00
.global RESET_RST
FLASH_START .equ 0x90000400 ;flash start address
CODE_START .equ 0x00000400 ;start of boot code
CODE_SIZE .equ 0x00003BF8 ;boot code size in byte
.sect "vectors"
RESET_RST:
mvkl .S2 _boot_start, B0
mvkh .S2 _boot_start, B0
B .S2 B0
NOP
NOP
NOP
NOP
NOP
unused 1
unused 2
unused 3
unused 4
unused 5
unused 6
unused 7
unused 8
unused 9
unused 10
unused 11
unused 12
unused 13
unused 14
unused 15
.sect "bootload"
_boot_start:
;disable global interrupts
mvc.s2 CSR,B4
and.d2 -2,B4,B4
mvc.s2 B4,CSR
nop
;****************************************************************
; *EMIFA_GCTL = EMIFA_GCTL_V;
;****************************************************************
mvkl EMIFA_GCTL,A4
|| mvkl EMIFA_GCTL_V,B4
mvkh EMIFA_GCTL,A4
|| mvkh EMIFA_GCTL_V,B4
stw B4,*A4
;****************************************************************
; *EMIFA_CE1 = EMIFA_CE1_V (not used)
;****************************************************************
mvkl EMIFA_CE1,A4
|| mvkl EMIFA_CE1_V,B4
mvkh EMIFA_CE1,A4
|| mvkh EMIFA_CE1_V,B4
stw B4,*A4
mvkl FLASH_START,B4 ;flash start address ->B4
mvkh FLASH_START,B4
mvkl CODE_START,A4 ;apps code start address ->A4
mvkh CODE_START,A4
zero A1
_boot_loop1:
ldb *B4++,B5 ; flash read
mvkl CODE_SIZE,B6 ; B6 = BOOT_SIZE
add 1,A1,A1 ;A1+=1,inc outer counter
|| mvkh CODE_SIZE,B6
cmplt A1,B6,B0
nop
stb B5,*A4++
[B0]b _boot_loop1
nop 5
mvkl .S2 _c_int00, B0
mvkh .S2 _c_int00, B0
B .S2 B0
nop 5
Good luck
Adeel Shahze-
>
>I would add to Skuzbary's comments that for the secondary bootloader, there are lots
>of app notes and source examples to follow given by TI for other DSPs. Most of the
>54xx and 55xx families have very full-featured internal bootloaders stored in
>internal chip ROM, and tyically TI posts bootloader source code for those devices
>somewhere. The code is in asm, but typically almost commented line-by-line.
>
>Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which
>is the standard TI utility for generating bootloadable files / images for C6x
>devices.
>
>-Jeff
>
>s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device on the EMIF
I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of
CE1 is copied to address 0 by the EDMA using the default ROM timings, while the CPU is
internally “stalled”. The data should be stored in the endian format that the system is using.
The boot process also lets you choose the width of the ROM. In this case, the EMIF
automatically assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit
instruction words to be copied. The transfer is automatically done by the EDMA as a
single-frame block transfer from the ROM to address 0. After completion of the block transfer,
the CPU is released from the “stalled” state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is compatible with this
EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary bootloader, and
will execute once the ROM bootloader copy it into internal RAM, then you can have a standard
bitmap load stored in your FLASH, and you secondary bootloader will copy it to internal RAM,
then give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> > i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1
through EDMA
>> >
>> > Please guide me in
>> > how to write bootloader???
>> >
>> > What setting are required in writing bootloader??
>> >
>> > What is algorithm of bootlaoding ???
>> >
>> > Sequence of operations needed by DSP after reset and power on related to
bootloading????
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - Jeff Brower - Nov 12 16:33:46 2006
Suresh- > Since the discussion was on bootloader & hex6x.exe I would like to > confirm from the group (jeff) whether hex6x has a limitation that it > won't convert coff files(*.out files) greater than 600KB(I think it is > 640KB) properly. > > Say for example if the coff file is around 1000KB approximates only the > last 400KB(1000KB - 640 KB) would be converted to hex .This probably the > first 640KB gets overwritten by the next. Even the map file show the > same observation. I haven't heard that one before, but wouldn't be surprised -- unfortunately I've found and fought my way through lots of bugs in TI tools over the years before TI released fixed versions. My suggestions on this would be: -verify it's not intentional; for example maybe it's a limitation on the DSK version of tools; i.e. "non full version" -check with super experts on this group, including Mike Dunn, Bhooshan Iyer, and Andrew Nesterov -- maybe they know about this bug. Bhoohsan is hooked up with latest TI tools version and errata info, so maybe he knows -try the latest version of hex6x.exe from CCS v3.1x. It would be unlikely this bug could live long with some of the big programs people must be putting together for 641x platforms -Jeff > Jeff Brower <j...@signalogic.com> wrote: > Adeel Shahze- > > I would add to Skuzbary's comments that for the secondary bootloader, > there are lots > of app notes and source examples to follow given by TI for other DSPs. > Most of the > 54xx and 55xx families have very full-featured internal bootloaders stored > in > internal chip ROM, and tyically TI posts bootloader source code for those > devices > somewhere. The code is in asm, but typically almost commented > line-by-line. > > Also, whatever approach you take, I suggest you stay compatible with > hex6x.exe, which > is the standard TI utility for generating bootloadable files / images for > C6x > devices. > > -Jeff > > s...@tx.rr.com wrote: >> >> Greetings, >> >> It seems to me that you want to start your system booting from a device >> on the EMIF I/F. >> >> From C6713 data sheet, SPRS186J >> >> EMIF boot (using default ROM timings) >> >> Upon the release of internal reset, the 1K-Byte ROM code located in the >> beginning of CE1 is copied to address 0 by the EDMA using the default >> ROM timings, while the CPU is internally “stalled”. The data should be >> stored in the endian format that the system is using. The boot process >> also lets you choose the width of the ROM. In this case, the EMIF >> automatically assembles consecutive 8-bit bytes or 16-bit half-words to >> form the 32-bit instruction words to be copied. The transfer is >> automatically done by the EDMA as a single-frame block transfer from the >> ROM to address 0. After completion of the block transfer, the CPU is >> released from the “stalled” state and start running from address 0. >> >> Your code generation is capable of generating FLASH code that is >> compatible with this EMIF Boot using TI's COFF format. >> >> If you elect to write your own bootloader, which will be secondary >> bootloader, and will execute once the ROM bootloader copy it into >> internal RAM, then you can have a standard bitmap load stored in your >> FLASH, and you secondary bootloader will copy it to internal RAM, then >> give it control of the CPU. >> >> Good luck. >> >> hi >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at >> CE1 through EDMA >> > >> >Please guide me in >> >how to write bootloader??? >> > >> >What setting are required in writing bootloader?? >> > >> >What is algorithm of bootlaoding ??? >> > >> >Sequence of operations needed by DSP after reset and power on related >> to bootloading????
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - suresh kirthi - Nov 12 16:36:38 2006
Since the discussion was on bootloader & hex6x.exe I would like to confirm from the
group (jeff) whether hex6x has a limitation that it won't convert coff files(*.out files)
greater than 600KB(I think it is 640KB) properly.
Say for example if the coff file is around 1000KB approximates only the last 400KB(1000KB -
640 KB) would be converted to hex .This probably the first 640KB gets overwritten by the next.
Even the map file show the same observation.
thank you,
Suresh Kirthi,
Kolkata
Jeff Brower <j...@signalogic.com> wrote:
Adeel Shahze-
I would add to Skuzbary's comments that for the secondary bootloader, there are lots
of app notes and source examples to follow given by TI for other DSPs. Most of the
54xx and 55xx families have very full-featured internal bootloaders stored in
internal chip ROM, and tyically TI posts bootloader source code for those devices
somewhere. The code is in asm, but typically almost commented line-by-line.
Also, whatever approach you take, I suggest you stay compatible with hex6x.exe, which
is the standard TI utility for generating bootloadable files / images for C6x
devices.
-Jeff
s...@tx.rr.com wrote:
>
> Greetings,
>
> It seems to me that you want to start your system booting from a device on the EMIF I/F.
>
> From C6713 data sheet, SPRS186J
>
> EMIF boot (using default ROM timings)
>
> Upon the release of internal reset, the 1K-Byte ROM code located in the beginning of CE1
is copied to address 0 by the EDMA using the default ROM timings, while the CPU is internally
“stalled”. The data should be stored in the endian format that the system is using. The boot
process also lets you choose the width of the ROM. In this case, the EMIF automatically
assembles consecutive 8-bit bytes or 16-bit half-words to form the 32-bit instruction words to
be copied. The transfer is automatically done by the EDMA as a single-frame block transfer from
the ROM to address 0. After completion of the block transfer, the CPU is released from the
“stalled” state and start running from address 0.
>
> Your code generation is capable of generating FLASH code that is compatible with this EMIF
Boot using TI's COFF format.
>
> If you elect to write your own bootloader, which will be secondary bootloader, and will
execute once the ROM bootloader copy it into internal RAM, then you can have a standard bitmap
load stored in your FLASH, and you secondary bootloader will copy it to internal RAM, then give
it control of the CPU.
>
> Good luck.
>
> hi
> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at CE1 through
EDMA
> >
> >Please guide me in
> >how to write bootloader???
> >
> >What setting are required in writing bootloader??
> >
> >What is algorithm of bootlaoding ???
> >
> >Sequence of operations needed by DSP after reset and power on related to
bootloading????
Regards,
Suresh Kirthi..........
"If a problem can be solved there is no use worrying about it. If it can't be solved,
worrying will do no good."
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - suresh kirthi - Nov 12 16:37:56 2006
Jeff, Thank you Jeff. I'll elaborate on my problem: There was paging limitation of 512KB (though flash-memory is 4MB & this is due to address line limitation which are only 19 & rest 3bits are updated in FPGA page register )flashburn tool v2.8 provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation. And by the way I'am usin DM642 (720Mhz). I tried for the tool over the net to convert coff to hex but with hard-luck. But recently came to know about objcopy an utility of linux which does that conversion but still haven't tried it. I'am currently speaking to TI also.Incase there is any thing i'll keep the group posted. And in the meanwhile if anybody faced similar problem I would be grateful if you people could share your experience. thank you again, Suresh Kirthi, Kolkata. Jeff Brower <j...@signalogic.com> wrote: Suresh- > Since the discussion was on bootloader & hex6x.exe I would like to > confirm from the group (jeff) whether hex6x has a limitation that it > won't convert coff files(*.out files) greater than 600KB(I think it is > 640KB) properly. > > Say for example if the coff file is around 1000KB approximates only the > last 400KB(1000KB - 640 KB) would be converted to hex .This probably the > first 640KB gets overwritten by the next. Even the map file show the > same observation. I haven't heard that one before, but wouldn't be surprised -- unfortunately I've found and fought my way through lots of bugs in TI tools over the years before TI released fixed versions. My suggestions on this would be: -verify it's not intentional; for example maybe it's a limitation on the DSK version of tools; i.e. "non full version" -check with super experts on this group, including Mike Dunn, Bhooshan Iyer, and Andrew Nesterov -- maybe they know about this bug. Bhoohsan is hooked up with latest TI tools version and errata info, so maybe he knows -try the latest version of hex6x.exe from CCS v3.1x. It would be unlikely this bug could live long with some of the big programs people must be putting together for 641x platforms -Jeff > Jeff Brower wrote: > Adeel Shahze- > > I would add to Skuzbary's comments that for the secondary bootloader, > there are lots > of app notes and source examples to follow given by TI for other DSPs. > Most of the > 54xx and 55xx families have very full-featured internal bootloaders stored > in > internal chip ROM, and tyically TI posts bootloader source code for those > devices > somewhere. The code is in asm, but typically almost commented > line-by-line. > > Also, whatever approach you take, I suggest you stay compatible with > hex6x.exe, which > is the standard TI utility for generating bootloadable files / images for > C6x > devices. > > -Jeff > > s...@tx.rr.com wrote: >> >> Greetings, >> >> It seems to me that you want to start your system booting from a device >> on the EMIF I/F. >> >> From C6713 data sheet, SPRS186J >> >> EMIF boot (using default ROM timings) >> >> Upon the release of internal reset, the 1K-Byte ROM code located in the >> beginning of CE1 is copied to address 0 by the EDMA using the default >> ROM timings, while the CPU is internally “stalled”. The data should be >> stored in the endian format that the system is using. The boot process >> also lets you choose the width of the ROM. In this case, the EMIF >> automatically assembles consecutive 8-bit bytes or 16-bit half-words to >> form the 32-bit instruction words to be copied. The transfer is >> automatically done by the EDMA as a single-frame block transfer from the >> ROM to address 0. After completion of the block transfer, the CPU is >> released from the “stalled” state and start running from address 0. >> >> Your code generation is capable of generating FLASH code that is >> compatible with this EMIF Boot using TI's COFF format. >> >> If you elect to write your own bootloader, which will be secondary >> bootloader, and will execute once the ROM bootloader copy it into >> internal RAM, then you can have a standard bitmap load stored in your >> FLASH, and you secondary bootloader will copy it to internal RAM, then >> give it control of the CPU. >> >> Good luck. >> >> hi >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at >> CE1 through EDMA >> > >> >Please guide me in >> >how to write bootloader??? >> > >> >What setting are required in writing bootloader?? >> > >> >What is algorithm of bootlaoding ??? >> > >> >Sequence of operations needed by DSP after reset and power on related >> to bootloading???? Regards, Suresh Kirthi.......... "If a problem can be solved there is no use worrying about it. If it can't be solved, worrying will do no good."
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - Jeff Brower - Nov 12 16:44:39 2006
Suresh- > Jeff,Thank you Jeff.I'll elaborate on my problem: There was paging limitation of > 512KB (though flash-memory is 4MB & this is due to address line limitation which > are only 19 & rest 3bits are updated in FPGA page register )flashburn tool v2.8 > provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn > provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation. > And by the way I'am usin DM642 (720Mhz). Ok, but these are separate issues, right? Whether hex6x.exe generates correct .rom file is independent of which utility is used to actually write to Flash (Flashburn, in-house, etc). > I tried for the tool over the net to convert coff to hex but with hard-luck. But > recently came to know about objcopy an utility of linux which does that conversion > but still haven't tried it. You might look for "TI COFF Loader" source code or similar; i.e. program that reads .out file and loads to DSP memory. If you can find that source, then you can modify to write data to binary or ASCII file. > I'am currently speaking to TI also.Incase there is any thing i'll keep the group > posted.And in the meanwhile if anybody faced similar problem I would be grateful if > you people could share your experience. If TI confirms a bug in hex6x, then yes please mention on the group. Could save people a lot of time. -Jeff > Jeff Brower <j...@signalogic.com> wrote: > > Suresh- > > > Since the discussion was on bootloader & hex6x.exe I would like to > > confirm from the group (jeff) whether hex6x has a limitation that it > > won't convert coff files(*.out files) greater than 600KB(I think it is > > 640KB) properly. > > > > Say for example if the coff file is around 1000KB approximates only the > > > last 400KB(1000KB - 640 KB) would be converted to hex .This probably > the > > first 640KB gets overwritten by the next. Even the map file show the > > same observation. > > I haven't heard that one before, but wouldn't be surprised -- > unfortunately I've found and fought my way through lots of bugs in TI > tools over the years before TI released fixed versions. > > My suggestions on this would be: > > -verify it's not intentional; for example maybe it's > a limitation on the DSK version of tools; i.e. "non > full version" > > -check with super experts on this group, including > Mike Dunn, Bhooshan Iyer, and Andrew Nesterov -- > maybe they know about this bug. Bhoohsan is > hooked up with latest TI tools version and errata > info, so maybe he knows > > -try the latest version of hex6x.exe from CCS v3.1x. > It would be unlikely this bug could live long with > some of the big programs people must be putting > together for 641x platforms > > -Jeff > > > Jeff Brower wrote: > > Adeel Shahze- > > > > I would add to Skuzbary's comments that for the secondary bootloader, > > there are lots > > of app notes and source examples to follow given by TI for other DSPs. > > Most of the > > 54xx and 55xx families have very full-featured internal bootloaders > stored > > in > > internal chip ROM, and tyically TI posts bootloader source code for > those > > devices > > somewhere. The code is in asm, but typically almost commented > > line-by-line. > > > > Also, whatever approach you take, I suggest you stay compatible with > > hex6x.exe, which > > is the standard TI utility for generating bootloadable files / images > for > > C6x > > devices. > > > > -Jeff > > > > s...@tx.rr.com wrote: > >> > >> Greetings, > >> > >> It seems to me that you want to start your system booting from a > device > >> on the EMIF I/F. > >> > >> From C6713 data sheet, SPRS186J > >> > >> EMIF boot (using default ROM timings) > >> > >> Upon the release of internal reset, the 1K-Byte ROM code located in > the > >> beginning of CE1 is copied to address 0 by the EDMA using the default > >> ROM timings, while the CPU is internally “stalled”. The data should be > > >> stored in the endian format that the system is using. The boot process > > >> also lets you choose the width of the ROM. In this case, the EMIF > >> automatically assembles consecutive 8-bit bytes or 16-bit half-words > to > >> form the 32-bit instruction words to be copied. The transfer is > >> automatically done by the EDMA as a single-frame block transfer from > the > >> ROM to address 0. After completion of the block transfer, the CPU is > >> released from the “stalled” state and start running from address 0. > >> > >> Your code generation is capable of generating FLASH code that is > >> compatible with this EMIF Boot using TI's COFF format. > >> > >> If you elect to write your own bootloader, which will be secondary > >> bootloader, and will execute once the ROM bootloader copy it into > >> internal RAM, then you can have a standard bitmap load stored in your > >> FLASH, and you secondary bootloader will copy it to internal RAM, then > > >> give it control of the CPU. > >> > >> Good luck. > >> > >> hi > >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom > at > >> CE1 through EDMA > >> > > >> >Please guide me in > >> >how to write bootloader??? > >> > > >> >What setting are required in writing bootloader?? > >> > > >> >What is algorithm of bootlaoding ??? > >> > > >> >Sequence of operations needed by DSP after reset and power on related > > >> to bootloading???? > Regards, > Suresh Kirthi.......... >
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - suresh kirthi - Nov 14 11:32:46 2006
Jeff & 6x group,
I spoke to TI they have accepted that hex converter (hex6x) of TI seem to have some
limitation that it cannot convert *.out greater than 512KB to hex properly (rather it
overwrites ).
be aware of this when burning your application on flash.
thank you,
suresh kirthi
kolkata
suresh kirthi <k...@yahoo.com> wrote:
Jeff,
Thank you Jeff.
I'll elaborate on my problem:
There was paging limitation of 512KB (though flash-memory is 4MB & this is due to address
line limitation which are only 19 & rest 3bits are updated in FPGA page register )flashburn
tool v2.8 provided by TI with CCS v 3.1 which I got it fixed by talking to the flashburn
provider SDS. But I somehow feel even the hex6x tool of TI has similar limitation. And by the
way I'am usin DM642 (720Mhz).
I tried for the tool over the net to convert coff to hex but with hard-luck. But recently came
to know about objcopy an utility of linux which does that conversion but still haven't tried
it.
I'am currently speaking to TI also.Incase there is any thing i'll keep the group posted.
And in the meanwhile if anybody faced similar problem I would be grateful if you people could
share your experience.
thank you again,
Suresh Kirthi,
Kolkata.
Jeff Brower <j...@signalogic.com> wrote:
Suresh-
> Since the discussion was on bootloader & hex6x.exe I would like to
> confirm from the group (jeff) whether hex6x has a limitation that it
> won't convert coff files(*.out files) greater than 600KB(I think it is
> 640KB) properly.
>
> Say for example if the coff file is around 1000KB approximates only the
> last 400KB(1000KB - 640 KB) would be converted to hex .This probably the
> first 640KB gets overwritten by the next. Even the map file show the
> same observation.
I haven't heard that one before, but wouldn't be surprised --
unfortunately I've found and fought my way through lots of bugs in TI
tools over the years before TI released fixed versions.
My suggestions on this would be:
-verify it's not intentional; for example maybe it's
a limitation on the DSK version of tools; i.e. "non
full version"
-check with super experts on this group, including
Mike Dunn, Bhooshan Iyer, and Andrew Nesterov --
maybe they know about this bug. Bhoohsan is
hooked up with latest TI tools version and errata
info, so maybe he knows
-try the latest version of hex6x.exe from CCS v3.1x.
It would be unlikely this bug could live long with
some of the big programs people must be putting
together for 641x platforms
-Jeff
> Jeff Brower wrote:
> Adeel Shahze-
>
> I would add to Skuzbary's comments that for the secondary bootloader,
> there are lots
> of app notes and source examples to follow given by TI for other DSPs.
> Most of the
> 54xx and 55xx families have very full-featured internal bootloaders stored
> in
> internal chip ROM, and tyically TI posts bootloader source code for those
> devices
> somewhere. The code is in asm, but typically almost commented
> line-by-line.
>
> Also, whatever approach you take, I suggest you stay compatible with
> hex6x.exe, which
> is the standard TI utility for generating bootloadable files / images for
> C6x
> devices.
>
> -Jeff
>
> s...@tx.rr.com wrote:
>>
>> Greetings,
>>
>> It seems to me that you want to start your system booting from a device
>> on the EMIF I/F.
>>
>> From C6713 data sheet, SPRS186J
>>
>> EMIF boot (using default ROM timings)
>>
>> Upon the release of internal reset, the 1K-Byte ROM code located in the
>> beginning of CE1 is copied to address 0 by the EDMA using the default
>> ROM timings, while the CPU is internally “stalled”. The data should be
>> stored in the endian format that the system is using. The boot process
>> also lets you choose the width of the ROM. In this case, the EMIF
>> automatically assembles consecutive 8-bit bytes or 16-bit half-words to
>> form the 32-bit instruction words to be copied. The transfer is
>> automatically done by the EDMA as a single-frame block transfer from the
>> ROM to address 0. After completion of the block transfer, the CPU is
>> released from the “stalled” state and start running from address 0.
>>
>> Your code generation is capable of generating FLASH code that is
>> compatible with this EMIF Boot using TI's COFF format.
>>
>> If you elect to write your own bootloader, which will be secondary
>> bootloader, and will execute once the ROM bootloader copy it into
>> internal RAM, then you can have a standard bitmap load stored in your
>> FLASH, and you secondary bootloader will copy it to internal RAM, then
>> give it control of the CPU.
>>
>> Good luck.
>>
>> hi
>> >i hav givenn a task for writing bootloader for c6713 ,from flash rom at
>> CE1 through EDMA
>> >
>> >Please guide me in
>> >how to write bootloader???
>> >
>> >What setting are required in writing bootloader??
>> >
>> >What is algorithm of bootlaoding ???
>> >
>> >Sequence of operations needed by DSP after reset and power on related
>> to bootloading????
Regards,
Suresh Kirthi..........
"If a problem can be solved there is no use worrying about it. If it can't be solved,
worrying will do no good."
Regards,
Suresh Kirthi..........
"If a problem can be solved there is no use worrying about it. If it can't be solved,
worrying will do no good."
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: BOOT LOADER - Jeff Brower - Nov 15 8:37:32 2006
Suresh- > I spoke to TI they have accepted that hex converter (hex6x) of TI seem to have some > limitation that it cannot convert *.out greater than 512KB to hex properly (rather > it overwrites ). be aware of this when burning your application on flash. Thanks for this update. One thing you might try (or maybe you already did) is removing all debug information from the .out file, which would make it smaller -- although not sure if the TI bug has to do with 512k of actual executable code or 512k of overall file size. I think turning off global symbols in CCS is one part of this. For production systems, that may be a good idea anyway to make it harder for a competitor to reverse-engineer your code. -Jeff > suresh kirthi <k...@yahoo.com> wrote: > > Jeff, > Thank you Jeff. > I'll elaborate on my problem: > > There was paging limitation of 512KB (though flash-memory is 4MB & this > is due to address line limitation which are only 19 & rest 3bits are > updated in FPGA page register )flashburn tool v2.8 provided by TI with > CCS v 3.1 which I got it fixed by talking to the flashburn provider SDS. > But I somehow feel even the hex6x tool of TI has similar limitation. And > by the way I'am usin DM642 (720Mhz). > > I tried for the tool over the net to convert coff to hex but with > hard-luck. But recently came to know about objcopy an utility of linux > which does that conversion but still haven't tried it. > > I'am currently speaking to TI also.Incase there is any thing i'll keep > the group posted. > And in the meanwhile if anybody faced similar problem I would be grateful > if you people could share your experience. > > thank you again, > Suresh Kirthi, > Kolkata. > > Jeff Brower <j...@signalogic.com> wrote: > Suresh- > > > Since the discussion was on bootloader & hex6x.exe I would like to > > confirm from the group (jeff) whether hex6x has a limitation that it > > won't convert coff files(*.out files) greater than 600KB(I think it is > > 640KB) properly. > > > > Say for example if the coff file is around 1000KB approximates only the > > > last 400KB(1000KB - 640 KB) would be converted to hex .This probably > the > > first 640KB gets overwritten by the next. Even the map file show the > > same observation. > > I haven't heard that one before, but wouldn't be surprised -- > unfortunately I've found and fought my way through lots of bugs in TI > tools over the years before TI released fixed versions. > > My suggestions on this would be: > > -verify it's not intentional; for example maybe it's > a limitation on the DSK version of tools; i.e. "non > full version" > > -check with super experts on this group, including > Mike Dunn, Bhooshan Iyer, and Andrew Nesterov -- > maybe they know about this bug. Bhoohsan is > hooked up with latest TI tools version and errata > info, so maybe he knows > > -try the latest version of hex6x.exe from CCS v3.1x. > It would be unlikely this bug could live long with > some of the big programs people must be putting > together for 641x platforms > > -Jeff > > > Jeff Brower wrote: > > Adeel Shahze- > > > > I would add to Skuzbary's comments that for the secondary bootloader, > > there are lots > > of app notes and source examples to follow given by TI for other DSPs. > > Most of the > > 54xx and 55xx families have very full-featured internal bootloaders > stored > > in > > internal chip ROM, and tyically TI posts bootloader source code for > those > > devices > > somewhere. The code is in asm, but typically almost commented > > line-by-line. > > > > Also, whatever approach you take, I suggest you stay compatible with > > hex6x.exe, which > > is the standard TI utility for generating bootloadable files / images > for > > C6x > > devices. > > > > -Jeff > > > > s...@tx.rr.com wrote: > >> > >> Greetings, > >> > >> It seems to me that you want to start your system booting from a > device > >> on the EMIF I/F. > >> > >> From C6713 data sheet, SPRS186J > >> > >> EMIF boot (using default ROM timings) > >> > >> Upon the release of internal reset, the 1K-Byte ROM code located in > the > >> beginning of CE1 is copied to address 0 by the EDMA using the default > >> ROM timings, while the CPU is internally “stalled”. The data should be > > >> stored in the endian format that the system is using. The boot process > > >> also lets you choose the width of the ROM. In this case, the EMIF > >> automatically assembles consecutive 8-bit bytes or 16-bit half-words > to > >> form the 32-bit instruction words to be copied. The transfer is > >> automatically done by the EDMA as a single-frame block transfer from > the > >> ROM to address 0. After completion of the block transfer, the CPU is > >> released from the “stalled” state and start running from address 0. > >> > >> Your code generation is capable of generating FLASH code that is > >> compatible with this EMIF Boot using TI's COFF format. > >> > >> If you elect to write your own bootloader, which will be secondary > >> bootloader, and will execute once the ROM bootloader copy it into > >> internal RAM, then you can have a standard bitmap load stored in your > >> FLASH, and you secondary bootloader will copy it to internal RAM, then > > >> give it control of the CPU. > >> > >> Good luck. > >> > >> hi > >> >i hav givenn a task for writing bootloader for c6713 ,from flash rom > at > >> CE1 through EDMA > >> > > >> >Please guide me in > >> >how to write bootloader??? > >> > > >> >What setting are required in writing bootloader?? > >> > > >> >What is algorithm of bootlaoding ??? > >> > > >> >Sequence of operations needed by DSP after reset and power on related > > >> to bootloading???? > > Regards, > > Suresh Kirthi.......... > > "If a problem can be solved there is no use worrying about it. If it > can't be solved, worrying will do no good." > Regards, > Suresh Kirthi..........
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )