RE: What is the minimum arm processor architecture for reliably running Linux?

["Craig Cervo" <ccervo@xxxxxxxxxxxx>]

Thanks for the information I had reached the same conclusion on most of the points you raised.

Memory fragmentation - I'm not at all concerned about the real time controls or motor control fragmenting memory. As you point out the real time portion of the application is can be very tightly designed and will use statically assigned memory. The motor control will be largely offloaded to intelligent PID controllers. The application will have a very heavy network component, wireless Ethernet, Can Bus. I'm concerned about that and about other more general application requirements which are as yet largely undefined.



"Life is like riding a bicycle. To keep your balance you must keep moving."
- Albert Einstein


-----Original Message-----
From: Aras Vaichas [mailto:arasv@xxxxxxxxxxxxxx] 
Sent: Thursday, September 25, 2008 8:01 PM
To: Craig Cervo
Cc: linux-arm@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: What is the minimum arm processor architecture for reliably running Linux?

Craig Cervo wrote:
> I'm evaluating some packaged motor controller boards that include arm
> processors as part of the controller architecture. The application I'm
> working on requires OS support. I would prefer to use Linux. I'm trying
> to determine what the minimum Arm core architecture to reliably support
> Linux would be. Note I emphasize reliable. I do not want to have
> situations where memory fragmentation resulting from a lack of mmu would
> cause Linux failures.  Based on my investigations this would mean that
> as a minimum I need
>
> Can anyone share their real workd experience?
>   
Wow, what a question. It's very hard to answer without knowing the
actual requirements but I do have a lot of real world experience in
developing microcontroller products.

First of all uCLinux is the non-MMU version of Linux. So you have a
choice between uCLinux and Linux depending on your final CPU choice.

(*) Memory fragmentation. Most low-level embedded applications have
fixed memory requirements. The only time you need to be allocating
dynamic memory is when you have data entering and leaving the system.
e.g. a command line interpreter, network device. Even then, you can use
fixed buffers and the kernel should handle most of the low level
buffering anyway.

A motor controller is a closed system, so I don't see why you would have
fragmentation problems because of your application.

I can't speak for the kernel's use of *alloc though but I'm sure that
uCLinux *doesn't* crash every non-MMU CPU it runs on because of memory
fragmentation. I would trust it.

(*) Responsiveness. Well, if I was driving a motor, I'd worry about
response time to interrupts. Linux is NOT a hard a realtime kernel. It's
pretty fast but the response time is NOT guaranteed. You can get real
time extensions/patches to fix this though.

(*) Price. Most microcontrollers (and their development boards) are so
closely spaced in price that moving between 8bit, 32bit, 32bit+MMU is
very little price step unless you are looking to make 1000+ units and
then price starts to become important. So you might as well choose
something that is larger rather than smaller ... unless power is an issue.

(*) Support and availability. I reckon this is the most important
criteria. There are loads of excellent  microcontrollers out there, and
some great memory chips but if they don't have well supported and mature
device drivers then I wouldn't bother. Also, if you need to purchase
100+ of the unit in the future, will you be able to?

Also, I agree with Bill. Go with the ARM9 because of the support but
double check the errata sheets if you need specific features.

Aras



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php