From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 1 11:06:53 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 941B8106567D for ; Mon, 1 Dec 2008 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9C78FC20 for ; Mon, 1 Dec 2008 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1B6rWa052505 for ; Mon, 1 Dec 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1B6qFF052501 for freebsd-embedded@FreeBSD.org; Mon, 1 Dec 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Dec 2008 11:06:52 GMT Message-Id: <200812011106.mB1B6qFF052501@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/101228 embedded [nanobsd] [patch] Two more entries for FlashDevice.sub o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c o misc/15876 embedded [picobsd] PicoBSD message of the day problems 4 problems total. From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 4 22:25:19 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC52E106564A for ; Thu, 4 Dec 2008 22:25:19 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5298FC0A for ; Thu, 4 Dec 2008 22:25:19 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSThYzm9fFFwz4YwVBwEUWvEXd6sBBALZ@postini.com; Thu, 04 Dec 2008 14:25:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 4 Dec 2008 14:23:42 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 14:23:42 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 14:23:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Dec 2008 17:23:41 -0500 Message-ID: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to support a TrueIDE (ATA) NANDrive chip Thread-Index: AclWXvZsIhGoBqf8T9e9zZkN9WRp5g== From: Andrew Duane To: X-OriginalArrivalTime: 04 Dec 2008 22:23:41.0911 (UTC) FILETIME=[F67D9670:01C9565E] Subject: How to support a TrueIDE (ATA) NANDrive chip X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 22:25:19 -0000 We have an SST NANDrive chip on our board that supports the simple ATA command set. What's the easiest way to get support for this into our kernel so we can partition and mount the device? Using "da" and "umass" isn't really an option, since it is neither SCSI, nor attached to USB. Pulling in all of "ata" seems like overkill; all we really need is read/write block and some simple sense commands. They are all synchronous, it's low traffic and we are more concerned with simplicity than performance. Is there some subset of "ata" I can use that won't involve pci bus, controllers, etc? We just want to be able to write the LBA, SECT_CNT, and GO command and read the data. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418 =20 From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 4 22:39:04 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B54106564A for ; Thu, 4 Dec 2008 22:39:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 51BCC8FC1B for ; Thu, 4 Dec 2008 22:39:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB4MbIpN096864 for ; Thu, 4 Dec 2008 15:37:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 04 Dec 2008 15:37:26 -0700 (MST) Message-Id: <20081204.153726.-1548257878.imp@bsdimp.com> To: embedded@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Looking to formalize board support in embedded platforms. X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 22:39:04 -0000 I've spent a little bit of time implementing the start of board files for the arm port. The initial push has been for the at91 subport only, and many improvements could be made to this. I've written up my initial thoughts on this on the FreeBSD wiki http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much improvement, I'm sure. One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share. I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides). I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here. From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 5 06:22:02 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF48106564A for ; Fri, 5 Dec 2008 06:22:02 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 130858FC17 for ; Fri, 5 Dec 2008 06:22:01 +0000 (UTC) (envelope-from antab@valka.is) Received: from dumb.farm.antab.is (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id mB567tmr047766; Fri, 5 Dec 2008 07:08:08 +0100 (CET) (envelope-from antab@valka.is) Message-Id: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> From: Arnar Mar Sig To: "M. Warner Losh" In-Reply-To: <20081204.153726.-1548257878.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 07:07:55 +0100 References: <20081204.153726.-1548257878.imp@bsdimp.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: embedded@freebsd.org Subject: Re: Looking to formalize board support in embedded platforms. X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 06:22:02 -0000 On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote: > I've spent a little bit of time implementing the start of board files > for the arm port. The initial push has been for the at91 subport only, > and many improvements could be made to this. I've written up my > initial thoughts on this on the FreeBSD wiki > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much > improvement, I'm sure. Some comments: What is the point of a std.* file for every board, cant this be in the config file? I can understand the reason for having std.at91 and std.xscale that board configs can include to set cpu dependent options. But imo it would be cleaner to skip the std.* files for the boards. "There's some suggestions that there be a separate "boards" directory. I'm not sure that I like it." Depends on have many board we have, with 2 board it doesn't matter much, but with 10+ board all with a separate std.*, *.c and maybe files.* then its probably best to add the "boards" directory. > > One idea that hasn't been reflected there yet, was shown to me by Sam > Laffler who suggested using linker sets to allow boards to 'probe', > 'init' and other standardized functions. This is an interesting idea > and I plan on working on adding it to the above links when Sam has > results to share. Sounds interesting > > I'd also like to expand the above wiki page to be a 'best practices' > guide for all architectures where there's great diversity of > boards/cpus/etc (eg, not the homogeneous env that x86 provides). Good thing. > > I'm also soliciting comments on the above boards in addition to the > above. Send them to me, or post them here. > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org > " Another thing semi related to board settings, device clocks. I see that in some of the device drivers for at91 the peripheral input clock is hard coded. This is probably fine for cpu's with one clock zone (don't know if at91 has one or many), but for cpu's like avr32 where you have many clock zones and peripherals can be connected to any one of them then hard coding this will not work. I think we need a clock framework (extension to the device driver framework?) to be able to lookup the peripherals input clock so the driver can calculates its prescalers right. This would also allow use to dynamically change the frequency for zones to get better power efficiency. Greets Arnar Mar Sig Valka ehf From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 5 06:29:56 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1D6A1065670 for ; Fri, 5 Dec 2008 06:29:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2E98FC08 for ; Fri, 5 Dec 2008 06:29:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB56S97L001105; Thu, 4 Dec 2008 23:28:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 04 Dec 2008 23:28:13 -0700 (MST) Message-Id: <20081204.232813.-1592326736.imp@bsdimp.com> To: antab@valka.is From: "M. Warner Losh" In-Reply-To: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> References: <20081204.153726.-1548257878.imp@bsdimp.com> <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: Looking to formalize board support in embedded platforms. X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 06:29:56 -0000 In message: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> Arnar Mar Sig writes: : On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote: : > I've spent a little bit of time implementing the start of board files : > for the arm port. The initial push has been for the at91 subport only, : > and many improvements could be made to this. I've written up my : > initial thoughts on this on the FreeBSD wiki : > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much : > improvement, I'm sure. : Some comments: : What is the point of a std.* file for every board, cant this be in the : config file? I can understand the reason for having std.at91 and : std.xscale that board configs can include to set cpu dependent : options. But imo it would be cleaner to skip the std.* files for the : boards. The thinking here is that each of the board defines a certain set of things that are standard for all users of that board, and that the kernel config just stitches together the non-board specific parts for the kernel. Each of these boards may have slightly different load addresses, and the like, and putting that in the kernels for the board is very repetitive and error prone. It is a hierarchy: boards define the most specific thing, and then include the next more general thing (usually the SoC definitions), which in turn includes the next more general thing (say, the family of devices) and so on until we get to the std.arm file which is what's standard for all arm boards. In any event, that's why it is there. I'll keep track of your comments. It may mean that how we're doing things is wrong, and your reaction to the solution to the wrongness informs us that something else is wrong... I'm not sure yet... : "There's some suggestions that there be a separate "boards" directory. : I'm not sure that I like it." : Depends on have many board we have, with 2 board it doesn't matter : much, but with 10+ board all with a separate std.*, *.c and maybe : files.* then its probably best to add the "boards" directory. I'll keep that in mind. You may be right... : > One idea that hasn't been reflected there yet, was shown to me by Sam : > Laffler who suggested using linker sets to allow boards to 'probe', : > 'init' and other standardized functions. This is an interesting idea : > and I plan on working on adding it to the above links when Sam has : > results to share. : Sounds interesting I'm very interested to see how his experiments work out. : > I'd also like to expand the above wiki page to be a 'best practices' : > guide for all architectures where there's great diversity of : > boards/cpus/etc (eg, not the homogeneous env that x86 provides). : Good thing. I hope so... : > I'm also soliciting comments on the above boards in addition to the : > above. Send them to me, or post them here. : > _______________________________________________ : > freebsd-embedded@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded : > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org : > " : : : Another thing semi related to board settings, device clocks. : I see that in some of the device drivers for at91 the peripheral input : clock is hard coded. This is probably fine for cpu's with one clock : zone (don't know if at91 has one or many), but for cpu's like avr32 : where you have many clock zones and peripherals can be connected to : any one of them then hard coding this will not work. The AT91 has several clock zones. We're trying to move away from having these clocks hard coded. It works for the moment, but doesn't scale well. We also need a generic hierarchical clock framework as well, since differing clock domains are a common feature of embedded processors. : I think we need a clock framework (extension to the device driver : framework?) to be able to lookup the peripherals input clock so the : driver can calculates its prescalers right. This would also allow use : to dynamically change the frequency for zones to get better power : efficiency. Absolutely! On the AT91 there's also a number of different ways to drive the core CPU frequency that help save energy, at the cost of a slight increase in latency to the memory chips. Some folks want less energy use, others want faster RAM access to improve their execution times (some folks are greedy and want both). Having the ability to control the clock domains would help this out a lot. This is an area that's rich for research, I think. People have done some interesting things here in Linux, and I think we can learn from their successes and failures. Thanks again for all your comments! I appreciate them. Warner : Greets : Arnar Mar Sig : Valka ehf : : From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 5 08:33:28 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D83C7106568E for ; Fri, 5 Dec 2008 08:33:28 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mr0.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 32DBD8FC26 for ; Fri, 5 Dec 2008 08:33:28 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L8W7o-0005kz-VD; Fri, 05 Dec 2008 11:33:25 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 756FD398F4; Fri, 5 Dec 2008 11:35:07 +0300 (MSK) Date: Fri, 5 Dec 2008 11:35:02 +0300 From: Stanislav Sedov To: Andrew Duane Message-Id: <20081205113502.f9871231.stas@FreeBSD.org> In-Reply-To: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> References: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__5_Dec_2008_11_35_02_+0300_nlqVJjlEj+LW03Ob" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-embedded@freebsd.org Subject: Re: How to support a TrueIDE (ATA) NANDrive chip X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 08:33:28 -0000 --Multipart=_Fri__5_Dec_2008_11_35_02_+0300_nlqVJjlEj+LW03Ob Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 4 Dec 2008 17:23:41 -0500 Andrew Duane mentioned: > We have an SST NANDrive chip on our board that supports the simple ATA > command set. What's the easiest way to get support for this into our > kernel so we can partition and mount the device? > > Using "da" and "umass" isn't really an option, since it is neither SCSI, > nor attached to USB. Pulling in all of "ata" seems like overkill; all we > really need is read/write block and some simple sense commands. They are > all synchronous, it's low traffic and we are more concerned with > simplicity than performance. Is there some subset of "ata" I can use > that won't involve pci bus, controllers, etc? We just want to be able to > write the LBA, SECT_CNT, and GO command and read the data. > Why not attach the ATA stack to the register space the chip provides. Doesn't look like an overkill to me. It should work pretty well. I'm using something like this for AT91 CF controller. I'v attached it source, it might be useful to you. It's simple enough. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkk457sACgkQK/VZk+smlYHvAQCfYOd+soOVtbmLr1mFC51irI3w YnQAni7TgWtsukf4ZcOS1lR9r/qAynyu =H60J -----END PGP SIGNATURE----- --Multipart=_Fri__5_Dec_2008_11_35_02_+0300_nlqVJjlEj+LW03Ob-- From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 5 15:30:09 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228D3106564A for ; Fri, 5 Dec 2008 15:30:09 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id D9E0F8FC08 for ; Fri, 5 Dec 2008 15:30:08 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mB5F8k1G017532 for ; Fri, 5 Dec 2008 08:08:47 -0700 Message-ID: <493943FC.8080001@semihalf.com> Date: Fri, 05 Dec 2008 16:08:44 +0100 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: Subject: i2c(8) diagnostic tool for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 15:30:09 -0000 This nice little program is helpful with inspecting an I2C bus, when bringing up a new system, or just for diagnostic purposes: http://people.freebsd.org/~raj/patches/misc/i2c.diff Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated start' method. More detailed description of the tool is in the manual page: http://people.freebsd.org/~raj/patches/misc/i2c-man.txt Any comments welcome. Rafal From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 5 19:09:06 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CF921065677; Fri, 5 Dec 2008 19:09:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F11438FC0A; Fri, 5 Dec 2008 19:09:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB5J80kA015964; Fri, 5 Dec 2008 12:08:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 05 Dec 2008 12:08:06 -0700 (MST) Message-Id: <20081205.120806.1661913579.imp@bsdimp.com> To: stas@freebsd.org From: "M. Warner Losh" In-Reply-To: <20081205113502.f9871231.stas@FreeBSD.org> References: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> <20081205113502.f9871231.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: How to support a TrueIDE (ATA) NANDrive chip X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 19:09:06 -0000 In message: <20081205113502.f9871231.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Thu, 4 Dec 2008 17:23:41 -0500 : Andrew Duane mentioned: : : > We have an SST NANDrive chip on our board that supports the simple ATA : > command set. What's the easiest way to get support for this into our : > kernel so we can partition and mount the device? : > : > Using "da" and "umass" isn't really an option, since it is neither SCSI, : > nor attached to USB. Pulling in all of "ata" seems like overkill; all we : > really need is read/write block and some simple sense commands. They are : > all synchronous, it's low traffic and we are more concerned with : > simplicity than performance. Is there some subset of "ata" I can use : > that won't involve pci bus, controllers, etc? We just want to be able to : > write the LBA, SECT_CNT, and GO command and read the data. : > : : Why not attach the ATA stack to the register space the chip provides. : Doesn't look like an overkill to me. It should work pretty well. : I'm using something like this for AT91 CF controller. I'v attached : it source, it might be useful to you. It's simple enough. I'd concur. I believe that we can configure the ata stuff such that we don't get pci, et al, in this case. If not, we should fix that. Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 6 10:26:16 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6D41065673 for ; Sat, 6 Dec 2008 10:26:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 93B228FC18 for ; Sat, 6 Dec 2008 10:26:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C28621CF6A3; Sat, 6 Dec 2008 05:09:11 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 06 Dec 2008 05:09:11 -0500 X-Sasl-enc: DLJF/W1MiYyP/wVowzc9fi1imyoDm7HX007ZBYdr4rqj 1228558151 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id EC89BB4E8; Sat, 6 Dec 2008 05:09:10 -0500 (EST) Message-ID: <493A4F45.9040105@FreeBSD.org> Date: Sat, 06 Dec 2008 10:09:09 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Rafal Jaworowski References: <493943FC.8080001@semihalf.com> In-Reply-To: <493943FC.8080001@semihalf.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: i2c(8) diagnostic tool for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 10:26:16 -0000 Looks good, though I haven't built or tested it. I've found smbmsg to be very useful, although of course if you are working with raw i2c, it's not useful. I noticed that the x1226 clock chip doesn't seem to show up on the NSLUG atthe i2c address I'd expect it to, this will come in very useful for that. I am doubtful I'll get free time to look at that right away-- I have new stuff brewing and want to try to hand off stuff where possible. cheers BMS From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 6 14:45:58 2008 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271C61065679 for ; Sat, 6 Dec 2008 14:45:58 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mr0.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 75F0C8FC1B for ; Sat, 6 Dec 2008 14:45:57 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L8xxg-0008Cr-7R; Sat, 06 Dec 2008 17:16:48 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 5B4D13996C; Sat, 6 Dec 2008 17:18:29 +0300 (MSK) Date: Sat, 6 Dec 2008 17:18:29 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-Id: <20081206171829.82f0618a.stas@FreeBSD.org> In-Reply-To: <493943FC.8080001@semihalf.com> References: <493943FC.8080001@semihalf.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: i2c(8) diagnostic tool for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 14:45:58 -0000 On Fri, 05 Dec 2008 16:08:44 +0100 Rafal Jaworowski mentioned: > This nice little program is helpful with inspecting an I2C bus, when bringing > up a new system, or just for diagnostic purposes: > http://people.freebsd.org/~raj/patches/misc/i2c.diff > > Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated > start' method. > > More detailed description of the tool is in the manual page: > http://people.freebsd.org/~raj/patches/misc/i2c-man.txt > > Any comments welcome. > Great! I haven't tried the tool itself yet, but there're some comments for the source itself. Hopefully, it'll be useful. > +The options are as follows: > +.Bl -tag -width ".Fl d Ar direction" > +.It Fl a Ar address > +7-bit address on the I2C device to operate on (hex). > +.It Fl f Ar device > +I2C bus to use (default is /dev/iic0). > +.It Fl d Ar r|w > +transfer direction: r - read, w - write. > +.It Fl w Ar 0|8|16 > +device addressing width (in bits). > +.It Fl o Ar offset > +offset within the device for data transfer (hex). > +.It Fl c Ar count > +number of bytes to transfer (dec). > +.It Fl m Ar ss|rs|no > +addressing mode, i.e., I2C bus operations performed after the offset for the > +transfer has been written to the device and before the actual read/write > +operation. rs - repeated start; ss - stop start; no - none. > +.It Fl v > +be verbose I think options here should come sorted if there're no specific needs. At least -v in the middle looks weird. > +.if ${MACHINE_ARCH} == "arm" > +_i2c= i2c > +.endif It there any specific reason the utility is limited to arm? I2C interface is generic enough, and I think the utility will be useful for other platforms as well. > +#define I2C_DEV "/dev/iic0" > +#define I2C_MODE_NOTSET 0 > +#define I2C_MODE_NONE 1 > +#define I2C_MODE_STOP_START 2 > +#define I2C_MODE_REPEATED_START 3 #define and name should delimited by tab according to style(9) > +static void > +usage(void) > +{ > + > + fprintf(stderr, "usage: %s -a addr [-f device] [-d [r|w]] [-o offset] " > + "[-w [0|8|16]] [-c count] [-m [ss|rs|no]] [-b] [-v]\n", > + getprogname()); > + fprintf(stderr, " %s -s [-f device] [-n skip_addr] -v\n", > + getprogname()); > + fprintf(stderr, " %s -r [-f device] -v\n", getprogname()); > + exit(1); > +} You're using sysexit codes everywhere, I suppose the exit code here should be EX_USAGE too? At least, it looks inconsistent to other parts of the code. Also it might make sense to mark the function as __dead2 as it never returns. This will enable a number of possible optimisations to gcc. > + token = strsep(&skip_addr, ".."); > + if (token) > + addr_range.end = strtoul(token, 0, 16); > + } I think there's a check missing around strtoul? > + if (token == NULL) > + break; > + sk_addr[i] = strtoul(token, 0, 16); > + } The same as above. > + tokens = (int *)malloc((len / 2 + 1) * sizeof(int)); > + index = skip_get_tokens(skip_addr, tokens, > + len / 2 + 1); > + } The check around malloc is missing. Also, len should be checked to be non-zero. > +prepare_buf(int size, uint32_t off) > +{ > + char *buf; > + > + buf = malloc(size); > + if (buf == NULL) > + return (buf); Consider adding a check around size. > +static int > +i2c_write(char *dev, struct options i2c_opt, char *i2c_buf) > +{ > + struct iiccmd cmd; > + int ch, i, error, fd, bufsize; > + char *err_msg, *buf; > + > + /* > + * Read data to be written to the chip from stdin > + */ > + if (i2c_opt.verbose && !i2c_opt.binary) > + fprintf(stderr, "Enter %u bytes of data: ", i2c_opt.count); > + > + for (i = 0; i < i2c_opt.count; i++) { > + ch = getchar(); > + if (ch == EOF) { > + free(i2c_buf); > + err(1, "not enough data, exiting\n"); > + } > + i2c_buf[i] = ch; > + } > + > + fd = open(dev, O_RDWR); > + if (fd == -1) { > + free(i2c_buf); > + err(1, "open failed"); > + } > + > + /* > + * Write offset where the data will go > + */ > + cmd.slave = i2c_opt.addr; > + error = ioctl(fd, I2CSTART, &cmd); > + if (error == -1) { > + err_msg = "ioctl: error sending start condition"; > + goto err1; > + } > + > + if (i2c_opt.width) { > + bufsize = i2c_opt.width / 8; > + buf = prepare_buf(bufsize, i2c_opt.off); > + if (buf == NULL) { > + err_msg = "error: offset malloc"; > + goto err1; > + } > + > + cmd.count = bufsize; > + cmd.buf = buf; > + error = ioctl(fd, I2CWRITE, &cmd); > + free(buf); > + if (error == -1) { > + err_msg = "ioctl: error when write offset"; > + goto err1; > + } > + } You're freeing i2c_buf on every exit, but not here. Why? Probably, it'll be better to move the buffer freeing duty to the calling function as the i2c_buf comes as an argument. It'll also help to eliminate a lot of code here. There're also a lot of places where buffer is not freed later in this function. > + i2c_opt.addr = (strtoul(optarg, 0, 16) << 1); > + i2c_opt.addr_set = 1; > + break; > + case 'f': > + dev = optarg; > + break; > + case 'd': > + i2c_opt.dir = optarg[0]; > + break; > + case 'o': > + i2c_opt.off = strtoul(optarg, 0, 16); > + break; > + case 'w': > + i2c_opt.width = atoi(optarg); > + break; > + case 'c': > + i2c_opt.count = atoi(optarg); > + break; > + case 'm': I think the checks around strtoul and atoi should be added to properly inform user about bad arguments passed, instead of just silently ignoring junk. > + if (i2c_opt.scan) { > + if (i2c_opt.addr_set) > + usage(); > + } else if (i2c_opt.reset) { > + if (i2c_opt.addr_set) > + usage(); > + } else if ((i2c_opt.dir == 'r' || i2c_opt.dir == 'w')) { > + if ((i2c_opt.addr_set == 0) || > + !(i2c_opt.width == 0 || i2c_opt.width == 8 || > + i2c_opt.width == 16)) > + usage(); > + } else > + usage(); I think this code could be simplifed, e.g. checks could be combined into a single if, like else if (i2c_opt.reset && i2c_opt.addr_set) an eliminating the default usage() case. There're also a number of minor spelling errors and extra spaces, I can look for them if needed. Thanks for a good work! -- Stanislav Sedov ST4096-RIPE