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.
Related
I want to write a driver for sensor which can tell me if my yoga 2 pro is in tablet mode or not.
I read some about writting modules but as far as I know, I need to know address in memory which belongs to this device (hope it's correct), and here is my question.
How can I find information about this address?
Or what should I do to find this address?
Both in Windows and in Android you absolutely don't need to write a driver for this purpose. To identify Tablet/Laptop mode, you need just one sensor - accelerometer. In Windows 8.1 + this functionality is built-in, but in case you wish to build your own application you can use an example from here: https://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671
In Android, you have a Java API to all sensors:
https://developer.android.com/guide/topics/sensors/sensors_overview.html
However if you have a custom Linux installed on your Yoga, there indeed may arise a need to add a driver. As of now, the most useful solution are IIO drivers that are part of Kernel:
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf
If there aren't already there, you'll have to rebuild a Kernel and include those drivers. If you don't know how to find a device address, you have to learn for a while about Linux Kernel in general. Anyway, some tips:
Sensors are normally defined via USB/HID interface
If you still have your Windows along with Linux, you may go to
Devices Manager and there you can easily reach Sensors and see what
address is used by a driver.
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.
I have a Linux network driver that was originally written for 2.4 kernel. It works perfect.
I want to port it to kernel 2.6.31 and then to ARM Linux with same kernel i.e. 2.6.31. I have actually done some minor changes to the driver so that it is able to compile under kernel 2.6.31 and it also loads and unloads without crashing. It also cross compiles for the ARM Linux. But I am unable to test it on ARM so far.
How do I check that the driver is fully compatible with the target kernel, and what considerations shall be made to make it compatible with ARM.
The driver is a virtual network device driver.
Thanks in advance.
Maybe you could use Qemu ( http://wiki.qemu.org/Main_Page) to emulate an ARM platform to be able to test your driver.
You cannot check the driver like that - you have to consider the API changes within 2.6.x series kernel. The changes are quite significant and the overall of the API's from the 2.4 series which is not currently in use.
I would suggest you to go here to the Amazon book store for this book in particular. The book is called 'Essential Linux Device Drivers', by Sreekrishnan Venkateswaran. A very well detailed explanation that will be your guidance in ensuring it works properly.
Since you mentioned the device driver is a network, presumably char device (You're not accessing it in blocks), well, the good news is that the 2.6.x series kernel APIs for the character devices are significantly easier and more centralized to focus on - in fact a lot of the framework is already in place in which the author of said book explains very clearly.
By the way, the book focusses on the latter 2.6.x series after 2.6.19, so this will help you clue in on what needs to be done to ensure your driver works.
You did not specify the ARM chipset you're targetting?
As for testing... well.. perhaps the best way to do this, this is dependant on how you answer the above question to you regarding ARM chipset - if its ARMv6, then perhaps, a cheap android handset that you can easily unlock and root, and pop the kernel in there and see what happens - sorry for sounding contrived but that's the best thing I can think of and that's what pops into my head, to enable you to test it out for ease of testing :)
PS: A lot of cheap ARMv6 handsets would have kernel 2.6.32 running Froyo if that's of any help!
I am looking at some pointers for understanding how the Linux kernel implements the setting up of various hardware clocks. This basically relates to working with setting up the various clocks that hardware features like the LCD, UART etc will use. For example when Linux boots how does it handle setting up the clocks for UART or USB. Maybe something like a Clock manager or something.
I am basically trying to implement something similar for a different OS on a new hardware that i am working on. Any help would be really appreciated.
[Edit]
Thanks for the replies and the links. So here is what i have implemented up until now. This should give you an idea of where I'm headed.
I looked up the Hardware Reference Manual for the particular system I'm targeting and wrote some code to monitor/modify the signals/pins of the peripherals I am interested in i.e. turning them ON/OFF from the command line.Now a collection of these clocks/signals together control a peripheral.The HRM would say that if you want to turn on the UART or something then turn on such and such signals/pins. And #BjoernD yes I am using something like a mmap() function to talk to the peripherals.
The meat of my question is that I want to understand the design and implementation of a Clock/Peripheral Manager which uses the utility that I have already written. This Clock/Peripheral Manager would give me the control of enabling/disabling the peripherals I want.Basically this Manager would enable me to make changes in the init code that is right now running. Also during run time processes can call this Manager to turn ON/OFF the devices so that power consumption is optimized. It might not have made perfect sense but I'm myself trying to wrap my head around this.
Now I'm sure something like this would have been implemented in Linux or for that matter any OS for performance issues (nobody would want to waste power by turning on all peripherals at boot time). I want to understand the Software Architecture of it. Reference from any OS would do as of now to atleast get a headstart. Also I am not writing my own OS, there is an OS in place but Im looking more at a board level software aka BSP to work on. But thanks for the OS link anyways, they are really good. Appreciate it.
Thanks!
What you want to achieve is highly specific to a) the platform you are using and b) the device you want to use. For instance, on x86 there are 3 ways to communicate with a device:
Interrupts allow the device to signal the CPU. The OS usually provides mechanisms to register interrupt handlers - functions that are called upon occurrence of an interrupt. In Linux see request_irq() and friends in linux/include/interrupt.h
Memory-mapped I/O is physical memory of the device that the platform's BIOS makes available in the same way you also access plain physical memory - simply by writing to a memory address. What exactly is behind such memory (e.g., network interface config registers or an LCD frame buffer) depends on the device and is usually specified in the device's data sheet.
I/O ports are accessed through a special address space and special instructions (INB/OUTB & co.). Other than that they work similar to I/O memory.
There's a multitude of ways to find out what resources a device provies and where the BIOS mapped them. Some platforms use ACPI tables (google yourself for the 1,000k page spec), PCI provides info on devices in a standardized way through the PCI config space, USB has similar ways of discovering devices attached to the bus, and some devices, e.g., UARTS, are simply specified to be available at a pre-configured I/O range that is fixed for your platform.
As a start for understanding Linux, I'd recommend "Understanding the Linux kernel". For specifics on how Linux handles devices and what is there to write drivers, have a look at Linux Device Drivers. Furthermore, you will need to have a look at the peculiarities of your platform and the device you want to drive.
If you want to start an own OS, a UART is certainly something that will be veeery helpful to print debug output, so you might want to go for this first.
Now that I wrote down all this, it seems that your actual question is: How to get started with Operating System design. This question should be highly valuable for you: What are some resources for getting started in operating system development?
The two big power users in most computers are the CPU and the disks. Both of these have capabilities for power saving in Linux. The CPU clock can be slowed down when the system is not busy, and the disk motors can be stopped when no I/O is happening. For a UART, even if you save all of the power that it uses by turning off its clock, it is still tiny compared to the others because a UART doesn't have much logic in it.
Best ways to save power are
1) more efficient power supply
2) replace rotating disk with SSD
3) Slow down the CPU and memory bus
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.