**** BEGIN LOGGING AT Tue Dec 29 02:59:58 2015
Dec 29 03:06:34 <mranostay> ok dumb question. the grove connectors on the green are muxable right?
Dec 29 04:57:06 <wmat> mranostay: isn't everything? ;)
Dec 29 04:58:19 * mranostay smacks wmat
Dec 29 05:00:59 * wmat heehee
Dec 29 05:04:39 <Vishakh> hey.. I am planning to develop image processing applications on an embedded board. Is BBB suited for such applications?
Dec 29 05:09:35 <mranostay> heh i remember this channel now
Dec 29 05:22:44 <zauslande> Looked at a X15 on mouser last week and the delay increased and the price increased. BBB is looking better.
Dec 29 05:23:11 <zauslande> I'm guessing that means a new board layout revision for the X15
Dec 29 05:23:34 <veremit> as long as you don't want to do real-time .. or big images, BBB can do image processing lol
Dec 29 05:23:44 <zauslande> Or time is slowing down because a black hole is orbiting our planet
Dec 29 05:24:13 <veremit> last news on x15 was a new board spin was necessary after it failed FCC testing
Dec 29 05:24:26 <veremit> expect more news late January
Dec 29 05:24:33 <zauslande> Ah... sad that pushed the price out of reason.
Dec 29 05:25:00 <veremit> price will always be ~$200 .. its not a 'cheap' arm board like all the others. its a Performance arm board.
Dec 29 05:26:29 <veremit> there are a few options down the 'cheaper' end, depending what you wanna do
Dec 29 05:26:47 <zauslande> $200 is fine... I saw a higher price on Mouser.... maybe it was a typo and they fixed it.
Dec 29 05:27:05 <veremit> but if you really are serious about real-time video or MPEG encoding .. you want a video chip or dedicated video hardware
Dec 29 05:29:47 <veremit> I got GBP183 .. that's not too bad
Dec 29 05:30:17 <veremit> $260US
Dec 29 05:30:56 <veremit> looks like they're being VERY conservative with delivery dates lol
Dec 29 05:30:59 <veremit> wisely so
Dec 29 05:31:29 <veremit> aside frm the fact it'll take CCo 12 months to spin up 900 boards lol
Dec 29 05:32:38 <zauslande> $260 is over a threshold considering there are no capes/shields for it
Dec 29 05:33:06 <veremit> its a brand new board. Even TI have little documentation on the processor
Dec 29 05:33:20 <veremit> so until it gets out there .. nobody can make anything for it :p
Dec 29 05:33:31 <zauslande> BBB will do what I need, maybe even an Arduino Tian... if they're become available.
Dec 29 05:34:08 <zauslande> Yeah, they'll have to warm up the demand for 2017
Dec 29 05:35:10 <veremit> some interesting new arduino's coming on line
Dec 29 05:35:44 <veremit> pity about the Tre .. that looked like a good board combining the BBB with an arduino micro :/
Dec 29 05:35:59 <veremit> hmm that reminds me ..
Dec 29 05:37:29 <yates> where are the board IDs stored in the eeprom defined? e.g., what's the difference between A335BONE and A335BNLT ?
Dec 29 05:37:48 <zauslande> Mouser says 26 weeks lead-time... is that really better than typing, "We have no idea when"
Dec 29 05:38:15 <zauslande> one misspelled "bone"?
Dec 29 05:38:33 <zauslande> less calories in the LT?
Dec 29 05:39:52 <yates> zauslande: ha!
Dec 29 05:42:33 <yates> what about the new am88xx or whatever?
Dec 29 05:42:35 <veremit> I suspect its for the different 'bone' boards
Dec 29 05:42:44 <yates> veremit: brilliant!
Dec 29 05:43:13 <veremit> bone-plain .. bone white .. bone black .. bone xm...
Dec 29 05:43:38 <yates> yeah, i was asking for the exact mappings.
Dec 29 05:43:39 <veremit> although the xm isn't the am335x
Dec 29 05:43:43 <veremit> so .. that narrows it down
Dec 29 05:44:29 <veremit> might need to track down jkdridner or one of the other sw guru's
Dec 29 05:45:07 <yates> might be buried somewhere on this site: http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB
Dec 29 05:51:46 <yates> i'm trying to read the sdram initialization in u-boot and at a high level it determines initialization parameters based on this string.
Dec 29 05:58:56 <yates> it says "bone_lt" - what's that?
Dec 29 05:59:46 <ds2> mapping?
Dec 29 05:59:52 <ds2> what mapping are you looking for?
Dec 29 06:00:23 <yates> from eeprom board id to beagle board type
Dec 29 06:00:37 <ds2> there are 4 boards produced by beagleBoard.org
Dec 29 06:00:42 <yates> the on-board eeprom, not the one(s) on the cape(s)
Dec 29 06:00:47 <ds2> xM/Classic do not use a eeprom.
Dec 29 06:00:55 <ds2> BBB/BBW use a eeprom
Dec 29 06:01:01 <yates> ok
Dec 29 06:01:08 <ds2> they need different settings as one is DDR3 and other is DDR2
Dec 29 06:01:12 <ds2> that's it.
Dec 29 06:01:28 <ds2> the eeprom is an artifact of this being derived from the EVM
Dec 29 06:01:42 <ds2> LT is the black
Dec 29 06:02:04 <ds2> you can trivially bypass all that i2c stuff for a simplier u-boot
Dec 29 06:02:25 <yates> here is the relevent code from uboot: http://ur1.ca/od3eu -> http://paste.fedoraproject.org/305611/51368920
Dec 29 06:02:34 <yates> ds2: how did you know lt is the black?
Dec 29 06:02:54 <ds2> because I been following this stuff
Dec 29 06:03:18 <yates> oh, you mean tribal undocumented knowledge? wonderful!
Dec 29 06:03:33 <ds2> and I have worked on projects using derivative boards
Dec 29 06:03:36 <ds2> so I had to verify it
Dec 29 06:04:03 <ds2> the other eeprom settings are not BeagleBoard.org products
Dec 29 06:04:11 <ds2> they are other dev boards such as the EVM
Dec 29 06:05:00 <yates> ds2: re: bypass: i am definitely interested in doing that very soon, but that's not my goal now, which is to basically parrot their sdram initialization into my own standalone assembly program to test out new board's sdram.
Dec 29 06:05:04 <yates> right
Dec 29 06:05:22 <yates> s/out/our/
Dec 29 06:05:38 <ds2> ah
Dec 29 06:06:05 <ds2> I'd be very careful about just parroting it
Dec 29 06:06:05 <yates> so how do you bypass it easily? i will need to do this next as we removed that eeprom
Dec 29 06:06:19 <yates> ds2: why? doesn't it work?
Dec 29 06:06:27 <ds2> replace the if() with the relevant stuff
Dec 29 06:06:35 <ds2> it works but it may not be optimal
Dec 29 06:06:43 <ds2> esp. if you don't have the exact same chips
Dec 29 06:06:45 <yates> huh? if()?
Dec 29 06:07:02 <yates> i believe it is the exact same.
Dec 29 06:07:06 <ds2> those inline functions are used in if (foo == true) { do this }
Dec 29 06:07:14 <ds2> remove the if() and just keep the revelant do this parts
Dec 29 06:07:26 <ds2> very useful if you are doing a fresh bring up w/o a programmed EEPROM
Dec 29 06:07:28 <yates> oh, yeah, sure.
Dec 29 06:07:46 <ds2> you can use it as a starting point but I'd verify it
Dec 29 06:07:59 <ds2> I have seen stuff get lost going from vendor u-boot's and upstream
Dec 29 06:08:14 <yates> ds2: why would there be any question of it if you assume it's the exact same DRAM?
Dec 29 06:08:16 <yates> ah.
Dec 29 06:08:39 <ds2> if you used hte original vendor u-boot, it should be fine... at least good enough
Dec 29 06:09:23 <yates> well i was trying to rebuild the entire bbb debian distro from bb-kernel but kept running into walls. the idea was that the build process would grab and patch u-boot, and i would take it from there.
Dec 29 06:09:41 <ds2> heheh... "good luck"
Dec 29 06:09:53 <yates> why do you say that?!?
Dec 29 06:10:11 <ds2> unless you are really limited in skills, debian is nothing but trouble for embedded stuff
Dec 29 06:10:35 <ds2> Angstrom was the distro during development
Dec 29 06:11:00 <yates> why? i've used it successfully on plain-jane bbb's before. works great.
Dec 29 06:11:17 <ds2> to which part?
Dec 29 06:11:41 <yates> it == debian
Dec 29 06:11:47 <yates> to a bbb
Dec 29 06:11:55 <yates> or maybe i don't get your question.
Dec 29 06:12:20 <ds2> debian boots and runs like a desktop. it has a lot of stuff that is a pain to deal with for embeddeduse
Dec 29 06:12:38 <ds2> i.e. a RO fs
Dec 29 06:13:02 <yates> huh?
Dec 29 06:13:20 <yates> i wrote logs using standard fwrite() no problem
Dec 29 06:13:41 <yates> (actually it was the c++ equivalent, but still)
Dec 29 06:13:56 <yates> RO = Read-Only?
Dec 29 06:14:07 <ds2> no no
Dec 29 06:14:20 <ds2> it is often desireable to keep flash RO in an embedded situation
Dec 29 06:14:42 <ds2> debian makes it painful if it doesn't have a few areas taht are writeable
Dec 29 06:14:47 <yates> you're not going to the "wear out your flash" argument, are you?
Dec 29 06:15:14 <ds2> no, I am going to yanking hte power will corrupt things and then customer service will bankrupt you argument :D
Dec 29 06:16:19 <yates> aha.
Dec 29 06:16:22 <yates> i see.
Dec 29 06:17:06 <yates> why does that happen? isn't it ext3 or ext4 fs?
Dec 29 06:17:21 <yates> with journals and all to keep such corruption from happening?
Dec 29 06:17:21 <ds2> it isn't perfect
Dec 29 06:17:43 <yates> so it's the same with my desktop?
Dec 29 06:17:53 <yates> i do backups, but that still makes me nervous..
Dec 29 06:18:03 <yates> Linux localhost.localdomain 4.1.13-100.fc21.x86_64 #1 SMP Tue Nov 10 13:13:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Dec 29 06:19:07 <ds2> I have had corruption on desktops
Dec 29 06:19:23 <ds2> journals doesn't guarantee anything about lost data
Dec 29 06:19:49 <ds2> esp. if the journal write is lost/corrupted so it goes back to a prior state w/o the journal entry
Dec 29 06:20:24 <yates> yeah, i guess if saving state was critical, that would be a problem.
Dec 29 06:20:56 <ds2> could be simple things like password change for the UI
Dec 29 06:20:57 <ds2> :D
Dec 29 06:21:25 <yates> yeah, but the chances? ...
Dec 29 06:21:37 <yates> then there's always Murphy's law.
Dec 29 06:22:52 <ds2> rather not have to explain things to irate customers if I can engineer out the risk
Dec 29 06:23:05 <ds2> there is just no good reason to go with debian
Dec 29 06:23:26 <yates> how about a package manager that has a whole crapload of stuff?
Dec 29 06:24:04 <yates> i was building natively on that project.
Dec 29 06:24:14 <yates> building the application, that is.
Dec 29 06:24:37 <yates> and i needed stuff like the soci database C++ library
Dec 29 06:24:54 <ds2> from a product standpoint that doesn't have much value
Dec 29 06:24:58 <yates> yeah, i could've tarballed it, but apt-get socii is just so easy...
Dec 29 06:25:15 <ds2> embedded stuff are fixed function
Dec 29 06:25:32 <ds2> that's ignoring the quagmire of license issues
Dec 29 06:25:33 <yates> how about troubleshooting?
Dec 29 06:25:57 <yates> customer xyz has problem abc with your company's board. you ssh in to take a look.
Dec 29 06:26:00 <ds2> if you got the resources to deal with the licensing issues... have fun.
Dec 29 06:26:14 <yates> "damn, i need nmap, or ..."
Dec 29 06:26:19 <yates> something not installed.
Dec 29 06:26:44 <ds2> vs you ship something GPLv3 and have no idea where the corresponding source debian is
Dec 29 06:26:51 <ds2> up the creek w/o a paddle
Dec 29 06:27:26 <yates> licensing is another issue. i thought we were discussing purely engineering reasons.
Dec 29 06:27:56 <yates> granted one i don't understand.
Dec 29 06:28:21 <yates> yes, at some level you coudl call that engineering, yes yes yes....
Dec 29 06:28:49 <ds2> providing sources is an engineering issue
Dec 29 06:28:59 <ds2> if you donno where the sources, you are dead.
Dec 29 06:29:07 <yates> sure, i know
Dec 29 06:29:35 <yates> they're in my tar/zipped bb-kernel i socked away for that release.
Dec 29 06:29:54 <ds2> kernel is easy... it is all those damn packages
Dec 29 06:31:24 <ds2> kernel, u-boot... that's all pretty universal esp. if you are doing your own HW. you KNOW what is going on cuz you worked on it
Dec 29 06:31:48 <yates> what packages do you need in the embedded app proper? i guess i gave one example earlier: socii c++ library. but i don't see a bunch of those being required for the actual application. am i wrong?
Dec 29 06:32:51 <yates> i guess you also would need all the standard installed packages - is that what you mean? i.e., the packages that get installed in a fresh bbb debian build
Dec 29 06:33:06 <yates> "included" is probably better than "installed"
Dec 29 06:33:30 <yates> openssh, e.g.
Dec 29 06:34:23 <yates> the ideal system doesn't exist.
Dec 29 06:34:30 <ds2> you ship it, you are responsible for getting sources
Dec 29 06:34:39 <ds2> don't matter if you use it or not
Dec 29 06:34:56 <ds2> a lot of the stuff in debian is compiled for options that you might not care about
Dec 29 06:34:57 <yates> you mean by the licensing rules?
Dec 29 06:35:03 <ds2> yep
Dec 29 06:35:34 <yates> well why would angstrom change any of this?
Dec 29 06:36:03 <yates> if you need a package, you need it.
Dec 29 06:36:15 <yates> no matter the distro
Dec 29 06:36:56 <ds2> you compile it all from sources
Dec 29 06:37:03 <ds2> you have to have had the sources
Dec 29 06:37:34 <yates> hey, it's been good chatting, ds2. it's getting late for me. have a happy new year! (i'll be saving this conversation for future reference)
Dec 29 06:37:37 <ds2> a lot of the yocto stuff is to address that
Dec 29 06:37:46 <ds2> have a happy new year yourself!
Dec 29 06:38:34 <yates> :)
Dec 29 08:24:46 <micha_> Does anyone knows which camera modules are supported by beagleboard-xm?
Dec 29 10:00:18 <Guest66784> cross compiled to basic c code our ubuntu laptop for beaglebone green
Dec 29 10:00:41 <Guest66784> but exe is not running
Dec 29 10:01:14 <Guest66784> "arm-linux-gnueabihf-gcc -mfpu=neon -mfloat-abi=softfp main.c -o main"
Dec 29 10:01:44 <Guest66784> and scp main root@192.168.2.41:/root
Dec 29 10:01:58 <Guest66784> -bash: ./main: No such file or directory
Dec 29 10:02:42 <Guest66784> main exe runs on beaglebone black but dont run on beaglebone green
Dec 29 10:07:22 <himmet> Hello
Dec 29 10:08:17 <Guest66784> how can I resolve this problem
Dec 29 10:25:45 <tbr> Guest66784: which distributions do you run on both?
Dec 29 10:27:26 <Guest66784> debian
Dec 29 10:28:19 <tbr> I'd expect debian images to be hardfp
Dec 29 10:28:36 <Guest66784> but black is debian
Dec 29 10:28:48 <Guest66784> too
Dec 29 10:29:07 <tbr> same version?
Dec 29 10:32:12 <Guest66784> black version :7.5
Dec 29 10:32:55 <Guest66784> green version: 7.8
Dec 29 10:34:54 <tbr> shouldn't be very different then
Dec 29 10:36:32 <Guest66784> can you explain a little bit?
Dec 29 10:36:33 <Guest66784> pls
Dec 29 10:41:27 <tbr> what does "file main" say?
Dec 29 10:41:50 <tbr> also what does "file /bin/bash" say on each of the boards?
Dec 29 10:43:31 <Guest66784> beaglebone black is OK,everything is running
Dec 29 10:44:04 <Guest66784> but "main" not running on green
Dec 29 10:44:40 <Guest66784> ./main: No such file or directory
Dec 29 10:45:58 <tbr> please answer my questions, thanks
Dec 29 10:46:17 <Guest66784> ı dont understand
Dec 29 10:46:27 <tbr> > what does "file main" say?
Dec 29 10:46:31 <Guest66784> file main say ??
Dec 29 10:46:33 <tbr> > also what does "file /bin/bash" say on each of the boards?
Dec 29 10:46:54 <tbr> yes, run the command
Dec 29 10:47:34 <Guest66784> ok one second
Dec 29 10:47:58 <Guest66784> ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=1a8601b954c83a01d91298d0f2f8f61ca033ebdd, stripped
Dec 29 10:48:41 <tbr> which one is that?
Dec 29 10:48:53 <Guest66784> this is "file /bin/bash"
Dec 29 10:49:04 <tbr> on which of the boards?
Dec 29 10:49:40 <Guest66784> green
Dec 29 10:49:48 <Guest66784> beaglebone green
Dec 29 10:49:50 <tbr> and on the black?
Dec 29 10:49:57 <Guest66784> main: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=6e55952a557992089e59b8b41fa40d54b12f49ec, not stripped
Dec 29 10:50:36 <Guest66784> ok will write beaglebone black
Dec 29 10:51:46 <Guest66784> beaglebone black:
Dec 29 10:51:56 <Guest66784> "file /bin/bash"
Dec 29 10:51:58 <tbr> so the "main" file is compiled for "softfp", notice that it's missing the "armhf" for the linker
Dec 29 10:53:23 <Guest66784> but I tried arm
Dec 29 10:54:17 <Guest66784> arm-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=softfp main.c -o main
Dec 29 10:55:30 <Guest66784> still continues the same problem.
Dec 29 10:57:18 <goonie> I'm having problems with booting a BBB off an SD card.
Dec 29 10:57:30 <goonie> I flash the latest Debian image, and it boots fine.
Dec 29 10:58:38 <goonie> but then after a reboot I can't access the device via USB.
Dec 29 10:58:52 <Guest66784> sorry tbr how can ı resolve prroblem ?
Dec 29 11:00:31 <tbr> goonie: give it time, first boot is slow
Dec 29 11:00:52 <tbr> goonie: if you interrupt first boot it might break things and you need to reflash
Dec 29 11:01:18 <tbr> Guest66784: you still haven't posted the output of "file /bin/bash" on the BBB
Dec 29 11:01:53 <ogra_> shouldnt he use the armel toolchain for building armel code ? :)
Dec 29 11:01:56 <goonie> OK, will try that.  I assume "shutdown -h now" will shut a BBB down cleanly? Trying to rule out shutdown corrutpion.
Dec 29 11:02:01 <Guest66784> ok I writing
Dec 29 11:02:29 <Guest66784> beaglebone black
Dec 29 11:03:11 <Guest66784> ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xc1c0045c796fe3b54c8e3496e2f4e1943e37025d, stripped
Dec 29 11:03:37 <Guest66784> this is "file/bin/bash"
Dec 29 11:04:25 <Guest66784> beaglebone black "file/main"
Dec 29 11:04:26 <Guest66784> ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x2a95556e08927955b4b8599e540da41fec492fb1, not stripped
Dec 29 11:08:15 <Guest66784> Sorry tbr, I posted outputs
Dec 29 11:09:20 <tbr> it didn't mention the interpreter
Dec 29 11:09:51 <tbr> anyway, I suspect that the BBB for some reason runs a softfp userland
Dec 29 11:10:11 <tbr> which means that binaries won't be compatible between both, as you already found out
Dec 29 11:10:33 <tbr> I'd recommend to reflash both devices with the latest debian image
Dec 29 11:10:48 <tbr> and then build for armhf
Dec 29 11:12:06 <Guest66784> mr tbr , I downloaded to latest debian image on sdcard
Dec 29 11:12:43 <Guest66784> Now , we are runnnig latest debian version on bbg
Dec 29 11:12:48 <Guest66784> debian 8.2
Dec 29 11:13:00 <tbr> make sure both boards run the same
Dec 29 11:13:24 <Guest66784> only bbg is debian 8.2
Dec 29 11:13:57 <Guest66784> bbb is still debian 7.5
Dec 29 11:15:12 <Guest66784> but still continuos problem on bbg
Dec 29 11:16:08 <tbr> you MUST build for armhf. This is the last time I'm going to repeat this.
Dec 29 11:16:17 <Guest66784> ok
Dec 29 11:18:51 <Guest66784> like this ?
Dec 29 11:18:54 <Guest66784> arm-linux-gnueabihf-gcc -mfpu=neon -mfloat-abi=softfp main.c -o main
Dec 29 11:19:14 <Guest66784> "-mfloat-abi=softfp " is it true ?
Dec 29 11:19:34 <tbr> softfp is WRONG
Dec 29 11:19:43 <Guest66784> it is hard ?
Dec 29 11:21:46 <Guest66784> tbr, it is running "mfloat-abi=hard"
Dec 29 11:22:04 <Guest66784> why softfp is wrong ?
Dec 29 11:23:03 <tbr> you might want to ask a web search engine about "the difference between arm softfp and hardfp" or such
Dec 29 11:23:56 <Guest66784> ı know the difference
Dec 29 11:24:32 <tbr> then the answer to your question should be obvious
Dec 29 11:24:40 <Guest66784> I use mfloat-abi=softfp
Dec 29 11:24:50 <Guest66784> but exe is not runnig
Dec 29 11:24:54 <Guest66784> running
Dec 29 11:25:25 * tbr is *not* going to repeat himself
Dec 29 11:27:11 <Guest66784> why doesn't run when mfloat=softfp
Dec 29 11:36:59 <tbr> Guest66784: I told you where your problem is. Repeatedly. What more can I do?
Dec 29 11:37:55 <Guest66784> tbr sorry, my english is little
Dec 29 11:39:48 <Guest66784> I want to use "softfp" on NEON
Dec 29 11:40:48 <Guest66784> dont want to use "hard"
Dec 29 11:42:01 <Guest66784> because I needed feature of softfp
Dec 29 11:43:31 <Guest66784> but the main is not running on bbg when mfloat-abi is softfp
Dec 29 11:43:46 <tbr> then you need to find an softfp image
Dec 29 11:43:51 <tbr> good luck with that
Dec 29 11:44:16 <ogra_> for next time:
Dec 29 11:44:17 <ogra_> dpkg --print-architecture
Dec 29 11:44:27 <ogra_> that prints the debian arch you are using
Dec 29 11:44:28 <Guest66784> have a softfp image
Dec 29 11:44:48 <Guest66784> http://beagleboard.org/latest-images
Dec 29 11:44:58 <Guest66784> ok
Dec 29 11:45:27 <Guest66784> dpkg --print-architecture              "armhf"
Dec 29 11:45:35 <tbr> I don't think any of the 'latest-images' are softfp
Dec 29 11:45:52 <ogra_> also dont use the hardfloat toolchain to build softfp like above ... there are many more defaults you would have to override ... if you want to build softfloat binaries use the -gnueabi toolchain packages, not -gnueabihf
Dec 29 11:45:55 <tbr> I'm surprised that there was a softfp debian image at all for the BBB at some point
Dec 29 11:46:13 <ogra_> yeah
Dec 29 11:46:17 <ogra_> thats rather weird
Dec 29 11:46:33 <tbr> as that would have implied armel
Dec 29 11:46:45 <tbr> which was what, ARMv5?
Dec 29 11:46:54 <ogra_> v4t or so even
Dec 29 11:47:02 <tbr> ugh
Dec 29 11:47:21 <ogra_> to keep openmoko in zombie state :)
Dec 29 11:48:56 <Vishal_> hello
Dec 29 11:49:10 <Vishal_> Vishal here
Dec 29 11:49:23 <Guest66784> tbr and ogra I build use -gnueabi
Dec 29 11:49:35 <Vishal_> i want help ralated to beaglebone black
Dec 29 11:49:50 <ogra_> well, then the result should be armel (softfp)
Dec 29 11:49:51 <Guest66784> but is not running
Dec 29 11:50:14 <ogra_> <Guest66784> arm-linux-gnueabihf-gcc -mfpu=neon -mfloat-abi=softfp main.c -o main
Dec 29 11:50:23 <ogra_> this isnt the softfp complier ...
Dec 29 11:51:24 <Guest66784> arm-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=softfp main.c -o main
Dec 29 11:51:29 <ogra_> (you can surely use the armhf compiler to build armel, but then only setting -mfpu=neon -mfloat-abi=softfp will not be enough ... there is lots of more defaults)
Dec 29 11:51:41 <ogra_> yeah, thats better
Dec 29 11:52:01 <ogra_> but effectively you should really see to run armhf on both devices ...
Dec 29 11:52:04 <Guest66784> but it is not running on bbg
Dec 29 11:52:16 <Guest66784> it is running on bbb
Dec 29 11:52:29 <ogra_> why do you define -mfpu=neon -mfloat-abi=softfp ?
Dec 29 11:52:42 <ogra_> let the compiler default do their duty instead ;)
Dec 29 11:52:47 <ogra_> *defaults
Dec 29 11:53:36 <Guest66784> I writing kaiser filteriing code
Dec 29 11:54:05 <Guest66784> floating operations must be fast
Dec 29 11:54:16 <Guest66784> so I use neon and softfp
Dec 29 11:58:34 <Guest66784> ogra
Dec 29 11:58:37 <Guest66784> sorry
Dec 29 11:58:49 <Guest66784> can you help me?
Dec 29 12:00:54 <tbr> so, you want fast floating point operations and then explicitly want to loose about 10% performance by using softfp instead of hardfp?
Dec 29 12:01:01 <tbr> I don't have to understand this...
Dec 29 12:03:59 <Guest66784> thx tbr
Dec 29 12:04:10 <Guest66784> for helping
Dec 29 12:04:15 <Guest66784> ok
Dec 29 12:04:22 <Guest66784> understand to you
Dec 29 15:43:02 <olfox> Hi all , i would like to use the 4D 7" display but for outdoor puropose, 250cd will be not enough... So find another display with higher brightness could be the solution. If so, must i choose a ttl display to be compatible? Thanks a lot !
Dec 29 15:48:37 <av500> olfox: ttl or HDMI
Dec 29 15:48:44 <av500> thats the two options you have
Dec 29 16:26:41 <zmatt> tbr: *lose
Dec 29 16:28:36 <tbr> yes
Dec 29 16:29:18 <zmatt> I wonder if he cared so much about performance, why there's no optimization flag
Dec 29 16:29:31 <zmatt> but oh well
Dec 29 17:47:53 <jacob33> is it possible to view 800x600 resolution on a 420x320 screen as a rolling/scrolling mouse view under debian xfce?
Dec 29 17:49:20 <jacob33> having problems setting things up as i can't click ok or apply
Dec 29 18:01:11 <zmatt> you can try requesting it with xrandr
Dec 29 18:05:11 <zmatt> xrandr --output FOO --panning 800x600      replace FOO by the name of the output (check by running xrandr without any arguments)
Dec 29 18:07:31 <zmatt> but that's only going to work if the fbdev driver supports software-panning... hardware panning can only work in the vertical direction
Dec 29 18:16:31 <jacob33> xrandr failed to get size of gamma for output default screen 0: minimun 480x320 current 480x320, maximum 480x320 default connected 480x320+0+0 0mm x 0mm 480x320 0.00*
Dec 29 18:18:57 <zmatt> which kernel?
Dec 29 18:19:38 <jacob33> i don't know I'm kinda new at this
Dec 29 18:19:45 <zmatt> uname -r
Dec 29 18:20:13 <jacob33> 4.1.15-v7+
Dec 29 18:20:36 <zmatt> huh, that's a weird kernel, what image are you running?
Dec 29 18:20:59 <zmatt> normally a kernel on a BBB will contain -bone or -ti in the name
Dec 29 18:21:05 <jacob33> debian i think
Dec 29 18:21:18 <zmatt> cat /etc/dogtag
Dec 29 18:21:46 <jacob33> no such file of directory
Dec 29 18:22:59 <zmatt> where'd you get it?  because a missing /etc/dogtag normally means a really old debian image (or a non-debian image), except that seems to be contradicted by the kernel version (which is weird, but not old)
Dec 29 18:24:53 <jacob33> I compiled it with a running version of kali 2.0
Dec 29 18:24:55 <zmatt> other files that might exist and indicate system version are /ID.txt  /etc/debian_version  /etc/rcn-ee.conf  /etc/os-release
Dec 29 18:25:20 <zmatt> ok so you got some weird but debian-like image?
Dec 29 18:25:34 <zmatt> cat /etc/debian_version
Dec 29 18:26:20 <jacob33> yes and i've had issues with it since I'm thinking about starting over but i don't want to loose all of my work
Dec 29 18:27:04 <jacob33> debian version "Kali Linux 2.0"
Dec 29 18:28:57 <zmatt> if you do start over, I recommend the latest jessie snapshot from here -> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
Dec 29 18:29:20 <zmatt> ok so you have a totally weird system, it'll be hard to give you much advice on that
Dec 29 18:29:24 <jacob33> ok thanks g2g my dog just excaped
Dec 29 18:51:04 <THE> hallo
Dec 29 18:51:38 <THE> IRENE FONTANELLO IS A BITCH
Dec 29 19:20:30 <Guest34724> on jessie (kernel 4.1). how can i disable i2c pins (P9_19 & 20)? need to use for GPIO.
Dec 29 19:21:02 <zmatt> use a device tree without capemgr
Dec 29 19:22:34 <Guest34724> so i'll need to disable the capemgr?
Dec 29 19:25:04 <zmatt> P9_19 and P9_20 are used for the I2C bus used for CAPE auto-detection
Dec 29 19:25:51 <Guest34724> ah so can they not be disable
Dec 29 19:25:56 <Guest34724> *d
Dec 29 19:26:13 <zmatt> they can, if you don't need automatic CAPE detection
Dec 29 19:26:19 <zmatt> I never use capemgr
Dec 29 19:26:37 <zmatt> but, sorry to leave you with incomplete explanation, but I gotto go
Dec 29 19:28:26 <Guest34724> ok
Dec 29 19:28:34 <Guest34724> might be worth just using a diff pin
Dec 30 00:22:52 <sd4130> hey guys- so i'm trying to enable the analog inputs on my beaglebone black
Dec 30 00:23:03 <sd4130> cd'd into /sys/bus expecting the iio path to be there, but it's not
Dec 30 00:23:14 <sd4130> any reason why this isn't included in the latest debian image from the website?
Dec 30 00:28:41 <sd4130> What i'm reading is something informing me to use the cape manager, but I'm guessing it's not in this distro
Dec 30 00:29:10 <sd4130> Would editing the .dtb file in the /boot/dtbs/ path be the right course of action to enable certain analog inputs?
Dec 30 00:38:09 <veremit> you need to configure the IO pins using a device-tree file or some virtual 'cape'
Dec 30 00:41:46 <sd4130> I see
Dec 30 00:42:50 <sd4130> I'll keep digging
Dec 30 00:42:50 <sd4130> Thanks
Dec 30 00:47:04 <veremit> my live beagle is too old .. but this may help a little .. http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc
Dec 30 00:47:21 <veremit> dunno where my other beagle is .. oh its *there* .. :)
Dec 30 01:13:12 <bertwert> Hello, would it be possible to get data from an image sensor on a BeagleBone Black?
Dec 30 01:22:35 <bertwert> The CMOS image sensor is this one: http://canada.newark.com/aptina-imaging/mt9p031i12stc/image-sensor-2-2-x-2-2-um-ilcc/dp/80P6532
Dec 30 01:23:26 <bertwert> All I want to do is get data from the sensor (5MP) and convert it to a DNG file.
Dec 30 01:29:31 <veremit> possible, yes.
Dec 30 01:29:53 <veremit> what's a DNG file?!
Dec 30 01:30:28 <bertwert> Adobe DNG -> RAW file
Dec 30 01:30:43 <bertwert> https://en.wikipedia.org/wiki/Digital_Negative
Dec 30 01:30:43 <veremit> ah so I See
Dec 30 01:31:11 <veremit> you're not hoping to capture video .. just still images?
Dec 30 01:31:17 <bertwert> No video
Dec 30 01:31:40 <veremit> ah an Aptina .. heh.
Dec 30 01:32:10 <bertwert> but it would be nice to get as high as frame rate possible from the sensor - sensor is rated 15fps
Dec 30 01:32:21 <bertwert> 15fps at 5mp
Dec 30 01:32:32 <bertwert> but that is not neccesary
Dec 30 01:34:28 <veremit> yeah the BBB won't process the video fast enough .. unless you dump it straight to ethernet or disk :)
Dec 30 01:34:44 <veremit> you'd struggle on ethernet without compression
Dec 30 01:35:25 <veremit> <= does h264 HD video by day . normally.
Dec 30 01:36:21 <bertwert> Have you got suggestions on how to connect the sensor/programming etc. or a link to a guide?
Dec 30 01:36:37 <veremit> if it were me, I'd capture the data using the PRU module
Dec 30 01:36:43 <bertwert> I haven't bought either the sensor or BBB yet.
Dec 30 01:36:53 <bertwert> No experience with either as well :)
Dec 30 01:37:01 <veremit> but you're probably going to have to write the data out fairly quickly or you'll run out of RAM I -think-
Dec 30 01:38:00 <bertwert> I guess 512mb RAM, a 5mp raw file wouldn't be any bigger than 10-20mb hmm
Dec 30 01:38:42 <veremit> ah perhaps not .. depends how many bits/pixel ;)
Dec 30 01:39:25 <bertwert> 12 bit, from the data sheet. too lazy to calculate how many mb right now.
Dec 30 01:39:31 <bertwert> http://www.farnell.com/datasheets/1525407.pdf
Dec 30 01:42:20 <veremit> I've gotta concede, though I can't recommend it (per se) .. if you want to do serious video work .. http://www.mouser.com/search/refine.aspx?Ntk=P_MarCom&Ntt=105312261
Dec 30 01:42:37 <veremit> the DM368 (with Leopard modules) is what I've been working with.
Dec 30 01:42:56 <veremit> their SDK is .. *ahem* a mess .. but its the chip for video processing
Dec 30 01:46:20 <bertwert> I don't want video... for still photos. Wildlife through a telescope, or attach to microscope. Also going to make an adapter for M42 lenses, etc.
Dec 30 01:48:26 <bertwert> How much other hardware would I need apart from a BB and sensor? What sort of connection in between?
Dec 30 01:50:37 <veremit> hmm .. electrically .. not much
Dec 30 01:52:23 <bertwert> Can I do it with the 'bare' sensor (48 pin) or do I need to buy it in a configuration thing?
Dec 30 01:53:21 <veremit> should be able to do with bare sensor .. as long as you have good electrical and mechanical interfaces
Dec 30 01:53:32 <veremit> http://www.onsemi.com/PowerSolutions/product.do?id=MT9P031 - current data
Dec 30 01:55:29 <veremit> there's i2c drivers in kernel for control .. http://lxr.free-electrons.com/source/drivers/media/i2c/mt9p031.c
Dec 30 01:55:59 <veremit> but that's probably not going to help you as you're not going to be enumerating it as a video device lol
Dec 30 01:56:27 <bertwert> ok...
Dec 30 01:56:36 <veremit> it'll give you some i2c control guidance though
Dec 30 01:58:02 <bertwert> on the onsemi page i like how it says 'uses: security' when i'm going to use this for wildlife/astro/microphotography lol
Dec 30 01:58:37 <veremit> ah yes .. 12-bit x 2752x2004 pixels = 757 Mb
Dec 30 01:58:58 <veremit> eh its a standard "ccd" module .. most commerically active application is security
Dec 30 01:59:17 <veremit> we use HD blocks for both security and broadcast video
Dec 30 01:59:37 <bertwert> cmos not ccd
Dec 30 01:59:42 <veremit> 1080p 30fps
Dec 30 01:59:50 <veremit> mm ok same old :P lol
Dec 30 02:00:22 <bertwert> actually they are quite different but what ever lol
Dec 30 02:01:00 <veremit> have you found an interface board? you're gonna need some form of pcb :)
Dec 30 02:01:06 <veremit> or are you developing a cape?
Dec 30 02:01:07 <bertwert> not yet
Dec 30 02:01:13 <bertwert> still looking around
Dec 30 02:01:24 <bertwert> no
Dec 30 02:02:41 <bertwert> this might help me... https://groups.google.com/forum/#!topic/beagleboard/ydjqGjzJpps
Dec 30 02:03:26 <bertwert> maybe not.
Dec 30 02:05:24 <veremit> something like .. http://canada.newark.com/aptina-imaging/mt9p031i12stch-es/mt9p031-cmos-image-sensor-5mp/dp/80P6534
Dec 30 02:05:30 <veremit> even if you don't need the usb
Dec 30 02:05:48 <veremit> gives you power supply, and some interfacing
Dec 30 02:06:04 <veremit> wonder what the s/w usb interface is like ..
Dec 30 02:06:34 <veremit> if you went with a quad-core arm .. you might be able to run that straight in .. Rpi2/wandboard-quad .. perhaps... thinking laterally
Dec 30 02:07:26 <bertwert> was asking on pi forums and they said try BBB lol
Dec 30 02:08:00 <veremit> otherwise .. http://www.ti.com/devnet/docs/catalog/endequipmentproductfolder.tsp?actionPerformed=productFolder&productId=12600
Dec 30 02:08:06 <bertwert> looks like this sensor has been used on the beagleboard-xm
Dec 30 02:08:20 <bertwert> but at this price i might as well go leopad
Dec 30 02:09:31 <bertwert> bbb and sensor would cost me 100 and i'm trying to keep this under 150...
Dec 30 02:09:32 <veremit> wow .. that looks pretty nifty that interface
Dec 30 02:09:43 <veremit> yeah you're gonna struggle .. video is always pricey
Dec 30 02:09:56 <bertwert> photos, not video ;)
Dec 30 02:10:08 <veremit> you're looking at a video camera ;)
Dec 30 02:10:15 <bertwert> i know :
Dec 30 02:10:18 <veremit> may find a still sensor is easier to 'plumb' together
Dec 30 02:10:27 <bertwert> yep
Dec 30 02:10:31 <veremit> but the technology has kinda moved on .. :/
Dec 30 02:10:56 <bertwert> thinking about taking apart a compact camera and checking out the sensor
Dec 30 02:13:03 <veremit> btw, don't forget a lens :)
Dec 30 02:13:15 <veremit> .. in the budget
Dec 30 02:14:22 <bertwert> telescope and microscope, also think of putting a k-mount on the camera from extension tube parts
Dec 30 02:14:37 <bertwert> i have lots of k mount and m42 lenses...
Dec 30 02:14:49 <veremit> you might be better trying the camera modules more designed for mobile applications .. perhaps not usb, but cell-phone ..
Dec 30 02:15:03 <veremit> then you can go straight in on camera interfaces on rpi/etc
Dec 30 02:15:26 <bertwert> used a webcam today but the image quality and resolution was ****
Dec 30 02:15:27 <veremit> the BBB just doesn't have parallel input buses as standard .. so you'd have to implement capture by hand
Dec 30 02:15:40 <veremit> yeah you got the same kinda dilemma .. high quality = $$$$
Dec 30 02:15:47 <bertwert> i could just use rpi and rpi camera as well... :)
Dec 30 02:15:59 <veremit> the sensors are fairly easy to come-by .. its the just the back-end hardware isn't
Dec 30 02:16:31 <veremit> And I can concede, the sensor quality can be very good for not-too-bad $$
Dec 30 02:16:39 <bertwert> eventually in my future i plan on using a digital sensor in film camera and make millions lol
Dec 30 02:16:52 <veremit> heh good luck ;)
Dec 30 02:17:02 <bertwert> i know IQ can be good for not too much (my dslr cost only $500!)
Dec 30 02:17:25 <veremit> what ya get?
Dec 30 02:17:33 <bertwert> My DSLR?
Dec 30 02:17:36 <veremit> mhmm
Dec 30 02:17:42 <bertwert> Pentax K-50
Dec 30 02:17:52 <veremit> ah ok
Dec 30 02:18:02 <veremit> most of the keen photographers I know have gone nikon
Dec 30 02:18:23 <bertwert> That is why i have many k mount and m42 lenses... and i don't mention Canikon lol
Dec 30 02:18:42 <veremit> canon are a different breed
Dec 30 02:18:52 <veremit> but seems nikon are popular
Dec 30 02:18:57 <veremit> And good
Dec 30 02:19:12 <veremit> my plain 35mm SLR is canon. me like.
Dec 30 02:19:24 <bertwert> but bentax is best bang for the buck.
Dec 30 02:19:33 <veremit> just getting harder to get film+processing
Dec 30 02:19:50 <bertwert> i would shout a roll a film one day but for film and processing costs
Dec 30 02:20:09 <bertwert> and my ability lol
Dec 30 02:20:52 <veremit> this guy is a friend of work's .. http://www.poochpurtillphotography.com
Dec 30 02:21:03 <veremit> knows his sh1t
Dec 30 02:21:14 <veremit> nice chap too
Dec 30 02:21:48 <bertwert> with the image sensor i showed on my telescope it would be an equivalent 4480mm lens...
Dec 30 02:22:18 <veremit> hehe nice
Dec 30 02:22:43 <bertwert> i have to go now, thnaks for the chat and advice
Dec 30 02:23:23 <veremit> np
Dec 30 02:53:58 <Clay__> Hey, finally trying to get my beagle bone up and running and I'm having driver issues. I installed all the windows 64bit drivers successfully, board seems to boot correctly (I see flickering LED's which eventually settle to a 'heartbeat') but device does not install software when I plug it in. It's not serving a local webpage (192.168.7.2) nor is the site http://beagleboard.org/getting-started showing that the first two steps (install
Dec 30 02:55:58 <veremit> that'll be shitty windows-lack-of-gadget
Dec 30 02:56:10 <veremit> just shitty usb-gadget period tbh.
Dec 30 02:58:35 <Clay> in that case, where can I update the windows usb gadgets?
Dec 30 02:59:52 <Clay> the mass storage gadget seems to work though...
**** ENDING LOGGING AT Wed Dec 30 02:59:59 2015