Hi, everybody,
if you are only interested in CRP (Code Read protection), Please
ignore the following issues:
- Any disassembly of the bootloader, done on wrong LPC2105 chip
with no protection
- Any undocumented commands on bootloader, e.g. 'T' command
- Any of the JTAG boundary scan
Most people here have come to conclusion of the following, and
waiting for philips reply:
=>> Is the JTAG port enabled by hardware (if P1.26/P1.20 pulled low)
after chip reset??
(***** PLEASE FOCUS ON THIS ISSUE *******)
Case 1) If JTAG port enabled by hardware automatically
- Hardware copies the state of P1.26/P1.30 and updates PINSEL2
after reset.
- For CRP, the bootloader have to read location 0x1fc early and
disables JTAG ports if CRP enabled
- This gives a hacking window of JTAG port not disabled between
reset and before bootloader disabling it.
- The hacking windows could be "ENLARGE" by clocking the ARM CPU at
much lower clock speed. i.e. 10KHz
- You could send in all the JTAG commands in that window then and
controls the ARM7 CPU...
- For manufacturing, Philips could use the JTAG port to program
very first copy of bootloader when the chip is completely empty.
Case 2) If JTAG port is NOT enabled by hardware automatically
- PINSEL2 is cleared after reset. All JTAG port are disabled by
default.
- The bootloader have to read location 0x1fc and P1.26/P1.30 and
enables JTAG ports accordingly
- The chip is well protected. There is no way to read back code
from JTAG port (unless and until bootloader enables it).
- For manufacturing, Philips must have "another way" of programming
the chip (may be parallel programming). Since there is no boot
loader code when manufactured, plus JTAG is disabled after reset
and cannot be used to write first copy of bootloader.
- As long as Philips keep secret of this "alternate flash
programming" method. We are safe...
(but Keep in mind that those chips are probably manufactured in
TSMC-Taiwan or MXIC-Taiwan :) )
Pls just sit back, relax and wait for philips answer...
they can run, buy-time but they cannot hide.... Heehee...
If philips "screw up" on this, affected parts will mostly be on
LPC2114-LPC2194 and LPC2212-LPC2294 (all could be same silicon).
They might have fixed the problem on LPC213x and LPC214x...
--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> It is still an apples and oranges discussion. My LPC2106 has
version
> 1.52 of the boot loader. The 2106 doesn't implement CRP nor is
there
> any claim that it does or ever will.
>
> The LPC2292/LPC2294 Product Datasheet in section 6.2 indicates
that
> CRP wasn't implemented in the boot code until version 1.60 and the
> November 14, 2005 Errata for the 2294 mentions version 1.63 as
being
> current in 2004. Presumably, Philips is at or beyond 1.63.
Anyone
> with a device that implements CRP can find the boot loader version
> with the ISP Utility.
>
>
> So, any tests or results on the 2106 are meaningless. CRP was
never
> implemented on this device and the boot code may never have been
> upgraded beyond 1.52 because the hardware doesn't support CRP.
This
> is a guess. I bought my 2106 within the last 6 months but that
> doesn't mean the chip is recent manufacture.
>
>
> One could draw a couple of likely incorrect conclusions. The code
> protection is ALL firmware and the boot code totally implements
it.
> Or, some hardware was added to the design of some devices (but not
the
> 2106) and the boot code takes advantage of the addition.
>
> What shouldn't be done is mention any results of testing the 2106
and
Show quoted textHide quoted text
> CRP in the same document. Or mention any version of the boot code
> prior to version 1.60 because CRP wasn't implemented.
>
> Richard
>