Jaya,
http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
Chapter B3 about synchronized clock
Somebody at Philips went through some effort and wrote a very nize
summary on Dec 22
This should give you a good idea why the bootcode is not available in
source code:
---- quote -------
2) I am going to replace the Philips bootloader. I have figured out
how to do it.
Replacing the Philips bootloader is not recommended. It hides the
underlying hardware and allows Philips to use new flash technologies
without impacting the end user. Philips Bootloader may reside in ROM
or write/erase protected flash making replacement impossible. In
LPC2101/2/3 the bootloader resides in on-chip ROM.
---- end quote -------
Flash blocks change in size and timing. Providing a software interface
that you just need to call is much more user friendly than running
into support and debug issues every time an "expert" changes the
code
to his/her liking generating undefined events in the flash programming
sequence or timing.
It is fine that you disassembled the bootloader, nice exercise. Using
a reengineered version of the bootloader / programming software can
probably not increase the functionality but I can assure you it will
increase the trouble you get yourself and your customers in.
Overall, I do not understand you, if you think the CRP is not save,
then look at other devices and try to find one that is good enough for
your high standards. So far there have been 50++ messages but nobody
said that they were able to break the mechanism.
So, once you were able to set CRP in a device that actually can be
secured, which are all device but the LPC2104/5/6 and enable JTAG
without doing a chip erase I would be interested in your data. But
only then!
As a previous poster said, please feel free to set up a new Yahoo
group "Code read protection in ARM devices" and the enthusiasts
will
follow you there.
As long as you post your assumptions, non-applicable bootloaders ....
Bob
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...>
wrote:
> > Reverse disassembly of bootloader is of no use in hacking the chip.
> > Regards
>
> If this is true, Philips would have provided us with source for the
> boot loader.
>
> You do not expect Philips to build defects into the boot loader. It
> does not follow however that there are no defects, or that they cannot
> be exploited.
>
> In a regime where obscurity is critical component of security,
> exposing internals is a high security risk.
>
> Jaya
>
Re: LPC Boot Loader Internals
Started by ●January 4, 2006
Reply by ●January 4, 20062006-01-04
Reply by ●January 4, 20062006-01-04
Umm... OK => by studying the bootloader, may be you can figure out
some silly mistakes by boot loader writer making CRP vulnerable to
attack. But pls reverse/disassembly on a correct CRP enabled chip.
And Let us know if you have some proven way of cracking the
protection. There is supposed to have enough hardware protection
(even if that H/W protection of "cannot crack into the JTAG enabled
window" is by "coincidence" and not original function by design).
The P89C51RD+ was also done in the same bootloader way (except
it has protection lock bits to disable the parallel programming)
Somwhow had not heard of anybody cracked the chip...
I'm happy as long as there is no simple way of cracking LPC2xxx...
Regards
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > Reverse disassembly of bootloader is of no use in hacking the
chip.
> > Regards
>
> If this is true, Philips would have provided us with source for the
> boot loader.
>
> You do not expect Philips to build defects into the boot loader.
It
> does not follow however that there are no defects, or that they
cannot
> be exploited.
>
> In a regime where obscurity is critical component of security,
> exposing internals is a high security risk.
>
> Jaya
>
some silly mistakes by boot loader writer making CRP vulnerable to
attack. But pls reverse/disassembly on a correct CRP enabled chip.
And Let us know if you have some proven way of cracking the
protection. There is supposed to have enough hardware protection
(even if that H/W protection of "cannot crack into the JTAG enabled
window" is by "coincidence" and not original function by design).
The P89C51RD+ was also done in the same bootloader way (except
it has protection lock bits to disable the parallel programming)
Somwhow had not heard of anybody cracked the chip...
I'm happy as long as there is no simple way of cracking LPC2xxx...
Regards
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > Reverse disassembly of bootloader is of no use in hacking the
chip.
> > Regards
>
> If this is true, Philips would have provided us with source for the
> boot loader.
>
> You do not expect Philips to build defects into the boot loader.
It
> does not follow however that there are no defects, or that they
cannot
> be exploited.
>
> In a regime where obscurity is critical component of security,
> exposing internals is a high security risk.
>
> Jaya
>
Reply by ●January 4, 20062006-01-04
Bob, are you having a bad day or is it a bad month? Hopefully it will
improve. In the past you have been a helpful happy chap and a welcome
contributor to this group.
I was going to reply to your initial remarks (ouch) but others answered
up very well. Could you please explain to me why you are so insistent on
shooting down this thread (or is it Jaya?). Do you think that we really
want this group to become fragmented into specialist groups like "Code
read protection in ARM devices"? I can only shake my head at the thought.
Posting information that could prove useful to somebody in the group
should be encouraged. We all appreciate the discussions whether they are
relevant to what we ourselves are doing at the time or not, or should we
then just burn >99.9% of the books at the library because we think they
are not relevant? If it's relevant to LPC2000 then this is where it belongs.
I treat Jaya's volunteered information as a "this is what I did" post of
interest. It would be foolish to expect him to do something more or
differently unless we were paying him.
Didn't he say he did this because his students were killing their
USB-LPC boards. As far as I understand it, it was not a code security
issue per se but rather a way of finding a way to make the boards
"student proof" (good luck!).
*Peter*
lpc2100_fan wrote:
> Jaya,
>
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
>
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
>
> This should give you a good idea why the bootcode is not available in
> source code:
>
> ---- quote -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
>
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
>
> ---- end quote -------
>
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing.
>
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
>
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
>
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
>
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
>
> As long as you post your assumptions, non-applicable bootloaders ....
>
> Bob
improve. In the past you have been a helpful happy chap and a welcome
contributor to this group.
I was going to reply to your initial remarks (ouch) but others answered
up very well. Could you please explain to me why you are so insistent on
shooting down this thread (or is it Jaya?). Do you think that we really
want this group to become fragmented into specialist groups like "Code
read protection in ARM devices"? I can only shake my head at the thought.
Posting information that could prove useful to somebody in the group
should be encouraged. We all appreciate the discussions whether they are
relevant to what we ourselves are doing at the time or not, or should we
then just burn >99.9% of the books at the library because we think they
are not relevant? If it's relevant to LPC2000 then this is where it belongs.
I treat Jaya's volunteered information as a "this is what I did" post of
interest. It would be foolish to expect him to do something more or
differently unless we were paying him.
Didn't he say he did this because his students were killing their
USB-LPC boards. As far as I understand it, it was not a code security
issue per se but rather a way of finding a way to make the boards
"student proof" (good luck!).
*Peter*
lpc2100_fan wrote:
> Jaya,
>
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
>
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
>
> This should give you a good idea why the bootcode is not available in
> source code:
>
> ---- quote -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
>
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
>
> ---- end quote -------
>
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing.
>
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
>
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
>
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
>
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
>
> As long as you post your assumptions, non-applicable bootloaders ....
>
> Bob
Reply by ●January 4, 20062006-01-04
Hee, just kidding...pls don't mind
May be lpc2100_fan is one of the Philips chip engineer...
and does not want us to know:
- How to enable the 4 CAN ports on a LPC2124...
- Or may be how to enable the USB on LPC2138...
- Or may be how to enable some 2x 64K sectors on LPC2114...
Also rumours of Philips is trying to sell away it's whole semicon
division (?? don't know how true is that) Potential buyers
are Infineon and ST-Micro, but will be mostly just buying
part of the semicon...
Pls don't try to kill me....
--- In lpc2000@lpc2..., Peter Jakacki <peterjak@t...> wrote:
>
> Bob, are you having a bad day or is it a bad month? Hopefully it
will
> improve. In the past you have been a helpful happy chap and a
welcome
> contributor to this group.
>
> I was going to reply to your initial remarks (ouch) but others
answered
> up very well. Could you please explain to me why you are so
insistent on
> shooting down this thread (or is it Jaya?). Do you think that we
really
> want this group to become fragmented into specialist groups
like "Code
> read protection in ARM devices"? I can only shake my head at the
thought.
>
> Posting information that could prove useful to somebody in the
group
> should be encouraged. We all appreciate the discussions whether
they are
> relevant to what we ourselves are doing at the time or not, or
should we
> then just burn >99.9% of the books at the library because we think
they
> are not relevant? If it's relevant to LPC2000 then this is where
it belongs.
>
> I treat Jaya's volunteered information as a "this is what I did"
post of
> interest. It would be foolish to expect him to do something more
or
> differently unless we were paying him.
>
> Didn't he say he did this because his students were killing their
> USB-LPC boards. As far as I understand it, it was not a code
security
> issue per se but rather a way of finding a way to make the boards
> "student proof" (good luck!).
>
> *Peter*
>
> lpc2100_fan wrote:
> > Jaya,
> >
> > http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> > Chapter B3 about synchronized clock
> >
> > Somebody at Philips went through some effort and wrote a very
nize
> > summary on Dec 22
> >
> > This should give you a good idea why the bootcode is not
available in
> > source code:
> >
> > ---- quote -------
> > 2) I am going to replace the Philips bootloader. I have figured
out
> > how to do it.
> >
> > Replacing the Philips bootloader is not recommended. It hides the
> > underlying hardware and allows Philips to use new flash
technologies
> > without impacting the end user. Philips Bootloader may reside in
ROM
> > or write/erase protected flash making replacement impossible. In
> > LPC2101/2/3 the bootloader resides in on-chip ROM.
> >
> > ---- end quote -------
> >
> > Flash blocks change in size and timing. Providing a software
interface
> > that you just need to call is much more user friendly than
running
> > into support and debug issues every time an "expert" changes the
code
> > to his/her liking generating undefined events in the flash
programming
> > sequence or timing.
> >
> > It is fine that you disassembled the bootloader, nice exercise.
Using
> > a reengineered version of the bootloader / programming software
can
> > probably not increase the functionality but I can assure you it
will
> > increase the trouble you get yourself and your customers in.
> >
> > Overall, I do not understand you, if you think the CRP is not
save,
> > then look at other devices and try to find one that is good
enough for
> > your high standards. So far there have been 50++ messages but
nobody
> > said that they were able to break the mechanism.
> >
> > So, once you were able to set CRP in a device that actually can
be
> > secured, which are all device but the LPC2104/5/6 and enable JTAG
> > without doing a chip erase I would be interested in your data.
But
> > only then!
> >
> > As a previous poster said, please feel free to set up a new Yahoo
> > group "Code read protection in ARM devices" and the enthusiasts
will
> > follow you there.
> >
> > As long as you post your assumptions, non-applicable
bootloaders ....
> >
> > Bob
>
May be lpc2100_fan is one of the Philips chip engineer...
and does not want us to know:
- How to enable the 4 CAN ports on a LPC2124...
- Or may be how to enable the USB on LPC2138...
- Or may be how to enable some 2x 64K sectors on LPC2114...
Also rumours of Philips is trying to sell away it's whole semicon
division (?? don't know how true is that) Potential buyers
are Infineon and ST-Micro, but will be mostly just buying
part of the semicon...
Pls don't try to kill me....
--- In lpc2000@lpc2..., Peter Jakacki <peterjak@t...> wrote:
>
> Bob, are you having a bad day or is it a bad month? Hopefully it
will
> improve. In the past you have been a helpful happy chap and a
welcome
> contributor to this group.
>
> I was going to reply to your initial remarks (ouch) but others
answered
> up very well. Could you please explain to me why you are so
insistent on
> shooting down this thread (or is it Jaya?). Do you think that we
really
> want this group to become fragmented into specialist groups
like "Code
> read protection in ARM devices"? I can only shake my head at the
thought.
>
> Posting information that could prove useful to somebody in the
group
> should be encouraged. We all appreciate the discussions whether
they are
> relevant to what we ourselves are doing at the time or not, or
should we
> then just burn >99.9% of the books at the library because we think
they
> are not relevant? If it's relevant to LPC2000 then this is where
it belongs.
>
> I treat Jaya's volunteered information as a "this is what I did"
post of
> interest. It would be foolish to expect him to do something more
or
> differently unless we were paying him.
>
> Didn't he say he did this because his students were killing their
> USB-LPC boards. As far as I understand it, it was not a code
security
> issue per se but rather a way of finding a way to make the boards
> "student proof" (good luck!).
>
> *Peter*
>
> lpc2100_fan wrote:
> > Jaya,
> >
> > http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> > Chapter B3 about synchronized clock
> >
> > Somebody at Philips went through some effort and wrote a very
nize
> > summary on Dec 22
> >
> > This should give you a good idea why the bootcode is not
available in
> > source code:
> >
> > ---- quote -------
> > 2) I am going to replace the Philips bootloader. I have figured
out
> > how to do it.
> >
> > Replacing the Philips bootloader is not recommended. It hides the
> > underlying hardware and allows Philips to use new flash
technologies
> > without impacting the end user. Philips Bootloader may reside in
ROM
> > or write/erase protected flash making replacement impossible. In
> > LPC2101/2/3 the bootloader resides in on-chip ROM.
> >
> > ---- end quote -------
> >
> > Flash blocks change in size and timing. Providing a software
interface
> > that you just need to call is much more user friendly than
running
> > into support and debug issues every time an "expert" changes the
code
> > to his/her liking generating undefined events in the flash
programming
> > sequence or timing.
> >
> > It is fine that you disassembled the bootloader, nice exercise.
Using
> > a reengineered version of the bootloader / programming software
can
> > probably not increase the functionality but I can assure you it
will
> > increase the trouble you get yourself and your customers in.
> >
> > Overall, I do not understand you, if you think the CRP is not
save,
> > then look at other devices and try to find one that is good
enough for
> > your high standards. So far there have been 50++ messages but
nobody
> > said that they were able to break the mechanism.
> >
> > So, once you were able to set CRP in a device that actually can
be
> > secured, which are all device but the LPC2104/5/6 and enable JTAG
> > without doing a chip erase I would be interested in your data.
But
> > only then!
> >
> > As a previous poster said, please feel free to set up a new Yahoo
> > group "Code read protection in ARM devices" and the enthusiasts
will
> > follow you there.
> >
> > As long as you post your assumptions, non-applicable
bootloaders ....
> >
> > Bob
>
Reply by ●January 5, 20062006-01-05
B3 in ARM7TDMI-S reference manual does not address the issue I raised.
The response from Philips is what you would expec. Philips is not the
only manufacturer that produces devices with flash memory. The other
manufacturs do change their technology too.
Unlike Philips, they publish the programming algorithm so that we all
can evaluate it for what it is worth. Philips programming algorithm
has no safeguards whatsoever with respect to what happens when code
fails -- not just user code, but the supplied boot loader code too.
I do not know of any other manufacturer who sells you 128K flash and
at the same time demands that reserve 8K or 12K of this for the sole
use by the manufacturer, to install code that will enable the device
to accessed from the outside world, but with no garantees whatsoever.
--- In lpc2000@lpc2..., "lpc2100_fan" <lpc2100_fan@y...> wrote:
>
> Jaya,
>
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
>
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
>
> This should give you a good idea why the bootcode is not available in
> source code:
>
> ---- quote -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
>
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
>
> ---- end quote -------
>
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing.
>
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
>
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
>
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
>
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
>
> As long as you post your assumptions, non-applicable bootloaders ....
>
> Bob >
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> >
> > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > > Reverse disassembly of bootloader is of no use in hacking the chip.
> > > Regards
> >
> > If this is true, Philips would have provided us with source for the
> > boot loader.
> >
> > You do not expect Philips to build defects into the boot loader. It
> > does not follow however that there are no defects, or that they cannot
> > be exploited.
> >
> > In a regime where obscurity is critical component of security,
> > exposing internals is a high security risk.
> >
> > Jaya
> >
>
The response from Philips is what you would expec. Philips is not the
only manufacturer that produces devices with flash memory. The other
manufacturs do change their technology too.
Unlike Philips, they publish the programming algorithm so that we all
can evaluate it for what it is worth. Philips programming algorithm
has no safeguards whatsoever with respect to what happens when code
fails -- not just user code, but the supplied boot loader code too.
I do not know of any other manufacturer who sells you 128K flash and
at the same time demands that reserve 8K or 12K of this for the sole
use by the manufacturer, to install code that will enable the device
to accessed from the outside world, but with no garantees whatsoever.
--- In lpc2000@lpc2..., "lpc2100_fan" <lpc2100_fan@y...> wrote:
>
> Jaya,
>
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf
> Chapter B3 about synchronized clock
>
> Somebody at Philips went through some effort and wrote a very nize
> summary on Dec 22
>
> This should give you a good idea why the bootcode is not available in
> source code:
>
> ---- quote -------
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
>
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash technologies
> without impacting the end user. Philips Bootloader may reside in ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
>
> ---- end quote -------
>
> Flash blocks change in size and timing. Providing a software interface
> that you just need to call is much more user friendly than running
> into support and debug issues every time an "expert" changes the code
> to his/her liking generating undefined events in the flash programming
> sequence or timing.
>
> It is fine that you disassembled the bootloader, nice exercise. Using
> a reengineered version of the bootloader / programming software can
> probably not increase the functionality but I can assure you it will
> increase the trouble you get yourself and your customers in.
>
> Overall, I do not understand you, if you think the CRP is not save,
> then look at other devices and try to find one that is good enough for
> your high standards. So far there have been 50++ messages but nobody
> said that they were able to break the mechanism.
>
> So, once you were able to set CRP in a device that actually can be
> secured, which are all device but the LPC2104/5/6 and enable JTAG
> without doing a chip erase I would be interested in your data. But
> only then!
>
> As a previous poster said, please feel free to set up a new Yahoo
> group "Code read protection in ARM devices" and the enthusiasts will
> follow you there.
>
> As long as you post your assumptions, non-applicable bootloaders ....
>
> Bob >
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote:
> >
> > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > > Reverse disassembly of bootloader is of no use in hacking the chip.
> > > Regards
> >
> > If this is true, Philips would have provided us with source for the
> > boot loader.
> >
> > You do not expect Philips to build defects into the boot loader. It
> > does not follow however that there are no defects, or that they cannot
> > be exploited.
> >
> > In a regime where obscurity is critical component of security,
> > exposing internals is a high security risk.
> >
> > Jaya
> >
>
Reply by ●January 5, 20062006-01-05
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
> The response from Philips is what you would expec. Philips is not the
> only manufacturer that produces devices with flash memory. The other
> manufacturs do change their technology too.
>
> Unlike Philips, they publish the programming algorithm so that we all
> can evaluate it for what it is worth.
Not all of them do, in fact ST pops immediately to mind as one who has
done a very similar thing. And I suspect it was for much the reason
the Philips has claimed (to keep the changes in flash technology from
having to be propagated up to the user). They got bit by that once.
Philips left out an obvious and related reason. By keeping the flash
algorithm hidden in an internal state machine they reduce the
inevitable support cost associated with exposing it.
In some sense I haven't seen a flash in quite some time that had it's
programming algorithm exposed. The last one I saw was probably in the
early to mid 90's. Even the external ones hide it behind an internal
state machine. NAND flash on the other hand I don't know about. I can understand your security concerns even if I don't share them but
your angst over them not exposing the flash programming algorithm
seems to be overdone. That the programming section is somewhat
vulnerable is unfortunate even if you are one of very few people who
have reported a problem with it, but it is no worse than any micro
with no built-in isp algorithm. ISP support is, after all, a fairly
recent innovation. I still know of systems where development testing
is done by unsocketing an EPROM and placing under a UV lamp while
replacing it with a newly programmed replacement.
Better protection of that boot block is desireable, but if Philips is
really moving that into ROM as has been suggested then that is already
happening.
Advertising what is essentially a 120K device as a 128K device is
another question, but it is unfortuately the sort of specmanship I've
come to expect from semiconductor companies.
RTFM and caveat emptor
Robert
> The response from Philips is what you would expec. Philips is not the
> only manufacturer that produces devices with flash memory. The other
> manufacturs do change their technology too.
>
> Unlike Philips, they publish the programming algorithm so that we all
> can evaluate it for what it is worth.
Not all of them do, in fact ST pops immediately to mind as one who has
done a very similar thing. And I suspect it was for much the reason
the Philips has claimed (to keep the changes in flash technology from
having to be propagated up to the user). They got bit by that once.
Philips left out an obvious and related reason. By keeping the flash
algorithm hidden in an internal state machine they reduce the
inevitable support cost associated with exposing it.
In some sense I haven't seen a flash in quite some time that had it's
programming algorithm exposed. The last one I saw was probably in the
early to mid 90's. Even the external ones hide it behind an internal
state machine. NAND flash on the other hand I don't know about. I can understand your security concerns even if I don't share them but
your angst over them not exposing the flash programming algorithm
seems to be overdone. That the programming section is somewhat
vulnerable is unfortunate even if you are one of very few people who
have reported a problem with it, but it is no worse than any micro
with no built-in isp algorithm. ISP support is, after all, a fairly
recent innovation. I still know of systems where development testing
is done by unsocketing an EPROM and placing under a UV lamp while
replacing it with a newly programmed replacement.
Better protection of that boot block is desireable, but if Philips is
really moving that into ROM as has been suggested then that is already
happening.
Advertising what is essentially a 120K device as a 128K device is
another question, but it is unfortuately the sort of specmanship I've
come to expect from semiconductor companies.
RTFM and caveat emptor
Robert
Reply by ●January 5, 20062006-01-05
--- In lpc2000@lpc2..., "robertadsett" <subscriptions@a...>
> Not all of them do, in fact ST pops immediately to mind
> as one who has done a very similar thing.
If you can tell me which device in particular, I would like to look
into it when get bored. My previous experience was with ST10 and its
errata sheet was nothing like that for 2105 in terms of the types of
bugs in silicon.
>I can understand your security concerns even if I don't share
>them but your angst over them not exposing the flash programming
>algorithm seems to be overdone.
Off top of my head:
1/ The entire on-chip flash can be destroyed by scribbling over the
just one location in memory with some random value. [PLLs and WDs
incorporate feed sequences, but this self destruct sequence has none.]
2/ The sector bit maps are all over the place. In the case of 2105
its 16 sectors are mapped to the top and bottom 8 bits, leaving out 16
bits in the middle. [The product appears to be in its infant stages
of development in relation to maturity of design.]
3/ It appears that to program the flash charge pump cycle parameters
are required. [Using inappropriate values here could result in frying
the part for good.]
It is in consumers' interest to know about things like this that can
destroy the LPC. [LPC was abandoned for laboratory kits that students
load and run programs.]
It is quite possible for hardware manufacurers and software providers
to blame each other for field failures in the light of the above.
About 10% of LPC2105 parts with bootloader versions prior to 1.52 did
fail in the field according to Philips. One wonders what happened in
the field resulting in Philips stating this in the errata sheet.
Jaya
> Not all of them do, in fact ST pops immediately to mind
> as one who has done a very similar thing.
If you can tell me which device in particular, I would like to look
into it when get bored. My previous experience was with ST10 and its
errata sheet was nothing like that for 2105 in terms of the types of
bugs in silicon.
>I can understand your security concerns even if I don't share
>them but your angst over them not exposing the flash programming
>algorithm seems to be overdone.
Off top of my head:
1/ The entire on-chip flash can be destroyed by scribbling over the
just one location in memory with some random value. [PLLs and WDs
incorporate feed sequences, but this self destruct sequence has none.]
2/ The sector bit maps are all over the place. In the case of 2105
its 16 sectors are mapped to the top and bottom 8 bits, leaving out 16
bits in the middle. [The product appears to be in its infant stages
of development in relation to maturity of design.]
3/ It appears that to program the flash charge pump cycle parameters
are required. [Using inappropriate values here could result in frying
the part for good.]
It is in consumers' interest to know about things like this that can
destroy the LPC. [LPC was abandoned for laboratory kits that students
load and run programs.]
It is quite possible for hardware manufacurers and software providers
to blame each other for field failures in the light of the above.
About 10% of LPC2105 parts with bootloader versions prior to 1.52 did
fail in the field according to Philips. One wonders what happened in
the field resulting in Philips stating this in the errata sheet.
Jaya
