1. Embedded Linux and Commercial RTOS are friends in the growing multi-core solution.
------------------------------------------------------------------------------------
Consider a hypervisor so you can have both RTOS and Linux for user interface
Venders like Wind River and Green Hills have lightweight hypervisors that allow for mixing Linux and RTOS on different cores.
Also, during our panel discussion, most of the vendor talked about running an RTOS alongside Linux on a two-core chip.
2. Chat of footprint
-------------------------------------------------
ThreadX can be as small as 2KB
if you're targeting 16Kb RAM, then Linux is out of the question. Think uCOS/III, ThreadX, uVelocity, etc. if you really need an O/S.
Jim Turley (10/22/2010 3:45:35 AM):Minimum memory size for Linux is about 4 MB, according to our panelists.
in a prev company I was stuck with an in-house RTOS very limited ability. Installed a demo RTOS that had a remote debug system. That alone justified the purchase order. (this was 8/16-bit days)
Mike Anderson (10/22/2010 3:46:26 AM):I've gotten Linux down to 295K, but it was a very focused application. 2K is so small that even the tiny RTOS kernels may be too big.
John Carbone (10/22/2010 3:50:42 AM):@zahir - for 25 tasks (we call them "threads" but it's the same thing), each one uses about 164 bytes, so 4KB of RAM just for the Thread Control Blocks.
3. Chat of ucLinux
---------------------------------
Bruce Christensen (10/22/2010 3:53:24 AM):@Dave M -- uClinux doesn't have an MMU so it doesn't support multi-threaded designs which eliminates some of the open source software out there. In some aspects it is easier though when working with an embedded system because addresses referred to in the code are 'real' addresses, not virtual
Lloyd Sargent (10/22/2010 3:54:15 AM):@Dave M Also you can't really use fork - there is a work-around but it can mean a lot of code rework
4. Chat of eCOS
---------------------------
Yanming Wu (10/22/2010 3:58:28 AM):eCos is also open source, like linux, any comments on eCos?
Mike Anderson (10/22/2010 4:02:25 AM):eCOS is a nice little platform, you see it most often these days ad the RedBoot boot loader.
erol ozkarsli (10/22/2010 4:04:44 AM):@mike is eCOS open source?
zahir parkar (10/22/2010 4:04:53 AM):@john Thanks
Mike Anderson (10/22/2010 4:05:01 AM):@erol: yes, covered by GPL
erol ozkarsli (10/22/2010 4:22:23 AM):@Yanming eCOS is not support luminary devices instead eCOScentric does
5. Firmware Upgrade with Embedded Linux
-----------------------------------------------------
WanQiang(Quentin) YANG (10/22/2010 4:20:38 AM): Hi, what's the common way or is there common way to do firmware upgrade with embedded Linux? For our previous products without RTOS, firmware itself is able to reprogram the whole flash(ROM) with new firmware delievered via 3G modem.
Mike Anderson (10/22/2010 4:22:31 AM):@Wan: You could certainly do it that way. Boot firmware like UBoot could support that. But, I normally have a piece of firmware that I never allow the users to update so they can't brick the box. Then the O/S & filesystem are updated in flash via the boot firmware like you've done in the past
WanQiang(Quentin) YANG (10/22/2010 4:25:45 AM):Yeah, in our previous product, one piece of code, we call it bootloader, can never be upgraded, which stay same in a certain part of FLASH.
Raghavendra Reddy Desai (10/22/2010 4:28:20 AM):@ EROL :for cortex-M3 try using openICE EDS
WanQiang(Quentin) YANG (10/22/2010 4:28:40 AM):So, you reckon, I can do the same thing, get one level of boot loader before UBoot to manage the Embedded Linux upgrade for both Kernel and File System. Thanks. That'll be part of job outside of Linux Porting.
Mike Anderson (10/22/2010 4:29:25 AM):@Wan: Yes, that's what we've done many times in the past and that seems to work reliably. Good luck.
6. Chat of Real-time about Embedded Linux
----------------------------------------------------
Mike Anderson (10/22/2010 6:05:42 AM):Yes, that would be unfair. I've seen very good determinism from the RT-patched kernel.
Doug Gibbs (10/22/2010 6:07:21 AM):@Brett, the patch removes/replaces instances of the big lock. Mainline kernel is also removing them.
Mike Anderson (10/22/2010 6:07:28 AM):Absolutely. Real-time means being fast enough. Deterministic behavior is great, but the world is rarely deterministic. And, if you want real determinism, you have to be willing to disable your processor caches and SMP.
Nuno Felicio (10/22/2010 6:07:28 AM):an RT-patched kernel runs linux as a low priority task of an hard RTOS
Jose Luis Briz (10/22/2010 6:08:01 AM):@Sutton you have fully preemption. Without the RT patch, processes running kernel mode can't be preempted if holding a spin lock
Jason Wessel (10/22/2010 6:08:10 AM):Doug / Brett: It is more than that, an RT patched kernel converts nearly all the spin locks in the kernel into priority based mutexes.
Jason Wessel (10/22/2010 6:09:03 AM):Jose Luis Briz, in most cases that is true, some drivers do not play so nice and they are made RT safe with non-premptible locks.
Mike Anderson (10/22/2010 6:09:08 AM):@Nuno: actually, that is only one type of RT-Linux -- the sub- or co-kernel flavor RTAI and Xenomai are examples of that. But the RT-patched kernel (PREEMPT_RT) has determinism built into the kernel as a native feature.
Jose Luis Briz (10/22/2010 6:09:15 AM):@Sutton All interrupt serv.routines and softirqs are tasks, so they imply a context switch. And all spin locks are mutexes (the process blocks)
Nuno Felicio (10/22/2010 6:10:37 AM):@Mike yes but the RT- patched kernel only gives determinist arround 100 us or something like that, so its only soft real time
Don McFarland (10/22/2010 6:10:52 AM):having only used embedded Linux kernels that use MMUs (Coldfire processors), I was wondering if ucLinux does better in tight timing situations ?
Mike Anderson (10/22/2010 6:10:59 AM):That depends on your system requirements.
7. Chat of boot time about Embedded Linux
---------------------------------------------------
Don McFarland (10/22/2010 6:16:31 AM):one serious problem with embedded Linux w/MMU is the rediculous boot times - 1 1/2 minutes on one of our boards and 30 seconds on another of our boards - with CPU clock in excess of 100MHz on both boards
Dean Misenhimer (10/22/2010 6:17:41 AM):@don we just did a webinar on fast boot techniques...it's not here in the show but you can find it on our website. Lots of good info in it
Dean Misenhimer (10/22/2010 6:13:24 AM):There is a white paper on real-time in our booth that may be helpful...It's a few years old, but still has some good info in it. Look in the general info section of our collateral.
Ron Wilson (10/22/2010 6:13:56 AM):@Dean: which booth is that?
Mike Anderson (10/22/2010 6:14:00 AM):http://www.versalogic.com/downloads/whitepapers/Real-time_Linux_Benchmark.pdf
Dean Misenhimer (10/22/2010 6:14:12 AM):@ron Sorry...MontaVista
Dean Misenhimer (10/22/2010 6:18:48 AM):we also did a one second boot for a customer...cold power on to data display in 1.5 seconds, so it can be done...takes a lot of tuning
John Faith (10/22/2010 6:19:00 AM):Don: you might try running bootchart. See http://elinux.org/Bootchart
Jose Luis Briz (10/22/2010 6:20:28 AM):@Brian PREEMPT_RT is only in the patc
Nuno Felicio (10/22/2010 6:22:50 AM):@Brian, with an mpu Linux can provide process isolation/protection
Don McFarland (10/22/2010 6:23:50 AM):Nuno - are you running the kernel out of the flash - with a one second boot I had to ask... because decompressing and loading the kernel before any code actually start running except for the boot loader, can take that long
Nuno Felicio (10/22/2010 6:23:55 AM):for example AT91SAM9G20 have mpu
Nuno Felicio (10/22/2010 6:24:04 AM):and runs the complete Linux
Nuno Felicio (10/22/2010 6:24:31 AM):@Don the kernel its not compressed
Nuno Felicio (10/22/2010 6:24:43 AM):@Don its faster
Don McFarland (10/22/2010 6:26:09 AM):@Nuno - understood - Ive never seen a Linux be able to load and initialize all of the device drivers in that time frame, even on a 3 GHz Intel CPU
Nuno Felicio (10/22/2010 6:27:51 AM):@Don in a PC its very hard to achieve very fast boot times, the PC is a horrible designed machine :), in a small board its more or less easy
Tim Michals (10/22/2010 6:25:46 AM):From many RTOS Linux providers give the response, "You have to test your application to validate the timing will be met" That is a hard sell to management to spend money any comments?
Lloyd Sargent (10/22/2010 6:28:49 AM):@Tim In my 25 years (save for one company) it was ALWAYS a hard sell to get management to spend money to validate testing
Lloyd Sargent (10/22/2010 6:29:26 AM):@Tim Sorry, TIMING not TESTING
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment