Re: LED support for ALIX 2/3 series
On Wednesday 15 December 2010 12:38:23 Emanuel Haupt wrote: > Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series > [2]? The following version uses linux API's. > > I'd gladly write a port for it if someone could port it. > > Emanuel > > [1] http://people.freebsd.org/~ehaupt/misc/leds-alix-0.0.1/leds-alix.c > [2] http://www.pcengines.ch/ > Hi, we have in CURRENT gpio framework with gpioctl control program and gpioled device. I think we should use this approach instead. In past I tested something similar on WRAP (older product, ALIX could be considered ancestor of it) and it works. Also, if you look at sys/i386/geode.c, there is already something written, which should be working... Regards, Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: how to use iic(4)
On Tuesday 25 September 2007 06:13:10 John-Mark Gurney wrote: > Ian Smith wrote this message on Sat, Sep 22, 2007 at 13:16 +1000: > > This drew a blank in -questions. I don't know where else to post it, so > > I'm hoping someone here might be able to spare me a clue. > > You should probably have posted this question to -hackers instead.. > This is more low level hardware than networking... > ... > > You need to have a device that connects between your i2c bus hardware > and iicbb or iicbus... I'm not familar w/ lpbb, but I have used > /dev/iic? w/ some HD capture card drivers I've written, and they are > created when the device driver probes them... lpbb may need hints to > get it to attach, or may need a properly functioning parallel port.. > > > Also, iicbb(4) is said to be a master-only interface. I can work with > > that, but if anyone knows of any iicbus slave-mode code I'm all eyes .. > > That's even more complicated as you either need specialized hardware > that will detect when your i2c address is on the bus, or you need to > poll/interrupt on line changes, which could get a bit expensive... > > I have a command line iic program that I used to help debug my drivers.. > The tool lets you start and then read/write from the device, and then > stop the bus... > > I haven't committed it yet, because a few other developers want it under > tools, and I don't like it there, as no one knows about most of the > tools under there... Maybe if we had a man page that talked about the > tools available there it'd be more attractive... Could you post it somewhere? Web, maybe... I was trying to write i2c driver for WRAP board, but failed. Now it's time to try again, maybe, (there is new generation WRAP board). It is definitely possible, there is an ACB driver in OpenBSD, but I did not gain knowledge to port it, the whole bus/driver infrastructure is too different... Regards, Milan -- No need to mail me directly. Just reply to mailing list, please. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode SC1100 i2c bus
On Sunday 04 February 2007 22:24, Cats wrote:
> I played a bit today with Geode registers.
>
> Well, I tried to tweak the /usr/src/sys/i386/i386/geode.c
>
> *** 198,203
> --- 198,207
> * people think their box just died.
> */
> led_func(&led1b, 1);
> + outb(0x2E,0x7); // Select LDN Page 80
> + outb(0x2F,0x2); // Put 02h in LDN to select IR Port
> + outb(0x2E,0x30); // Select Logical Device Control
> Register + outb(0x2F,inb (0x2F)+1); // Set LDCR[0] to
> enable IR port }
> if ( strlen(bios_oem) )
> printf("Geode %s\n", bios_oem);
>
> After rebooting with the new kernel I got this in the dmesg:
>
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 16550A, console
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> sio1 at port 0x2f8-0x2ff irq 3 on isa0
> sio1: type 16550A
>
> Yes, the IR port is seen as a standard serial port and I have the cuad1*
> and ttyd1* in the /dev
>
> Well of course none of IRRCX1 and IRTX pins are wired on the wrap board, so
> no way to test it.
>
> This might be a trick to enable the ACBbuses on the geode to have them
> recognized by a driver on the isa bus.
>
> Got to try when I'll have some spare time.
>
It will not work, there is much more to do. As shown in your test, even second
serial will not work because irq routing is not set. But I will try to
analyze Pascal's sources and compare it to my older work, maybe I can find
the problem, just wait a bit... I will keep you informed if I achieve any
progress...
Milan
--
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode SC1100 i2c bus
On Sunday 04 February 2007 21:21, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Milan Obuch <[EMAIL PROTECTED]> writes: > : On Sunday 04 February 2007 01:21, [EMAIL PROTECTED] wrote: > : > > > The ACB is at the same level than Uart, so I had a look at sio > : > > > source and got a big headache. I'm not really used to drivers > : > > > nor kernel programming stuff, that's why I need your help. > : > > > : > > Why do you compare ACB and UART? In FreeBSD, sio is serial i/o > : > > controller, not superIO, maybe you are confused... ACB and UART > : > > does not have much in common... > : > > : > As I read the OP, both the ACB and the serial are in the same chip > : > (the superIO), so it would seem reasonable to expect that the method > : > of accessing the device registers in the (currently unsupported) ACB > : > might be similar to the method of accessing the device registers in > : > the (supported) serial port. > : > : You are right from the point of view 'how to access registers'. But what > : OP wrote could be understand another way, too - he tried to modify sio to > : create acb driver, which would not achieve the correct results. There is > : i2c infrastructure in FreeBSD, acb driver should fit into its place there > : and it is not that easy - I tried to understand it, but nobody could/was > : willing to/did not care to help me understand it. > > I'm happy to help you understand it. > > Warner > Great, I will go through the code and will ask. What made me not achieve progress was lack of docs - this area is, ehm, under-documented, and lack of description in pcf, the only i2c hardware controller in source tree currently. Correct me, if I am wrong and there are more - but not smbus, they are not the same thing, even if very near to each other. SMbus controller in FreeBSD does not expose i2c device to userland, as far as I read it, but this was some time ago. I need some time to prepare myself, but I would like to get this working. There are some projects waiting for it... Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode SC1100 i2c bus
On Sunday 04 February 2007 01:21, [EMAIL PROTECTED] wrote: > > > The ACB is at the same level than Uart, so I had a look at sio > > > source and got a big headache. I'm not really used to drivers > > > nor kernel programming stuff, that's why I need your help. > > > > Why do you compare ACB and UART? In FreeBSD, sio is serial i/o > > controller, not superIO, maybe you are confused... ACB and UART > > does not have much in common... > > As I read the OP, both the ACB and the serial are in the same chip > (the superIO), so it would seem reasonable to expect that the method > of accessing the device registers in the (currently unsupported) ACB > might be similar to the method of accessing the device registers in > the (supported) serial port. > You are right from the point of view 'how to access registers'. But what OP wrote could be understand another way, too - he tried to modify sio to create acb driver, which would not achieve the correct results. There is i2c infrastructure in FreeBSD, acb driver should fit into its place there and it is not that easy - I tried to understand it, but nobody could/was willing to/did not care to help me understand it. > Note I said "reasonable" -- it may not be "accurate" -- and > this sort of analysis applies only to getting at the hardware. > Certainly the means of communicating with the rest of the OS > would be different, unless one wants the ACB to show up as sio7 > or some such :) > At hardware level, I consider it to be 'accurate', at OS level, they are completely different. Globally, at looks to me we basically do not disagree on subject, but that's just langauage ambiguity out there... Regards, Milan -- No need to mail me directly. Just reply to mailing list, please. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode SC1100 i2c bus
On Saturday 03 February 2007 17:10, Cats wrote: > Hello all, > Hi, > I've been looking for some technical infos and/or driver for the i2c bus on > the Geode SC1100 processor under FreeBSD 6. > I tried it too, but no success yet, partially due to ENOTIME :( > I found i2c stuff, tried to compile a kernel with it but nothing showed up. > I had a look at the sources and apparently it doesn't hook up to isa bus. > There is no driver yet. > From the geode databook, on page 11, i2c bus that is called ACB bus is in > the superIO block. This superIO block is attached on the isa bus. > Geode has hardware i2c controller. > The ACB is at the same level than Uart, so I had a look at sio source and > got a big headache. I'm not really used to drivers nor kernel programming > stuff, that's why I need your help. > Why do you compare ACB and UART? In FreeBSD, sio is serial i/o controller, not superIO, maybe you are confused... ACB and UART does not have much in common... > My goal is to use the i2c bus on a wrap board to supervise voltages, pilot > a servo motor and so on. I do not want to use USB because it's easier with > i2c and I already have i2c hardware ready. > > Does someone already tried to use i2c bus on a wrap board under FreeBSD ? > Well, the best I achieved was working bit-banged i2c for wrap's onboard lm77. I was able to read temperature and that's all. Unfortunatelly, external i2c bus works only with geode's hardware i2c controller, which I did not got into working state, internal bus can be switched into gpio mode, which works for me. But that is not really usefull. > I had a look at openbsd and looks like it has already i2c support, but I > ain't had time to build a system and test it on the wrap. For now all my > wrap boards run flawlessly with FreeBSD. > I looked there too, but OpenBSD has different infrastructure, and porting is not easy, at least for me. They have even some more Geode's resources working, but, again, porting is not easy for me. > I searched the mailing list archive but did not found something that could > help me. Remember I'm not really good at writing drivers stuff. I'd like to > learn but I have no start point. > All I can offer is bit-banged stuff, which I got into working state... Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
On Thursday 16 March 2006 14:57, Artem 'ZaZooBred' Ignatiev wrote: > On Thu, 16/03/2006 at 15:06 +0300, Artem 'ZaZooBred' Ignatiev wrote: > > > > > Yes, I've got some clearance in how that _if.m files are > > written, but bktr driver is too complex for me to understand how the > > things are done right now. I'll look at it again, though, maybe I could > > understand the logic of how such things are done, when I could clearly > > separate generic logic from implementation of particular hardware > > driver. > > Looks like I'm totally newbie there. I've created small saa_if.m file, > with CODE section, declaring two small debug functions, and two METHODS, > DEFAULTing to that functions. Now I want to update Makefile so that > typing ``make depend'' will produce .c and .h from the .m file. Looks > like /sys/conf/kmod.mk lists all .m files by name, and deals with them > on one-by-one basis, so I must manually insert all that awk -f ... > invocations for these targets, am I right? Not necessarily. You should put saa_if.m into kmod.mk, yes, but you should actually somewhere use it. > Or had I overlooked feature of automated codegeneration just in > Makefile? Could you show your Makefile? I think you are missing something there - like saa_if.h and saa_if.c, maybe... > P.S. I suppose, that it's worth to create some useful doc with skeleton > bus driver, one dummy method, and child driver overriding that method. > (As to me, the latest task is the easiest, at least I know how to do > this, e.g., PCI device overriding probe method). Any idea how? Maybe manpage patch? You know, every one welcomed :) > P.P.S Hey, that's my birthday! So I would like a toast to all BSD > developers, core team and hackers Mnoga ljeta, mnoga ljeta, mnoga ljeta... :) Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
On Thursday 16 March 2006 13:06, Artem 'ZaZooBred' Ignatiev wrote: ... > > > 2. SAA7146 uses I2C to communicate with tuners, and I know that there > > > are some I2C-related peaces already in kernel. I would like to reuse > > > that code, if possible, but can't figure out where to look and how to > > > link it in. > > > > There is some basis for i2c, look in /usr/src/sys/dev/iicbus directory. > > There are two kinds of i2c controllers - bit banged and full hardware > > controlled. The former is easily usable, you need just set and query > > methods implementation (look into iicbb_if.m), even if this has not the > > full i2c potential, the latter is (at least for me) somewhat hard to > > understand. I tried to implement such driver with Geode's Access.BUS > > controller, but so far no luck. And no description, google does not help > > me either. > > If SAA7146 uses bit banging interface or can be forced into such mode, > > you can do it in small amount of time. > > I had looked at both iicbb_if.m and iicbus_if.m. > SAA has internal logic to handle IIC, so iicbb was of no interest to me. > As to iicbus_if.m, it way closer to what I want. i2c subsystem in FreeBSD is somewhat SMBus oriented. Look at iicsmb, smbus and smb manpages. iicbus class implements just basic primitives. > It looks like linux is one layer of abstraction higher, so they have > "send N i2c messages" kind of functions, and in case of these cards, > logic is like that: > get array of messages, pack them into dwords, transfer that dwords using > DMA to card, read that dwords back and decode them into response. All > START/STOP conditions are handled by SAA chip itself, and I hoped that > there was something similar in other drivers, so there's no need to > reinvent the wheel for me. There is substantial difference - FreeBSD is modularised, linux (and NetBSD and OpenBSD as well, if I looked there at rught places) somehow makes i2c drivers monolithic, with code duplicated over all drivers. FreeBSD lacks this 'top-level' i2c-exec function. > > > 3. Card vendors use different PCI_SUBDEVICE on SAA7146 to indicate > > > which tuner is (possibly) used. So, I suppose that "bus"-driver shall > > > provide some way to tuner-driver to get this information. How that can > > > be done? > > > > This is not that easy to understand at first, but bus 'ivars' are > > intended for this purpose. man device_get_ivars would be first step as it > > was for me to understand this. > > Yeah, that told me to look into BUS_READ_IVAR(9), and it looks like > something I can use, so now my question is reformed to ``how can I from > child driver get the bus device_t''. > Look into bus_if.m - child devices are added using device_add_child. And there is device_get_parent... Oh, and maybe pcf device is similar to SAA7146 and may give you an idea on i2c driver implementation... Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
On Thursday 16 March 2006 11:59, Artem 'ZaZooBred' Ignatiev wrote: > Hello, hackers! ... > As far as I understand, all such cards have the same architecture: there > is bridge chip (Philips SAA7146) which interfaces with PC (using PCI) > and tuner on the card (using I2C), so in terms of newbus Properly > Written (tm) driver must be split in two parts: driver for the SAA7146 > itself (which will be a ``bus-device'') and drivers for specific tuners > (which will act as a child device on a SAA7146 "bus"). ... > 1. How to create the bus itself, and properly describe its interfaces? > skeletons of bus-driver and frontend-drivers would be a GREAT help. Being far from everything knowing hacker, I just can help with what I found when working on something totally unrelated. First you need to write .m file describing your methods - they are class description, kind of. There are couple of them - maybe PCI analogy (pci_if.m and pcib_if.m) could help a little to understand their role. Then you can use these methods in your device_method_t array describing your device. Actually, these definitions are something like software bus between parent and child device. And maybe you could get some clue looking at bktr driver, which could be somehow related to your are of interest. > 2. SAA7146 uses I2C to communicate with tuners, and I know that there > are some I2C-related peaces already in kernel. I would like to reuse > that code, if possible, but can't figure out where to look and how to > link it in. There is some basis for i2c, look in /usr/src/sys/dev/iicbus directory. There are two kinds of i2c controllers - bit banged and full hardware controlled. The former is easily usable, you need just set and query methods implementation (look into iicbb_if.m), even if this has not the full i2c potential, the latter is (at least for me) somewhat hard to understand. I tried to implement such driver with Geode's Access.BUS controller, but so far no luck. And no description, google does not help me either. If SAA7146 uses bit banging interface or can be forced into such mode, you can do it in small amount of time. > 3. Card vendors use different PCI_SUBDEVICE on SAA7146 to indicate which > tuner is (possibly) used. So, I suppose that "bus"-driver shall provide > some way to tuner-driver to get this information. How that can be done? This is not that easy to understand at first, but bus 'ivars' are intended for this purpose. man device_get_ivars would be first step as it was for me to understand this. There is maybe much more into this, but I can comment only on what I tried/did. Hopefully you could find some usefull info in my writing :) Regards, Milan -- Please reply only to mailing list. This address is filtered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question: tracking filesystem changes?
On Tuesday 01 February 2005 17:02, Deomid Ryabkov wrote: > This could be a custom filesystem wrapper for UFS that would report > name of the file/directory being changed. > >>> > >>> Couldn't you use kqueue system to monitor the directory-file? > >> > >> I could, if I hadn't near 10 millions of them. > > > > Hm. I meant monitoring the directory itself, as a file, then parsing > > the directory list to determine what has changed. But with 10M files, > > probably nothing would work... > > these are 10M of static documents, the daily change is minmal. > the question is: where it is the appropriate place to collect those > changes? the right way seems to implement a customs filesystem, but would > it possible to obtain a full path at that level? > Did you consider using fam (file alteration monitor) from ports? Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode integrated peripherals support?
On Friday 21 January 2005 00:51, John-Mark Gurney wrote: > Milan Obuch wrote this message on Wed, Jan 19, 2005 at 10:00 +0100: > > [skip] > > Great, could we cooperate? > > Sure, though Joerg Wunsch has been doing work w/ I2C more recently than > me, so you might want to drop him an email. > Is he on this list? I have no other idea how coould I reach him. > > I know there are two modes - bit banging software i2c bus and real > > hardware controller. Which one would be easier to begin with? With geode, > > both are possible. Pins designed for ACCESS.bus (at least the second, > > there are two buses integrated) can be used as GPIO pins. > > The hardware I worked on was bit banging only, so I used that interface > and it was surprisingly easy, since you just define an interface that > will get called by the i2c bus to do the necessary toggling... Of course > this is more cpu intensive since it requires timing and other things > like that.. > Maybe I will try to make bit banged version first. Just when I find all the subtle details necessary to toggle pins... > Take a look at sys/dev/iicbus/iic*_if.m. Those are the two different > programming interfaces. You of course just need to do one of the two... > I did. Actually first I must figure how this all contributes to total picture... I am on my way. I must first know the hardware part, which is not that easy on the first stage, but I am reading through specs, some examples, mostly in assembly. I am doing my homework :) [skip] > > You can take a look at lpbb for a simple example of the bit banging > interface... sys/dev/ppbus/lpbb.c The other controllers also implement > iicbus directly.. You can look at the modules/i2c/contollers/*/Makefile > to see who uses iicbus_if.h to see examples that implement it.. > On the other side - what is sys/dev/pcf directory for? I do not see those files referenced elsewhere... Other than that, device pcf looks like the best candidate to work with. I would like to use integrated controller, naturally. Regards, Milan N. B. No need to send cc: to me, I am subscribed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd problem: Cannot detect Hard Disk (SATA)
On Wednesday 19 January 2005 14:47, yoke an wrote: >> >Hi , >> > >> >We have recently purchased Tyan Transport GX21 (B2735G21S2) > >with Tiger > >> >i7501R S2735-8M motherboard. I'm trying to install FreeBSD v4.8 > >but it > >> >cannot detect my hard disk during the installation. I think the >> >problem should be the SATA driver. Coz I'm currently using SATA >> >instead of IDE/ATAPI. >> > >> >Is FreeBSD v4.8 support SATA or any available free downld > >driver for > >> >SATA? Can I use "ICH5-R SATA Chip driver " for supporting > >FreeBSD > >> >v4.8? If yes, where can i downld it? >> >>Could you try 5.3? I think 4.8 does not support SATA well, if at all. > >On > >>contrary, I am using SATA on 5.3 without problems, the last time I > >tried 4.10 > >>all I got was unknown disk or something like this. >> >>Milan > >Thanks. I knew 5.3 is work very well. But due to my application that >only support 4.8, so I need a way out to install 4.8. > >Ann > There is compatibility layer for FreeBSD, so older application should work with new OS version. Did you consider this? It is much easier (if it works) than porting some support from 5.3... Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd problem: Cannot detect Hard Disk (SATA)
On Wednesday 19 January 2005 13:19, yoke an wrote: >Hi , > >We have recently purchased Tyan Transport GX21 (B2735G21S2) with Tiger >i7501R S2735-8M motherboard. I'm trying to install FreeBSD v4.8 but it >cannot detect my hard disk during the installation. I think the >problem should be the SATA driver. Coz I'm currently using SATA >instead of IDE/ATAPI. > >Is FreeBSD v4.8 support SATA or any available free downld driver for >SATA? Can I use "ICH5-R SATA Chip driver " for supporting FreeBSD >v4.8? If yes, where can i downld it? > Could you try 5.3? I think 4.8 does not support SATA well, if at all. On contrary, I am using SATA on 5.3 without problems, the last time I tried 4.10 all I got was unknown disk or something like this. Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode integrated peripherals support?
On Wednesday 19 January 2005 01:43, John-Mark Gurney wrote: > Milan Obuch wrote this message on Mon, Jan 17, 2005 at 13:14 +0100: > > On Monday 17 January 2005 12:55, Bruce M Simpson wrote: > > > On Sun, Jan 16, 2005 at 03:01:17PM +0100, Milan Obuch wrote: > > > > ACCESS.bus support (i2c bus compatible) and LPC bus bridge (for > > > > expansion). The first one is present in OpenBSD. I am currently > > > > studying that and FreeBSD kernel sources to try port it, however, any > > > > help would be great. No idea on LPC, through... > > > > > > There's some i2c support in FreeBSD already, whether or not this > > > applies to the i2c hardware in the Geode I don't know. iic(4) would be > > > a good place to start. > > > > I think so. However, I built kernel with device iic, iicbus, iicbb, but > > nothing shows. As said, I am doing my 'homework' now - astudying sources, > > but, as usual, any help appreciated. > > Well, as having used the i2c code, I know it works... You probably > need to look at the hardware spec, and figure out if you need to write > a iicbb device driver (one that directly controls the SCL/SDA lines), or > a higher level one, that has hardware that can issue i2c reads and wrights > directly... > > I recently d/l'd the ACCESS.bus spec myself, since I have a firewire/usb2.0 > card that says it's an ACCESS.bus card, but not quite (the subrev is > wrong for access.bus), and didn't realize that ACCESS.bus was so close > to i2c.. There might need to be a layer written on top of i2c to make > it appear as an access.bus and do access.bus type things.. Great, could we cooperate? I know there are two modes - bit banging software i2c bus and real hardware controller. Which one would be easier to begin with? With geode, both are possible. Pins designed for ACCESS.bus (at least the second, there are two buses integrated) can be used as GPIO pins. Actually the first thing I need to get working is simple LM75 sensor reading, which is just i2c device, so nothing else (higher level access.bus layer) is necessary for me. Regards, Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode integrated peripherals support?
On Monday 17 January 2005 12:55, Bruce M Simpson wrote: > On Sun, Jan 16, 2005 at 03:01:17PM +0100, Milan Obuch wrote: > > ACCESS.bus support (i2c bus compatible) and LPC bus bridge (for > > expansion). The first one is present in OpenBSD. I am currently studying > > that and FreeBSD kernel sources to try port it, however, any help would > > be great. No idea on LPC, through... > > There's some i2c support in FreeBSD already, whether or not this applies > to the i2c hardware in the Geode I don't know. iic(4) would be a good > place to start. > I think so. However, I built kernel with device iic, iicbus, iicbb, but nothing shows. As said, I am doing my 'homework' now - astudying sources, but, as usual, any help appreciated. > LPC just looks like ISA for most intents and purposes, and if we didn't > support ISA, we couldn't boot on i386... > So it means we need either hack pci_isa pridge to recognise and work with geode's LPC bridge or build new PCI - LPC bridge. When I will have some LPC peripheral available, I will do some tests. Until then, i2c support has higher priority - can be tested just now and could bring something when working. Regards, Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Geode integrated peripherals support?
On Saturday 15 January 2005 00:29, you wrote: > > is someone working with Geode processors? There are many peripherals > > integrated, but not all supported under FreeBSD. Has someone already done > > some patched for this? > > We use the geode and haven't noticed the lack. What's missing? > > Warner [Second try - first one apparently did not came through to hackers] ACCESS.bus support (i2c bus compatible) and LPC bus bridge (for expansion). The first one is present in OpenBSD. I am currently studying that and FreeBSD kernel sources to try port it, however, any help would be great. No idea on LPC, through... Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Geode integrated peripherals support?
Hi, is someone working with Geode processors? There are many peripherals integrated, but not all supported under FreeBSD. Has someone already done some patched for this? Regards, Milan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
