From owner-freebsd-arm@FreeBSD.ORG Fri Apr 17 14:09:02 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AECF928; Fri, 17 Apr 2015 14:09:02 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 007D87BB; Fri, 17 Apr 2015 14:09:01 +0000 (UTC) Received: from mbpro2.bs.cs.huji.ac.il ([132.65.179.20]) by kabab.cs.huji.ac.il with esmtp id 1Yj6wg-000BOf-RR; Fri, 17 Apr 2015 17:08:39 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2090\)) Subject: Re: help with coding a loadable kernel module From: Daniel Braniss In-Reply-To: Date: Fri, 17 Apr 2015 17:08:46 +0300 Cc: Ian Lepore , freebsd-arm@freebsd.org Message-Id: <8C177A8C-F6B2-43D5-925F-A3C33B6CF577@cs.huji.ac.il> References: <20150417080839.GO2743@home.opsec.eu> <9B835088-661C-456E-84A7-47BC1835C0CB@cs.huji.ac.il> <20150417095536.GA38091@gmail.com> <32D7EBD3-813E-4062-8A06-ED8E82BA50DA@cs.huji.ac.il> <1429276417.1182.71.camel@freebsd.org> To: Warner Losh X-Mailer: Apple Mail (2.2090) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 14:09:02 -0000 > On Apr 17, 2015, at 4:42 PM, Warner Losh wrote: >=20 >>=20 >> On Apr 17, 2015, at 7:26 AM, Daniel Braniss = wrote: >>=20 >>>=20 >>> On Apr 17, 2015, at 4:13 PM, Ian Lepore wrote: >>>=20 >>> On Fri, 2015-04-17 at 13:46 +0300, Daniel Braniss wrote: >>>>> On Apr 17, 2015, at 12:55 PM, Tom Jones wrote: >>>>>=20 >>>>> On Fri, Apr 17, 2015 at 12:15:33PM +0300, Daniel Braniss wrote: >>>>>>=20 >>>>>>> On Apr 17, 2015, at 11:08 AM, Kurt Jaeger = wrote: >>>>>>>=20 >>>>>>> Hi! >>>>>>>=20 >>>>>>>> I know I'm embarking on a dangerous trip, but I want to use a = Raspberry Pi >>>>>>>> and or a BeagleBone to read (and write) RFID cards. >>>>>>>> Since a driver is needed to use the spibus, I have 2 options = while >>>>>>>> developing: >>>>>>> [...] >>>>>>>> So before I give up on option 2, is there some examples/help? >>>>>>>=20 >>>>>>> Are you aware of this book ? >>>>>>>=20 >>>>>>> http://www.nostarch.com/bsddrivers.htm = >>>>>>=20 >>>>>> no, but before I spend more money (this is getting expensive :-), >>>>>> does it explain how to write a loadable module that needs to to = talk >>>>>> to a spibus? >>>>>=20 >>>>> I don't think it does. >>>>>=20 >>>>> spibus is very simple, there is one interface call >>>>>=20 >>>>> SPIBUS_TRANSFER(device_t, device_t, strcut spi_command); >>>>>=20 >>>>=20 >>>> chicken and egg issue :-), what device_t dev should I use? >>>> it must point to the spibus =E2=80=A6 >>>=20 >>> Your device will be a child of the spibus, and it is the bus that >>=20 >> it=E2=80=99s the =E2=80=98child of=E2=80=99 that I have problems. = this will be a loadable module, so >> it will have to tell the parent that he is no longer an orphan :-) >=20 > When you declare the module, one of the parameters are what bus to > attach to. >=20 > If you are using FDT in your system, then you=E2=80=99ll put your = device into the > FDT tree below the spibus to create the device_t node in the tree. = When > your module is loaded, its probe routine will be called, and you can > match based on the compatible string given in the FDT. >=20 I was afraid of that :-), this FDT stuff is new to me, and so far I was = successful in adding a gpio/led, but grep has not found any spibus. any chance for a small template/example ? rpi or bbb would help! cheers danny >>> implements the SPIBUS_TRANSFER() method, so it's the bus's device_t = that >>> needs to be passed as the first parameter in the call (if it were = C++ it >>> would be the "this" pointer -- this stuff is OO implemented in = plain-C). >>>> =46rom your driver, something like: >>>=20 >>> SPIBUS_TRANSFER(device_get_parent(sc->sc_dev), sc->sc_dev, cmdptr); >>>=20 >>> I haven't got time this morning to put together a complete example = of >>> how to add a module to the build, but the process is basically along = the >>> lines of... >>>=20 >>> Add a new directory to sys/dev for your driver just like you were >>> going to compile it into the kernel. Then in sys/modules find = another >>> simple driver, copy it to a new directory, and change the names of >>> things in the makefile so that it refers to your new dir/files in >>> sys/dev. You can set MODULES_OVERRIDE=3Dyournew_dirname on the make >>> command line or in your kernel config to make it compile. >>>=20 >>=20 >> I have that, even figured out how to cross compile and use the make = buildenv. >> it=E2=80=99s great! I can compile outside the source tree too. >=20 > Yes. That=E2=80=99s also possible. Build it in a buildenv environment = and then > copy the .ko file over to the target system to kldload. >=20 > Warner