Reply by jayasooriah February 2, 20062006-02-02
John,

If you are kind enough to point out what I said is incorrect, I am
happy to oblige you with evidence provided you can get Philips to
assure us here that they do not object in anyway to disclosure of my
findings in this forum.

As to the boot process flowchart, you seem to have missed an earlier
discussion where I pointed out with reference to boot loader code that
 the flowchart is incorrect or at best oversimplified.

The first three instructions executed by the boot loader serve to
"hastiliy" block JTAG debugging, and then later on, JTAG debugging is
renabled only if CRP is not in effect.  So the device wakes up with
JTAG enabled, and from memory, Philips admitted to this in this forum.

Back to you.

Jaya

--- In lpc2000@lpc2..., "John Heenan" <l10@...> wrote:
>
> Lots of innuendo, no detail, hysteria and bizarre statements. The 
> latest is the 'academic' line, not the sort of standards we expect 
> from someone aligning themselves on this front.
> 
> This guy has a bee in his bonnet about CRP (Code Read protection). 
> What is the agenda?
> 
> According to the boot process flowchart 'Debug' is not enabled after 
> reset until confirmation it can be enabled. So guess what, you cannot 
> fiddle with the JTAG lines on reset to grab control before the boot 
> loader. The boot loader is needed to enable JTAG and it won't enable 
> JTAG if the bootloader cannot run.
> 
> John Heenan
> 
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@> wrote:
> >
> > I do not expect Philips to comment to either ... if they just listen
> > and fix issues raised in their future releases, that is more than 
> what
> > one can expect under the circumstances.
> > 
> > As an academic, my personal intersts in reverse engineering is that
> > unlike computer forensics, I can make up case study tutorials out of
> > work I do for my clients.
> > 
> > --- In lpc2000@lpc2..., "brendanmurphy37"
<brendan.murphy@>
> > wrote:
> > 
> > > I'd be vey surprised if Philips even comment on this: why would 
> or 
> > > should they comment on an undocumented feature that may or may 
> not 
> > > actually exist?
> >
>
	

An Engineer's Guide to the LPC2100 Series

Reply by John Heenan February 2, 20062006-02-02
Lots of innuendo, no detail, hysteria and bizarre statements. The 
latest is the 'academic' line, not the sort of standards we expect 
from someone aligning themselves on this front.

This guy has a bee in his bonnet about CRP (Code Read protection). 
What is the agenda?

According to the boot process flowchart 'Debug' is not enabled after 
reset until confirmation it can be enabled. So guess what, you cannot 
fiddle with the JTAG lines on reset to grab control before the boot 
loader. The boot loader is needed to enable JTAG and it won't enable 
JTAG if the bootloader cannot run.

John Heenan

--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@...> wrote:
>
> I do not expect Philips to comment to either ... if they just listen
> and fix issues raised in their future releases, that is more than 
what
> one can expect under the circumstances.
> 
> As an academic, my personal intersts in reverse engineering is that
> unlike computer forensics, I can make up case study tutorials out of
> work I do for my clients.
> 
> --- In lpc2000@lpc2..., "brendanmurphy37" <brendan.murphy@>
> wrote:
> 
> > I'd be vey surprised if Philips even comment on this: why would 
or 
> > should they comment on an undocumented
feature that may or may 
not 
> > actually exist?
>
	
Reply by jayasooriah February 2, 20062006-02-02
Mauricio,

The boot loader update (which is generic to the family) actually only
updates the code segment while preserving the boot block parameter in
the boot segment that is in the part you are updating/

It is the boot block parameters, more specifically the part IDENT,
that determines, for example, how much ROM, how much RAM etc is enabled..

For example, if you destroyed the boot boot paramete block, you cannot
use the boot loader update to restore your boot loader sector.

Jaya

--- In lpc2000@lpc2..., Mauricio Scaff <scaffm@...> wrote:
>
> If the selection of "features" is done via Bootloader, the
bootloader 
> upgrade option would not have only 1 .hex file for download, but
several 
> files, one for each device.
> 
> Am I wrong ?
	
Reply by Mauricio Scaff February 2, 20062006-02-02
If the selection of "features" is done via Bootloader, the
bootloader 
upgrade option would not have only 1 .hex file for download, but several 
files, one for each device.

Am I wrong ?

Mauricio
	jayasooriah wrote:
> I was not thinking of this reason when I asked the
question.  However,
> after grading, the devices are typically permanantly 'fused' to
> reflect their capabilities.
>
> In the case of LPC, it appears that the grading is reversible.  The
> only reason for 'soft' grading I can think of is for purposes of
> competive pricing.  If this were the case, could Philips block the
> publication of discovered features relating to up/down grading device
> capabilities?
>
> --- In lpc2000@lpc2..., "Paul Curtis" <plc@...> wrote:
>
> > Hypothetically, one assumes that all chips are graded
> > and those that do not make the grade (i.e. have certain defects)
> > will have those defective blocks disabled ...
> >
> > Isn't it common to grade CPUs this way?
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>

> 	Microprocessor 
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>

> 	Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>

>
> Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>

>
>
>
> 
> >.
>
>
> 
>
	
	
Reply by derbaier February 2, 20062006-02-02
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@...>
wrote:
>
> --- In lpc2000@lpc2..., "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.
> 

I will bet that the boot loader code is in FLASH and not in ROM, so of
course, the FLASH is used directly.  It contains the boot loader. In
any case, the boot sequence is tangential to the issue of sorting and
enabling parts based on wafer level testing, and is also not very
relevant to the "free lunch" that you have proposed. If FLASH
technology is actually on the same die as the logic, it also does not
all have to exist directly in ARM's memory space. If it is on a
stacked die, then it would more likely have to all be in ARM's memory
space.

Enough time wasting conjecture for me today!  ;-)

-- Dave
	
Reply by jayasooriah February 2, 20062006-02-02
I do not expect Philips to comment to either ... if they just listen
and fix issues raised in their future releases, that is more than what
one can expect under the circumstances.

As an academic, my personal intersts in reverse engineering is that
unlike computer forensics, I can make up case study tutorials out of
work I do for my clients.

--- In lpc2000@lpc2..., "brendanmurphy37" <brendan.murphy@...>
wrote:

> I'd be vey surprised if Philips even comment on
this: why would or 
> should they comment on an undocumented feature that may or may not 
> actually exist?
	
Reply by jayasooriah February 2, 20062006-02-02
--- In lpc2000@lpc2..., "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@lpc2..., "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
	
Reply by brendanmurphy37 February 2, 20062006-02-02
As with any un-documented "feature" (assuming it even exists), it's 
of little more than academic/hobbyist interest.

I can't think any company who values their reputation would make use 
of something like this to "enhance" a lower-spec device to a higher 
one:

- the "feature" could disappear at any time, meaning you'd have to 
test every unit for the enhanced feature

- if it failed that test, what are you going to do: send the units 
back because they "er, don't have this undocumented feature we 
found"? Fine if you've bought one or two, but a bit problematic if 
you've a few thousand parts to offload....

- maybe the IC is downgraded (as others have suggested) becase it 
fails some production test in the feature that's been removed: are 
you really going to risk putting product in the field with this risk?

I'd be vey surprised if Philips even comment on this: why would or 
should they comment on an undocumented feature that may or may not 
actually exist?

Brendan

--- In lpc2000@lpc2..., "Paul Curtis" <plc@...> wrote:
>
> Hi, 
> 
> > I was not thinking of this reason when I asked the question.  
However,
> > after grading, the devices are typically
permanantly 'fused' to
> > reflect their capabilities.
> > 
> > In the case of LPC, it appears that the grading is reversible.  
The
> > only reason for 'soft' grading I can think of
is for purposes of
> > competive pricing.  If this were the case, could Philips block the
> > publication of discovered features relating to up/down grading 
device
> > capabilities?
> 
> Could they block it?  Probably not, you can opt to publish and be
> damned.  As you've alerted them via this list, then one option they 
have
> is to take out an injunction (or similar) against
publication of 
that
> information, if they can get one.  I am not a
lawyer, and I have no 
real
> expertise in that area, but I believe an
injunction needs to be 
issued
> by a judge after a convincing argument in the UK,
and it's possibly 
the
> same elsewhere.
> 
> 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.
 However, I do 
not
> believe that this will stop a legal challenge to
be resolved in the
> courts, should Philips wish it.
> 
> Again, just my opinion.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>
	
Reply by derbaier February 2, 20062006-02-02
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@...>
wrote:
>
> I was not thinking of this reason when I asked the question.  However,
> after grading, the devices are typically permanantly 'fused' to
> reflect their capabilities.
> 

Actually, that is not really true.  Some CMOS processes have the fuse
link capabilities, but many newer ones do not.  Another grading method
is by "bond out" options, where the packaging process sets the
capabilities available after basic die testing and sorting. That, of
course, cannot be easily reversed by an experimenter. 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.  If that is what they are doing, then the deleted
functions may work fine under nominal temperature/voltage/frequency
conditions, but will fail at one of the "corner" conditions.
	TANSTAAFL - Robert A. Heinlein

-- Dave
	
Reply by jayasooriah February 2, 20062006-02-02
I was not thinking of this reason when I asked the question.  However,
after grading, the devices are typically permanantly 'fused' to
reflect their capabilities.

In the case of LPC, it appears that the grading is reversible.  The
only reason for 'soft' grading I can think of is for purposes of
competive pricing.  If this were the case, could Philips block the
publication of discovered features relating to up/down grading device
capabilities?

--- In lpc2000@lpc2..., "Paul Curtis" <plc@...> wrote:

> Hypothetically, one assumes that all chips are
graded 
> and those that do not make the grade (i.e. have certain defects)
> will have those defective blocks disabled ...
> 
> Isn't it common to grade CPUs this way?