Robert,
What does the ISP 'T' command do? I found this command in version
1.51 of the boot loader for 2104/5/6 but it looks like it has been
omitted from Command Summary Table 142 on page 184 of the user manual.
Perhaps it would be useful also to to add such information to your FAQ.
Jaya
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...> wrote:
>
> At 01:19 AM 12/23/05 +0000, philips_apps wrote:
> >Hope this answers all the questions raised on Flash security. Many
> >thanks to the group users. We appreciate your feedback. Please keep
it
> >coming. Most of us are out till Jan 2 due to year end shutdown.
> >
> >Happy Holidays and a Happy New Year
> >
> >- Philips Microcontroller Team
>
> Nice summary. With your permission I'll copy this to the FAQ (with
> appropriate credit of course).
>
> Robert
>
> " 'Freedom' has no meaning of itself. There are always
restrictions, be
> they legal, genetic, or physical. If you
don't believe me, try to
chew a
> radio signal. " -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>
Flash Security Clarification
Started by ●December 22, 2005
Reply by ●December 23, 20052005-12-23
Reply by ●December 23, 20052005-12-23
Sorry for the typo error, version is 1.52, not 1.51.
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
>
> Robert,
>
> What does the ISP 'T' command do? I found this command in version
> 1.51 of the boot loader for 2104/5/6 but it looks like it has been
> omitted from Command Summary Table 142 on page 184 of the user manual.
>
> Perhaps it would be useful also to to add such information to your FAQ.
>
> Jaya
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
>
> Robert,
>
> What does the ISP 'T' command do? I found this command in version
> 1.51 of the boot loader for 2104/5/6 but it looks like it has been
> omitted from Command Summary Table 142 on page 184 of the user manual.
>
> Perhaps it would be useful also to to add such information to your FAQ.
>
> Jaya
Reply by ●December 24, 20052005-12-24
ok, i've tried couple experiments and done RE of the boot loader, and
here are my findings:
1. JTAG pins are configured as GPIO inputs during reset, RTCK is
sampled by the boot loader itself and GPIO are configured accordingly
at latter stage
2. There is something, like CRP latch in the chip, the boot loader
writes 0xFFFFFFFF there, if CRP is enabled
3. it is possible to rewrite the boot loader only, even on CRP
protected devices.
4. it is possible to ENABLE the JTAG on CRP protected devices, using
5 asm commands run from ram, however FLASH is still inaccessible from
JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less
zeroing the CRP latch by means of JTAG enables full access to FLASH,
provided, you stop CPU before that (zeroing CRP latch resets the cpu
core. Only the core, not periferals)
This was tested on LPC2129, with latest bootloader.
tools :
IDA Pro Advanced,
philips on-field boot loader update utility
Olimex LPC2129 board.
here are my findings:
1. JTAG pins are configured as GPIO inputs during reset, RTCK is
sampled by the boot loader itself and GPIO are configured accordingly
at latter stage
2. There is something, like CRP latch in the chip, the boot loader
writes 0xFFFFFFFF there, if CRP is enabled
3. it is possible to rewrite the boot loader only, even on CRP
protected devices.
4. it is possible to ENABLE the JTAG on CRP protected devices, using
5 asm commands run from ram, however FLASH is still inaccessible from
JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less
zeroing the CRP latch by means of JTAG enables full access to FLASH,
provided, you stop CPU before that (zeroing CRP latch resets the cpu
core. Only the core, not periferals)
This was tested on LPC2129, with latest bootloader.
tools :
IDA Pro Advanced,
philips on-field boot loader update utility
Olimex LPC2129 board.
Reply by ●December 24, 20052005-12-24
--- In lpc2000@lpc2..., "Felix" <felix_lazarev@y...>
wrote:
>
> ok, i've tried couple experiments and done RE of the boot loader,
and
> here are my findings:
>
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is
> sampled by the boot loader itself and GPIO are configured
accordingly
> at latter stage
> 2. There is something, like CRP latch in the chip, the boot loader
> writes 0xFFFFFFFF there, if CRP is enabled
> 3. it is possible to rewrite the boot loader only, even on CRP
> protected devices.
> 4. it is possible to ENABLE the JTAG on CRP protected devices,
using
> 5 asm commands run from ram, however FLASH is still inaccessible
from
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the
less
> zeroing the CRP latch by means of JTAG enables full access to
FLASH,
> provided, you stop CPU before that (zeroing CRP latch resets the
cpu
> core. Only the core, not periferals)
>
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.
>
Hi, Sorry, I do not understand a few points:
Item 3) How do you write to the boot loader??
If CRP is ON. JTAG should be disabled and user cannot
load/execute to/from RAM (ISP Command also disabled)
Item 4) Same questions, How do you put that few (5 ARM)
instructions onto the RAM and execute?? JTAG and ISP
load/execute to/from RAM are disabled.
=> Is there another way to force load+run code from RAM when both
JTAG and ISP command are disabled??
Thanks, and Regards /MH
>
> ok, i've tried couple experiments and done RE of the boot loader,
and
> here are my findings:
>
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is
> sampled by the boot loader itself and GPIO are configured
accordingly
> at latter stage
> 2. There is something, like CRP latch in the chip, the boot loader
> writes 0xFFFFFFFF there, if CRP is enabled
> 3. it is possible to rewrite the boot loader only, even on CRP
> protected devices.
> 4. it is possible to ENABLE the JTAG on CRP protected devices,
using
> 5 asm commands run from ram, however FLASH is still inaccessible
from
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the
less
> zeroing the CRP latch by means of JTAG enables full access to
FLASH,
> provided, you stop CPU before that (zeroing CRP latch resets the
cpu
> core. Only the core, not periferals)
>
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.
>
Hi, Sorry, I do not understand a few points:
Item 3) How do you write to the boot loader??
If CRP is ON. JTAG should be disabled and user cannot
load/execute to/from RAM (ISP Command also disabled)
Item 4) Same questions, How do you put that few (5 ARM)
instructions onto the RAM and execute?? JTAG and ISP
load/execute to/from RAM are disabled.
=> Is there another way to force load+run code from RAM when both
JTAG and ISP command are disabled??
Thanks, and Regards /MH
Reply by ●December 25, 20052005-12-25
There is a technique called JTAG boundary scanning. From memory, (I
did this some years ago) boundary scanning does not require the target
to come out of reset. In such a system, the "ememy" is all over the
code long before the processor even wakes up, and thus how quickly it
takes to secure flash becomes irrelevant.
Incidentally, the unavailablity of BSDL files (for LPC devices) does
not prevent this type of attack. There are methods by which one can
"discover" boundary architecture by blind scanning.
Philips needs to release a lot more information relating to its CRP
implementation and be more forthcoming with describing thing as they
are, not as they like us to believe (referring to "enabling" JTAG in
the boot loader) before I would consider CRP as anything more than
just a marketting gimmic.
Having said this, the issue with boot loader is that because Philips
will not publish its boot loader code, we never know what is hidden in
there that can be explioted by any would be attacker to void security
features.
The 'T' command that exists in 2104/5/6 boot loader that Philips has
not documented in any of the user manuals is one example. What *is*
this command there for and why is Philips not telling us about it?
I prefer not to say more about the 'T' command until Philips has had
an opportunity to respond to my question in the new year.
Meanwhile, may your holiday break be happy and safe, and may the new
year bring you more happiness and even more prosperity.
Best wishes to all ...
Jaya
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> => Is there another way to force load+run code from RAM when both
> JTAG and ISP command are disabled??
> Thanks, and Regards /MH
>
did this some years ago) boundary scanning does not require the target
to come out of reset. In such a system, the "ememy" is all over the
code long before the processor even wakes up, and thus how quickly it
takes to secure flash becomes irrelevant.
Incidentally, the unavailablity of BSDL files (for LPC devices) does
not prevent this type of attack. There are methods by which one can
"discover" boundary architecture by blind scanning.
Philips needs to release a lot more information relating to its CRP
implementation and be more forthcoming with describing thing as they
are, not as they like us to believe (referring to "enabling" JTAG in
the boot loader) before I would consider CRP as anything more than
just a marketting gimmic.
Having said this, the issue with boot loader is that because Philips
will not publish its boot loader code, we never know what is hidden in
there that can be explioted by any would be attacker to void security
features.
The 'T' command that exists in 2104/5/6 boot loader that Philips has
not documented in any of the user manuals is one example. What *is*
this command there for and why is Philips not telling us about it?
I prefer not to say more about the 'T' command until Philips has had
an opportunity to respond to my question in the new year.
Meanwhile, may your holiday break be happy and safe, and may the new
year bring you more happiness and even more prosperity.
Best wishes to all ...
Jaya
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> => Is there another way to force load+run code from RAM when both
> JTAG and ISP command are disabled??
> Thanks, and Regards /MH
>
Reply by ●December 25, 20052005-12-25
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> There is a technique called JTAG boundary scanning. From memory, (I
> did this some years ago) boundary scanning does not require the target
> to come out of reset. In such a system, the "ememy" is all over the
> code long before the processor even wakes up, and thus how quickly it
> takes to secure flash becomes irrelevant.
>
> Incidentally, the unavailablity of BSDL files (for LPC devices) does
> not prevent this type of attack. There are methods by which one can
> "discover" boundary architecture by blind scanning.
>
It is really hard to believe that any manufacturer of high volume
systems would buy a component with missing BSDL files! That would
make tests costs and time too high. Are you sure that major
manufacturers can not get BSDL files for LPC parts?
-- Dave
>
> There is a technique called JTAG boundary scanning. From memory, (I
> did this some years ago) boundary scanning does not require the target
> to come out of reset. In such a system, the "ememy" is all over the
> code long before the processor even wakes up, and thus how quickly it
> takes to secure flash becomes irrelevant.
>
> Incidentally, the unavailablity of BSDL files (for LPC devices) does
> not prevent this type of attack. There are methods by which one can
> "discover" boundary architecture by blind scanning.
>
It is really hard to believe that any manufacturer of high volume
systems would buy a component with missing BSDL files! That would
make tests costs and time too high. Are you sure that major
manufacturers can not get BSDL files for LPC parts?
-- Dave
Reply by ●December 25, 20052005-12-25
Ummm.... So far... I've confidence that Philips CRP is secure and
hack-proof.
a) Hacking LPC2xxx by JTAG boundary scan.
- Cannot answer your questions. But would that be same problems for
all other ARM chips from TI, Atmel and AD??
b) Current Philips Code locking
"Quite" safe. as long as..
- No secret alternate way of programming or chip testing. for e.g.
parallel programming
- Boot Loader programmer remembers to disable all commands and only
allows Chip Erasing when CRP enabled
- Boot Loader programmer remembers to erase the sector containing
0x87654321 last (Not first sector to erase)
c) Re-writing bootloader and replacing philips code
Why want to do that? Problems...
- Flash programming timing will be different if philips switches
silicon foundry
- It seems like all the 64Pin and 144pin devices (2294, 2292, 2214,
2114, 2124, 2129, 2194...) are same silicon. May be the boot loader
initialize chip to different parts. Oops! You might accidentally
enable a 64KB flash sector with lots of faulty bits, though your
128KB part becomes 256KB part free of charge...
- Philips Bootloader might initialize some unknown hardware or
memory mapping properly.
d) Undocumented commands in BootLoader.
- It can be extra commands for flash memory testing, peeping or etc.
However, not too much for concern as long as the guys writing the
boot loader remembers to disables all these commands when CRP is
enabled.
e) Allowing Customer App Program
- The LPC2xxx is NOT the correct part for a product with build in
O/S and customer could develop their own application program (and
where CRP on O/S section is needed). You need an ARM with MMU.
- OR: Change the design to include an interpreter (e.g. JAVA Run
time or Basic Interpreter)
- BTW, anybody has good recommendation for a Open Source Basic
interpreter to be ported onto LPC2124?? I'm looking for one
(Thanks in Advance)
f) May be another way to hack the Chip (I don't know..)
- Find out the exact clock cycles from reset and bootloader reads
0x87654321 (This is fixed no of clock cycles from reset as No
Interrupt, PLL disabled, Mem Accelerator is off)
- Pulse that few clock cycles to >100Mhz. The ARM CPU Core seems
could take >100MHz but not the philips flash memory. Hence the CPU
will read some "garbage bits"... May be 0x97654331 (even after the
ECC)
- Slow down the clock cycles to normal speed... as you get what you
want after that.... Yeah!!
- Philips could fix this by reading the 0x87654321 multiple times,
at random intervals.
=> To summarize, is it just whether you trust Philips or NOT....
Finally, Merry X'Mas....
Have fun hacking the chip over the holidays....
Let me know the outcome... THANKS!!
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> There is a technique called JTAG boundary scanning. From memory,
(I
> did this some years ago) boundary scanning does not require the
target
> to come out of reset. In such a system, the "ememy" is all over
the
> code long before the processor even wakes up, and thus how quickly
it
> takes to secure flash becomes irrelevant.
>
> Incidentally, the unavailablity of BSDL files (for LPC devices)
does
> not prevent this type of attack. There are methods by which one
can
> "discover" boundary architecture by blind scanning.
>
> Philips needs to release a lot more information relating to its CRP
> implementation and be more forthcoming with describing thing as
they
> are, not as they like us to believe (referring to "enabling" JTAG
in
> the boot loader) before I would consider CRP as anything more than
> just a marketting gimmic.
>
> Having said this, the issue with boot loader is that because
Philips
> will not publish its boot loader code, we never know what is
hidden in
> there that can be explioted by any would be attacker to void
security
> features.
>
> The 'T' command that exists in 2104/5/6 boot loader that Philips
has
> not documented in any of the user manuals is one example. What
*is*
> this command there for and why is Philips not telling us about it?
>
> I prefer not to say more about the 'T' command until Philips has
had
> an opportunity to respond to my question in the new year.
>
> Meanwhile, may your holiday break be happy and safe, and may the
new
> year bring you more happiness and even more prosperity.
>
> Best wishes to all ...
>
> Jaya
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > => Is there another way to force load+run code from RAM when both
> > JTAG and ISP command are disabled??
> > Thanks, and Regards /MH
> >
>
hack-proof.
a) Hacking LPC2xxx by JTAG boundary scan.
- Cannot answer your questions. But would that be same problems for
all other ARM chips from TI, Atmel and AD??
b) Current Philips Code locking
"Quite" safe. as long as..
- No secret alternate way of programming or chip testing. for e.g.
parallel programming
- Boot Loader programmer remembers to disable all commands and only
allows Chip Erasing when CRP enabled
- Boot Loader programmer remembers to erase the sector containing
0x87654321 last (Not first sector to erase)
c) Re-writing bootloader and replacing philips code
Why want to do that? Problems...
- Flash programming timing will be different if philips switches
silicon foundry
- It seems like all the 64Pin and 144pin devices (2294, 2292, 2214,
2114, 2124, 2129, 2194...) are same silicon. May be the boot loader
initialize chip to different parts. Oops! You might accidentally
enable a 64KB flash sector with lots of faulty bits, though your
128KB part becomes 256KB part free of charge...
- Philips Bootloader might initialize some unknown hardware or
memory mapping properly.
d) Undocumented commands in BootLoader.
- It can be extra commands for flash memory testing, peeping or etc.
However, not too much for concern as long as the guys writing the
boot loader remembers to disables all these commands when CRP is
enabled.
e) Allowing Customer App Program
- The LPC2xxx is NOT the correct part for a product with build in
O/S and customer could develop their own application program (and
where CRP on O/S section is needed). You need an ARM with MMU.
- OR: Change the design to include an interpreter (e.g. JAVA Run
time or Basic Interpreter)
- BTW, anybody has good recommendation for a Open Source Basic
interpreter to be ported onto LPC2124?? I'm looking for one
(Thanks in Advance)
f) May be another way to hack the Chip (I don't know..)
- Find out the exact clock cycles from reset and bootloader reads
0x87654321 (This is fixed no of clock cycles from reset as No
Interrupt, PLL disabled, Mem Accelerator is off)
- Pulse that few clock cycles to >100Mhz. The ARM CPU Core seems
could take >100MHz but not the philips flash memory. Hence the CPU
will read some "garbage bits"... May be 0x97654331 (even after the
ECC)
- Slow down the clock cycles to normal speed... as you get what you
want after that.... Yeah!!
- Philips could fix this by reading the 0x87654321 multiple times,
at random intervals.
=> To summarize, is it just whether you trust Philips or NOT....
Finally, Merry X'Mas....
Have fun hacking the chip over the holidays....
Let me know the outcome... THANKS!!
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> There is a technique called JTAG boundary scanning. From memory,
(I
> did this some years ago) boundary scanning does not require the
target
> to come out of reset. In such a system, the "ememy" is all over
the
> code long before the processor even wakes up, and thus how quickly
it
> takes to secure flash becomes irrelevant.
>
> Incidentally, the unavailablity of BSDL files (for LPC devices)
does
> not prevent this type of attack. There are methods by which one
can
> "discover" boundary architecture by blind scanning.
>
> Philips needs to release a lot more information relating to its CRP
> implementation and be more forthcoming with describing thing as
they
> are, not as they like us to believe (referring to "enabling" JTAG
in
> the boot loader) before I would consider CRP as anything more than
> just a marketting gimmic.
>
> Having said this, the issue with boot loader is that because
Philips
> will not publish its boot loader code, we never know what is
hidden in
> there that can be explioted by any would be attacker to void
security
> features.
>
> The 'T' command that exists in 2104/5/6 boot loader that Philips
has
> not documented in any of the user manuals is one example. What
*is*
> this command there for and why is Philips not telling us about it?
>
> I prefer not to say more about the 'T' command until Philips has
had
> an opportunity to respond to my question in the new year.
>
> Meanwhile, may your holiday break be happy and safe, and may the
new
> year bring you more happiness and even more prosperity.
>
> Best wishes to all ...
>
> Jaya
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > => Is there another way to force load+run code from RAM when both
> > JTAG and ISP command are disabled??
> > Thanks, and Regards /MH
> >
>
Reply by ●December 25, 20052005-12-25
Dave,
One poster on another forum says what client claims:
http://www.embeddedrelated.com/groups/lpc2000/show/2534.php
Major manufactures surely can get them, but they may need the muscle
or sign NDAs. I have always been able to obtain BSDL files using only
a Google search, but no hits for LPC except the above.
There is another hit but that is in a foreign language :(
Jaya
PS: I can understand why Philips would not make BSDL files freely
available if it can be used to work out how to defeat CRP :)
--- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote:
> It is really hard to believe that any manufacturer of high volume
> systems would buy a component with missing BSDL files! That would
> make tests costs and time too high. Are you sure that major
> manufacturers can not get BSDL files for LPC parts?
>
> -- Dave
>
One poster on another forum says what client claims:
http://www.embeddedrelated.com/groups/lpc2000/show/2534.php
Major manufactures surely can get them, but they may need the muscle
or sign NDAs. I have always been able to obtain BSDL files using only
a Google search, but no hits for LPC except the above.
There is another hit but that is in a foreign language :(
Jaya
PS: I can understand why Philips would not make BSDL files freely
available if it can be used to work out how to defeat CRP :)
--- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote:
> It is really hard to believe that any manufacturer of high volume
> systems would buy a component with missing BSDL files! That would
> make tests costs and time too high. Are you sure that major
> manufacturers can not get BSDL files for LPC parts?
>
> -- Dave
>
Reply by ●December 25, 20052005-12-25
Boundary Scan is not just a technique, it needs to be implemented in
hardware as such AND IT IS NOT IMPLEMENTED on the devices on the
market so far.
Robert
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
>
> There is a technique called JTAG boundary scanning. From memory, (I
> did this some years ago) boundary scanning does not require the
target
> to come out of reset. In such a system, the "ememy" is all over the
> code long before the processor even wakes up, and thus how quickly it
> takes to secure flash becomes irrelevant.
hardware as such AND IT IS NOT IMPLEMENTED on the devices on the
market so far.
Robert
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
>
> There is a technique called JTAG boundary scanning. From memory, (I
> did this some years ago) boundary scanning does not require the
target
> to come out of reset. In such a system, the "ememy" is all over the
> code long before the processor even wakes up, and thus how quickly it
> takes to secure flash becomes irrelevant.
Reply by ●December 25, 20052005-12-25
On Sunday 25 December 2005 02:35, Felix wrote:
> ok, i've tried couple experiments and done RE of the boot loader, and
> here are my findings:
>
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is
> sampled by the boot loader itself and GPIO are configured accordingly
> at latter stage
The manual says that PINSEL2 bit 2 is determined by the state of RTCK, and the
bootloader behaves as if this is correct. It clears bits 0 to 2 very early,
but saves PINSEL2's initial value. If 0x1fc isn't set to 0x87654321, the
value of PINSEL2 is restored. I can't see where the bootloader samples RTCK,
but even if it does, JTAG is reenabled before.
> 2. There is something, like CRP latch in the chip, the boot loader
> writes 0xFFFFFFFF there, if CRP is enabled
Where is that? It is written to the undocumented location 0x3fff8024 no matter
if CRP is enabled or not.
> 3. it is possible to rewrite the boot loader only, even on CRP
> protected devices.
I don't see how that's possible. The bootloader-updater is first written to
RAM, then rewrites Flash from there. You can't write to RAM using the ISP
routines when CRP is enabled, nor can you use JTAG.
> 4. it is possible to ENABLE the JTAG on CRP protected devices, using
> 5 asm commands run from ram, however FLASH is still inaccessible from
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less
> zeroing the CRP latch by means of JTAG enables full access to FLASH,
> provided, you stop CPU before that (zeroing CRP latch resets the cpu
> core. Only the core, not periferals)
How do you put these 5 asm commands into ram when CRP is enabled?
If flash is inaccessible "from JTAG" it is inaccessible from any code running.
I guess you misinterpreted some things. What debugger did you use for your
tests?
>
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.
Maybe you could provide more details? At what location is that "CRP latch"? I
don't think that CRP is implemented in hardware. The manual says that CRP is
available since bootloader version 1.61, which suggests that it was added
after the silicon was finished. CRP seems to be implemented only in software
(with the exception of non-standard JTAG handling, where nRESET keeps the
test logic in reset, too, preventing debug out of reset).
Regards,
Dominic
> ok, i've tried couple experiments and done RE of the boot loader, and
> here are my findings:
>
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is
> sampled by the boot loader itself and GPIO are configured accordingly
> at latter stage
The manual says that PINSEL2 bit 2 is determined by the state of RTCK, and the
bootloader behaves as if this is correct. It clears bits 0 to 2 very early,
but saves PINSEL2's initial value. If 0x1fc isn't set to 0x87654321, the
value of PINSEL2 is restored. I can't see where the bootloader samples RTCK,
but even if it does, JTAG is reenabled before.
> 2. There is something, like CRP latch in the chip, the boot loader
> writes 0xFFFFFFFF there, if CRP is enabled
Where is that? It is written to the undocumented location 0x3fff8024 no matter
if CRP is enabled or not.
> 3. it is possible to rewrite the boot loader only, even on CRP
> protected devices.
I don't see how that's possible. The bootloader-updater is first written to
RAM, then rewrites Flash from there. You can't write to RAM using the ISP
routines when CRP is enabled, nor can you use JTAG.
> 4. it is possible to ENABLE the JTAG on CRP protected devices, using
> 5 asm commands run from ram, however FLASH is still inaccessible from
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less
> zeroing the CRP latch by means of JTAG enables full access to FLASH,
> provided, you stop CPU before that (zeroing CRP latch resets the cpu
> core. Only the core, not periferals)
How do you put these 5 asm commands into ram when CRP is enabled?
If flash is inaccessible "from JTAG" it is inaccessible from any code running.
I guess you misinterpreted some things. What debugger did you use for your
tests?
>
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.
Maybe you could provide more details? At what location is that "CRP latch"? I
don't think that CRP is implemented in hardware. The manual says that CRP is
available since bootloader version 1.61, which suggests that it was added
after the silicon was finished. CRP seems to be implemented only in software
(with the exception of non-standard JTAG handling, where nRESET keeps the
test logic in reset, too, preventing debug out of reset).
Regards,
Dominic
