For reference the posting we did on Dec 22
----
1) Am I right in assuming LPC2000 CRP is a software fence implemented
in the supplied boot loader code?
Partially. It is a combination of Hardware and Software supplied in
the bootloader code. Application running in micro has full access to
the entire memory space.
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.
3) How is Bootloader programmed for the first time?
Via JTAG on a tester. JTAG is accessible in virgin devices. Once
bootloader is programmed and CRP is enabled the tester can't access
the JTAG.
4) CRP in devices with internal flash and external bus.
The bootloader prevents external boot if CRP is enabled. User
Application residing in on-chip flash which needs to be protected
should not execute code from external memory.
5) Can bootloader write/erase itself?
No.
6) Can bootloader get corrupted?
Very unlikely if IAP/ISP calls are used for flash programming.
Very likely if Flash programming interface registers are directly
accessed for flash programming.
7) Can Philips comment if Quick-Pulse parallel programming can void
CRP?
First of all there is no Quick-Pulse parallel programming option for
ARM based micros. We are sorry for not making clear what is meant by
"Parallel Programming" for ARM based micros. Parallel programming
for
ARM based micros just means that the device can be mass programmed in
a commercial programmer. Parallel programmers still use JTAG and/or
ISP and go through the bootloader IAP routines to program the on-chip
flash. It does not matter how a part is programmed. If CRP is enabled
it will remain enabled once the part is programmed. If CRP is enabled
a parallel programmer can't access the flash unless it erases the
whole flash. Same applies to the ISP utility and JTAG based
debuggers.
8) Is CRP option available for 2104/05/06?
Not yet.
9) Devices with external memory bus can be forced to boot from
external memory?
ONLY if CRP is NOT enabled or NO internal flash present. Also see
(4).
10) Can I tell client Philips has confirmed CRP is not voided by PP?
Yes. Also see (7).
11) How do I reprogram a CRP enabled part?
Erase all user sectors in one go via ISP. You can reprogram it after
a
power cycle.
Please note that the protected code vanished and was not visible to a
"spy" or "praying eyes".
--------
12) Can JTAG be or remain enabled through clocking the CPU slowly
and JTAG fast during the initial time window after reset where JTAG
is enabled?
No, the clock for JTAG and the CPU are syncronized on these devices.
There are not enough JTAG clocks to control the CPU before the JTAG
gets disabled by the bootloader software.
13) Can the bootloader update be performed when CRP is enabled?
No, the bootloader update uses commands like copy RAM to Flash which
is disabled when CRP is enabled. The message will be that there is
no communication possible.
Comment to Robert Adsets posting:
It is correct that support efforts would be significantly higher
with published source code of the bootloader and let me add without
adding any benefits to you, our customers.
Bootloader / CRP summary update
Started by ●January 5, 2006
Reply by ●January 5, 20062006-01-05
Thank you!
Richard
--- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
wrote:
>
> For reference the posting we did on Dec 22
> ----
> 1) Am I right in assuming LPC2000 CRP is a software fence
implemented
> in the supplied boot loader code?
>
> Partially. It is a combination of Hardware and Software supplied in
> the bootloader code. Application running in micro has full access
to
> the entire memory space.
>
> 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.
>
> 3) How is Bootloader programmed for the first time?
>
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
>
> 4) CRP in devices with internal flash and external bus.
>
> The bootloader prevents external boot if CRP is enabled. User
> Application residing in on-chip flash which needs to be protected
> should not execute code from external memory.
>
> 5) Can bootloader write/erase itself?
>
> No.
>
> 6) Can bootloader get corrupted?
>
> Very unlikely if IAP/ISP calls are used for flash programming.
> Very likely if Flash programming interface registers are directly
> accessed for flash programming.
>
> 7) Can Philips comment if Quick-Pulse parallel programming can
void
> CRP?
>
> First of all there is no Quick-Pulse parallel programming option
for
> ARM based micros. We are sorry for not making clear what is meant
by
> "Parallel Programming" for ARM based micros. Parallel programming
for
> ARM based micros just means that the device can be mass programmed
in
> a commercial programmer. Parallel programmers still use JTAG and/or
> ISP and go through the bootloader IAP routines to program the on-
chip
> flash. It does not matter how a part is programmed. If CRP is
enabled
> it will remain enabled once the part is programmed. If CRP is
enabled
> a parallel programmer can't access the flash unless it erases the
> whole flash. Same applies to the ISP utility and JTAG based
> debuggers.
>
> 8) Is CRP option available for 2104/05/06?
>
> Not yet.
>
> 9) Devices with external memory bus can be forced to boot from
> external memory?
>
> ONLY if CRP is NOT enabled or NO internal flash present. Also see
> (4).
>
> 10) Can I tell client Philips has confirmed CRP is not voided by
PP?
>
> Yes. Also see (7).
>
> 11) How do I reprogram a CRP enabled part?
>
> Erase all user sectors in one go via ISP. You can reprogram it
after
> a
> power cycle.
> Please note that the protected code vanished and was not visible
to a
> "spy" or "praying eyes".
>
> --------
> 12) Can JTAG be or remain enabled through clocking the CPU slowly
> and JTAG fast during the initial time window after reset where
JTAG
> is enabled?
>
> No, the clock for JTAG and the CPU are syncronized on these
devices.
> There are not enough JTAG clocks to control the CPU before the
JTAG
> gets disabled by the bootloader software.
>
> 13) Can the bootloader update be performed when CRP is enabled?
>
> No, the bootloader update uses commands like copy RAM to Flash
which
> is disabled when CRP is enabled. The message will be that there is
> no communication possible. > Comment to Robert Adsets posting:
> It is correct that support efforts would be significantly higher
> with published source code of the bootloader and let me add
without
> adding any benefits to you, our customers.
>
Reply by ●January 5, 20062006-01-05
It is so very easy to make you happy Richard :)
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Thank you!
>
> Richard
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> Thank you!
>
> Richard
Reply by ●January 5, 20062006-01-05
Many thanks to the summary and conclusion, and clarifications
showing "no simple way of cracking the read protection."
I would suggest may be portion of bootloader should be locked
up permanently, such that no user could reverse/disassembly
the bootloader completely. =>
- Break down bootloader flash into 2 segments/sectors,
- After power up, ARM7 runs on segment #0, immediately
disables JTAG
- After doing all the secret chip initialization, disabling of
some chip features, switch to segment #1
- Bootloader Disables segment #0, this is sticky disabling and
could only be clear by reset or WDT
- Sticky bit also disables bootloader update, fulfilling some
high expectation engineers bootloader will NEVER be corrupted
- Enable JTAG now if needed to, proceed to normal boot
loader functions...
- All user functions like flash programming are in segment #1
Nobody could predict what hackers will do after disassembly the
boot loader, why not lock portion of it up permanently. Only
drawback of user like us can no longer upgrade bootloader easily.
===================================
Secondly, may be good to build in a very very simple MMU on LPFQ144
in future...
- All flash+ram+bootloader inside chip are supervisor mode
- whatever outside chip are user mode
- I/O are not protected.
(better if it can be a pointer dividing internal flash memory into 2)
It will be good for:
- Someone to come out with a very nice LPC2xxx educational kit
- Some "Open Platform" oem board builder.
Regards --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
wrote:
>
> For reference the posting we did on Dec 22
> ----
> 1) Am I right in assuming LPC2000 CRP is a software fence
implemented
> in the supplied boot loader code?
>
> Partially. It is a combination of Hardware and Software supplied in
> the bootloader code. Application running in micro has full access
to
> the entire memory space.
>
> 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.
>
> 3) How is Bootloader programmed for the first time?
>
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
>
> 4) CRP in devices with internal flash and external bus.
>
> The bootloader prevents external boot if CRP is enabled. User
> Application residing in on-chip flash which needs to be protected
> should not execute code from external memory.
>
> 5) Can bootloader write/erase itself?
>
> No.
>
> 6) Can bootloader get corrupted?
>
> Very unlikely if IAP/ISP calls are used for flash programming.
> Very likely if Flash programming interface registers are directly
> accessed for flash programming.
>
> 7) Can Philips comment if Quick-Pulse parallel programming can
void
> CRP?
>
> First of all there is no Quick-Pulse parallel programming option
for
> ARM based micros. We are sorry for not making clear what is meant
by
> "Parallel Programming" for ARM based micros. Parallel programming
for
> ARM based micros just means that the device can be mass programmed
in
> a commercial programmer. Parallel programmers still use JTAG and/or
> ISP and go through the bootloader IAP routines to program the on-
chip
> flash. It does not matter how a part is programmed. If CRP is
enabled
> it will remain enabled once the part is programmed. If CRP is
enabled
> a parallel programmer can't access the flash unless it erases the
> whole flash. Same applies to the ISP utility and JTAG based
> debuggers.
>
> 8) Is CRP option available for 2104/05/06?
>
> Not yet.
>
> 9) Devices with external memory bus can be forced to boot from
> external memory?
>
> ONLY if CRP is NOT enabled or NO internal flash present. Also see
> (4).
>
> 10) Can I tell client Philips has confirmed CRP is not voided by
PP?
>
> Yes. Also see (7).
>
> 11) How do I reprogram a CRP enabled part?
>
> Erase all user sectors in one go via ISP. You can reprogram it
after
> a
> power cycle.
> Please note that the protected code vanished and was not visible
to a
> "spy" or "praying eyes".
>
> --------
> 12) Can JTAG be or remain enabled through clocking the CPU slowly
> and JTAG fast during the initial time window after reset where
JTAG
> is enabled?
>
> No, the clock for JTAG and the CPU are syncronized on these
devices.
> There are not enough JTAG clocks to control the CPU before the
JTAG
> gets disabled by the bootloader software.
>
> 13) Can the bootloader update be performed when CRP is enabled?
>
> No, the bootloader update uses commands like copy RAM to Flash
which
> is disabled when CRP is enabled. The message will be that there is
> no communication possible. > Comment to Robert Adsets posting:
> It is correct that support efforts would be significantly higher
> with published source code of the bootloader and let me add
without
> adding any benefits to you, our customers.
>
showing "no simple way of cracking the read protection."
I would suggest may be portion of bootloader should be locked
up permanently, such that no user could reverse/disassembly
the bootloader completely. =>
- Break down bootloader flash into 2 segments/sectors,
- After power up, ARM7 runs on segment #0, immediately
disables JTAG
- After doing all the secret chip initialization, disabling of
some chip features, switch to segment #1
- Bootloader Disables segment #0, this is sticky disabling and
could only be clear by reset or WDT
- Sticky bit also disables bootloader update, fulfilling some
high expectation engineers bootloader will NEVER be corrupted
- Enable JTAG now if needed to, proceed to normal boot
loader functions...
- All user functions like flash programming are in segment #1
Nobody could predict what hackers will do after disassembly the
boot loader, why not lock portion of it up permanently. Only
drawback of user like us can no longer upgrade bootloader easily.
===================================
Secondly, may be good to build in a very very simple MMU on LPFQ144
in future...
- All flash+ram+bootloader inside chip are supervisor mode
- whatever outside chip are user mode
- I/O are not protected.
(better if it can be a pointer dividing internal flash memory into 2)
It will be good for:
- Someone to come out with a very nice LPC2xxx educational kit
- Some "Open Platform" oem board builder.
Regards --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
wrote:
>
> For reference the posting we did on Dec 22
> ----
> 1) Am I right in assuming LPC2000 CRP is a software fence
implemented
> in the supplied boot loader code?
>
> Partially. It is a combination of Hardware and Software supplied in
> the bootloader code. Application running in micro has full access
to
> the entire memory space.
>
> 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.
>
> 3) How is Bootloader programmed for the first time?
>
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
>
> 4) CRP in devices with internal flash and external bus.
>
> The bootloader prevents external boot if CRP is enabled. User
> Application residing in on-chip flash which needs to be protected
> should not execute code from external memory.
>
> 5) Can bootloader write/erase itself?
>
> No.
>
> 6) Can bootloader get corrupted?
>
> Very unlikely if IAP/ISP calls are used for flash programming.
> Very likely if Flash programming interface registers are directly
> accessed for flash programming.
>
> 7) Can Philips comment if Quick-Pulse parallel programming can
void
> CRP?
>
> First of all there is no Quick-Pulse parallel programming option
for
> ARM based micros. We are sorry for not making clear what is meant
by
> "Parallel Programming" for ARM based micros. Parallel programming
for
> ARM based micros just means that the device can be mass programmed
in
> a commercial programmer. Parallel programmers still use JTAG and/or
> ISP and go through the bootloader IAP routines to program the on-
chip
> flash. It does not matter how a part is programmed. If CRP is
enabled
> it will remain enabled once the part is programmed. If CRP is
enabled
> a parallel programmer can't access the flash unless it erases the
> whole flash. Same applies to the ISP utility and JTAG based
> debuggers.
>
> 8) Is CRP option available for 2104/05/06?
>
> Not yet.
>
> 9) Devices with external memory bus can be forced to boot from
> external memory?
>
> ONLY if CRP is NOT enabled or NO internal flash present. Also see
> (4).
>
> 10) Can I tell client Philips has confirmed CRP is not voided by
PP?
>
> Yes. Also see (7).
>
> 11) How do I reprogram a CRP enabled part?
>
> Erase all user sectors in one go via ISP. You can reprogram it
after
> a
> power cycle.
> Please note that the protected code vanished and was not visible
to a
> "spy" or "praying eyes".
>
> --------
> 12) Can JTAG be or remain enabled through clocking the CPU slowly
> and JTAG fast during the initial time window after reset where
JTAG
> is enabled?
>
> No, the clock for JTAG and the CPU are syncronized on these
devices.
> There are not enough JTAG clocks to control the CPU before the
JTAG
> gets disabled by the bootloader software.
>
> 13) Can the bootloader update be performed when CRP is enabled?
>
> No, the bootloader update uses commands like copy RAM to Flash
which
> is disabled when CRP is enabled. The message will be that there is
> no communication possible. > Comment to Robert Adsets posting:
> It is correct that support efforts would be significantly higher
> with published source code of the bootloader and let me add
without
> adding any benefits to you, our customers.
>
Reply by ●January 6, 20062006-01-06
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> It is so very easy to make you happy Richard :)
Yes. My applications are trivial, my knowledge nearly non-existent
and security is no concern. I'm just building toys, really.
I am more than willing to accept what is stated in the datasheet and,
as I read it, CRP works. Philips says it does, they stand behind
their products; therefore, it is settled. In my mind...
I would still be 'curious', but not concerned, about the 'T' command.
Richard
>
> It is so very easy to make you happy Richard :)
Yes. My applications are trivial, my knowledge nearly non-existent
and security is no concern. I'm just building toys, really.
I am more than willing to accept what is stated in the datasheet and,
as I read it, CRP works. Philips says it does, they stand behind
their products; therefore, it is settled. In my mind...
I would still be 'curious', but not concerned, about the 'T' command.
Richard
Reply by ●January 6, 20062006-01-06
OK, Me too also accept and trust what Philips says. I'm happy
with the read protection mechanism what Philips had implemented
so far.
There will always be some very unexpected way of hacking the chip.
May be by:
- clock the first few instructions at >100Mhz (after reset) such
that the first few instruction for disabling the JTAG are
"screw up" and breaking the CRP.
But who cares...
Somebody please provide some proven way of cracking the chip
else this thread should be concluded.
Regards
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
> >
> > It is so very easy to make you happy Richard :)
>
> Yes. My applications are trivial, my knowledge nearly non-
existent
> and security is no concern. I'm just building toys, really.
>
> I am more than willing to accept what is stated in the datasheet
and,
> as I read it, CRP works. Philips says it does, they stand behind
> their products; therefore, it is settled. In my mind...
>
> I would still be 'curious', but not concerned, about the 'T'
command.
>
> Richard
>
with the read protection mechanism what Philips had implemented
so far.
There will always be some very unexpected way of hacking the chip.
May be by:
- clock the first few instructions at >100Mhz (after reset) such
that the first few instruction for disabling the JTAG are
"screw up" and breaking the CRP.
But who cares...
Somebody please provide some proven way of cracking the chip
else this thread should be concluded.
Regards
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
> --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
> >
> > It is so very easy to make you happy Richard :)
>
> Yes. My applications are trivial, my knowledge nearly non-
existent
> and security is no concern. I'm just building toys, really.
>
> I am more than willing to accept what is stated in the datasheet
and,
> as I read it, CRP works. Philips says it does, they stand behind
> their products; therefore, it is settled. In my mind...
>
> I would still be 'curious', but not concerned, about the 'T'
command.
>
> Richard
>
Reply by ●January 6, 20062006-01-06
I dont know why are so eager to quench this discussion just because
you have no (or very simplistic) requirements in relation to code
security. It is perfectly alright for you to be not interested.
There are many people here, including myself, who are concerned (to
say the least) as to how safe IP that is loaded onto on-chip flash is
when the part is in thehands of the those who know what they are doing.
The ball is now in Philips' court. Give them time to respond
credibly, or not at all as they see fit. We all know how to make
inferences.
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> Many thanks to the summary and conclusion, and clarifications
> showing "no simple way of cracking the read protection."
> ...
> Somebody please provide some proven way of cracking the chip
> else this thread should be concluded.
you have no (or very simplistic) requirements in relation to code
security. It is perfectly alright for you to be not interested.
There are many people here, including myself, who are concerned (to
say the least) as to how safe IP that is loaded onto on-chip flash is
when the part is in thehands of the those who know what they are doing.
The ball is now in Philips' court. Give them time to respond
credibly, or not at all as they see fit. We all know how to make
inferences.
--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> Many thanks to the summary and conclusion, and clarifications
> showing "no simple way of cracking the read protection."
> ...
> Somebody please provide some proven way of cracking the chip
> else this thread should be concluded.
Reply by ●January 6, 20062006-01-06
--- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...>
wrote:
>
> I dont know why are so eager to quench this discussion just because
> you have no (or very simplistic) requirements in relation to code
> security. It is perfectly alright for you to be not interested.
>
> There are many people here, including myself, who are concerned (to
> say the least) as to how safe IP that is loaded onto on-chip flash
is
> when the part is in thehands of the those who know what they are
doing.
>
> The ball is now in Philips' court. Give them time to respond
> credibly, or not at all as they see fit. We all know how to make
> inferences.
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > Many thanks to the summary and conclusion, and clarifications
> > showing "no simple way of cracking the read protection."
> > ...
> > Somebody please provide some proven way of cracking the chip
> > else this thread should be concluded.
But, they have answered. Again, today. They posted replies to each
and every issue. The only outstanding item, and it wasn't on the
list, is the T command.
Each and every item, answered. And, no, they're not going to post
the source. And they don't recommend replacing the boot code for a
couple of pretty good reasons.
To continiue badgering over "it isn't good enough because it isn't
hardware only" seems to me to be questioning the skills of the
engineers and the integrity of the company. I am not willing to do
either.
The questions were answered. Except for the T command. And I am
willing to believe that a) the engineers know it is there and b) it
doesn't provide a way to get around what they have designed.
If I needed security and I wasn't convinced after the answers
provided that the system was satisfactory, I would just buy another
product. No big deal, there are dozens of competing devices.
Richard
>
wrote:
>
> I dont know why are so eager to quench this discussion just because
> you have no (or very simplistic) requirements in relation to code
> security. It is perfectly alright for you to be not interested.
>
> There are many people here, including myself, who are concerned (to
> say the least) as to how safe IP that is loaded onto on-chip flash
is
> when the part is in thehands of the those who know what they are
doing.
>
> The ball is now in Philips' court. Give them time to respond
> credibly, or not at all as they see fit. We all know how to make
> inferences.
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote:
> > Many thanks to the summary and conclusion, and clarifications
> > showing "no simple way of cracking the read protection."
> > ...
> > Somebody please provide some proven way of cracking the chip
> > else this thread should be concluded.
But, they have answered. Again, today. They posted replies to each
and every issue. The only outstanding item, and it wasn't on the
list, is the T command.
Each and every item, answered. And, no, they're not going to post
the source. And they don't recommend replacing the boot code for a
couple of pretty good reasons.
To continiue badgering over "it isn't good enough because it isn't
hardware only" seems to me to be questioning the skills of the
engineers and the integrity of the company. I am not willing to do
either.
The questions were answered. Except for the T command. And I am
willing to believe that a) the engineers know it is there and b) it
doesn't provide a way to get around what they have designed.
If I needed security and I wasn't convinced after the answers
provided that the system was satisfactory, I would just buy another
product. No big deal, there are dozens of competing devices.
Richard
>
Reply by ●January 6, 20062006-01-06
Badgering? With all due respect, let Philips do their job as they see
fit. The forum could do less with your brown nosing.
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> To continiue badgering over "it isn't good enough because it isn't
> hardware only" seems to me to be questioning the skills of the
> engineers and the integrity of the company. I am not willing to do
> either.
fit. The forum could do less with your brown nosing.
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
> To continiue badgering over "it isn't good enough because it isn't
> hardware only" seems to me to be questioning the skills of the
> engineers and the integrity of the company. I am not willing to do
> either.
Reply by ●January 6, 20062006-01-06
>The forum could do less with your brown nosing.
>
Well, that would imply that I wanted something from Philips. I
don't. My total demand for silicon won't exceed 3 or 4 devices over
the forseeable future. I don't work, I don't consult and I never
will again. There is nothing I want that I can't buy.
So, brown nosing isn't it.
I truly believe the questions have been asked and that the answers
are satisfactory. I believe the datasheets and I believe the
engineers know how to design a chip. I also believe that there are
two choices re: the devices: accept the answers and buy them or
reject the answers and buy something else. I don't see a 3d
solution because I doubt that Philips is going to change the
technology based on this forum.
Richard
>
Well, that would imply that I wanted something from Philips. I
don't. My total demand for silicon won't exceed 3 or 4 devices over
the forseeable future. I don't work, I don't consult and I never
will again. There is nothing I want that I can't buy.
So, brown nosing isn't it.
I truly believe the questions have been asked and that the answers
are satisfactory. I believe the datasheets and I believe the
engineers know how to design a chip. I also believe that there are
two choices re: the devices: accept the answers and buy them or
reject the answers and buy something else. I don't see a 3d
solution because I doubt that Philips is going to change the
technology based on this forum.
Richard
