**** BEGIN LOGGING AT Wed Jun 13 02:59:58 2012 Jun 13 06:39:54 hello all Jun 13 07:14:52 hello lautriv Jun 13 12:00:18 Crofton|work: btw, it looks like there are a few hw-specific recipes in meta-oe that look like they ought to be in meta-ettus, what's the story there? Jun 13 12:09:31 such as? Jun 13 12:09:54 gnuradio is not Jun 13 12:09:57 and uhd is not Jun 13 12:19:02 Crofton|work: uhd isn't hardware specific? Jun 13 12:19:17 gnuradio wasn't one of the ones I was thinking of, there was one other Jun 13 12:19:33 no Jun 13 12:19:47 you can attach a usrp via usb or gig-e Jun 13 12:20:09 so not machone specific Jun 13 12:20:21 I think I even split out the e100 specific stuff into a package :) Jun 13 12:20:55 I guess I was confused by DESCRIPTION = "Universal Hardware Driver for Ettus Research products." Jun 13 12:22:07 yeah, but not all products are tied to a particular machine Jun 13 12:22:33 https://www.ettus.com/product/category/USRP_Bus_Series Jun 13 12:23:35 hmm, ok Jun 13 12:25:26 Isn't UHD "USRP Hardware Driver" nowadays? Jun 13 12:25:58 hmm, I should fix that :) Jun 13 12:58:15 khem: around? Jun 13 12:58:57 khem: is there a way, using TARGET_FEATURES, to check if a machine is capable of running using softfp or only soft? Jun 13 13:29:51 Hi all Jun 13 14:05:31 hi Jun 13 15:21:38 otavio: yes you can check TUNE_FEATURES Jun 13 15:24:34 otavio: you could actually use TARGET_FPU as well Jun 13 15:24:45 TARGET_FPU=soft means no VFP or neon Jun 13 15:25:56 if you want to check TUNE_FEATURES then you should check for present of of vfp or neon Jun 13 15:37:58 khem: if it has vfp or neon then softfp would work? Jun 13 15:38:34 yes Jun 13 15:39:18 well, ultimate check is if we pass right options to gcc but in OE as a whole we know that when these options are set then we do pass the required options Jun 13 15:40:28 khem: I am trying to get nodejs properly behaving for hardfp, softfp and soft Jun 13 15:41:12 ok Jun 13 15:41:24 khem: we now have FORCE_SOFT_FPU = "${@bb.utils.contains("TUNE_FEATURES", "soft", "yes", "no", d)}" Jun 13 15:41:39 This works for soft but not for softfp and harfp Jun 13 15:41:45 hardfp Jun 13 15:41:50 you need to check for callconvention-hard be present in TUNE_FEATURES for it to assume hardfp Jun 13 15:42:06 and for softfp as I said Jun 13 15:42:09 earlier Jun 13 15:42:15 use TARGET_FPU Jun 13 15:42:28 or TUNE_FEATURES soft Jun 13 15:44:50 khem: but for softfp, tune would be soft too? Jun 13 15:46:29 yes Jun 13 15:47:13 check for TARGET_FPU Jun 13 15:47:44 and if its not soft and check callconvention-hard is not in TUNE_FEARTUES Jun 13 15:47:52 then its softfp Jun 13 15:47:54 phew Jun 13 15:50:55 khem: http://paste.debian.net/174316/? Jun 13 15:50:58 * otavio lunch time Jun 13 15:52:44 otavio looks ok Jun 13 18:28:33 are the c++ related build problems for beecrypt known? Jun 13 18:33:34 e.g. like in http://autobuild.buildroot.org/results/5c1e904b201676275465c902ba3c09951973755c/build-end.log Jun 13 19:49:00 bluelightning, hi ..... we talked about kernel 3.5 yesterday. actually no need to test i had a look and it contains a bunch of problems ( builds modules which are not even selected, missing symbols which are present ... ) because linus is on hollidays there will no change for a week ;) Jun 13 19:50:27 bluelightning, but another thing : in the old kernels was hx4700_bt what i can't find. idea if that went into upstream ? Jun 13 19:51:46 lautriv: it just enables bt power, can be replaced with rfkill_gpio Jun 13 19:53:02 anyway, bluetooth stack seems to be broken for some devices in recent kernel (3.1-3.4 are affected for sure) Jun 13 19:53:03 anarsoul, but the old one was specially for driving BRF6150 from Ti, is this now part of another one ? Jun 13 19:53:21 lautriv: afaik it's attached to uart, isn't it? Jun 13 19:54:07 anarsoul, yes, hx47 has 3 UART, one is ttyS0, one is irda and one BT Jun 13 19:54:22 no special driver is needed Jun 13 19:54:36 just enable power (via rfkill_gpio) and attach to it via hciattach Jun 13 19:54:48 however you may hit same bug as I hit :) Jun 13 19:55:05 anarsoul, i'll check it soon ;) Jun 13 19:55:20 there's memory corruption somewhere in bluetooth stack, bt in my h1940 (on uart) and usb dongle from dx can easily put kernel into panic Jun 13 19:56:08 easy to reproduce with hcitool scan; hcitool info Jun 13 19:56:16 anarsoul, i had a lot of BT problems from 3.0 to 3.3 with a generic box (x86_64) but seems in 3.4+ it is somewhat stable. Jun 13 19:56:46 3.4 still crashes kernel with bt from dealextreme for me Jun 13 19:57:12 anarsoul, on your h1940 or in general ? **** ENDING LOGGING AT Thu Jun 14 02:59:58 2012