Lpc2000

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> On Monday 24 April 2006 09:54, John Heenan wrote:
> > The 'first thing', as falsely claimed on the web site, has to wait
> > eight ARM instructions to complete after reset with additional 
wait
> > states imposed by accessing the VPB. If it was genuinely 
the 'first
> > thing' it would only require three ARM instructions to complete!

> It's likely that you're talking about different versions of the 
bootloader. 
> Bootloader version 1.63 on a LPC2294 does what Jaya describes on 
his page. It 
> swaps the content of PINSEL2 with a 0x0 in the first three 
instructions.
> 

Here is the bizarre claim by Jaya again.

"However the first thing the boot loader in LPC2148 does (in a quite 
hasty fashion as if to minimise the window of opportunity) is to 
disable JTAG debug port.  This code is executed for both hardware and 
watchdog resets.  Why disable JTAG debug port if  is indeed already 
disabled on reset?."

Here are the first eight instructions on my LPC2148, including the 
first five which have nothing to do with disconnecting the JTAG port.

LDR       R4,[PC,#+0x34]
MOV       R5,#0x2
STR       R5,[R4,#+0]   ;stores 2 to VPB register MAMCR
MOV       R5,#0x3     
STR       R5,[R4,#+0x4] ;stores 3 to VPB register MAMTIM
LDR       R2,[PC,#+0x1c]
MOV       R3,#0
SWP       R0,R3,[R2]    ;exchange 0 with contents of PINSEL2 into R3


> Anyway, I don't think that it matters if it's done in the first 
three or eight 
> instructions - the window is too small for the necessary number of 
JTAG 
> cycles. I said it before, and I'm happy to repeat it: CRP is safe 
in that 
> regard.

Sounds like an indirect assertion Jaya has no idea what he is talking 
about.

> 
> > ATMEL fuse bits are nothing more than non volatile storage bits, 
> > which guess what, so is address 0x1FC where the CRP value is held!


> One difference is that a "fuse" could be evaluated by the hardware 
itself, 
> without relying on software (e.g. use the fuse value to force 
nTRST). This is 
> more complicated with flash, which could be the reason why Philips 
made CRP 
> at least partly a software feature.

There is no difference in this context. A fuse is just a label. The 
fuse still represents non volatile memory storage. Ultimately all 
memory storage have their contents grabbed by hardware after setting 
up bus signals, be that by software or hardware.

> 
> > ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT
> > THAT AN ENABLED JTAG DOES NOT MEAN  NECESSARILY INTERNAL DEBUG
> > SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? 
THIS
> > IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF
> > ELECTONICS AND MICROCONTROLLER ARCHITECTURE.
> 
> I don't understand why you're repeating this claim again and again. 
At least I 
> haven't seen any evidence that suggests that what you're saying is 
true - at 
> least not for the LPC2294. 

In the context of the speculative nature of the postings, I don't 
understand why you have a problem with this statement. Lack of 
concrete evidence has never been a problem for Jaya, so why can't I 
present a sensible and obvious credible possibility that I have no 
concrete evidence for, while accepting it is just a possibility. It 
is not normal for semiconductor companies to publicly document the 
entire internal bus workings of their products, least of all security 
mechanisms.

I am not able to confirm your statements about the LPC2294.

John Heenan
 
> Regards,
> 
> Dominic Rath
>