Forums

Re: LPC Internals Question

Started by Paul Curtis February 2, 2006
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>

>
>
>
> 
> >.
>
>
> 
>
	
	

An Engineer's Guide to the LPC2100 Series

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