Yahoo Groups archive

Lpc2000

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

Message

Re: LPC Internals Question

2006-02-02 by jayasooriah

--- In lpc2000@yahoogroups.com, "derbaier" <dershu@...> wrote:
> Since Philip's seems to have FLASH capabilities on the
> same die as the logic, it seems logical that they may
> make use of it for sorting parts with some minor defects.

Philips does not make use of flash directly, but depend on boot loader
code to set up the part parameters.  This IMO is strongest reason why
they have chosen to support boot loader at the binary level, which I
must say is at considerable expense to themselves.

It is not the "proprietary flash architecture" claim that they said to
me as the reason for not disclosing flash programming algorithm.  It
does not take much to work out that they are fetching 128 bits at a
time and this make the flash look 16 times faster than it really is.

I must add, they are doing this at the expense of generalised and
independent instruction and data caching that is available in most, if
not all, other ARM cores, which arguably works better than pre-fetch
cache for both I and D using 128-bit wide flash and MAM in LPC
implementation.

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@...> wrote:
> I'm not sure of the legality of reverse engineering a
> device's firmware and operation, but when I have purchased
> LPC devices or boards with them on, I have not been subject
> to a license agreement relating to the silicon, so I think
> reverse engineering them is fine.  If your discovery is not
> covered by any license agreement you have signed or undertaken,
> then I believe the information can be made public.

As it happens, I informed Philips I was reverse engineering the code,
and my reasons.  They did not object.  They chose to just advise me
that they cannot guarantee the part if I did not use their boot loader
to program on-chip flash.  (What can you expect them to say, one might
ask.)

In the process of discovering the flash algorithms, I found out things
I think they did not expect me to find out: CSI vulnerabilities; CRP
problems; limitations in their implementation of the flash programming
algorithm; problems with their implementation of flash programming;
and this how one can possibly enable hidden features.

I just got my LPC2292 today, and who knows what else I find out.  I do
not have enough prototypes to burn, so I am restricting myself to just
replacing the boot loader.  If I had more parts to kill (after this
project is over), I will surely play with it more more as an academic
exercise.

Incidentally, my reason for raising this in this forum is not to
undermine Philips's business in any way, or to claim they got the
wrong people to code their boot loader.

The documentation of what I found and how I found out (with absolutely
zero support from Philips) IMHO makes a good case study tutorial on
reverse engineering for teaching purposes.

Jaya

Attachments

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.