From: JockyW <joc...@ho...> - 2004-04-08 23:24:55
|
I'm currently developing a kernelmodule to access the dvd. I have a .c and a .S file. The .S contains a few cache invalidate and flush routines and the .c has all the init, read and ioctl code. My problem is that I have no idea how my Makefile should look, such that both files are compiled and linked into a working module.o When I build a module out of just the .c it compiles fine and with insmod I can make it run. But to make it work 100% my module needs both files. Can anyone help me out? Thx and Happy Easter! |
From: <a.o...@bl...> - 2004-04-08 23:59:22
|
On Fri, Apr 09, 2004 at 01:24:46AM +0200, JockyW wrote: > I'm currently developing a kernelmodule to access the dvd. I have a .c and a > .S file. The .S contains a few cache invalidate and flush routines and the > .c has all the init, read and ioctl code. My problem is that I have no idea > how my Makefile should look, such that both files are compiled and linked > into a working module.o Driver code written in assembly language is generally a Bad Idea (tm). > When I build a module out of just the .c it compiles fine and with insmod I > can make it run. But to make it work 100% my module needs both files. > > Can anyone help me out? > > Thx and Happy Easter! That aside, hooking your code into kbuild would look something like: --- a/drivers/cdrom/Kconfig 2004-03-25 22:08:47.000000000 +0100 +++ b/drivers/cdrom/Kconfig 2003-10-18 20:31:17.000000000 +0200 @@ -256,4 +256,13 @@ To compile this driver as a module, choose M here: the module will be called sonycd535. +config GCDVD + tristate "Nintendo GameCube DVD-ROM support" + depends on CD_NO_IDESCSI && GAMECUBE + ---help--- + Support for the Nintendo GameCube DVD-ROM. + + To compile this driver as a module, choose M here: the + module will be called gcdvd. + endmenu --- a/drivers/cdrom/Makefile 2004-03-26 00:10:19.000000000 +0100 +++ b/drivers/cdrom/Makefile 2004-03-15 11:26:08.000000000 +0100 @@ -20,3 +20,4 @@ obj-$(CONFIG_SBPCD) += sbpcd.o cdrom.o obj-$(CONFIG_SJCD) += sjcd.o obj-$(CONFIG_CDU535) += sonycd535.o +obj-$(CONFIG_GCDVD) += gcdvd.o cdrom.o |
From: JockyW <joc...@ho...> - 2004-04-10 15:00:00
|
> > Driver code written in assembly language is generally a Bad Idea (tm). > > > That aside, hooking your code into kbuild would look something like: > Thanks for your reply, but fttb it doesn't really help me. I have tried with this Makefile: obj-m := gcdvd.o module-objs := gcdvd.o cache.o But unfortunately cache.o isn't linked. After insmod gcdvd.o I get a unknown symbol, tho it is defined in cache.o A bit strange is that insmod gcdvd.ko doesn't work at all because of a bad format or so. Only insmod gcdvd.o is accepted. As alternative to above Makefile I can take: TARGET := gcdvd WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes INCLUDE := -I/usr/src/linux/include CFLAGS := -c -O2 -DMODULE -D__KERNEL__ -DKBUILD_MODNAME="${TARGET}" ${WARN} ${INCLUDE} CC := gcc-3.0 ${TARGET}.o: ${TARGET}.c cache.o: cache.S .PHONY: clean clean: rm -rf ${TARGET}.ko rm -rf ${TARGET}.o But there is again the problem that I don't know how to extend it such that it also links cache.o Any help is appreciated! |
From: <a.o...@bl...> - 2004-04-10 17:03:08
|
On Sat, Apr 10, 2004 at 04:59:51PM +0200, JockyW wrote: > > Thanks for your reply, but fttb it doesn't really help me. > > I have tried with this Makefile: > obj-m := gcdvd.o > module-objs := gcdvd.o cache.o > > But unfortunately cache.o isn't linked. After insmod gcdvd.o I get a unknown > symbol, tho it is defined in cache.o s/module-objs/gcdvd-objs/ > A bit strange is that insmod gcdvd.ko doesn't work at all because of a bad > format or so. Only insmod gcdvd.o is accepted. You'll need module-init-tools for that. Grab them from http://kernel.org/pub/linux/utils/kernel/module-init-tools/ See also http://lwn.net/Articles/22197/ > As alternative to above Makefile I can take: > TARGET := gcdvd > WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes > INCLUDE := -I/usr/src/linux/include > CFLAGS := -c -O2 -DMODULE -D__KERNEL__ -DKBUILD_MODNAME="${TARGET}" ${WARN} > ${INCLUDE} > CC := gcc-3.0 > > ${TARGET}.o: ${TARGET}.c > cache.o: cache.S > > .PHONY: clean > > clean: > rm -rf ${TARGET}.ko > rm -rf ${TARGET}.o > > But there is again the problem that I don't know how to extend it such that > it also links cache.o > > Any help is appreciated! See http://lwn.net/Articles/21823/ for how to properly compile external modules. Arthur |
From: JockyW <joc...@ho...> - 2004-04-14 16:45:11
|
Thanks for your assistance Arthur, My simple dvd characterdevice works quite well. I rewrote the linux IRQ2 handler to handle all dvd irqs (not just the cover int). But now I stumbled on a memory problem. My devicedriver uses a read buffer which is a 2048 bytes static char array. When I print the address, it sits on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory Address Register. It is a strange address, because in "yagcd" http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that uncached logical ram addresses run from 0xc0000000-0xc17fffff What kind of address translation should I apply to get the dma to work? "Arthur Othieno" <a.o...@bl...> wrote in message news:20040410170241.GA29363@mars... > On Sat, Apr 10, 2004 at 04:59:51PM +0200, JockyW wrote: > > > > Thanks for your reply, but fttb it doesn't really help me. > > > > I have tried with this Makefile: > > obj-m := gcdvd.o > > module-objs := gcdvd.o cache.o > > > > But unfortunately cache.o isn't linked. After insmod gcdvd.o I get a unknown > > symbol, tho it is defined in cache.o > > s/module-objs/gcdvd-objs/ > > > A bit strange is that insmod gcdvd.ko doesn't work at all because of a bad > > format or so. Only insmod gcdvd.o is accepted. > > You'll need module-init-tools for that. Grab them from > http://kernel.org/pub/linux/utils/kernel/module-init-tools/ > > See also http://lwn.net/Articles/22197/ > > > As alternative to above Makefile I can take: > > TARGET := gcdvd > > WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes > > INCLUDE := -I/usr/src/linux/include > > CFLAGS := -c -O2 -DMODULE -D__KERNEL__ -DKBUILD_MODNAME="${TARGET}" ${WARN} > > ${INCLUDE} > > CC := gcc-3.0 > > > > ${TARGET}.o: ${TARGET}.c > > cache.o: cache.S > > > > .PHONY: clean > > > > clean: > > rm -rf ${TARGET}.ko > > rm -rf ${TARGET}.o > > > > But there is again the problem that I don't know how to extend it such that > > it also links cache.o > > > > Any help is appreciated! > > See http://lwn.net/Articles/21823/ for how to properly compile external > modules. > > Arthur > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click |
From: <a.o...@bl...> - 2004-04-16 20:28:52
|
On Wed, Apr 14, 2004 at 06:44:55PM +0200, JockyW wrote: > Thanks for your assistance Arthur, > > My simple dvd characterdevice works quite well. I rewrote the linux IRQ2 > handler to handle all dvd irqs (not just the cover int). Block device, you mean ;) > But now I stumbled on a memory problem. My devicedriver uses a read buffer > which is a 2048 bytes static char array. When I print the address, it sits > on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory > Address Register. It is a strange address, because in "yagcd" > http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that > uncached logical ram addresses run from 0xc0000000-0xc17fffff > > What kind of address translation should I apply to get the dma to work? You want to use memory allocated from a dma pool for that instead. Create one with: struct dma_pool *dma_pool_create(const char *name, struct device *dev, size_t size, size_t align, size_t alloc); Allocate memory from it with: void *dma_pool_alloc(struct dma_pool *pool, int gfp_flags, dma_addr_t *dma_handle); Free alloc'd memory with dma_pool_free(), destroy the pool with dma_pool_destroy(). See drivers/base/dmapool.c and Documentation/DMA-API.txt for the gory details. Arthur |
From: JockyW <joc...@ho...> - 2004-04-16 21:32:07
|
> > Block device, you mean ;) > It'll become a block device. Since this is my first linux devicedriver, I decided to start with a simple character devicedriver. Meanwhile I got it to work with kmalloc. See my previous message nested deep in this thread. I would appreciate it if you can answer the question in that message (what kind of address is 0xc200ba40, it doesn't map to physical memory) Thanks again for your support :) JockyW |
From: Steven L. <st...@kr...> - 2004-05-28 19:55:21
|
How is the driver coming? Already ready for general use? Steven On Fri, Apr 16, 2004 at 11:31:52PM +0200, JockyW wrote: > > > > Block device, you mean ;) > > > It'll become a block device. Since this is my first linux devicedriver, I > decided to start with a simple character devicedriver. > > Meanwhile I got it to work with kmalloc. See my previous message nested deep > in this thread. > I would appreciate it if you can answer the question in that message (what > kind of address is 0xc200ba40, it doesn't map to physical memory) > > Thanks again for your support :) > > JockyW > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gc-linux-devel mailing list > Gc-...@li... > https://lists.sourceforge.net/lists/listinfo/gc-linux-devel > |
From: Groepaz <gr...@gm...> - 2004-04-14 16:54:10
|
On Wednesday 14 April 2004 18:44, JockyW wrote: > Thanks for your assistance Arthur, > > My simple dvd characterdevice works quite well. I rewrote the linux IRQ2 > handler to handle all dvd irqs (not just the cover int). > > But now I stumbled on a memory problem. My devicedriver uses a read buffer > which is a 2048 bytes static char array. When I print the address, it sits > on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory > Address Register. It is a strange address, because in "yagcd" > http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that > uncached logical ram addresses run from 0xc0000000-0xc17fffff > > What kind of address translation should I apply to get the dma to work? for a start, make sure the address you pass to the dma registers is 32 byte aligned (didnt i write it somewhere? :=P) gpz |
From: JockyW <joc...@ho...> - 2004-04-15 15:29:13
|
Of course i have read that :) I didn't write it but I align the address before i pass it to the DMA address reg (same for length). Problem is that the DMA regs take only 26 bits (b0-b25) with b0-b4 all zero. My address is 32 bits so should I simply strip 6 bits off? I have the feeling that the address has to be remapped to some kind of bus address. But I have no idea how. > > for a start, make sure the address you pass to the dma registers is 32 byte > aligned (didnt i write it somewhere? :=P) > > gpz > |
From: Groepaz <gr...@gm...> - 2004-04-15 15:46:49
|
On Thursday 15 April 2004 17:27, JockyW wrote: > Of course i have read that :) I didn't write it but I align the address > before i pass it to the DMA address reg (same for length). > > Problem is that the DMA regs take only 26 bits (b0-b25) with b0-b4 all > zero. My address is 32 bits so should I simply strip 6 bits off? I have the > feeling that the address has to be remapped to some kind of bus address. > But I have no idea how. err? *dmareg=((address&~0xc0000000)>>5); ? gpz |
From: JockyW <joc...@ho...> - 2004-04-15 21:10:23
|
"Groepaz" <gr...@gm...> wrote in message news:200...@gm...... > > err? *dmareg=((address&~0xc0000000)>>5); ? No, it is more like this: *dmareg=(address & 0x3FFFFE0); But this wont work since 'address' is for example 0xC20048E0, which is not a physical (0x00000000-0x017fffff) nor a logical address (0x80000000-0x817fffff or 0xC0000000-0xC17fffff). In my opinion 'address' must first be remapped to a logical address. I still don't know how. |
From: JockyW <joc...@ho...> - 2004-04-16 19:14:43
|
Problem finally solved by allocating buffer memory with kmalloc Like this: kmalloc (BUF_DISC, GFP_DMA); The flag indicates that the allocated memory can be used in DMA transfers. My original method, allocating a static char array, definitely doesn't work. The virtual address 0xC200EB40 is not associated or cannot be mapped to physical memory. I still have no idea with what other memory it is associated. So if someone can clear me up I would feel even more relieved. |