Re: LPC Internals Question

Started by Paul Curtis February 2, 2006
Hi, 

> Consider the following purely hypothetical
scenario: a) LPC variants
> have identical architecture on silicon; b) anyone can upgrade or
> downgrade the parts in their possession between these variants; and c)
> quite by accident you discover how to do this in the course 
> of your work.
> 
> I like the opinion from the vocals here as to what you would/should do
> in with your discovery.

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 before being packaged as some other chip.  One assumes
that if the process is in some way reversible, it's an interesting
academic exercise but if you turn on and make use of the defective
blocks then you're asking for a certain amount of trouble from customers
and, perhaps, Philips.

Isn't it common to grade CPUs this way?  It's just what I've read in the
many books I have, I have no direct experience with semi foundries.

Just my opinion.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

An Engineer's Guide to the LPC2100 Series

Consider the following purely hypothetical scenario: a) LPC variants
have identical architecture on silicon; b) anyone can upgrade or
downgrade the parts in their possession between these variants; and c)
quite by accident you discover how to do this in the course of your work.

I like the opinion from the vocals here as to what you would/should do
in with your discovery.
	
jayasooriah <jayasooriah@jaya...> schrieb am Thu, 02 Feb 2006 
10:20:00 -0000:

> Consider the following purely hypothetical
scenario: a) LPC variants
> have identical architecture on silicon;

I am pretty sure, some are, esp. if they differ only in RAM/FLASH sizes.
Often (not knowing about Philips, but read about this for others),
the chips are either downgraded artifically (Atari bought 32MHz 68020
which were labeled as 16MHz, because Motorola could not deliver real
16MHz version.)
Sometimes it is a selection during production test and parts that
do not work are disabled either via laser or some fuses.
(Intel did this with the 486DX or the 487er.)

The only way to know is to open e.g. a 2294,2292,2290 and look at the
die.

  b) anyone can upgrade or
> downgrade the parts in their possession between
these variants;

Maybe downgrading by burning some fuses .
	-- 
42Bastian Schick

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

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?
	
--- 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
	
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
>
	
--- 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
	
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?
	
--- 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