I've arm board equipped with Samsung S3C2410A chipset. And at the moment we are using 2.4.18-rmk7-pxa1 linux kernel. Now we need to have SPI support for our product but through my search i have come to know that there is no SPI driver for 2.6.x backward builds, my conclusion is based on this [
formatting link
] source.
Now it would be great if some one can clarify following points:
0) Should i upgrade to 2.6.x version? are there in porting issues involved?
1) Can i write my own SPI driver for our existing version (2.4.18) ?
2) I have done driver development for windows but never did this in linux world! any good pointers or tutorials for writing/compiling the driver and interface will be appreciated.
For writing Linux device drivers, my favourite starting point is
Linux Device Drivers, 2nd Edition By Alessandro Rubini & Jonathan Corbet 2nd Edition June 2001, O'Reilly, ISBN 0-59600-008-1
It is also available as Web pages at:
--
The SPI is pretty simple to handle even in software, as
long as it is the master. A slave has timing issues, as
the clocking is detemined by master alone.
The main problem is to find what kind of interface there
is on the board and how to control it.
I have written a couple of SPI masters for embedded ARMs
on own controller boards. If you're interested, contact
me by changeing the mail address in the sig in an obvious
way (sorry for the mess, to mislead bots).
That depends very much on what other drivers you must use. If you have any nonstandard drivers on the 2.4 kernel, you are likely to have to port them to 2.6. It's not always straightforward.
The 2.6 kernels have, as you have noticed, generic SPI support, including drivers for your platform. So unless you have a good reason not to, I would recommend moving to 2.6.x
Yes, of course. There is a lot of knowledge on the 'net on how to do it. It's also a dead end and 2.6 drivers are much more fun.
Rubini's book is a very good starting point, as Tauno said.
Read the book and look at the kernel source. If you have only done windows drivers so far, you're in for a treat.
Make that third edition if you consider 2.6.x kernels. Things have changed dramatically and the 2.4 way of thinking is likely to be counterproductive.
formatting link
This is true, in principle. However, the newer 2.6.x kernels have a SPI subsystem which allows to use SPI in a way similar to USB.
In a nutshell, you have a SPI core, an "adapter driver" which takes care of the SPI controller and "client drivers", which talk to the connected slave devices via a consistent API.
There is a learning curve involved, but it means that if you switch to a different platform, you only have to rewrite the low-level adapter driver and keep the client drivers unchanged.
It also allows several devices on the same SPI bus to work in 'parallel', where the chip-selects are controlled by the subsystem.
Strictly taken, SPI is only a spec of two interconnected shift registers for exchanging data words between the systems involved. The data word size is usually an octet (8 bits), but there are other sizes in use, as well.
The higher layer protocols, like A/D converters, memory chips etc, are not part of SPI.
Friends, thanks for your valuable comments. I've decided to upgrade it for 2.6.20, finished compiling the cross platform tool chain and just finished building a zImage. And will give it a try very soon with old bootloader and old cramfs file. Is it ok to use old (2.4.xx) ones? or do i need to have a brand new bootloader and file system file for newer kernel?
One thing more, i tried a compile a hello world driver but can't load it via insmod;-) system is complaining that "insmod: error inserting 'hello.o' : -1 Invalid module format " anyidea?
Well, SPI isn't a specification at all. But I would most definitely include the chip-select lines into that non-existing specification. ;-)
The subsystem does control the chipselect lines on behalf of the client drivers. There is no knowledge of higher level protocols required. The client drivers deal with that.
AFAIK cramfs stands for file system, so having an advantage of suspicion , it will be having *ONLY* file system driver if possible;-) IMHO it is just a module that helps to mount the memory for kernel. I might be wrong;-) Anyway, the most intersting part is how can one know what drivers are packed in that cramfs file? so i migh tbe compiling those as well.
Snip from lwo:
What do you mean by C library? i've read somewhere that printk is not the runtime C library function. How i can compile the C library indeed? and what exactly is uClibC?
Snip from lwo:
I am trying to compile with following commands, please advice the appropriate command set.
root# gcc -c hello.c root# insmod ./hello.o
Snip from lwo:
No! i'm using the same machine for compiling and loading;-) anyother possible reason for failure?
Snip from lwo:
Thanks for that very detailed help! but how to get .ko file out from c file with gcc?
The cramfs is indeed a file system. To be accurate, it is the initial file system from which the system is booted. The kernel must have the driver for this file system compiled-in. In other words, this is the only driver which can't be a module.
This filesystem then typically contains a collection of kernel modules in /lib/modules, a C library in /lib/libc*, and a minimal set of userspace programs such as a shell and various system tools. On small systems this is all provided by busybox.
It was mentioned in the cross-compiling link you have posted yesterday.
Roughly speaking, it's the compatibility layer between programs written in C and the kernel. It contains function implementations such a printf, open, close, etc.
Its purpose is to allow C programs to be platform independent.
OK, what you did was to make an object file from a C file. Under
2.4.x kernels, kernel modules are indeed object files, but they are somewhat special.
To make that clear, kernel drivers have been renamed to *.ko in
2.6.
Since you are building and running on your host machine, you need to compile against the kernel on your host machine.
This normally involves having an already set up kernel build system and then having *it* compile your module.
Judging by your apparent level of knowledge, I would strongly recommend you read "Linux device drivers" by Rubini
formatting link
This will teach you how to build drivers on and for your local system.
Building for embedded systems adds another level of complexity. A good book about that topic is "Building embedded Linux systems" by Karim Yaghmour.
Well! thank you very much . Yeah, i noticed that bit late that i was reading 2dn edition [
formatting link
] which is indeed meant for 2.4.x versions. The right book for 2.6.x is here [
formatting link
] as you mentioned. Having a quick overview of 2.4 and 2.6 driver model reminds me the transition which happened in MS world from VXD to WDM, yeah i was really amazed to learn that one can just hookup the compiler to produce some nasty stuff. Though we still need to be superuser for loading it. 2.6 driver model looks farmore generic with all those goodies. I have started on driver part, still trying to upgrade the mr. kernel but thats not working either;-)
Any pointers to read somewhat more about cramfs file? especially i'm interested for S3C2410A. I've tried a newly compiled kernel [2.6.xx] which comes with SPI driver support for my board [ S3C2410A ] BUT unfortunately it didn't work. System is halting while Uncompressing the Linux with error of "bad gzip magic number" or sometime it is different. I tried to use tar and gzip with zImage but no luck.
What you have is a cramfs image - a single file which contains the whole filesystem with several files (but not the kernel) inside. It's a bit like a ISO image for a CDROM.
The filesystem is mounted late in the kernel boot sequence, so it's not your current problem.
It could be a garbled kernel image by the time it reaches SDRAM, or the image wasn't correctly wrapped for your specific bootloader.
Unfortunately, I don't know your particular system, so I can only guess.
Usually, your flash contains a boot loader, a kernel image and the filesystem image. There are variants on this theme, where up to 3 different bootloaders are used in sequence, there may be several kernel and filesystems, etc.
The zImage contains its own decompression code. To launch the kernel, the bootloader copies the image gust after the beginning of SDRAM and jumps to the start address.
If, for instance, you use u-boot as the bootloader, the bootloader can also decompress the kernel while copying. On the other hand, the kernel must be wrapped into special headers for u-boot, which is then called a uImage.
The embedded Linux book does go into this kind of details.
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.