RE: [uClinux-dev] Queueing work from both driver and interrupt
David Wooff http://www.calrec.com/images/siglogo.gif Software Development Engineer Tel: +44 (0)1422 842159 Fax: +44 (0)1422 845244 Email: david.wo...@calrec.com Web: www.calrec.com http://www.calrec.com/ CALREC AUDIO LTD Nutclough Mill Hebden Bridge W Yorks HX7 8EZ England From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Phil Wilshire Sent: 03 February 2010 20:34 To: uClinux development list Subject: Re: [uClinux-dev] Queueing work from both driver and interrupt Hi David, You may still want to make sure that you can give priority to interrupts. The single work queue will tend to mix them all together. As far as I can see anyway. Phil Wilshire David Wooff wrote: Yes, it is safe. See kernel/workqueue.c: queue_work - queue_work_on - __queue_work - spin_lock_irqsave Best regards, Daniel Ah, I see now! I should examine the code a bit more readily in future. Many thanks. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Queueing work from both driver and interrupt
Yes, it is safe. See kernel/workqueue.c: queue_work - queue_work_on - __queue_work - spin_lock_irqsave Best regards, Daniel Ah, I see now! I should examine the code a bit more readily in future. Many thanks. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Queueing work from both driver and interrupt
Hello, I have a bottom half processing function which I'm queueing from an interrupt on a workqueue. Is it OK/safe to also queue the same function on the same workqueue from the driver in response to an application read/write? I have read LDD3 and looked for workqueues in the documentation and consulted various other sources but I can't figure out if this is safe by design (without trying it obviously). Sorry for the legal stuff btw (no way to get it removed so far). Regards, This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] kfifo spinlock sharing
Hi, if I have a set of (40) kfifos, can I point them all to use the same spinlock? Having 40 separate spinlocks and only two threads accessing the kfifos seems a little wasteful. Thanks, Dave W This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] char device driver interfacing to 32 bit wide fpga interface
Hi, re subject, would it be inappropriate to use read and write calls to communicate with a 32 bit wide interface? The fpga cannot accept byte accesses and nor do I want it to anyway. So, should I control the file position so it can only ever be on 32 bit boundaries and accept accesses in multiples of 4 bytes (returning errors otherwise), or would I be better off acessing via specific ioctl calls (passing in a pointer to a structure specifying the access) and not using normal read and write calls? The former seems unnatural and therefore probably plain wrong. If there are known examples of this in the source then please feel free to point me at them, thanks very much. Sorry again for footer - company will not remove :-( This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] char device driver interfacing to 32 bit wide fpgainterface
Is this an Altera FPGA ? Thanks Michael, I probably should have ellaborated a little more. It is an Altera FPGA as it happens, but it's irrelevant really because I'm running uClinux on an ARM processor talking to the FPGA, so I could have said simply device. There is no NIOS or Avalon buss involved. The function of the FPGA is naturally 32 bits wide so I don't want to alter it just to allow it to accept byte wide accesses (I don't think we have connected byte strobes to the FPGA in any case so it would be impossible with the hardware without nodification). I have just realised that this sort of thing is done using ioctls in LDD3 so I may have found an answer to my own (perhaps slightly premature) question. Sorry for the newbieness. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Finding function source code
e.g. if I use grep to find occurrences of say gpio_request, I get a long list to search through, but I know many of the files are not even compiled into my build. Is there an easy way to find the real place where a function is coded for my particular build? I use to look for it in the object files: find . -name *.o -o -name *.ko \ | xargs nm -o 2 /dev/null | grep -w function-or-variable Same for error messages: use strings -f on object files, instead of looking in the sources. Many thanks - this is probably what I'm really looking for. Again sorry for footer (still working on it) Dave W. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Finding function source code
Hi, this may be a stupid question. As I look around the kernel and driver source code I often find it difficult to find the real instance of a function. e.g. if I use grep to find occurrences of say gpio_request, I get a long list to search through, but I know many of the files are not even compiled into my build. Is there an easy way to find the real place where a function is coded for my particular build? This also applies to usage - say I want to find some example of the use gpio_request in my particular configuration so I can copy it to save time or even to know that it is even used in my configuration. Is there a quick and easy way to do this? Many thanks and sorry for the footer (my company won't remove it - I may have to migrate to my own personal e-mail account to get around this unless someone out there has a suggestion, other than hitting the IT guy over the head, that is). This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Finding function source code
I think LXR may be what you are looking for. If you only want That looks helpful, thanks. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] ARM GPIO - use directly?
Hi, I noticed in the ARM specific code that there are functions like at91_set_gpio Are these meant to be used directly or are they referenced by the generic gpio code in some way? Also, is there a way to write to a group of gpio pins e.g. a group of 8 configured as a byte? Many thanks P.S. Sorry everyone for the footer on this message - I'm trying to get my company to remove it but they say it's a legal requirement and added automatically by the server. :-( This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Device driver types
It sounds like ioctls are the way to talk to the FPGA, and your driver should take on the appearance of a platform or multifunction device driver (most likely the latter). I've written drivers like this in the past and it sounds like that's the way you're going to want to head if you want to minimize the amount of code you will be writing. If I were you I think I'd take a look at a few of the MFD drivers (drivers/mfd/*) in the kernel already to get a feel for how things are pieced together, get the FPGA part working and then start building on from there. Thanks very much for the pointer. More reading to do. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Device driver types
Try the char driver, it is simplest of three. Sounds like a good plan. Thanks for your advice. I'm currently following the ioctl route. It's slightly complicated because my FPGA is effectively a bridge to a number of hot-pluggable backplane I/O cards. It seems to me that I should probably attempt to structure it (the FPGA and backplane) as a bus with I/O card devices hanging off it. The FPGA also performs other functions. So, although I could talk to my FPGA via ioctl commands, how should I talk to the I/O cards when they are plugged in? Should each of these be recognised as a single char device? My other option is to keep it simple and use the driver just to talk to the FPGA and let the application code make sense of the remote I/O cards, for now at least. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Driver appears to be successfully registetered but doesn't appear in /dev
Hi,
would someone mind checking my module initialisation function in case I
have missed something?
It loads without error and the appropriate message is printed out on the
console, buit it does not appear in /dev.
I also do not see a modules directory in /lib (this was the subject of
another question), but it may be related?
I'm compiling it as a built in module and it compiles without warnings.
Thanks
Dave W.
static int __init dave_init(void)
{
int result;
int err;
dev_t device_number;
struct cdev * the_device;
/*
* Allocate device number
*/
if (!(result = alloc_chrdev_region (device_number, 0, 1,
fpga)))
printk (KERN_INFO CALREC: Device number %d, %d\n,
MAJOR(device_number), MINOR(device_number));
else {
printk (KERN_WARNING CALREC: Failed to allocate
device\n);
return result;
}
/*
* Request memory region associated with CS2 (address
0x3000)
*/
if (!request_mem_region(FPGA_BASE, FPGA_SIZE, fpga)) {
printk (KERN_WARNING CALREC: Can't request FPGA memory
region\n);
result = -EBUSY;
goto err1;
}
/*
* Allocate the char device
*/
the_device = cdev_alloc();
if (!the_device) {
printk (KERN_WARNING CALREC: Can't allocate char
device\n);
result = -ENOMEM;
goto err2;
}
/*
* Initialise the device
*/
the_device-ops = fops;
the_device-owner = THIS_MODULE;
/*
* Register the device
*/
if ((err = cdev_add(the_device, device_number, 1))) {
printk (KERN_WARNING CALREC: Can't add device - error
%d, err);
goto err2;
}
/*
* success
*/
printk (KERN_INFO CALREC: Hello, there!!);
return 0;
/*
* error handling
*/
err2:
/*
* free up the mem region
*/
release_mem_region (FPGA_BASE, FPGA_SIZE);
err1:
/*
* free up the device number region
*/
unregister_chrdev_region (device_number, 1);
return result;
}
module_init(dave_init);
static void __exit dave_exit(void)
{
printk (KERN_WARNING Bye!\n);
}
module_exit(dave_exit);
MODULE_DESCRIPTION(Driver for Dave module); MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:atmel_dave);
This electronic transmission is strictly confidential and intended solely for
the addressee(s). If you are not the intended addressee, you must not disclose,
copy or take any action in reliance of this email. If you have received this
email in error please notify the sender as soon as possible. Any views
expressed within this email may not necessarily be the views held by Calrec
Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free
from computer viruses, however it is recommended that you also employ
anti-virus measures on your computer systems.
Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE
registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill,
Hebden Bridge, West Yorks, HX7 8EZ.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Driver appears to be successfully registetered butdoesn't appear in /dev
you need to create it yourself with `mknod`, or if you want to utilize the hotplug stack, you have to create some classes/devices using the kobject layer. /dev is not a pseudo file system (ignoring the devtmpfs in 2.6.32) which means *someone* has to create the device node. it's either you, or you setup the hotplug layer to respond to device events and create device nodes on the fly. i'm pretty sure the LDD3 book goes into these details, so you might want to try reading that. or, since apparently you only need one device node, simply use the miscdevice layer and it'll take care of it all for you. see linux/miscdevice.h and the many drivers that use it under drivers/char/. -mike OK, many thanks for the direction Mike. I've been reading LDD3 as it happens but no mention of hotplug events until later chapters. Will read further. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Loadable module on uCLinux (ATSAM9G20 ARM)
Thanks Christian, yes I have that option enabled - I'm puzzled. The sub options are all [ ] except Module unloading [*] Sorry if I screwed up the formatting of this message btw - am I supposed to be bottom posting? Dave. Hi Dave, your build output looks ok to me. The /lib/modules folder is created if the symbol MODULES is set in the Linux kernel configuration. ... if [ $CONFIG_MODULES = y ]; then \ [ -d /home/christian/uClinux-dist/romfs/lib/modules ] || mkdir -p /home/christian/uClinux-dist/romfs/lib/modules; \ ... Have you enabled the option Enable loadable module support in the Linux Kernel Configuration that sets this symbol? Regards, Christian -Ursprüngliche Nachricht- Von: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] Im Auftrag von David Wooff Gesendet: Freitag, 11. Dezember 2009 11:21 An: uClinux development list Betreff: RE: [uClinux-dev] Loadable module on uCLinux (ATSAM9G20 ARM) Thanks Christian, I don't have a /lib/modules/ directory. I must be missing an option somewhere. This is the output of my build: [?]$ make ARCH=arm CROSS_COMPILE=~/buildroot-v23434/build_arm/staging_dir/usr/bin/arm-linux- scripts/kconfig/conf -s arch/arm/Kconfig CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-arm CALLscripts/checksyscalls.sh stdin:1097:2: warning: #warning syscall fadvise64 not implemented stdin:1265:2: warning: #warning syscall migrate_pages not implemented stdin:1321:2: warning: #warning syscall pselect6 not implemented stdin:1325:2: warning: #warning syscall ppoll not implemented stdin:1365:2: warning: #warning syscall epoll_pwait not implemented CHK include/linux/compile.h CC arch/arm/kernel/compat.o CC arch/arm/kernel/setup.o LD arch/arm/kernel/built-in.o CC arch/arm/mm/init.o CC arch/arm/mm/mmu.o LD arch/arm/mm/built-in.o CC arch/arm/mach-at91/board-sam9g20ek.o LD arch/arm/mach-at91/built-in.o LD drivers/misc/built-in.o CC [M] drivers/misc/atmel_dave.o LD drivers/built-in.o CC sound/soc/atmel/sam9g20_wm8731.o LD sound/soc/atmel/snd-soc-atmel-pcm.o LD sound/soc/atmel/snd-soc-atmel_ssc_dai.o LD sound/soc/atmel/snd-soc-sam9g20-wm8731.o LD sound/soc/atmel/built-in.o LD sound/soc/built-in.o LD sound/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map OBJCOPY arch/arm/boot/Image Kernel: arch/arm/boot/Image is ready GZIParch/arm/boot/compressed/piggy.gz AS arch/arm/boot/compressed/piggy.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 31 modules CC drivers/misc/atmel_dave.mod.o LD [M] drivers/misc/atmel_dave.ko Thanks, Dave. Hi Dave, if you build the loadable module with the make process for the image the loadable modules should be in /lib/modules/version/kernel/... Regards, Christian Hi, I have successfully built a simple driver module configured for built in operation and it runs at startup - great so far. I then built it for loadable operation and it builds ok. I am left with a .ko file. When I download my new image to the target, I cannot see the ko file in order to load it. Do I have to download the module separately or should it be part of the image and visible somewhere? Is there anything else I need to do other than enabling loadable module support and selecting the loadable module M in the config? I'm running 2.6.30 btw. Thanks, Dave W. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev
[uClinux-dev] Device driver types
Hello, I have read that there are 3 types, char, block and network. Does it follow that if I write a device driver for my custom FPGA that it MUST fit in to this structure? Assuming this to be the case, would it be best to use the char device type and then use fseek to access a given address within the memory map of the FPGA? Are there any other options other than user space hacking (I need to handle interrupts so I don't think I can do this). Regards, Dave Wooff This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Loadable module on uCLinux (ATSAM9G20 ARM)
Thanks Christian, I don't have a /lib/modules/ directory. I must be missing an option somewhere. This is the output of my build: [?]$ make ARCH=arm CROSS_COMPILE=~/buildroot-v23434/build_arm/staging_dir/usr/bin/arm-linux- scripts/kconfig/conf -s arch/arm/Kconfig CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-arm CALLscripts/checksyscalls.sh stdin:1097:2: warning: #warning syscall fadvise64 not implemented stdin:1265:2: warning: #warning syscall migrate_pages not implemented stdin:1321:2: warning: #warning syscall pselect6 not implemented stdin:1325:2: warning: #warning syscall ppoll not implemented stdin:1365:2: warning: #warning syscall epoll_pwait not implemented CHK include/linux/compile.h CC arch/arm/kernel/compat.o CC arch/arm/kernel/setup.o LD arch/arm/kernel/built-in.o CC arch/arm/mm/init.o CC arch/arm/mm/mmu.o LD arch/arm/mm/built-in.o CC arch/arm/mach-at91/board-sam9g20ek.o LD arch/arm/mach-at91/built-in.o LD drivers/misc/built-in.o CC [M] drivers/misc/atmel_dave.o LD drivers/built-in.o CC sound/soc/atmel/sam9g20_wm8731.o LD sound/soc/atmel/snd-soc-atmel-pcm.o LD sound/soc/atmel/snd-soc-atmel_ssc_dai.o LD sound/soc/atmel/snd-soc-sam9g20-wm8731.o LD sound/soc/atmel/built-in.o LD sound/soc/built-in.o LD sound/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map OBJCOPY arch/arm/boot/Image Kernel: arch/arm/boot/Image is ready GZIParch/arm/boot/compressed/piggy.gz AS arch/arm/boot/compressed/piggy.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 31 modules CC drivers/misc/atmel_dave.mod.o LD [M] drivers/misc/atmel_dave.ko Thanks, Dave. Hi Dave, if you build the loadable module with the make process for the image the loadable modules should be in /lib/modules/version/kernel/... Regards, Christian Hi, I have successfully built a simple driver module configured for built in operation and it runs at startup - great so far. I then built it for loadable operation and it builds ok. I am left with a .ko file. When I download my new image to the target, I cannot see the ko file in order to load it. Do I have to download the module separately or should it be part of the image and visible somewhere? Is there anything else I need to do other than enabling loadable module support and selecting the loadable module M in the config? I'm running 2.6.30 btw. Thanks, Dave W. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Loadable module on uCLinux (ATSAM9G20 ARM)
Hi, I have successfully built a simple driver module configured for built in operation and it runs at startup - great so far. I then built it for loadable operation and it builds ok. I am left with a .ko file. When I download my new image to the target, I cannot see the ko file in order to load it. Do I have to download the module separately or should it be part of the image and visible somewhere? Is there anything else I need to do other than enabling loadable module support and selecting the loadable module M in the config? I'm running 2.6.30 btw. Thanks, Dave W. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
