Lpc2000

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

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@...> 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@yahoogroups.com, "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@yahoogroups.com, "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@yahoogroups.com, "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@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

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@yahoogroups.com, "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@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- 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.
> 

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

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@yahoogroups.com, "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=95&.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=95&.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=95&.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=95&.sig=Malspbd0T4Rq3M4Q0nHrfw> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



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

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@yahoogroups.com, 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 ?

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@yahoogroups.com, "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@yahoogroups.com, "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?
>

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@yahoogroups.com, "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@yahoogroups.com, "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@yahoogroups.com, "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?
> >
>