Getting started with ARM processors - recommendations

On 31/10/10 11:31, Simon Clubley wrote:
> On 2010-10-30, Mel<mwilson@the-wire.com>  wrote:
>> David Brown wrote:
>>
>>> But MIPS has been around for decades - it's older than ARM, and
>>> certainly much more established than the modern popular ARM cores.
>>
>> And getting a lot of use in China as a mainstream processor -- not so much
>> embedded or microcontroller.  See Dragon Chip.
>>
>
> Before these and similar processors are used in products, what tests do
> companies perform to make sure that some nasty logic surprises have not
> been left in them ?
>
> I have known for some time about the possibility of hardware based spying
> instead of software based spying, but have not really thought about it
> been mainstream yet.
>
> However, Scientific American ran a article on this a couple of months ago
> and it made me think about how widespread concerns about this must be if
> it's considered newsworthy enough for a international science magazine to
> run a full article on it.
>
> In other words, is it possible there are some nasty surprises just waiting
> for us in the existing hardware on our desks, in our server rooms and in
> our mobile devices ?
>

I gave up my Scientific American subscription a few years ago, partly 
because of that sort of sensationalist nonsense (I remember the article 
in question).  That is not to say that hardware-based trojans are not 
impossible - just that they are very unlikely, and the article was very 
unrealistic.  It goes along with their fondness for predictions like 
"scientists have now made a one-bit half-adder quantum computer that 
runs at -260 C with a record uptime of 3 ms - in a few years, we'll all 
have quantum supercomputers on our desks!"


Before worrying too much about hardware spying, think about who would 
/want/ to do it, who /could/ do it, what it would cost to do it, and 
what it would cost to achieve the same ends by different means.

The Dragon devices are made to be cheap, aimed at mass-produced embedded 
systems.  The cost of adding the large amounts of software in every 
Dragon chip sold, just on the off-chance that it gets used in something 
with useful data, is a massive investment with very little chance of a 
payback.

Also consider the reputation of software writers.  Are the spyware 
writers going to get it right first time, so that the code can be hidden 
inside the logic of the chip?  You can't update this later - that relies 
on co-operation from the outside (such as the microcode patches for 
Intel processors).


All in all, it is /far/ cheaper and easier to write a traditional 
windows virus or worm to do the same job, or to rely on the standard 
three B's espionage.

On 31/10/10 02:04, rickman wrote:
> On Oct 30, 8:58 am, David Brown
> <david.br...@removethisbit.hesbynett.no>  wrote:
>> On 29/10/10 22:59, rickman wrote:
>>
>>
>>
>>> On Oct 29, 4:07 am, David Brown<da...@westcontrol.removethisbit.com>
>>> wrote:
>>>> On 29/10/2010 02:36, hamilton wrote:
>>
>>>>> On 10/28/2010 3:18 PM, Ulf Samuelsson wrote:
>>>>>> The AVR32 is more in the Cortex-M4 class, than the M3.
>>
>>>>> How does the AVR32 compare to the MIPS processors ??
>>
>>>> It compares with difficulty.
>>
>>>> MIPS is a family of licensable cores covering a huge spread.  The
>>>> microMIPS cores will be probably be smaller and lower power than an
>>>> AVR32 (though it will depend on the implementation), while the biggest
>>>> cores are orders of magnitude faster.  "MIPS" is more like "ARM" in this
>>>> respect.
>>
>>> I guess you can't knock the MIPS parts for being a poor step child
>>> like the AVR32.  It may not be available from more than one maker as a
>>
>> I don't know quite what you mean about the AVR32 being a "poor step
>> child" - it's an independent modern 32-bit processor architecture with
>> all the advantages and disadvantages that brings.
>
> Yes, poor step child as in not getting all the same stuff that the
> others get... like a huge following, open source tools (not sure about
> that one), but the main thing is that it is 100% sole sourced.  If
> Atmel doesn't make the flavor you need, go pound sand.  With ARM you
> can go to another vendor to find just the mix that suits your app
> best.
>

AVR32 had reasonably wide support in open source, but it faded a bit 
when they dropped their AP7000 line (which was designed to run Linux). 
Still, there is solid gcc support, although I don't think it is in the 
mainline FSF tree.

MIPS is a fully supported architecture in the open source community, 
roughly equal to PPC (and therefore only a little behind ARM, but 
noticeably behind x86 and amd64).

>
>> But MIPS has been around for decades - it's older than ARM, and
>> certainly much more established than the modern popular ARM cores.  MIPS
>> also have more experience at the higher end - they had 64-bit cores long
>> before the amd64 architecture (or even Intel's disastrous IA-64), and
>> SMP is standard stuff for MIPS.  But they haven't had so much at the low
>> end until recently - the microMIPS extensions are quite new.  And they
>> have always targeted a few big customers rather than being used by the
>> "little people".
>
> I got no problem with MIPS.  But if there is only one supplier of a
> MIPS MCU, it has the same limitation that AVR32 has.
>

There are lots of suppliers of MIPS chips, but currently only one 
(AFAIK) that sells ready-made devices to small buyers.


Remember that although there are a lot of companies producing ARM 
microcontrollers, none of them are close to drop-in replacements for 
their competitors.

>
>>> standard part, it does have a huge base of users, etc.  So it is not
>>> likely to go away... at least not as a core.  Has Microchip been
>>> selling these chips in high enough volume to assure that they will
>>> continue to make them for years to come?  That would be my biggest
>>> concern at this point.
>>
>> MIPS is a core that will never go away - it is far too established for
>> that.  People who want a CPU core for their chips that will be used for
>> the next 20 years pick either MIPS or PPC cores.
>
> Isn't that what I said, it is not likely to go away... as a core.  As
> an MCU it may or may not make the cut.  Why do you think ARM is not
> good for the next 20 years?  They are running away with the MCU market
> at this point.
>

I don't necessarily mean that ARM is not a good choice for these 
devices.  But the market for cores for long-term devices is not the same 
as the market for MCUs.  While a certain proportion of MCUs need to be 
stable for such long terms, a large proportion of embedded designs are 
only produced for a few years before they are updated or upgraded with 
new features and faster processors.  And by volume produced, most 
designs are probably produced for well under a year.

If you are making systems that you expect to last for decades, and that 
you want to produce for decades, you are looking for long-term stability 
of the company and its designs.  A company that is know for rapid growth 
and lots of flashy new designs is not the stability you are looking for. 
  You don't want to hear that the core you licensed a few years ago has 
been obsoleted for a newer faster version - you want to hear that it is 
still fully supported.

On 31/10/10 10:55, Oliver Betz wrote:
> David Brown wrote:
>
> [...]
>
>> MIPS is a core that will never go away - it is far too established for
>> that.  People who want a CPU core for their chips that will be used for
>> the next 20 years pick either MIPS or PPC cores.
>
> M68K should be mentioned.
>
> Oliver

OK, the M68K can be mentioned too.  I like the M68K - I think it's a 
very nice architecture.  And in its current ColdFire manifestation it 
turns up more in ASICs you've never heard of (and now FPGA designs too) 
than in microcontroller's bought from Freescale.  So it is in a similar 
category.

Paul E. Bennett wrote:
> Simon Clubley wrote:
>> Before these and similar processors are used in products, what tests do
>> companies perform to make sure that some nasty logic surprises have not
>> been left in them ?
> 
> Apart from incorrect maths functions and inverted logical operations?
>  
>> I have known for some time about the possibility of hardware based spying
>> instead of software based spying, but have not really thought about it
>> been mainstream yet.
> 
> Whether or not it is mainstream yet might depend on the numbers and types
> of devices we are speaking about.

Intel recently bought McAfee.  Imaginably this could get them some talent to 
use for Trusted Computing Platform implementation, and that could be either 
the cure or the disease here, depending on which side one thinks one is on.

	Mel.

On Sun, 31 Oct 2010 16:11:51 +0100, David Brown
<david.brown@removethisbit.hesbynett.no> wrote:

>All in all, it is /far/ cheaper and easier to write a traditional 
>windows virus or worm to do the same job, or to rely on the standard 
>three B's espionage.

Babes, booze, and bucks?

-- 
Rich Webb     Norfolk, VA

On 31/10/10 17:53, Rich Webb wrote:
> On Sun, 31 Oct 2010 16:11:51 +0100, David Brown
> <david.brown@removethisbit.hesbynett.no>  wrote:
>
>> All in all, it is /far/ cheaper and easier to write a traditional
>> windows virus or worm to do the same job, or to rely on the standard
>> three B's espionage.
>
> Babes, booze, and bucks?
>

I thought it refered to bribery, blackmail and burglary, but your 
choices are probably equally effective.

On Sun, 31 Oct 2010 16:11:51 +0100, David Brown wrote:

> The Dragon devices are made to be cheap, aimed at mass-produced embedded 
> systems.  The cost of adding the large amounts of software in every 
> Dragon chip sold, just on the off-chance that it gets used in something 
> with useful data, is a massive investment with very little chance of a 
> payback.

If I was going to implement hardware spying, I wouldn't attempt to embed
specific software on the chip. Too hard to get right and too easy to find.
Instead, I'd try to introduce an attack vector which would allow arbitrary
code to be injected at a later date. Something subtle enough that it could
be dismissed as a bug if it was discovered.

Simon Clubley wrote:


> Very hidden and your tests as described above would be unlikely to
> identify such malicious logic.
> 
> Normally I have associated such threats with things like trojan network
> cards whose boot code executes during system startup. However, the
> Scientific American issue was primarily concerned with the compromise of
> the processor itself in that additional logic could be designed into the
> processor itself. (The basic argument is that it is impossible in current
> processors, due to their complexity, to test _all_ possible logic paths.)

The network card boot-code example is more plausible as an attack strategy. 
That I suppose can be a scary prospect. I have never been tempted to the 
very complex processors for my projects, much preferring the simpler ones 
(stack machines and the like). So far I have had no problems ensuring that 
the processors perform as per the data-sheet or finding deviations from it. 
I'd agree that some of the more complex processors would take an inordinate 
amount of time to check out.
 
> Such a device would appear to operate normally until a trigger sequence
> was executed. If this is a viable threat, then it takes the issue of
> hardware based spying to a whole new level. What I don't know is if this
> _is_ a viable threat or not.
> 
> The one thing I do take issue with in the article is the article's focus
> on a date and time trigger as unless that functionality is built into the
> processor itself, it would mean that the malicious logic would need to
> know how to access that information from across the system bus.
> 
> This doesn't change the fact that such malicious logic could be triggered
> in many other ways such as, for example, by a opcode sequence executed by
> normal unprivileged user mode code.

So you think it might just be sensationalism then?

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On Oct 31, 11:31=A0am, David Brown
<david.br...@removethisbit.hesbynett.no> wrote:
> On 31/10/10 02:04, rickman wrote:
>
> > On Oct 30, 8:58 am, David Brown
> > <david.br...@removethisbit.hesbynett.no> =A0wrote:
> >> On 29/10/10 22:59, rickman wrote:
> >>> I guess you can't knock the MIPS parts for being a poor step child
> >>> like the AVR32. =A0It may not be available from more than one maker a=
s a
>
> >> I don't know quite what you mean about the AVR32 being a "poor step
> >> child" - it's an independent modern 32-bit processor architecture with
> >> all the advantages and disadvantages that brings.
>
> > Yes, poor step child as in not getting all the same stuff that the
> > others get... like a huge following, open source tools (not sure about
> > that one), but the main thing is that it is 100% sole sourced. =A0If
> > Atmel doesn't make the flavor you need, go pound sand. =A0With ARM you
> > can go to another vendor to find just the mix that suits your app
> > best.
>
> AVR32 had reasonably wide support in open source, but it faded a bit
> when they dropped their AP7000 line (which was designed to run Linux).
> Still, there is solid gcc support, although I don't think it is in the
> mainline FSF tree.
>
> MIPS is a fully supported architecture in the open source community,
> roughly equal to PPC (and therefore only a little behind ARM, but
> noticeably behind x86 and amd64).
>
> >> But MIPS has been around for decades - it's older than ARM, and
> >> certainly much more established than the modern popular ARM cores. =A0=
MIPS
> >> also have more experience at the higher end - they had 64-bit cores lo=
ng
> >> before the amd64 architecture (or even Intel's disastrous IA-64), and
> >> SMP is standard stuff for MIPS. =A0But they haven't had so much at the=
 low
> >> end until recently - the microMIPS extensions are quite new. =A0And th=
ey
> >> have always targeted a few big customers rather than being used by the
> >> "little people".
>
> > I got no problem with MIPS. =A0But if there is only one supplier of a
> > MIPS MCU, it has the same limitation that AVR32 has.
>
> There are lots of suppliers of MIPS chips, but currently only one
> (AFAIK) that sells ready-made devices to small buyers.

I didn't say anything about ASICS.  I am talking about using MCUs.


> Remember that although there are a lot of companies producing ARM
> microcontrollers, none of them are close to drop-in replacements for
> their competitors.

I didn't say anything about drop in replacements.  I am talking about
finding an MCU that suits your needs.  With just a single supplier you
will likely need to make more compromises than if you have half a
dozen or more to choose from.  Yes, it is not trivial to change from
one supplier to another, but it is even more work to change CPUs as
well.


> >> MIPS is a core that will never go away - it is far too established for
> >> that. =A0People who want a CPU core for their chips that will be used =
for
> >> the next 20 years pick either MIPS or PPC cores.
>
> > Isn't that what I said, it is not likely to go away... as a core. =A0As
> > an MCU it may or may not make the cut. =A0Why do you think ARM is not
> > good for the next 20 years? =A0They are running away with the MCU marke=
t
> > at this point.
>
> I don't necessarily mean that ARM is not a good choice for these
> devices. =A0But the market for cores for long-term devices is not the sam=
e
> as the market for MCUs. =A0While a certain proportion of MCUs need to be
> stable for such long terms, a large proportion of embedded designs are
> only produced for a few years before they are updated or upgraded with
> new features and faster processors. =A0And by volume produced, most
> designs are probably produced for well under a year.

I don't know what you mean by "a few years".  I am happy with a given
part being produced for five years after I design it in.  So far I've
not found an ARM MCU that wasn't produced for at least five years.  In
fact, I've seen few dropped at all.


> If you are making systems that you expect to last for decades, and that
> you want to produce for decades, you are looking for long-term stability
> of the company and its designs. =A0A company that is know for rapid growt=
h
> and lots of flashy new designs is not the stability you are looking for.
> =A0 You don't want to hear that the core you licensed a few years ago has
> been obsoleted for a newer faster version - you want to hear that it is
> still fully supported.

Sure if you want to make the same system with the same parts for
"decades", then you have very special and unusual needs.  You are also
a very, very small segment of the market and most companies ignore
you.  But I'm not talking about ASIC cores at all.  If that is what
you are talking about, then we are having two separate conversations.

Rick

On 01/11/10 05:33, rickman wrote:
> On Oct 31, 11:31 am, David Brown
> <david.br...@removethisbit.hesbynett.no>  wrote:
>> On 31/10/10 02:04, rickman wrote:
>>
>>> On Oct 30, 8:58 am, David Brown
>>> <david.br...@removethisbit.hesbynett.no>    wrote:
>>>> On 29/10/10 22:59, rickman wrote:
>>>>> I guess you can't knock the MIPS parts for being a poor step child
>>>>> like the AVR32.  It may not be available from more than one maker as a
>>
>>>> I don't know quite what you mean about the AVR32 being a "poor step
>>>> child" - it's an independent modern 32-bit processor architecture with
>>>> all the advantages and disadvantages that brings.
>>
>>> Yes, poor step child as in not getting all the same stuff that the
>>> others get... like a huge following, open source tools (not sure about
>>> that one), but the main thing is that it is 100% sole sourced.  If
>>> Atmel doesn't make the flavor you need, go pound sand.  With ARM you
>>> can go to another vendor to find just the mix that suits your app
>>> best.
>>
>> AVR32 had reasonably wide support in open source, but it faded a bit
>> when they dropped their AP7000 line (which was designed to run Linux).
>> Still, there is solid gcc support, although I don't think it is in the
>> mainline FSF tree.
>>
>> MIPS is a fully supported architecture in the open source community,
>> roughly equal to PPC (and therefore only a little behind ARM, but
>> noticeably behind x86 and amd64).
>>
>>>> But MIPS has been around for decades - it's older than ARM, and
>>>> certainly much more established than the modern popular ARM cores.  MIPS
>>>> also have more experience at the higher end - they had 64-bit cores long
>>>> before the amd64 architecture (or even Intel's disastrous IA-64), and
>>>> SMP is standard stuff for MIPS.  But they haven't had so much at the low
>>>> end until recently - the microMIPS extensions are quite new.  And they
>>>> have always targeted a few big customers rather than being used by the
>>>> "little people".
>>
>>> I got no problem with MIPS.  But if there is only one supplier of a
>>> MIPS MCU, it has the same limitation that AVR32 has.
>>
>> There are lots of suppliers of MIPS chips, but currently only one
>> (AFAIK) that sells ready-made devices to small buyers.
>
> I didn't say anything about ASICS.  I am talking about using MCUs.
>
>
>> Remember that although there are a lot of companies producing ARM
>> microcontrollers, none of them are close to drop-in replacements for
>> their competitors.
>
> I didn't say anything about drop in replacements.  I am talking about
> finding an MCU that suits your needs.  With just a single supplier you
> will likely need to make more compromises than if you have half a
> dozen or more to choose from.  Yes, it is not trivial to change from
> one supplier to another, but it is even more work to change CPUs as
> well.
>

OK, we were talking about slightly different markets.  Given that, I 
agree with you.  Clearly, the more you have to change, the more effort 
it will typically be.

Many people do seem to think that since there are several companies 
producing ARM devices, then there are drop-in second source 
replacements, which is why I pointed it out.

>
>>>> MIPS is a core that will never go away - it is far too established for
>>>> that.  People who want a CPU core for their chips that will be used for
>>>> the next 20 years pick either MIPS or PPC cores.
>>
>>> Isn't that what I said, it is not likely to go away... as a core.  As
>>> an MCU it may or may not make the cut.  Why do you think ARM is not
>>> good for the next 20 years?  They are running away with the MCU market
>>> at this point.
>>
>> I don't necessarily mean that ARM is not a good choice for these
>> devices.  But the market for cores for long-term devices is not the same
>> as the market for MCUs.  While a certain proportion of MCUs need to be
>> stable for such long terms, a large proportion of embedded designs are
>> only produced for a few years before they are updated or upgraded with
>> new features and faster processors.  And by volume produced, most
>> designs are probably produced for well under a year.
>
> I don't know what you mean by "a few years".  I am happy with a given
> part being produced for five years after I design it in.  So far I've
> not found an ARM MCU that wasn't produced for at least five years.  In
> fact, I've seen few dropped at all.
>
>
>> If you are making systems that you expect to last for decades, and that
>> you want to produce for decades, you are looking for long-term stability
>> of the company and its designs.  A company that is know for rapid growth
>> and lots of flashy new designs is not the stability you are looking for.
>>    You don't want to hear that the core you licensed a few years ago has
>> been obsoleted for a newer faster version - you want to hear that it is
>> still fully supported.
>
> Sure if you want to make the same system with the same parts for
> "decades", then you have very special and unusual needs.  You are also
> a very, very small segment of the market and most companies ignore
> you.  But I'm not talking about ASIC cores at all.  If that is what
> you are talking about, then we are having two separate conversations.
>
> Rick

I think we are having at least slightly different conversations.  You 
are viewing things from the ARM target market, while I had joined this 
part of the thread by discussing MIPS and their target market - and 
these are different (though partially overlapping) markets.  I think we 
would agree on most points, if we were saying them in the same context!