bootstrap code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bootstrap code

Dale Cunningham
I'm trying to write a bootstrap routine in C that will reside in flash
and be copied to RAM for execution.  Can anyone give me some helpful
hints on how to do that?

I've searched the docs for any reference to relocatable code (there will
be some subroutines, also in RAM) or preprocessor commands that might be
able to specify that this code will be running at a particular address
(in this case within the RAM) and haven't been able to find anything
that relates to this problem.

Thanks,
Dale Cunningham


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

N. Coesel
At 04:53 17-06-05 -0400, you wrote:
>I'm trying to write a bootstrap routine in C that will reside in flash
>and be copied to RAM for execution.  Can anyone give me some helpful
>hints on how to do that?

In an earlier discussion the method of copying a routine was discussed.

>I've searched the docs for any reference to relocatable code (there will
>be some subroutines, also in RAM) or preprocessor commands that might be
>able to specify that this code will be running at a particular address
>(in this case within the RAM) and haven't been able to find anything
>that relates to this problem.

Why would you copy more than one subroutine in RAM? The only thing you will
want in RAM is the code that actually programs the flash. The amount of
memory doesn't allow for allocating large fixed buffers for this.

I'm planning to implement a method in which the data and the programming
routine are both on the stack to use the memory most efficiently. When
programming is finished, the memory is available again for other buffers.

Nico Coesel



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Tennessee Carmel-Veilleux
In reply to this post by Dale Cunningham

On Jun 17, 2005, at 4:53 AM, Dale Cunningham wrote:

> I'm trying to write a bootstrap routine in C that will reside in flash
> and be copied to RAM for execution.  Can anyone give me some helpful
> hints on how to do that?
>
> I've searched the docs for any reference to relocatable code (there
> will be some subroutines, also in RAM) or preprocessor commands that
> might be able to specify that this code will be running at a
> particular address (in this case within the RAM) and haven't been able
> to find anything that relates to this problem.
>
I have devised a way to do this for assembly routines. The data and
code will be copied to the stack and run from there. The code is in C,
but the routine you want to put in the stack must be in assembly for
the moment. I have also got some misc routines in there, including
buffered SD16 with timestamps, buffered UART in assembly and other
stuff. The important routine is WriteBlock() in asmlib.s. It shows how
to copy a routine to stack and run it from there. In this case, it is
used to write to info memory. I have included the necessary files that
should form a good example.

The configuration of this code is in an MSP430F427 with 32.768k XTAL
and a multiplexer on analog A2. The selection signal is P2.2.

This whole code is the stuff I want to contribute to the example
library of MSPGCC. At the moment, it is not quite "pretty" enough, but
I will soon butcher it to parts to form a complete example. The entire
code is well commented though.

If any of this code is used, please credit Tennessee Carmel-Veilleux
([hidden email])

Best Regards,

Tennessee Carmel-Veilleux

ASMLIB.H (2K) Download Attachment
ASMLIB.S (22K) Download Attachment
fonctions.c (3K) Download Attachment
HARDWARE.H (8K) Download Attachment
MAIN.C (6K) Download Attachment
MAIN.H (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Dale Cunningham
In reply to this post by N. Coesel
N. Coesel wrote:
> At 04:53 17-06-05 -0400, you wrote:
>
>>I'm trying to write a bootstrap routine in C that will reside in flash
>>and be copied to RAM for execution.  Can anyone give me some helpful
>>hints on how to do that?
>
>
> In an earlier discussion the method of copying a routine was discussed.

That should be the easy part.  I wasn't worried about that, but I'll
check the archives just in case I'm missing something.

>>I've searched the docs for any reference to relocatable code (there will
>>be some subroutines, also in RAM) or preprocessor commands that might be
>>able to specify that this code will be running at a particular address
>>(in this case within the RAM) and haven't been able to find anything
>>that relates to this problem.
>
>
> Why would you copy more than one subroutine in RAM? The only thing you will
> want in RAM is the code that actually programs the flash. The amount of
> memory doesn't allow for allocating large fixed buffers for this.

This BSL also needs to decrypt the data to be written to flash and
handle some handshaking with the PC.  The decryption routine might be
erased at some point during the flash programming even if I only erase
the segment about to be written.  That wouldn't be good.  And, part of
the decryption algorhythm makes multiple calls to a subroutine, so that
inlining that code would increase the size - this might not be a
problem.  I'm using an msp430x449 with 2k of RAM, so I think I'll have
plenty of space for code and a communications buffer.

So far, looking at the assembler output, it seems that calls are my only
problem - they use direct addressing.  So, I can just "fix" these few
lines in the assembler or try indirect calls in C or just inline everything.

Dale Cunningham


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

RE: bootstrap code

Frederic Beaulieu
I use function pointer to bypass direct addressing.
Fred

--------------------------------------------
Frederic Beaulieu, M.Sc.
Research and Development
NewTrax Technologies Inc.
http://www.newtraxtech.com/


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Dale
Cunningham
Sent: Friday, June 17, 2005 5:05 PM
To: [hidden email]
Subject: Re: [Mspgcc-users] bootstrap code

N. Coesel wrote:
> At 04:53 17-06-05 -0400, you wrote:
>
>>I'm trying to write a bootstrap routine in C that will reside in flash

>>and be copied to RAM for execution.  Can anyone give me some helpful
>>hints on how to do that?
>
>
> In an earlier discussion the method of copying a routine was
discussed.

That should be the easy part.  I wasn't worried about that, but I'll
check the archives just in case I'm missing something.

>>I've searched the docs for any reference to relocatable code (there
will
>>be some subroutines, also in RAM) or preprocessor commands that might
be
>>able to specify that this code will be running at a particular address

>>(in this case within the RAM) and haven't been able to find anything
>>that relates to this problem.
>
>
> Why would you copy more than one subroutine in RAM? The only thing you
will
> want in RAM is the code that actually programs the flash. The amount
of
> memory doesn't allow for allocating large fixed buffers for this.

This BSL also needs to decrypt the data to be written to flash and
handle some handshaking with the PC.  The decryption routine might be
erased at some point during the flash programming even if I only erase
the segment about to be written.  That wouldn't be good.  And, part of
the decryption algorhythm makes multiple calls to a subroutine, so that
inlining that code would increase the size - this might not be a
problem.  I'm using an msp430x449 with 2k of RAM, so I think I'll have
plenty of space for code and a communications buffer.

So far, looking at the assembler output, it seems that calls are my only

problem - they use direct addressing.  So, I can just "fix" these few
lines in the assembler or try indirect calls in C or just inline
everything.

Dale Cunningham


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.7/20 - Release Date: 6/16/2005
 

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.7/20 - Release Date: 6/16/2005
 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

N. Coesel
In reply to this post by Dale Cunningham
At 17:05 17-06-05 -0400, you wrote:

>N. Coesel wrote:
>> At 04:53 17-06-05 -0400, you wrote:
>>
>>>I'm trying to write a bootstrap routine in C that will reside in flash
>>>and be copied to RAM for execution.  Can anyone give me some helpful
>>>hints on how to do that?
>>
>>
>> In an earlier discussion the method of copying a routine was discussed.
>
>That should be the easy part.  I wasn't worried about that, but I'll
>check the archives just in case I'm missing something.
>
>>>I've searched the docs for any reference to relocatable code (there will
>>>be some subroutines, also in RAM) or preprocessor commands that might be
>>>able to specify that this code will be running at a particular address
>>>(in this case within the RAM) and haven't been able to find anything
>>>that relates to this problem.
>>
>>
>> Why would you copy more than one subroutine in RAM? The only thing you will
>> want in RAM is the code that actually programs the flash. The amount of
>> memory doesn't allow for allocating large fixed buffers for this.
>
>This BSL also needs to decrypt the data to be written to flash and
>handle some handshaking with the PC.  The decryption routine might be
>erased at some point during the flash programming even if I only erase
>the segment about to be written.  That wouldn't be good.  And, part of
>the decryption algorhythm makes multiple calls to a subroutine, so that
>inlining that code would increase the size - this might not be a
>problem.  I'm using an msp430x449 with 2k of RAM, so I think I'll have
>plenty of space for code and a communications buffer.

I'm working along similar lines. I think it is a very bad idea to allow to
erase the decryption routine. If power fails during programming, or the
file to be programmed is invalid, the device is ready for a repair because
the end user is unable to load new firmware.

It is also a good idea to add extra guards just before the flash erase
process is started which explicitly protect the sector(s) containing the
download & decryption routines. If the software starts to have a life on
its own (random execution), this will help to prevent unwanted erases of
critical information.

In my setup, the bootloader will be fixed (like the standard BSL). It will
program the rest of the flash memory with an overlay which is the actual
firmware. My bootloader will never be replaced and should also be
intelligent enough to talk to a host in order to obtain a new file for
programming. This will -hopefully- result in a device which can always be
reprogrammed by the end user unless it is really broken.

Nico Coesel



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Chris Liechti
In reply to this post by Dale Cunningham
Dale Cunningham wrote:
...
> So far, looking at the assembler output, it seems that calls are my only
> problem - they use direct addressing.  So, I can just "fix" these few
> lines in the assembler or try indirect calls in C or just inline
> everything.

you could make your own linker script that links the program into the
RAM address range. then just insert that data as a const char * array in
your application a small copy and execute assembler function
"StartBSL(void * src)" can then copy and execute that code from RAM.

see in our CVS, the jtag code uses "funclets" and the sources have such
a linker script like the mentioned above.

http://cvs.sourceforge.net/viewcvs.py/mspgcc/jtag/funclets/

i guess i have to implement somthing like that in the "examples" section ;-)

chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Chris Liechti
In reply to this post by N. Coesel
N. Coesel wrote:
> Why would you copy more than one subroutine in RAM? The only thing you will
> want in RAM is the code that actually programs the flash. The amount of
> memory doesn't allow for allocating large fixed buffers for this.

the MSP430 can program itself when executing from flash. the flash
controler handles that nicely.

of course, it's a problem if you want to program the entire flash, but
then updating only parts of a program is tricky anyway.

right now, i'm implementing my own BSL (compatible with TI's BSL) that
resides in the top 2kB of flash, which i won't delete in upgrades. (it
currently is slightly larger than 1kB. maybe i'll reserve only 1.5kB)

chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Chris Liechti
In reply to this post by N. Coesel
N. Coesel wrote:
> It is also a good idea to add extra guards just before the flash erase
> process is started which explicitly protect the sector(s) containing the
> download & decryption routines. If the software starts to have a life on
> its own (random execution), this will help to prevent unwanted erases of
> critical information.

unfortunately, does the msp430 not support locking. (at least not the
1xx series. the 2xx have some locking, but only for the information
memory and it seems, only 64 bytes..)

i think the best protection is if you have a large enough capacitor on
the supply (best before the voltage regualtor).
before every activation of the flash controller, check the voltage and
decide if there is enough energy to complete the operation.

some other measures are:
- keep the flash cotroller activated as short as possible. disable it
   between writes.
- use MCLK of 1..2MHZ during the update. that way you're always within
   the specs if VCC drops. (reduces the chances of random code execution)
- use a reset device, a msp430 with brownout or svs.
- the 2xx devices will have beter protection against random code
   execution

> In my setup, the bootloader will be fixed (like the standard BSL). It will
> program the rest of the flash memory with an overlay which is the actual
> firmware. My bootloader will never be replaced and should also be
> intelligent enough to talk to a host in order to obtain a new file for
> programming. This will -hopefully- result in a device which can always be
> reprogrammed by the end user unless it is really broken.

as i mentioned in the other mail, i'm working on a simiar loader.
i've made two special linker scripts:
- one for the updater that only uses the top 2kB of the flash
- the other for the application, which cuts away the top 2kB flash and
   moves the interrupt vectors 2kB lower

then i can mass erase, program the boot laoder and then the application
trough JTAG.

the updater redirects all interrupt vectors to the applications
interrupt table.

i identified 3 possible use cases:
- normal upgrade. the application can initiate the upgrade
- no application. the boot loader "sees" the invalid application reset
   vector and falls into "upgrade mode"
- a completly wrong application has been progarmmed. the boot loader
   needs to check some key combination or something after a reset to
   force "upgrade mode" before launching a corrupt application.

unfortunately there is one problem left...
when the updater is erasing or writing a flash segment and the power
fails. then in rare cases it could lead to random code execution and
with a bit of bad luck destroy the boot loader itself.

chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Dale Cunningham
In reply to this post by Chris Liechti
I thought I had read in the documentation that the code to write to
flash either should be or must be run out of RAM.  Or, maybe I decided
to use the mass erase function to save time and power.  I've forgotten.
  Your scheme seems good if it works.

I know the TI supplied BSL copies itself to RAM before execution.  Why?

Dale

Chris Liechti wrote:

> N. Coesel wrote:
>
>> Why would you copy more than one subroutine in RAM? The only thing you
>> will
>> want in RAM is the code that actually programs the flash. The amount of
>> memory doesn't allow for allocating large fixed buffers for this.
>
>
> the MSP430 can program itself when executing from flash. the flash
> controler handles that nicely.
>
> of course, it's a problem if you want to program the entire flash, but
> then updating only parts of a program is tricky anyway.
>
> right now, i'm implementing my own BSL (compatible with TI's BSL) that
> resides in the top 2kB of flash, which i won't delete in upgrades. (it
> currently is slightly larger than 1kB. maybe i'll reserve only 1.5kB)
>
> chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Steve Underwood
Dale Cunningham wrote:

> I thought I had read in the documentation that the code to write to
> flash either should be or must be run out of RAM.  Or, maybe I decided
> to use the mass erase function to save time and power.  I've
> forgotten.  Your scheme seems good if it works.
>
> I know the TI supplied BSL copies itself to RAM before execution.  Why?
>
> Dale

You can erase and write to flash from code running in flash. The flash
timing control circuitry deals with this, and inserts the appropriate
delays for both erasing and writing. This is described in the
documentation, but you have to do some reading to figure that out. A
simple clear statement that it works would have been nice.

The following simple routines, running from flash, will deal with erase
and write operations:

/* ptr must point to an address within the flash page you wish to clear */
void flash_clr(int *ptr)
{
        _DINT();
        FCTL3 = FWKEY;                                  /* Lock = 0 */
        FCTL1 = FWKEY | ERASE;
        *((int *) ptr) = 0;                             /* Erase flash
segment */
        FCTL1 = FWKEY;                                  /* Erase, write
= 0 */
        FCTL3 = FWKEY | LOCK;
        _EINT();
}

void flash_write_int16(int16_t *ptr, int16_t value)
{
        _DINT();
        FCTL3 = FWKEY;                                  /* Lock = 0 */
        FCTL1 = FWKEY | WRT;
        *((int16_t *) ptr) = value;             /* Program the flash */
        FCTL1 = FWKEY;                                  /* Erase, write
= 0 */
        FCTL3 = FWKEY | LOCK;
        _EINT();
}

Steve



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Dale Cunningham
In reply to this post by Chris Liechti
Chris Liechti wrote:
> as i mentioned in the other mail, i'm working on a simiar loader.
> i've made two special linker scripts:
> - one for the updater that only uses the top 2kB of the flash
> - the other for the application, which cuts away the top 2kB flash and
>   moves the interrupt vectors 2kB lower

This redirection of the interrupt vectors seems like a bad idea from a
security standpoint.  It would be really easy to guess what the TI BSL
password is - at least for anyone who's seen your post.

Circumventing all the TI security problems is the major reason I'm
writing this BSL.  Even if the supplied BSL had the ability to handle
decryption, once you've sent that password over the serial line you got
trouble.  One could easily intercept that by putting a device inline
that buffers and analyzes the communications.  Once they see the
password, they take over, send the password and read out all your code.
  Another hole: if you erase segment 0 and you're configured in such a
way that the TI BSL can be invoked...  It would be tricky to know
exactly when you've done that, but I think it is possible to make a good
guess by counting command packets - it's bound to be close to the first
or last packet.  I'm thinking I can avoid this by configuring the NMI
pin so the BSL cannot be invoked, at least during the rewrite of segment 0.

Oh, BTW it's seems like I'm wrong about the TI BSL loading itself into
RAM - couldn't find it again in the docs.

Dale


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Dale Cunningham
In reply to this post by Steve Underwood
Thank you.

Dale

Steve Underwood wrote:
> You can erase and write to flash from code running in flash. The flash
> timing control circuitry deals with this, and inserts the appropriate
> delays for both erasing and writing.
<clip>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Chris Liechti
In reply to this post by Dale Cunningham
Dale Cunningham wrote:

> Chris Liechti wrote:
>
>> as i mentioned in the other mail, i'm working on a simiar loader.
>> i've made two special linker scripts:
>> - one for the updater that only uses the top 2kB of the flash
>> - the other for the application, which cuts away the top 2kB flash and
>>   moves the interrupt vectors 2kB lower
>
>
> This redirection of the interrupt vectors seems like a bad idea from a
> security standpoint.  It would be really easy to guess what the TI BSL
> password is - at least for anyone who's seen your post.

yes. the password is weaker. but i can use numbers from the entire 2kB
flash i reserve for the boot loader. interrupt 16 isn't used, i can
write there any number i want. and my redirection table does not need to
be sorted, it can have any order.

as i'm using my own loader, i'm using also different IOs. there is no
way to activate the ROM BSL without opening the device and connecting
wires to the other pins.

> Circumventing all the TI security problems is the major reason I'm
> writing this BSL.  Even if the supplied BSL had the ability to handle
> decryption, once you've sent that password over the serial line you got
> trouble.  One could easily intercept that by putting a device inline
> that buffers and analyzes the communications.  Once they see the
> password, they take over, send the password and read out all your code.

i don't need to transmit the password. a mass erase command only erases
the application and not the bootloader itself. but i don't plan to
encrypt the data anyway.

(if i used a password, it would be the one of the application, not the
one of the boot loader)

if you realy want to encrypt the data, then some asymmetric algorithm
with private and public key would be good. each device could have it's
own private key, so that you can sell the updates per device.

>  Another hole: if you erase segment 0 and you're configured in such a
> way that the TI BSL can be invoked...  It would be tricky to know
> exactly when you've done that, but I think it is possible to make a good
> guess by counting command packets - it's bound to be close to the first
> or last packet.

i don't plan to erase segment 0, so that no concern for me.

 > I'm thinking I can avoid this by configuring the NMI
> pin so the BSL cannot be invoked, at least during the rewrite of segment 0.

the NMI function is only active once. a second pulse is a reset, unless
you reconfigure the pin to NMI in the NMI interrupt service routine. i
guess there is no way to ensure that this is done fast enough if someone
  unsolders your chip and connects it to his own circuit.

> Oh, BTW it's seems like I'm wrong about the TI BSL loading itself into
> RAM - couldn't find it again in the docs.

it isn't copied to RAM . it runs directly from the built in ROM.

but there are "replacement BSLs" that allow higher baudrates and fix
some bugs of BSL version 1.1. these are often used with F14x devices.
they are loaded into RAM and executed from there.

chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Chris Liechti
In reply to this post by Dale Cunningham
Dale Cunningham wrote:
> I thought I had read in the documentation that the code to write to
> flash either should be or must be run out of RAM.

i mean to remember that the block write modes would need to be used from
a program in RAM. but i dont use that anyway. i write word after word
and that works very well from flash.

 > Or, maybe I decided
> to use the mass erase function to save time and power.  I've forgotten.
> Your scheme seems good if it works.

it works. i have a prototype running :-)

chris


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

N. Coesel
In reply to this post by Chris Liechti
At 00:24 18-06-05 +0200, you wrote:
>N. Coesel wrote:
>> Why would you copy more than one subroutine in RAM? The only thing you will
>> want in RAM is the code that actually programs the flash. The amount of
>> memory doesn't allow for allocating large fixed buffers for this.
>
>the MSP430 can program itself when executing from flash. the flash
>controler handles that nicely.

I've read about it, unfortunately that doesn't work for page programming
which is much faster than programming byte after byte.

Nico Coesel



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

N. Coesel
In reply to this post by Dale Cunningham
At 00:50 18-06-05 -0400, you wrote:

>Chris Liechti wrote:
>> as i mentioned in the other mail, i'm working on a simiar loader.
>> i've made two special linker scripts:
>> - one for the updater that only uses the top 2kB of the flash
>> - the other for the application, which cuts away the top 2kB flash and
>>   moves the interrupt vectors 2kB lower
>
>This redirection of the interrupt vectors seems like a bad idea from a
>security standpoint.  It would be really easy to guess what the TI BSL
>password is - at least for anyone who's seen your post.
>
>Circumventing all the TI security problems is the major reason I'm
>writing this BSL.  Even if the supplied BSL had the ability to handle
>decryption, once you've sent that password over the serial line you got
>trouble.  One could easily intercept that by putting a device inline
>that buffers and analyzes the communications.  Once they see the

If the encryption method is a proper one, you would not be able to decode
the password. It would be nice if the BSL would be able to store an
encryption key in the device.

>password, they take over, send the password and read out all your code.
>  Another hole: if you erase segment 0 and you're configured in such a
>way that the TI BSL can be invoked...  It would be tricky to know
>exactly when you've done that, but I think it is possible to make a good
>guess by counting command packets - it's bound to be close to the first
>or last packet.  I'm thinking I can avoid this by configuring the NMI
>pin so the BSL cannot be invoked, at least during the rewrite of segment 0.

AFAIK it is always possible to invoke the BSL at device startup. But you do
have a good point... If you want so secure your firmware, you should not
reprogram the interrupt vectors.

Nico Coesel



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Steve Underwood
In reply to this post by N. Coesel
N. Coesel wrote:

>At 00:24 18-06-05 +0200, you wrote:
>  
>
>>N. Coesel wrote:
>>    
>>
>>>Why would you copy more than one subroutine in RAM? The only thing you will
>>>want in RAM is the code that actually programs the flash. The amount of
>>>memory doesn't allow for allocating large fixed buffers for this.
>>>      
>>>
>>the MSP430 can program itself when executing from flash. the flash
>>controler handles that nicely.
>>    
>>
>
>I've read about it, unfortunately that doesn't work for page programming
>which is much faster than programming byte after byte.
>  
>
I don't know what you mean.

You can't program byte by byte. It has to be word by word.

A write takes about 75us per word. 60K bytes (30K words) would only take
2.25s + the software overhead. It's not exactly slow. Overheads, rather
than word by word writing, are the usual limiting factor.

Regards,
Steve



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

N. Coesel
In reply to this post by Chris Liechti
Chris Liechti wrote:
>
>i don't need to transmit the password. a mass erase command only erases
>the application and not the bootloader itself. but i don't plan to
>encrypt the data anyway.

I don't quite follow this. Do you mean there is a way to let the mass erase
operation skip a section of internal flash?

>(if i used a password, it would be the one of the application, not the
>one of the boot loader)
>
>if you realy want to encrypt the data, then some asymmetric algorithm
>with private and public key would be good. each device could have it's
>own private key, so that you can sell the updates per device.

Private/public keys algorithms are not usefull to protect firmware. If the
key is public, anyone could write some firmware for your device and upload
it to read the rest of the firmware. Private/public keys are intended to
send encrypted information to someone. You'll need an encryption method
where both sides need the exact key.
AES/Rijndael is a very good one and has not been compromised -yet-.

>but there are "replacement BSLs" that allow higher baudrates and fix
>some bugs of BSL version 1.1. these are often used with F14x devices.
>they are loaded into RAM and executed from there.

These still need a mass erase before they can be loaded into RAM.

BTW, for absolute protection of the firmware, the JTAG fuse needs to be
blown as well.

Nico Coesel



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: bootstrap code

Dale Cunningham
In reply to this post by Chris Liechti

Chris Liechti wrote:
> as i'm using my own loader, i'm using also different IOs. there is no
> way to activate the ROM BSL without opening the device and connecting
> wires to the other pins.

We are putting the signals required for the TI BSL on a header that you
have to open the device to get to but which make it easy for the factory
to download code in the case where the flash is just too corrupted to
run my BSL code.  And we are also using different IOs for the user port.

> if you realy want to encrypt the data, then some asymmetric algorithm
> with private and public key would be good. each device could have it's
> own private key, so that you can sell the updates per device.

That's the plan, plus adding keys for major and minor software version
so something like a bug fix can be distributed for free, with a single
update file, to anyone with that software version and the cost of an
upgrade can depend on which version you currently have.

> but there are "replacement BSLs" that allow higher baudrates and fix
> some bugs of BSL version 1.1. these are often used with F14x devices.
> they are loaded into RAM and executed from there.

That's probably where I got the idea that my BSL would have to operate
out of RAM.  Not needing to do that is hugely helpful.

Dale


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
12