**** BEGIN LOGGING AT Mon Apr 11 02:59:58 2016
Apr 11 04:13:12 <zmatt> to further clarify: when using a gcc-based toolchain you can pass any combination of assembly files, C/C++ sources, and object files and it'll compile/assemble as needed and invoke the linker to link the bunch together (along with libraries and startfiles depending on commandline options given)
Apr 11 04:14:55 <zmatt> you mentioned neither what your target nor your toolchain is (CCS is just an IDE, there's no "CCS assembler") so it's hard to give specifics
Apr 11 04:15:32 <zmatt> though things actually work similar for TI's toolchains (e.g. for PRU)
Apr 11 04:17:11 <zmatt> for baremetal applications a linker script is generally also involved.  (well, for hosted applications too, but then it's usually a standard one you don't need to be concerned about)
Apr 11 05:08:01 <kremlin> zmatt: this is all using CCS' PRU compiler/linker
Apr 11 05:15:08 <snowstaff> Guys, if PRU receives 3.3V - it will be interpreted how logical 1. If from line comes (-3.3V) - it interpreted how logical 1 or 0?
Apr 11 06:01:42 <veremit> snowstaff: 0 .. but that may cause you problems as it shouldn't go below 0v
Apr 11 06:39:57 <zmatt> snowstaff: it is interpreted as "absolute maximum rating violation, processor may be fried"
Apr 11 06:42:34 <zmatt> if the source is weak enough (fairly high impedance) then it will simply fail at getting the pin significantly below 0
Apr 11 06:43:59 <zmatt> if it does manage to get the pin below -0.5V or the current exceeds 45 mA you're in violation of the absolute maximum ratings
Apr 11 06:45:16 <zmatt> kremlin: ah, PRU.  then the same is still true actually, although the syntax is wildly different.  but if you're using CSS it should normally take care of these things for you, that's what an IDE is for
Apr 11 07:00:39 <snowstaff> zmatt, veremit, thanks. I solved this - need buffer for that signal.
Apr 11 07:01:38 <zmatt> for future reference, check the processor datasheet for electrical characteristics (such as absolute maximum ratings and switching thresholds)
Apr 11 07:03:31 <zmatt> switching thresholds are also in my spreadsheet (on the "Elec" tab)... for inputs in 3.3V domain, logical 0 is < 0.8 V, logical 1 is > 2V
Apr 11 07:07:05 <veremit> zmatt++
Apr 11 07:10:02 <zmatt> other info that can be gleaned from that page is that at 3.3V the internal pull-ups are pretty much unspecified... min 19 uA max 243 uA
Apr 11 07:11:27 <veremit> zmatt: +3.3v?
Apr 11 07:11:42 <veremit> I thought IO was 1.8v .. but perhaps not.
Apr 11 07:11:51 <veremit> <= needs intravenous caffeine drip
Apr 11 07:12:36 <zmatt> they'd much prefer to be, but they support either 1.8V or 3.3V operation and on the BBB they chose the latter obviously
Apr 11 07:14:00 <zmatt> for IO banks operated at 1.8V the internal pulls have 50% tolerance, which is pretty standard for uncalibrated on-chip resistors
Apr 11 07:14:45 <zmatt> at 3.3V same is still true for pulldown, but pullup completely sucks
Apr 11 07:15:14 <zmatt> the minimum specified is basically identical to the max current of a pull-disabled pin
Apr 11 07:16:03 <zmatt> (although for pull-disabled you obviously don't know in which direction it'll drift)
Apr 11 08:47:19 <snowstaff> One more question: why when i use SBCO (for RAM0, example), max range for ofset 255?
Apr 11 08:48:27 <snowstaff> How to apply to the address 256, for example?
Apr 11 09:00:44 <Spidler> veremit: High latency, regarding UART/cape,  "yep, I know" on the toggle. Just that it _receives_ data on rs485, but transmission goes active on rs232. I'm assuming that device tree file is fubar somehow?
Apr 11 09:01:23 <veremit> Spidler: I think I read that the UART4 has no link to the RS485 transmitter .. and they are shared between RS232 and RS485
Apr 11 09:01:42 <veremit> you may wish to check the schematics yourself .. I'll see if I can find the link I had ..
Apr 11 09:03:00 <Spidler> veremit: Yeah, Afaik that's true. The cape has a jumper to toggle rs323/485, but whats messing with me is that it ... doesn't seem to work.
Apr 11 09:03:46 <veremit> Spidler: I think what you're trying to do  may be possible lol .. have you got a schematic/fritzing/etc of what you're trying to do? it -could- be a DT issue .. but I'm not (yet) convinced ..
Apr 11 09:05:15 <Spidler> veremit: What I _want_ to do is: Get rs485 working on kernel 4.4 or above with the CBB-serial cape
Apr 11 09:05:37 <Spidler> veremit: What I _get_ is rs485 -recieve-  automatic RTS working with driver, but _output_ data written goes on the rs232 ports.
Apr 11 09:05:50 <Spidler> And thats why I have a headache.
Apr 11 09:05:56 <veremit> Spidler: that suggests to me you have a jumper issue .. >,<
Apr 11 09:06:05 <veremit> as its the same .. port? pins?
Apr 11 09:06:12 * veremit digs up the schematics again
Apr 11 09:06:20 <Spidler> https://docs.google.com/document/d/1y0aKYqKd3_5HuzUvIepQmC5AjbFIqBlBak-Jtv0YB7Q/edit# <-- cape schematics
Apr 11 09:06:25 <Spidler> Well, documentation.
Apr 11 09:06:58 <veremit> oh bugger .. I need to install eagle .. hold on ..
Apr 11 09:07:12 <Spidler> Uh oh, that sounds scary :)
Apr 11 09:07:22 <veremit> Spidler: https://raw.githubusercontent.com/lgxlogic/CBB-Serial/master/Eagle-files/CBB-Serial-r02.sch
Apr 11 09:07:43 <Spidler> Yeah, I'm not the right guy to get there. Hardware really isn't my thing.
Apr 11 09:08:36 <veremit> I *wish* people would do PDF exports ..
Apr 11 09:10:17 <dirkk> Hi, I'm trying to cross compile Qt program from windows machine to my beaglebone black. I downloaded https://launchpad.net/linaro-toolchain-binaries/trunk/2013.10/+download/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10-20131018_win32.exe
Apr 11 09:10:36 <dirkk> but I don't know where to find the appropriate qmake file
Apr 11 09:11:00 <veremit> dirkk: you should have a <project name>.pro file no?
Apr 11 09:11:46 <dirkk> veremit: yes you mean in qt project
Apr 11 09:12:16 <veremit> qmake will generate a Makefile from the .Pro
Apr 11 09:12:51 <LetoThe2nd> dirkk: i highly doubt that the toolchain even comes including qt libraries to link against.
Apr 11 09:13:05 <LetoThe2nd> dirkk: step #1: get a qt-aware toolchain.
Apr 11 09:13:32 <dirkk> veremit: I have to setup the kit in the Qt Creator settings and I have to define Qt version with a qmake
Apr 11 09:14:37 <veremit> yeah Leto has a point .. but there are ways...
Apr 11 09:14:45 <dirkk> LetoThe2nd: do you know one ?
Apr 11 09:15:32 <LetoThe2nd> dirkk: nope. and if i had, it would be of no use to you. the toolchain has to fit the environment that you have in use on your bbb.
Apr 11 09:16:07 <LetoThe2nd> dirkk: so step #0: identify the environment on your BBB and select a corresponding toolchain provider.
Apr 11 09:17:16 <dirkk> LetoThe2nd: Did you say that I can't cross compile windows to bbb. My bbb is running on Jessie Debian
Apr 11 09:17:21 <dirkk> *?
Apr 11 09:18:37 <LetoThe2nd> dirkk: no, i did not say that you can't - i just said that its not trivial getting the fitting toolchain
Apr 11 09:18:37 <tbr> nothing I'd recommend to attempt by a beginner
Apr 11 09:18:50 <LetoThe2nd> exactly.
Apr 11 09:18:59 <tbr> far easier to spin up a linux VM and set things up in there
Apr 11 09:19:13 <LetoThe2nd> cross compiling for qt onto a desktop style distro under linux is hard enough already.
Apr 11 09:21:28 <dirkk> Ok ok I will try LinuxVM to bbb first. Thanks veremit, LetoThe2nd, tbr
Apr 11 09:22:36 <veremit> don't get caught out biulding x86/64 binaries when you want arm either .. you'res till gonna need  across-compiler lol
Apr 11 09:23:45 <LetoThe2nd> yeah. one would usually start 1) compile in target. 2) crosscompile on a closely related environment 3) crosscompile using a build system
Apr 11 09:23:57 <LetoThe2nd> note that there is no windows involved anywhere ;-)
Apr 11 09:24:44 <dirkk> veremit: yes I know. I found more tuto with Linux and approximate windows tuto (for c. compiling)
Apr 11 09:25:04 <Spidler> C++ is a bit more painful than C to cross compile, in practice.
Apr 11 09:25:29 <zmatt> Spidler: depends on the code I guess
Apr 11 09:25:38 <LetoThe2nd> Spidler: nope, you are mixing up things. generally it is harder to cross compile when you need to link against any libraries on the target.
Apr 11 09:25:50 <Spidler> zmatt: True, but symbol versioning and features gives me shivers.
Apr 11 09:26:09 <LetoThe2nd> a hello world that depends on nothing but libc is equqlly trivial in c and c++
Apr 11 09:26:11 <Spidler> LetoThe2nd: Sure, if you just cross compile static binaries it's mostly fune.
Apr 11 09:26:16 <zmatt> symbol versioning?  that has nothing to do with C++
Apr 11 09:26:22 <LetoThe2nd> zmatt: ++
Apr 11 09:26:42 <LetoThe2nd> that the point. its the dependencies that give you headaches - not the language (dialect)
Apr 11 09:26:57 <zmatt> Spidler: I wouldn't recommend static compilation
Apr 11 09:27:04 <zmatt> on glibc targets anyway
Apr 11 09:27:19 <zmatt> one utterence of something like printf and you have a huge binary
Apr 11 09:27:19 <Spidler> Not as if static vs- glibc is 'static' in that regard either.
Apr 11 09:27:32 <Spidler> Because nss and others can still come in play.
Apr 11 09:27:42 <Spidler> Or did that get fixed?
Apr 11 09:28:07 <zmatt> I regularly cross-compile baremetal C++ executables in range 6 - 20 KB though
Apr 11 09:28:20 <zmatt> nss is runtime configuration anyway
Apr 11 09:28:26 <Spidler> I irregularly cross-compile entire distributions....
Apr 11 09:28:34 <Spidler> Thus a lot of my pain with C++
Apr 11 09:30:10 <zmatt> I've discovered how easy it is to use system-nspawn + qemu-user to enter a container of a different arch, while using bind mounts to overlay some executables that are performance critical (or not supported by qemu-user) from the host system
Apr 11 09:30:25 <zmatt> with some systemd stuff overlayed I can even "boot" a minimal armhf in a container
Apr 11 09:30:32 <zmatt> (gives a really weird uname -a)
Apr 11 09:30:51 <Spidler> Haha.
Apr 11 09:30:59 <zmatt> I think if you manage to get a cross-compiler in that environment acting like it's the host compiler, then cross-compilation suddenly becomes a *lot* easier
Apr 11 09:31:04 <zmatt> configure scripts will work
Apr 11 09:31:17 <zmatt> everything thinks it's just native-compiling on the target
Apr 11 09:31:19 <Spidler> Yea, true.
Apr 11 09:31:46 <LetoThe2nd> hence step 3)
Apr 11 09:31:50 <zmatt> as long as key executables are in fact native, you'll get close to normal cross-compilation performance
Apr 11 09:32:17 <LetoThe2nd> properly set up your infrastructure so a buildsystem takes care of all that and hides the magic away.
Apr 11 09:32:58 <veremit> leto .. that should be your #1 aim ;)
Apr 11 09:33:05 <zmatt> yeah, I haven't tried it yet though... so there might still be annoying obstacles in getting the cross-compile to behave sufficiently native
Apr 11 09:33:22 <zmatt> *cross-compiler
Apr 11 09:33:40 <zmatt> I mean, w.r.t. paths used and such
Apr 11 09:33:51 <zmatt> in my memory paths can be headache :P
Apr 11 09:34:14 <Guest48906> Can someone briefly explains the diff between bb-kernel & ti-kernel for BBB.
Apr 11 09:37:14 <zmatt> Guest48906: 4.1-ti has improvements to TI-specific stuff that sometimes takes annoyingly long to hit mainline for some reason
Apr 11 09:37:43 <zmatt> 4.1-bone is useful for people who still want uio_pruss
Apr 11 09:38:17 <zmatt> 4.4-bone is useful for those who don't need to specific enhancements of 4.1-ti and prefer the general improvements of mainline linux
Apr 11 09:38:32 <zmatt> this is my very short impression
Apr 11 09:39:53 <Guest48906> thanks so much zmatt, what abount earlier releases? it seems that u prefer 4.x.x over 3.8 or 3.14.x-ti am i right?
Apr 11 09:41:33 <zmatt> well, I'm not really into archeology
Apr 11 09:42:52 <tbr> 3.8 is for people who like to copy paste #exactsteps from random internet pages
Apr 11 09:44:22 <Guest48906> :), i debugged the 3.8 kernel booting and it was faster than 3.14-ti for same rootfs. so i thogut 3.8 is more stable
Apr 11 09:45:04 <Guest48906> but i should also try 4.1.-ti . thanks
Apr 11 09:57:06 <veremit> Spidler: http://expirebox.com/files/e147ec1c0ff9dff5079aed5450751ea6.pdf <= pdf version of schematics
Apr 11 09:59:02 <Spidler> veremit: Thank you!
Apr 11 10:00:31 <veremit> Spidler: I'd suggest probing the signal from the P8/9 header through and see where its getting 'lost'
Apr 11 10:00:52 <veremit> I suspect its coming out the BBB right .. if not .. I think you can suspect the DT may need 'tweaking'
Apr 11 10:01:13 <Spidler> Mmm
Apr 11 10:01:21 <Spidler> DT might be it right now.
Apr 11 10:02:13 <veremit> is the software on the google drive?
Apr 11 10:04:29 <Spidler> veremit: Sorry, I have a hard time parsing that sentence. "the software" refers to DT files, or just the code I'm using to test this with?
Apr 11 10:04:52 <veremit> Spidler: my bad .. don't worry .. I'm on it :D
Apr 11 10:05:23 <Spidler> veremit: the bb.org overlay repo and the CBB-serial repo contain.. slightly differing DT files it seems
Apr 11 10:07:45 <Spidler> veremit: Where the CBB-serial DT file seems to set target to uart5  and uart3,  while bb.org uses uart2 and uart4 ..
Apr 11 10:07:47 <veremit> Spidler: can you link either .. can't see anythiing in the Official repo
Apr 11 10:07:51 <Spidler> Were there an off-by-one somewhere?
Apr 11 10:08:25 <Spidler> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts
Apr 11 10:08:33 <Spidler> https://github.com/lgxlogic/CBB-Serial/blob/master/overlay/cape-CBB-Serial-r01.dts
Apr 11 10:13:55 <veremit> Spidler: have you tried both? I'd be inclined to go with RN's work ..
Apr 11 10:14:38 <veremit> I suspect with changing kernel versions there was a renumbering
Apr 11 10:14:43 <Spidler> Probably
Apr 11 10:14:46 <veremit> else you'd see it on yet another port...
Apr 11 10:14:52 <Spidler> Yea
Apr 11 10:14:59 <veremit> case of "join the dots" if you will
Apr 11 10:15:28 <Spidler> Right now it's a weekend since I played with this, so I'm about to blow all that I have and start over, starting at the beginning and move from there.
Apr 11 10:15:39 <Spidler> Too many combinations of kernels, DT's and settings
Apr 11 10:16:03 <Spidler> Not to mention omap_serial vs 8250 driver
Apr 11 10:17:59 <veremit> yeah tell me about it. I'm holding off investigating RS485 myself .. but I'd go direct to UART pins and add the conversion after. The support for the TXEN signal is mostly missing from most implementations, and that's critical for my applications.
Apr 11 10:18:15 <Spidler> Yeah
Apr 11 10:18:26 <Spidler> I'm talking low speed stuff anyhow. 2400 baud
Apr 11 10:18:28 <veremit> definitely not designed for it
Apr 11 10:18:33 <Spidler> Could be bit-banged :)
Apr 11 10:18:36 <veremit> ah we're on 115200 for speed :)
Apr 11 10:18:40 <veremit> yeah .. go for the PRU ;) hehe
Apr 11 10:19:17 <veremit> I know how stupid it seems .. but this seems to be the shape of electronics+software these days!
Apr 11 10:19:30 <Spidler> I know, and it's really bugging me
Apr 11 10:20:09 <veremit> Spidler: do some probing on the P8/9 pins, let me know what you find. If the UART is wrong, you'll see it on the third one (not connected via cape) on the BBB headers
Apr 11 10:20:27 <veremit> I can't remember, think its UART5 that appears on there too
Apr 11 10:20:47 <veremit> all I remember is they skip one .. so its 1,4,5 or somesuch
Apr 11 10:21:25 <Spidler> I think one of them (uart3?) had only TX line connected and no RX?
Apr 11 10:21:29 <Spidler> or was it the other way around?
Apr 11 10:22:05 <Spidler> 0 at least works,  although I can't have my probe hooked to it since the shield is in the way...
Apr 11 10:23:12 <veremit> Spidler: http://elinux.org/Beagleboard:Cape_Expansion_Headers - P8 UART1,2,4 .. P9 has U5, but its shared with the LCD pins / HDMI so you'd have to unload/disable all that crap
Apr 11 10:24:26 <veremit> ok I need to shower and git to work lol .. good luck folks!
Apr 11 10:24:48 <Spidler> veremit: Thanks for your help!
Apr 11 10:24:54 <veremit> np
Apr 11 11:35:19 <zmatt> pfft, recent 4.4 kernels did some work on the SPI driver... gpio chip selects added, but the driver seems to have broken horribly as a side-effect :/
Apr 11 11:36:01 <zmatt> and spams my kernel log with "not using DMA for McSPI" .. WHY WOULD I CARE... those are like 4-byte transfers I'm doing
Apr 11 11:41:34 <zmatt> k, bbl
Apr 11 11:57:18 <snowstaff> Guys, how much from Data 8KB RAM 0 available to me for write?
Apr 11 12:18:29 <zmatt> both PRU cores have full access to both 8KB data rams as well as the 12 KB shared ram... how you use it is up to you.  if you use the C compiler then it might allocate some stuff there itself (check the linker map), if you use pasm then you have complete freedom
Apr 11 12:22:28 <zmatt> anyway, really afk now
Apr 11 12:35:41 <Venataratnam> Hi
Apr 11 12:36:26 <av500> Lo
Apr 11 12:39:05 <Venkataratnam> Hello
Apr 11 12:39:24 <av500> Lo
Apr 11 12:39:44 <tbr> mid(i)
Apr 11 12:58:08 <thinkfat> you guys!!
Apr 11 12:58:19 <Spidler> Wasn't me!
Apr 11 13:46:15 <alexhiam> Spidler: having trouble with the CBB-Serial?
Apr 11 13:49:49 <Spidler> alexhiam: yeap
Apr 11 13:58:55 <Spidler> alexhiam: I'm trying to get rs485 working with 4.4.x kernels.
Apr 11 13:59:21 <alexhiam> Spidler: the jumper only switches the RX, so it will still be TXing on 232
Apr 11 13:59:31 <Spidler> .....
Apr 11 14:00:00 <Spidler> alexhiam: That explains why I can't seem to get two way working on RS485.
Apr 11 14:00:14 <alexhiam> the idea being that if you're using that 485 you probably won't have anything connected to that 232
Apr 11 14:00:24 <alexhiam> well, it'll TX to both
Apr 11 14:00:25 <Spidler> Also true
Apr 11 14:00:30 <Spidler> Actually, no.
Apr 11 14:00:36 <Spidler> It's only TX'ing on rs232 :(
Apr 11 14:00:55 <Spidler> Its dead outgoing on the rs485 labelled connections
Apr 11 14:01:17 <alexhiam> if you're not seeing the 485 TX then I'd guess the RE/DE line low the whole time
Apr 11 14:01:22 <Spidler> And the assumption is correct, I don't care the least about rs232 for uart4.
Apr 11 14:01:36 <Spidler> Lemme hook the oscilloscope back up
Apr 11 14:01:45 <alexhiam> you have to tell the omap serial driver to use 485 mode, and you have to tell it which gpio pin to use
Apr 11 14:01:48 <Spidler> I know I've had it go high when transmitting, but not seeing traffic
Apr 11 14:02:01 <Spidler> Right, omap serial, 8250 serial.  Dammit
Apr 11 14:02:05 <Spidler> lemme rebuild the kernel again.
Apr 11 14:03:28 <alexhiam> you can either tell it the RE/DE GPIO through the DT or with an ioctl
Apr 11 14:04:08 * alexhiam hasn't tried 485 since 3.8, so omap-serial may have changed some
Apr 11 14:06:00 <Spidler> Via DT is basically loading the UART4-RTSCTS DT overlay, correct?
Apr 11 14:06:40 <alexhiam> no, at least in 3.8 omap-serial doesn't support driving RE/DE with RTS, so you also need to give it a GPIO pin
Apr 11 14:07:38 <Spidler> 3.8 is sadly flat out due to other requirements.  4.4 and above (well, 4.3 but noone really uses 4.3).  I got it all to work on the 3.8  with GPIO pin driving
Apr 11 14:09:16 <alexhiam> 'rts-gpio' in DT
Apr 11 14:09:31 <alexhiam> https://github.com/Sillern/BB-RS485/blob/master/BB-RS485-00A0.dts
Apr 11 14:10:00 <Spidler> That's a different one compared to the others I've seen.....
Apr 11 14:10:11 <alexhiam> and 'gpio_pin' in ioctl
Apr 11 14:10:33 <alexhiam> I haven't tried the DT way
Apr 11 14:11:16 <Spidler> I'm still waiting for my kernel rebuild, something is going weirdly slow here
Apr 11 14:23:56 <Xabaras76> Hello to everyone.....!
Apr 11 14:24:43 <Spidler> hello, Xabaras76
Apr 11 14:24:58 <Xabaras76> I need help to install SGX driver in a beaglebone black.....
Apr 11 14:26:04 <Xabaras76> I have followed the instructions here : http://elinux.org/BeagleBoardUbuntu#SGX_BeagleBone.2FBeagleBone_Black
Apr 11 14:26:10 <tbr> Xabaras76: and which system are you running?
Apr 11 14:26:37 <Xabaras76> I can install the driver...but it won't load at the beginning......
Apr 11 14:27:14 <Xabaras76> I have tryied a 3.14 kernel.....and a 4.1 kernel.....but nothing change.....
Apr 11 14:27:39 <Xabaras76> Hello tbr...I'm running debian
Apr 11 14:28:31 <tbr> if you are running the official debian image, then there should be scripts and other things to help you with that.
Apr 11 14:28:34 <tbr> probably in /opt
Apr 11 14:28:48 <tbr> maybe even packages, then apt might know
Apr 11 14:30:57 <Xabaras76> well...I can't find anything about scripts that install sgx driver...
Apr 11 14:31:24 <Xabaras76> I would like if a script is made....!! :)
Apr 11 14:32:07 <tbr> hrm, pretty much same instructions on the wiki for debian: http://elinux.org/BeagleBoardDebian#SGX_Drivers
Apr 11 14:33:01 <tbr> ./sgx_create_package.sh
Apr 11 14:33:11 <tbr> sudo ./sgx-install.sh
Apr 11 14:33:20 <tbr> there, one script for x86 and one for arm
Apr 11 14:33:24 <Xabaras76> yes...I have made this passages...described in the wiki.....
Apr 11 14:33:33 <Xabaras76> yes I have made it....
Apr 11 14:33:53 <tbr> the period key on your keyboard seems to be broken, it's bouncing
Apr 11 14:34:31 <av500> .........
Apr 11 14:34:39 <tbr> please keep in mind that we don't have crystal balls and we are not clairvoyant. So you have to tell and or show us your problems.
Apr 11 14:34:51 * tbr bounces av500 
Apr 11 14:41:28 <jose__> Hi, I trying to connect to the BBB serial port using a FT232RL FTDI USB to TTL, but I just get garbage output
Apr 11 14:41:31 <jose__> any ideas?
Apr 11 14:41:50 <alexhiam> jose__: baud rate?
Apr 11 14:41:50 <jose__> my adapter is this http://www.amazon.com/Pixnor-FT232RL-Serial-Adapter-Arduino/dp/B0146HBT7U
Apr 11 14:42:04 <alexhiam> should be 115200
Apr 11 14:42:07 <alexhiam> I think
Apr 11 14:42:08 <jose__> 115200 yes
Apr 11 14:42:28 <jose__>  sudo screen /dev/ttyUSB0 115200
Apr 11 14:43:19 <alexhiam> doesn't screen have funky defaults? make sure it's 8N1 with no flow control
Apr 11 14:43:52 <alexhiam> 8N1 == 8 data bits, no parity, 1 stop bit
Apr 11 14:44:26 <jose__> ok, I will try that
Apr 11 14:44:50 <jose__> should this serial port work without OS? I trying to debug some failure to load a yocto image
Apr 11 14:45:10 <alexhiam> depends on the bootloader
Apr 11 14:45:41 <alexhiam> the u-boot in the default debian images uses it
Apr 11 14:47:11 <alexhiam> nerdboy may be able to help with yocto problems
Apr 11 14:47:31 <tbr> Xabaras76: stay here on channel, no need to try to take this private.
Apr 11 14:47:58 <Xabaras76> ok thanks...
Apr 11 14:48:00 <tbr> Xabaras76: HERE, not private messages!
Apr 11 14:48:45 <Xabaras76> on win7 pc I format sdcard with sd formatter
Apr 11 14:49:34 <Xabaras76> then on win7 I use win32diskimager to copy the debian image on sdcard
Apr 11 14:50:15 <Xabaras76> I use this image : bone-debian-8.2-lxqt-4gb-armhf-2016-01-10-4gb.img
Apr 11 14:50:40 <Xabaras76> then I put sd card in to bbb
Apr 11 14:51:15 <Xabaras76> as soon I get in to desktop I use script grow_partition.sh
Apr 11 14:51:30 <mausy> hi
Apr 11 14:52:19 <Xabaras76> reboot
Apr 11 14:52:21 <mausy> using beagleboard black with wheezy. I've found GNUplot v4.6.0 is installed. Is there a way to upgrade to v4.6.6?
Apr 11 14:52:59 <dsockwell> try using wheezy-backports
Apr 11 14:53:04 <Xabaras76> and then follow the steps here : http://elinux.org/BeagleBoardUbuntu#SGX_BeagleBone.2FBeagleBone_Black
Apr 11 14:53:05 <dsockwell> or upgrading to jessie
Apr 11 14:55:44 <mausy> there's no hardware support on jessie last time I tried :-(
Apr 11 14:55:53 <mausy> I'll try the "backport"
Apr 11 14:56:03 <vagrantc> no hardware support? what?
Apr 11 14:56:08 <alexhiam> mausy: or build from source
Apr 11 14:56:10 <Xabaras76> the script sgx_create_package.sh install everything with no errors....
Apr 11 14:56:28 <Xabaras76> but when I reboot....sgx drivers aren't loaded....
Apr 11 14:56:41 <vagrantc> beaglebone black works fine with jessie
Apr 11 14:57:26 <Xabaras76> I have tryied also 3.14 kernel......with same method described before...but no luck....
Apr 11 14:57:58 <Xabaras76> I tryied also start from this image : bone-debian-7.9-lxde-4gb-armhf-2015-11-03-4gb.img
Apr 11 14:58:29 <Xabaras76> and update the kernel to 4.1 with apt-get....but same story.....
Apr 11 15:00:06 <tbr> Xabaras76: so how do you do the first part of that instruction? if you have windows
Apr 11 15:00:10 <Xabaras76> If you want to laugh a lot......I installed the sgx before....but after I messed up my image ..I'm trying to build my system again...
Apr 11 15:00:38 <Xabaras76> I run a ubuntu from an usb hdd....
Apr 11 15:01:18 <Xabaras76> in ubuntu I run the first part of the instructions on my laptop.....
Apr 11 15:01:53 <Xabaras76> then I disconnect the usb hdd...and connect it to my BBB.....and the copy the deploy folder...
Apr 11 15:04:04 <Xabaras76> I tryied to do the install from debian user.....and also as root user......no difference...
Apr 11 15:04:18 <tbr> is there any output? error messages?
Apr 11 15:04:42 <Xabaras76> no.....no errors......
Apr 11 15:04:57 <tbr> you really should replace your broken keyboard
Apr 11 15:05:20 <Xabaras76> why change keyboard..??
Apr 11 15:05:40 <tbr> because.........it...........produces..........................millions.......................of.......................dots............................
Apr 11 15:05:51 <Xabaras76> :):)
Apr 11 15:06:08 <Xabaras76> sorry...I'm writing them
Apr 11 15:06:12 <Xabaras76> :):):)
Apr 11 15:06:14 <tbr> then don't
Apr 11 15:06:16 <Xabaras76> I stop now
Apr 11 15:06:20 <Xabaras76> sorry
Apr 11 15:06:32 <tbr> anyway. look for error messages.
Apr 11 15:06:38 <tbr> check if the module gets loaded
Apr 11 15:06:44 <tbr> check if you can load it manually
Apr 11 15:06:45 <tbr> etc
Apr 11 15:07:50 <nerdboy> the best yocto build at this point is meta-ti bsp instead of yocto-bsp
Apr 11 15:08:28 <Xabaras76> I check if the omapfb and pvrsrvkm with lsmod command but no luck. They are not loaded
Apr 11 15:08:46 <nerdboy> https://github.com/VCTLabs/vct-beagleboard-bsp-platform  <=  try poky-jethro branch and use meta-ti bsb
Apr 11 15:09:45 <tbr> Xabaras76: and if you try to modprobe them?
Apr 11 15:09:55 <alexhiam> cc jose__ ^
Apr 11 15:11:24 <Xabaras76> but i notice something strange
Apr 11 15:12:26 <Xabaras76> when I copy the deploy folder to my BBB and decompress the file GFX_5.01.01.02.tar.gz
Apr 11 15:12:53 <Xabaras76> it will generate 2 folders. One etc and one opt folder
Apr 11 15:13:12 <jose__> nerdboy: I was trying to build jethro core-image-minimal, but was not able to get it to boot, following the steps in https://www.yoctoproject.org/downloads/bsps/jethro20/beaglebone
Apr 11 15:13:16 <nerdboy> that should also be a deb package in rcn debian repos
Apr 11 15:14:05 <nerdboy> are you manually copying the MLO/u-boot files to /boot?
Apr 11 15:14:17 <jose__> yes
Apr 11 15:14:20 <Xabaras76> if I run the script from this new opt folder it said depmod <my image > and then stops
Apr 11 15:14:27 <nerdboy> *the sgx drivers are packaged against each kernel version
Apr 11 15:14:56 <nerdboy> jose__: did you copy MLO as the first file?
Apr 11 15:15:42 <nerdboy> ti u-boot-2015.7 should work the same as rcn u-boot
Apr 11 15:15:51 <jose__> Yes , as noted there in 2. Install the boot loaders
Apr 11 15:15:56 <Xabaras76> but if I copy all files and folders to my system opt folder and run the scripts from system opt folder I get something like this :
Apr 11 15:16:02 <Xabaras76> `/opt/gfxlibraries/gfx_rel_es8.x/libGLES_CM.so' -> `/usr/lib/libGLES_CM.so' `/opt/gfxlibraries/gfx_rel_es8.x/libusc.so' -> `/usr/lib/libusc.so' `/opt/gfxlibraries/gfx_rel_es8.x/libGLESv2.so' -> `/usr/lib/libGLESv2.so' `/opt/gfxlibraries/gfx_rel_es8.x/libGLESv2.so' -> `/usr/lib/arm-linux-gnueabihf/libGLESv2.so' `/opt/gfxlibraries/gfx_rel_es8.x/libglslcompiler.so' -> `/usr/lib/libglslcompiler.so' `/opt/gfxlibraries/gfx_rel_es8.x/lib
Apr 11 15:16:15 <alexhiam> Xabaras76: pastebin
Apr 11 15:18:50 <nerdboy> http://www.gentoogeek.org/files/arm-bb_yocto/  <=  maybe this helps?
Apr 11 15:19:11 <nerdboy> check make.txt compared to what you did
Apr 11 15:22:17 <jose__> nerdboy: no  uEnv.txt  in my build
Apr 11 15:24:41 <Xabaras76> http://pastebin.com/40HFvyS0
Apr 11 15:24:54 <Xabaras76> this is what I got
Apr 11 15:31:05 <nerdboy> no card image either
Apr 11 15:31:16 <nerdboy> you have to make your own
Apr 11 15:31:50 <nerdboy> because u-boot is also on emmc
Apr 11 15:33:49 <nerdboy> might also help to flash latest debian/machinekit on emmc
Apr 11 15:39:19 <Xabaras76> well now I will to install SGX drivers with no monitor connected and see if I can find any differences
Apr 11 15:39:44 <nerdboy> use the package, might be easier...
Apr 11 15:58:16 <jose__> Trying to boot from Yocoto http://pastebin.com/yixnhQZK
Apr 11 15:59:33 <jose__> I trying to boot from SDCARD now, and erase mcc and as pointed in yocto install notes
Apr 11 17:08:41 <jkt> I take it that there's no repo with amd64 packages of the patched device-tree-compiler, is it?
Apr 11 17:09:05 <jkt> (http://repos.rcn-ee.com/debian/dists/jessie/main/ doesn't have an amd64 version for sure)
Apr 11 17:12:38 <Spidler> alexhiam: Okay. Several hours later, I now have a 4.6-rc3 kernel that seems to work using the manual GPIO method.  Thanks for the help there!
Apr 11 17:13:44 <Spidler> alexhiam: I still can't seem to get automatic DE (RTSCTS) to work, but that will have to be a question for tomorrow
Apr 11 17:13:50 <Spidler> I'm off folks, have a good evening!
Apr 11 17:14:02 <alexhiam> great
Apr 11 17:14:37 <Spidler> alexhiam: tracking down the correct device trees is also fun :)
Apr 11 17:17:55 <alexhiam> it always is
Apr 11 17:19:00 <alexhiam> Spidler: you definitely do want to get the driver toggle RE/DE, otherwise you'll run into timing issues because the UART module does its RX/TX async
Apr 11 17:19:06 <Spidler> Right now, trying to decode the difference between the one you linked, that does magic on "0x1a4 0x07" (mode7 on GPIO3_19 I guess) and  this one: https://github.com/lgxlogic/CBB-Serial/blob/master/overlay/BB-UART4-RTSCTS-00A0.dts
Apr 11 17:19:45 <Spidler> alexhiam: Yeah. I might poke you again, but at least I know it's electrically okay right now.
Apr 11 17:20:16 <Spidler> So now I have to learn how Device tree actually works.
Apr 11 17:20:37 <alexhiam> well, or just use ioctl
Apr 11 17:20:45 <alexhiam> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
Apr 11 17:20:50 <Spidler> Yeah, found that one
Apr 11 17:21:07 <Spidler> But I'm not fond of digging through all the various places in codebase to rip out and change to custom ioctl
Apr 11 17:21:32 <alexhiam> fair enough
Apr 11 17:21:55 <Spidler> And I'd hate code going "Test if the current driver is. then do magic"  even more.
Apr 11 17:24:37 <Spidler> Anyhow, this is all for tonight, thanks, have a great evening/day/timezone :)
Apr 11 17:25:12 <alexhiam> ok, feel free to ping me about it later
Apr 11 17:26:43 <zmatt> or ditch the kernel driver, mmap the uart :P
Apr 11 17:29:50 <alexhiam> forget mmap, just bit-bang it from userspace
Apr 11 19:10:06 <zmatt> why would you do that?
Apr 11 19:12:05 <zmatt> also GODDAMNIT... see this is why I always use heatshrink-tubing-protected female ends on wires whenever possible, and insert a header to couple when needed.... some board here had two wires with male ends soldered on, I moved something and one of them landed perfectly onto the pcb of a bbb
Apr 11 19:12:13 <zmatt> which turned out to be a +7V supply wire
Apr 11 19:12:29 <zmatt> #@U^$%#@&
Apr 11 19:36:09 <jose__> http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot, is the special format explained here required to boot from sdcard?
Apr 11 19:36:25 <zmatt> are you using an omap3 ?
Apr 11 19:37:56 <jose__> BeagleBoneBlack board
Apr 11 19:38:19 <zmatt> then no
Apr 11 20:21:10 <jose__> So when I format my SD with fdisk, firt partion starts at 2048 and the image fails to boot, if use -c=dos to format the SD the first partition starts at 63 and it boots, does that make sense?
Apr 11 20:21:41 <jose__> the OS is yocto, the core-image-minimal
Apr 11 21:01:58 <zmatt> weird.  I normally never use a FAT boot partition, but the few times that I tested that method I never used any old/compat/nonstandard layout
Apr 11 21:03:09 <zmatt> see for example https://github.com/mvduin/bbb-asm-demo where I show minimal steps for getting the BBB to load an MLO, both using raw mmc boot and using a FAT partition (both methods tested)
Apr 11 21:04:51 <zmatt> when booting linux the MLO would be u-boot's SPL obviously (beware that last time I checked u-boot produces a file named "MLO" that's actually _not_ an MLO but rather a raw eMMC header, padded to 512 bytes, concatenated with the actual MLO)
Apr 11 21:07:13 <zmatt> I have no experience with yocto, but I don't see any reason why the particular distro would matter
Apr 11 21:17:17 <zmatt> train to catch, bbl
Apr 11 21:19:17 <epipe> having trouble sharing internet connection to BB
Apr 11 21:19:22 <epipe> trough usb
Apr 11 21:19:31 <epipe> from win pc
Apr 11 23:00:09 <zmatt> epipe: no ethernet available?
Apr 11 23:00:45 <epipe> wifi
Apr 11 23:00:52 <zmatt> sharing internet to the bbb via usb is possible, but it will require reconfiguring networking on the bbb
Apr 11 23:00:53 <epipe> oh nvm
Apr 11 23:01:00 <epipe> finally got it working
Apr 11 23:01:45 <epipe> I had to make my ethernetcard available even tough I dont use it
Apr 11 23:01:53 <zmatt> ..
Apr 11 23:01:56 <zmatt> that sounds odd
Apr 11 23:01:59 <epipe> otherwise I could not choose bb on share
Apr 11 23:02:02 <epipe> yea
Apr 11 23:02:43 <zmatt> merely sharing your connection with the bbb will however probably not make it automagically *work* on the bbb
Apr 11 23:02:46 <epipe> I had no options to choose from on share. When I turn ethernet card on, I get both ethernet and bb to choose from
Apr 11 23:03:29 <zmatt> so, previously it probably just assumed the bbb since there was no other choice?
Apr 11 23:03:50 <epipe> maybe, but it did not work
Apr 11 23:04:38 <epipe> but after I switched on ethernetcard. I can choose, and as some other links said, the bb ip address somehow gets to be 192.168.137.1
Apr 11 23:04:55 <epipe> and I change that to dhcp, and it works
Apr 11 23:05:33 <epipe> yea, windows works in mysterious ways :D
Apr 11 23:05:52 <epipe> its crap
Apr 11 23:06:57 <zmatt> noone is forcing you to use it ;)
Apr 11 23:07:30 <zmatt> or well, I suppose I can't exclude the possibility someone is
Apr 11 23:07:32 <epipe> unfortunatly
Apr 11 23:07:57 <epipe> but not in this matter tou :D
Apr 11 23:08:37 <epipe> but lets say I need to program a PLC at work. Often the plc's only supports windows
Apr 11 23:08:54 <epipe> same for alot of ship equipment
Apr 11 23:09:14 <epipe> hate it. windows is like a virus
Apr 11 23:09:23 <epipe> cant get rid of it
Apr 11 23:11:24 <epipe> also I wanted to delete windows of my home computer, but I am waiting for ubuntu-mate 16.04
Apr 11 23:11:35 <epipe> any time no I suppose :D
Apr 11 23:13:24 <zmatt> well, we're currently using some dsp for which there's only a crappy IDE for Windows and no public docs on the instruction set
Apr 11 23:13:53 <zmatt> I've now figured out most of the instruction set and am close to being able to generate my own code :D
Apr 11 23:15:16 <zmatt> (never get between me and something I want to understand :P )
Apr 11 23:16:36 <epipe> Yea I would like to have time to do that for any system. But instead I get my company to buy me a windows laptop for work. I wont pay for that shit
Apr 11 23:17:55 <epipe> When I was in school, I looked forward to get rid of it. I wasnt really forced to use it in school, but often when working in groups, people only use MS office
Apr 11 23:18:25 <epipe> Turns out it got alot worse when coming out to the professional world
Apr 11 23:23:33 <epipe> just got a 20x4 lcd and one 16x2 lcd to play with
Apr 11 23:23:51 <epipe> with I2C modules
Apr 12 02:53:37 <snowstaff> Guys, hi. It's important: why i can write only 255 cells local memory for PRU? Because of their size 8 KB, but available only 256 bytes for write. But i can write to memory from ARM.
**** ENDING LOGGING AT Tue Apr 12 02:59:58 2016