Getting started with ARM processors - recommendations

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.

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".

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.

I have no idea how popular the PIC32 is. Microchip's handling of "their" PIC32 compiler puts me off it.

Reply to
David Brown
Loading thread data ...

And getting a lot of use in China as a mainstream processor -- not so much embedded or microcontroller. See Dragon Chip.

Mel.

Reply to
Mel

Google found all sorts of interesting things.

1GHz Chinese Dragon chip Comparable to 2GHz Pentium 4

formatting link

Reply to
hamilton

this

a

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.

S
w

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.

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.

Rick

Reply to
rickman
[...]

M68K should be mentioned.

Oliver

--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

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 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

I notice I wrongly cut out embedded systems from that sentence, which is annoying given that this _is_ comp.arch.embedded. :-)

Given the traditional lax security found on many network connected embedded systems, the possibility of hardware surprises in those systems is of course a major concern.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

Of course, but that's not exclusive to China.

-a

Reply to
Anders.Montonen
[%X]

Apart from incorrect maths functions and inverted logical operations?

Whether or not it is mainstream yet might depend on the numbers and types of devices we are speaking about.

The question would be "how many organisations need to be either so lax or complicit in ensuring that those who wanted to steal information could succeed?".

In dealing with components from suppliers I obtain certificates of conformity to the data-sheet. With more complex logic devices, I run tests on a few sample components to the extent of satisfying myself that the devices are as described in the data-sheet. Not having seen that issue of Scientific American how hidden can such logic be?

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

Yes. The focus here is on processors with additional logic designed to remain hidden but with the ability to compromise system security at some future point in time upon some trigger occuring.

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.)

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.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

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.

Reply to
David Brown

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).

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.

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.

Reply to
David Brown

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.

Reply to
David Brown

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.

Reply to
Mel

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.

Reply to
Nobody

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.

So you think it might just be sensationalism then?

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

s a

MIPS

ng

low

ey

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

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.

for

t
e

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.

h

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

Reply to
rickman

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.

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!

Reply to
David Brown

Yes and no.

There's clearly a major element of sensationalism, but there's also a real potential issue which has been identified as well. What I don't have a feeling for is where viable reality becomes sensationalism.

IMHO, the date/time trigger bit is mostly sensationalism and would be more in place in a tabloid than a science magazine. A potentially hostile state player is not going to have countless devices all suddenly go rogue at some future fixed point in time. This would be a viable terrorist goal, but having terrorists secretly modify chip designs is not something I worry about. :-)

OTOH, a potentially hostile state player been able to covertly access systems on demand in order to carry out espionage and disrupt systems in a crisis is a very realistic requirement for them. But then are they just going to modify some software somewhere or is there a real practical advantage to been able to spy at hardware level as well ?

One could argue the hardware based approach allows malicious logic to be more easily hidden, but are there less risky ways of achieving your goals ?

If there is a real advantage, is that advantage sufficient for the risks and resources involved in taking a hardware based approach ?

I honestly do not know.

Simon.

PS: BTW, just out of interest, which stack based processors do you use ?

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

[%X]

Software based attacks seem to be doing just fine for the moment.

I am not sure anyone does.

Have used Novix NC4016, Harros RTX2000 and 2010. More recently I have been looking at the Intellasys SeaForth chips but am probably going with the Green Arrays GA144 for the next projects.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.