Date: Tue, 25 Mar 2008 15:32:27 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Bruce M Simpson <bms@incunabulum.net> Cc: nsouch@freebsd.org, FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: lpbb broken in 6.x? Message-ID: <Pine.BSF.3.96.1080325152322.21551B-100000@gaia.nimnet.asn.au> In-Reply-To: <47E7D003.3070009@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Mar 2008, Bruce M Simpson wrote: > Just for giggles, I decided to solder up the circuit in lpbb(4) and try > to use it to talk to a 24LC64 EEPROM with its i2c address set to 0. > (Yes, I am using 74LS05s specifically for this circuit.) > > Imagine my surprise and dismay, when I try to test out the i2c bus using > this tool: > http://www.ricin.com/freebsd/kbtv/kbtv-1.1.3/saa/saa/support/scan_i2c.c > > ...and keep seeing this on the console, presumably whenever scan_i2c > issues an iic(4) ioctl: > lpbb0: can't allocate ppbus Bearing in mind that I'm looking at RELENG_5 sources (lpbb.c 1.18), and that there have been a bunch of commits to iicbus mostly by Warner a year ago .. that message can be printed in lpbb_detect or lpbb_reset .. but if lpbb_detect failed I don't see how lpbb_probe could succeed, yet device_set_desc seems to have succeeded, according to first line below. > I made sure that no other devices were attached to ppbus0. Voltages on > the port and the bus looked sane... SCL and SDA stable below 0.1V, If the bus were successfully reset, these should both be nearer 5V, 0.1V being signal active low, which isn't a desirable bus state indefinitely. > nothing floating, good solid +5V on the supply rail using a 7805 > regulator on a 9V battery to avoid any nasty current surprises -- I > haven't fried my laptop's LPT port. That's good :) > Initially I had ppi loaded as well, I booted a clean kernel and loaded > lpbb from the loader: > > Mar 24 15:40:39 empiric kernel: lpbb0: <Parallel I2C bit-banging > interface> on ppbus0 > Mar 24 15:40:39 empiric kernel: iicbb0: <I2C bit-banging driver> on lpbb0 > Mar 24 15:40:39 empiric kernel: iicbus0: <Philips I2C bus> on iicbb0 > master-only > Mar 24 15:41:10 empiric kernel: iic0: <I2C generic I/O> on iicbus0 > Mar 24 15:41:10 empiric kernel: iic1: <I2C generic I/O> on iicbus0 > > Not sure why iic attaches twice to the iicbus created by lpbb. There are comments with iicbus.c saying that hints are now required, but without recent sources to hand I'm a bit lost. Certainly the diffs to the RELENG_5 sources that I've been trying to sus out are extensive. > However, I still got the same message when I re-ran scan_i2c: > > Mar 24 15:41:19 empiric kernel: lpbb0: can't allocate ppbus > Mar 24 15:41:55 empiric last message repeated 1020 times > > There are real uses for this code, so I'm wondering, what's wrong with lpbb? > > Does lpbb explicitly require hints to be told where to attach? > IMO it shouldn't, it already seems to attach to the first ppbus instance > in the system. > > If I get free time otherwise, I'll try to investigate further. I'm sure Warner will deliver the goods .. probably still partying :) Reason I chimed in is that I was hoping to use lbpp myself last year, figuring it should be fast enough to snoop on an I2C-compatible bus running at 400kHz between a couple of AVR tiny45s for debugging, data acquisition and control, however a) it - or rather iicbb(4) - is a master-only interface and b) the slew of DELAY(10)s even mid-bit in iicbb means it can never get anywhere near even 'standard' 100kbps. To finish off completely hijacking your thread :) does anyone know of anything that can run a master/slave interface like pcf(4) which appears to have been an ISA bus only device? I don't have C skills to write one, though 400kHz master and slave routines in AVR asm were fun :) Later: after nearly losing this in a pine crash (don't ask), I've since seen John's reply to your later message. Could it be that smbus or something is also using iicbus rather than something messing with ppbus? cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080325152322.21551B-100000>