From phil_straw at mac.com Mon Dec 1 14:32:15 2008 From: phil_straw at mac.com (Phil Straw) Date: Mon Dec 1 14:32:21 2008 Subject: FYI on Atheros HAL Message-ID: http://hardware.slashdot.org/hardware/08/11/29/2047230.shtml ISC License is BSD compatible too. p/. From d9364104 at mail.nchu.edu.tw Mon Dec 1 16:58:48 2008 From: d9364104 at mail.nchu.edu.tw (Eric L. Chen) Date: Mon Dec 1 16:58:55 2008 Subject: FYI on Atheros HAL In-Reply-To: References: Message-ID: Thanks, it's a great news!!! On Tue, Dec 2, 2008 at 5:31 AM, Phil Straw wrote: > http://hardware.slashdot.org/hardware/08/11/29/2047230.shtml > > ISC License is BSD compatible too. > > p/. > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From imp at bsdimp.com Mon Dec 1 17:54:08 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Dec 1 17:54:14 2008 Subject: FYI on Atheros HAL In-Reply-To: References: Message-ID: <20081201.185133.337862776.imp@bsdimp.com> In message: Phil Straw writes: : http://hardware.slashdot.org/hardware/08/11/29/2047230.shtml : : ISC License is BSD compatible too. Thanks! But Sam is putting the code into the FreeBSD tree, so we'll get it for MIPS for free, or almost free. Warner From imp at bsdimp.com Thu Dec 11 09:09:50 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 11 09:09:56 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: <86oczjklk8.fsf@ds4.des.no> References: <200812110822.mBB8MKLd059320@svn.freebsd.org> <86oczjklk8.fsf@ds4.des.no> Message-ID: <20081211.100636.631212415.imp@bsdimp.com> In message: <86oczjklk8.fsf@ds4.des.no> Dag-Erling_Sm?rgrav writes: : Warner Losh writes: : > Author: imp : > Date: Thu Dec 11 08:22:20 2008 : > New Revision: 185925 : > URL: http://svn.freebsd.org/changeset/base/185925 : > : > Log: : > Push mips support into the tree. : : Just to pick a random mips commit - : : There is something wrong with the mips toolchain. The build breaks in : libpam, while building the static version, which includes all modules: Something is wrong either with the toolchain or with PAM's assumptions. I've not tracked it down further than that yet, but I think the latter. Let me explain. : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In function `pam_sm_open_session': : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple definition of `pam_sm_open_session' : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14):/src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined here : [lather, rinse, repeat for every service function in every module] : : The service functions should be static. The logic PAM uses to determine : whether it is building static or shared modules is as follows: : : #if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES) I think the problem here is a confusion between 'static vs dynamic' and 'pic vs nonpic'. #ifdef __PIC__ int x; #else int y; #endif produces a .o with the symbol 'x' always. That was as far as I had got on looking into the problem. Warner From imp at bsdimp.com Thu Dec 11 10:00:24 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 11 10:00:30 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: <20081211.100636.631212415.imp@bsdimp.com> References: <200812110822.mBB8MKLd059320@svn.freebsd.org> <86oczjklk8.fsf@ds4.des.no> <20081211.100636.631212415.imp@bsdimp.com> Message-ID: <20081211.105808.-1186640207.imp@bsdimp.com> In message: <20081211.100636.631212415.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <86oczjklk8.fsf@ds4.des.no> : Dag-Erling_Sm?rgrav writes: : : Warner Losh writes: : : > Author: imp : : > Date: Thu Dec 11 08:22:20 2008 : : > New Revision: 185925 : : > URL: http://svn.freebsd.org/changeset/base/185925 : : > : : > Log: : : > Push mips support into the tree. : : : : Just to pick a random mips commit - : : : : There is something wrong with the mips toolchain. The build breaks in : : libpam, while building the static version, which includes all modules: : : Something is wrong either with the toolchain or with PAM's : assumptions. I've not tracked it down further than that yet, but I : think the latter. Let me explain. : : : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In function `pam_sm_open_session': : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple definition of `pam_sm_open_session' : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14):/src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined here : : [lather, rinse, repeat for every service function in every module] : : : : The service functions should be static. The logic PAM uses to determine : : whether it is building static or shared modules is as follows: : : : : #if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES) : : I think the problem here is a confusion between 'static vs dynamic' and : 'pic vs nonpic'. : : #ifdef __PIC__ : int x; : #else : int y; : #endif : : produces a .o with the symbol 'x' always. That was as far as I had : got on looking into the problem. Ooops, looks like I neglected to add the following: The reason that it always produces 'x' has to do with the MIPS calling conventions. Everything is always compiled PIC. There's a way to disable this for the kernel, -mnoabicalls, but in userland that's what all the tool chains expect. There may be other issues. I have a fuzzy memory of some, but I can't recall any and explain them in a way that makes sense, so I'll leave it at that. So if you are compiling for a static library or a dynamic library doesn't matter: __PIC__ is effectively always defined. Any suggestions on how to handle this problem? Warner From xcllnt at mac.com Thu Dec 11 12:04:09 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 12:04:16 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: <20081211.105808.-1186640207.imp@bsdimp.com> References: <200812110822.mBB8MKLd059320@svn.freebsd.org> <86oczjklk8.fsf@ds4.des.no> <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> Message-ID: On Dec 11, 2008, at 9:58 AM, M. Warner Losh wrote: > In message: <20081211.100636.631212415.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <86oczjklk8.fsf@ds4.des.no> > : Dag-Erling_Sm?rgrav writes: > : : Warner Losh writes: > : : > Author: imp > : : > Date: Thu Dec 11 08:22:20 2008 > : : > New Revision: 185925 > : : > URL: http://svn.freebsd.org/changeset/base/185925 > : : > > : : > Log: > : : > Push mips support into the tree. > : : > : : Just to pick a random mips commit - > : : > : : There is something wrong with the mips toolchain. The build > breaks in > : : libpam, while building the static version, which includes all > modules: > : > : Something is wrong either with the toolchain or with PAM's > : assumptions. I've not tracked it down further than that yet, but I > : think the latter. Let me explain. > : > : : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In > function `pam_sm_open_session': > : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple > definition of `pam_sm_open_session' > : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14):/ > src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined here > : : [lather, rinse, repeat for every service function in every module] > : : > : : The service functions should be static. The logic PAM uses to > determine > : : whether it is building static or shared modules is as follows: > : : > : : #if defined(__GNUC__) && !defined(__PIC__) && ! > defined(NO_STATIC_MODULES) > : > : I think the problem here is a confusion between 'static vs > dynamic' and > : 'pic vs nonpic'. > : > : #ifdef __PIC__ > : int x; > : #else > : int y; > : #endif > : > : produces a .o with the symbol 'x' always. That was as far as I had > : got on looking into the problem. > > Ooops, looks like I neglected to add the following: > > The reason that it always produces 'x' has to do with the MIPS calling > conventions. Everything is always compiled PIC. There's a way to > disable this for the kernel, -mnoabicalls, but in userland that's what > all the tool chains expect. There may be other issues. I have a > fuzzy memory of some, but I can't recall any and explain them in a way > that makes sense, so I'll leave it at that. So if you are compiling > for a static library or a dynamic library doesn't matter: __PIC__ is > effectively always defined. > > Any suggestions on how to handle this problem? What about using OPENPAM_STATIC_MODULES for it? It's now defined in openpam.h as a consequence of the faulty logic. We might as well make it the pivotal flag... -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Thu Dec 11 12:09:19 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 11 12:09:26 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: References: <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> Message-ID: <20081211.130830.1365011002.imp@bsdimp.com> In message: Marcel Moolenaar writes: : : On Dec 11, 2008, at 9:58 AM, M. Warner Losh wrote: : : > In message: <20081211.100636.631212415.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <86oczjklk8.fsf@ds4.des.no> : > : Dag-Erling_Sm?rgrav writes: : > : : Warner Losh writes: : > : : > Author: imp : > : : > Date: Thu Dec 11 08:22:20 2008 : > : : > New Revision: 185925 : > : : > URL: http://svn.freebsd.org/changeset/base/185925 : > : : > : > : : > Log: : > : : > Push mips support into the tree. : > : : : > : : Just to pick a random mips commit - : > : : : > : : There is something wrong with the mips toolchain. The build : > breaks in : > : : libpam, while building the static version, which includes all : > modules: : > : : > : Something is wrong either with the toolchain or with PAM's : > : assumptions. I've not tracked it down further than that yet, but I : > : think the latter. Let me explain. : > : : > : : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In : > function `pam_sm_open_session': : > : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple : > definition of `pam_sm_open_session' : > : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14):/ : > src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined here : > : : [lather, rinse, repeat for every service function in every module] : > : : : > : : The service functions should be static. The logic PAM uses to : > determine : > : : whether it is building static or shared modules is as follows: : > : : : > : : #if defined(__GNUC__) && !defined(__PIC__) && ! : > defined(NO_STATIC_MODULES) : > : : > : I think the problem here is a confusion between 'static vs : > dynamic' and : > : 'pic vs nonpic'. : > : : > : #ifdef __PIC__ : > : int x; : > : #else : > : int y; : > : #endif : > : : > : produces a .o with the symbol 'x' always. That was as far as I had : > : got on looking into the problem. : > : > Ooops, looks like I neglected to add the following: : > : > The reason that it always produces 'x' has to do with the MIPS calling : > conventions. Everything is always compiled PIC. There's a way to : > disable this for the kernel, -mnoabicalls, but in userland that's what : > all the tool chains expect. There may be other issues. I have a : > fuzzy memory of some, but I can't recall any and explain them in a way : > that makes sense, so I'll leave it at that. So if you are compiling : > for a static library or a dynamic library doesn't matter: __PIC__ is : > effectively always defined. : > : > Any suggestions on how to handle this problem? : : What about using OPENPAM_STATIC_MODULES for it? : It's now defined in openpam.h as a consequence of : the faulty logic. We might as well make it the : pivotal flag... I'm not sure i follow your suggestion... Warner From xcllnt at mac.com Thu Dec 11 12:24:03 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 12:24:15 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: <20081211.130830.1365011002.imp@bsdimp.com> References: <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> <20081211.130830.1365011002.imp@bsdimp.com> Message-ID: On Dec 11, 2008, at 12:08 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Dec 11, 2008, at 9:58 AM, M. Warner Losh wrote: > : > : > In message: <20081211.100636.631212415.imp@bsdimp.com> > : > "M. Warner Losh" writes: > : > : In message: <86oczjklk8.fsf@ds4.des.no> > : > : Dag-Erling_Sm?rgrav writes: > : > : : Warner Losh writes: > : > : : > Author: imp > : > : : > Date: Thu Dec 11 08:22:20 2008 > : > : : > New Revision: 185925 > : > : : > URL: http://svn.freebsd.org/changeset/base/185925 > : > : : > > : > : : > Log: > : > : : > Push mips support into the tree. > : > : : > : > : : Just to pick a random mips commit - > : > : : > : > : : There is something wrong with the mips toolchain. The build > : > breaks in > : > : : libpam, while building the static version, which includes all > : > modules: > : > : > : > : Something is wrong either with the toolchain or with PAM's > : > : assumptions. I've not tracked it down further than that yet, > but I > : > : think the latter. Let me explain. > : > : > : > : : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In > : > function `pam_sm_open_session': > : > : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple > : > definition of `pam_sm_open_session' > : > : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text > +0x14):/ > : > src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined > here > : > : : [lather, rinse, repeat for every service function in every > module] > : > : : > : > : : The service functions should be static. The logic PAM uses to > : > determine > : > : : whether it is building static or shared modules is as follows: > : > : : > : > : : #if defined(__GNUC__) && !defined(__PIC__) && ! > : > defined(NO_STATIC_MODULES) > : > : > : > : I think the problem here is a confusion between 'static vs > : > dynamic' and > : > : 'pic vs nonpic'. > : > : > : > : #ifdef __PIC__ > : > : int x; > : > : #else > : > : int y; > : > : #endif > : > : > : > : produces a .o with the symbol 'x' always. That was as far as > I had > : > : got on looking into the problem. > : > > : > Ooops, looks like I neglected to add the following: > : > > : > The reason that it always produces 'x' has to do with the MIPS > calling > : > conventions. Everything is always compiled PIC. There's a way to > : > disable this for the kernel, -mnoabicalls, but in userland > that's what > : > all the tool chains expect. There may be other issues. I have a > : > fuzzy memory of some, but I can't recall any and explain them in > a way > : > that makes sense, so I'll leave it at that. So if you are > compiling > : > for a static library or a dynamic library doesn't matter: > __PIC__ is > : > effectively always defined. > : > > : > Any suggestions on how to handle this problem? > : > : What about using OPENPAM_STATIC_MODULES for it? > : It's now defined in openpam.h as a consequence of > : the faulty logic. We might as well make it the > : pivotal flag... > > I'm not sure i follow your suggestion... Sorry, I was a bit cryptic. Currently openpam.h does something like: #if defined(__GNUC__) && !defined(__PIC__) && ! defined(NO_STATIC_MODULES) #define OPENPAM_STATIC_MODULES 1 ... foo ... #else ... bar ... #endif Why not make OPENPAM_STATIC_MODULES a define that you put on the compiler command line and change the code to: #ifdef OPENPAM_STATIC_MODULES ... foo ... #else ... bar ... #endif It should be fairly easy for us to add it only when needed, given that we have different rules for building static vs shared libraries... -- Marcel Moolenaar xcllnt@mac.com From des at des.no Thu Dec 11 13:39:57 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Dec 11 13:40:04 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: (Marcel Moolenaar's message of "Thu, 11 Dec 2008 12:23:57 -0800") References: <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> <20081211.130830.1365011002.imp@bsdimp.com> Message-ID: <86hc5as8va.fsf@ds4.des.no> Marcel Moolenaar writes: > Why not make OPENPAM_STATIC_MODULES a define that you put > on the compiler command line and change the code to: > > #ifdef OPENPAM_STATIC_MODULES > ... foo ... > #else > ... bar ... > #endif My preference would be to remove support for statically linked modules altogether, but some people might object... This is probably the best compromise. DES -- Dag-Erling Sm?rgrav - des@des.no From imp at bsdimp.com Thu Dec 11 14:12:41 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 11 14:12:48 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: <86hc5as8va.fsf@ds4.des.no> References: <20081211.130830.1365011002.imp@bsdimp.com> <86hc5as8va.fsf@ds4.des.no> Message-ID: <20081211.151051.-1112729558.imp@bsdimp.com> In message: <86hc5as8va.fsf@ds4.des.no> Dag-Erling_Sm?rgrav writes: : Marcel Moolenaar writes: : > Why not make OPENPAM_STATIC_MODULES a define that you put : > on the compiler command line and change the code to: : > : > #ifdef OPENPAM_STATIC_MODULES : > ... foo ... : > #else : > ... bar ... : > #endif : : My preference would be to remove support for statically linked modules : altogether, but some people might object... This is probably the best : compromise. We could just not support it on MIPS as well... I have patches in my tree that do this in an uglyass way and was hoping for a better solution... Warner From bms at incunabulum.net Sat Dec 13 13:30:02 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Dec 13 13:30:14 2008 Subject: MIPS port repository question In-Reply-To: <20081115.100002.-1384053695.imp@bsdimp.com> References: <491EE062.2070705@incunabulum.net> <20081115.100002.-1384053695.imp@bsdimp.com> Message-ID: <49442957.9030300@incunabulum.net> M. Warner Losh wrote: > Most of the mips stuff has been pushed into the tree. The bleeding > edge stuff is still just in p4. I didn't merge your bfe(4) changes > into svn, but if you have something that's stable, there's no reason > not to do so. OK, it's still in p4 branch mips2. I committed the change there which lets the PHY for bfe(4) attach on the Sentry5. The Sentry5 machine itself is now with gonzo@. cheers BMS From des at des.no Sat Dec 13 15:41:52 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Dec 13 15:41:59 2008 Subject: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams In-Reply-To: (Marcel Moolenaar's message of "Thu, 11 Dec 2008 12:23:57 -0800") References: <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> <20081211.130830.1365011002.imp@bsdimp.com> Message-ID: <86myezve0x.fsf@ds4.des.no> Marcel Moolenaar writes: > It should be fairly easy for us to add it only when needed, given that > we have different rules for building static vs shared libraries... Not quite. We have different rules, but they use the same CFLAGS. The "least intervention" to achieve what we want is to redefine the .c.o rule in lib/libpam/modules/Makefile.inc; see attached patch. A cleaner solution would be to modify share/mk/sys.mk and share/mk/bsd.lib.mk to add STATIC_CFLAGS and SHARED_CFLAGS variables, so we could simply set STATIC_CFLAGS=-DOPENPAM_STATIC_MODULES in Makefile.inc. DES -- Dag-Erling Sm?rgrav - des@des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: openpam_static_modules.diff Type: text/x-patch Size: 2045 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20081213/ab52c984/openpam_static_modules.bin From alancyang at gmail.com Wed Dec 17 13:46:15 2008 From: alancyang at gmail.com (alan yang) Date: Wed Dec 17 13:46:22 2008 Subject: FreeBSD on RMI In-Reply-To: <20081115.153058.1716877238.imp@bsdimp.com> References: <290865fd0811141044i46399307ob44e53642beac15d@mail.gmail.com> <491F39F7.7010401@bluezbox.com> <20081115.153058.1716877238.imp@bsdimp.com> Message-ID: <290865fd0812171346n1e2fbbf4g81b29f0c5a38a809@mail.gmail.com> Wonder people could shed some light on building the tool-chain of RMI SDK under FreeBSD that would provide good help for us. Thanks in advance!! On Sat, Nov 15, 2008 at 2:30 PM, M. Warner Losh wrote: > In message: <491F39F7.7010401@bluezbox.com> > Oleksandr Tymoshenko writes: > : alan yang wrote: > : > Hi, All, > : > > : > Wonder any work / progress towards porting of FreeBSD on RMI chip. If > : > is, can people provide some pointers on the build environment and > : > target XLR chip. > : As far as I know none of FreeBSD/MIPS developers has access to the > : hardware, hence there is no port for RMI. > > Actually, some of the FreeBSD/mips developers do have access to the > RMI chipset. The problem is that the NDA required to use the RMI > documentation makes it impossible to release the code to support > it... I don't have such hardware, but I know that those that do tell > me this... > > Warner >