So, I know Linux kernel is quite "heavy" when considering lower scale embedded systems, but currently but we're a 2 man team trying to see how to create our own embedded system.
I'm the one in charge of all software (the other guy is a HW guy), and thus I would like to re-use existing libraries and frameworks as much as possible, and I would like to bounce off some ideas with gurus around here.
I am fairly comfortable in Linux, but the booting and initialization process is new to me, and I need to dive in to that soon enough. Any book recommendations are welcome as well!
I haven't designed any embedded systems before.. Only own some ARM dev boards (beagleboard and raspberry pi).
Current I have prototype of the software running on beagleboard already, and now we're thinking how to minimize the cost, and to create something our own..
It's a system connected to the internet, and I need to run a tiny web server with some scripting support. Performance wise I don't think it needs to be too powerful.
I would like to minimize all bootloader etc work, since I'm a one man SW team, and just concentrate on the application itself.
Of course I understand that I need to configure our kernel for this, but this is indeed why I thought selecting some SoC would be good, since they usually have some linux and bootloaders ready..
First I thought that Cirrus EP9301 would be perfect, since it seems to be a good package, and not very expensive.. But it seems that it's already in end-of-life, and also support for this is very bad (people on the cirrus forums constantly complain about it).
Are there some good choices for this kind of project, which would enable us "easily" to get linux kernel up and running, with still maintaining some kind of decent BOM (hopefully 20USD or so) ?
Your hardware guy should already know this, but go with an existing reference design. Take the raspberry pi, the beagleboard/bone, open-rd, or any number of other existing systems and clone the part you need. As a result the linux porting will be a matter of removing what you are not using from the reference design instead of adding new stuff and hoping it works. If you go with flat pack parts you can do the work in your garage, if you go with bgas you need the equipment for that or pay someone to do it. (can you tell yet that I hate bgas?).
Is linux a requirement, if not that opens the door to a lot more devices using freertos or chibios or a number of other solutions. the stm32f4 discovery board for example is $20, uses what can barely be called a microcontroller for all the features it has (cortex-m4). Supposedly possible to run uclinux on a cortex-m, but definitely possible to run any number of rtoses and have an ip stack, etc. stellaris (ti.com) has a number of eval boards, one/some with ethernet already (use as a reference design). You can also take the wiznet approach (or a spi ethernet) and use any microcontroller (puts you into the avr/msp430 level and price range). Bang for buck the cortex-m's are good, arm based so comfortable to work with, etc.
Using linux if you are already not an experienced at porting to an embedded platform, and dont want to learn that on this go around, I would definitely go with a clone of an existing design, leverage as much as you can from a project with folks that are experienced at porting linux to a platform. If need be take an existing board (beagle/raspi/openrd) and go through the motions of porting to the platform with the cheat sheet of having access to an existing port, see if you cant get uboot ported and linux booting, etc. (dont really need uboot at all, that is possibly an unnecessary complication, just get dram up and pass the atags, etc to linux and just branch to it, pretty easy to launch linux from bare metal).
You could probably do worse than taking the Broadcom BCM2835 - used on the Raspberry Pi - as your starting point - especially if you want to avoid kernel and boot-loader work and a source of reference schematics. If this proves too expensive, check out other devices in the Broadcom range.
A few bits of advice
You probably want some flash rather than a MMC card interface for production use. eMMC is an option. NAND flash is a nightmare due to rapid component obsolescence and the need to get own and dirty with the MTD drivers.
USB Ethernet will be easier to integrate than a controller hanging off a general purpose bus, but won't perform as well. SmSC seems to be popular source for either
You could also have a look at the work that Olimex is doing with their linux boards. Perhaps even order a som and then combine it with other external components.
Related
Context
Debian 64 bit. kernel 3.18.x
Litterally struggling to understand how a network driver is initialized.
I mean how to choose which flag to set. I dig in the kernel for days now to train myself. The card setup is the only point I miss.
I take the intel 82574 as an example. I downloaded the card's datasheet, saw many information but not a clue on how to setup the hardware.
Question
Where to start to know what flags to set ? The datasheet didn't helped me (i am not very experienced but willing to learn).
Please give me a starting point, a tip or anything to help me understand what is going on in the already written open sourced driver.
How can a developer knows how to initialize his nic ? (yes reinventing the wheel the time to understand)
You'll need to read the source code of the kernel module that handles your specific NIC.
EDIT: Of course, to develop such a module, you'd usually just use a register map as specified in a data sheet or application node; often, manufacturers develop their linux drivers themselves, so the driver developers might even be the same people that developed the chipset (because it's really handy to have a platform to test against -- it's impossible to test hardware without having something like a driver, so you might as well write a proper driver).
Furthermore, devices often come with code examples -- no one is going to build a device based on an IC that he has not seen in action.
If you've got access to neither proper documentation nor source, you can only reverse engineer - and that's an incredibly large field.
Using your example with the Intel 82574 Network Adapter, Intel provides a zip file of the source code used to build the Linux driver. The driver is like all drivers in that it hooks into the OS API for Networking.
The Linux networking API is document on both the linux.org site and discussed on popular Linux sites like lwn.org. Below is the link to lwn's chapter on Network drivers using the networking API called NAPI.
https://static.lwn.net/images/pdf/LDD3/ch17.pdf
You'll notice in the Intel igb driver source code that the NAPI net_device data structure is one of the first things that is setup. It registers the driver with the OS. This way the OS knows which igb functions to call when loading/unloading the driver, or when needing to send/receive data.
The igb functions read/modify/write the necessary bits in the 82574's memory-mapped registers that control and monitor the device. The device registers are all documented in the 82574 datasheet available on Intel's site. And this is usually the case for almost any networking company like Broadcom/Chelsio/Mellanox/Marvell.
Hope that helps a little more.
I've spent a lot of time developing an operating system and working on my low level boot loader. But now I want to take some time off my operating system while not leaving the low-level environment and doing something involving security.
So I chose to build my own standard password utility following the pre-boot authentication scheme. Since I want the software to be at least a little portable I want it to use as little external support as is possible. I figured that I'd be best if I somehow managed to 'hook' into the bios somewhere between the self checks and the int 19 bootstrap from within a running real mode OS.
However finding information on how to modify the bios code proved to be impossible. I've found nothing on how to achieve the before mentioned. I have only found pages describing how to flash your bios.
Does anyone know how I can read/write bios code? Or can someone provide links to pages that describe this?
I know that it's not only possible to brick my device but it is also likely, I'm aware of the risk and willing to take it.
Pinczakko's articles on BIOS reverse engineering are a great place to start looking at this. There was also a book published by the same author but it is now out of print.
I'm not sure if this approach is the best approach towards a secure boot, but the articles on this site are very detailed and should point you towards a method for modifying your BIOS firmware.
I'm not really sure what you are trying to achieve, but:
The BIOS is completely hardware specific - each manufacturer will have their own mechanism for updating / flashing BIOS and so trying to come up with a portable mechanism for updating a BIOS is destined for failure. For example when using Bochs you "update" the BIOS by specifying a different BIOS ROM image.
If you want to modifty / write your own BIOS then its going to be completely specific to that hardware. Your best bet would be to start with something like Bochs as its open source - as you can take a look at the source code for the BIOS (and easily test / debug it) you stand a reasonable chance of understanding the BIOS code and modifying it into something that works, however I suspect this isn't what you are trying to do.
Why not just perform this authentication as your OS boots? If you want to protect the data then you should encrypt it and require that the user supply log in / supply the decryption key on startup.
If you were thinking of working with "legacy" PC BIOS, I would dissuade you from trying for many of the reasons Justin mentioned: 1) legacy BIOS is PC vendor-specific; 2) it is closed source and proprietary; 3) there are no industry standards defining legacy BIOS interfaces for extending the system as you are trying to do.
On the other hand, if you have access to a UEFI-based BIOS PC, you may be able to write your own PEI/DXE driver(s) to implement such a feature. This will at least point you in the right direction:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
Intel Press book on the topic: Beyond BIOS
Regarding the practicality of read/writing the BIOS, you'll need to identify the SPI part containg the BIOS and get a ROM burner. The SPI part may or may not be socketed; if it is not socketed, you'll need a soldering iron and be able to create a socket/header for the part. You obviously do not want to embark on this project with your primary computer system. Perhaps you could find an older system or a reference board.
was wondering - if knowing The Linux way of life or the Linux architecture, would give a better frame of mind for programming on embedded devices especially when they have some kind of OS in them.
Just want to be sure that I did not miss a major thing :)
Note:
I come from a windows background, can program in C and C++.
Passionate and finally want to get started into Embedded programming. I would like to start by doing typical hobbyists project at home.
It would be nice if anyone would also comment on BeagleBoard as a starting point for me.
"Embedded" is a fuzzy word. There are two categories:
There are realtime embedded systems: microcontroller/microprocessor applications that are intimately communicating directly with the hardware on a low abstraction level. Typical applications are control systems/automation, industrial, automotive, medtech, household electronics, data/telecom communications etc.
And then there are fluffy embedded systems: various laptop:ish computers, embedded linux, embedded windows, phones and phoney operative systems, anything involving internet, human-machine intefaces etc.
People working in both categories will firmly state that they are working with embedded systems, while the latter kind are often just doing another flavour of desktop applications. Depending on which category you are aiming for, Linux may or may not be a merit. The telecom branch for example, overlaps both of these categories, and they are often using embedded Linux even for non-fluffy applications.
In either case, *nix may be used as the development platform, so knowing it won't hurt.
Yes and no. Mostly yes.
Lundin correctly described the "two worlds of embedded" (although the border between them is very fuzzy).
If you're writing for "higher embedded", like Android, or other devices that run Linux, then definitely expert knowledge of Linux will be of much help. You still need to know some "bare bones" and don't get scared when you see the likes of &=~ operator in C, but knowing Linux - the Linux of the old, where you configured stuff by editing files in /etc, where you compiled your own kernels for everyday use, where you would build software from tarballs, that's what helps. Knowing modern Linux - Gnome, gconf-editor, Synaptic and the likes will not be of much help.
Then next, if you're programming devices without OS, in the middle area - fast and strong enough to run C programs, but not the OS, you still need Linux. Because crosscompile. You don't need actual Linux. Cygwin is okay for that. MinGW may suffice. Still, you will probably need to be able to build your own crosscompiler (based on GCC), linker, debugger, make tools, and the rest of "backbone" of the IDE. Unless your chip supplier is awesome and provides a complete toolchain with IDE.
Only when you're into tiny processors, you don't need Linux. Stuff like car alarm remote, christmas lights blinker, car tire pressure sensor, battery level monitor - stuff that can have 16 bytes RAM, 1KB EEPROM, and the rest of CPU to match, you will need to use an IDE that works with this CPU, no OS, no C compiler, nothing remotely close to Linux - the IDE will most likely be Windows based.
I'd say you really do not need to know Linux for embedded programming. Many companies developing embedded software do it on windows and have no contact with other OS.
But sure, knowing more makes you more versatile, and general knowledge makes you a better engineer. This includes different OS as many other things.
When it comes to BeagleBoard, it depends on the kind of application you are interested in.
If you want to understand the low-level, I would start on a simpler processor and learn how to use peripherals, hardware interrupts, debouncing signals... There is an educational point in doing this yourself some time.
I suppose you can also skip that and start with an ARM-A8 and possibly an embedded OS, it's just not the path I followed.
What I am about to say may cause a flame war, but...
I have found that Linux is a much more productive development environment than Windows. At my previous job, we were developing firmware for managed switches and industrial automation equipment, which ran an embedded Linux operating system. All the developers had both Windows and Linux boxes, as the user interface software only ran on Windows. We all used Linux for developing, though, as it was simply easier.
At my current job, the only choice is to run Windows, but to make it more productive we are running Cygwin, which provides a Linux-like environment. It is very difficult to develop software on Windows that is not specifically for Windows.
As for developing for an embedded system without an OS... I have an Arduino that I play with occasionally. I have programmed it both from Windows and Linux, and have found the experiences fairly similar. Using Arduino's own tools, Windows seems to run a bit more smoothly, but if you want to hack on it and make something interesting, you're better off using Linux.
Personally (and this will likely provoke some nasty comments), I feel that Linux is best for doing productive work, and Windows is best for playing games.
So basically, this all boils down to this: Try using Linux for developing your project. You will probably find it to be a much smoother, more productive experience. If you don't like it, you don't have to keep using it. But the experience will probably be worth it.
Edit (due to question rewording): Knowing the "Linux way of life" is unlikely to help much when coding for an embedded project that is not running Linux itself. As I understand it, the Unix philosophy is about two main issues:
Each tool should do one thing and do it well (don't make something that tries to be everything).
Whenever possible, data should be plain text (allows for simple piping through processes and searching for content).
If you are working on a system without an operating system, you are writing code for a compiler and not likely working with a full shell at any point. You also are unlike to have any sort of file system. So both of these points are moot; you are not likely to gain anything concretely related to embedded programming by studying Linux, although it certainly couldn't hurt :-)
I really think if you want to learn a little about embedded sphere you should not start by using an OS directly. Prefer to have hands on a small low level project then add an OS if it's really needed for your final application.
I don't think setting up an OS into an embedded device will be easier than starting from scratch. It will bring you some functionalities (that I am not sure you really need to learn embedded) but it will bring you lot of hard debugging time in case of problems in the OS port.
I have been doing embedded programming for 10 years, currently for networking equipment and before that Apache helicopters. Both companies had POSIX-like operating systems on the target, but not embedded Linux directly. My current company uses mostly Windows for individual developer environments. However, we do have a few Linux boxes hanging around for special purposes. My previous company used a mix of Windows and Sun Solaris Unix. So wherever you go, you may not use Unix or Linux on your day to day computer, but you are likely to come across it at least occasionally.
On the other hand, I've known developers who have programmed on Linux for embedded Linux targets their entire careers. It really depends on the company, as smaller or newer companies have a tendency to use Linux more than corporations. However, using embedded forms of Windows on targets is very rare in my experience. I know devices are out there, but I've never personally met a developer who worked on one.
Anyway, Linux is free to use and has other benefits besides being good for a job. There's really no downside to giving it a try for a couple of months, other than giving up some of your time.
Linux is growing in embedded... see latest research:
Top 10 trends for the embedded software and tools market in 2011 - VDC research
Android Becomes Number One in U.S. Smartphone Market Share
Knowing the Linux way of life will definitely be a plus in embedded domain provided the kind of apps you are interested in are contained in the above mentioned links.
understanding Linux architecture will be over kill (although basic overview is good) before just starting in embedded field
e.g. to cut a tree you don't have to invent an axe - just start using one, then gradually you could learn to sharpen the axe
Its better to get started small - get hands-on, and focus on specific areas as is the need of the hour. grow with your work and work keeping your goals in mind
you will surely gain much faster and not get stuck in self loop - R&D to do R&D ;)
Only if you want to embed Linux! And as an embedded systems developer of some 22 years, I would suggest that Linux is unsuitable and unnecessary for a very large proportion of embedded systems projects.
Understanding the workings of an RTOS, and real-time priority based pre-emptive scheduling and IPC mechanisms would stand you in better stead. Take a look at this for example.
I need to produce an embedded ARM design that has requirements to do many things that embedded Linux would do. However the design is cost sensitive and does not need huge amounts of horse power. Mostly will be talking to serial interfaces. Ideally I would like to use one of the low end ARMs. What is the lowest configuration of an ARM that you have successfully used embedded Linux on.
Edit:
The application needs a file system on some kind of flash device and the ability to run applications for processing the data. Some of the applications might be written by others than myself. I also need to ability to load new applications or update old apps using the serial ports to accept the apps.
When I have looked at other embedded OSes they seem to be more of a real time threading solution than having the ability to run applications. I am open to what ever will get the job done.
I think you need to weigh your cost options here.
ARM + linux is an option but you will be paying a very high operating overhead for such a simple (from your description) set of features. You can't just look at the cost of the ARM chip but must also consider external RAM which will very likely be required as well as flash to get enough space available to run the kernel + apps.
NOTE: you may be able to avoid the external requirements with a very minimal kernel and simple apps combined with a uC with large internal resources.
A second option is a much simpler microcontroller with a light weight OS. This will cut your hardware costs on the CPU and you can likely run something like this without external RAM or flash (dependent on application RAM and program space requirement)
third option: I don't actually see anything in your requirements that demands any OS at all be used. Basic file systems are very simple, for instance there are even FAT drivers out there for 8 bit PIC's. Interfacing to an SD card only requires a SPI port and minimal external circuitry.
The application bit could be simple or complex. I've built systems around PIC18 microcontollers that run a web server and allow program updates via a simple upload screen, it just stores the new program into an EEPROM or flash, reboots into a bootloader and copies the new program into internal program memory. You could likely design a way to do this without the reboot via a cooperative multitasking type of architecture. Any way you go the programmers writing the apps are going to need to have knowledge of the architecture and access to libraries / driver you write. Your best bet to simplify this is to provide as simple an API as possible and to try to automate the build process for them.
The third option will be the "cheapest" in terms of hardware as there will be very little overhead in the processing of your applications allowing you to get away with minimal processing power and memory. It likely will require some more programming/software architecting on your part but won't require nearly the research you will need to undertake to get linux up and running in addition to learning to write the needed device drivers under a linux paradigm.
As always you have to include the software development costs in the build cost of the device. If you plan to build 10,000+ of these your likely better off keeping hardware costs down and putting more man power into designing a software solution that allows that hardware to meet the design goals. If your building 10 of them, your better off spending an extra $15-20 on hardware if it can cut down on your software development costs. For example an ARM with MMU with full linux kernel support and available device drivers.
I kind of feel that your selecting the worst of both worlds at the moment, your paying extra to get a uC you can run linux on but by doing so your also selecting a part that will likely be the most complex to get linux up and running on, especially having not worked with linux on embedded platforms before.
I've had success even on ARM7TDMI, so I don't think you're going to have any trouble. If you have a low-requirements system, you could use any kind of lightweight real-time executive and have a lot better experience than you would getting Linux to work.
I've used a TS-7200 for about five years to run a web server and mail server, using Debian GNU Linux. It is 200 MHz and has 32 MB of RAM, and is quite adequate for these tasks. It has serial port built in. It's based on a ARM920T.
This would be overkill for your job; I mention it so you have another data point.
For several years I've been using a gumstix to do prototyping and testing and I've had good results with it. I don't know if the processor they are using (Intel PXA255 on my board) is considered low-cost, but the entire Verdex line seems pretty cheap to me for an adaptable device.
ucLinux is designed specifically for resource constrained targets, but perhaps more importantly for targets without an MMU.
However you have to have a good reason to use Linux on such a system rather than a small real-time executive. Out-of-the-box networking, readily available drivers and protocol stacks for complex hardware and support for existing POSIX legacy or open source code are a few perhaps. However if you don't need that, Linux is still large, and you may be squandering resources for no real benefit. In most cases you will still need off-chip SDRAM and Flash if you choose Linux of any flavour.
I would not regard serial I/O as 'complex hardware', so unless you are running a complex, but standard protocol, your brief description does not appear to warrant the use of Linux IMO
My DLINK DIR-320 router runs Linux inside.
And I know some handymen, flashing it with Optware and connecting USB-hub, HDDs, USB-flash, and much more.
It's low-cost ready for use "platform". (If you don't need mass production). But maybe more powerful than you need.
Additionally, it can be configured wirelessly via web-interface even through your pda :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I was always attracted to the world of kernel hacking and embedded systems.
Has anyone got good tutorials (+easily available hardware) on starting to mess with such stuff?
Something like kits for writing drivers etc, which come with good documentation and are affordable?
Thanks!
If you are completely new to kernel development, i would suggest not starting with hardware development and going to some "software-only" kernel modules like proc file / sysfs or for more complex examples filesystem / network development , developing on a uml/vmware/virtualbox/... machine so crashing your machine won't hurt so much :) For embedded development you could go for a small ARM Development Kit or a small Via C3/C4 machine, or any old PC which you can burn with your homebrew USB / PCI / whatever device.
A good place to start is probably Kernelnewbies.org - which has lots of links and useful information for kernel developers, and also features a list of easy to implement tasks to tackle for beginners.
Some books to read:
Understanding the Linux Kernel - a very good reference detailing the design of the kernel subsystems
Linux Device Drivers - is written more like a tutorial with a lot of example code, focusing on getting you going and explaining key aspects of the linux kernel. It introduces the build process and the basics of kernel modules.
Linux Kernel Module Programming Guide - Some more introductory material
As suggested earlier, looking at the linux code is always a good idea, especially as Linux Kernel API's tend to change quite often ... LXR helps a lot with a very nice browsing interface - lxr.linux.no
To understand the Kernel Build process, this link might be helpful:
Linux Kernel Makefiles (kbuild)
Last but not least, browse the Documentation directory of the Kernel Source distribution!
Here are some interesting exercises insolently stolen from a kernel development class:
Write a kernel module which creates the file /proc/jiffies reporting the current time in jiffies on every read access.
Write a kernel module providing the proc file /proc/sleep. When an application writes a number of seconds as ASCII text into this file ("echo 3 > /proc/sleep"), it should block for the specified amount of seconds. Write accesses should have no side effect on the contents of the file, i.e., on the read accesses, the file should appear to be empty (see LDD3, ch. 6/7)
Write a proc file where you can store some text temporarily (using echo "blah" > /proc/pipe) and get it out again (cat /proc/pipe), clearing the file. Watch out for synchronisation issues.
Modify the pipe example module to register as a character device /dev/pipe, add dynamic memory allocation for write requests.
Write a really simple file system.
An absolute must is this book by Rubini. (available both as a hardcopy or a free soft copy)
He gives implementations of several dummy drivers that don't require that you have any hardware other than your pc. So for getting started in kernel development it's the easiest way to go.
As for doing embedded work I would recommend purchasing one of the numerous SBC (single board computers) that are out there. There are a number of these that are based on x86 processors, usually with PC/104 interfaces (electrically PC/104 is identical to the ISA bus standard, but based on stackable connectors rather than edge connectors - very easy to interface custom hardware to)
They usually have vga connectors that make it easier to do debugging.
For embedded Linux hacking, simple Linksys WRT54G router that you can buy everywhere is a development platform on its own http://en.wikipedia.org/wiki/Linksys_WRT54G_series:
The WRT54G is notable for being the first consumer-level network device that had its firmware source code released to satisfy the obligations of the GNU GPL. This allows programmers to modify the firmware to change or add functionality to the device. Several third-party firmware projects provide the public with enhanced firmware for the WRT54G.
I've tried installing OpenWrt and DD-WRT firmware on it. You can check those out as a starting point for hacking on a low-cost platform.
For starters, the best way is to read a lot of code. Since Linux is Open Source, you'll find dozens of drivers. Find one that works in some ways like what you want to write. You'll find some decent and relatively easy-to-understand code (the loopback device, ROM fs, etc.)
You can also use the lxr.linux.no, which is the Linux code cross-referenced. If you have to find out how something works, and need to look into the code, this is a good and easy way.
There's also an O'Reilly book (Understanding the Linux Kernel, the 3rd edition is about the 2.6 kernels) or if you want something for free, you can use the Advanced Linux Programing book (http://www.advancedlinuxprogramming.com/). There are also a lot of specific documentation about file systems, networking, etc.
Some things to be prepared for:
you'll be cross-compiling. The embedded device will use a MIPS, PowerPC, or ARM CPU but won't have enough CPU power, memory, or storage to compile its own kernel in a reasonable amount of time.
An embedded system often uses a serial port as the console, and to lower the cost there is usually no connector soldered onto production boards. Debugging kernel panics is very difficult unless you can solder on a serial port connector, you won't have much information about what went wrong.
The Linksys NSLU2 is a low-cost way to get a real embedded system to work with, and has a USB port to add peripherals. Any of a number of wireless access points can also be used, see the OpenWrt compatibility page. Be aware that current models of the Linksys WRT54G you'll find in stores can no longer be used with Linux: they have less RAM and Flash in order to reduce the cost. Cisco/Linksys now uses vxWorks on the WRT54G, with a smaller memory footprint.
If you really want to get into it, evaluation kits for embedded CPUs start at a couple hundred US dollars. I'd recommend not spending money on these unless you need it professionally for a job or consulting contract.
I am completely beginner in kernel hacking :) I decided to buy two books "Linux Program Development: a guide with exercises" and "Writing Linux Device Drivers: a guide with exercises" They are very clearly written and provide good base to further learning.