Lpc2000

Hello,

If would like to know if people here would be interested in a free LPC
boot loader with the following properties:

*  autobaud on receiving a single space character;
*  Intel-hex download and run from on-chip RAM;
*  Intel-hex download to non-boot sector flash;
*  CRP feature to extent supported by hardware; and
*  kernel and compatible mode flash support.

Kernel and compatible mode flash libraries will allow existing
programs that use IAP calls to work as-is.  The CPU clock paramter
will be now be reduntant if you chose this option. 

It will allow boot loader intercept method to be customised.  You can
either use P0.14 or UART method to invoke the boot loader.

It will also allow external bus interface (on parts with external bus)
to be customised at the boot loader block itself.

The aim here is to release P0.15 (and BOOT1:0) pins for general
purpose IO.

CRP equivalent will be implemented as "one time fuse" in the boot
loader itself.  Once activated, boot loader will not do anything other
than to allow the entire device to be "restored".

Restoration will be done by first erasing all sectors except boot
sector and then verifying that they are fully erased before finally
self reinitialising the boot sector itself.

The aim is to reduce CRP attack surface area of the boot loader.

The boot loader image (in hex format) can be a property of the LPC2000
forum and be freely available to any member of the forum.

I can provide Windows I86 binaries of tools to backup the supplied
boot loader on your part, to install the free boot loader, and to
revert to the boot loader that you have backed up should this be
necessary.  These tools will also be owned by the LPC2000 forum.

Boot loader will not be open soruce for legal reasons.  (Philips can
remove this restriction.)

I can also provide components of the source code relating to any tools
I provide so that co-developers on other platforms can build binaries
and distribute these freely.

My reason for doing this is to demonstrate to this forum by way of
example how one could better support the LPC Family.

If there is interest, please follow up in this thread.

Regards,

Jaya

Umm.....Some questions, don't mind:
- How do I know there is no Trojan Horse inside??
- How do I know your code does not over-cooked my flash??
  or make it raw/medium when I actually ordered well done??
- How do I know your code could handle Exception Interrupt 
  properly?? without crashing??
- How do I know your code does not have CSI bugs??
- How do I know if you could understand the watchdog hardware
  in detail and handle it properly upon a watchdog reset event??
- How do I know if I will not have CRP problem, after installing
  your that boot loader?? And What's that "CRP feature to extent
  supported by hardware"??
- How do I know if you are able to get Philips to ship with your
  bootloader?? Or I need to re-load everychip? Or you could 
  provide free bootloader upgrade every chip programming 
  services??
- How do I know if you are Philips Certified/Appointed consultant??
Thanks!!


--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> Hello,
> 
> If would like to know if people here would be interested in a free 
LPC
> boot loader with the following properties:
> 
> *  autobaud on receiving a single space character;
> *  Intel-hex download and run from on-chip RAM;
> *  Intel-hex download to non-boot sector flash;
> *  CRP feature to extent supported by hardware; and
> *  kernel and compatible mode flash support.
> 
> Kernel and compatible mode flash libraries will allow existing
> programs that use IAP calls to work as-is.  The CPU clock paramter
> will be now be reduntant if you chose this option. 
> 
> It will allow boot loader intercept method to be customised.  You 
can
> either use P0.14 or UART method to invoke the boot loader.
> 
> It will also allow external bus interface (on parts with external 
bus)
> to be customised at the boot loader block itself.
> 
> The aim here is to release P0.15 (and BOOT1:0) pins for general
> purpose IO.
> 
> CRP equivalent will be implemented as "one time fuse" in the boot
> loader itself.  Once activated, boot loader will not do anything 
other
> than to allow the entire device to be "restored".
> 
> Restoration will be done by first erasing all sectors except boot
> sector and then verifying that they are fully erased before finally
> self reinitialising the boot sector itself.
> 
> The aim is to reduce CRP attack surface area of the boot loader.
> 
> The boot loader image (in hex format) can be a property of the 
LPC2000
> forum and be freely available to any member of the forum.
> 
> I can provide Windows I86 binaries of tools to backup the supplied
> boot loader on your part, to install the free boot loader, and to
> revert to the boot loader that you have backed up should this be
> necessary.  These tools will also be owned by the LPC2000 forum.
> 
> Boot loader will not be open soruce for legal reasons.  (Philips 
can
> remove this restriction.)
> 
> I can also provide components of the source code relating to any 
tools
> I provide so that co-developers on other platforms can build 
binaries

> and distribute these freely.
> 
> My reason for doing this is to demonstrate to this forum by way of
> example how one could better support the LPC Family.
> 
> If there is interest, please follow up in this thread.
> 
> Regards,
> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> Umm.....Some questions, don't mind:
> - How do I know there is no Trojan Horse inside??

If you get Philips to agree to disclosure of the full source, you
inspect and validate the source code yourself.

You can also use reverse engieering methods I explain here:

  http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

> - How do I know your code does not over-cooked my flash??
>   or make it raw/medium when I actually ordered well done??

I use the exact the same timing parameters that is boot loader uses
and in your part.  The only thing I do differently is rather than
blindly wait for a given number of cycles (and hope the flash is
ready) I poll the flash status registers to determine when it is ready.

> - How do I know your code could handle Exception Interrupt 
>   properly?? without crashing??

Check out exception handling in SILL at

  http://www.cse.unsw.edu.au/~jayas/esdk/sill.html  

> - How do I know your code does not have CSI bugs??

It does not have a CSI so it cannot have CSI bugs.

> - How do I know if you could understand the watchdog hardware
>   in detail and handle it properly upon a watchdog reset event??

See discussions in other threads here.

> - How do I know if I will not have CRP problem, after installing
>   your that boot loader?? And What's that "CRP feature to extent
>   supported by hardware"??

See the specifications of how the chip is restored.

> - How do I know if you are able to get Philips to ship with your
>   bootloader?? Or I need to re-load everychip? Or you could 
>   provide free bootloader upgrade every chip programming 
>   services??

You do not get this boot loader from Philips.  You fetch the image and
tools from the forum download area.

You do not *have* to use this boot loader if you do not need it.

Note:

1/  Philips *cannot* forbid you from runing your own code in the boot
sector.  (Different story if boot sector is in ROM).

2/  If you are concerned about warranty issues, make a backup of hte
original boot loader in your part, and just restore it before you
raise any warranty issues with Philips.

> - How do I know if you are Philips Certified/Appointed consultant??

If you want Philips Certified/Appointed cosultant, you are better of
sticking to suppied boot loader.

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> Umm.....Some questions, don't mind:
> - How do I know there is no Trojan Horse inside??
> - How do I know your code does not over-cooked my flash??
>   or make it raw/medium when I actually ordered well done??
> - How do I know your code could handle Exception Interrupt 
>   properly?? without crashing??
> - How do I know your code does not have CSI bugs??
> - How do I know if you could understand the watchdog hardware
>   in detail and handle it properly upon a watchdog reset event??
> - How do I know if I will not have CRP problem, after installing
>   your that boot loader?? And What's that "CRP feature to extent
>   supported by hardware"??
> - How do I know if you are able to get Philips to ship with your
>   bootloader?? Or I need to re-load everychip? Or you could 
>   provide free bootloader upgrade every chip programming 
>   services??
> - How do I know if you are Philips Certified/Appointed consultant??
> Thanks!!
> 

To add to the list:

- why should I break the most basic rule of design and rely on 
something that in turn relies on undocumented and unsupported 
features from a manufacturer?

- what do I do when I'm in production and Philips supply a batch of 
parts that have some change in them that renders your boot-loader or 
some feature of it ineffective? 

I assume that one of the reasons for Philips implementing the boot-
loader the way it is is that it gives them the flexibility to change 
the hardware without changing the documented interface to it.

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> - why should I break the most basic rule of design and rely on 
> something that in turn relies on undocumented and unsupported 
> features from a manufacturer?

Stick to the boot supplied boot loader if you only wish to rely on
what Philips publishes.

As for support, I do not want engage in politics.

> - what do I do when I'm in production and Philips supply a batch of 
> parts that have some change in them that renders your boot-loader or 
> some feature of it ineffective?

Stick to the original boot loaeder then.  My tools have never replaced
any code without first checking what was there in the first place.

> I assume that one of the reasons for Philips implementing the boot-
> loader the way it is is that it gives them the flexibility to change 
> the hardware without changing the documented interface to it.

There you go making assumptions.  I do not want to go into this again.

I asked for expression of interest.  If you are not interested perhaps
you are better off staying out of this thread.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
> I asked for expression of interest.  If you are not interested 
perhaps
> you are better off staying out of this thread.
> 

You're right, and I will.

My reason for the post was to point out to others the problems 
associated with using undocumented and unsupported features. My 
recommendation would be for anyone producing commercial products not 
to do this, for the reasons I gave (amongst others).

Brendan

jayasooriah ha scritto:
I am interested only if it will be in source code form.
> Hello,
>
> If would like to know if people here would be interested in a free LPC
> boot loader with the following properties:
>
> *  autobaud on receiving a single space character;
> *  Intel-hex download and run from on-chip RAM;
> *  Intel-hex download to non-boot sector flash;
> *  CRP feature to extent supported by hardware; and
> *  kernel and compatible mode flash support.
>
> Kernel and compatible mode flash libraries will allow existing
> programs that use IAP calls to work as-is.  The CPU clock paramter
> will be now be reduntant if you chose this option. 
>
> It will allow boot loader intercept method to be customised.  You can
> either use P0.14 or UART method to invoke the boot loader.
>
> It will also allow external bus interface (on parts with external bus)
> to be customised at the boot loader block itself.
>
> The aim here is to release P0.15 (and BOOT1:0) pins for general
> purpose IO.
>
> CRP equivalent will be implemented as "one time fuse" in the boot
> loader itself.  Once activated, boot loader will not do anything other
> than to allow the entire device to be "restored".
>
> Restoration will be done by first erasing all sectors except boot
> sector and then verifying that they are fully erased before finally
> self reinitialising the boot sector itself.
>
> The aim is to reduce CRP attack surface area of the boot loader.
>
> The boot loader image (in hex format) can be a property of the LPC2000
> forum and be freely available to any member of the forum.
>
> I can provide Windows I86 binaries of tools to backup the supplied
> boot loader on your part, to install the free boot loader, and to
> revert to the boot loader that you have backed up should this be
> necessary.  These tools will also be owned by the LPC2000 forum.
>
> Boot loader will not be open soruce for legal reasons.  (Philips can
> remove this restriction.)
>
> I can also provide components of the source code relating to any tools
> I provide so that co-developers on other platforms can build binaries
> and distribute these freely.
>
> My reason for doing this is to demonstrate to this forum by way of
> example how one could better support the LPC Family.
>
> If there is interest, please follow up in this thread.
>
> Regards,
>
> Jaya
>
>
>
>
>
>  
> Yahoo! Groups Links
>
>
>
>  
>
>
>
>
>
>   


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.1/326 - Release Date: 27/04/2006


[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, Micron Engineering <micronpn@...> wrote:
>
> jayasooriah ha scritto:
> I am interested only if it will be in source code form.

I like to but open source approach could potentially infringe on
Philips's rights to keeping chip initialisation methods a secret.

Suggestions anyone?

Jaya

> From: "jayasooriah" <jayasooriah@...>
> I like to but open source approach could potentially infringe on
> Philips's rights to keeping chip initialisation methods a secret.
> Suggestions anyone?

Ask Philips ? I think they are reading the mailinglist, perhaps they can 
clarify it...

Regards,

       Martin

Hi Martin,

I am quite sure Philips monitors this forum.  I am prepared to let
Philips validate my source code before it is put in public domain.

I believe Philips would respond if there is sufficient interest for
such a boot loader.

Jaya

--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@...> wrote:
>
> > From: "jayasooriah" <jayasooriah@...>
> > I like to but open source approach could potentially infringe on
> > Philips's rights to keeping chip initialisation methods a secret.
> > Suggestions anyone?
> 
> Ask Philips ? I think they are reading the mailinglist, perhaps they
can 

> clarify it...
> 
> Regards,
> 
>        Martin