Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

re: self-destruct code in Philips boot sector

re: self-destruct code in Philips boot sector

2005-12-12 by jayasooriah

Hello,

An application code being debugged on LPC device that crashes can
execute code in boot sector and cause the device to self-destruct.

This is because the code provided by Philips in boot sector is not
protected from inadvertent execution.

Furthermore the algorithms for programming LPC flash do not require
any feed sequences (eg 0xaa followed by 0x55) as is the industry
practice.  

For these reasons, I want to replace Philips boot loader with my own.
The aim is to not have any flash programming code at all in the boot
sector, or for that matter, in any flash sector.

My bootloader allows you to load and run code by simply copying and
pasting Intel-hex load files onto Minicom or HyperTerm window to the
serial port.  This is another reason why I want to replace the loader
provided by Philips.

Has anyone replaced Philips boot loader code for any LPC device?

Kind regards,

Jaya

Re: self-destruct code in Philips boot sector

2005-12-12 by Rick Collins

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> Hello,
> 
> An application code being debugged on LPC device that crashes can
> execute code in boot sector and cause the device to self-destruct.
> 
> This is because the code provided by Philips in boot sector is not
> protected from inadvertent execution.

I suppose they could generate an interrupt on execution of any part of
the bootloader other than the first few bytes which would contain code
to turn off the interrupt.  But what if you had all interrupts
disabled when you entered the erroneous section?  

 
> Furthermore the algorithms for programming LPC flash do not require
> any feed sequences (eg 0xaa followed by 0x55) as is the industry
> practice.  

I never bother with this sort of code because it provides very little
protection.  Errant code can always jump to the area after the code
that checks the "feed" sequences.  


> For these reasons, I want to replace Philips boot loader with my own.
> The aim is to not have any flash programming code at all in the boot
> sector, or for that matter, in any flash sector.
> 
> My bootloader allows you to load and run code by simply copying and
> pasting Intel-hex load files onto Minicom or HyperTerm window to the
> serial port.  This is another reason why I want to replace the loader
> provided by Philips.
> 
> Has anyone replaced Philips boot loader code for any LPC device?

So your new code would provide a RAM based bootload which can load a
program to program the flash?  That can be more secure, but make sure
you wipe the programming code after you use it so that you can't
accidentally execute it in RAM.  

Just my 2 cents worth.

Re: self-destruct code in Philips boot sector

2005-12-13 by jayasooriah

--- In lpc2000@yahoogroups.com, "Rick Collins" <gnuarm@a...> wrote:

> > Furthermore the algorithms for programming LPC flash do not require
> > any feed sequences (eg 0xaa followed by 0x55) as is the industry
> > practice.  
> 
> I never bother with this sort of code because it provides very little
> protection.  Errant code can always jump to the area after the code
> that checks the "feed" sequences.

Yes, but still this primitive method is a infinitely superior to the
technique Philips uses in its LPC devices.

> So your new code would provide a RAM based bootload which can load a
> program to program the flash?

Yes, this is for use in a laboratory environment where students have
no reason to load code that modifies flash.  The flash just contains
static library and OS kernel which never needs changing except for
infrequent updates.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.