**** BEGIN LOGGING AT Wed Feb 11 02:59:58 2015 Feb 11 08:05:54 hi Feb 11 08:05:59 good morning Feb 11 08:06:21 i have enable the beagle bone black uarts Feb 11 08:07:02 serinfo:1.0 driver revision: Feb 11 08:07:03 0: uart:OMAP UART0 mmio:0x44E09000 irq:88 tx:355 rx:0 RTS|CTS|DTR|DSR Feb 11 08:07:05 1: uart:OMAP UART1 mmio:0x48022000 irq:89 tx:0 rx:0 CTS|DSR|CD|RI Feb 11 08:07:06 2: uart:OMAP UART2 mmio:0x48024000 irq:90 tx:0 rx:0 CTS|DSR Feb 11 08:07:08 4: uart:OMAP UART4 mmio:0x481A8000 irq:61 tx:0 rx:0 CTS|DSR Feb 11 08:07:09 5: uart:OMAP UART5 mmio:0x481AA000 irq:62 tx:392 rx:1 brk:1 RTS|CTS|DTR|DSR Feb 11 08:07:11 root@beaglebone:~# ls -la /dev/ttyø* Feb 11 08:07:12 ls: cannot access /dev/ttyø*: No such file or directory Feb 11 08:07:14 root@beaglebone:~# ls -la /dev/ttyO* Feb 11 08:07:15 crw-rw---- 1 root tty 249, 0 Jan 6 2015 /dev/ttyO0 Feb 11 08:07:17 crw-rw---T 1 root dialout 249, 1 Jan 1 2000 /dev/ttyO1 Feb 11 08:07:18 crw-rw---T 1 root dialout 249, 2 Jan 1 2000 /dev/ttyO2 Feb 11 08:07:20 crw-rw---T 1 root dialout 249, 4 Jan 1 2000 /dev/ttyO4 Feb 11 08:07:21 crw-rw---T 1 root dialout 249, 5 Mar 24 15:06 /dev/ttyO5 Feb 11 08:07:44 I unable to read on uart 5 with python script Feb 11 08:08:16 here is my write script Feb 11 08:08:20 import serial Feb 11 08:08:21 from time import sleep Feb 11 08:08:22 port = "/dev/ttyO5" Feb 11 08:08:24 while True: Feb 11 08:08:25 ser = serial.Serial(port, 38400) Feb 11 08:08:27 x = ser.write('hello') Feb 11 08:08:28 print 'Write Hello to port : ', port Feb 11 08:08:30 sleep(0.5) Feb 11 08:08:32 ser.close() Feb 11 08:08:32 oi Feb 11 08:08:33 and read script Feb 11 08:08:37 paste that somewhere else Feb 11 08:10:09 dmelani: any help? Feb 11 08:14:30 mumair: step 1, learn about pastebin Feb 11 08:15:50 mumair: step2 verify each of the ports by doing a loopback test Feb 11 08:18:32 tbr: i am doing step, loopback Feb 11 08:18:37 it not working Feb 11 08:18:59 mumair: how are you doing the loopback test? Feb 11 08:23:36 tbr: I am loopback test on UART5: by connecting Tx: P8_37 to Rx: P8_38 and test with python script Feb 11 08:24:28 mumair: just use a terminal emulator like minicom or picocom or even just "screen /dev/ttyO5 115200" Feb 11 08:31:02 tbr: i didn't see any data on screen Feb 11 08:33:45 mumair: did you test all the serial ports that you muxed? Feb 11 08:34:25 yes i tried with uart4 and uart5 Feb 11 08:34:49 let me try uart2 Feb 11 12:05:22 which is the best toolchains for cross-compilation for beagle on windows using c++ Feb 11 12:06:01 gcc? Feb 11 12:10:39 wouldnt linaro be good? Feb 11 12:13:46 they make everything 2x faster, so yes Feb 11 12:14:12 reds: seriously, consider getting a linux PC or a VM for BBB development work Feb 11 12:15:20 whee, 3.19 kernel with working USB *and* working PRUSS stuff :)) Feb 11 12:15:50 i hav never worked before on a linux enviroment Feb 11 12:16:52 (after merging the patches from http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/thread.html#267588 ) Feb 11 12:22:12 reds: well, since the BBB runs a Linux, you better start getting used to it Feb 11 12:22:22 nomis: nice! Feb 11 12:24:37 it's not like you have to use linux on it Feb 11 12:47:25 nomis where did you get it from? Feb 11 13:01:16 woglinde: what do you mean? The kernel from kernel.org, the patches from the ML... Feb 11 13:30:52 I am doing some image processing on a BeagleBone and was wondering if there is any way to increase the speed of my program using the NEON acceleration that comes with the Beagle? Feb 11 13:36:24 nomis which mailinglist? Feb 11 13:37:23 Sc0tty-: sure Feb 11 13:38:01 Sc0tty-: it means you need to rewrite your algorithms to use NEON assembly Feb 11 13:40:12 av500: do you know of any resources I can look up on how to do this? Feb 11 13:40:51 google? Feb 11 13:41:10 I deserved that haha Feb 11 13:41:15 https://www.google.com/search?q=using+arm+neon Feb 11 13:41:48 multimedia stuff like e.g. libav is full of neon Feb 11 13:41:55 or libjpeg Feb 11 13:41:59 etc Feb 11 13:42:45 https://www.google.com/search?q=opencv+neon Feb 11 13:42:47 etc Feb 11 13:43:49 okay thanks, I am using opencv and am trying to optimize my code Feb 11 14:00:15 hi Feb 11 14:01:07 i see no usb0 on the 2015-01-06 jessie image, loading g_multi or g_ether says No such device. any pointer? Feb 11 14:02:16 kernel is 3.8.13-bone70 Feb 11 14:06:54 hii..i want to know that is there any way i can access arm processor without debian ??..like for arduino which has a avr gcc compiler whcih generates a .hex file..i mean accessing hardware directly.. Feb 11 14:07:32 yes Feb 11 14:09:30 can u tell me something abt this plss ?? can we directly use arm compiler also ?? Feb 11 14:12:28 geekswine: build a binary and run it from u-boot Feb 11 14:17:48 samael: is it maybe a built-in? Feb 11 14:22:56 tbr: i have a wheezy image which uses g_multi as module (3.8.13-bone63), and works. on jessie i don't have it and can't get it to work. just tried downgrading to 3.8.13-bone63, no luck still Feb 11 14:23:44 no idea, ask rcn if it's his Feb 11 14:24:52 will do, thanks Feb 11 14:26:09 georgem: thanx.. Feb 11 14:36:29 woglinde: see the link I pasted: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/thread.html#267588 Feb 11 14:55:28 BeagleBot: help Feb 11 14:55:35 bborg_builds: help Feb 11 14:55:35 Get help on what? (try 'help ', 'help , or 'commands' for a command list) Feb 11 14:55:52 bborg_builds: commands Feb 11 14:55:52 buildbot commands: commands, dance, destroy, force, hello, help, last, list, mute, notify, shutdown, source, status, stop, unmute, version, watch Feb 11 14:56:01 bborg_builds: status Feb 11 14:56:01 build-buildroot: building('make') Feb 11 14:56:01 build-image: idle, last build 40m52s ago: exception git Feb 11 14:56:01 build-kernel: idle, last build 10h57m15s ago: build successful Feb 11 15:07:56 <[nwbi]HSSTUDENT> hi i have absolutly no idea what i am doing when it comes to programing and i was wondering if someone could direct me to a tutorial on how to program the bpio with buttons as a basic imput device. EX: up,down,left,right,enter. Feb 11 15:10:00 [nwbi]HSSTUDENT: in which langage? c? python? Feb 11 15:10:20 <[nwbi]HSSTUDENT> it doesnt matter i need it to work directly in linux Feb 11 15:10:37 <[nwbi]HSSTUDENT> just like a keyboard because there will be no keyboard connected Feb 11 15:10:45 http://www.linux.com/learn/tutorials/765810-beaglebone-black-how-to-get-interrupts-through-linux-gpio Feb 11 15:12:11 <[nwbi]HSSTUDENT> Thank you i will be back if i have anymore questions Feb 11 15:15:17 nomis hm okay, are they now applied upstream? Feb 11 15:17:13 woglinde: they are not yet applied in vanilla 3.19 (and they don't apply cleanly so they'd probably need some work). Feb 11 15:17:36 woglinde: not sure what the "reference" kernel for the beagleboneblack is and if these patches are applied there. Feb 11 15:18:04 woglinde: there was some discussion on these patches on the ml but as far as I see there never was a second iteration. Feb 11 15:19:21 and while I gladly would create a new version of this patchset (if someone tells me where to send it to) I'll probably won't push for upstreaming, since this tends to be a lot amount of work... Feb 11 15:20:53 nomis: http://github.com/beagleboard/linux has what I think gets referred to as the reference kernel Feb 11 15:25:00 jkridner: ah, thanks. But of course 3.14 is a kernel version more suitable for the Raspberry Pi. Feb 11 15:25:04 Badum *tss* Feb 11 15:25:26 well, you know where to find mainline. :-) Feb 11 15:25:51 i am new beagle bone black . i will tell basic idea of my project. i will connect 2 switches to beagle bone black. i want to control a game in laptop with these switches. could any one please help me over this issue Feb 11 15:26:12 harsha: the beagle bone black is way too overpowered. Feb 11 15:26:31 harsha: better look at an arduino leonardo and look for some input device emulation. Feb 11 15:26:55 nomis: harsha can get started that way and grow. doesn't hurt to learn Linux GPIO. Feb 11 15:27:08 true. Feb 11 15:27:22 better not fear a steep learning curve though :) Feb 11 15:27:58 please guys i need to do it only using beagle bone black Feb 11 15:28:34 harsha: what connection do you plan between the BBB and the laptop? Ethernet? USB? Serial? Feb 11 15:28:47 usb Feb 11 15:29:08 harsha: and do you plan to run linux on the BBB? Feb 11 15:29:13 over USB, there is a network interface configured by default. this is the easiest way to get going. Feb 11 15:29:36 nomis: do you really think he's going to run anything other than the image that ships with the board? Feb 11 15:29:36 is there a gadget driver for HID? Feb 11 15:29:53 nomis: yes, but it is confusing for someone new. Feb 11 15:29:55 nomis: there is debian inux in ti Feb 11 15:30:12 debian linux in it Feb 11 15:30:38 nomis: the network interface that is already preconfigured is more flexible. sure, HID is the embedded way to do it, but you have to understand more specifics. Feb 11 15:32:51 yeah, but this also means custom software on the laptop, implementing a network protocol for translating it into game controls in some fashion. Feb 11 15:33:32 harsha: anyway, have fun. Feb 11 15:34:00 nomis: i am using linux terminalwith help of putty and running small programs like blinking. Feb 11 15:37:24 harsha: sorry, I can't really help you much there. It sounds like it'd be a lot of work. You first need to sketch out what way of communication you need: What do you want to handle as input on the laptop side and can you provide that from the BBB? Feb 11 15:40:59 as jkridner said, a network connection is probably fairly easy. Provided you can handle that in your game on the laptop. Feb 11 15:46:37 nomis: i don't understand what is this network connection Feb 11 15:47:57 harsha: I understood you have a game running on your laptop and want to connect some buttons to a beaglebone to control the game on the laptop Feb 11 15:48:38 harsha: so you need to establish some sort of communication between the beaglebone and the laptop so that there is a chance of informing the game "hey, there has been a button press of button 1" Feb 11 15:49:13 harsha: and the first thing you need to figure out is: how will this communication work? Feb 11 15:49:35 because this has an impact on the follow-up things. Feb 11 15:51:59 nomis:s, on searching i came to know we should use emulations for these tasks Feb 11 15:52:18 harsha: what kind of device do you want to emulate? Feb 11 15:53:37 nomis: i don't know whether this is correct or not Feb 11 15:55:10 nomis Feb 11 15:55:58 harsha: do you know what "emulation" means? Feb 11 15:56:01 nomis: i think to emulate beagle bone black and we are thinking to use python language in beagle bone black Feb 11 15:57:23 harsha: if you would emulate *a* beagle bone black you wouldn't need one. If you want to emulate something *on a* beaglebone black you need to get an idea what that "something" is. Feb 11 15:58:29 for example: you could use a beagle bone black to emulate a joystick device. Feb 11 16:01:59 nomis: i think emulation means as for example i have a game with 2 controls up and down arrows. i have 2 push buttons to bbb. when i press one push button it takes the control of up arrow and similarly with other . is this the emulation Feb 11 16:02:59 that is a type of emulation, on a small scale, yes Feb 11 16:04:50 hello Feb 11 16:05:03 a lot of time people come in talking about emulating the entire platform in software Feb 11 16:05:52 nomis why do you fear to bring it mainline? lack of time? Feb 11 16:08:35 woglinde: I have some experience with mainlining a new touchscreen driver. It was a long and intense process. Not sure I can commit to do that again. Especially since I didn't write the pru-driver and am not sure that I can competently handle change requests. Feb 11 16:09:08 harsha: how do you want to connect the beaglebone to the laptop? Feb 11 16:10:11 usb Feb 11 16:10:37 i mean by putty we are getting into its terminal Feb 11 16:13:09 harsha: you really need to do the development process yourself. Right now it feels to me that you're answering my questions without thinking about your problem. Feb 11 16:13:38 harsha: I am somewhat trying to shape your thought process with my questions, but it doesn't work. Feb 11 16:14:11 harsha: I suspect this is an assignment from university or something. Maybe you need to contact your advisor. Feb 11 16:19:19 harsha: if you're using putty you're entering an ip address to connect to the beagle bone. You're using a network connection that is encapsulated over USB. Feb 11 16:21:12 harsha: you need to figure out if your game is capable - or can be made capable - to accept control input from a network connection. If that is possible then you can use the network-over-usb connection to write a program for the BBB to control your game. Feb 11 16:22:10 and *then* you can extend the program for the BBB to listen to the buttons you connect to some GPIOs Feb 11 16:24:27 However, I'd still recommend using an arduino. Feb 11 16:32:17 how should i generate binary file so that i can run it from u-boot ?? for atmega we gave makefile which generates a .hex file which is then dumped...is the same possible with this ?? Feb 11 16:54:55 Hey - is there a way for me to monitor flashing of an image? I'm trying to flash a FreedomBox image, but I'm not sure it's actually beginning to flash - from what I understand the four status lights should light up simultaneously for a short period of time, but that never happens. Feb 11 16:55:11 HDMI, serial, anything - just some confirmation that it's actually flashing :) Feb 11 16:55:30 ryukafalz: that will depend on how the flashing image is done Feb 11 16:55:44 oh hi tbr Feb 11 16:55:49 OHAI! Feb 11 16:55:52 :P Feb 11 16:56:04 so that's specific to the image? Feb 11 16:56:05 ryukafalz: basically ask the party that provides the flasher image, only they know Feb 11 16:56:09 gotcha Feb 11 16:56:25 the thing just boots linux and then does stuff™ Feb 11 16:57:04 or if someone went super fancy it might run something bare metal ;) Feb 11 16:57:13 Since you're here, do you know if there are Mer images for the BBB? I only found old BeagleBoard images when I looked a while back Feb 11 16:58:08 I wanted to do a hw adaptation once Feb 11 16:58:15 but then remembered it needs SGX Feb 11 16:58:23 so I was like "urgh, meh, no" Feb 11 16:58:49 if you don't need 3D gfx, then it should be trivial Feb 11 16:59:15 heh, hmm Feb 11 16:59:16 just take any minimal ARMv7 mer image and pair it with kernel+modules, done Feb 11 17:17:16 woot mer is still used? Feb 11 17:18:07 woglinde: the new mer that is a continuation of MeeGo Feb 11 17:18:22 woglinde: the deb/ubuntu abomination is dead and burried Feb 11 17:20:06 tbr yes I know what mer is, but I wondered after tizen that still someone is working on it Feb 11 17:20:34 woglinde: mer started before tizen and is a perpendicular approach to things Feb 11 17:20:57 woglinde: tizen is driven by Samsung and maybe intel, rubber stamped by LF in exchange for moniez Feb 11 17:21:05 tbr I know all this Feb 11 17:21:08 Mer is supposed to be community driven Feb 11 17:21:20 so Feb 11 17:21:39 there are shipping products, foremost the Jolla phone uses Mer at its core Feb 11 17:21:48 but as it is with community, with time the activity can become quiet low Feb 11 17:21:53 and thats what I expected Feb 11 17:21:57 for mer Feb 11 17:22:09 hm okay Feb 11 17:22:18 I forgot jolla right Feb 11 17:22:40 the problem is that jolla killed most of the community input when they decreed that there must be a project merge between middleware and core Feb 11 17:22:48 since then everything has stalled Feb 11 17:23:09 so I am not completly wrong Feb 11 17:23:23 community is unhappy, open source minded people in jolla are unhappy, management is by now probably unhappy because they start seeing a pile of technical debt Feb 11 17:23:47 depends™, the community is still there, just desperate, pissed or unhappy Feb 11 17:24:25 what would really help would be another product using mer, but given how they currently present themselves, I don't see anyone remotely sane going near that with a ten foot pole Feb 11 17:55:25 tbr: KDE was heading in that direction w/ Plasma Active and MakePlayLive, but MPL kinda fell apart Feb 11 17:56:10 yes, I know, sad, would have been a good thing for Mer Feb 11 17:56:13 though strictly speaking MPL wasn't officially part of KDE but rather an offshoot from one KDE developer Feb 11 17:56:19 * ryukafalz nods Feb 11 17:56:27 I still wish I could've gotten an Improv :( Feb 11 18:04:58 Quick question that may have an involved answer: I have a number of custom boards that speak I2C. Experienced in embedded C and Lazarus Pascal, somewhat less in Java. Feb 11 18:05:39 I want to talk to these boards from the beaglebone black. (Rev C). I could use either Debian (latest image) which seems to have hardware libraries, Feb 11 18:06:20 But seems to have no support to build a GUI on the BBB itself (GUI composer seems to be only for the PC) Feb 11 18:06:58 GUI? huh? Feb 11 18:06:58 OR I could use Android, which seems to have native support for building a GUI style application, but has uncertain access to hardware (and needs to be programmed in Java). Feb 11 18:07:10 Graphical User Interface Feb 11 18:07:18 Program with pretty buttons and text fields Feb 11 18:07:22 yes, the board runs linux, linux has GUIs galore Feb 11 18:07:33 I fail to understand why you think that's desktop only Feb 11 18:08:13 Mostly because the application stuff seems to indicate that it calls functions on the PC to connect to the program Feb 11 18:08:19 I'm looking for standalone Feb 11 18:08:27 Did I miss something? Feb 11 18:08:41 "application stuff" "calls function on the pc" - what are you talking about? Feb 11 18:09:00 OK, as I understand it, you write an application for the BBB Feb 11 18:09:07 the BBB essentially _is_ a PC btw Feb 11 18:09:45 the PC can communicate with it (Windows used), at the PC end, you can create a screen to display variables in the user program running on the BBB Feb 11 18:10:31 so it looks as if GUI composer is designed to be used on the PC only, talking with your application on the BBB Feb 11 18:10:42 nice, and will be useful, but not what I want now Feb 11 18:11:57 what is this gui composer you are talking about? Feb 11 18:12:20 the one in TI's Code Composer Studio, version 6, sorry about that Feb 11 18:12:26 the board runs linux, a FULL LINUX DISTRIBUTION, with all graphics and shizznizz Feb 11 18:12:45 oh, you are talking TI? nobody, I repeat, NOBODY, around here uses that Feb 11 18:12:51 ok.... Feb 11 18:13:03 is it all javascript and bonescript then? Feb 11 18:13:34 It's whatever you want to run on it - I use Python :P Feb 11 18:13:58 Haven't really used that Feb 11 18:14:07 lots of experience in pascal and C Feb 11 18:14:15 C down to and including device drivers Feb 11 18:14:24 but embedded C for the AVR series Feb 11 18:14:29 (which are the custom boards) Feb 11 18:15:10 Perphaps a bit more of what I'd like to see for convenience Feb 11 18:15:41 Delphi/Lazarus/Visual studio all use a drag and drop approach to GUI design Feb 11 18:16:04 take a button, put it on a form, and then add code for that button's method to control what it does Feb 11 18:16:11 Both Pascal and C should work fine, it's an ARM Linux box :P Feb 11 18:16:32 right, so I may see if Lazarus will compile to this platform.... Feb 11 18:16:54 that would work, because I really don't care (yet) if I use Android or Linux Feb 11 18:19:30 it's program development that I'm concerned with Feb 11 18:19:53 that and access to I2C libraries (a must for this design, otherwise I have to play games) Feb 11 18:21:01 I have custom hardware data collection hardware as well as generic I2C devices Feb 11 18:21:30 Some of those are logic analyzers, I2C analyzers, and oscilloscopes (as plugin cards) Feb 11 18:22:06 I2C is used to talk to them, so whatever programming solution I use, I need to have access to I2C. Feb 11 18:22:42 so how to develop a program that uses forms, buttons, panels, etc? and has I2C access... Feb 11 18:22:53 That's the basic problem, and have it run standlone on the BBB Feb 11 18:23:20 I haven't done it myself, but it looks like you interface with I2C devices though /dev/i2c Feb 11 18:23:58 er, /dev/i2c-0 and so on Feb 11 18:24:04 there should be userspace libraries too (mostly C probably) Feb 11 18:24:10 right, and if that is present on the Linux version (I am fairly certain that it's on Android), then that's a help Feb 11 18:24:20 and if anyone suggests /dev/mem - run, run for your life Feb 11 18:24:26 heheh Feb 11 18:24:38 Linux generally seems to be on processors that don't have I2C Feb 11 18:24:41 https://www.kernel.org/doc/Documentation/i2c/dev-interface Feb 11 18:24:58 Not really, just the devices you happen to have don't have I2C ;) Feb 11 18:25:15 Thanks, I'll look at that Feb 11 18:25:35 heh, all of my processors have I2C, but they don't run Linux, being embedded harvard architecture stuff Feb 11 18:25:45 stored program, not made to run programs from RAM, so not general purpose Feb 11 18:26:44 but the BBB has lots of RAM, runs programs from RAM, has SD card interfaces, a better graphics interface than the one that I built, etc Feb 11 18:26:59 actually most PCs have I²C, disguised as SMBus Feb 11 18:27:08 so using a BBB for a main controller, and allowing it to talk over I2C, is a good thing Feb 11 18:27:31 true, the SMBus runs the display (monitor) enumeration, as I understand it Feb 11 18:27:53 but I am looking for something that runs on the BBB, since there's a considerable size difference Feb 11 18:27:59 oh and VGA had I²C too for EDID Feb 11 18:28:11 exactly Feb 11 18:29:01 however, these resources need to be accessable, and I'd just as soon not have to write a device driver for I2C under linux or android Feb 11 18:29:17 although there's one around somewhere for standalone Feb 11 18:29:40 oh, look: http://elinux.org/Interfacing_with_I2C_Devices Feb 11 18:29:43 so for android, use eclipse-android Feb 11 18:29:50 ah, ok, I'll do that too Feb 11 18:30:29 part of the problem I have is that I don't know where to look yet, and google searches are not all that comprehensive Feb 11 18:30:55 the above was written for the older BeagleBoard's but should largely apply also to the BeagleBone Feb 11 18:31:24 good, that's one thing that had me worried a bit, not the hardware differences so much as the OS differences between the two Feb 11 18:35:31 oh, and a hardware question Feb 11 18:36:01 apparently, the beagleboard has a number of 1.8 volt max busses brought out to the user pins (not thinking ADC here) Feb 11 18:36:26 the BBB specifically says that all pins are 3.3 volt signals (except the ADC inputs) Feb 11 18:36:36 is this correct? Anyone know? Feb 11 18:39:30 guess nobody has built their own capes for the BBB, or this has not been an issue Feb 11 18:45:55 Ok, on board I2C enumeration eeprom runs from 3.3 volts, now to track that down Feb 11 18:48:28 Ok, answer is that IC0_SCL and IC0_SDA have passive pullups to 3.3 volts,not 1.8 volts Feb 11 18:49:01 so the answer on the BBB is most likely that all pins but the ADC are 3.3 volt tolerant, so VCCIO on the processor is 3.3 volts Feb 11 18:49:09 for the expansion stuff, I'd say Feb 11 18:49:55 at least one cape design for LCD's has a level shifter in there, which works with 5.0 volt displays, I'd say. Not all LCD's are 5 volts, some work on 3.3 Feb 11 18:51:28 ok, thanks for the links for the I2C stuff, now to see what I can do with it Feb 11 18:51:36 any last words from anyone? Feb 11 18:52:15 thanks, and bye... Feb 11 18:57:05 * nomis blinks Feb 11 18:57:21 well he seems to be sort of off in the right direction now Feb 11 18:58:20 rubber-duck-debugging^Wproject planning :) Feb 11 18:59:31 Can we convert a c code into bootable file and than run that code on BBB ? Feb 11 19:00:02 probably, why would you though? Feb 11 19:00:23 ZeekHuge: yeah. This is how uboot works. Feb 11 19:00:52 May be because i want my program to use all the processing cycles of the processor.. ... Feb 11 19:01:22 then you get to write your own OS too Feb 11 19:01:27 well Feb 11 19:01:35 you could make your code a kernel module :) Feb 11 19:01:46 Ok !! So i want to do that ... How should i start ?? Learning about the kernels ?? Or something else ? Feb 11 19:01:47 but he wants ALL THE CYCLES! Feb 11 19:01:53 ah, right Feb 11 19:02:00 then you have to make your code a kernel :) Feb 11 19:02:17 ZeekHuge: look at the build process of uboot and replicate it. Feb 11 19:02:24 with your own code of course. Feb 11 19:02:30 * tbr personally doubts that will be efficient, but knock yourself out with uboot Feb 11 19:02:52 yeah, will be hard. Feb 11 19:02:58 read a book about minix ... helped others too to write an OS Feb 11 19:03:30 it will only be as hard as it is pointless :) Feb 11 19:04:01 A complete os ?? Why ?? I want the bbb just to run a single process !! Feb 11 19:04:02 (actually, if you're fine with providing your code under the GPL you could embed it into uboot, which is reasonably easy. Feb 11 19:04:29 Has anyone done SPI programming with the BB-xM? I've tried with two different chips, but neither of them work. flashrom can't detect an AT26DF321 ("No EEPROM/flash device found."), and reading an MX25L6405D results in different output each time. I'm using 10-cm jumper cables without resistors; could the extra 3 or 4 cm between the expansion header and the SoC be an issue? Feb 11 19:04:45 ZeekHuge: so what is your single process going to do? Feb 11 19:05:20 Actually ... It would do some speech recognition and all such stuff . Feb 11 19:05:33 "lol" Feb 11 19:05:37 I want it to be super fast. Feb 11 19:05:37 yeah, then you need to write an OS Feb 11 19:05:45 ?? Feb 11 19:06:03 ZeekHuge: what drivers do you want to use to communicate with a microphone? Feb 11 19:06:07 first of all make your code drive microphone hardware :) Feb 11 19:06:55 * tbr would suggest to liquid cool the CPU, that gets you crazy fast Feb 11 19:07:05 with coke ! Feb 11 19:07:30 (since that looks good if you pipe it through transparent pipes) Feb 11 19:07:32 * tbr was thinking of liquid nitrogen or such Feb 11 19:07:50 Can this be done ? The thing that i wish to ? Feb 11 19:08:02 ZeekHuge: yes. Feb 11 19:08:08 ZeekHuge: but you probably don't really want to. Feb 11 19:08:18 ZeekHuge, yes, but if you would do it like you want to you will really have to write your own mini OS Feb 11 19:08:21 yes - but is it a good idea to do? no Feb 11 19:08:34 ZeekHuge: the major advantage of using linux etc. is that someone else already has done the heavy lifting. Feb 11 19:08:54 ZeekHuge, instead just run your app under linux and spare some cycles for an existing OS Feb 11 19:09:09 ZeekHuge: and rest assured that even bringing up the CPU/RAM etc. is probably more complicated than you expect. Feb 11 19:09:14 yoou can likely optimize that linux to shove off some extra cycles Feb 11 19:10:26 ZeekHuge: if you're worried about the rest of the infrastructure burning useless cycles you can specify your application as the init process. Then you can fully control if other processes (beyond the kernel internal processes) are running or not. Feb 11 19:10:40 right Feb 11 19:10:41 I have done that - mainly to improve boot time - and it works. Feb 11 19:10:55 well, not on the BBB yet. But it should work the same. Feb 11 19:11:05 yeah, it is definitely an option Feb 11 19:11:39 or using a rt hypervisor Feb 11 19:11:53 Actually i wish .... That people could connect various appliances and different devices present at home (and just specify those pins in a file) and the just say a command and that appliance gets switched on !! Feb 11 19:11:55 and really, having the convenience of just using the network and/or flash filesystems is saving a lot of headaches you'd otherwise have. Feb 11 19:12:41 Yes ... The connections would be through a cape ... Feb 11 19:12:45 ZeekHuge plan for the next 5 years to achieve this Feb 11 19:15:12 Is it really that difficult to be achieved ? Feb 11 19:15:37 ZeekHuge: the benefit of not using a OS is typically negligable. Lets say if recognizing speech in a text sample typically takes 0.05s, then ditching the OS will reduce this to 0.0499s. Not worth it. Feb 11 19:15:41 it requires knowledge Feb 11 19:16:28 is there any example or kinda thing with the help of which i can write a led program using u-boot..i.e directly accessing hardware on BBB..main motive is how to make binary file for u-boot.. Feb 11 19:17:10 like which we have for atmega...after writing in C a hex file is generated.. Feb 11 19:17:32 <_av500_> yes, you can do that Feb 11 19:17:44 <_av500_> basically you need to setup a simple linker script Feb 11 19:17:53 <_av500_> and load the binary using uboot to that adress Feb 11 19:18:02 <_av500_> like use the address that uboot loads the kernel to Feb 11 19:18:18 <_av500_> then to access e.g. a GPIO, see the TRM for register addresses Feb 11 19:18:29 <_av500_> but note you might also need to enable clocks Feb 11 19:18:31 <_av500_> and pinmux Feb 11 19:18:39 <_av500_> some of that might already be in uboot Feb 11 19:18:45 hm or he include it in u-boot itself Feb 11 19:18:49 *g* Feb 11 19:18:54 strange ideas today Feb 11 19:18:58 <_av500_> sure Feb 11 19:19:02 <_av500_> for a quick test Feb 11 19:19:18 <_av500_> after all, the linker script for uboot can be a start Feb 11 19:19:44 <_av500_> also http://www.ti.com/tool/starterware-sitara Feb 11 19:19:44 oh my Feb 11 19:19:55 or he boots linux and uses, a shell script Feb 11 19:20:09 <_av500_> sure Feb 11 19:20:13 no C needed at all Feb 11 19:20:17 <_av500_> but where is the fun in that Feb 11 19:20:39 where is the fun doing atmel stuff on beagle? Feb 11 19:21:00 ohk..i have written lcd JHD16 library for atmega16a...is it the same way we do here also ?? Feb 11 19:21:20 and? Feb 11 19:21:24 <_av500_> well, more or less Feb 11 19:21:26 <_av500_> it depends Feb 11 19:21:31 <_av500_> se the starterware link Feb 11 19:21:33 <_av500_> see Feb 11 19:21:39 <_av500_> that seems to have what you need Feb 11 19:21:49 There are some speech recognition libraries for C, is it still that difficult ? Feb 11 19:21:55 <_av500_> or course you can treat the am335x as a microcontroller Feb 11 19:22:00 <_av500_> a very compley one Feb 11 19:22:10 <_av500_> ZeekHuge: sure there are Feb 11 19:22:38 <_av500_> https://www.google.com/search?q=linux+speech+recognition Feb 11 19:23:08 <_av500_> https://www.google.com/search?q=linux+arm+speech+recognition Feb 11 19:24:04 _av500_: okk..i'll go through it..will return back, if further needs ur help..thanx..:) Feb 11 19:24:25 hm yes it has LED-Blink Feb 11 19:24:51 in speech recognition ?? Feb 11 19:25:03 <_av500_> in starterware Feb 11 19:25:57 Making that speech recognizer on BBB, can't it be done in 2- 3 months ? Feb 11 19:26:00 av500 how the stuff is loaded with starterware, is the compiled binary started as MLO? Feb 11 19:26:12 so starterware is like an ide..same as we have for arduino..right ?? Feb 11 19:27:14 <_av500_> why not read about it? Feb 11 19:27:23 <_av500_> ZeekHuge: define "making"? Feb 11 19:27:24 sure..:) Feb 11 19:27:38 <_av500_> to recompile julius, I doubt that takes 2-3 months Feb 11 19:27:48 <_av500_> to write your own, 2-3 years maybe? Feb 11 19:28:16 av500 ah found the wiki pae for flashing Feb 11 19:28:19 page Feb 11 19:28:52 <_ssl> rcn-ee hi, i tired to get hardware accelerated graphics working on my BBB using your instructions on the wiki (http://elinux.org/BeagleBoardDebian#SGX_Drivers) but unfortunatly i can't get them to work. can you please help me? Feb 11 19:30:08 _ssl, btw, it's "framebuffer" only ogles2, so if your trying opengl 2 that's not going to work... Feb 11 19:30:21 otherwise what issues are you seeing? Feb 11 19:30:43 <_av500_> rcn-ee: still no x11? Feb 11 19:31:00 there's egl, but "i" haven't got wayland working.. Feb 11 19:31:14 x11 is long gone in the notes as deleted.. Feb 11 19:31:17 <_av500_> will that be there before rpi3? Feb 11 19:31:24 lol Feb 11 19:32:11 qt eglfs works thou... just haven't thrown the magic switch on debian jessie's qtbase to rebuild (and sneak those lib's i can't distrubute in it) Feb 11 19:32:31 <_ssl> not sure what "framebuffer-only" means really, but shouldn't i be able to see something on my screen? tried with glxgears demo but got shitty framerates and glxinfo reports software rasterizer as renderer Feb 11 19:32:50 that is what framebuffer only means :) Feb 11 19:32:51 glxgears is "open gl" look for "es2_info" Feb 11 19:33:04 (well glx... but...) Feb 11 19:34:33 <_ssl> es2_info: command not found :/ Feb 11 19:34:52 rcn-ee which is the latest kernel sgx drivers are working with? Feb 11 19:34:52 _ssl, "mesa-utils-extra" Feb 11 19:35:03 <_ssl> thx Feb 11 19:35:20 woglinde, ti's 5.01.01.02 works with v3.14-ti with no patches, released two weeks ago (before i left for vacation) Feb 11 19:35:30 it builds fine against v3.19.0 Feb 11 19:35:44 (with a few select config options disabled..) Feb 11 19:36:01 <_ssl> Unable to locate package mesa-utils-extra Feb 11 19:36:13 _ssl, are you on wheezy? Feb 11 19:36:17 rcn-ee builds does not mean its running Feb 11 19:36:28 details Feb 11 19:36:35 <_ssl> Linux arm 3.14.31-ti-r49 #1 SMP PREEMPT Sat Jan 31 08:36:47 UTC 2015 armv7l GNU/Linux Feb 11 19:36:46 <_ssl> using your 2015-01-06 image Feb 11 19:37:11 woglinde, well the old 5.01.01.01 worked, according to the release notes, "they" only added the v3.14.x patches... Feb 11 19:37:30 _ssl, on the image you downloaed, did it say "7.8"? Feb 11 19:37:48 rcn-ee hm I meant 3.19 Feb 11 19:38:19 kernel would be 3.19 .. debian image 7.8 ? Feb 11 19:38:23 that it runs with 3.14 I believe Feb 11 19:38:41 <_ssl> 7.7. i tried 7.8 but that came with 3.8 kernel Feb 11 19:38:43 dates don't really help Feb 11 19:38:53 <_ssl> so i switched back to 7.7 with 3.14 kernel Feb 11 19:39:01 o.O Feb 11 19:39:23 you can use whatever kernel you want Feb 11 19:39:28 _ssl, well 7.7 vs 7.8 is just a date stamp issues, if you "sudo apt-get update; sudo apt-get upgrade" your 7.7 is 7.8... Feb 11 19:39:56 <_ssl> oh cool. ill try that :) Feb 11 19:39:56 but it sounds like your running wheezy = 7.x, in which case that package doesn't exist... Feb 11 19:41:15 do to all the limitations of sgx, very few people actually use it.. qt 5.x is the most useful target... Feb 11 19:41:21 <_ssl> how to confirm im on jessie after upgrade? Feb 11 19:41:55 well, jessie = 8.x and is currently "not" released... Feb 11 19:43:00 it's up to you if you want to update /etc/apt/sources.list and do the full "sudo apt-get update ; sudo apt-get upgrade ; sudo apt-get dist-upgrade" routine.. i'll take some time and lots of microSD space... (lots) Feb 11 19:46:41 probvably easier to redownload from scratch Feb 11 19:46:44 -v Feb 11 19:47:12 <_ssl> ok back to graphics. say im writing a c++ application and using sfml library. any way to get hardware support? Feb 11 19:48:13 <_ssl> .oO(still not sure about difference between openGL and ... es2? glx?) Feb 11 19:48:20 well build it against opengl es2, the lib's included in the sgx package and run your app in full screen.. Feb 11 19:49:32 opengl es2 is a subset of opengl (2)... Feb 11 19:49:49 hm uh never heard of sfml before Feb 11 19:50:05 https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_2.0 Feb 11 19:50:17 is it packaged under debian? Feb 11 19:50:35 hm yes Feb 11 19:51:17 but there is not hint it is compiled agains gles Feb 11 19:51:40 _ssl so you might recompile sfml with gles support Feb 11 19:52:10 <_ssl> um... Feb 11 19:52:56 * ogra_ was pushing for getting all debian packages in armhf recompiled for GLES by default some years ago ... i was shouted down by the debian games team ... since potentially there could be arm boards with PCI slots "soon" then you could have real GL Feb 11 19:53:41 ogra there already ones Feb 11 19:53:48 since two years or so Feb 11 19:53:51 there are a few arm boards with pcie Feb 11 19:54:00 i had one at that time ... marvell dove had 3 PCI slots Feb 11 19:54:01 but thats not really the point Feb 11 19:54:12 that was ~6 years ago Feb 11 19:54:23 you don't want a compact embedded board and then one massive graphics card blobbed onto it Feb 11 19:54:32 and sgx graphics libs stucked back then too. ;) no improvement.. Feb 11 19:54:37 yep Feb 11 19:54:50 ogra_ ... try again ;) Feb 11 19:54:52 lol Feb 11 19:54:56 haha, no Feb 11 19:55:06 i gave up trying to convince debian :) Feb 11 19:55:24 from the sfml cmake file Feb 11 19:55:25 sfml_set_option(SFML_OPENGL_ES ${OPENGL_ES} BOOL "TRUE to use an OpenGL ES implementation, FALSE to use a desktop OpenGL implementation") Feb 11 19:55:27 well .. since they like systemd *chuckle* Feb 11 19:55:43 anyway Feb 11 19:55:51 I like it too Feb 11 19:55:55 luckily with snappy i dotn have to care about debs that much anymore ... as an ubuntu dev Feb 11 19:56:12 fast booting Feb 11 19:56:15 did they fork completely? Feb 11 19:56:25 fork ? Feb 11 19:56:32 thought ubuntu was still dependant on debian to some exten Feb 11 19:56:34 +t Feb 11 19:56:37 it is Feb 11 19:56:41 but snappy isnt Feb 11 19:56:47 ah Feb 11 19:57:15 <_ssl> woglinde so i can build sfml to support the hardware acceleration on my BBB? Feb 11 19:57:27 snap packages can actually bundle anything you want ... no matter what your input is ... (could be debs indeed) Feb 11 19:58:35 <_ssl> still i'm a little lost with stuff. I always tought you need Xorg if you want to build something graphical. now you say the sgx drivers don't support X? i don't get it Feb 11 19:59:22 I think they mean there are no x-written drivers .. Feb 11 19:59:48 ie. use the other drivers IN x .. its only a display server system Feb 11 20:00:01 _ssl, if that was true waylan or Mir wouldnt work ;) Feb 11 20:00:05 ssl in theory yes Feb 11 20:00:16 _ssl, we don't have xorg drivers or the old "x11" overlay... so nope.. Just framebuffer, unless you have a system like wayland which can use EGL... Feb 11 20:00:17 you dont need X to display something Feb 11 20:00:41 ogra is there puppet for snappy? Feb 11 20:00:53 woglinde, nope, not yet Feb 11 20:01:03 ora hm but ssh? Feb 11 20:01:09 so ansible would work Feb 11 20:01:09 sure Feb 11 20:01:24 rcn-ee : would that mean you run X with fb driver, and it works within .. or has to be Outside x ? Feb 11 20:01:37 veremit, "full screen" Feb 11 20:01:52 <_ssl> orga_ say i have a binary like glxgears which does show something on screen. when running it without Xorg running, it complains about "cant open display". Feb 11 20:01:58 think dos days.. with 3d acceleration... Feb 11 20:02:14 outside X ? without window manager, yes .. Feb 11 20:02:20 "glx"gears needs a glx display (xorg) Feb 11 20:02:28 _ssl, because it was built against Xorg ... Feb 11 20:02:34 yeah, what robert said Feb 11 20:02:37 <_ssl> oh i see Feb 11 20:02:49 there's an "egl"gears for wayland/mir Feb 11 20:02:54 hm I would say _ssl reads about gl and egl and comes back after that Feb 11 20:03:05 ++ Feb 11 20:03:22 <_ssl> so i should be able to run the sgx demos, which don't exist in my installation? Feb 11 20:03:32 woglinde .. everyone comes in here looking for the shortcut to research+reading :P Feb 11 20:03:54 veremit uhm I am here so long Feb 11 20:03:59 I know all kinds of tricks Feb 11 20:04:09 <_ssl> veremit trust me, i've read ALOT in the past days, and also learned a lot. not enough though Feb 11 20:04:10 .. or to talk to the 'experts' :p Feb 11 20:04:15 _ssl, kinda good overview: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/ (it's old) Feb 11 20:04:28 <_ssl> rcn-ee thank you Feb 11 20:05:24 _ssl, so for the bbb, we have kms and egl2... No xorg drivers or gl2... when you read that page.. Feb 11 20:06:24 <_ssl> ok thanks, will come back after reading this if i still have questions, but i looks like a great overview, including all the fancy names im used to but don't know what they do :) Feb 11 20:08:24 haha Feb 11 20:08:38 there are much more fancy names Feb 11 20:09:45 dri,drm, galium, glamor Feb 11 20:18:40 rcn-ee : got some issues with the rtl8192cu driver .. anything you're familiar with? Feb 11 20:20:08 veremit, disable hdmi, or put a usb extension cable on it... usually it's just too close to the gnd plane of the hdmi. Feb 11 20:21:04 its via usb Feb 11 20:21:16 rcn-ee : not on the beagle either :) Feb 11 20:22:12 Sorry, that's all i know about them. ;) I just run atheros when i need wifi... Feb 11 20:23:47 hehe wise choice Feb 11 20:25:56 I've briefly tested a few of those rtl8192's, did a bulk random order on amazon... Opened them up, all the same oem, randomly some kinda worked, while some just failed... Crappy quailty control is the first issue.. Feb 11 20:27:07 no sh1t .. this is an rt8188 .. shows all the signs of the usual rt crap :/ Feb 11 20:36:10 rcn-ee : perhaps I'll have to resort to the RT drivers .. or the sunxi build .. or else :( Feb 11 20:36:47 wireless authentication is working, but dhcp craps out .. but seems to mysteriously work if I do 'ifdown wlan0 && ifup wlan0' Feb 11 20:37:01 could be some strange debian-ish I fear. Feb 11 20:38:13 oh make sure pm in iwconfig is disabled Feb 11 20:38:28 wpa_supplicant :/ Feb 11 20:38:31 ftw Feb 11 20:38:56 is there a pm option in there? Feb 11 20:39:38 * veremit ssh's back into the damn board Feb 11 20:41:32 veremit, you can add it to /etc/network/interfaces: wireless-power off Feb 11 20:41:55 just test with: sudo iwconfig wlan0 power off Feb 11 20:42:15 Error for wireless request "Set Power Management" (8B2C) : Feb 11 20:42:15 SET failed on device wlan0 ; Operation not supported. Feb 11 21:02:00 rcn-ee : would it be possible to cross-compile the realtek driver into the 3.19 sources somehow? Feb 11 21:02:59 well, you can install the headers (sudo apt-get install linux-headers-`uname -r`) , and then try building against them.. Feb 11 21:06:06 hmm true Feb 11 21:07:17 ah hell .. the sodding thing's disappeared off USB lol Feb 11 21:08:12 rcn-ee : that won't work .. I'm using the roll-your own kernel from your A10 guide :P Feb 11 21:08:56 theoretically the 3.19 kernel driver should be >> realtek's Feb 11 22:29:32 <_ssl> rcn-ee ok i've read up a little and think that i want to use wayland instead of X because it's based on og-es right? Feb 11 22:31:33 <_ssl> on a side note: i'd really like to run the /opt/gfxsdkdemos/ogles2/ demos but that directory does not exist on my installation. where do i find them? Feb 11 22:31:37 correct, wayland use "EGL" https://en.wikipedia.org/wiki/EGL_%28API%29 , we have EGL drivers from TI... Feb 11 22:31:57 _ssl, those are gone as of 5.01.01.02, haven't take a moment to update the directions. Feb 11 22:32:28 <_ssl> ok. any other way to test the drivers? Feb 11 22:32:58 <_ssl> es2_info still does not work after doing apt-get update, upgrade and dist-upgrade Feb 11 22:34:55 there are a few "sgx_*" tests, including: xeglinfo Feb 11 22:36:48 <_ssl> debian@arm:/opt/gfxlibraries/gfx_rel_es8.x$ ./xeglinfo Error: couldn't open display Feb 11 22:36:49 <_ssl> meh Feb 11 22:37:23 <_ssl> that's what i *thought* i needed Xorg for Feb 11 22:37:23 (not over serial..) Feb 11 22:38:15 <_ssl> with Xorg i usually started an X server and started the app by typing DISPLAY=:0 ./xeglinfo into the ssh session and it showed up on the BBB Feb 11 22:38:29 <_ssl> but without X, there is no DISPLAY=:0 Feb 11 22:38:58 yet with "kms" there is... Feb 11 22:39:53 <_ssl> umm... so i need to fire up "kms" somehow first?! Feb 11 22:40:19 do you have a console prompt on your hdmi? Feb 11 22:40:38 <_ssl> on my BBB theres an lcd attatched which shows the login promt Feb 11 22:40:49 then kms is enabled and running.. Feb 11 22:40:51 <_ssl> made it work with my custom devicetree Feb 11 22:41:46 <_ssl> so is there a way to tell xeglinfo to run on that (remote) screen, instread of trying to run in my putty session (like i did with DISPLAY=:0 and Xorg) Feb 11 22:42:12 plug in a keyboard Feb 11 22:43:29 <_ssl> don't have one around :/ Feb 12 00:57:34 Anyone had experience with Beaglebone black + CAN cape TT3201? Feb 12 01:24:40 so the public BOM I can find for making a beaglebone black lists the processor as a SubArctic Cortex A8 Processor, but the webiste lists the processor as a Sitara Cortex A8 Processor Feb 12 01:25:11 does anyone know where I can find the BOMs for the Sitara based board Feb 12 02:02:28 It looks like the SPI data pins on the BB-xM are 1.8 V; is this correct? Feb 12 02:24:56 Anyone had experience with Beaglebone black + CAN cape TT3201? **** ENDING LOGGING AT Thu Feb 12 02:59:58 2015