Ok, before I explain the specifics, let me review what I know of w1. Much of this was worked out consulting Evgeniy Polyakov, the kernel developer responsible for the system.
w1 (now called wire) was designed as part of the hardware sensors system, with a wire kernel module, and subsystems support various bus masters (usb, gpio but not serial or i2c). The communication is via netlink (a local socket-based protocol) but with some limitations: 1. the connector protocol is layers over it. 2. only root processes can connect to netlink 3. only one netlink socket is supported (a "party line" for those old enough to understand the allusion.) 4. bus masters and "slaves" devices are handled dynamically, but grouped together. 5. there seems to be some limits imposed on the number of slaves allowed. It's probably configurable, and perhaps there is a limit of masters -- I don't have the resources to test. Within the netlink/connector protocol, there is a w1 message protocol, with message types (including broadcast messages) sub messages, and variable payloads). Fortunately the actuial implementation is simpler than the defined protocol, with only a simgle message per packet actually used. Evgeniy added generic support for us, so OWFS can use w1 as a bus master. We still have to get a little fancy, reading all the netlink messages, and distributing them the the correct thread in the program, as well as watching for time outs and broadcast messages. Paul Alfille On Thu, Oct 14, 2010 at 7:39 PM, Mauricio Culibrk <[email protected]> wrote: > > After some more digging through kernel code (connector, w1_netlink etc.) I > think I found some discrepancies in few includes. > The problem is I'm not too familiar with the details of connector/netlink > programming (netlink groups, ids, sequences etc) > > Ok, I'll try to explain my findings in short words. > > I'm using kernel 2.6.34.5 on the current platform. In the kernel > include/linux/connector.h are a few defines > CN_W1_IDX 3 > CN_W1_VAL 1 > CN_NETLINK_USERS 8 > > on the other side, owfs (using version 2.8p2) has some includes of its own - > namely owlib/src/include/connector.h which also has the same defines but > with slightly different values: > CN_W1_IDX 3 > CN_W1_VAL 1 > CN_NETLINK_USERS 5 > > for what I understanf this CN_NETLINK_USERS value is used just in the kernel > connector initialization and defines the "maximum connector/netlink group" > as CN_NETLINK_USERS + 0xf > The only place where I noticed the usage of the nl_grup in in > owlib/src/c/ow_w1_bind.c - line 53 - l_local.nl_groups = 23 > This should be ok (in limits) if the CN_NETLINK_USERS is defined as 8 (which > it should be in the kernel include) - 8 + 0xf gives 23, but if the > cn_netlink_users is used from the connector.h found in owfs the value of 23 > is "out of bounds". I'm not sure if that "group number" is defined/used also > somewhere else.... so I'm asking could this difference cause any harm? > > Why owfs brings it's own connector.h instead of using the kernel provided > one? > > The other maybe more problematic issue is in the file > owlib/src/include/w1_netlink.h where I found this > > #ifndef CN_W1_IDX > #define CN_W1_IDX 4 > #define CN_W1_VAL 1 > #endif > > As I'm not sure where this "w1_netlink.h" is used and which value is > "actually active" at the compile time I cannot tell for sure, but this > surely could procure some issues, right? > > I did not test (changed and recompiled) any of this so maybe this is all > just "spam" but maybe someone could enlighten the situation a little. > > Best regards, > Mauricio Culibrk > > > On Thu, 14 Oct 2010 15:22:00 -0400 > Paul Alfille <[email protected]> wrote: >> I certainly know the internals. >> >> I don't know if it's endian sensitive. I used the kernel headers >>from >> the netlink for the netlink information. Can I send you an >> "instrumented" owfs version that will print out more detail? >> >> Paul Alfille >> >> 2010/10/14 Mauricio Culibrk <[email protected]>: >>> >>> Hi again! >>> >>> After some more frustration I recompiled the kernel and all modules >>>with >>> dynamic debugging enabled (dynamic_printk) and after re-flashing the >>>board >>> enabled all debug messages for wire.ko kernel module (w1-master >>>kernel >>> module). >>> >>> After starting owserver/owfs... I thought the wire would give some >>>"debug >>> messages" of netlink messages passwd from the user-space (I checked >>>the >>> source code of the wire module and saw some points where the debug >>>message >>> should be printed if anything get to the module) and... >>> >>> nothing! the kernel module receives absolutely no messages from >>> user-space... >>> >>> Could, please, someone which knows some "internals" on >>>owfs/netlink/kernel >>> w1 point me to the "right direction"? >>> >>> Is it possible the owfs/kernel-w1 code is "endian sensitive"? I'm >>>currently >>> using the code on a little endian board... (still had no time to >>>test on >>> another board) >>> >>> Any hint would be really appreciated. >>> >>> Anyone could tell me if there are any other "special requirements" - >>>any >>> libraries, kernel modules, settings... regarding owfs/kernel-w1 >>>interaction? >>> >>> Best regards, >>> m.culibrk >>> >>> >>> On 10/14/2010 11:20 AM, Gregg Levine wrote: >>> >>> On Thu, Oct 14, 2010 at 4:05 AM, Mauricio Culibrk >>><[email protected]> >>> wrote: >>> >>> Hi! >>> >>> I'm sorry for bothering but I'm starting pulling my hair on this >>>problem I >>> have... >>> I tried to search the mailing lists and elsewhere but I'm unable to >>>find any >>> relevant information... >>> >>> The goal is to make owfs work with the kernel w1-gpio-master driver. >>> >>> I'm trying to setup the owfs on an embedded board - really a >>>"router" - >>> netgear wgt634u - a mips (LE) based machine using the kernel w1-gpio >>>master >>> driver and a spare gpio pin. >>> The software (os) used is OpenWrt trunk r23070 (build from scratch) >>>with >>> kernel 2.6.34.5. >>> >>> Linux WGT634U 2.6.34.5 #1 Wed Oct 13 16:10:34 CEST 2010 mips >>>GNU/Linux >>> >>> The W1 subsystem is actually working good. >>> After loading all the required modules: >>> fuse 49168 0 >>> w1_gpio 752 0 >>> w1_gpio_custom 864 0 >>> wire 17584 1 w1_gpio >>> cn 4336 1 wire >>> nfnetlink 1712 0 >>> >>> Netfilter messages via NETLINK v0.30. >>> Driver for 1-wire Dallas network protocol. >>> Custom GPIO-based W1 driver version 0.1.1 >>> w1_master_driver w1 bus master: Family 10 for 10.00080198f8e6.d8 is >>>not >>> registered. >>> >>> I can see the w1 bus and the attached DS18S20 slave: >>> >>> r...@wgt634u:~# ls /sys/bus/w1/ >>> devices drivers drivers_autoprobe >>>drivers_probe >>> uevent >>> >>> r...@wgt634u:~# ls /sys/bus/w1/devices/ >>> 10-00080198f8e6 w1 bus master >>> >>> If I also load the kernel w1-thermal driver I can see the w1 system >>>is >>> actually working as expected. I can read the temperature from the >>>sensor: >>> >>> r...@wgt634u:~# ls /sys/bus/w1/devices/10-00080198f8e6/ >>> driver id name subsystem uevent w1_slave >>> >>> r...@wgt634u:~# cat /sys/bus/w1/devices/10-00080198f8e6/w1_slave >>> 30 00 4b 46 ff ff 09 10 12 : crc=12 YES >>> 30 00 4b 46 ff ff 09 10 12 t=24187 >>> >>> Other than for testing the kernel w1-slave-thermal driver is not >>>loaded, >>> just the w1-gpio master driver is. >>> >>> I'm using the latest owfs sources: >>> r...@wgt634u:~# owfs -V >>> owfs version: >>> 2.8p2 >>> libow version: >>> 2.8p2 >>> >>> So, to the problem! >>> I'm unable to make owfs/owserver/owhttps to "work/talk" with the w1 >>>kernel >>> driver. >>> After starting the owfs/owserver it "hungs" for some reason. Here is >>>the >>> debug output: >>> >>> r...@wgt634u:~# owserver --w1 --debug -p 4000 >>> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[] >>> DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C >>>100C (for >>> simulated adapters) >>> DEBUG: owserver.c:main(152) main_threadid = 715849728 >>> DEBUG: ow_w1_list.c:w1_list_masters(54) Sending w1 bus master list >>>message >>> DEBUG: ow_w1_send.c:W1_send_msg(119) Netlink send >>>----------------- >>> NLMSGHDR: len=48 type=3 (NLMSG_DONE) flags=0 seq=0|1 pid=880 >>> CN_MSG: idx/val=3/1 (CN_W1_IDX) seq=0|1 ack=1 len=12 flags=0 >>> W1_NETLINK_MSG: type=6 (W1_LIST_MASTERS) len=0 id=0 >>> Byte buffer Data, length=0 >>> <> >>> DEBUG: ow_w1_dispatch.c:W1_Dispatch(125) Dispatch loop >>> DEBUG: ow_w1_parse.c:Netlink_Parse_Get(114) Wait to peek at >>>message >>> DEBUG: ow_w1_parse.c:Netlink_Parse_Get(122) Pre-parse header: 16 >>>bytes >>> len=52 type=3 seq=0|1 pid=0 >>> DEBUG: ow_w1_parse.c:Netlink_Parse_Get(144) Netlink read >>>----------------- >>> NLMSGHDR: len=52 type=3 (NLMSG_DONE) flags=0 seq=0|1 pid=0 >>> CN_MSG: idx/val=3/1 (CN_W1_IDX) seq=0|1 ack=0 len=16 flags=0 >>> W1_NETLINK_MSG: type=6 (W1_LIST_MASTERS) len=4 id=65544 >>> Byte buffer Data, length=4 >>> --000: 01 00 00CONNECT: ow_zero.c:ZeroConf_Announce(144) Zeroconf >>>and/or >>> Multithreading are not enabled >>> 00 >>> <....> >>> DEBUG: ow_w1_dispatch.c:Dispatch_Packet(92) Sending this packet to >>>root >>> bus >>> DEBUG: ow_w1_dispatch.c:W1_Dispatch(125) Dispatch loop >>> DEBUG: ow_w1_parse.c:Netlink_Parse_Get(114) Wait to peek at >>>message >>> DEBUG: ow_w1_list.c:w1_parse_master_list(64) W1 List 1 masters >>> DEBUG: ow_w1_parse.c:Netlink_Parse_Get(122) Pre-parse header: 16 >>>bytes >>> len=48 type=3 seq=0|1 pid=0 >>> >>> It seems to me the owfs is somehow having problems communicating >>>with the >>> kernel w1 driver. >>> I have no more ideas on what to try/what to check. >>> Well, I'm really new to the owfs stuff but otherwise I have quite >>>some >>> experience with OpenWrt, kernel modules/programming, 1-wire etc. >>> I took me some tries to figure out the OpenWrt W1 modules makefiles >>>are >>> "broken" for proper support of the w1 kernel driver... it's missing >>>the >>> "connector" suport by default. >>> I tried to compile the kernel & w1 modules "by hand" and to set all >>>the >>> required options but the results were the same - no fun. >>> >>> I did not have time to test this identical setup on another >>>platforms (mipe >>> BE (atheros) boards, ixp425 boards, sheevaplugs). Also, I have not >>>tried >>> some i2c/usb/serial w1-masters as I not have them handy right now >>>(basicaly >>> just to test owfs is working) - but I really need it to work with >>>the kernel >>> w1-gpio driver... >>> >>> As far as I checked, owfs should work with the w1-gpio as I found >>>quite a >>> lot of information about that, well, reference to other problems but >>>the >>> "core" owfs <--> kernel-w1-gpio seems to be working/supported. >>> >>> Any suggestion/information would be more than welcome. >>> >>> Best regards, >>> M.Culibrk >>> >>> ------------------------------------------------------------------------------ >>> >>> Hello! >>> Actually you're heading the right direction completly. Why not post >>> someplace your build steps. Such as how you created that run of >>> "OpenWrt trunk r23070", and then the methods to compile it. Finally >>> how you installed onto your router. Also was the router properly >>> reinitialized after the whole steps. >>> >>> Also did you test the One-Wire hardware elsewhere first? Then on the >>> router, and finally back again. List what happened when you tried to >>> use the One-Wire hardware to sense room temperature via your Linux >>> system. >>> >>> Also list what distribution you used for that. >>> >>> And no you did not bother us. >>> ----- >>> Gregg C Levine [email protected] >>> "This signature fought the Time Wars, time and again." >>> >>> >>> ------------------------------------------------------------------------------ >>> Beautiful is writing same markup. Internet Explorer 9 supports >>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >>> Spend less time writing and rewriting code and more time creating >>>great >>> experiences on the web. Be a part of the beta today. >>> http://p.sf.net/sfu/beautyoftheweb >>> _______________________________________________ >>> Owfs-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> >>> >>> ------------------------------------------------------------------------------ >>> Beautiful is writing same markup. Internet Explorer 9 supports >>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >>> Spend less time writing and rewriting code and more time creating >>>great >>> experiences on the web. Be a part of the beta today. >>> http://p.sf.net/sfu/beautyoftheweb >>> _______________________________________________ >>> Owfs-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Beautiful is writing same markup. Internet Explorer 9 supports >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >> Spend less time writing and rewriting code and more time creating >>great >> experiences on the web. Be a part of the beta today. >> http://p.sf.net/sfu/beautyoftheweb >> _______________________________________________ >> Owfs-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Owfs-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
